refactor(codex-playbook): согласована оптика тонкого мастера

- Зачем: - нужно сохранить контекст координатора и устранить расхождения с зеркальным playbook. - Что: - закреплены делегирование, маршрутизация моделей и ограничение кругов ревью. - добавлены файловый договор ревью и согласованная эмпирика прогонов. - исправлены сборка слепых линий и компактные статусы находок. - Проверка: - quick_validate.py, git diff --check и проверка локальных Markdown-ссылок.
2026-07-13 13:07:52 +03:00
1 parent a4985b365d
commit 6cc1b26ce4
@@ -1,132 +1,132 @@
 ---
 name: codex-subagent-playbook
-description: Оптика тонкого мастера для одной нетривиальной задачи: субагенты сохраняют контекст и приносят нужную независимость.
+description: "Оптика тонкого мастера для одной нетривиальной задачи: исследование, планирование, реализация и независимая проверка через субагентов без поглощения контекста координатора."
 ---
 # Тонкий мастер
-Это оптика работы, а не обязательный конвейер. Цель — решить одну
+Это оптика, а не обязательный конвейер. Координатор сохраняет внимание для
-нетривиальную задачу, сохранив внимание мастера для цели, ограничений,
+цели, ограничений, решений, рисков и приёмки. Субагенты выясняют и выполняют;
-решений и рисков. Субагенты нужны результату, а не процессу.
+координатор решает.
 Тонкий мастер не пустой мастер. Он сам принимает решения, делает дешёвые
 точечные проверки и смотрит ключевые артефакты. Исследование, реализацию или
 проверку он отдаёт только тогда, когда отдельный контекст даст задаче
 конкретное преимущество.
 ## Основная оптика
- Перед каждым запуском ответь: что этот агент добавит — защиту контекста,
+- Перед запуском агента назови его вклад: защита контекста, свежий взгляд,
-  свежий взгляд, специализацию, параллельность или отдельную среду проверки?
+  специализация, параллельность или отдельная среда. Без вклада работай сам
-  Если ничего, работай сам или продолжи существующий тред.
+  либо продолжай существующий тред.
- Держи у мастера короткий индекс: цель, ограничения, принятые решения,
+- Сам читай верхнеуровневые документы и принимай решения. Исследование кода,
-  риски, вердикты и доказательства, влияющие на следующий шаг. Полные diff,
+  журналов, зависимостей и вариантов с неизвестным объёмом по умолчанию
-  журналы и нарративы ему не нужны.
+  отдавай субагенту. Самостоятельно проверяй одну узкую гипотезу с коротким
- Исследование с неизвестным или шумным объёмом делегируй до погружения.
+  выводом; дальнейшее погружение делегируй.
-  Одну узкую гипотезу с предсказуемо короткой командой мастер может проверить
+- Держи у себя цель, ограничения, решения, риски, краткие сводки и пути к
-  сам; если ответа нет, продолжение уходит агенту.
+  доказательствам. Полезную нагрузку передавай между агентами файлами, не
- Свежий тред даёт независимость от исполнителя, но не разнообразие ошибок.
+  через контекст координатора.
  Другое семейство моделей даёт отдельную линию; второй агент того же
  семейства оправдан только высоким риском или действительно иным фокусом.
 - Выбирай самый дешёвый надёжный уровень для выбранной работы. Если хост не
  показывает модель и глубину, считай стоимость незакреплённой и не умножай
  совместимые роли без явной пользы.
 - Один исполнитель владеет изменениями исходников. Его же продолжай для
-  исправлений; независимую оценку отдавай свежему треду. Права
+  обычных исправлений. Если исполнитель не справляется, останови его и дай
-  `workspace-write` сами по себе не делают агента владельцем исходников.
+  свежему более сильному агенту постановку, текущее дерево и файловые отчёты.
-
+- Выбирай модель и уровень рассуждения независимо. Повышай effort, когда
-Внешняя модель полезна как дополнительная линия, когда её родословная и цена
+  подходящей модели не хватило глубины; повышай модель, когда не хватает
-оправданы риском. Процесс не должен от неё зависеть.
+  качества суждения. Текущая привязка ролей — в
  [уровнях и ролях](references/roles.md).
 ## Контекст и обмен
- Если результат понадобится следующему агенту, полный отчёт запиши в
+`$SCRATCH` — логический общий каталог одного прогона, доступный координатору и
-  уникальный файл временного обменного каталога. Мастеру верни только итог,
+назначенным агентам. Физически это скретчпад сессии, временный каталог ОС либо
-  счётчики, вопросы-решения и путь. Короткий конечный результат можно вернуть
+гарантированно игнорируемый каталог проекта. В нём живут временные промпты,
-  одним сообщением.
+отчёты, триаж и перепроверки; это не артефакты проекта.
- Канал результата не связан с правами агента. Ревьюеру можно дать рабочие
+
  права для тестов, кэшей, поиска и документации, а запрет менять исходники и
  постоянное окружение удерживать мандатом и сверкой Git до и после.
 - Не возвращай один полный отчёт одновременно файлом и сообщением. Не
  переписывай находки между файлами: передавай исходный путь или собирай новый
  промпт механической конкатенацией.
 - Не выводи в контекст мастера полную точку отсчёта, diff, перечень хэшей или
  сырой журнал. Если дерево грязное или возможны пересечения, порученный
  агент либо готовый скрипт сохраняет подробности во временный файл и сообщает
  только состояние, счётчики, пересечение с разрешённым объёмом и путь.
 - Временные обменные файлы веди на английском. Долговечные документы и текст
-  для пользователя пиши на языке проекта.
+  для партнёра пиши на языке проекта.
- Сообщай пользователю короткий статус на действительно значимых границах, а
+- Полный результат агент пишет в назначенный уникальный файл и возвращает
-  не на каждом служебном переходе. Тайм-аут и `idle` не являются результатом.
+  краткую сводку с путём. Не возвращай тот же полный текст сообщением и не
  переписывай чужой отчёт: передавай путь или собирай новый файл механически.
 - Если общий каталог недоступен, передай через контекст только компактный
  индекс. Сразу сообщи партнёру наблюдаемый сбой, использованный запасной
  канал и то, что нужно проверить после задачи.
 - Права агента не определяют канал результата. Ревьюер может иметь рабочие
  права для тестов и временных файлов, но его единственный назначенный
  результат — отчёт. Исходники, Git и постоянное окружение он не меняет.
-## Когда какой приём полезен
+Точные способы сборки файлов и промптов бери из
 [нативных шаблонов](references/prompt-templates.md) только после выбора
 конкретного приёма.
- **Самодостаточная постановка** нужна, когда исполнитель начинает без истории
+## Выбор приёма
  разговора или проекту важен долговечный след. Для локальной ясной правки
  достаточно короткого мандата.
 - **Исследователь** нужен для неизвестного объёма, внешних фактов или шумного
  обхода репозитория. Его результат — факты и вопросы, не реализация.
 - **Ревью постановки** окупается при скрытых проектных решениях, дорогой ошибке
  или критериях, которые можно выполнить формально без нужного результата.
 - **Исполнитель** нужен, когда отдельный контекст реализации ценнее прямой
  работы мастера. Он не коммитит и не расширяет объём без решения мастера.
 - **Проверяющий** нужен для шумных журналов, специальной среды, стенда или
  независимого подтверждения команд. Не создавай отдельную роль, если те же
  проверки дёшево и надёжно выполняет исполнитель либо ревьюер.
 - **Свежий ревьюер** нужен, когда цена пропущенного дефекта выше стоимости
  обзора. По умолчанию достаточно одного. Вторую линию добавляй ради другого
  семейства моделей или отдельного класса риска, а не ради числа два.
-## Типичный ход задачи
+- **Самодостаточная постановка** нужна исполнителю без истории разговора и
  там, где проекту нужен долговечный след. Для ясной локальной правки хватит
  короткого мандата.
 - **Исследователь** собирает факты неизвестного объёма. Он возвращает записку
  решений и пути к доказательствам, а не реализацию.
 - **Deep-reasoner** готовит архитектурное предложение, декомпозицию или
  сравнение компромиссов. Итоговое решение остаётся у координатора. Важное
  решение полезно проверить двумя слепыми линиями разных семейств.
 - **Исполнитель** получает одну цель, границы и критерии. Он не коммитит и не
  расширяет объём без решения координатора.
 - **Проверяющий** запускает известную проверку в специальной среде или с
  шумным выводом. Не создавай роль, если координатор либо исполнитель может
  получить тот же надёжный результат дёшево.
-Часто полезно уточнить постановку, дать одному исполнителю реализовать её,
+### Режимы ревью
 проверить обязательные свойства и при заметном риске получить свежий обзор.
 Пропускай, объединяй и меняй порядок этих действий, если так надёжнее и
 дешевле достигается результат.
- Перед реализацией разреши продуктовые, архитектурные и относящиеся к
+Для нетривиальной делегируемой постановки один узкий свежий обзор — точка
-  границам решения вне мандата исполнителя. Технический способ внутри мандата
+отсчёта. Пропускай его для ясной ограниченной задачи, если можешь коротко
-  оставь ему.
+назвать причину. Сложную, рискованную или архитектурную постановку проверяй
- Пока исполнитель меняет исходники, не запускай другого владельца тех же
+двумя слепыми линиями, когда цена оправдана.
  файлов. Параллель разрешай для независимых неизменяемых входов, отдельных
  worktree или команд без общего изменяемого состояния.
 - Обязательные и доступные сквозные проверки должны пройти до финальной
  приёмки. Недоступную или падающую проверку нельзя молча превратить в зелёную:
  риск принимает пользователь либо полномочие, заранее записанное в задаче.
 - Ревьюеру дай задачу, изменённый объём, проверки и один выбранный фокус. Он
  исследует и проверяет гипотезы, но не исправляет исходники. Вердикт без
  находок должен назвать просмотренный объём и выполненные проверки либо
  проверенные гипотезы.
 - Находки возвращай тому же исполнителю. Он исправляет или аргументированно
  отклоняет их через контракт и проверку. Исходный ревьюер при необходимости
  узко проверяет свои находки; новый соседний дефект не скрывает.
 - На финале мастер смотрит только решения, остаточные риски, итоговые счётчики
  и действительно ключевые артефакты. Полный diff и отчёты читают агенты,
  которым поручена их проверка. Коммит делай только по просьбе пользователя.
-## Нативные договоры
+Реализацию проверяй по риску:
-Если нужны готовые роли или выбор моделей, прочитай
+- тривиальная — саморевью исполнителя;
-[уровни и роли](references/roles.md). Если роли не настроены, не имитируй
+- обычная — один независимый ревьюер по коду;
-экономию названиями: честно отметь незакреплённую стоимость.
+- сложная или рискованная — два адверсариальных ревьюера: соответствие задаче
  и качество кода.
-Когда выбран конкретный приём, возьми только его договор из
+Разные семейства моделей предпочтительны: они дают больше разнообразия, чем
-[сборки нативных промптов](references/prompt-templates.md). Не загружай все
+два свежих треда одной родословной. Когда внешняя линия технически недоступна,
-шаблоны заранее и не переписывай их текст в вызов агента.
+используй доступных ревьюеров; процесс от неё не зависит.
-При развитии скилла или первом прогоне в новой среде прочитай
+Выбрав ревью постановки или реализации, прочитай единый
-[полевые заметки](references/field-notes.md) и проверь живые предположения.
+[договор ревью и триажа](references/review-and-triage.md). Он определяет
 владельца триажа, файловый канал, повторные проверки и предохранитель кругов.
 ## Приёмка
 Координатор принимает результат, но углубляется в доказательства постепенно:
 1. состав изменений и краткие сводки ревью;
 2. отдельные спорные фрагменты;
 3. полный diff, только когда его объём ограничен и чтение нужно для решения.
 Доступную детерминированную финальную проверку запускай сам с выводом в файл.
 В контекст возьми точную команду, код возврата, итоговые счётчики, имена
 упавших тестов и путь к журналу. Зелёный журнал не читай. Красный журнал
 направь исполнителю или отдельному разборщику; сам открывай детали, когда они
 нужны для решения о границах, риске, среде или смене исполнителя. Если
 проверка доступна только проверяющему в специальной среде, явно назови
 свидетельство косвенным.
 Перед завершением:
 - сопоставь результат с исходной целью и назови всё неподтверждённое;
 - убедись, что выбранная независимая проверка завершена либо риск принят
  полномочным решением;
 - дай партнёру короткую саморефлексию: что больше всего потратило контекст,
  оправдана ли трата, что в следующий раз направить через файл или субагента,
  какие отклонения процесса произошли.
 Новый урок для [эмпирики](references/lessons.md) только предложи партнёру.
 Правь долговечную эмпирику после его согласия.
 ## Сбои координации
- Агент завершился без ожидаемого файла: один раз запроси короткий итог в том
+- Нет ожидаемого файла: один раз запроси короткий итог в том же треде; после
-  же треде; после повторной тишины продолжи свежим агентом от сохранённых
+  повторной тишины продолжи свежим агентом от сохранённых артефактов.
-  артефактов.
+- Длинный рассказ пришёл сообщением: попроси повторить ответ сводкой и путём,
- Агент вернул длинный рассказ в сообщение: попроси повторить ответ индексом и
+  не переноси рассказ дальше.
  путём, не переноси рассказ дальше.
 - Два исполнителя пересеклись в исходниках: останови их, установи одного
-  владельца и продолжи от проверенного состояния, не откатывая чужие правки.
+  владельца и продолжи от проверенного состояния без отката чужих правок.
- Находки не становятся слабее по раундам: если аргументы исчерпаны, вынеси
+- Процесс не сходится: используй точки вмешательства из договора ревью,
-  пользователю противоречие, риск или неверную границу задачи.
+  объясни партнёру причину, стоимость и принятое решение.
 - После завершения сохрани только предусмотренные проектом долговечные
  решения и удали временные артефакты именно этого прогона.
@@ -10,7 +10,7 @@ Codex и проверит полный конвейер на боевой зад
 - процесс тонкого мастера — [`../SKILL.md`](../SKILL.md);
 - выбор ролей и уровней — [`../references/roles.md`](../references/roles.md);
 - перенесённые уроки и открытые проверки —
-  [`../references/field-notes.md`](../references/field-notes.md);
+  [`../references/lessons.md`](../references/lessons.md);
 - точные договоры нативных агентов —
  [`../references/prompt-templates.md`](../references/prompt-templates.md);
 - явный вызов скилла — [`../agents/openai.yaml`](../agents/openai.yaml).
@@ -13,7 +13,7 @@
 [`../references/roles.md`](../references/roles.md).
 Факты двух прогонов и ещё непроверенные предположения дистиллированы в
-[`../references/field-notes.md`](../references/field-notes.md). Не переносить
+[`../references/lessons.md`](../references/lessons.md). Не переносить
 их обратно в основной файл без нового наблюдаемого сбоя.
 Ключевая граница следующей работы: субагент запускается ради конкретной пользы
@@ -39,7 +39,7 @@
   сверить её с фактическим вкладом.
 3. Измерить только мастерский след: какие полные отчёты или diff всё ещё попали
   в его контекст, сколько агентов можно было не запускать.
-4. Проверить живые предположения из `references/field-notes.md`: управляемость
+4. Проверить живые предположения из `references/lessons.md`: управляемость
   ролей и стоимости, `workspace-write`-ревью, сеть и файловый канал.
 5. Менять скилл только по фактам прогона; дистиллировать поглощённые уроки.
@@ -1,39 +0,0 @@
 # Полевые заметки
 Читай при развитии скилла и первом прогоне в новой среде. Храни здесь только
 факты, которые меняют выбор приёма, и живые предположения. Поглощённый урок
 сжимай до одной строки с указателем на действующий договор.
 ## Наблюдения
 - 2026-07-10 — хост скрыл выбор роли и модели; стоимость осталась
  незакреплённой. Исследователь нашёл блокирующий `.gitignore`, но без нужды
  запустил полный набор тестов. Вывод поглощён в
  [основную оптику](../SKILL.md) и [мандаты](roles.md).
 - 2026-07-10 — главной утечкой контекста была повторная передача отчётов и
  промптов через мастера. Вывод поглощён в [правила обмена](../SKILL.md) и
  [сборку промптов](prompt-templates.md).
 - 2026-07-12 — разные семейства ревьюеров пересеклись в двух темах примерно из
  восьми и сохранили заметный независимый вклад. Вывод поглощён в
  [основную оптику](../SKILL.md).
 - 2026-07-12 — самоприменение поймало сломанную сборку с необязательным
  `notes.md` и показало, что язык обмена надо задавать явно. Вывод поглощён в
  [сборку промптов](prompt-templates.md).
 - 2026-07-12 — тот же прогон выявил регрессии производного скилла: второй
  ревьюер того же семейства не давал новой родословной; мастер вывел в свой
  контекст 44 хэша, полный отчёт и почти весь diff; права ревьюера смешались с
  каналом результата; семь буквальных этапов породили лишние проверки. Вывод
  поглощён в [основную оптику](../SKILL.md).
 ## Проверить боем
 1. Выбирает ли текущий хост пользовательского агента по имени и показывает ли
   фактически использованную модель после новой сессии с TOML.
 2. Даёт ли дешёвая роль экономию без повторной работы сильной модели.
 3. Остаётся ли дерево неизменным после ревьюера с `workspace-write` и явным
   мандатом не менять исходники.
 4. Доступны ли ревьюеру поиск и документация при текущих сетевых разрешениях.
 5. Достаточно ли файлового канала, чтобы мастер не открывал полный отчёт и
   сырые журналы.
 6. Когда отдельный проверяющий или вторая линия ревью окупаются лучше
   объединения совместимой работы.
@@ -0,0 +1,47 @@
 # Эмпирика прогонов
 Храни здесь только датированные факты, которые меняют выбор приёма, и живые
 гипотезы. Поглощённый урок сжимай до строки с указателем на действующий
 договор. Правь этот долговечный файл только после согласования с партнёром.
 ## Наблюдения
 - 2026-07-10 — хост скрыл выбор роли и модели; стоимость осталась
  незакреплённой. Исследователь нашёл блокирующий `.gitignore`, но без нужды
  запустил полный набор тестов. Вывод поглощён в
  [основную оптику](../SKILL.md) и [роли](roles.md).
 - 2026-07-10 — главной утечкой контекста была повторная передача отчётов и
  промптов через координатора. Вывод поглощён в
  [правила обмена](../SKILL.md) и [сборку промптов](prompt-templates.md).
 - 2026-07-12 — разные семейства ревьюеров пересеклись в двух темах примерно из
  восьми и сохранили заметный независимый вклад. Вывод поглощён в
  [договор ревью](review-and-triage.md).
 - 2026-07-12 — самоприменение поймало сломанную сборку с необязательным
  `notes.md` и показало, что язык обмена надо задавать явно. Вывод поглощён в
  [сборку промптов](prompt-templates.md).
 - 2026-07-12 — второй ревьюер того же семейства не дал новой родословной;
  координатор вывел в свой контекст 44 хэша, полный отчёт и почти весь diff;
  права ревьюера смешались с каналом результата; семь буквальных этапов
  породили лишние проверки. Вывод поглощён в
  [основную оптику](../SKILL.md) и [договор ревью](review-and-triage.md).
 ## Проверить боем
 1. Удерживает ли Sol оптику тонкого мастера: что больше всего расходует
   контекст координатора и можно ли направить это через файл или субагента.
 2. Достаточна ли Luna `medium` для простой ограниченной реализации и
   подтверждается ли, что `low` даёт слишком много повторной работы.
 3. Окупается ли Terra `medium` на узком обзоре постановки и проверке
   реализации по задаче.
 4. Сходится ли обычная реализация на Sol `medium`, а сложная — на Sol
   `high`, с меньшей общей стоимостью петли.
 5. Оправдан ли ручной `xhigh` хоть в одном классе задач; текущая гипотеза —
   штатно переходить от `high` сразу к `max` только по сильному триггеру.
 6. Остаётся ли дерево неизменным после ревьюера с `workspace-write` и явным
   мандатом сохранять результат только в назначенный отчёт.
 7. Доступны ли ревьюеру поиск и документация при текущих сетевых разрешениях.
 8. Достаточно ли файлового канала, чтобы координатор не открывал полный
   отчёт, diff и сырые журналы.
 9. Может ли будущая линия другого семейства читать и писать общий
   `$SCRATCH`. Пока адаптер запуска не проверен, он не является действующим
   договором.
@@ -1,88 +1,134 @@
 # Сборка нативных промптов
-Открывай только раздел выбранного приёма. Это справочник готовых договоров,
+Это механика после выбора приёма в [основной оптике](../SKILL.md). Смысл
-а не обязательная последовательность. Постоянный текст живёт в
+ревью и триажа задаёт [единый договор](review-and-triage.md); здесь только
-[prompts/](prompts/):
+параметры, файловые пути и сборка.
 Постоянный текст живёт в [prompts/](prompts/):
 - [result-contract.md](prompts/result-contract.md) — обычный результат;
- [review-boilerplate.md](prompts/review-boilerplate.md) — слепое ревью;
+- [review-boilerplate.md](prompts/review-boilerplate.md) — независимое ревью;
 - [triage-header.md](prompts/triage-header.md) — закрытие находок;
 - [recheck-header.md](prompts/recheck-header.md) — узкая перепроверка;
 - [runtime-language.md](prompts/runtime-language.md) — язык временного обмена.
-Текст договора меняй только в его авторитетном файле. Здесь остаются выбор и
+Меняй договор только в его авторитетном файле. В параметрических файлах держи
-механика сборки.
+только факты конкретной задачи.
-## Канал результата
+## Каталог прогона
-Канал выбери по [основной оптике](../SKILL.md). Здесь важна только механика:
+`$SCRATCH` определён в основном файле как общий временный каталог. Для задачи
-для файлового канала задай уникальный `REPORT`, для сообщения не создавай
+создай уникальную подпапку: `D="$SCRATCH/<NN-slug>"`. `P` указывает на
-вторую копию результата.
+`references/prompts` этого скилла. Каждый агент получает отдельный `REPORT`.
-## Обычный исполнитель или исследователь
+Собирай файлы механически, не читая полезную нагрузку в контекст координатора.
 Примеры ниже используют POSIX `cat`; в PowerShell применяй
 `Get-Content <paths> | Set-Content -Encoding utf8 <target>`.
-Параметрический файл содержит только нужные конкретной задаче поля:
+## Исполнитель или исследователь
 `params.md`:
 ```text
 GOAL: one verifiable goal
 BOUNDARIES: allowed and forbidden work
 READ FIRST: paths to contracts and examples
 CHECKS: commands this agent should run
-REPORT: path, only when the result will be reused
+REPORT: absolute unique path
 ```
 Добавь общий результат и язык временного обмена:
 ```bash
 cat "$D/params.md" "$P/result-contract.md" "$P/runtime-language.md" \
    > "$D/prompt.md"
 ```
-Самодостаточный файл задачи, критерии и подробное обязательное чтение добавляй
+Самодостаточную постановку и подробное обязательное чтение добавляй только
-только когда они действительно нужны выбранной работе.
+когда они нужны выбранной работе.
-## Свежий ревьюер
+## Ревью постановки или реализации
-Общая часть содержит задачу, изменённый объём и известные проверки. Фокус
+`review-common.md` одинаков для одного обзора:
-содержит только выбранный для этого ревью класс риска. Для одного ревьюера:
+
 ```text
 TITLE: short review title
 WORKING DIRECTORY: absolute repo path
 STATEMENT: task and parent spec paths
 SCOPE: changed files or task sections under review
 BASELINE: what is explicitly outside this review
 CHECKS: commands and expected counters
 ```
 `review-output.md` задаёт поля конкретной линии:
 ```text
 TYPE: spec | task | code
 FINDING PREFIX: SPEC-A | SPEC-B | TASK | CODE
 REPORT: absolute unique path
 ```
 `review-focus.md` задаёт один выбранный фокус. Для постановки:
 ```text
 Review the task statement, not an implementation. Check facts against code,
 hidden one-line decisions, boundaries, checkable acceptance criteria, and
 ways to satisfy the wording without the intended result.
 ```
 Для реализации выбери task lens или code lens из договора ревью:
 ```text
 TASK LENS: compare the implementation with the statement, acceptance criteria,
 boundaries, and intended observable result.
 CODE LENS: seek correctness bugs, broken invariants, regressions, security
 issues, and tests that can pass without proving the behavior.
 ```
 ```bash
-cat "$D/review-common.md" "$D/review-focus.md" \
+cat "$D/review-common.md" "$D/review-focus.md" "$D/review-output.md" \
    "$P/review-boilerplate.md" "$P/runtime-language.md" \
    > "$D/review-prompt.md"
 ```
-Если осознанно выбраны несколько линий, каждому ревьюеру дай отдельный файл
+Для двух слепых линий создай `review-focus-a.md` и `review-focus-b.md`,
-фокуса и отдельный путь результата. Не создавай вторую линию только ради
+`review-output-a.md` и `review-output-b.md` со своими `TYPE`, уникальными
-симметрии или свежего треда того же семейства.
+`FINDING PREFIX` и разными путями `REPORT`. `review-common.md` используй один;
 отчёты и финальные сообщения линий не объединяй до их завершения.
-## Закрытие находок
+## Триаж постановки
-Передай исполнителю исходные индексы без пересказа. Обязательный
+Координатор читает краткие строки и нужные подробности, принимает решение по
-`triage-params.md` задаёт путь полного отчёта и нужные проверки. `notes.md`
+каждому `SPEC-*` и обновляет постановку. Резолюции сохраняет в
-добавляй только для новых решений мастера, которых у исполнителя ещё нет:
+`spec-resolutions.md`; этот файл и новая постановка идут исходному ревьюеру
 на узкую перепроверку.
 ## Триаж реализации
 Передай исполнителю исходные отчёты без пересказа. `triage-params.md`
 содержит путь итогового отчёта и проверки. `coordinator-notes.md` добавляй
 только для совпадений, противоречий и новых решений уровня задачи.
 ```bash
-cat "$P/triage-header.md" "$D/triage-params.md" "$D/review-a.md" \
+cat "$P/triage-header.md" "$D/triage-params.md" \
-    > "$D/fix-prompt.md"
+    "$D/review-a.md" > "$D/fix-prompt.md"
 if [ -f "$D/review-b.md" ]; then
  cat "$D/review-b.md" >> "$D/fix-prompt.md"
 fi
-if [ -f "$D/notes.md" ]; then
+if [ -f "$D/coordinator-notes.md" ]; then
-  cat "$D/notes.md" >> "$D/fix-prompt.md"
+  cat "$D/coordinator-notes.md" >> "$D/fix-prompt.md"
 fi
 cat "$P/runtime-language.md" >> "$D/fix-prompt.md"
 ```
 ## Узкая перепроверка
-Используй прежний тред ревьюера. Параметры содержат пути к его исходному
+Продолжай исходный тред ревьюера. `recheck-params.md` задаёт пути к его
-индексу и отчёту решений, а также проверку, если она нужна:
+исходному отчёту и файлу резолюций, нужную проверку и новый уникальный
 `REPORT`.
 ```bash
 cat "$P/recheck-header.md" "$D/recheck-params.md" \
    "$P/runtime-language.md" > "$D/recheck-prompt.md"
 ```
-Не запускай перепроверку автоматически: она нужна для принятых исправлений,
+Перепроверка следует решению координатора по договору ревью, а не номеру этапа.
 спорного отклонения или дорогой ошибки, а не для закрытия ритуального этапа.
@@ -1,14 +1,17 @@
 # Narrow re-check
-Re-check only your original findings and the changes immediately adjacent to
+Read your original report and the resolution report supplied by the caller.
 Re-check only your original findings and changes immediately adjacent to
 their resolution. Do not perform a full review.
-For every original finding report `CLOSED`, `NOT_CLOSED`, `REJECTION_VALID`,
+For every original ID report `CLOSED`, `NOT_CLOSED`, `REJECTION_VALID`,
-or `REJECTION_INVALID`, with concise evidence. If this narrow work exposes a
+or `REJECTION_INVALID`, with concise evidence. Report a newly exposed
-new adjacent defect, report it in the normal findings format; the scope bound
+adjacent defect with a new stable ID; the narrow scope limits exploration, not
-limits exploration, not honest reporting.
+honest reporting.
-Return the full re-check through the channel named by the caller. For a file
+Write the detailed re-check to REPORT. Return only:
-channel, write it to the supplied path and return only
+
-`RECHECK: ALL_CLOSED | ISSUES_REMAIN`, counters, and `REPORT: <absolute path>`.
+- `VERDICT: APPROVED | CHANGES_REQUESTED`;
-For a message channel, return the concise finding statuses once.
+- status counters;
 - one line per original or new ID: `ID | status | one-phrase essence`;
 - `REPORT: <absolute path>`.
@@ -4,7 +4,7 @@ Write the full result through the channel chosen by the caller:
 - `STATUS: complete | questions | blocked`
 - `EVIDENCE:` changed files, executed commands, and final counters
- `DECISIONS:` only questions for the orchestrator or user
+- `DECISIONS:` only questions for the coordinator or partner
 - `FINDINGS:` severity, location, essence, and verification method
 - `NEXT:` one concrete action or `none`
@@ -1,21 +1,30 @@
 ## Mandate
- Review and test hypotheses; do not edit source files or persistent
+- Review independently and test hypotheses. Do not edit source files,
-  environment state.
+  persistent environment state, or Git.
 - Use the working permissions needed for checks, caches, temporary artifacts,
-  documentation and primary-source research. The caller verifies Git before
+  documentation, and primary-source research.
-  and after the review.
+- Write the detailed report only to REPORT. This assigned exchange file is the
- Do not run `git add`, `git commit`, or commands that discard changes.
+  sole write exception to the observer mandate.
- Report only the findings index and verdict through the channel named by the
+- Treat another agent's claims as untrusted until evidence supports them.
  caller.
-## Findings index
+## Detailed report
-For each finding:
+Use stable IDs with FINDING PREFIX:
-`SEVERITY(BLOCKER|MAJOR|MINOR|NIT) | file:line or task section | failure scenario | evidence | how to verify`
+`PREFIX-N | BLOCKER|MAJOR|MINOR|NIT | file:line or task section | violated
 criterion | failure scenario | evidence | minimal verification`
-If there are no findings, list the reviewed scope and every executed check or
+If there are no findings, record the reviewed scope and every executed check
-tested hypothesis with its outcome. A bare no-findings assertion is invalid.
+or tested hypothesis with its outcome. A bare approval is invalid.
-Final line: `VERDICT: APPROVED | APPROVED_WITH_MINORS | CHANGES_REQUIRED`
+## Final message
 Return only:
 - `VERDICT: APPROVED | CHANGES_REQUESTED`
 - severity counters;
 - one line per finding: `ID | severity | area | one-phrase essence`;
 - `REPORT: <absolute path>`.
 Do not repeat the detailed report or reasoning narrative in the final message.
@@ -1,15 +1,17 @@
-# Triage blind-review findings
+# Triage independent-review findings
-The review indexes below are immutable input. Process every finding and change
+The review reports below are immutable input. Process every stable finding ID
-nothing outside their scope. For each finding, either:
+and change nothing outside their scope. Assign exactly one disposition:
- fix it and name the contract or check that proves closure; or
+- `FIXED`: change it and name the contract or check that proves closure;
- reject it with evidence from the contract and a check, never a bare claim.
+- `REJECTED`: cite the contract and a check, never a bare claim;
 - `OUT_OF_SCOPE`: explain the boundary decision needed;
 - `NEEDS_DECISION`: state the unresolved product, architecture, or risk choice.
-Do not commit or stage changes. Propose accepted rejections and residual risks
+Do not commit, stage, or rewrite the source reports. Write detailed resolutions
-for the orchestrator to own and record as durable task decisions. The
+to REPORT. Return only:
 orchestrator cannot silently accept risk; authority must come from the user or
 already be explicit in the task.
-Write a full resolution report to the path supplied by the caller. Return only
+- overall status and disposition counters;
-status, counters, executed checks, and that path in the final message.
+- one line per finding: `ID | disposition | one-phrase essence`;
 - questions for the coordinator and executed-check counters;
 - `REPORT: <absolute path>`.
@@ -0,0 +1,144 @@
 # Ревью и триаж
 Читай этот файл целиком после выбора независимого ревью постановки или
 реализации. Режим и стоимость выбираются в [основной оптике](../SKILL.md);
 здесь один авторитетный договор выполнения.
 - [Независимость и фокус](#независимость-и-фокус)
 - [Файловый маршрут](#файловый-маршрут)
 - [Отчёт ревьюера](#отчёт-ревьюера)
 - [Владелец триажа](#владелец-триажа)
 - [Перепроверка и круги](#перепроверка-и-круги)
 - [Что читает координатор](#что-читает-координатор)
 ## Независимость и фокус
 Запускай ревьюера свежей сессией без истории исполнителя и других ревьюеров.
 Повторную проверку точечных исправлений продолжает тот же ревьюер: его контекст
 находок полезен и не отменяет независимость исходного обзора.
 Для двойного ревью разделяй фокусы:
 - **по задаче** — соответствие постановке, критериям, границам и ожидаемому
  результату;
 - **по коду** — корректность, межмодульные инварианты, регрессии, безопасность
  и честность тестов.
 Давай обоим общую постановку и изменённый объём, но отдельный файл фокуса и
 отдельный путь отчёта. Они не знают о второй линии до завершения исходных
 обзоров. Разные семейства моделей предпочтительны; две доступные линии одного
 семейства всё равно полезны на сложной задаче, если их фокусы различаются.
 Ревьюер — наблюдатель с нужными инструментами. Он может читать код, запускать
 тесты, проверять гипотезы, создавать временные кэши и писать назначенный файл
 отчёта. Исходники, постоянное окружение и Git он не меняет. Координатор
 сверяет состояние дерева до и после.
 ## Файловый маршрут
 Назначь каждому участнику уникальные файлы в каталоге задачи внутри
 `$SCRATCH`. Временные промпты и отчёты веди на английском.
 ```text
 reviewer -> detailed report file -> triage owner
             |
             +-> short summary -> coordinator
 ```
 Ревьюер сам пишет полный отчёт в назначенный файл. Координатор не принимает
 полный отчёт сообщением и не переписывает его перед передачей. Владелец
 триажа читает исходные отчёты напрямую и пишет подробные резолюции в следующий
 файл.
 Если общий каталог недоступен, верни через контекст компактный индекс без
 нарратива. Координатор сразу сообщает партнёру, какой агент не получил доступ,
 к какому пути, какой запасной канал использован и что нужно проверить после
 задачи. Сбой канала ухудшает экономию контекста, но не отменяет ревью.
 ## Отчёт ревьюера
 Каждая находка получает устойчивый идентификатор с уникальным префиксом
 линии: `SPEC-A-N` и `SPEC-B-N` для постановки, `TASK-N` для соответствия
 реализации задаче и `CODE-N` для качества кода. Полный файл содержит:
 - идентификатор, тяжесть и `файл:строка` либо раздел постановки;
 - нарушенный критерий;
 - сценарий сбоя и доказательство;
 - минимальный способ проверки.
 В сообщение координатору верни только:
 - `VERDICT: APPROVED | CHANGES_REQUESTED`;
 - счётчики по тяжести;
 - по одной строке на находку: идентификатор, область, суть и тяжесть;
 - абсолютный путь к полному отчёту.
 При отсутствии находок полный файл перечисляет просмотренный объём и
 выполненные проверки. Голая строка `APPROVED` без подтверждения работы не
 засчитывается.
 ## Владелец триажа
 **Постановка.** Координатор принимает или отклоняет каждую находку, потому что
 цель, границы и критерии — его решения. Открытое техническое исследование он
 может отдать deep-reasoner, но сам читает верхнеуровневые документы и итоговую
 постановку. Продуктовый выбор и принятие риска выносит партнёру.
 **Реализация.** Пофиндинговый триаж делает исполнитель, у которого есть
 контекст кода. Координатор передаёт оба исходных отчёта без изменений и
 добавляет отдельную короткую шапку: совпадения, противоречия и возможный выход
 за границы. Он не сливает и не удаляет «дубликаты».
 Для каждого идентификатора исполнитель возвращает один статус:
 - `FIXED` — исправлено и названо доказательство;
 - `REJECTED` — отклонено через контракт и проверку;
 - `OUT_OF_SCOPE` — требует отдельного решения о границах;
 - `NEEDS_DECISION` — технического решения недостаточно.
 Подробности остаются в файле триажа. Координатор получает по одной компактной
 строке `ID | status | essence` на находку, счётчики, вопросы уровня задачи и
 путь. Риск и выход за границы решает координатор; техническую истинность
 находки — исполнитель и ревьюер.
 ## Перепроверка и круги
 Один круг — назначенные обзоры, триаж его владельца и узкая перепроверка.
 Исходный ревьюер читает свой отчёт и файл резолюций, проверяет только свои
 находки и соседние изменения. Выбранное независимое ревью закрывается
 `APPROVED` либо явным принятием риска полномочным координатором или партнёром.
 Координатор получает по одной компактной строке со статусом каждого исходного
 или нового идентификатора; подробности остаются в файле перепроверки.
 Повторно поднятое аргументированно отклонённое замечание пометь как спор и
 отправь на отдельную узкую проверку усиленного уровня. Полный новый обзор
 нужен, когда реализация широко изменилась, исходный отчёт слаб или требуется
 новая независимая линия.
 Третий круг — точка вмешательства: сообщи партнёру, почему процесс не сходится,
 какова стоимость и что меняешь. Координатор может уточнить постановку,
 повысить модель или effort, заменить исполнителя свежим сильным агентом,
 разделить задачу, назначить усиленный гейт либо принять риск в пределах
 мандата.
 Пятый круг не начинай автоматически. Сначала прими явное решение и объясни его
 партнёру; если полномочий недостаточно, остановись и запроси решение. Это
 предохранитель от дорогой вложенной петли, а не запрет координатору управлять
 работой.
 ## Что читает координатор
 Краткие строки находок нужны координатору для сравнения линий. Подробный файл
 открывай, когда находка меняет границы или риск, ревьюеры противоречат друг
 другу, возник спор, сводка непонятна либо без деталей нельзя выбрать следующий
 шаг.
 Для обычной починки координатор видит переход:
 ```text
 CHANGES_REQUESTED -> triaged -> rechecked -> APPROVED
 ```
 Полный diff, доказательства и журналы читают назначенные агенты. Координатор
 углубляется в них по правилам приёмки основной оптики, когда это нужно для его
 собственного решения.
@@ -1,5 +1,8 @@
 # Уровни и роли
 Маршрутизация моделей обновлена 2026-07-13. Имена и уровни здесь — датированная
 настройка среды; логика [основной оптики](../SKILL.md) остаётся относительной.
 Читай этот файл только при настройке ролей или когда нужная роль недоступна.
 [Основная оптика](../SKILL.md) описывает, когда отдельный агент вообще нужен.
 Этот файл — условные настройки мандата, а не список обязательных участников.
@@ -7,6 +10,7 @@
 - [Возможности хоста](#возможности-хоста)
 - [Выбор уровня](#выбор-уровня)
 - [Текущая маршрутизация](#текущая-маршрутизация)
 - [Роли](#роли)
 - [Файл пользовательского агента](#файл-пользовательского-агента)
 - [Пределы параллельности](#пределы-параллельности)
@@ -23,7 +27,7 @@
  `reasoning_effort` без пользовательской роли с закреплённой моделью.
  Плейбук использует `fork_turns="none"` ради чистого контекста. Технически
  ограниченный fork числом тоже допускает переопределения; только полный
-  fork `all` наследует модель мастера и отклоняет их.
+  fork `all` наследует модель координатора и отклоняет их.
 - **Неуправляемая стоимость.** Интерфейс запуска принимает только задачу и
  имя треда. Передавай роль мандатом в промпте, но не утверждай, что выбрана
  дешёвая или сильная модель. `task_name` — идентификатор треда, а не выбор
@@ -69,25 +73,40 @@
 | Уровень | Для чего | Настройка |
 |---|---|---|
-| Быстрый | Поиск, чтение журналов, тесты, пакетная механика | Быстрая дешёвая модель, `low` или `medium` |
+| Быстрый | Поиск, журналы, известные проверки, ограниченная механика | Дешёвая подходящая модель, обычно `medium` |
-| Рабочий | Обычная реализация по ясной постановке | Сильная модель для кода, `medium` или `high` |
+| Рабочий | Обычная реализация и проверка по задаче | Подходящая ролевая модель, `medium` |
-| Глубокий | Архитектура, сложная диагностика, ревью высокого риска | Самая сильная доступная модель, `high` или выше |
+| Глубокий | Архитектура, сложная реализация, ревью кода | Сильная модель, `high` |
 | Исключительный | Необратимое решение или несходимость сильных агентов | Самая сильная модель, `max` |
-Начинай с самого дешёвого подходящего уровня. Повышай уровень, когда агент
+Модель задаёт потолок способности, effort — глубину работы этой модели.
-не может проверить предположение, дважды возвращает слабый результат или
+Повышай effort, когда подходящей модели не хватило поиска или рассуждения.
-задача требует решения с высокой ценой ошибки. Не повышай уровень ради
+Повышай модель, когда не хватает качества решения. После двух слабых
-объёма механической работы: дели её на независимые части.
+результатов замени исполнителя свежим более сильным агентом вместо переноса
 его неудачного контекста.
- `low`/`medium`: детерминированная механика, поиск и известные проверки.
+`xhigh` не является автоматической ступенью: текущая эмпирика показывает
- `medium`/`high`: реализация по ясному контракту, несколько связанных
+малый прирост относительно `high` при заметной цене. Выбирай его вручную для
-  файлов, нет необратимых решений.
+узкой задачи. `max` заметно сильнее и дороже; используй по явному триггеру и
- `high`: публичный контракт, безопасность, целостность данных, конкуренция,
+объясняй партнёру причину.
  миграция или неоднозначная архитектура.
 - `xhigh` и выше: необратимый дорогой выбор либо повторное противоречие
  сильных агентов. Это исключение, а не обычный режим ревью.
-Конкретные названия моделей держи в конфигурации агентов, а не в `SKILL.md`.
+## Текущая маршрутизация
-Так замена модельной линейки не меняет процесс.
+
 Это начальная рабочая таблица, а не рейтинг моделей. Проверяй её на прогонах и
 меняй после согласования эмпирики с партнёром.
 | Роль | Модель и effort |
 |---|---|
 | Простая ограниченная реализация, `fast-worker`, известная проверка | Luna `medium` |
 | Узкий обзор постановки, проверка реализации по задаче | Terra `medium` |
 | Обычная нетривиальная реализация | Sol `medium` |
 | Сложная или рискованная реализация | Sol `high` |
 | `deep-reasoner`: архитектурное предложение, декомпозиция, компромиссы | Sol `high` |
 | Ревью кода | Sol `high` |
 | Необратимое решение, спор сильных агентов, повторная несходимость | Sol `max` |
 Официальное назначение текущих уровней семейства — в
 [каталоге моделей OpenAI](https://developers.openai.com/api/docs/models).
 Конкретные имена держи здесь и в конфигурации агентов, а не в `SKILL.md`.
 ## Возможные мандаты
@@ -104,7 +123,7 @@
 Уровень: быстрый. Строит карту кода, находит точки входа, контракты и команды
 проверки. Не запускает полный набор тестов и не проектирует решение, пока
-мастер прямо не попросит. Узкую команду запускает только для проверки факта,
+координатор прямо не попросит. Узкую команду запускает только для проверки факта,
 без которого карта ненадёжна.
 Обычно: `sandbox_mode = "read-only"`.
@@ -120,8 +139,8 @@
 ### `deep-reasoner`
 Уровень: глубокий. Принимает одно сложное решение: архитектура, алгоритм,
-диагноз, противоречие требований. Возвращает рекомендацию, ключевые доводы и
+диагноз, противоречие требований. Возвращает предложение, ключевые доводы и
-непроверенные предположения.
+непроверенные предположения; итоговое решение принимает координатор.
 Обычно: `sandbox_mode = "read-only"`.
@@ -136,7 +155,9 @@
 правок. Исходники и постоянное окружение защищает явный мандат, Git сверяется
 до и после. Доступ к сети проверять отдельно: право записи не гарантирует
 поиск и документацию. Непроверенную внешнюю механику отмечать как гипотезу.
-Канал результата от песочницы не зависит.
+Канал результата от песочницы не зависит. При выбранном ревью используй
 [единый договор](review-and-triage.md): назначенный файл отчёта — единственный
 результат наблюдателя; временные кэши допустимы, исходники и Git неизменны.
 ### `verifier`
@@ -169,7 +190,7 @@ developer_instructions = """
 ## Пределы параллельности
 - Держи глубину `1`: субагенты не создают собственное дерево исполнителей.
- Оставляй один слот мастеру.
+- Оставляй один слот координатору.
 - Параллельно запускай только работу без конфликтующих входов, команд и
  изменяемого состояния. Второй слепой обзор добавляй ради отдельной линии, а
  не ради заполнения свободного слота.