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, вариант 1B (фазовый) — точно ложится на сценарий Славы (утро-анализ / вечер-апрув / ночь-последовательная-реализация), минимум новых рисков, переиспользует max_concurrency + merge-lease. Достаточно для «10-20 задач за ночь».
Параллельно — настроить наблюдаемость (ORCH-83) чтобы видеть прогресс ночного прогона утром.
Этап 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?

9.9 KiB Raw Blame History Unescape Escape