# 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.