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

memory/2026-06-08.md

@@ -424,6 +424,14 @@
 - seq=87 id=8572689a-7f16-493a-98d0-8f00269e3b68, Backlog, MEDIUM. G1 не оставлять сирот / G2 заголовок не застывает (edit vs bump?) / G3 deploy-статусы видимы. 5 AC.
 - ⚡ **РАСШИРЕНА (Слава, 22:07): +2 требования.** (1) **G0 — СНАЧАЛА РАССЛЕДОВАНИЕ** (не фикс вслепую, НЕ принимать мой workaround-диагноз на веру): сколько реально сирот висело, в какие моменты tracker_message_id рассинхронится (send=None / рестарт / гонка / delete-fail), почему заголовок застывает, bump vs edit с ДАННЫМИ → ADR. (2) **ЭФФОРТ В КАРТОЧКУ:** сейчас строка стадии показывает модель, НО НЕ эффорт → добавить (напр. `opus-4-8 · xhigh`), источник — resolve_agent_effort или колонка agent_runs.effort (фактически применённый). PATCH 200.
 
+## 🌙 ORCH-88 [ЭПИК] ПАКЕТНЫЙ АВТОНОМНЫЙ РЕЖИМ (08.06 ~22:17 UTC) — Слава заказал
+- **Сценарий:** утром 10-20 задач в анализ → днём смотреть BRD → вечером апрув пачкой → ночью автономно реализуются. Семян=88, id=95173987-a029-4878-940a-c205ab8a2be5, Backlog. Анализ: tasks/orchestrator/ORCH-88_BATCH_AUTONOMY_ANALYSIS.md.
+- **ГЛАВНЫЙ ВЫВОД (аудит кода): риск перетирания ЕСТЬ.** max_concurrency=1 = один run за раз, НО claim=FIFO по ДЖОБАМ → джобы разных задач чередуются. **Код-затирание ЗАКРЫТО** (ORCH-26 auto_rebase+lease). **Логический stale-анализ ОТКРЫТ** (аналитик B читал main ДО мержа A → устаревшие файлы — точная формулировка Славы). + git-конфликт rebase при пересечении файлов.
+- **Этап 1 (последовательно):** 1A task-lease (один work-item/репо); **1B фазовый (РЕКОМ) — фаза A вся пачка в анализ / B групповой approve / C последовательная реализация с ре-базой на свежий main**. **Этап 2 (паралл.):** 2A по непересекающимся файлам / 2B merge-очередь+ре-анализ при stale.
+- ⚠️ Открытые вопросы к Славе: 1A vs 1B; approve пачкой vs поотдельно; окно «ночь» cron vs сразу после approve. НАБЛЮДАЕМОСТЬ (ORCH-83) нужна параллельно чтоб видеть прогресс ночного прогона.
+- ✅ **РЕШЕНИЯ СЛАВЫ (22:27):** (1) **Этап 1 = 1B фазовый**; (2) **approve ОТДЕЛЬНО** каждую (не пачкой); (3) **фаза C стартует ПОСЛЕ approve** (не cron); (4) **зависимость ORCH-88 ← ORCH-83** (наблюдаемость обязательна перед боевым пакетным прогоном).
+- ⚠️ **ФАКТ Plane API v1 (проверено + GitHub makeplane #6236):** bulk-операций НЕТ (404), issue-relation (blocked_by/blocking) в API v1 НЕТ (только UI/БД). → «пакетность» реализуется НА СТОРОНЕ ОРКА циклом (single-PATCH работает). Зависимости задач орк хранит у себя (ORCH-26 job_deps), не в Plane. Зависимость 88→83 — текстом в картах (relation в API нет). Реком: label «batch-night» для маркировки пачки (labels API работает).
+
 ## 📝 ORCH-86 заведена — reconciler шлёт шум «ET-002 done разблокирована» в Telegram (08.06 ~21:24 UTC, Слава: «приходит периодически, заводи исправление»)
 - **Продолжение ORCH-068** (тот livelock-фикс done, но НЕ закрыл этот путь). seq=86 id=d8133fbe-d16f-4787-85a4-3cabec4338c2, Backlog, MEDIUM.
 - **Корень (код-аудит):** `_note_unblock` (reconciler.py ~444) шлёт В Telegram. Dedup-guard ORCH-068 ключуется по state_uuid и работает только если state_uuid≠None. НО путь стр.228 (advance_if_gate_passed→_note_unblock) передаёт ТОЛЬКО 2 аргумента без state_uuid → dedup пропускается → шлёт каждый раз. + терминал-скип этот путь не ловит (advance_if_gate_passed считает ET-002 done «продвинувшейся»). Триггерится особенно при СТАРТЕ reconciler (после рестарта). G1 root-cause / G2 терминал-скип на этот путь / G3 state_uuid во все вызовы.