160 lines
35 KiB
Markdown
160 lines
35 KiB
Markdown
# 2026-06-09 — Дневник
|
||
|
||
## 🔍 ORCH-087 БЫЛА ЗАСТРЯВШЕЙ 6.5ч — разморозила (05:27 MSK, Слава заметил «статусы неактуальны»)
|
||
- Слава: «посмотри что висит в deploying/monitoring, статусы неактуальные».
|
||
- ⚠️ **Ложная тревога #1 снята:** Plane API v1 запрос `?state=<uuid>` НЕ фильтрует — вернул ВСЕ 89 issue в каждом deploy-статусе. Это артефакт API, не реальное состояние. Реальный статус — только прямым GET issue.
|
||
- ⚠️ **Ложная тревога #2 снята:** коммиты `analyst(ET)` у ВСЕХ ORCH-задач (082/086) — безобидный хардкод-префикс commit-helper, repo=orchestrator правильный. Не баг.
|
||
- 🎯 **РЕАЛЬНЫЙ баг — ORCH-087 (task 64) застряла:** история состояний Plane:
|
||
- 22:49:44 Backlog→To Analyse→Analysis
|
||
- 22:54:25 Analysis→**In Review** (analyst job 718/run 420 отработал успешно, BRD/ТЗ/AC эталон, $1.24)
|
||
- 22:56:49 In Review→**Backlog** ❗ — задачу ОТКАТИЛО в Backlog через 2.5 мин (вероятно мой PATCH/гонка при создании ORCH-89 в то же время ИЛИ sweeper)
|
||
- Итог: Plane=Backlog, БД орка=analysis с НЕзакрытым `brd_review_ended_at=None`, 0 активных jobs → **мёртвая задача 6.5ч**
|
||
- **Фикс (правило ORCH-89, техническая → согласовала сама):** проверила BRD/ТЗ/AC в worktree (эталон, оба требования учтены: G0-расследование bump + эффорт в карточку) → закрыла BRD-clock (`brd_review_ended_at=datetime('now')`) → Plane Backlog→Approved (PATCH 200) → webhook подхватил → **architect job 770/run 426 running**, stage=architecture. Разморожена.
|
||
- ⚠️ **УРОК:** одновременные ручные PATCH-операции в Plane (я создавала ORCH-89 + патчила статусы) могут откатить задачу с In Review в Backlog (гонка/случайное наложение). Когда задача на In Review ждёт approve — НЕ трогать соседние операции в Plane, либо проверять что approve-pending не сбросился. Застрявшую In Review→Backlog ловить по `brd_review_ended_at IS NULL` + stage=analysis + 0 jobs.
|
||
|
||
## ⤷ ORCH-087 расширена 2 замечаниями Славы (09.06 ~05:33 MSK) — оба верны
|
||
- Слава (reply на карточку 087): «(1) мы же нотифай меняли в 86, 87 должна использовать свежий; (2) в карточке время итоговое неправильно считается».
|
||
- **G6 — пересечение 86↔87 (Слава ПРАВ, риск эрозии):** ORCH-86 СЛИТА в main (PR #86, merge 493b9be: F-1 terminal-skip + state_uuid в reconciler.py). НО ветка 087 срезана от 9281788 (ДО 86), отстала на 9 коммитов, трогает `src/reconciler.py`+`tests/test_reconciler.py` — ТЕ ЖЕ файлы что 86. Domerge как есть → затрёт 86 (эрозия, .gitattributes union спасает только CHANGELOG не reconciler.py).
|
||
- **Решение:** ORCH-26 auto_rebase_onto_main сработает на merge-gate (merge_gate.py:113, rebase+force-with-lease ТОЛЬКО ветку). При конфликте reconciler.py → откат на development, dev переделает на свежей базе. Штатно, НЕ лезть руками под работающий конвейер (урок ORCH-26/71). G6 вписан в ТЗ 087.
|
||
- **G5 — итоговое время в карточке врёт (Слава ПРАВ, код-аудит notifications.py):** финальная строка `⏱️ Всего <wall> · агенты <agent_seconds> · твоё <review>`:
|
||
- `agent_seconds`=Σ(finished−started) agent_runs — КОРРЕКТНО.
|
||
- `review_seconds`=brd_review_ended−started — РАЗДУВАЕТСЯ при застое (087 показал «Подтверждение BRD 392м» = мой 6.5ч застой In Review→Backlog, не реальное обдумывание).
|
||
- `wall`=updated_at−created_at — включает ВСЁ ожидание/простой/queue-wait → не сходится с agent+review.
|
||
- G5: честно разделить рабочее (Σ agent_runs) / ожидание человека (только фактическое, без аномалий застоя) / wall (помечать «с ожиданием», не выдавать за работу); итог должен сходиться. AC: задача с искусств. застоем 6ч → «твоё время» НЕ показывает 6ч.
|
||
- PATCH ORCH-087 desc 200 (16767 симв). Задача идёт: analyst→architect(done, ADR корень=гонка update_task_tracker из ≥5 потоков без замка)→developer running (job 771).
|
||
- ⚠️ Следить: на merge-gate 087 ОБЯЗАН отребейзиться на main с 86. Проверить что reconciler.py 86 НЕ затёрт после merge 087 (регресс-гард ORCH-73 check_main_regression должен поймать).
|
||
|
||
## ↩️ ОТКАТ моей ошибки + ВАРИАНТ А (перепрогон 087 на свежей базе) (09.06 ~05:43 MSK)
|
||
- **МОЯ ОШИБКА:** Слава НАМЕРЕННО перевёл 087 в Backlog (вчера 22:56), чтобы перепрогнать через аналитика со СВЕЖИМ нотифаем из 86. Я приняла за «застряла» и протолкнула вперёд на СТАРОМ анализе (без 86). Слава поправил → откатываю.
|
||
- **Решение Славы: ВАРИАНТ А** — полный перепрогон через аналитика на свежей базе (main с 86).
|
||
- **Выполнено чисто (по урокам ORCH-81/26):**
|
||
1. developer pid 2130 был ЖИВ (проверила CPU delta=21/4с, 9 сокетов — НЕ убивала вслепую). Исчерпала ретраи job 771 (max_attempts=attempts) ПЕРЕД kill → SIGTERM → graceful выход 2с → job 771=failed, БЕЗ requeue.
|
||
2. Удалила worktree + локальную + **remote** ветку 87 (была срезана от 9281788, ДО 86). Бэкап рефа: `backup/ORCH-087-oldbase-20260609-084302` (194d6c8, работа developer'а на старой базе — на случай если понадобится).
|
||
3. Удалила task64 + jobs + agent_runs из БД орка → webhook на To Analyse пойдёт по `start_pipeline` (if not existing) = СВЕЖАЯ task + ветка от origin/main (493b9be с 86) + аналитик с нуля.
|
||
4. Plane 087 → Backlog (PATCH 200).
|
||
- ⚠️ **ВАЖНАЯ МЕХАНИКА (запомнить):** webhook на To Analyse при СУЩЕСТВУЮЩЕЙ task НЕ создаёт новую — релончит агента ТЕКУЩЕЙ стадии на ТОЙ ЖЕ ветке (webhooks/plane.py:250-300). Чтобы перепрогнать с НУЛЯ на свежем main — удалить task+ветку, тогда start_pipeline режет ветку от origin/main (git_worktree.py:86 `worktree add -b ... origin/main`).
|
||
- ✅ **Готово к запуску:** 087 в Backlog, чистая. При переводе в To Analyse аналитик прогонит на main с фиксом 86. ТЗ 087 уже содержит G5 (время) + G6 (использовать свежий notify/reconciler 86).
|
||
- ⚠️ УРОК: НЕ интерпретировать действия Славы как «баг застрял» без проверки его сообщений. Он перевёл в Backlog ОСОЗНАННО (написал про нотифай) — я не связала. Читать контекст реплаев внимательнее.
|
||
|
||
## ✅ ORCH-087 ПЕРЕЗАПУЩЕНА на свежей базе (09.06 ~05:50 MSK) + 📝 ORCH-90 STOP-механизм заведён
|
||
- **ORCH-087 запуск:** Plane Backlog→To Analyse (PATCH 200) → webhook `start_pipeline` (task64 удалена → if not existing) → **новая task 65**, stage=analysis, **analyst job 772 run 428 running**, ветка от свежего origin/main `493b9be`. Проверено: reconciler.py = 6× skipped_terminal_total → **фикс 86 на месте**, ветка содержит свежий main. Аналитик прогонит на свежей базе с нотифаем 86. ТЗ содержит G5(время)+G6(свежий 86).
|
||
- **📝 ORCH-90 STOP-механизм заведён** (Слава заказал) seq=90 id=dec2d922-9c98-4180-afd0-2abc507645aa, Backlog, HIGH:
|
||
- Идея Славы: новый Plane-статус **STOP** → орк немедленно останавливает работу (SIGTERM агенту, cancel job'ов, исчерпать ретраи, снять таймеры).
|
||
- **STOP = полный сброс прогресса.** Повторный запуск ТОЛЬКО через To Analyse (с нуля: свежая ветка от origin/main + аналитик).
|
||
- **Промежуточные статусы (Development/Architecture/...) вручную НЕ запускают стадии** — закрыть текущую дыру (handle_status_start релончит агента текущей стадии на той же ветке — ИМЕННО это вызвало сегодняшний инцидент с 087, когда я случайно протолкнула через статусы).
|
||
- G1 остановка / G2 полный сброс ветки+worktree+task / G3 единственный вход=To Analyse / G4 промежуточные статусы=no action / G5 идемпотентность+fail-safe при прерывании merge/deploy.
|
||
- Технические зацепки в карточке: webhooks/plane.py диспетчер, launcher SIGTERM, queue_worker cancel, git_worktree, новый STOP-UUID (группа cancelled). never-raise/kill-switch/self-hosting safety/не путать с Rejected.
|
||
- 🎯 Прямая мотивация: сегодняшний ручной откат 087 (kill+удаление ветки+task вручную) — это и должен делать STOP автоматически.
|
||
|
||
## ✅ ORCH-087 BRD APPROVED на свежей базе (09.06 ~05:58 MSK, Стрим сама — ORCH-89)
|
||
- Проверила свежие BRD(11к)/ТЗ(14к)/AC(9к) перепрогона (task 65, analyst run 428) — ЭТАЛОН, все замечания учтены:
|
||
- **BR-G6 + AC-6.1/6.2** — ветка от main с ORCH-86, reconciler.py не эродирован, проверка на merge-gate (маркеры 86 присутствуют).
|
||
- **BR-G5 + AC-5.1/5.2/5.3** — честное время: AC-5.1 застой 6ч → «твоё время» НЕ 6ч (ровно мой косяк), agent-время точное, итог сходится.
|
||
- BR-EFF/AC-E.1-4 эффорт в карточке (developer=xhigh из стампа resolve_agent_effort при запуске — эффорт не возвращается в result-JSON), G0-расследование, never-raise, ссылки/preview сохранены. 18 AC.
|
||
- PATCH In Review→Approved (200) → architect job 773 run 429 running, stage=architecture. Идёт автономно на свежей базе.
|
||
|
||
## 🔄 ORCH-88 ПЕРЕСМОТРЕН — полностью ПОСЛЕДОВАТЕЛЬНЫЙ E2E (Слава, 09.06 ~06:05 MSK)
|
||
- **Решение Славы:** после инцидентов 08-09.06 (эрозия main, перезатирание, ветка 087 срезана до 086) — отказ от параллелизма. Задачи строго ПОСЛЕДОВАТЕЛЬНО e2e: аналитика N+1 стартует ТОЛЬКО когда N задеплоена (stage=done). Post-deploy мониторинг (~15м) НЕ в счёт. «Восстановление дороже».
|
||
- **Корень (почему от АНАЛИЗА, не от merge):** анализ создаёт ветку от origin/main (git_worktree.py). Если N+1 анализируется пока N не в main → ветка от устаревшего main (= сегодняшний 087 до 086). Serial от анализа = каждая ветка от свежего main со всеми предыдущими.
|
||
- **Это РАДИКАЛЬНО упрощает Этап 1:** не нужны merge-очередь FIFO / pre-merge rebase / фазовый A-B-C. Достаточно ОДИН gate планировщика:
|
||
- FR-1 serial gate: не запускать analysis пока есть НЕ-done задача (stage<done) в репо.
|
||
- FR-2 очередь не параллель: «пачка утром» = в очередь, обработка по одной e2e.
|
||
- FR-3 per-repo (orch vs enduro параллельны — main-ы независимы).
|
||
- FR-4 restart-safe (gate по БД, не in-memory).
|
||
- **⚠️ Открытые вопросы к Славе (в карточке):** (1) меняется батч-сценарий — BRD появляются по одному (не пачкой днём) → подтвердить размен надёжность>батч-просмотр; (2) merge vs deploy как сигнал «завершена» (предложила deploy-done — один чёткий сигнал); (3) auto-rollback ORCH-21 во время мониторинга — приостановить gate+алерт?
|
||
- Зависимость ORCH-88←ORCH-83 сохраняется. PATCH 200 (13847 симв). Backlog.
|
||
|
||
## ✅ ORCH-88 СКОУП ЗАФИКСИРОВАН (Слава, 09.06 ~06:14) — решения по 3 вопросам
|
||
- (1) **Serial e2e подтверждён** — BRD по одному, не пачкой. Осознанный размен надёжность>батч. «Пока так».
|
||
- (2) **Сигнал «завершена» = успешный ПРОД-деплой** (не merge, не staging). Gate N+1 открывается когда N задеплоена в прод (done). Мониторинг не ждём.
|
||
- (3) **Auto-rollback во время мониторинга → ЗАМОРОЗИТЬ gate + алерт** (FR-5). Не стартовать следующую до ручного разбора.
|
||
- ⚠️ **Зависимость ORCH-88←ORCH-83 УБРАНА** (Слава: «сейчас не критично»). 88 запускается независимо.
|
||
- **Итоговый скоуп Этапа 1 (минимальный):** FR-1 serial gate (analysis ждёт done предыдущей в репо) / FR-2 очередь e2e / FR-3 per-repo (orch∥enduro) / FR-4 restart-safe по БД / FR-5 rollback-freeze. БЕЗ merge-очереди/rebase/фазового режима. Backlog, запуск по решению Славы. PATCH 200 (15650 симв).
|
||
|
||
## 🔴 ORCH-087 застряла на development — CI КРАСНЫЙ из-за непереносимого теста (09.06 ~06:40 MSK)
|
||
- Слава: «что тут» (карточка $0.00) → потом «разбирайся, может связано с нештатным срубанием прошлой итерации».
|
||
- **НЕ связано с моими kill** (зомби нет, claude.exe нет, act_runner на хосте жив, я его не трогала). НЕ инфраструктура.
|
||
- **Корень (распаковала zst-лог CI 1240 из gitea-контейнера):** ОДИН тест упал —
|
||
`FAILED tests/test_launcher.py::TestEffortStamp::test_spawn_stamps_resolved_effort - PermissionError: [Errno 13] Permission denied: '/app'`. **1 failed, 1089 passed.**
|
||
- **Механизм:** `launcher._spawn` (стр.464) хардкодит `output_path="/app/data/runs/{run_id}.log"` + `os.makedirs('/app/data/runs')`. Новый тест BR-EFF (стамп эффорта) дёргает `_spawn`, который пытается makedirs('/app/...'). В КОНТЕЙНЕРЕ орка `/app` есть → проходит (я локально видела 1090 passed). В CI на ХОСТЕ (act_runner hostexecutor, юзер slin) `/app` недоступен → PermissionError → fail.
|
||
- **Это законный баг теста:** developer не замокал хардкод `/app` в `_spawn`. Тест окружение-зависимый (контейнер vs CI-хост). check_ci_green ПРАВИЛЬНО держит задачу на development (гейт работает).
|
||
- ⚠️ Почему dev получил 1090 локально: он тоже бежал pytest В контейнере орка (/app есть). CI бежит на хосте — там нет. Расхождение local-vs-CI = непереносимый тест.
|
||
- **Урок:** тесты НЕ должны зависеть от хардкод-путей контейнера (`/app`). _spawn хардкодит /app → надо мокать output_path/makedirs ИЛИ брать путь из settings. Это надо чинить (reviewer должен был поймать, или developer — замокать). Задача вернётся на доработку через REQUEST_CHANGES естественным путём ИЛИ нужно перезапустить dev с указанием.
|
||
- ⏸️ Жду решения Славы: (a) дать конвейеру самому завернуть на reviewer REQUEST_CHANGES; (b) перезапустить developer с явным указанием замокать /app; (c) я через сессию Dev-агента поправлю тест. НЕ обхожу CI-гейт.
|
||
|
||
## 🔒 УРОК ЗАКРЕПЛЁН (Слава: «закрепи») + перезапуск developer (вариант 2)
|
||
- **Урок (класс «зелёный локально → красный CI»):** тесты орка НЕ должны зависеть от хардкод-путей контейнера (`/app`). developer/тестер гоняют pytest В контейнере (/app есть), CI бежит на ХОСТЕ (act_runner hostexecutor под slin, /app НЕТ).
|
||
- Закреплено в 3 местах: (1) ТЗ ORCH-087 — новый AC + fix-требование (мокать output_path/tmp_path или вынести runs-путь в settings); (2) коммент reviewer в Plane ORCH-087; (3) reviewer-чеклист «заворачивать тесты с хардкод-путями контейнера» — для ВСЕХ задач впредь.
|
||
- **Диагностика CI-фейла (метод):** логи Gitea Actions = zstd в gitea-контейнере `/data/gitea/actions_log/admin/orchestrator/dN/NNNN.log.zst`. API `/actions/.../logs` КЭШИРУЕТ старые логи (отдал 07.06!) — распаковывать zst напрямую (`docker cp` + `zstd -dc` на хосте). Статусы: `GET /commits/<sha>/statuses` (все), combined `/status`.
|
||
- ⚠️ TODO: дописать этот урок в MEMORY.md (раздел про тесты) — сейчас не вышло (bootstrap-усечение секции). Дописать append'ом в конец позже.
|
||
|
||
## 🎉 ORCH-087 В ПРОДЕ (09.06 ~07:12 MSK) — перепрогон на свежей базе УСПЕШЕН, автономный деплой
|
||
- Слава: «Аппрувь» (на staging-OK уведомление) → проверила → Confirm Deploy.
|
||
- **developer (job 775/run 431) починил CI-тест ПРАВИЛЬНО (вынос в settings, не костыль):** config.py `runs_dir="/app/data/runs"` + launcher `output_path` через `settings.runs_dir` везде (no hardcoded /app). Проблемный тест test_spawn_stamps_resolved_effort → 1 passed (окружение-независим). CI → success.
|
||
- **Верификация перед прод-деплоем (моя):** G6 цел — ветка от main с 86, reconciler.py НЕ тронут (0 изменений, skipped_terminal_total=6), terminal-skip 86 на месте. Тест-фикс = корневой (хардкод /app убран), не маскировка.
|
||
- **Confirm Deploy → автономный деплой БЕЗ ручного домержа:** PR #87 merged=True (честный, ensure_open_pr ORCH-81 сработал), main a23d4c0, код 087 в main (runs_dir=2, tracker_messages=9). task→done, post-deploy-monitor HEALTHY.
|
||
- **ИТОГ 087:** весь цикл перепрогона на свежей базе (после моего отката варианта А) прошёл чисто: analysis→arch→dev→CI-fail(непереносимый тест)→dev-fix→review→test→staging→prod. Реализованы G1(сироты: леджер tracker_messages)/G2(заголовок)/G3(deploy-цикл)/BR-EFF(эффорт в карточке)/BR-G5(честное время, cap brd-review)/G6(свежий 86)/G7(гонка метрик)+урок про /app.
|
||
- ✅ Карточка трекера теперь: не оставляет сирот, показывает эффорт (· model · effort), честное итоговое время (cap на застой). Баг со скриншота Славы закрыт.
|
||
|
||
## 🚀 ORCH-88 ЗАПУЩЕНА (serial e2e) + ✏️ ORCH-89 ПЕРЕПИСАНА (авто-режим по лейблам) (09.06 ~07:35 MSK)
|
||
- **ORCH-88 запуск:** перед To Analyse вычистила МИНУ — карточка содержала ДВЕ противоречивые версии скоупа подряд (старый фазовый A/B/C+merge-очередь+зависимость от ORCH-83 СВЕРХУ, новый serial e2e СНИЗУ). Аналитик прочёл бы весь desc → спроектировал фазовую махину. Переписала: один скоуп serial e2e (FR-1..5) + дисклеймер сверху «фазовый/merge-очередь/ORCH-83 ОТМЕНЕНЫ». PATCH 200.
|
||
- Plane Backlog→To Analyse (PATCH 200) → webhook start_pipeline → **task 66, analyst job 810 run 435 running**, ветка `feature/ORCH-088-orch-88-10-20` от свежего main a23d4c0 (с 86+087). Конвейер был свободен (0 активных). Идёт автономно, жду BRD на апрув.
|
||
- ⚠️ УРОК: при повторных PATCH desc карточки старый текст НЕ затирается — накапливается. Перед запуском задачи ВСЕГДА вычитать ВЕСЬ desc, убрать устаревшие/противоречивые блоки, иначе аналитик возьмёт не ту версию. Single source of truth в одной карточке.
|
||
- **ORCH-89 переписана (Слава: «забудь прошлый подход»):** старая модель «Стрим ревьюит и аппрувит BRD технических задач» ОТМЕНЕНА. Новая модель — **автономность по ЛЕЙБЛАМ Plane**:
|
||
- `autoApprove` → орк САМ подтверждает BRD (гейт 1, In Review→Approved), без человека.
|
||
- `autoDeploy` → орк САМ подтверждает прод-деплой (гейт 2, Confirm Deploy) и деплоит, без человека.
|
||
- Лейблы независимы; оба = полная автономность анализ→деплой. Без лейблов = текущее ручное поведение.
|
||
- 🔒 Авто снимает ТОЛЬКО человеческое решение. Тех-гейты (CI green, staging healthy, provenance, regression-guard ORCH-73, merge-lease ORCH-81) ОСТАЮТСЯ — autoDeploy НЕ деплоит сломанное.
|
||
- fail-safe: label неясен → откат к ручному гейту. Каждый авто-проход логируется в карточку/Telegram (прозрачность).
|
||
- 7 AC. Лейблов в проекте СЕЙЧАС нет (count=0) → создать autoApprove/autoDeploy (labels API v1 работает). Новое name + desc, PATCH 200. Backlog.
|
||
|
||
## 🐛 ORCH-91 ЗАВЕДЕНА — заголовок карточки застывает «To Analyse» на stage=deploy-staging (09.06 ~08:25 MSK)
|
||
- **Слава (скрин):** «почему опять на тестировании To Analyse». Карточка ORCH-088: тело все стадии ✅ ($20+), а заголовок «📍 To Analyse».
|
||
- ⚠️ Сначала решила «косметика/гонка bump» — но ПРОВЕРИЛА КОДОМ и нашла РЕАЛЬНЫЙ детерминированный баг:
|
||
- `tasks.stage='deploy-staging'`, а в `_STAGE_STATUS_LABEL` (notifications.py ~941) НЕТ ключа `deploy-staging` (только `deploy`). `.get(stage, _DEFAULT_STATUS_LABEL)` → дефолт «To Analyse».
|
||
- Воспроизведено: `plane_status_label(task66)` → 'To Analyse' при stage='deploy-staging'. `render_task_tracker(66)` свежий → тоже «To Analyse».
|
||
- render stateless и читает stage каждый раз — рендер ОК, баг в СЛОВАРЕ меток. Не bump, не сироты (леджер tracker_messages работает: 18432 активна, старые deleted).
|
||
- **Шире:** набор реальных stage-значений stage_engine/STAGE_TRANSITIONS РАСХОДИТСЯ с ключами `_STAGE_STATUS_LABEL`. Возможно не только deploy-staging выпадает — проверить deploy-prod/confirm и др. при реализации.
|
||
- **Связь с ORCH-87:** 87 закрыл сирот+эффорт+время, но G2 «заголовок не застывает» НЕ полностью — этот кейс (неизвестный stage→дефолт) остался. ORCH-91 = follow-up.
|
||
- ORCH-91 seq=91 id=60bba158-c1b2-40d5-98e4-e0d9f31b578e, Backlog, medium. BR-1 все stage имеют метку / BR-2 deploy-staging→Deploying / BR-3 анти-регресс тест по всем STAGE_TRANSITIONS / 4 AC. Где: notifications.py _STAGE_STATUS_LABEL + plane_status_label, сверить со stage_engine.
|
||
- ⚠️ УРОК: не объявлять «косметика» не проверив кодом. Сначала решила гонка bump — оказался детерминированный баг словаря. Воспроизводить вживую (render_task_tracker + plane_status_label) ПЕРЕД выводом.
|
||
|
||
## 🔬 Системное ревью 6 промптов агентов + ORCH-92 «промпт-аудит» (09.06 ~15:30 MSK)
|
||
- **Контекст:** Слава спросил про роль аналитика (БА vs системный). Вывод: агент-«аналитик» делает 01-brd (БА) + 02-trz (модули src/, API, схема БД — уже **системный анализ**) + 03-acceptance-criteria + 04-test-plan → это **бизнес-системный аналитик**, не чистый БА (спускается до src/-модулей и схемы БД).
|
||
- **По просьбе Славы провела системное ревью всех 6 промптов** (`.openclaw/agents/`: analyst/architect/developer/reviewer/tester/deployer). Достала из main через exec. Качество высокое (52d/52e подтянули единый канон Anthropic, эмит схемы 52c, анти-регресс).
|
||
- **3 системные проблемы найдены:**
|
||
1. (изначально подозревала рассинхрон tester-гейта `check_tests_passed` vs `_parse_tests_verdict`)
|
||
2. вердикт-формат tester читает `result:`
|
||
3. сверка имён гейтов в промптах с реестром QG_CHECKS.
|
||
- ⚠️ **КЛЮЧЕВОЙ УРОК ДНЯ (проверка кодом окупилась):** перед закладкой P0-замечаний в ТЗ ВЕРИФИЦИРОВАЛА их реальным кодом (`grep` по checks.py / QG_CHECKS). **Моё P0-замечание №2 оказалось ЛОЖНЫМ:** гейт `check_tests_passed` **реально существует** (`checks.py:182`, в `QG_CHECKS:765`) — tester.md называет его **ВЕРНО**. Я спутала с внутренним хелпером `_parse_tests_verdict` (это не имя гейта). Если бы не проверила — аналитик пошёл бы «чинить» то, что не сломано. → **Правило: ВСЕГДА верифицировать замечания/баги кодом ПЕРЕД закладкой в ТЗ. Не доверять памяти про имена функций/гейтов.**
|
||
- **Реальные имена гейтов в QG_CHECKS** (проверено grep'ом checks.py): check_analysis_complete, check_architecture_done, check_ci_green, check_tests_passed (checks.py:182), check_security_gate. tester читает вердикт `result:` — security-гейт зовётся `check_security_gate`.
|
||
- **ORCH-92 заведена** (seq 92, id 4f83483e-89b8-4c7f-80a8-ae69e4d1cd10, HIGH): «промпт-аудит» с детальными ПРОВЕРЕННЫМИ замечаниями. В карточке явно отмечено: «подозрение про check_tests_passed было ложным — гейт верный, НЕ трогать».
|
||
- **Запуск:** навесила autoDeploy (label f04e2721-1f9b-469e-bd2b-d87e7c3b106f) → To Analyse → webhook start_pipeline → **task, stage=analysis, analyst job 1069 running**, ветка `feature/ORCH-092-6-escalation`. Идёт автономно.
|
||
- Скрипт создания: `temp/create_promptaudit.py` (21469 байт).
|
||
|
||
## 📌 Состояние ORCH-задач на конец сессии (09.06 ~15:36 MSK)
|
||
- **ORCH-87** ✅ В ПРОДЕ (перепрогон на свежей базе успешен, сироты+эффорт+время+G6 закрыты).
|
||
- **ORCH-88** идёт (serial e2e gate, task 66, заведена утром).
|
||
- **ORCH-89** Backlog (переписана: автономность по лейблам autoApprove/autoDeploy).
|
||
- **ORCH-90** Backlog (STOP-механизм, HIGH).
|
||
- **ORCH-91** Backlog (баг словаря _STAGE_STATUS_LABEL: нет ключа deploy-staging→дефолт «To Analyse»).
|
||
- **ORCH-92** running (промпт-аудит, autoDeploy, analyst job 1069).
|
||
|
||
## 🔀 ORCH-72 → дубль (Cancelled), всё слито в ORCH-91 — баг карточки трекера, 3 дефекта (09.06 ~15:50 MSK)
|
||
- **Слава:** «72 и 91 разберись, баг въедливый. Проанализируй таски/прод/логи/телегу, заверни всё в 91, 72 отмени как дубль».
|
||
- **Анализ обеих карточек Plane:** оба — про ОДИН баг live-карточки трекера (ORCH-067). 72 старше (Слава 08.06), 91 свежее (09.06, мой детерминированный repro). ⚠️ 72 ШИРЕ — содержит 3 дефекта; 91 покрывал только дефект 1. Простое «отменить 72» потеряло бы дефекты 2/3 → слила ВСЁ в 91.
|
||
- **3 дефекта (все верифицированы кодом/БД прода 09.06 — урок дня сработал):**
|
||
- **Деф.1 (заголовок «To Analyse»):** `_STAGE_STATUS_LABEL` (notifications.py:940) = 8 ключей, нет `deploy-staging`. Реальные stage = ключи `STAGE_TRANSITIONS` (src/stages.py): 9 шт, не покрыта РОВНО `deploy-staging` → `.get(stage, _DEFAULT)` → «To Analyse». Проверено программно: из 9 stage непокрыта одна (deploy-staging), но фолбэк-«To Analyse» = мина на будущее.
|
||
- **Деф.2 (откаты):** при rollback стадии карточка не снимает ✅ с верхних стадий («Внедрение ✅, но идёт Разработка 🔄»). Требование: снимать ✅ после точки отката.
|
||
- **Деф.3 (метрики 💰🔢⏱, НЕ косметика):** карточка берёт ПОСЛЕДНИЙ agent_run на стадию, теряя ретраи. **Верифицировано на ORCH-069 (task 54):** developer×3=$3.98, reviewer×3=$2.10, tester×2, deployer×2 — карточка показывала ~$0 за «Разработка», тотал занижен. Требование: Σ всех agent_runs по (task_id,agent) для $/токенов/времени.
|
||
- **Сделано (Plane):** PATCH 091 desc (полное ТЗ, 3 дефекта, AC-1..7) + priority high (200); PATCH 072→Cancelled (200); коммент-трассировка на обе (201/201). На 091 уже висели лейблы autoApprove+autoDeploy → запустится автономно.
|
||
- ⚠️ Источник истины stage = `src/stages.py STAGE_TRANSITIONS` (НЕ stage_engine — там нет такого атрибута). Реальные tasks.stage = его КЛЮЧИ: created/analysis/architecture/development/review/testing/deploy-staging/deploy/done.
|
||
- Скрипты: temp/inspect_72_91.py, inspect3.py, merge_72_into_91.py.
|
||
|
||
## 🚀 ORCH-091 ЗАПУЩЕНА (Слава: «Погнали», 09.06 ~15:52 MSK)
|
||
- Plane Backlog→To Analyse (PATCH 200) → webhook start_pipeline → **task 77, analyst job 1111 queued**, ветка `feature/ORCH-091-bug-to-analyse-stage-deploy-st` от свежего main.
|
||
- Конвейер serial (max_concurrency=1, serial_gate ORCH-88 в проде): очередь = 063(developer running)→062(analyst q)→090(analyst q)→**091(analyst q)**. Пойдёт по одной e2e.
|
||
- ⚠️ 063 уже на development (job 1110), не architecture — продвинулась пока разбирала 72/91.
|
||
- 091 несёт autoApprove+autoDeploy → пройдёт автономно (BRD сама подтвердит, прод сама задеплоит после тех-гейтов).
|
||
- ⚠️ Хвост старых ET-задач (task 2,3,5,6,18,31) висит в analysis/development БЕЗ активных job — старые смоук-тесты, не наш конвейер, не трогаю (serial-gate их игнорит т.к. репо enduro≠orchestrator, либо это мусор для будущей чистки).
|