From 7cc5a2edd72874a09432e31e1667f34703487c5d Mon Sep 17 00:00:00 2001 From: Stream Date: Tue, 9 Jun 2026 01:20:01 +0300 Subject: [PATCH] auto-sync: 2026-06-09 01:20:01 --- .../ORCH-88_BATCH_AUTONOMY_ANALYSIS.md | 79 +++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 tasks/orchestrator/ORCH-88_BATCH_AUTONOMY_ANALYSIS.md diff --git a/tasks/orchestrator/ORCH-88_BATCH_AUTONOMY_ANALYSIS.md b/tasks/orchestrator/ORCH-88_BATCH_AUTONOMY_ANALYSIS.md new file mode 100644 index 0000000..c908110 --- /dev/null +++ b/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?