# coordinator-loop

Координаторский цикл: проводит готовые issues через subagent-worker по TDD, держит
границы задач, фильтрует находки и сам делает коммиты.

## Зачем

Когда подряд идёт несколько связанных кодовых срезов, писать их «одним потоком» —
значит терять границы задач и контроль над тем, что попало в коммит. Навык
разделяет роли: один subagent-worker делает **одну** issue по TDD и не коммитит, а
координатор проверяет, классифицирует находки и фиксирует результат. Навык узкий и
работает только по явному вызову (`/coordinator-loop`): он не проектирует, он
исполняет.

## Где в потоке

coordinator-loop — исполнительное звено в середине цепочки, а не вся цепочка:

```text
проектная документация    (/brainstorm-with-docs | /grill-with-docs)
        ↓
узкие проверяемые issues  (/to-issues)
        ↓
coordinator-loop          каждый issue: worker (/goal + /tdd) + независимое ревью
                          (запускает координатор) → индекс → коммит координатора;
                          в финале — ревью на соответствие замыслу + handoff
        ↓
приёмка                   ручной кросс-линия ревью (обычно Claude) + проверка человеком
```

- **До скилла — проектирование.** Сначала выверенная верхнеуровневая документация
  (`/brainstorm-with-docs` или `/grill-with-docs`): без неё issues не на чем
  основывать. Затем `/to-issues` режет её на узкие задачи. Именно здесь
  закладывается проверяемость результата (см. «Что получается»).
- **Скилл — исполнение.** Берёт **готовые** issues по одной и проводит каждую через
  цикл worker (`/goal` + `/tdd`) → независимое ревью (ревьюеры-наблюдатели, запускает
  координатор; триаж находок — в worker-е) → индекс → chain-level классификация →
  коммит координатора. Контекст координатора держится на индексах, не на diff'ах.
  В финале цепочки координатор прогоняет ревью на соответствие замыслу (целое против
  исходной спеки, сильной моделью на усиленном уровне) и пишет handoff, готовящий
  приёмку.
- **После скилла — приёмка.** Ревью другой модельной линией (Codex ревьюил Codex, так
  что кросс-линия — обычно ручной проход Клодом) плюс проверка человеком. Скилл её не
  автоматизирует — только передаёт эстафету с зафиксированным открытым риском.

## Что делает и чего не делает

Делает: ведёт по одному issue за раз, держит границы, фильтрует находки, коммитит.
Подробный цикл и роли — в [SKILL.md](SKILL.md).

Не делает:

- не создаёт проектную документацию и не принимает архитектурные решения — это
  предыдущий этап;
- не нарезает issues — это `/to-issues`;
- не отвечает за проверяемость результата — она закладывается при проектировании;
- не делает финальную приёмку — это ревью другим агентом плюс человек;
- не готовит набор issues «пачкой» автоматически — пока не цель.

## Что получается

Результат прогона по одной issue — «пакет для проверки»:

- **отдельный коммит на каждую issue** с узким, в границах задачи, diff;
- **финальный отчёт worker-а**: какие файлы, какие тесты прогнаны, какие acceptance
  criteria закрыты, риски, `git status`;
- **chain-level классификация** (риск / вне скоупа); per-finding триаж («реально /
  ложно / чинить») делает worker по индексам ревьюеров.

Один issue = один проверяемый коммит плюс отчёт — так пост-цикловое ревью и ручная
проверка остаются посильными.

**Про проверяемость.** Прошлый прогон показал: если итог цепочки можно принять
только чтением diff, ручная проверка становится слишком дорогой. Лекарство — на
уровне проектирования: у всего набора issues должен быть **наблюдаемый конечный
результат** для приёмки (запись в Kafka-топик, строки в конкретной таблице, панель
дашборда, вывод команды). Это ответственность `/to-issues` и брейншторма, **не**
этого скилла. Координатор может отметить слабую проверяемость как **риск** и вернуть
сигнал на уровень выше, но сам критерий приёмки не выдумывает.

## Как вызвать

Только по явному запросу — навык узкий и не срабатывает сам:

```text
/coordinator-loop
```

## Статус и что дальше

Экспериментальный — прямое продолжение эксперимента с координатором субагентов,
будет дорабатываться. Открытые вопросы (когда нужен отдельный ревьюер, обязательные
промежуточные отчёты, бюджет worker-а) собраны в разделе «Открытые вопросы»
файла [references/rationale.md](references/rationale.md).

## Что читать рядом

- [SKILL.md](SKILL.md) — как координатор исполняет цикл (инструкция для агента).
- [references/rationale.md](references/rationale.md) — почему цикл устроен так:
  эмпирика эксперимента, находка про ревьюера другой родословной, открытые вопросы.