From 7e5f185265c54ae9c910279ffe00bdfd05a3f758 Mon Sep 17 00:00:00 2001 From: Stream Date: Tue, 9 Jun 2026 09:10:01 +0300 Subject: [PATCH] auto-sync: 2026-06-09 09:10:01 --- memory/2026-06-09.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/memory/2026-06-09.md b/memory/2026-06-09.md index 7972da5..46198b4 100644 --- a/memory/2026-06-09.md +++ b/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батч-просмотр; (2) merge vs deploy как сигнал «завершена» (предложила deploy-done — один чёткий сигнал); (3) auto-rollback ORCH-21 во время мониторинга — приостановить gate+алерт? +- Зависимость ORCH-88←ORCH-83 сохраняется. PATCH 200 (13847 симв). Backlog.