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

tasks/orchestrator/ORCH-88_BATCH_AUTONOMY_ANALYSIS.md

@@ -0,0 +1,79 @@
+# ORCH-88 — Анализ: пакетный автономный режим (10-20 задач за ночь)
+
+**Автор:** Стрим · **Дата:** 2026-06-08 · **Заказчик:** Слава
+**Сценарий:** утром запустить 10-20 задач в анализ → днём просмотреть BRD → вечером заапрувить пачкой → ночью орк автономно реализует. Без перетираний/конфликтов.
+
+---
+
+## 0. Что УЖЕ есть (аудит кода 08.06 — не изобретать заново)
+
+| Механизм | Что делает | Статус |
+|---|---|---|
+| `max_concurrency=1` (queue_worker) | очередь исполняет джобы ПО ОДНОМУ | ✅ работает |
+| claim FIFO (`ORDER BY id LIMIT 1`) | берёт старейший queued джоб | ✅ |
+| Стадии enqueue по одной | след. стадия создаётся ПОСЛЕ завершения текущей | ✅ |
+| ORCH-26 merge-сериализация | `auto_rebase_onto_main` + `--force-with-lease` + per-repo merge-lease | ✅ защищает от ЗАТИРАНИЯ КОДА |
+| ORCH-26 task_deps | `is_task_ready`/`declare_dependency`/`detect_cycle`, гейт не клеймит blocked | ✅ |
+| ORCH-73 merge-verify | SHA-в-main, регресс-гард | ✅ |
+
+## 1. ЕСТЬ ЛИ РИСК ПЕРЕТИРАНИЯ? — ДА (главный вывод)
+
+`max_concurrency=1` означает «один agent-run за раз», НО claim = **FIFO по ДЖОБАМ, не по задачам**. При пачке из 15 задач джобы РАЗНЫХ задач ЧЕРЕДУЮТСЯ:
+```
+analyst(A) → analyst(B) → analyst(C) → architect(A) → developer(B) → architect(C) → developer(A) ...
+```
+
+**Два уровня риска:**
+
+- **Код-затирание (FIXED).** Когда задача A смержилась в main, задача B при своём merge делает `auto_rebase_onto_main` (ORCH-26) → код A не теряется. ✅ Этот риск ЗАКРЫТ.
+- **Логический stale-анализ (НЕ закрыт).** Аналитик/архитектор B читал main ДО мержа A. B спроектирована под устаревший main. `auto_rebase` сольёт текст без git-конфликта, но **B не знает про изменения A** → может: дублировать логику, сломать инвариант A, конфликт по смыслу (не по строкам). Это и есть «аналитик ковыряется в устаревших файлах» — точная формулировка Славы. ⚠️ **ОТКРЫТ.**
+- **Git-конфликт при rebase.** Если A и B правят один файл — `auto_rebase` упадёт с конфликтом → задача B встанет (HOLD). Сейчас разрешается вручную. ⚠️
+
+## 2. Чего Слава хочет (2 этапа)
+
+- **Этап 1 (последовательно):** пока одна задача не завершилась ПОЛНОСТЬЮ (доехала до done/main), другая не стартует. Аналитик всегда видит свежий main. Медленно, но 100% без stale/конфликтов. **Для ночного прогона 10-20 задач — безопасно.**
+- **Этап 2 (параллельно):** задачи идут параллельно с умной координацией (где безопасно).
+
+## 3. ВАРИАНТЫ РЕШЕНИЯ
+
+### Этап 1 — последовательное исполнение (сделать первым)
+
+**Вариант 1A — глобальный «task-lease» (один активный work-item за раз).**
+- Новый гейт в claim: не клеймить джоб задачи, если ЕСТЬ другая НЕ-done задача того же репо с активными/пройденными стадиями (in-flight).
+- Очередь FIFO по задачам: первая задача проходит analyst→...→done, ТОЛЬКО потом стартует analyst второй.
+- Реализация: расширить `claim_next_job` dep_gate'ом «нет другой in-flight задачи в этом репо» (по аналогии с task_deps, но глобально per-repo).
+- Плюс: минимальная правка, переиспользует существующий dep-gate-механизм. Минус: медленно (полный цикл задачи ~30-40 мин × 15 = ночь — но это и есть план Славы).
+- ⚠️ approve-gate: задача встаёт на BRD-approve (In Review). «Последовательно» должно означать: следующая стартует после ВСЕЙ предыдущей (включая её approve+merge), ИЛИ — режим «пачка анализа сначала, пачка разработки потом» (см. 1B).
+
+**Вариант 1B — фазовый пакетный режим (ТОЧНО под сценарий Славы).**
+- Явные ФАЗЫ пачки: (Фаза A) все 15 задач проходят ТОЛЬКО анализ (analyst→BRD→In Review), параллельно или последовательно — анализ main НЕ меняет, безопасно; (Фаза B) Слава апрувит пачку; (Фаза C) разработка+merge — ПОСЛЕДОВАТЕЛЬНО (одна задача analyst-после-апрува→dev→merge→done, потом следующая, каждая ребейзится на свежий main ПОСЛЕ предыдущей).
+- Это ровно «утром анализ, вечером апрув, ночью последовательная реализация».
+- ⚠️ Тонкость: после апрува BRD у задачи ещё раз идёт architect/developer, которые ТОЖЕ читают main. Чтобы аналитик/архитектор не ковырялись в устаревшем — пере-валидация/ре-анализ свежего main ПЕРЕД разработкой каждой задачи в фазе C (или просто строгая последовательность C).
+
+### Этап 2 — умная параллельность (потом)
+
+**Вариант 2A — параллельно по НЕпересекающимся файлам.**
+- Анализатор задачи декларирует «затрагиваемые файлы/модули» (есть в ТЗ — «Задействованные модули»). Планировщик пускает параллельно задачи с НЕпересекающимися наборами файлов; пересекающиеся — последовательно (auto-dependency).
+- Использует ORCH-26 `declare_dependency` + detect_cycle. Нужен: парсер «затронутых файлов» из ТЗ/ADR → авто-граф зависимостей.
+
+**Вариант 2B — merge-очередь + обязательный ре-анализ при stale.**
+- Параллельный анализ/разработка, но перед merge: если main изменился с момента старта задачи И задача трогает изменённые файлы → авто-ре-прогон (re-review/re-test на свежем main), иначе merge.
+- Сложнее, но максимально автономно и быстро.
+
+## 4. РЕКОМЕНДАЦИЯ
+
+1. **Сначала Этап 1, вариант 1B (фазовый)** — точно ложится на сценарий Славы (утро-анализ / вечер-апрув / ночь-последовательная-реализация), минимум новых рисков, переиспользует max_concurrency + merge-lease. Достаточно для «10-20 задач за ночь».
+2. **Параллельно — настроить наблюдаемость (ORCH-83)** чтобы видеть прогресс ночного прогона утром.
+3. **Этап 2 (2A по файлам)** — когда Этап 1 обкатан и захочется скорости.
+
+## 5. Что доработать (декомпозиция Этапа 1)
+- D1. Гейт «один активный work-item на репо» в claim (kill-switch, per-repo, не трогает enduro).
+- D2. Фазовый режим: пакетный запуск в анализ; групповой approve; последовательная фаза реализации с ре-базой на свежий main перед каждой.
+- D3. (страховка) При git-конфликте rebase в пакете — НЕ вешать весь пакет: пометить задачу Blocked+alert, продолжить следующую.
+- D4. Ре-валидация свежего main перед разработкой задачи в фазе C (анти-stale).
+- D5. Конфиг: размер пачки, режим (sequential/phased), окно «ночь».
+
+## 6. Открытые вопросы к Славе
+- В Этапе 1: «последовательно» = задача целиком до done, потом следующая (1A)? ИЛИ фазами — сначала вся пачка в анализ, потом вся в разработку последовательно (1B)? (Думаю 1B — ближе к твоим словам.)
+- Approve: пачкой одной кнопкой или каждую отдельно? (Для «вечером апрувлю и иду спать» — нужен пакетный approve.)
+- Окно «ночь»: фаза реализации стартует по времени (cron 23:00) или сразу после пакетного approve?