feat(skill): coordinator-loop — топология ревью под Codex и эскалация

- Зачем:
  - боевой прогон цепочки 07-11 показал: worker в Codex не может запускать
    субагентов, ревью шло пятью кругами без ограничителя, финальный handoff
    и закрытие issue выпадали из цикла.
- Что:
  - ревьюеров запускает координатор (наблюдатели, ограничение промптом),
    триаж находок и флаг «спор» — в worker-е; политика кругов с потолком.
  - две ручки стоимости: модель по роли и уровень мышления, таблица
    references/effort-levels.md; шаблон references/reviewer-prompt.md —
    скилл самодостаточен, без файлов claude-team-review.
  - журнал с метками времени; финал: PRD до ревью, Status: done
    docs-коммитом, handoff — условие выхода; handoff пакета правок.
- Проверка:
  - адверсарное ревью пакета свежим субагентом (2 блокера и 7 important
    закрыты) плюс саморевью; следующий боевой прогон цепочки — замер.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

agents/.agents/skills/coordinator-loop/references/effort-levels.md

@@ -0,0 +1,35 @@
+# Уровни мышления и модели по ролям
+
+Обновлено: 2026-07-04. Логика скилла оперирует относительными уровнями
+(экономный / рабочий / усиленный) и «моделью по роли»; здесь — привязка к
+конкретным настройкам хостов. Вышла новая модель или переименовались уровни —
+правится этот файл, не `SKILL.md`.
+
+## Codex CLI (проверено на боевом прогоне 2026-07-04)
+
+Ручка уровня — reasoning effort субагента (`low` / `medium` / `high` / `xhigh`).
+
+| Роль | Уровень | Настройка |
+|---|---|---|
+| task-lens ревью, диагностика, разбор логов | экономный | ступень ниже дефолта сессии |
+| worker, обычное code review | рабочий | дефолт сессии |
+| узкий гейт по спору, финальное chain-ревью | усиленный | `xhigh` |
+
+Модель по роли: во всех ролях — модель сессии; отдельной дешёвой модели для
+субагентов в текущей конфигурации нет, экономия достигается уровнем.
+
+## Claude Code (если прогон под этим хостом)
+
+Ручки: effort субагента (`low` / `medium` / `high` / `xhigh` / `max`) и model
+(`haiku` / `sonnet` / `opus`).
+
+| Роль | Уровень | Настройка |
+|---|---|---|
+| task-lens ревью, диагностика, разбор логов | экономный | модель ступень ниже, effort `low`–`medium` |
+| worker, обычное code review | рабочий | модель сессии, effort по умолчанию |
+| узкий гейт по спору, финальное chain-ревью | усиленный | сильная модель, effort `xhigh`–`max` |
+
+## Хост без управляемых уровней
+
+Эскалация вырождается в запуск свежего субагента — слабее, но не пусто
+(см. `SKILL.md`, «Режимы ревью»).

agents/.agents/skills/coordinator-loop/references/rationale.md

@@ -82,6 +82,16 @@ issue. Выводы — хороший сигнал для класса «пос
 > наблюдаемость при обрыве, ретроспективную правку истории и handoff «по памяти»;
 > ложь в момент события ловит только внешняя проверка (кросс-линия, человек).
 
+> **Поправка 2026-07-04.** Боевой прогон цепочки 07 → 11 (генератор кликстрима) дал два
+> уточнения. Первое — факт среды: в Codex worker не может запускать субагентов
+> (проверено диагностом с `agent_type=worker`), поэтому топология изменена — ревьюеров
+> запускает координатор, а триаж находок остаётся в worker-е (см. `SKILL.md` и handoff
+> `2026-07-04-codex-topology-and-escalation.md`). Второе — вопросы про число кругов
+> ревью из списка ниже стали боевыми: issue 07 прошёл пять кругов без ограничителя, а
+> спор с ревьюером разрешил изобретённый по ходу «узкий гейт на xhigh». Ответ закреплён
+> политикой кругов в `SKILL.md`: флаг «спор» в триаже worker-а, узкий гейт на усиленном
+> уровне, потолок четыре круга на issue, дальше — человек.
+
 ## Чего не делать слепо
 
 - Не запускать ревьюера после каждой мелкой правки — дорого и раздувает задачу.
@@ -99,5 +109,7 @@ issue. Выводы — хороший сигнал для класса «пос
 - как заранее понять, что задаче нужен отдельный ревьюер, а не только саморевью;
 - стоит ли заранее обязывать worker-а к промежуточным отчётам на статистике и
   долгих тестах;
-- нужно ли явно ограничивать бюджет worker-а и число кругов ревью;
-- как формализовать порог «большое исправление требует второго круга».
+- нужно ли явно ограничивать бюджет worker-а (число кругов ревью закрыто политикой
+  кругов — поправка 2026-07-04);
+- как формализовать порог «большое исправление требует второго круга» (частично
+  закрыто: rerun после правок по гейт-находкам координатор назначает автоматически).

agents/.agents/skills/coordinator-loop/references/reviewer-prompt.md

@@ -0,0 +1,116 @@
+# Шаблон промпта ревьюеру
+
+Координатор заполняет плейсхолдеры и передаёт текст как промпт
+reviewer-субагенту. Адаптирован из `reviewer-prompt.md` скилла
+`claude-team-review` (2026-07-04) под топологию coordinator-loop: чинящего
+лида здесь нет — правит worker по индексу находок, круги считает координатор.
+
+---
+
+## Шаблон
+
+```text
+Ты — старший адверсарный ревьюер. Твоя работа — подорвать доверие к изменению,
+а не подтвердить его. Скепсис по умолчанию: считай, что в работе есть дыры,
+пока доказательства не показали обратное. Не засчитывай добрые намерения и
+«допилят следом». Работает только на happy path — это настоящая слабость.
+
+## Фокус проверки
+
+{FOCUS}
+# по коду    — тонкие баги, межмодульные инварианты, форма распределений
+# по задаче  — сделано ли то, что требует issue/спека (acceptance criteria)
+# узкий гейт — только спорный вопрос: {SPOR_SUMMARY}
+# chain      — вся реализация цепочки против исходной спеки/PRD (дрейф целого)
+
+## Что проверяем
+
+{ARTIFACT}
+# для issue: текст issue, ссылки на PRD/спеку/смежное — «зачем».
+#   Работа worker-а НЕ закоммичена: смотри рабочее дерево целиком —
+#   `git status --short` (новые файлы untracked, в diff их нет!) плюс
+#   `git diff`; закоммиченная история — контекст, не объект ревью
+# для chain: ключевые пути реализации + исходная спека/PRD;
+#   объект — закоммиченная реализация цепочки
+
+## Круг
+
+{ROUND}   # 1 — первичное ревью; N — rerun после правок worker-а
+
+{PREVIOUS_FINDINGS_BLOCK}
+# Только на rerun (свежий субагент не знает прошлого круга): дословно находки
+# прошлого круга; что worker исправил; что отклонил и с каким обоснованием
+# (контракт/тест). Отклонённое оценивай по существу: обоснование верно —
+# признай; неверно — переформулируй находку с контраргументом и новым
+# доказательством, а не повторением прежней формулировки.
+
+## Что можно
+
+- Читать любые файлы репозитория; git-историю, диффы, ветки.
+- Запускать команды: тесты, линтеры, сборку, воспроизведение находок.
+- Искать в сети и документации (Context7) для проверки предположений.
+
+## Что нельзя
+
+- Создавать, менять или удалять файлы проекта; менять среду (git-операции с
+  записью, установка пакетов, правка конфигов).
+- Чинить находки — это работа worker-а. Ты аудитор, не участник.
+
+## Планка находки
+
+Каждая находка отвечает на четыре вопроса:
+
+1. Что сломается? — конкретный сценарий, не гипотеза.
+2. Почему уязвимо? — `файл:строка` или раздел.
+3. Последствия — что и насколько плохо (потеря данных > простой > деградация).
+4. Рекомендация — конкретный фикс, достаточный worker-у для работы.
+
+Вне скоупа: стиль и нейминг; спекуляции без конкретного сценария; «неплохо
+бы» без связи с корректностью или безопасностью.
+
+Перед докладом верифицируй находку: прогони тесты, сверь документацию,
+воспроизведи путь. Одна проверенная находка стоит десяти догадок; ссылки на
+доки и upstream-issue давай точно — их проверят.
+
+## Калибровка
+
+- Одна сильная находка лучше нескольких слабых.
+- Серьёзность: critical (данные/безопасность) > high (баг в проде) >
+  medium (крайний случай).
+- Работа крепкая — так и скажи: ложные тревоги подрывают доверие.
+
+## Формат ответа — индекс, не нарратив
+
+**Findings:** на каждую — `[severity]`, `файл:строка`, какой критерий нарушен,
+минимальный repro, рекомендация. Без diff, без полного вывода тестов, без
+нарратива рассуждений. Нет находок — «No actionable findings».
+
+Последняя строка ответа — ровно одна из:
+VERDICT: APPROVED
+VERDICT: CHANGES_REQUESTED
+
+APPROVED — находок нет или все medium без нарушения acceptance criteria.
+CHANGES_REQUESTED — есть high/critical или нарушен критерий issue/спеки.
+
+## Язык
+
+Отвечай на русском. Severity, заголовки полей и строку VERDICT оставляй
+латиницей как есть.
+```
+
+---
+
+## Заметки по запуску
+
+- Координатор собирает бриф сам — ревьюер не наследует историю сессии;
+  передавай только нужное.
+- Модель и уровень мышления — по [effort-levels.md](effort-levels.md):
+  обычное ревью — рабочий уровень, узкий гейт по спору и chain-ревью —
+  усиленный на сильной модели.
+- **Не запускай ревьюера в урезанном/read-only субагенте**: тесты и
+  воспроизведение требуют исполнения команд. Ограничение «не менять
+  репозиторий и среду» держит промпт (раздел «Что нельзя») — как в
+  `claude-team-review`.
+- На узком гейте `{SPOR_SUMMARY}` — формулировка спора из индекса worker-а
+  (находка + его обоснование отклонения) дословно, без интерпретаций
+  координатора.