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

- Зачем:
  - нужно сохранить контекст координатора и устранить расхождения с зеркальным playbook.
- Что:
  - закреплены делегирование, маршрутизация моделей и ограничение кругов ревью.
  - добавлены файловый договор ревью и согласованная эмпирика прогонов.
  - исправлены сборка слепых линий и компактные статусы находок.
- Проверка:
  - quick_validate.py, git diff --check и проверка локальных Markdown-ссылок.

agents/.agents/skills/codex-subagent-playbook/SKILL.md

@@ -1,132 +1,132 @@
 ---
 name: codex-subagent-playbook
-description: Оптика тонкого мастера для одной нетривиальной задачи: субагенты сохраняют контекст и приносят нужную независимость.
+description: "Оптика тонкого мастера для одной нетривиальной задачи: исследование, планирование, реализация и независимая проверка через субагентов без поглощения контекста координатора."
 ---
 
 # Тонкий мастер
 
-Это оптика работы, а не обязательный конвейер. Цель — решить одну
-нетривиальную задачу, сохранив внимание мастера для цели, ограничений,
-решений и рисков. Субагенты нужны результату, а не процессу.
-
-Тонкий мастер не пустой мастер. Он сам принимает решения, делает дешёвые
-точечные проверки и смотрит ключевые артефакты. Исследование, реализацию или
-проверку он отдаёт только тогда, когда отдельный контекст даст задаче
-конкретное преимущество.
+Это оптика, а не обязательный конвейер. Координатор сохраняет внимание для
+цели, ограничений, решений, рисков и приёмки. Субагенты выясняют и выполняют;
+координатор решает.
 
 ## Основная оптика
 
-- Перед каждым запуском ответь: что этот агент добавит — защиту контекста,
-  свежий взгляд, специализацию, параллельность или отдельную среду проверки?
-  Если ничего, работай сам или продолжи существующий тред.
-- Держи у мастера короткий индекс: цель, ограничения, принятые решения,
-  риски, вердикты и доказательства, влияющие на следующий шаг. Полные diff,
-  журналы и нарративы ему не нужны.
-- Исследование с неизвестным или шумным объёмом делегируй до погружения.
-  Одну узкую гипотезу с предсказуемо короткой командой мастер может проверить
-  сам; если ответа нет, продолжение уходит агенту.
-- Свежий тред даёт независимость от исполнителя, но не разнообразие ошибок.
-  Другое семейство моделей даёт отдельную линию; второй агент того же
-  семейства оправдан только высоким риском или действительно иным фокусом.
-- Выбирай самый дешёвый надёжный уровень для выбранной работы. Если хост не
-  показывает модель и глубину, считай стоимость незакреплённой и не умножай
-  совместимые роли без явной пользы.
+- Перед запуском агента назови его вклад: защита контекста, свежий взгляд,
+  специализация, параллельность или отдельная среда. Без вклада работай сам
+  либо продолжай существующий тред.
+- Сам читай верхнеуровневые документы и принимай решения. Исследование кода,
+  журналов, зависимостей и вариантов с неизвестным объёмом по умолчанию
+  отдавай субагенту. Самостоятельно проверяй одну узкую гипотезу с коротким
+  выводом; дальнейшее погружение делегируй.
+- Держи у себя цель, ограничения, решения, риски, краткие сводки и пути к
+  доказательствам. Полезную нагрузку передавай между агентами файлами, не
+  через контекст координатора.
 - Один исполнитель владеет изменениями исходников. Его же продолжай для
-  исправлений; независимую оценку отдавай свежему треду. Права
-  `workspace-write` сами по себе не делают агента владельцем исходников.
-
-Внешняя модель полезна как дополнительная линия, когда её родословная и цена
-оправданы риском. Процесс не должен от неё зависеть.
+  обычных исправлений. Если исполнитель не справляется, останови его и дай
+  свежему более сильному агенту постановку, текущее дерево и файловые отчёты.
+- Выбирай модель и уровень рассуждения независимо. Повышай effort, когда
+  подходящей модели не хватило глубины; повышай модель, когда не хватает
+  качества суждения. Текущая привязка ролей — в
+  [уровнях и ролях](references/roles.md).
 
 ## Контекст и обмен
 
-- Если результат понадобится следующему агенту, полный отчёт запиши в
-  уникальный файл временного обменного каталога. Мастеру верни только итог,
-  счётчики, вопросы-решения и путь. Короткий конечный результат можно вернуть
-  одним сообщением.
-- Канал результата не связан с правами агента. Ревьюеру можно дать рабочие
-  права для тестов, кэшей, поиска и документации, а запрет менять исходники и
-  постоянное окружение удерживать мандатом и сверкой Git до и после.
-- Не возвращай один полный отчёт одновременно файлом и сообщением. Не
-  переписывай находки между файлами: передавай исходный путь или собирай новый
-  промпт механической конкатенацией.
-- Не выводи в контекст мастера полную точку отсчёта, diff, перечень хэшей или
-  сырой журнал. Если дерево грязное или возможны пересечения, порученный
-  агент либо готовый скрипт сохраняет подробности во временный файл и сообщает
-  только состояние, счётчики, пересечение с разрешённым объёмом и путь.
+`$SCRATCH` — логический общий каталог одного прогона, доступный координатору и
+назначенным агентам. Физически это скретчпад сессии, временный каталог ОС либо
+гарантированно игнорируемый каталог проекта. В нём живут временные промпты,
+отчёты, триаж и перепроверки; это не артефакты проекта.
+
 - Временные обменные файлы веди на английском. Долговечные документы и текст
-  для пользователя пиши на языке проекта.
-- Сообщай пользователю короткий статус на действительно значимых границах, а
-  не на каждом служебном переходе. Тайм-аут и `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) только предложи партнёру.
+Правь долговечную эмпирику после его согласия.
 
 ## Сбои координации
 
-- Агент завершился без ожидаемого файла: один раз запроси короткий итог в том
-  же треде; после повторной тишины продолжи свежим агентом от сохранённых
-  артефактов.
-- Агент вернул длинный рассказ в сообщение: попроси повторить ответ индексом и
-  путём, не переноси рассказ дальше.
+- Нет ожидаемого файла: один раз запроси короткий итог в том же треде; после
+  повторной тишины продолжи свежим агентом от сохранённых артефактов.
+- Длинный рассказ пришёл сообщением: попроси повторить ответ сводкой и путём,
+  не переноси рассказ дальше.
 - Два исполнителя пересеклись в исходниках: останови их, установи одного
-  владельца и продолжи от проверенного состояния, не откатывая чужие правки.
-- Находки не становятся слабее по раундам: если аргументы исчерпаны, вынеси
-  пользователю противоречие, риск или неверную границу задачи.
+  владельца и продолжи от проверенного состояния без отката чужих правок.
+- Процесс не сходится: используй точки вмешательства из договора ревью,
+  объясни партнёру причину, стоимость и принятое решение.
 - После завершения сохрани только предусмотренные проектом долговечные
   решения и удали временные артефакты именно этого прогона.