# Роутер + дисциплина: якорь на план — заметки по дизайну (в процессе обсуждения)

**Дата:** 2026-06-01
**Статус:** ОБСУЖДЕНИЕ. Ничего из «целевого» не реализовано. Это фиксация договорённостей, не спека к выкату.
**Владелец рассуждения:** Дмитрий. **Записал:** Claude (worktree `brainrepo`).

---

## Контекст

Разбираем, как устроена «умная» цепочка вокруг маршрутизации задач и как её ужесточить, не сломав. Четыре роли:

| Роль | Кто | Когда | Что делает |
|---|---|---|---|
| Классификатор / роутер | Sonnet | онлайн, на каждое сообщение пользователя | советует тип задачи + скил/цепочку |
| Судья (LLM-judge) | Sonnet | онлайн, на каждое действие | пускает / блокирует живьём |
| Самооценка (`self_assessment`) | контроллер сам | онлайн, в конце хода | сам ставит себе оценку |
| Оценщик (reviewer) | Opus | офлайн, по `/brain-retro` | оценивает задним числом качество решений + честность самооценки |

«Классификатор» и «роутер» — **одно и то же** (модуль `tools/router-classifier.mjs`).

---

## Ключевая проблема (диагноз)

Классификатор **слеп к контексту**: видит только текст текущего сообщения (+ крошечная пометка «продолжение/отмена»), нашего разговора не помнит. На богатом описании задачи он полезен; на короткой реплике («делай», «дальше») — почти пустышка. Сейчас память о ходе работы держит **контроллер (Claude)**, а не классификатор.

Отсюда вывод-инвариант:

> **Нельзя затягивать дисциплину (заставлять слушаться классификатор), пока он слеп. Иначе заставим исполнять заведомо плохой совет — это провал.**
> Сначала — **дать классификатору контекст**, потом — строгое принуждение.

---

## Зафиксированные решения

- **D1. Порядок работ жёсткий:** (1) дать классификатору контекст → (2) затянуть дисциплину (судья проверяет послушание) → (3) калибровка. Обратный порядок запрещён.
- **D2. Источник контекста — план-файл (вариант Б).** Скил/цепочка для каждого шага **прописываются прямо в плане в момент планирования** (`writing-plans`), а роутер потом просто **указывает на текущий шаг**. НЕ классификатор раздаёт скилы по пунктам — **план их несёт, роутер по плану ведёт.**
- **D3. Видимость + причина (правило записи плана):** в плане у **каждого пункта** явно указан скил/цепочка — **чтобы владелец это видел.** Если у пункта скила нет — в плане пишем **причину** (почему скил не нужен / почему direct).
- **D4. Калибровка классификатора — только вручную.** Корректировки по итогам `/brain-retro` вносит **владелец сам.** Авто-петля reviewer→классификатор **НЕ строится.**
- **D5. До плана** роутер работает как сейчас (реагирует на промты). **После плана** — ведёт по шагам с уже назначенными скилами.

---

## Открытый вопрос (обсуждаем сейчас)

- **OQ1. Неполная декомпозиция.** План, написанный в ходе рассуждения, **точно обрастёт** под-пунктами в процессе работы. Досконально разложить всё до листьев заранее **нельзя**: это либо очень долго, либо владелец теряет контекст и план выходит «лажа». Значит, под-пункты снова окажутся без скилов → снова падение на слепой классификатор. **Как закрыть этот разрыв — предмет следующего рассуждения.**

---

## Сделано в коде этой сессии (отдельно от целевой схемы, уже GREEN)

- Лимит ответа классификатора `max_tokens` 1500 → 15000 (потолок, не цель; защита от незаметной обрезки длинных цепочек).
- Починен рассинхрон «промпт ↔ разборщик» по полю `task_type` (промпт теперь требует поле + даёт пример; разборщик принимает и snake_case, и camelCase). Это устраняло ~46% сбоев разбора (`parse_null`).
- Регрессия tools: 1996 passed / 0 failed. **Ещё не закоммичено** (ждёт решения владельца).

---

## Обновления (2026-06-01, продолжение обсуждения)

- **Уточнение формулировки (важно):** «роутер» и «классификатор» — **одно и то же** (`tools/router-classifier.mjs`). Не два механизма. У него будет **два режима**: (1) «гадаю по сообщению» — когда плана нет (это всё, что он умеет сегодня); (2) «читаю план» — когда план есть, перестаёт гадать по слову «делай» и смотрит «на каком мы шаге». Тот же механизм, новый фокус. Прежняя формулировка D2/D5 «не классификатор раздаёт — роутер ведёт» была **ошибочной** (противопоставляла одно и то же).

- **D6. Волновая декомпозиция.** План — живое дерево. Сверху — крупные этапы (5–8). Этап дробится на под-пункты **в момент подхода к нему**, свежим контекстом, через скил-планировщик (`writing-plans` повторно). Наследование специалиста от родителя — **только временная заглушка** для ещё не рассмотренных под-пунктов, **не финал**. Финального специалиста под-пункту назначают **при разборе этого этапа**, и он **может быть любым**, не как у родителя. Если нужного специалиста **нет в наборе** — пункт помечается причиной (D3) и **всплывает к владельцу** (добавить скил / сделать вручную). Молча с неправильным специалистом не уезжает.

- **D7. План — всегда видимый файл, конец скрытому планированию.** Планировщик = это Claude, выполняющий скил `writing-plans` (не отдельный автономный агент). Значит план обязан быть **видимым артефактом** с разметкой по D3, а не «в голове у Claude». Сегодня по факту планирование чаще невидимо (в рассуждении) или полу-видимо (TodoWrite — без специалистов/причин); полноценный видимый размеченный план как привычка **не существует**. D7 это закрывает.

- **OQ2 (ПЕРЕСМАТРИВАЕТ D2): кто проставляет специалиста на шаг — Claude или роутер?**
  Владелец (из опыта, не как решение): **скилы на шаги должен проставлять РОУТЕР, а не Claude.** Причина: поведение роутера **можно корректировать** (правишь его правила — изменение держится); на Claude **влиять трудно** (дрейфует, рационализирует, не «крутилка»). Если назначение специалистов зашито в план рукой Claude — это опять опаковая, некорректируемая зона. Поэтому: **план несёт ШАГИ (это делает Claude — декомпозиция/описание), а специалиста на каждый шаг назначает РОУТЕР** (по тексту шага), и владелец калибрует роутер. Это **отменяет D2** в части «Claude вписывает скилы в план». Статус: обсуждается, не финал.

- **D8. Специалиста на шаг назначает РОУТЕР, не Claude (отменяет D2).** Разделение власти: Claude пишет **шаги** (декомпозиция + понятное описание), роутер читает текст шага и назначает **специалиста**, владелец **калибрует роутер**. Остаточная зона Claude — **качество формулировки шага** (видимая, проверяемая в плане), а не скрытый выбор инструмента. Техническая импликация: роутер запускается **на текст каждого шага плана**, а не только на сообщение в чат.

- **OQ3. Тихая подмена специалиста внутри нерасписанного шага.** Самый острый разрыв. Сценарий: под-плана нет (Claude решил не писать — «и так понятно»), а внутри работы возникает под-задача, которой **родительский специалист не подходит** и его надо **заменить**. Раз под-плана нет — роутер на эту под-задачу скил не назначал; решение «сменить специалиста» Claude принимает **в голове, невидимо**. Это ровно «влиять на Claude трудно» на микро-уровне. Направления (не решено): (а) правило «выход за рамки текущего специалиста = запрет на тихий пропуск: обязан остановиться и показать → роутер назначает» — но опирается на честность Claude заметить; (б) проверка на КАЖДОЕ действие (роутер/судья: «это действие в рамках назначенного шагу специалиста?») — не зависит от честности Claude, но дорого (LLM на действие) и сам проверяющий неидеален; (в) разрешать пропуск под-плана ТОЛЬКО для работы внутри одного специалиста — потребность в другом специалисте по определению значит, что пропускать было нельзя. **Честный предел:** поймать тихую микро-подмену без (а) опоры на честность Claude или (б) платы за по-actionную проверку — нельзя. Где граница — за владельцем.

- **D9. Судью РАСШИРИТЬ, не заменить (выбор владельца по OQ3-б).** Факт: судья `tools/llm-judge-per-tool.mjs` УЖЕ на каждом мутирующем действии спрашивает Sonnet «consistent ли действие с задачей пользователя и рекомендованным скилом/цепочкой?» — YES → пропуск, NO/сомнение → блок. Но его «линейка» сегодня = рекомендация классификатора на **последнее сообщение в чат** (слепая, по-message). Расширение: судья **продолжает** проверять безопасность/consistency И **дополнительно** сверяет действие со **специалистом ТЕКУЩЕГО ШАГА плана** (назначенным роутером по D8). Так закрывается OQ3: действие чужим специалистом → NO → блок → переназначение/всплытие к владельцу. Включать **точечно** (дорогие/необратимые действия), т.к. наследует минусы судьи: расход на действие, риск over-block (был прецедент с readonly git), неидеальность самого проверяющего. Это не замена вопроса судьи, а обогащение его эталона.

- **D10. Судья — всеобъемлющий, НЕ точечный (выбор владельца, отменяет «точечно» из D9).** Судья проверяет **каждое** действие, включая чтения, а не только дорогие/необратимые. Принцип владельца: **«лучше потом ослабить, чем оставить дыры»** — начинаем максимально строго, послабления вводим осознанно позже. Честная цена (зафиксирована, принята): максимум расхода (LLM на каждое действие) + максимум риска ложных блокировок, особенно на чтениях. Это сознательный выбор «сначала закрыть всё».

- **D11. Plan-gated execution (целевая схема владельца — «без плана нет действия»).** Поток на ЛЮБОЙ промт, требующий действий: (1) Claude ничего не делает руками → (2) строит план через `writing-plans` → (3) отдаёт план роутеру, тот проставляет специалистов/цепочки на шаги (D8) → (4) готовый план уходит судье И владельцу → (5) Claude выполняет; на **каждое** действие (вплоть до «прочитать файл») судья смотрит: **есть ли это действие в плане + тем ли специалистом** → добро / блок. **Без плана — никакого действия.** Судья — сторож плана.

- **OQ4. Переход «промт-задача → план-задача» (bootstrap-парадокс, поднял владелец).** Острая проблема внутри D11: чтобы **построить** план, Claude обязан **действовать** (читать файлы, искать, изучать, написать сам файл плана) — но D11 говорит «без плана нет действия». Замкнутый круг. Также: сама запись файла плана — действие, которого в ещё-не-существующем плане нет. Направление решения (не финал): **режим планирования (Фаза A)** — пока плана нет, судья пропускает ТОЛЬКО планировочные действия (read-only разведка + вопросы владельцу + написание самого плана), любую **мутацию** блокирует; событие-граница: план написан → роутер разметил → план ушёл судье+владельцу → **Фаза B** (исполнение, судья сверяет каждое действие с планом). Плюс floor: чистый разговор/тривиальное (нет действий) плана не требует — «без плана нет действия» там выполняется само собой (раз действий нет). Остаётся определить: что именно входит в «планировочные действия» Фазы A; как не зациклить (read-only разведка тоже может быть каналом утечки — действующие read-protections сохраняются).

- **D12. Решение bootstrap (версия владельца — чище «Фазы A с белым списком»).** Нет отдельного «режима планирования со списком разрешённых действий». Есть **одно семя-исключение**: судья **всегда безусловно пропускает вызов скила `writing-plans`** (можно обсудить альтернативы). **Всё остальное — включая чтения — проходит через план.** Поток: промт → вызываю `writing-plans` (судья пропускает) → пишу план, где даже «хочу прочитать» с перечнем 5 файлов = пункты плана → сдаю роутеру (он видит «это чтение» → специалиста не ставит, чтение специалиста не требует) → план уходит судье и владельцу → исполняю, судья сверяет каждое действие с планом → следующая порция действий = **новый план** (волнами, ср. D6). Запись самого файла плана **покрыта** разрешением на `writing-plans` (снимает прежний регресс «запись плана — действие вне плана»). Это отменяет формулировку «Фаза A / белый список» из OQ4: правило одно + одно семя.

- **Q-GRAPH (отдельный вопрос, не забыть).** Разведку **всегда начинать с графа** (graphify, `/graphify query`) ДО чтения файлов (ср. CLAUDE.md §5 п.14). Встроить как **дефолтный первый пункт** любого плана-разведки. Зафиксировано отдельно по просьбе владельца.

- **OQ6. Честные издержки D12 (принять осознанно).** (1) Каждая порция действий, включая «дай прочитаю» — это круг «writing-plans → роутер → судья». Тяжело; смягчается **батчингом** (перечислить много чтений сразу) и **волнами**. (2) `writing-plans` как единственный вход — тяжёл для тривиального; альтернатива «лёгкий микро-план» добавляет ветку = потенциальную дыру (против принципа «без дыр»). Открытый выбор: один вход (просто масштабируется до плана в 1 строку) ИЛИ два формата. (3) Незапланированное чтение в Фазе B → блок → надо до-планировать (дёшево дополнить план, но это снова круг). Принято под «строго сейчас, ослабим потом».

- **D13. Подтверждено владельцем (три ответа).** (1) `writing-plans` — **чистый**: только пишет план, руками ничего не читает/не трогает; любое чтение становится пунктом плана и исполняется ПОСЛЕ одобрения. (2) Нормальный ритм — **два круга**: «план-разведка» (граф+чтения, специалист не нужен) → исполнение чтений → «план-дела» (шаги со специалистами) → исполнение. (3) **Два семени** всегда-разрешённого без плана: `writing-plans` + **вопрос владельцу** (AskUserQuestion, нулевой риск). *(Владелец ответил «да» на вопрос «одно или два» — трактую как ДВА; если имелось одно — поправить.)*

- **D14. Роутер при планировании — консультант ТОЛЬКО по маршрутизации, не по сути.** Может: подсказать специалиста на шаг, пометить пробел «специалиста нет», предложить готовую цепочку, **разбить криво сформулированный под цепочку шаг**. НЕ может: трогать **замысел/содержание** шагов, подменять Claude как автора. Граница строгая: **routing-форма, не суть.**

- **OQ7 (НАЙДЕННАЯ ДЫРА — escape через недоописание).** Claude формулирует шаг так размыто/обобщённо, что роутер не может подобрать специалиста → `no_skill_found` → шаг идёт «без специалиста», свободно. Но по сути, если разложить, там нужно МНОГО специалистов. Через кривую формулировку большой кусок работы **уходит из-под маршрутизации и проверки**. Не обязательно злонамеренно — это «лёгкий путь»/рационализация. Это **инверсия** OQ3: не подмена специалиста, а **побег от маршрутизации вообще**.
  **Защита (слоями; главное — перевернуть умолчание):**
  1. **PRIMARY — `no_skill_found` это СТОП, не GO.** Шаг, который роутер не смог разметить, **не исполняется молча**: либо переформулировать до маршрутизируемости, либо **эскалация владельцу** («почему без специалиста? одобряешь?»). Default-deny: нет специалиста = остановка, не свобода. **Это убивает мотив** — кривая формулировка больше не покупает свободу, она покупает трение.
  2. **Smell-check размера/мульти-скилла.** Шаг настолько широкий, что не routable И пахнет несколькими специалистами (объём/несколько глаголов) → флаг «недоописан, разбей» → принудительная декомпозиция до исполнения. Честно: «тайно мульти-скилл» — нечёткое LLM-суждение, неидеально, но поднимает планку.
  3. **Backstop судьи.** Даже если размытый no-skill-шаг проскочил план — на исполнении судья видит каждое действие; действие, явно требующее специалиста, под шагом «без специалиста» → нестыковка → блок. Слабее, чем при mismatched (эталон «без специалиста» жидкий), но есть.
  4. **Сеть оценщика.** Брейн-репо ловит «большой no-skill шаг сделал много квалифицированной работы» → калибровка. Постфактум.
  5. **Последний рубеж — владелец.** Каждый план виден (D7); no-skill-шаги делать **громкими** (подсветка + требуют sign-off владельца).
  **Честный остаток:** идеального детектора «скрытый мульти-скилл» нет — можно слепить шаг, выглядящий атомарным и skill-less. Машинами в ноль не сводится; последние линии — качество формулировки (на Claude) + надзор владельца над планом. Та же семья пределов, что OQ3/OQ6.

- **D15. Два разных «без скила» (закрывает путаницу).**
  - **A — «специалист НЕ НУЖЕН»** (штатно, не провал): **закрытый короткий список** — чтение файла / запрос к графу / вопрос владельцу / пара тривиальных. Судья пропускает (проверять нечего), владельцу **НЕ эскалируется** (иначе утонет в эскалациях на каждое чтение).
  - **B — «специалист НЕ НАЙДЕН»** (провал маршрутизации): роутер не смог разметить **рабочий** шаг → **СТОП → эскалация владельцу**. Владелец может ответить «делай без скила» → судья пропускает, **НО** через **записанный канал одобрения** (как git-подтверждения: выбор владельца пишется в защищённый журнал, судья читает), а **не со слов Claude** (иначе Claude сам себе припишет «хозяин разрешил»).
  - **Защёлка против маскировки B под A:** A — **закрытый** список; всё, что роутер не отнёс ни к специалисту, ни к списку A → **автоматически B** (default-deny). Список A держать **узким**.
  - **Честный остаток:** роутер может ошибочно отнести хитрый рабочий шаг к A; митигируется узостью закрытого списка, в ноль не сводится.

- **R-COMM. Правила общения с владельцем (стандарт на всех эскалациях и вообще).** (1) **Только по-русски, простыми словами, но информативно** — без жаргона/кодов, но по сути. (2) **Не вводить владельца в заблуждение и не обходить его** — ни обманной рамкой, ни умолчанием; решения и их причины показывать честно. Это hard-требование к owner-facing коммуникации всей схемы.

- **D16. «Спор» роутер↔Claude о формулировке — это планировочный цикл, не разовое событие.** Пока пишется план: я пишу шаг → роутер пробует разметить → если размыто/склеено/велико, толкает назад («уточни/разбей») → переписываю → снова. Спор **ограничен формой маршрутизации** (D14), суть не трогает. Эскалация владельцу = **тупик цикла** (специалист реально не найден, B), а не начало. Круги спора **логируются** (аудируемы, «не обхожу»), но владельца ими **не заваливаю** — живьём только тупики. **ОТКРЫТО (ручка видимости):** показывать владельцу каждый круг спора (макс. прозрачность, шумно) ИЛИ только итог+эскалации (тихо, спор в журнале) — владелец **не ответил**.

---

## АНАЛИЗ СВЕЖИМ ВЗГЛЯДОМ: разрывы логики, незакрытые дыры, забытые вопросы (2026-06-01)

**Разрывы логики / напряжения:**
- **L1. Судья и роутер — оба LLM на одном ключе/бюджете/флаге, и сегодня падают OPEN.** Нет ключа / бюджет исчерпан / ошибка API → `degraded_allow` (пропустить). Значит вся «без дыр»-дисциплина при сбое LLM-слоя схлопывается в «пропускай всё». Fail-open vs fail-closed не решён (fail-closed = не могу работать при сбое API). **Единая точка отказа.**
- **L2. Линейку (план) пишет тот, кого судят (Claude).** Роутер метит по тексту шага, судья сверяет с планом — а план авторства Claude. Кривая формулировка → лояльный/неверный специалист. Частично прикрыто (OQ7, no-skill=стоп + надзор владельца), но в корне это «самоавторская линейка» — нерекурсивно не закрыть (= asymptote floor, recursive-trust предел). Последний рубеж — владелец на видимом плане, но он не технарь.

**Незакрытые дыры:**
- **H1. Калибровку роутера должен вести НЕ-программист.** D4: владелец крутит роутер. Но правка правил классификатора — технический акт. Либо владелец не сможет (калибровка застопорится), либо попросит Claude (и тогда Claude настраивает того, кто его же судит — конфликт интереса). **Нужен простой owner-facing способ менять маршрутизацию без правки кода.** Не придумано.
- **H2. Кто одобряет РОСТ плана при волне?** Дерево растёт под-планами (D6/D12). Каждый рост проходит роутер+судья заново — но **видит ли владелец каждый рост** (D7 «владелец видит все планы») или только верхний план? Если только судья — владелец теряет дерево из виду (противоречит D7). Баланс «D7 vs не заваливать владельца» на росте не решён.
- **H3. Чтение как канал утечки в новой схеме.** Чтения — категория A (свободно). Но чтение может утекать (секреты/транскрипты). Существующие read-protections надо явно встроить ПОД план (в OQ4 упомянуто, в D12/D15 не интегрировано).
- **H4. Чистота семян — обещание, не enforcement.** `writing-plans` «чистый» (D13) и `AskUser` безвредный — но что МЕШАЕТ внутри `writing-plans` сделать лишнее? Нужна реальная проверка «writing-plans только пишет план-файл, ничего не читает/не мутирует», а не обещание.

**Забытые вопросы:**
- **Q1. Граница «микро vs нужен план».** Тривиальная правка (опечатка) через полный writing-plans+роутер+судья = абсурдные накладные. Floor «разговор/микро без плана» назван, но граница «где кончается микро» не определена. Если микро пускать без плана — это щель (работа под видом микро); если нет — невыносимо.
- **Q2. Цена и скорость.** Судья на КАЖДОЕ действие (вкл. чтения, D10) + роутер на каждый шаг + два круга планирования = много вызовов Sonnet на задачу. Задержка (каждый tool ждёт round-trip к Sonnet) и деньги не оценены. Может оказаться болезненно медленно.
- **Q3. Зависимость «нет действия без плана» от D10.** Правило держится, ТОЛЬКО если судья реально срабатывает на каждое действие, включая чтения. Сегодня судья на чтения не срабатывает (только мутации). То есть «без плана не почитаешь» = именно дорогой D10, иначе разведку можно вести без плана.
- **Q4. Путь миграции.** Это всё ДИЗАЙН, не построено. Сегодня живо: классификатор (только что починен), судья (режим безопасности), оценщик (офлайн). Переход к этой схеме — большая стройка (недели), нужен полноценный spec+plan через `writing-plans`. Как мигрировать, не сломав мою работоспособность — не обсуждали.
- **Q5. Ручка видимости спора (D16)** — владелец не ответил.

**Сделанное в коде этой сессии — ОТДЕЛЬНО от дизайна (реально готово, не часть стройки выше):** `max_tokens` 1500→15000; починка `task_type` (промпт+разборщик), 1996 тестов GREEN, **не закоммичено**.

---

## РЕШЕНИЯ ПО ДЫРАМ (2026-06-01)

- **Д1 — ОТЛОЖЕН.** Как не-программисту крутить роутер — отдельный вопрос на потом.
- **D17 (закрывает Д2). Владелец видит ВСЕ планы и всех специалистов, включая каждый под-план волны.** Когда большой шаг дробится — этот под-план (со специалистами) тоже показывается владельцу, не только судье. Видно всё дерево, по уровням, по мере роста. **Честная цена:** больше точек просмотра (каждая волна = ещё план глянуть). Смягчение на будущее (опционально, не сейчас): авто-одобрение волн, где все специалисты уже одобрены раньше — по принципу «ослабим потом».
- **D18 (закрывает Д3). «В плане» ≠ «безопасно».** Отдельный всегда-включённый страж (read-protection) блокирует чтение секретов / чужих транскриптов / системных файлов **независимо** от того, что чтение в плане. Два независимых барьера: (1) «в плане?» (судья) И (2) «это вообще можно читать?» (страж). Барьер 2 существует уже сегодня (read-path-deny) и остаётся включён; «в плане» его **не отменяет**.
- **D19 (закрывает Д4). Чистота семени — enforcement, не обещание.** Семя `writing-plans` разрешает РОВНО одно: создать файл-плана (+ семя «спросить владельца»). Любое другое действие под видом writing-plans (чтение / правка / команда) блокируется как любое внеплановое. Если для плана нужно почитать — это идёт отдельным кругом-разведкой (план на чтение), а не внутри writing-plans. Разрешение семени **узкое по построению**.

- **D20 (закрывает В1, выбор владельца — вар. 2). «Мелочь без плана» — узкий закрытый список.** Мелочью считается действие, удовлетворяющее ВСЕМ условиям: один файл + мало строк (≈≤5) + без новых файлов + без запуска команд. Всё, что не влезло → **нужен план** (default-deny). Судья всё равно видит само действие. Защита от нарезки крупного на серию «мелочей»: серия однотипных мелких правок в одном месте → сигнал «это уже задача, нужен план».

- **D21 (закрывает В2, выбор владельца — вар. 2). «Проверять всё» ≠ «звать ИИ на всё».** Порядок: (1) сперва **бесплатная проверка кодом** — совпадает ли действие с текущим шагом плана и его специалистом → да → пропуск мгновенно, без ИИ; (2) к ИИ-судье уходят только **спорные/непохожие** случаи; (3) дешёвая модель (тип Haiku) для рутинного ИИ-слоя, дорогая — на рискованное; (4) кэш + батчинг чтений. Покрытие полное (каждое действие проверяется), но большинство проверок бесплатны. Честно: тонкую подмену специалиста ловит только ИИ (≈10% случаев — за деньги/время). Измерить на реале, ослаблять точечно.

- **D22 (уточнение к D15: что есть «чтение» / категория A).** Граница не в «скил/MCP/файл», а в **«меняет состояние или только узнаёт»**. **Чтение (A, свободно):** прочитать файл / `/graphify` / **read-only MCP** (context7, Boost-чтение схемы, Sentry-чтение, read-only API) / спросить владельца. **Действие (план+специалист+судья):** **вызов скила** (скил = специалист, всегда маршрутизируется, кроме семян `writing-plans`+вопрос владельцу), правка/коммит/push, **меняющий MCP** (постинг/запись/деплой), запуск субагента (Task). Ключ: **скил — НЕ чтение** (даже аналитический — это работа, планируется и видна); **MCP делится** на read-only (чтение) и меняющий (действие).

---

## МОДЕЛЬ «РОУТЕР = НАСТАВНИК» (2026-06-01, переписывает D8/D14)

> **Идея владельца:** роутер — это опытный **наставник** Claude. Пока наставник и Claude согласны — работают сами, владельца не дёргают. Владелец включается **ТОЛЬКО на разногласии**. Власть смещена к роутеру сознательно (роутер владелец может крутить, Claude — трудно).

- **D23. По умолчанию Claude берёт ВСЁ, что советует роутер.** Роутер советует скилы/MCP/инструменты (Claude не помнит все). **Эскалация владельцу — только при ЖЁСТКИХ сомнениях** Claude, что роутер прав: с двумя обоснованиями (Claude + роутер, простым русским) → решает владелец. Нет сомнений → берём. *(Разворот раннего «score≥70%→escalate»: теперь default-obey, escalate-on-strong-doubt.)*
- **D24. Роутер может МЕНЯТЬ план (обновляет D8/D14).** Роутер вправе **добавить/изменить шаг**, если видит улучшение результата (знает про доступные скилы/MCP). Claude конкретно против → к владельцу с обоснованиями → решает владелец. **Это переписывает D8 («роутер только метит специалистов») и D14 («роутер только форма, не суть»):** теперь роутер — **соавтор плана** с правом правки, ограниченный вето Claude → арбитражем владельца. Совместимо с D17: владелец **видит** всё, но **действует** только на разногласии.
- **D25. Оценщик расширяется + закрывает слепое пятно.** Оценщик (брейн-репо) теперь видит **диалог роутер↔Claude** (советы, согласия, разногласия, обоснования) **и конечный результат**, оценивает оба. По оценке **крутим роутер** (калибровка, manual — D4, Д1 отложен). **Зачем:** слепое пятно модели «наставник» — **«роутер и Claude СОГЛАСНЫ, но оба неправы»**: разногласия нет → владельца в реальном времени не зовут. Ловится только (а) глазом владельца на видимом плане (D17) и (б) **оценщиком постфактум** — поэтому расширение оценщика обязательно, это противовес. Вторичный риск: «жёсткие сомнения» — дискреция Claude (может недо-возразить); лечится тем же оценщиком («Claude послушал → результат плохой» → крутим роутер).
- **Требование к диалогу:** весь обмен роутер↔Claude **логируется** (для оценщика и аудита владельца), обоснования — **простым русским** (R-COMM).

- **D26 (закрывает В3, выбор владельца; обновляет D22).** Разделяем чтения по «локальное vs внешний вызов»:
  - **Локальное чтение файла** → вариант 2: **не блокируется**, но **логируется + показывается владельцу** + страж секретов (D18). Видно всё, утечки нет, разведка не тормозит.
  - **Читающий (read-only) MCP** (context7 / Boost-чтение / Sentry-чтение / openapi / любой внешний read) → **ТОЛЬКО ПО ПЛАНУ.** Причина: это **обращение к внешнему серверу** (стоит денег/квоты, видно снаружи, может тянуть много/чувствительное) → должно быть **осознанным**, строкой в плане. Тоже логируется + страж.
  - **Это обновляет D22:** read-only MCP уходит из «свободного чтения» в «по плану». Локальные файлы остаются свободными (вар. 2). Граф — по своей природе (если через скил → по плану; если локальное чтение → свободно).
  - **Честная цена:** быстрый просмотр доков через context7 теперь требует строки в плане (чуть больше трения). Ослабим потом, если будет мешать.

- **D27 (закрывает Л1, выбор владельца — вар. 3 + крик про деньги).** При сбое ИИ-слоя НЕ «пропускать всё». **Деградация до проверки кодом + fail-closed на неясном:** действие, которое код однозначно сверил с одобренным планом → пропуск; действие, которому нужно суждение ИИ, а ИИ лежит → СТОП + эскалация владельцу (на время сбоя владелец = запасной судья/роутер). **ДОБАВЛЕНИЕ владельца — различать причину сбоя:** (а) **деньги/бюджет кончились → ГРОМКО кричать владельцу** явным уведомлением «деньги на ИИ кончились!» (не уходить тихо в деградацию — это надо чинить пополнением); (б) transient (сеть/таймаут/временная ошибка) → тихая деградация + retry. Устойчивость зависит от точности плана (код матчит действие с шагом) — связь с Л2.

- **D28 (закрывает В4, выбор владельца — вар. 2). Поэтапно + сперва ТИХИЙ режим (shadow).** Порядок внедрения: (1) эти заметки → формальная **спека** + план реализации (через `writing-plans`); (2) сборка частей по TDD в стороне, не вживую; (3) **тихий режим** — новые гейты работают и **логируют**, что бы заблокировали/эскалировали, но **реально не блокируют**; меряем на живой работе долю ложных блоков, цену, объём эскалаций; (4) **подкрутка порогов** по реальным данным; (5) **включение в бой постепенно** (сперва мутации, потом чтения). Живая система во время стройки не ломается. Две сегодняшние починки кода (`max_tokens`, `task_type`) — независимы, выкатываемы сразу.

---

## L2 — РЕШЕНИЕ (D29)

- **D29 (закрывает Л2, выбор владельца — вар. 2; сильная форма Л2 СНЯТА).** Сильная форма «план пишет только подсудный» — **устарела**: план со-авторный (Claude пишет шаги; роутер правит/дополняет + назначает специалистов — D24; отказ Claude эскалирует к владельцу; оценщик сверяет план↔результат — D25). **Остаток:** содержание/формулировка шагов всё ещё в основном Claude → роутер проверяет **маршрутизируемость**, не **верность просьбе владельца**. **Решение:** отдельная проверка **«план ↔ просьба владельца» ДО исполнения** — внешний якорь = слова владельца (не линейка Claude), проверяющий ≠ автор. Ловит оба дрейфа: план **уже** просьбы (недоделка) и **шире** просьбы (самодеятельность / скрытый объём) → расхождение к владельцу. Отлична от судьи (тот: действие↔план) и оценщика (тот: постфактум). Цена: один прогон ИИ на план (планы редки). Честно: проверяющий тоже ИИ + просьба бывает размытой → остаток **сужается, не исчезает** (предел recursive-trust).

---

## ФИНАЛЬНЫЙ ПОТОК + СУДЬЯ-ВОРОТА (2026-06-01, D30–D33)

> **🔄 ПОМЕТКА 2026-06-04:** трёх-режимная модель D33 (болтовня/думанье/продукт) **пересмотрена** — в рабочей среде болтовни нет (она → claude.ai), осталось ДВА режима. Также: D29 (сверка план↔просьба) поглощена слоем общения + закрытой дверью; D32 — мыслительные скилы остаются семенным классом. Канон реализации — чертёж Машины 2 (`2026-06-03-router-mentor-machine-2-...md`). Этот файл — исторический первоисточник; при расхождении верить чертежу.

- **D30 (ИСПРАВЛЕННЫЙ, финальный — заменяет «владелец штампует каждый план»). Судья — ВОРОТА на план.** Результат решения **всегда** летит судье — звал владельца или нет. На входе цепочка: **«роутер+Claude»** (согласились) ИЛИ **«роутер+владелец+Claude»** (был спор, владелец рассудил). Судья смотрит, **права ли цепочка**: **согласен → пропуск** (владелец видит план по D17, но НЕ обязан штамповать); **не согласен → эскалация владельцу.** Владелец подключается **только** на: (1) спор роутер↔Claude (тай-брейк), (2) несогласие судьи. **Даже решение с участием владельца** («роутер+владелец+Claude») судья **перепроверяет** и при несогласии возвращает владельцу (владелец наверху, судья — независимая проверка). **Вторая роль судьи — надзор на исполнении** (не отойти от плана, не делать без специалиста, две проверки: план-уровень + action-уровень, см. пример «инспектор: утвердил чертёж + следит за стройкой») — без изменений. Закрывает слепое пятно D25 **в реальном времени**: чтобы плохое прошло, должны ошибиться **роутер + Claude + судья** разом И владелец не глянуть.
- **D31. Оценщик расширен на оценку СУДЬИ.** Брейн-репо оценивает работу и роутера, и судьи (вердикты, диалог, результат) → владелец **крутит обе ручки** — и роутер, и судью.
- **D32. Мыслительные скилы: семя + обязательны.** `brainstorming` / `discovery-interview` / `writing-plans` — **семенного класса** (вызываются без плана — они САМИ рождают план; убирает отговорку «не мог») И **обязательны для содержательного мышления**. **Роутер РЕКОМЕНДУЕТ** мыслительный скил (источник требования); Claude берёт по умолчанию (D23), сильно не согласен → владелец. **Судья на уровне ОТВЕТА (Stop) БЛОКИРУЕТ**, если содержательное мышление / написание плана идёт **без** рекомендованного скила. Судья ничего не «требует» сам — он **сторож исполнения рекомендации роутера / решения владельца**. Расширяет периметр на фазу мышления (дороже + риск ложных блоков на простом — тюнить).
- **D33. Режим разговора (расходится).** **(а) Тривиальная болтовня** (привет / да-нет / уточнить слово) — машина спит, скил не нужен. **(б) Содержательное мышление** (дизайн / discovery / брейнсторм / план) — обязателен мыслительный скил (D32). **(в) Продукт/код/прод** — полная машина (план→роутер→судья-ворота→исполнение). **Страж секретов (D18) работает ВСЕГДА**, в любом режиме. NB: ЭТА сессия (01.06) шла как (б) — дизайн БЕЗ `brainstorming` → в строгой схеме судья блокировал бы её многократно (живое доказательство «дрейфа без инструмента»).
  - **🔄 [РЕВИЗИЯ 2026-06-04 — призма владельца, синхрон с чертежами Машины 2]:** в РАБОЧЕЙ среде режим **(а) «болтовня» НЕприменим** — для болтовни владелец уходит в claude.ai. Остаются **ДВА режима: (б) думанье и (в) продукт**, дисциплина включена **всегда** (off-состояния нет → механический «триггер включения слоя» не нужен; finding 8 ревизии плана М2 растворён). В реализации Машины 2 D33 = два режима `decideMode` (нет плана → семена/зелёный проход; есть план → строгий матч); СМЫСЛОВОЙ разбор «что обязательно через навык» — рассуждение → **роутер (М3)**, не стена. Подробности — `docs/superpowers/plans/2026-06-03-router-mentor-machine-2-lock-and-supreme-hook.md` (раздел «ПРИЗМА ВЛАДЕЛЬЦА» + Self-Review fresh-eyes).

---

## D34 — ходы роутера + В5 + потолок кругов (2026-06-01)

- **D34. Ходы роутера при формировании плана (расширяет D14/D24).** Роутер может: (1) **рекомендовать скил** на шаг; (2) **разбить** склеенный шаг; (3) **добавить** шаг с полезным скилом/MCP, который Claude забыл/не знал; (4) **заменить** шаг/подход на лучший (убрать один → добавить 2 новых с другими скилами). **Причина:** Claude не держит всю картину скилов/MCP/плагинов/агентов и склонен лениться — роутер её держит, поэтому **помогает формировать план и вешать скилы.** **Граница:** роутер улучшает **МЕТОД** (как делать); **ЦЕЛЬ** остаётся владельца (D29, подтверждённая шапка). Claude не согласен с ходом → владелец; итог → судья-ворота (D30).
- **В5 (ЗАКРЫТ, вар. 2 + нумерация).** Владельцу показываем **итог + эскалации**; круги спора роутер↔Claude — **в журнал с нумерацией** («круг 1», «круг 2», …). Не заваливаем владельца, но всё аудируемо.
- **Потолок кругов (ответ на «сколько их может быть»).** Обычно **1 круг** (Claude берёт по умолчанию, D23). На спорном пункте — 2–3. **Жёсткий потолок N кругов на ОДИН спорный пункт (старт ~3)** → авто-эскалация владельцу → спор **не зацикливается.** N — ручка владельца.

---

## D35 — роутер может переписать план ЦЕЛИКОМ + В6 контекст (2026-06-01)

- **D35 (сильная форма D24/D34, подтверждение владельца пт.5).** Роутер вправе предложить не только точечные правки, а **полностью переделанный план** с другими шагами/специалистами. **Три жёстких условия:** (1) **не втихую** — каждое изменение с **мотивацией простым русским** «почему меняю это на то» (R-COMM); (2) Claude **смотрит предложение и соглашается/нет** — не автомат; (3) дальше по обычной схеме (Claude против → владелец-арбитр → судья-ворота D30). Власть роутера над **методом** велика (вплоть до полной замены плана), но **цель остаётся владельца** (D29) и **вето Claude → арбитраж владельца** никуда не делось. Это не «роутер диктует», это «опытный наставник предлагает, ученик может возразить, спор решает хозяин».

- **В6 (ОТКРЫТ — сколько контекста нужно роутеру). Вопрос владельца:** хватает роутеру последнего промпта или нужен контекст? **Анализ (честно):**
  - Старая роль роутера — «классифицировать один промпт» → последнего промпта хватало (он сейчас так и работает — stateless, без памяти).
  - Новая роль — **критиковать и переписывать ПЛАН** → последнего промпта **НЕ хватает.** Владелец прав: роутер, видя только последнюю фразу и не понимая замысла, начнёт **ломать хороший план от незнания.**
  - Но «вся сырая переписка каждый раз» — **дорого** (токены = деньги, а это твоя боль) + **шумно** + риск, что роутер начнёт **пере-оспаривать** уже решённое между тобой и Claude.
  - **Варианты:**
    - **A** — только последний промпт. ❌ Отклоняю (ломает планы, ты прав).
    - **B (РЕКОМЕНДУЮ)** — роутер получает **сам план + цель владельца + каждый шаг плана несёт свою короткую причину «зачем»** (план самодостаточен) + короткая выжимка контекста. Роутер судит **план-как-написан**, дёшево, без пере-оспаривания. Побочно вводит правило: **план обязан быть самообъясняющим** (у каждого шага строка «почему») — это и тебе читать удобнее.
    - **C** — вся сырая переписка на каждый вызов. Полный контекст, но дорого + риск пере-оспаривания + медленно.
  - **Моя рекомендация — B:** не «голый промпт» и не «весь чат», а **план+цель+самообъясняющие шаги**. Закрывает твой страх (роутер не ломает вслепую — он видит весь план и зачем каждый шаг), и не жжёт деньги. **Жду твой выбор A/B/C.**

---

## D36 — что нужно для живого диалога роутер↔Claude + В6 закрыт (2026-06-01)

- **В6 (ЗАКРЫТ, вар. B).** Роутеру даём **план + цель владельца + самообъясняющие шаги** (у каждого шага строка «зачем»). НЕ голый последний промпт (вслепую ломает план), НЕ вся сырая переписка (дорого + пере-оспаривание). Вводит правило: **план обязан быть самообъясняющим.**
- **D36. Для здорового диалога роутер↔Claude вариант B дополняется двумя вещами:**
  1. **Память самого спора.** Роутер сейчас stateless (одноразовый). Для 2–3 кругов по ОДНОМУ плану ему надо помнить, что он уже сказал в круге 1. Решение: подкладывать **журнал переговоров этого плана** (он и так ведётся — D24/В5), НЕ весь чат. Без этого круг 2 начинается с нуля.
  2. **Свежий каталог инструментов.** Чтобы роутер советовал **реальные** скилы/MCP/агенты, а не выдуманные, ему нужен актуальный реестр/граф доступных специалистов. Без этого — галлюцинации «возьми скил X», которого нет.
- **Достаточность (проверено):** общий предмет (план, B), цель (B), «зачем» на шагах (B), обоснования смены (D35, R-COMM), правило остановки (потолок кругов D34), формат «предложение→причина→вердикт» + журнал (В5) — уже есть. Плюс память спора + каталог = **полный набор для диалога.** Больше для диалога не требуется.

---

## СНАРЯЖЕНИЕ РОУТЕРА — что он должен иметь (2026-06-01, обсуждение по пунктам)

> Тема: «что роутер должен ИМЕТЬ, чтобы работать правильно и эффективно». Разбираем по пунктам, 6 групп / 24 пункта (см. карту в чате). Фиксируем по мере согласования. Статусы: ✅ согласовано / ⏳ обсуждается / ⏸ отложено.

### Группа 1 — Движок
- **1.1 ✅ Выбор скила — по смыслу + рассуждение модели; ключевые слова для маршрутизации СНЯТЫ.** Причина владельца: keyword-роутинг (а) не различает «близнецов» (два скила делают похожее, но один лучше под конкретную задачу — слово видит букву, не смысл) и (б) деградирует при росте мозга до 150–200+ узлов (пересечения, ручная починка списков). **Механизм (РЕШЕНИЕ ВЛАДЕЛЬЦА 2026-06-02 — БЕЗ СУЖЕНИЯ):** модель видит **ВЕСЬ граф+каталог узлов на 100%** (код-сужение до ~5 кандидатов ОТМЕНЕНО — иначе сыпется вся идея: код мог спрятать нужный узел) и **рассуждением** выбирает лучшего под ЭТУ задачу с обоснованием (привязка к 5.1), различая близнецов по полному набору. **Код в выборе скила НЕ участвует** — остаётся только на грубом фильтре «тривиал/работа» (D33) и на механической проверке, что выбранный скил реально существует (ОВ-Д2). Полный граф даётся один раз и кэшируется (см. «ПОЛНЫЙ ГРАФ — РЕШЕНИЕ ВЛАДЕЛЬЦА»). Качество держится на хороших описаниях узлов, которые растут вместе с мозгом.
- **1.2 ✅ «Думать лучше» = метод брейнсторма ВШИТ в инструкцию (приём, не запускаемый скил).** Берём из брейнсторма манеру: придумать 2–3 варианта (не хвататься за первый) → поспорить с собой → выбрать лучший с объяснением. **Отличие от скила:** скил — многошаговый процесс, который ведёт Claude через много вызовов; роутер — ОДИН вызов, скил «запустить» не может → суть приёма кладётся в его инструкцию, он применяет её внутри своего единственного раздумья. **Когда работает (с учётом 1.1):** НЕ на грубом фильтре (привет/ок — машина спит, $0); включается на выборе скила (различить близнецов по полному графу) и при критике/замене шага плана (4.3). Питает «рассмотренные альтернативы» + причину → трассу 5.1. **Цена ≈ ноль** (тот же вызов модели, просто аккуратнее инструкция). Близкий родственник 5.4 (самопроверка) — возможно слить в один приём «думай и перепроверь себя» при разборе 5.4.

  **РАСШИРЕНИЕ 1.2 (финал 2026-06-02): роутер несёт ДВА вшитых метода-стандарта, применяются в 3 СЛОЯ.** Уровень 1 (recommend Claude) — writing-plans уже есть как семенной скил (D32); здесь про уровень 2 — вшито в сам роутер, как брейнсторм. Когда приходит план:
  1. **БРЕЙНШТОРМ ПЛАНА** — 2–3 разных ПУТИ к цели, сравнить компромиссы, выбрать (роутер вправе предложить альтернативный подход целиком, D34/D35). Только если путей реально несколько.
  2. **WRITE-PLANS-стандарт** — выбранный путь → качественный план. Золотая тройка: (а) каждый шаг = проверяемый ИСХОД, не действие («X сделан и проверено» → даёт судье факт-сверку); (б) у шага «зачем» (самообъясн., B/D36); (в) делёж «как сделать просьбу / СВЕРХ просьбы» (анти-scope #5). Идёт ВСЕГДА на реальном плане.
  3. **БРЕЙНШТОРМ СКИЛА** — пошагово при разметке, где выбор спорен. Золотая тройка: ≥2 кандидата с разных углов графа + «почему не сосед-близнец» + один «а если я неправ?». Только где выбор реально есть.
  - Шаги 2–3 ИНТЕРЛИВ (пишу шаг → тут же размечаю). Каждый уровень УСЛОВНЫЙ (очевидный путь/скил → пропуск; тривиал → ничего — анти-турникет #1). Роутер не ЗАПУСКАЕТ скилы — впитал их СТАНДАРТ.
  - **ДИСЦИПЛИНА САМОГО РОУТЕРА (он тоже ИИ, может халявить «как Claude»):** полностью НЕ убираема (тот же архитектурный пол), но делаем ВИДИМОЙ + ПОЙМАННОЙ: (а) обязательная СТРУКТУРНАЯ трасса 5.1 со слотами (пути / почему этот / близнецы-почему-не / почему пропустил уровень) — пустой/тривиальный слот = видимый красный флаг, схалтурить МОЛЧА нельзя; (б) оценщик ловит штамповку постфактум; (в) судья ловит халтуру по качеству плана; (г) владелец видит трассы (D17). У роутера слабее мотив халявить — его продукт ЕСТЬ само мышление, некуда «спешить доделать задачу».

  **ОТКРЫТЫЕ ВОПРОСЫ — КАЧЕСТВО/УМЕНИЕ роутера (⏳ это НЕ про дисциплину/принуждение, а про то, как роутер ХОРОШО ДЕЛАЕТ работу; владелец вернётся):**
  - **ОВ-Д1. ✅ РЕШЕНО: цепочки СОБИРАЮТСЯ РАССУЖДЕНИЕМ; фиксированных/канонических цепочек НЕ храним (решение владельца, 100%).** Причина: хранимые цепочки = стандартизация, умрёт при росте узлов (та же логика, что убила ключевые слова в 1.1 — новый узел не впишется в замороженные рецепты). **Механизм:** роутер для конкретной задачи рассуждает «что нужно, чтобы сделать ЭТО хорошо, шаг за шагом» и собирает цепочку из ВСЕГО живого набора узлов по смыслу; граф = карта (что есть + связи по смыслу), НЕ книга рецептов. Новый узел → сразу в игре, списки чинить не надо. Звенья = реальные узлы графа (анти-выдумка, стык ОВ-Д2), порядок = по настоящей зависимости (X до Y, т.к. Y использует результат X). «Нужна ли цепочка» и её длину — тоже рассуждением (по размеру/природе задачи), не по типу-шаблону. **Размен (осознанный):** гибкость+масштаб ценой предсказуемости. Подчищены «рецепты/канонические цепочки» в 3.2/3.3/5.5. **Исполнение цепочки (стык дисциплина/#6):** цепочка обязательна ПО ЗВЕНЬЯМ — судья следит, что звенья пройдены, не схлопнуты. Схлопнуть 5→1 МОЛЧА нельзя; если Claude считает, что хватит одного скила (роутер пере-зачейнил) → ОТКРЫТОЕ предложение роутеру как находка (#6) с обоснованием → роутер решает (согласен → сворачивает открыто; спор → владелец). Это же — канал коррекции ПЕРЕ-routing роутера. Честно: без судьи ленивый Claude схлопнул бы молча — поэтому судья+дисциплина обязательны.
  - **ОВ-Д2. ✅ РЕШЕНО: заземление брейншторма — двумя способами.** ИИ генерит правдоподобное из общих знаний, не из нашей реальности (пример: предлагает Elasticsearch, которого нет в стеке; или скил, которого нет в узлах). **(1) Скилы/кандидаты — МЕХАНИЧЕСКИ:** каждый названный скил обязан резолвиться в реальный узел графа; выдумка → код отклоняет (как классификатор). Дёшево и насмерть. **(2) Пути/подходы — на ФАКТЫ:** роутер сперва тянет реальные факты (граф/каталог/контекст: стек, что есть) → потом рассуждает; путь без опоры на факт → пометка «гипотеза» + ниже уверенность (не выдавать догадку за факт); внедрение нового (Elasticsearch) = рост объёма → к владельцу (#5). **Предел:** скил-фантазии убиты механически; путь-фантазии труднее (код не проверит реалистичность подхода) → факт-привязка + «гипотеза» + оценщик/владелец постфактум. Усиливает шаг 2 сборки цепочки ОВ-Д1 («звено = реальный узел»).
  **ДИСЦИПЛИНА РОУТЕРА — ✅ ЗАЛОЧЕНО (отдельная ось: заставить роутер работать по стандартам, не халтурить; он тоже ИИ).** Полностью не убираема (архитектурный пол), но сделана ВИДИМОЙ + ПОЙМАННОЙ + ПРИНУДИТЕЛЬНОЙ:
  1. **Обязательные структурные слоты + механический валидатор.** Брейншторм/write-plans = слоты вывода роутера; код отклоняет неполный вывод → без них валидного результата НЕТ (тот же приём, что фикс классификатора `task_type`).
  2. **Пропуск уровня — только ЯВНЫЙ и из ЗАКРЫТОГО СПИСКА категорий** («путь один: атомарная» и т.п.). Свободный текст / «не хочу» → отклонён (как закрытый список «скил не нужен» D15). Убивает junk-обоснование.
  3. **Счётчик частоты пропусков** → аномально частый пропуск (даже валидной категорией) = флаг (как лимит обходов).
  4. **Постфактум:** оценщик проверяет ПРАВДИВОСТЬ категории («заявил атомарная — была ли?») + владелец видит трассы (D17).
  - Итог: молча или мусором не схалявить; хитрая ложь по категории → оценщик+владелец (тот же пол). Мотив халявить слабее — продукт роутера = само мышление.

### Группа 2 — Что получает на вход (2.1/2.2 ✅ ранее = B/D36)
- **2.3 ✅ Роутер видит прогресс плана (компактной выжимкой).** Не только статичный план, но «где мы сейчас»: какие шаги сделаны и чем кончились (получилось / провал / вскрылось новое). **Зачем:** (1) подстроиться под реальность — поздний шаг 4 вскрыл неожиданное → правильный скил для шага 5 уже другой (право со-автора D24/D35); (2) не советовать уже сделанное; (3) реакция на провал — вставить чинящий шаг, а не гнать по плану; (4) общая ориентация «шаг 5 из 7». **Форма:** компактная выжимка «сделано + итог» при разметке поздних шагов, не вся простыня (принцип 6.2). На коротких планах роли не играет; важно на длинных, где реальность расходится с планом.

### Группа 3 — Знания
- **3.1 + 3.2 + 3.3 ✅ ДВА СЛОЯ: граф инструментов → каталог (идея владельца).** Плоский каталог говорит ЧТО умеет инструмент, но не КАК инструменты связаны — а связи это и есть больные места. **Слой 1 — граф инструментов (3.2):** по смыслу задачи попасть в область графа и увидеть кандидатов + их связи: **альтернативы/«близнецы»** (ребро «A и B — альтернативы для X» → роутер ОБЯЗАН их сравнить, а не хватать вслепую — лечит претензию к 1.1), **связи-подсказки** (ребро «A по смыслу рядом с B» — ПОДСКАЗКА, НЕ канонический рецепт; саму цепочку роутер СОБИРАЕТ рассуждением под задачу — ОВ-Д1; сюда же бывший 3.3), **конфликты** (ребро «A конфликтует с B» = правило «два инструмента на одну задачу нельзя» → кормит 5.5). Рост до 200 узлов — навигация по областям графа узлов. **Слой 2 — каталог (3.1):** точные детали (описание/цена/как звать) — **по ВСЕМ узлам, 100%** (решение владельца 2026-06-02: модель видит полный каталог, не только финалистов; сужения нет). **Поток (решение владельца):** модель видит **весь граф (узлы+рёбра) и весь каталог сразу** → рассуждением выбирает; рёбра (близнецы/подсказки/конфликты) помогают сравнивать, но НИЧЕГО не прячут. **Жёсткое условие свежести:** граф и каталог — два ВИДА одного источника (реестра узлов); добавил узел в реестр → оба обновились сами, не разъезжаются.

  **УТОЧНЕНИЕ ВЛАДЕЛЬЦА (важно — две РАЗНЫЕ графа, не путать):**
  - **Граф УЗЛОВ (мозга/инструментов)** = основа маршрутизации. Узлы = скилы/MCP/агенты (~86 → 150–200), рёбра = альтернативы / связи-подсказки / конфликты. **Стабилен** — меняется только при добавлении/выводе инструмента. **Строится из РЕЕСТРА**, НЕ из graphify. Рёбра берём из задокументированных связей/конфликтов/альтернатив (надёжно), но это **ПОДСКАЗКИ, не фиксированные цепочки** — саму цепочку роутер собирает рассуждением (ОВ-Д1); graphify может лишь ПОДСКАЗАТЬ новое ребро → входит в граф узлов только через одобрение владельца (гейт 3.4/3.5), не сам.
  - **Граф ПРОЕКТА (graphify, 6305 узлов docs+код)** = ОТДЕЛЬНАЯ, волатильная штука («через неделю другой» — код меняется). Для выбора скила НЕ годится. Используется только по требованию для вопросов про код, не трогает маршрутизацию.
  - **Свежесть (3.6):** граф узлов почти не протухает (стабилен) → 3.6 в основном про каталог/память; граф проекта волатильный → on-demand.

  **ПОЛНЫЙ ГРАФ — РЕШЕНИЕ ВЛАДЕЛЬЦА (✅ ФИКС 2026-06-02, без вариантов).** Роутер И судья (и Claude, и оценщик) видят **граф+каталог узлов на 100%** — никакого код-сужения до кандидатов (отменено везде: 1.1/1.2/3.1-3.3/6.2 — иначе сыпется вся идея, код мог спрятать нужный узел).
  - **«Загрузить один раз, не таскать каждый запрос» — как это реально работает.** Модель БЕЗ памяти между вызовами — буквально «запомнить» граф не может. Поэтому: граф+каталог = **файл**, в промпт идёт каждый вызов, но через **кэш промпта** (граф большой и стабильный → кэшируется отлично, после первого вызова ~free). Итог ровно как просил владелец: собрали один раз, повторно не оплачиваем, не пересобираем на каждый запрос.
  - **Обновление — ТОЛЬКО при добавлении/выводе узла, в 4 местах сразу:** роутер / судья / Claude / оценщик. Чтобы не забыть и не разъехались — обновление делать **одним действием**, которое освежает все 4 (или все 4 читают из одного источника-реестра). Между добавлениями узлов — не трогаем.
  - **Деньги:** дорог только первый вызов каждого (роутер и судья — разные API, кэш у каждого свой); дальше кэш делает граф дешёвым. Урезанием не экономим — экономит кэш.
- **3.4 ✅ РЕШЕНО (владелец 2026-06-03): механизм СТРОИМ; наполнение — ТОЛЬКО по явному разрешению владельца, ИНАЧЕ НИКАК (hard-rule: без авто-наполнения, без авто-обучения, без тихого накопления в активный фонд). Примеры-прецеденты (few-shot), ДИНАМИЧЕСКИЕ + только по одобрению владельца.** 2–3 образца хорошо размеченных планов в инструкции → роутер подражает (модель сильно учится на примерах: формат, уровень детализации, как писать «почему», когда «не нужен»). Дополняет граф+каталог: те дают факты (что есть/как связано), примеры — манеру (как размечать хорошо). **Засада:** замороженный хардкод устаревает (растёт мозг) и перекашивает (частый скил X в примере → суёт X везде). **Решение:** примеры не вмораживать, а подтягивать несколько ЛУЧШИХ реальных случаев. **ЖЁСТКИЙ ГЕЙТ ВЛАДЕЛЬЦА:** оценщик/система только ПРЕДЛАГАЕТ кандидата (нашёл хороший случай) → попадает в «золотой фонд» примеров **ТОЛЬКО после явного одобрения владельца**. Без «да» — не добавляется. Мало + разнообразные (без перекоса). Связь с 3.5 (тот же гейт одобрения).
- **3.5 ✅ РЕШЕНО (владелец 2026-06-03): механизм СТРОИМ; наполнение — ТОЛЬКО по явному разрешению владельца, ИНАЧЕ НИКАК (hard-rule, без авто-обучения). Долгая память роутера — через оценщика, ТОЛЬКО по одобрению владельца.** Роутер умнеет между сессиями: помнит, что для таких задач сработало / где ошибся (копит оценщик/брейн-репо: «совет → результат → вывод»). Отлична от рабочей памяти 2.2 (та живёт минуты — спор по текущему плану; эта — месяцами). Без неё роутер повторяет промахи. Засада та же — закостенеет на плохом шаблоне. **Гейт владельца** (как 3.4): оценщик предлагает → в долгую память входит только с «да». По сути 3.4 (примеры) и 3.5 (опыт) — ОДИН механизм «оценщик предлагает → владелец одобряет → роутер учится», две витрины.
- **ИНСТРУМЕНТ ДОСТАВКИ одобрений (3.4+3.5, один на оба) ✅ СТРОИМ (решение владельца 2026-06-03); наполняется ИСКЛЮЧИТЕЛЬНО через явное одобрение владельца — система только ПРЕДЛАГАЕТ, никогда не добавляет сама.** (1) **Очередь** (файл) — оценщик копит туда только СИЛЬНЫХ кандидатов (мало, без усталости владельца). (2) **Показ — в `/brain-retro`** (владелец его и так гоняет): раздел «На одобрение», по каждому — что это (пример плана 3.4 / урок в память 3.5), суть строкой, ПОЧЕМУ предложено, выбор. (3) **Сигнал в STATUS.md** «ждут одобрения: N». **Одобрение пачкой:** «одобряю 1,3 / отклоняю 2 / отложить 4». Одобрено → в фонд/память; отклонено → выкинуто + помечено (не предлагать повторно); отложено → ждёт. Не дёргает в процессе, один экран для обоих, без «да» ничего не входит. Переиспользует существующий brain-retro + STATUS-генератор — почти ничего нового строить.
- **3.6 ✅ Чувство свежести.** Роутер знает, когда знания устарели (каталог/память; граф узлов стабилен — редко), и ПРЕДУПРЕЖДАЕТ, а не работает уверенно по старью. Граф+каталог делаются из реестра и обновляются сами, НО авто-обновление может не сработать/отстать (ручная правка, сбой хука). Размечать по устаревшему каталогу = посоветовать удалённый инструмент / не увидеть новый («уверенно-неправильно» — худший случай). **Механизм:** проверка «дата каталога/памяти против даты последней правки реестра»; реестр новее → «данные могли устареть, перестраиваю/предупреждаю» + не падает (работает с пометкой) + по возможности сам дёргает пересборку. Страховочная сетка к авто-обновлению (уже подвязано в хук post-commit). Дёшево (проверка дат), служит доверию к роутеру.

### Группа 4 — Умения роутера (все ✅, решены ранее, сведено)
- **4.1 ✅ Понять задачу (классификация).** Читает цель+план → тип задачи. Ядро уже есть (классификатор `router-classifier.mjs`, Sonnet 4.6).
- **4.2 ✅ Подобрать специалиста или честно «не нужен / не найден».** Механизм — апгрейженный 1.1 (граф узлов → каталог → модель). Два вида «без скила»: «не нужен» = закрытый список тривиальных шагов; «не найден» = СТОП (D15/D22/D26). Усилено 4.4 (вместо «не найден→делай без скила» роутер сперва переспросит).
- **4.3 ✅ Увидеть дыру — рекомендовать/разбить/добавить/заменить шаг** (вплоть до полной переделки плана с мотивацией). D34/D35. Граница: улучшает МЕТОД, цель — владельца (D29).
- **4.4 ✅ Уточняющий вопрос (от интервьюера).** Про метод спрашивает Claude (круг диалога); цель неясна → к владельцу. Только если ответ меняет выбор скила. Потолок кругов. Затыкает лазейку «расплывчатый шаг → без скила». D39.
- **4.5 ✅ Спорить с Claude.** Круги с нумерацией + потолок ~3/пункт → авто-эскалация владельцу. D34.
- **4.6 ✅ Объяснить простым русским.** Каждый совет/правка с причиной «почему». R-COMM. Питает трассу 5.1.

### Группа 5 — Качество и честность
- **5.1 ✅ Видимая трасса решения (⭐ сердце «крутить роутер»).** Не вердикт, а вердикт + ход мыслей: каких кандидатов рассматривал (граф узлов), кого отбросил и за что, почему выбрал этого под ЭТУ задачу, уверенность, на чём основался (граф/каталог/память/прецедент). **Зачем:** владелец хочет крутить роутер (Claude крутить трудно) — но нельзя крутить то, чего не видишь. Трасса = приборная панель: видно ГДЕ ошибка (плохое описание узла → чинить описание; кривое ребро → поправить связь; устаревшие данные → пересобрать 3.6; слабое рассуждение → подкрутить инструкцию/модель). Без трассы «роутер ошибся» = чёрный ящик. Кормит оценщика (оценивает ход рассуждения, не только результат), расширяет 4.6 (зерно «почему» → полная версия). Зачаток уже есть — поле «рассмотренные альтернативы» в классификаторе. **Цена ≈ ноль** (модель и так рассуждает). **Форма:** в плане — компактно (выбран X; отброшен Y почему; уверенность — владелец видит сразу, D17); полная трасса — в журнале (оценщик/разбор) и по требованию/на спорных (принцип 6.2).
- **5.2 ✅ Право воздержаться (⭐).** При низкой уверенности роутер НЕ угадывает: сперва спрашивает Claude (4.4, дёшево), если туман или про ЦЕЛЬ → эскалация владельцу. **Зачем:** угадывающий роутер опасен — уверенно ткнёт не тот скил, судья пропустит (всё «согласовано»), на выходе брак; «не уверен → тихо ошибся» превращается в «не уверен → переспросил». Особенно про близнецов (не может решить кто лучше → честнее спросить, чем монетка). Затыкает и лазейку обмана (расплывчато → низкая уверенность → переспрос, стык 5.3). **Настройка:** порог уверенности = РУЧКА ВЛАДЕЛЬЦА (высокий → душнит; низкий → угадывает), старт осторожный, крутим по оценщику. Воздержание идёт сперва по дешёвому пути (спросить Claude), владельца дёргает только при нужде; потолок кругов держит. **Цена:** иногда +один круг — дешевле, чем переделывать брак.
- **5.3 ✅ Подозрительность к расплывчатому = НЮХ, запускает интервьюера (4.4/D39).** Размытая/обтекаемая/слишком общая формулировка шага = КРАСНЫЙ ФЛАГ, а не повод «скил не нашёл → делай без скила». **Это закрывает дыру обмана** (Claude мутно формулирует шаг → роутер не матчит скил → «честно» пропускает). Анти-обманная тройка: **5.3 нюх** (учуял туман) + **4.4/D39 интервьюер** (переспросил «что конкретно делаешь?») + **5.2 страховка** (не уверен → не угадывает). Нюх без интервьюера бесполезен, интервьюер без нюха душнит — работают ТОЛЬКО в паре. Признаки тумана: «разобраться»/«сделать всё нужное», нет глагола+объекта, шаг слишком большой → пометка «подозрительно» → вопрос (4.4); всё ещё мутно → к владельцу. Часто размытый шаг = раздутый объём → стык с D29 (план↔просьба). **Подозрение ≠ блок** — запускает ВОПРОС, не стоп (нет ложных стопов; закрытый список тривиальных шагов D15 защищает простое от придирок). Цена минимальна.
- **5.4 ✅ Самопроверка перед выдачей — СЛИТА с 1.2 в единый приём «думай вариантами и перепроверь себя».** Перед отдачей роутер делает один внутренний «второй взгляд»: «не забыл скил? нет варианта лучше? не противоречу плану?» → правится ДО того, как Claude увидит. Ловит глупые промахи (очевидный скил пропущен, выбран близнец похуже) до ухода в работу. **Объединение с 1.2:** 1.2 = «придумай варианты на входе, выбери лучший»; 5.4 = «перечитай свой готовый ответ, поймай свою ошибку» → один приём, две фазы (варианты при выборе + контрольный взгляд перед выдачей). Не плодим две почти одинаковые сущности. Цена ≈ ноль (тот же вызов); на грубом фильтре не включается.
- **5.5 ✅ Согласованность плана ЦЕЛИКОМ.** Роутер смотрит план как единое, не поштучно: нет конфликтующих инструментов на соседних шагах (правило «два инструмента на одну задачу нельзя»), нет дублей, шаги в разумном порядке без дыр (цепочку роутер СОБИРАЕТ рассуждением под задачу — ОВ-Д1, без хранимых рецептов). **Зачем:** поштучная разметка даёт план, где каждый шаг ок, а целое кривое (шаг 2 инструмент A, шаг 4 конфликтующий B; дубли; есть проверенная связка, а слепил по кускам). **Как:** конфликты — по рёбрам графа узлов (3.2) по всему плану; цепочка собирается рассуждением под задачу (ОВ-Д1), не тянется рецептом; перестроил → объясняет (трасса 5.1). **Цена:** второй проход по плану; оправдан на реальных, на тривиале пропуск.

### Группа 6 — Деньги
- **6.1 ✅ Чувство стоимости.** Роутер знает цену каждого инструмента (вызовы ИИ, квоты MCP) + остаток бюджета → при равном качестве выбирает дешевле, предупреждает о дорогом, КРИЧИТ при нуле (D27). Среди близнецов цена — разделитель. **Жёсткая граница: цена НЕ важнее правильности.** Цена = (а) разделитель между РАВНОЦЕННЫМИ кандидатами, (б) предупреждение, (в) крик при нуле — НЕ глушилка, режущая нужный инструмент ради экономии. Сначала «подойдёт ли», потом «сколько стоит». Ценник — в каталоге 3.1; размер бюджета — ручка владельца.
- **6.2 ✅ Сквозной принцип «выжимка, не свалка» — с ИСКЛЮЧЕНИЕМ для графа.** Роутеру дают не «всё сразу», а выжимку/ссылку, тянут по необходимости. **ИСКЛЮЧЕНИЕ (решение владельца 2026-06-02): граф+каталог узлов — НЕ выжимка, даются на 100%** (см. «ПОЛНЫЙ ГРАФ — РЕШЕНИЕ ВЛАДЕЛЬЦА»); 6.2 к ним НЕ применяется — их «бесплатность» держит кэш, а не урезание. Принцип остаётся для: выжимка прогресса (2.3), компактная трасса в плане / полная в журнале (5.1), мало примеров (3.4). Каждое «дай ему ещё» (кроме графа) = больше токенов = больше денег.

---

## ИТОГ: снаряжение роутера — все 6 групп закрыты (2026-06-01)

6 групп / 24 пункта разобраны и зафиксированы. Ключевые развороты сессии: **1.1** — выбор скила по смыслу+модели, ключевые слова сняты (деградируют на 200 узлах, не различают близнецов); **3.1+3.2+3.3** — два слоя «граф УЗЛОВ (из реестра, стабильный) → каталог», граф ПРОЕКТА (graphify) отдельно и волатильно; **3.4+3.5** — обучение роутера только по одобрению владельца, доставка через очередь → `/brain-retro` → STATUS; **5.1** — видимая трасса (сердце «крутить роутер»); **5.2+5.3+4.4** — анти-обманная тройка (воздержание + нюх + интервьюер); **5.4** слит с 1.2; **6.1** — цена как разделитель, не глушилка. Дальше по дорожной карте D28: формальная спека через `writing-plans`.

---

## КРИТИЧЕСКИЙ РАЗБОР (свежий взгляд, брейнсторм 2026-06-01) — дыры + пред-спека вопросы

> Брейнсторм «посмотри на роутера критично, найди дыры, что мешает». Найдено 7 дыр. Призрачность: 🔴 реальный / 🟡 средний / 🟢 почти призрак. Разбираем по одной; решения фиксируем здесь. Список дыр: #1 турникет, #2 фолбэк=выброшенный механизм, #3 самоослепление петли обучения, #4 кто сторожит оценщика, #5 граница метод/цель течёт, #6 провал шага не перемаршрутизирует, #7 двойной гейт = театр.

- **ПРЕД-СПЕКА ВОПРОС (из дыры #1 «турникет»). РЕШИТЬ ДО СПЕКИ. 🔴 реальный.** Сегодня вживую: сохранение 1 doc-файла = 8 ударов в заборы. Текущая дисциплина = ДЕСЯТОК хуков (белый список команд, «не на main», «прогони тесты», судья-по-инструменту, лимит обходов, рекомендация цепочки…). **Но НОВАЯ конструкция (план→роутер→судья→владелец) — это И ЕСТЬ механизм дисциплины.** «Фаст-лейн поверх старых хуков» = турникет поверх турникета (ОТВЕРГНУТО владельцем). Правильно — **новое ЗАМЕНЯЕТ старый зоопарк: один умный судья вместо десяти тупых заборов** (меньше трения И цельнее дисциплина). **Рекомендация — вариант B (заменить дисциплину, безопасность оставить), одобрено владельцем как направление:**
  - **🟥 ДИСЦИПЛИНА → в новую конструкцию (старые хуки снимаются):** белый список команд, «не на main», «прогони тесты перед коммитом», судья-по-инструменту, лимит обходов, рекомендация цепочки. «Правильно ли делаешь работу» — новый судья делает в одном месте и лучше.
  - **🟩 БЕЗОПАСНОСТЬ → остаётся (другая работа):** поиск секретов, фильтр ПДн, защита нормативки/памяти от записи, крик при нуле бюджета, защита системных путей. Жёсткие предохранители, нужны независимо от роутера.
  - **Переход:** не разом — новое сперва в тихом режиме (D28) доказывает себя → старые дисциплинарные хуки снимаем ПО ОДНОМУ; до тех пор временно сосуществуют (турникет временный, с понятным концом).
  - **Финализировать при спеке:** точные списки 🟥/🟩 (какой именно хук куда).
- **#2 ✅ ЗАКРЫТА (запасной режим = выброшенный механизм). 🟡 средний.** При сбое ИИ код-фолбэк скатывается в ключевые слова (отвергнуты в 1.1), и молча — система слабее всего, когда выглядит нормально. **Решение — взяты ТОЛЬКО пункты 1 и 4 (решение владельца):** (1) честный флаг «⚠️ ИИ недоступен, разметка грубая — проверь сам» (падать ВИДИМО, не тихо); (4) различать причину сбоя — деньги кончились → ГРОМКИЙ крик «пополни» (D27); сеть/таймаут → короткий повтор. **ОТБРОШЕНО:** п.2 «стоп + спросить владельца» и п.3 «последнее-хорошее из памяти» — НЕ берём.
- **#3 ✅ ЗАКРЫТА (самоослепление петли обучения). 🟡 средний (пока память пустая — 🟢 спит).** Узел, ни разу не пробованный, не показывает успех → не попадает в «хорошие» → атрофируется; любимчики закрепляются («богатый богатеет»). **Решение — ручка «% разведки» (по умолчанию 0, ВЫКЛючена):** слот в логике выбора + счётчик использования узлов + предохранители (только близкие кандидаты / НЕ на опасном-необратимом). **КОРРЕКЦИЯ ВЛАДЕЛЬЦА: разведка — НЕ просто пометка, а роутер СПРАШИВАЕТ РАЗРЕШЕНИЕ** («хочу попробовать #95 вместо #49 — вот обоснование и риск») → **владелец решает.** Оценщик логирует пробы отдельно (окупилось/нет). **Предусмотреть СЕЙЧАС:** слот + ручка (0%) + счётчик использования + витрина проб у оценщика; включить позже, когда наполнится память. Острота зависит от наполнения 3.4/3.5.
- **#4 ✅ ЗАКРЫТА (кто сторожит оценщика). 🟢 почти призрак.** Регресс «кто сторожит сторожа» уже перерезан: владелец одобряет всё в память/примеры (3.4/3.5), разведку (#3), крутит ручки роутера/судьи руками (Д1/D4) — оценщик только СОВЕТУЕТ, не автомат; последний сторож = владелец. **Остаток (владелец решает по ПОДАЧЕ оценщика) — берём ТОЛЬКО пункт 1:** оценщик показывает СЫРЫЕ факты, а не только вердикт («вот 5 случаев, вот что реально произошло») → владелец судит реальность, а не мнение. **ОТБРОШЕНО:** п.2 «золотой набор эталонов» — НЕ берём.
- **#5 ✅ ЗАКРЫТА ЦЕЛИКОМ (граница метод/цель течёт). 🔴 реальный.** «Добавить шаг» бывает и методом, и ростом объёма; роутер может назвать расширение объёма «улучшением метода» и тихо вырастить цель (форма обратной связи → CRM-фича). Болезнь №1 ИИ — услужливо сделать больше просьбы. **Решение (всё):** (1) роутер ДЕЛИТ план на «КАК сделать просьбу» (его право) и «СВЕРХ просьбы» (территория владельца, отдельным списком); (2) показывает «было/стало» словами владельца («просил форму → план разросся до форма+капча+база+письма+A/B — подтверждаешь?»); (3) всё сверх буквальной просьбы → требует ДА владельца; (4) правило сомнения: не ясно метод или рост → считать РОСТОМ → спросить. Объём растёт только вверх по согласию владельца. Стык с D29 (план↔просьба).
- **#6 ✅ ЗАКРЫТА (провал шага не перемаршрутизирует). 🟡 средний, чинится одной строчкой.** В потоке роутер→Claude→судья нет триггера на провал/сюрприз → либо пилю не то, либо тупик с судьёй (отклонился от плана, а план уже неверный). **Решение (уточнение владельца — СХЕМА НЕ МЕНЯЕТСЯ, меняется только ТРИГГЕР):** триггер перепланирования = НАХОДКА/провал (не новый промпт). Claude возвращается к роутеру **не с «оно сломалось», а со СКОРРЕКТИРОВАННЫМ планом** (находка + обоснование корректировки) — ровно как при первичном написании плана; роутер смотрит, корректирует если считает нужным (D24/D35); дальше по ОСНОВНОЙ схеме (судья-ворота → продолжаем). Один механизм, не новый путь. Разблокирует тупик с судьёй (отклонение узаконено перепланированием). Предохранитель: потолок перезаходов на одном месте → к владельцу (как D34).
- **#7 ✅ СНЯТА (двойной гейт = «театр» — оказалась НЕДОПОНИМАНИЕМ потока, НЕ дыра).** Правильный поток (D30 + уточнение владельца): план «роутер+Claude» или «роутер+Claude+владелец» → судья; согласен → пропуск; НЕ согласен → эскалирует ЗАМЕЧАНИЯ владельцу; владелец решает — доработать ЧАСТЬ замечаний / ВСЕ / утвердить как есть (переехать судью). Судья = поставщик замечаний, не штамп и не самоблокиратор; финал — владелец. **Сохранены два кусочка:** (1) замечания судьи — по ВНЕШНИМ якорям (просьба владельца + факт), чтобы по существу, а не пересказ доводов роутера; (2) уточнение к D30 — гранулярная реакция владельца (часть / все / как есть). **Остаток** (судья разделит общую слепоту → план тихо пройдёт) — НЕ новый, уже признан в D30, ловится взглядом владельца (D17) + оценщиком.

### ИТОГ критического разбора (все 7 дыр)
- **#1 турникет** 🔴 → ПРЕД-СПЕКА вопрос: новая конструкция ЗАМЕНЯЕТ старый зоопарк дисциплинарных хуков (вариант B), безопасность остаётся; переход через тихий режим.
- **#2 фолбэк** 🟡 → закрыта пунктами 1+4 (честный флаг «туплю» + различать причину: деньги→крик / сеть→повтор).
- **#3 самоослепление** 🟡/🟢 → ручка «% разведки» (0 по умолчанию), проба = вопрос владельцу с обоснованием+риском.
- **#4 кто сторожит оценщика** 🟢 → почти призрак; добито пунктом 1 (оценщик показывает сырые факты).
- **#5 метод/цель течёт** 🔴 → закрыта целиком (делёж «как / сверх просьбы», «было/стало», рост только с да владельца).
- **#6 провал не перемаршрутизирует** 🟡 → триггер = находка (не промпт), Claude несёт скорректированный план, схема та же.
- **#7 двойной гейт театр** → СНЯТА (недопонимание потока).

## ПРИНЦИПЫ (поправки владельца 2026-06-02)

- **ПОРТАТИВНОСТЬ (важно для ВСЕЙ конструкции).** Судья — и весь аппарат — строится **под МНОГО проектов**, не под один. **Никакого project-specific хардкода.** В частности: **зашитой «карты критического» НЕТ** — это «баран в стойле». Судья УМНЫЙ: **рассуждает**, что критично/фатально, из цели+контекста + общий интеллект, а не лезет в список. Та же логика, что убила ключевые слова (1.1) и канонические цепочки (ОВ-Д1): хардкод не переносится и умирает при росте. Что project-specific нужно — берётся ЖИВЬЁМ из реального состояния, не вшивается.
- **R-COMM-2 (модель поведения Claude, глобально).** НЕ прилетать с готовым решением («моя ставка X») — это скрывает развилку и ход мысли, лишает владельца выбора пути. Надо: **показывать развилку + рассуждение, путь выбирает владелец.** Прозрачность важнее скорости вывода.

## СУДЬЯ — направление доработки (МОДЕЛЬ, не финал, 2026-06-02)

> ⏳ Владелец задал направление для будущей глубокой проработки судьи. **Конечных решений НЕТ — это рабочая модель.** «Пилим судью дальше» в отдельной фазе.

- **Вход судьи = ТОЛЬКО цель/контекст задачи + план со скилами.** БЕЗ рассуждений/спора роутер↔Claude и БЕЗ трассы 5.1. **Причина:** увидев ваши рассуждения, судья СВАЛИВАЕТСЯ в вашу логику → теряет независимость. Слепота к рассуждениям = условие независимости (уточняет #7 «судить по внешним якорям», не противоречит).
- **Работа судьи = ловить ГРУБЫЕ/ФАТАЛЬНЫЕ ошибки** (что убьёт задачу), НЕ полировать качество. Качество — уровень Claude+роутер+владелец, не судьи.
- **Роль-разделение (НЕ конфликт):** судья СЛЕП к рассуждениям (независимый детектор катастроф); ОЦЕНЩИК видит ВСЁ постфактум (спор, трасса, результат) для калибровки. Трасса 5.1 — для владельца+оценщика, НЕ для судьи.
- **Предложение Claude (на подумать):** границу «фатальное vs качество» резать по ПОСЛЕДСТВИЮ, не по элегантности — судья флагует необратимое/дорогое (потеря данных / дыра безопасности / ошибка в деньгах / утечка ПДн / ломает прод / план вообще не про цель), а не «можно красивее». Кандидаты-вопросы судье: (1) план реально служит цели (не та проблема)? (2) катастрофический/необратимый риск? (3) [ОТКРЫТО] опасно ли недо-проработан?
- **ОТКРЫТО (владелец не решил):** ~~судить ли частично «уровень проработки»~~ → ✅ РЕШЕНО блоком A (A3-замечание); точная граница «грубо vs качество» — блок только фатальное, качество — совет.

### Блок A — Функции судьи (✅ 2026-06-02)
- **A1. Ворота на ПЛАН** — вкл. ПЕРЕМАРШРУТИЗИРОВАННЫЙ план (#6: после находки скорректированный план СНОВА через ворота — обязательно). Согласен → пропуск; нет → замечания владельцу (часть/все/как есть, D30).
- **A2. Надзор на ИСПОЛНЕНИИ до конца** — не отхожу от плана; все звенья цепочки пройдены (не схлопнуты, ОВ-Д1); назначенные скилы взяты; финальная сверка «сделано = плану».
- **A3. Сила судьи в ДВУХ режимах:**
  - **A3-блок — ТОЛЬКО ФАТАЛЬНОЕ/критическое** (по последствию: данные/безопасность/деньги/ПДн/прод/«не про цель»). Останавливает, мимо не пройдёт.
  - **A3-замечание — свежий НЕЗАВИСИМЫЙ взгляд на качество плана и скилов/цепочек** → СОВЕТ владельцу (не блок), владелец триажит. Не штамп (судья слеп к доводам B1 → своя голова), не турникет (совет, не стена), ценность свежего взгляда не теряется. Граница: поднимает, когда видит СТОЯЩЕЕ, не стиль-придирки. Отлично от оценщика (тот постфактум).
- **Чего НЕ делает (анти-турникет):** не судит работу роутера (это оценщик); не придумывает план/скилы (это роутер); не полирует качество ПРИНУДИТЕЛЬНО (блок — только фатальное, качество — совет).
- **A0. Кто отдаёт план судье — СТРУКТУРНО, никто «не несёт» (✅ 2026-06-02, вар. 3).** Как только достигнуто состояние «план согласован и заморожен» (роутер+Claude договорились ИЛИ роутер+владелец+Claude после арбитража) — план лежит в известном месте, **ворота-хук срабатывают сами** и читают его оттуда (как router-gate / verify-before-push сегодня). **Причина:** подсудный (Claude) не должен владеть дверью в зал суда — иначе пропустит/подделает/отдаст не тот план (память: «сигнал, который пишет сам подсудный, подделывается тривиально»). Независимость судьи (D30) держится на том, что его НЕ зовут по желанию — он включается автоматически от состояния. Отклонены: вар.1 (Claude сам отдаёт — самый дырявый), вар.2 (роутер отдаёт — он соавтор, не нейтрал).
- **A0b. Терминальная метка обмена роутер↔Claude = «заморожен» (✅ 2026-06-02, зерно №4 ещё раз).** Зерно метода №4 (чёткая короткая форма-вердикт) применяется ВТОРОЙ раз — не как форма диалога (бинарность убила бы переговоры), а как **лёгкая метка КОНЦА обмена**: `СОГЛАСОВАНО` / `СПОР→ВЛАДЕЛЕЦ` (два значения, не тяжёлый вердикт). Эта же метка физически определяет состояние «план заморожен». **Один маркер закрывает два места:** (1) чистый триггер авто-эскалации по потолку кругов (D34) — без него «спорят ещё или сошлись?» размыто; (2) то самое «заморожен», от которого срабатывают автоворота A0. Без явной метки и D34, и A0 висят на «как-то само поймём» — это дыра, метка её закрывает.

### СНАРЯЖЕНИЕ СУДЬИ — методы анализа (⏳ в работе, 2026-06-02)
> Идём по методам анализа, что уже есть в мозге (аудит/риски), по одному, с честной оценкой. Берём ЗЕРНО метода, не данные (портативность). Решения по одному.

**Разобрано:**
- **Метод №1 — STRIDE-линза (#72 threat-model)** — ❌ В АУТ. Охранные категории (подмена/утечка/захват прав) мажут мимо нелибезопасных планов; на примере «чистка партиций» STRIDE не видит реального фатального «DROP не той → потеря данных». Ценное зерно (чек-лист вместо «на глаз») перекрывается методом №2.
- **Гибрид №2+№3 — ловля фатального риска у судьи (✅ ФИКС, только судья; роутер пока НЕ трогаем).** Один проход в три шага по порядку:
  1. **Где план сломается?** (пессимист, зерно №3 Trail of Bits — хакерскую часть выбросили). Не «выглядит ок», а «где слабое звено, что если шаг не пройдёт».
  2. **Если сломается — сильно будет больно?** (зерно №2 risk-assessment / #73). Косметика или потеря данных / упавший прод. «Насколько больно» судья оценивает сам по смыслу задачи, без зашитой таблицы (портативно).
  3. **Можно откатить назад?** (необратимость, №2).
  - Вывод: **больно + откатить нельзя → стоп.** Пессимист (шаг 1) находит слабое место, шаги 2–3 решают, стоп это или пропуск.
- **Метод №4 — форма вердикта go/no-go (#73 security-go-live)** — ✅ БЕРЁМ у судьи ЦЕЛИКОМ. Это не «как думать», а «как ОТВЕЧАТЬ»: жёсткая короткая форма вместо размытого абзаца. Три ящика ложатся ровно на блок A: **GO** (A1 пропуск) / **NO-GO + категория** (A3-блок) / **GO + замечание** (A3-замечание). Зачем нужна: машине-воротам нужен однозначный сигнал (как `task_type` у классификатора — чинили из-за размытости); форма заставляет судью определиться. Не конкурент №2/№3 (те — «как найти», это — «как сказать»), лежит в другом слое. Закрывает «как судья технически отдаёт решение воротам».
  - **Нести ли форму в общение роутер↔Claude / на передачу плана?** Честно: **в диалог роутер↔Claude — НЕТ.** Там не вердикт, а переговоры (D35/D36: «предложение→причина→Claude согласен/нет»), бинарный go/no-go исказил бы живой спор. **На стадию передачи плана судье — частично:** сам факт «план заморожен и готов» можно пометить структурно, но это не вердикт, а флаг готовности. Не размазывать форму туда, где она не вердикт.

**Качество ПЛАНА — мерило для A3-замечания (✅ ФИКС, 2026-06-02; из скила write-plans).** Риск закрыт гибридом 2+3, но КАЧЕСТВО само по себе ничем не мерилось — «свежий взгляд» без мерила пуст. Берём мерило из write-plans (уже используем). Хороший план = три вещи: (1) каждый шаг — **проверяемый результат** («сделано и проверено»), не размытое действие; (2) у каждого шага есть **«зачем»**; (3) разделено **«что просили» vs «сверх просьбы»**. Судья свежим взглядом сверяет план по трём пунктам → видит стоящий пробел → **замечание владельцу (совет, НЕ стоп)**, владелец решает. **Граница (судья ≠ роутер):** роутер/Claude ОБЯЗАНЫ написать план по этому стандарту (enforce при создании); судья только СВЕРЯЕТ и СОВЕТУЕТ по тому же списку, не блокирует, поднимает лишь стоящее, не придирки к стилю.

**Качество СКИЛОВ — три sanity-вопроса для A3-замечания (✅ ФИКС, 2026-06-02; мерило из стандарта выбора скила у роутера).** По аналогии с качеством плана: свежий взгляд + мерило + СОВЕТ, не перевыбор. Судья сверяет разметку скилов по трём простым вопросам: (1) **скил подходит к шагу?** (на «написать тест» повесили скил про UI-дизайн → замечание); (2) **не пусто ли там, где специалист явно нужен?** (содержательный шаг без скила → пробел); (3) **не навалено ли лишнего?** (на тривиальный шаг тяжёлая цепочка из 5 скилов → перебор). Вывод = **замечание владельцу (совет), не стоп.** **Граница (судья ≠ роутер):** роутер ВЫБИРАЕТ скилы (и может переделать); судья только СВЕРЯЕТ по трём вопросам и СОВЕТУЕТ, сам не перевыбирает. Если скил уводит задачу в катастрофу — это уже риск-путь (стоп, гибрид 2+3), а не качество.
  - **Судье для этих трёх вопросов НУЖЕН свежий каталог/граф СКИЛОВ (✅ ФИКС).** Без него «не пусто ли где нужен» и «подходит ли» повисают, и судья начнёт выдумывать несуществующие скилы. Берём **тот же граф УЗЛОВ (реестр скилов/MCP/агентов), что и роутер** (D36 п.2) — НЕ граф проекта (graphify, волатильный), а стабильный реестр узлов. **Только на чтение.** Отдельный каталог не строим — общий с роутером.

**БЛОКИРОВКА работы Claude на исполнении (✅ ФИКС, 2026-06-02; по D10/D11/D12/D26).** Судья смотрит каждое действие (D10); жёсткий стоп — ТОЛЬКО фатальное:
1. **Claude отходит от утверждённого плана** (делает не то, что согласовано).
2. **Действие → «больно + необратимо»** (гибрид 2+3 на реальной команде, напр. живой `DROP`).
3. **Схлопнул цепочку молча / не взял назначенный скил** (звенья обязательны, A2).
4. **Внешний read-вызов (read-only MCP) не по плану** (D26 — внешнее чтение идёт по плану).
- **НЕ стоп:** локальное чтение файла — свободно, но **логируется + показывается владельцу + страж секретов** (D26 вар.2 / D18); качество — только совет. Пере-блокировки чтением не будет именно из-за этого разделения (отдельная оговорка не нужна).
- **Механика:** хук-ворота возвращают «стоп», Claude дальше не идёт.
- **После блока → владельцу** (снимает / правит / подтверждает). **Claude сам блок НЕ снимает** (подсудный не открывает себе дверь — логика A0).

**РИСК-ФИЛЬТР У РОУТЕРА — ✅ ФИКС (2026-06-02, бывш. W1+W2 объединены).**
Роутер при сборке плана прогоняет **ту же тройку риска, что судья** — *где сломается → если сломается, больно? → откатимо?* — но **алгоритм переделан** под его роль автора:
- **Когда:** во время сборки плана (вплетено в размышление, не отдельный проход; цена ≈ ноль — тот же вызов).
- **Нашёл фатальное:** роутер **сначала ЧИНИТ сам** (добавь откат / выбери безопаснее / разбей / замени — D34/D35).
- **Не смог обезопасить:** тогда **флажок владельцу**.
- **Выход:** безопасный план (+ флажок на то, что не смог обезопасить). **Роутер НЕ блокирует** — блок только у судьи.
- **Порог эскалации:** рядовое чинит молча; владельцу — только фатальное И необезопашиваемое (чтоб не топить).
- **Пример:** «DROP старой партиции» → риск (не та / потеря данных / нет отката) → роутер ставит перед ним «бэкап → проверь → DROP», план безопасен, владельцу не лезет. Если безопасного пути нет в принципе → флажок «шаг необратим, подтверди».
- **Два слоя (защита-в-глубину):** дешёвый автор-фильтр спереди (роутер) + независимый судья сзади. **Условие: судью НЕ ослаблять** — «роутер проверил, судья расслабься» запрещено. Автор плохо видит свой косяк → роутер ловит очевидное, судья ловит слепые зоны.

### ПОРТРЕТ СУДЬИ — собрано вместе (✅ 2026-06-02, после разбора снаряжения)

**Кто он.** Независимый контролёр между «план готов» и «работа сделана». Не автор плана и не оценщик постфактум — он стоит на воротах в реальном времени.

**Что делает (функции).**
1. **Ворота на план.** Любой согласованный план проходит через него (даже если владелец уже участвовал). Согласен → пропуск; не согласен → замечание владельцу. Переделанный после находки план идёт через ворота СНОВА.
2. **Надзор на исполнении.** Следит, что Claude не отходит от плана, прошёл все звенья цепочки (не схлопнул), взял назначенные скилы; в конце сверяет «сделано = плану».
3. **Две силы:** жёсткий **стоп** — только за фатальное; **замечание владельцу** — за качество (совет, не стоп).

**Чем вооружён.**
- **Ловля фатального риска (гибрид):** 1) где план сломается? 2) если сломается — сильно больно? 3) можно откатить? → больно + откатить нельзя = стоп.
- **Форма вердикта:** коротко и однозначно — пропуск / стоп+причина / пропуск+замечание (не размытый абзац).
- **Мерило качества плана** (из write-plans): каждый шаг — проверяемый результат; у шага есть «зачем»; разделено «что просили / сверх просьбы». → совет владельцу.
- **Проверка скилов** (3 вопроса): скил подходит к шагу? не пусто где нужен? не навалено лишнего? → совет владельцу.
- **Свежий каталог/граф скилов** (для проверки скилов) — тот же граф УЗЛОВ, что у роутера (не граф проекта), только на чтение; без него судья выдумывал бы несуществующие скилы.
- **Короткая память задачи** — помнит в пределах одной задачи, что уже снято/решено, чтобы не блокировать/не поднимать то же второй раз. Помнит вердикты, НЕ доводы (независимость цела).

**Как получает план.** Структурно: как только план «заморожен», ворота срабатывают сами и читают его. Никто «не несёт», подсудный дверь не контролирует.

**Когда жёстко стопает (только фатальное).** Отход от плана; действие «больно+необратимо»; молча схлопнул цепочку / не взял скил; внешний read-вызов не по плану. Локальное чтение — свободно (логируется + страж секретов). После блока — к владельцу, сам Claude блок не снимает.

**Чего НЕ делает.** Не выбирает план/скилы (это роутер). Не оценивает работу роутера для калибровки (это оценщик). Не блокирует за качество — только советует.

**Независимость.** Видит ТОЛЬКО цель/контекст + план со скилами. НЕ видит спор роутер↔Claude и рассуждения — иначе свалится в чужую логику и потеряет свежий взгляд.

### ДОРАБОТКИ ПОСЛЕ КРИТ-РАЗБОРА (✅ 2026-06-02, свежий взгляд)

- **П1. Короткая память задачи у судьи (✅ ФИКС).** Судья помнит в пределах одной задачи, что уже снято/решено → не блокирует/не поднимает то же второй раз (защита от петли). Помнит вердикты, не доводы — независимость цела. Симметрично памяти спора у роутера (D36).
- **П2. Решение владельца ПОСЛЕ судьи — финальное, не пере-судится (✅ ФИКС, формулировка владельца).** Когда судья эскалировал владельцу и владелец вынес решение — это **конец линии**, судья этот вердикт владельца обратно НЕ тащит. Петля владелец↔судья разрывается на решении владельца. (NB: это про owner-решение ПОСЛЕ судьи; план с участием владельца в споре роутер↔Claude ДО ворот судья по-прежнему перепроверяет, D30 — два разных момента.)
- **П4. Роутеру — канал обратной связи от оценщика (✅ ФИКС: СТРОИМ).** Оценщик постфактум знает, какой выбор сработал; этот сигнал возвращается роутеру, чтобы он со временем лучше различал «близнецов». **Строим механизм полностью.** Пользоваться им или калибровать руками — владелец решит **в процессе эксплуатации** (не отложено, не выкинуто — построено и доступно).
- **П3. Цена/скорость судьи — ✅ ФИКС (2026-06-02). Делать два:**
  - **A. Точная граница код/ИИ.** Код решает САМ (без модели): локальное чтение (D26), бесспорно тривиальные реплики (привет/ок/да-нет/уточнить слово), жёсткие запреты по чёрному списку (пути/секреты/опасные команды), механическая сверка фактов (взят ли скил / пройдены ли звенья / совпадает ли действие с планом), страж секретов. ИИ — только смысл: ловля риска (где сломается→больно→откатимо), качество плана и скилов, «план про цель ли», выбор/различение скилов. **ВАЖНО (дыра, закрыта):** код НЕ вправе свалить весь разговор в «тривиал→свободно» — иначе при содержательном рассуждении брейншторм/интервьюер не вызовутся (живой пример: эта сессия). Решение «тривиал vs содержательное» — это смысл → его принимает **модель/классификатор** (D33 а/б), не код-список; при содержательном → обязателен мыслительный скил (D32) → судья сторожит вызов. **Риск:** грань тривиал↔содержательное ошибается в обе стороны → порог тюнить.
  - **B. Ворота = ОДИН вызов на весь план, не по вызову на каждый шаг.** На воротах судья читает план целиком и даёт один вердикт. На исполнении модель трогает только мутации/внешние вызовы, прошедшие код-фильтр. Без этого правила легко скатиться в вызов модели на каждый шаг → дорого.
  - Остальное (память-кэш П1, короткий вход, короткая форма №4) — уже в дизайне.

### ДИСЦИПЛИНА СУДЬИ — ✅ ЗАЛОЧЕНО (2026-06-02)

Судья — тоже ИИ, тоже халтурит. Главный риск — **штамповка** (написать «пропуск», не проверив; пропустить проще, чем вникать); реже — ленивый вердикт и пере-блок (придавлен «код-вперёд + только фатальное»). По образцу дисциплины роутера (не копия):
1. **Структурные слоты вердикта.** Судья обязан заполнить, что проверил: риск (где сломается / больно / откатимо), качество плана (3 пункта), скилы (3 вопроса). **Пустой слот = видимый красный флаг** — молча проштамповать «GO» нельзя.
2. **Механическая проверка вердикта (код).** «GO» с пустыми слотами рассуждения = невалидный вердикт, флаг.
3. **Оценщик судит судью постфактум (D31).** Проштамповал, фатальное прошло → оценщик ловит позже → владелец видит → крутит судью.
4. **Кто сторожит сторожа:** судья сторожит Claude; оценщик + владелец сторожат судью; владелец сверху — бесконечного круга нет.
- **Честно:** дисциплину нельзя убрать полностью (архитектурный пол — судья ИИ). Делаем халтуру ВИДИМОЙ + ПОЙМАННОЙ, не невозможной.
- **Нюанс памяти (П1):** память «что решено» — не повод не проверять ИЗМЕНИВШИЙСЯ план. План изменился → проверяй заново; память короткозамыкает только идентичные повторы.

### Блок H — Реакция владельца (✅ ЗАКРЫТО 2026-06-02)

**До владельца доходят две вещи:**
1. **СТОП** — судья остановил что-то опасное. Нужен ответ владельца.
2. **СОВЕТ** — замечание по качеству плана или скилов. Не останавливает, просто к сведению.

**Как владелец это видит (коротко, не простынёй):**
- **СТОП** — короткая карточка: что остановлено + почему (потеря данных / нельзя откатить / план не про то) одной фразой.
- **СОВЕТ** — список подсказок строкой каждая; показывается вместе с планом (владелец план и так видит), отдельно не дёргает.
- **Споры роутера и Claude** — в журнал по номерам, владельцу не шлём.

**Что владелец может ответить:**
- На СТОП: **снять** («пропускай») / **подтвердить** («стоп, переделать») / **сам поправить** («сделай вот так»).
- На СОВЕТ: принять / отклонить / отложить.

**Как ответ возвращается в работу:**
- Решение владельца после судьи — **окончательное, заново не пересудят** (П2). Снял стоп → работа идёт дальше.
- Если владелец **сам** решил (пропустить / своя правка) — финал, без повторной проверки. Если **отправил на переделку** — переделанный план идёт через ворота **заново**.

**Чтобы не заваливать владельца:** стопы редки (только опасное); советы — пачкой вместе с планом; споры — в журнал. По шагам не дёргаем.

### Блок I — Дыры судьи (✅ ЗАКРЫТО 2026-06-02, злой проход)

- **I-1. Уверенно-неправильный «пропуск» на необратимом — ОСТАТОК (архитектурный пол).** Дисциплина ловит ПУСТУЮ халтуру (пустой слот = флаг), но судья может заполнить все слоты, выглядеть прилежным и ошибиться по существу → валидатор/дисциплина молчат, оценщик заметит только постфактум (для необратимого поздно). **Пример (инцидент 29.05):** план «удалить старые партиции логов» → судья: «это логи, некритично» → но среди них `activity_log` = аудит-цепь 152-ФЗ → снос = необратимая порча. Слоты полные, прошёл. **Закрыть полностью нельзя** (судья — ИИ, уверенная ошибка возможна). **Смягчение (принято): Sonnet** на воротах (острее) + владелец видит план (D17) — на необратимом владелец и есть реальный ловец. Эшелоны Claude+роутер скоррелированы, надёжен только владелец.
- **I-2. Код-растяжка ловит совпадение по форме, не по смыслу — ✅ ЗАКРЫТО.** На исполнении код сверяет «действие = плану» и при совпадении пропускает без Sonnet — но код видит форму (та таблица/файл/глагол), не смысл команды. **Пример:** план «почистить старые записи из X» → действие `DELETE FROM X WHERE ...` со сломанным/потерянным `WHERE` → снесёт всю X; код видит «DELETE из X, как в плане» → совпало → пропуск, Sonnet не зван. Гейт благословлял ШАГ, не зная конкретной команды (она рождается на исполнении). **Фикс: разрушительные/необратимые команды (`rm`/`DROP`/`DELETE`/`TRUNCATE`/`migrate`/push в прод) → Sonnet смотрит на исполнении ДАЖЕ при совпадении** (конкретика — `WHERE`/цель/симлинк — может расходиться с допущением плана). Безопасные действия — по-прежнему только код. Цена мала (разрушительное редко).
- **I-3. Усталость владельца → штамп сверху — ⏸ В АУТ (докрутить по факту эксплуатации).** Владелец — верхний независимый эшелон; при потоке стопов/советов начнёт жать «снять/принять» не вникая → верхняя защита (и ловля I-1) отключается. Поведенческое, не код — заставить владельца думать нельзя. Смягчения (на будущее): меньше шума (стоп только фатальное; советы пачкой; только стоящее), стоп ≠ совет визуально, осознанное «снять» (причина+категория обязательны). **Не дорабатываем сейчас — настроим, когда увидим реальный поток в эксплуатации.**
- **I-4. Граф устарел → судья судит по старому — ⏸ В АУТ (владелец контролирует свежесть; 3.6 страхует).** Если узел убрали/сменили, а кэш графа не обновился (сбой хука) — судья сверяет скилы по устаревшему каталогу. Уже прикрыто «чувством свежести» (3.6: дата каталога vs дата реестра → предупреждает/пересобирает). Владелец: «такого не допущу, не зря строил». Не дорабатываем.
- **Призраки (все в аут, проверены):** (1) **подмена замороженного плана** — призрачность средняя-низкая, закрывается атомарной заморозкой + хэш плана при стройке; (2) **память П1 пропускает изменённое как идентичное** — высокая, хэш по полному содержимому, изменил символ → не идентично → пере-суд; (3) **судья подсмотрел рассуждения** — высокая, вход структурный, спор/рассуждения не кладём по конструкции. Все три — настоящие призраки, в аут.

### Блок D — Модель/движок судьи (✅ ЗАКРЫТО 2026-06-02)

Часть уже была (код-вперёд + один вызов на план, П3). Решение по модели:
- **Ворота на план = 1 вызов Sonnet** — делает разом риск + качество плана + скилы. Один раз на план, не на шаг.
- **Haiku НЕ используем.** Качество плана/скилов — самая тонкая часть, Haiku даёт плоское «вроде ок» → обнуляет свежий взгляд. Раз качество требует Sonnet, а гейт — один бандл-вызов, то весь вызов = Sonnet; слота для Haiku не остаётся, не порезав качество.
- **Исполнение:** код сверяет механику (скил взят / звенья цепочки не схлопнуты / действие=плану). **Совпало → пропуск ($0). Расхождение → зовётся Sonnet → блок или пропуск** (код ВИДИТ расхождение, но не СУДИТ — авто-блок дал бы тупые ложные стопы).
- **Sonnet на исполнении = на расхождении ИЛИ на разрушительной команде даже при совпадении** (правка по дыре I-2). Разрушительные: `rm`/`DROP`/`DELETE`/`TRUNCATE`/`migrate`/push в прод — у них конкретика (`WHERE`/цель/симлинк) может расходиться с допущением плана, код этого не видит → Sonnet смотрит. Безопасное совпавшее — код, $0.
- **Честный край:** если по ходу вскрылось новое и план больше не подходит к реальности (хоть действие «по плану») — это тоже расхождение (план↔реальность) → Sonnet.
- **Деньги:** держим РЕДКОСТЬЮ вызовов (план редок; на исполнении модель только на расхождении) + кэшем графа, а не дешёвой моделью. Качество не страдает.
- **Эшелоны (почему это безопасно):** для плохого исхода должны промахнуться разом роутер + Claude + судья + владелец не глянул (D30). NB честно: Claude и роутер — автор-сторона, скоррелированы (общие слепые зоны); реально независимы только судья + владелец. Поэтому судья на Sonnet, не режем.

### Блок C — Критерии судьи (✅ ЗАКРЫТО 2026-06-02)

Линейки: риск-тройка (где сломается → больно? → откатимо? → больно+необратимо = **стоп**); качество плана 3 пункта → **совет**; скилы 3 вопроса → **совет**; «план про цель ли» → не про цель = **стоп** (нет смысла исполнять не ту задачу).

**Граница «грубо vs качество» (была открыта) — режем ОБРАТИМОСТЬЮ; она же решает, куда падает сомнение:**
- **Необратимое** (откатить нельзя/дорого) → сомнение в сторону **СТОП** (назад не вернёшь — перестраховка).
- **Обратимое** (откатим легко) → сомнение в сторону **ПРОПУСК + совет** (поправим, незачем морозить работу).
- **Почему так:** ложный стоп на обратимом = трение (владелец снял); ложный пропуск необратимого = катастрофа. Строгость только там, где пути назад нет.
- **Примеры:** `DROP` без бэкапа / миграция на прод без отката → стоп (необратимо); скил похуже из близнецов / шаг без «зачем» / можно эффективнее → совет (обратимо).
- **Итог:** фатальное = тяжёлое последствие **И** необратимое → стоп; всё обратимое → максимум совет.

### Блок B — Вход судьи (✅ ЗАКРЫТО 2026-06-02)

Что физически кладём судье — структурой (слоты), не прозой: код механически проверяет, что слоты заполнены (часть дисциплины судьи) + вход короткий → дёшево/быстро.

**На воротах (весь план разом):**
1. **Цель** — 1–2 строки: что просил владелец (исходная просьба).
2. **План** — список шагов, на каждом: что делается (проверяемый исход) + зачем (строка) + назначенный скил (или «без скила — причина из закрытого списка»).
3. **Тип задачи** — ярлык классификатора (строгость: прод-код строже правки доки).
4. **Граф + каталог узлов — 100%** (решение владельца): полный, на чтение; даётся через кэш (не таскается каждый раз), обновляется при добавлении узла. Нужен, чтобы проверка скилов работала и судья не выдумывал.
5. **Память задачи** — что уже снято/решено (П1).

**На исполнении (другой вход):** одно конкретное действие (команда/правка) + его шаг плана — сверить «действие = плану». Не весь план заново.

**Чего НЕ кладём:** спор роутер↔Claude, рассуждения, весь чат, граф проекта (graphify). Независимость + дёшево.

## КАК ВЕРНУТЬСЯ К ЭТОЙ РАБОТЕ (якорь для любой сессии)

**Кодовая фраза владельца:** **«роутер-наставник»** (если владелец назовёт другую — заменить).
Когда владелец пишет эту фразу в любой сессии → прочитать **этот файл целиком** и продолжить с **открытых пунктов**.

**Открыто (на 2026-06-01):**
- **Л2** — ✅ ЗАКРЫТ (D29): сильная форма снята (план со-авторный), остаток закрыт проверкой «план ↔ просьба владельца».
- **В5** — ✅ ЗАКРЫТ (D34): итог+эскалации владельцу, круги спора в журнал с нумерацией, потолок ~3 круга/пункт → эскалация.
- **В6** — ✅ ЗАКРЫТ (D36, вар. B): роутер получает план+цель+самообъясняющие шаги; для диалога +память спора +свежий каталог инструментов.
- **СНАРЯЖЕНИЕ РОУТЕРА (6 групп / 24 пункта)** — ✅ ЗАКРЫТО (см. раздел «СНАРЯЖЕНИЕ РОУТЕРА» + «ИТОГ»). Что роутер должен иметь, чтобы работать правильно и эффективно.
- **КРИТИЧЕСКИЙ РАЗБОР (7 дыр)** — ✅ ЗАКРЫТ (см. раздел «КРИТИЧЕСКИЙ РАЗБОР» + «ИТОГ критического разбора»). #1 (пред-спека: новое заменяет старый зоопарк), #2/#3/#5/#6 закрыты решениями, #4 почти призрак, #7 снята. ПРЕД-СПЕКА вопрос #1 решить до спеки (точные списки 🟥/🟩 хуков).
- **3.4 / 3.5** — механизм строим, наполнять ли память/примеры — решение владельца отложено.
- **Умение роутера (ОВ-Д1 цепочки рассуждением / ОВ-Д2 заземление брейншторма)** — ✅ ЗАКРЫТО.
- **Дисциплина роутера** (слоты+валидатор+закрытый список пропусков+счётчик+постфактум) — ✅ ЗАЛОЧЕНО.
- **СУДЬЯ — функции + снаряжение + дисциплина** — ✅ ЗАКРЫТО (2026-06-02). Блок A (функции A0/A0b/A1/A2/A3-блок/A3-замечание); снаряжение (гибрид риска 2+3, форма go/no-go №4, мерило качества плана, 3 вопроса по скилам, каталог/граф узлов, память задачи); крит-разбор П1/П2/П3/П4; оптимизация (граница код/ИИ + ворота одним вызовом); ДИСЦИПЛИНА СУДЬИ. Портрет собран («ПОРТРЕТ СУДЬИ»).
- **СУДЬЯ — B/C/D закрыты (2026-06-02):** вход B (граф+каталог 100%), критерии C (граница по обратимости), модель D (Sonnet на воротах + код-сверка→Sonnet на расхождении, Haiku не используем). Независимость E и деньги G — по сути покрыты (E в портрете, G в D/П3).
- **СУДЬЯ — H и I закрыты (2026-06-02):** H (реакция владельца — стоп/совет, ответы, объём); I (дыры: I-1 остаток-пол смягчён Sonnet+владелец; I-2 закрыто — разрушительное→Sonnet на исполнении; I-3 усталость владельца в аут; I-4 устаревший граф в аут; 3 призрака в аут). **СУДЬЯ ПРОЙДЕН ПОЛНОСТЬЮ по карте A–I.**
- **Далее:** формальная спека через `writing-plans` (D28), затем стройка по этапам.
- **Далее** — формальная спека через `writing-plans` (D28 шаг 1), затем стройка по этапам D28.

**Закрыто:** D1–D28 + OQ1–OQ7 + R-COMM + Q-GRAPH (см. выше по файлу). Модель в основе: «без плана нет действия» (D11/D12), роутер=наставник (D23–D25), судья всеобъемлющий с кодом-вперёд (D10/D21), два вида «без скила» (D15/D22/D26), сбой ИИ = деградация+крик про деньги (D27).
