auto-sync: 2026-06-09 09:10:01

memory/2026-06-09.md

@@ -52,3 +52,14 @@
   - **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.