# Машина 3 (Роутер-наставник) — форма сборки + решение мины K4 — дизайн

**Кодовая фраза возобновления:** `роутер-наставник машина 3`

**Статус:** дизайн одобрен владельцем 2026-06-04 (brainstorming). Это НЕ полный дизайн Машины 3 — полное снаряжение роутера уже зафиксировано в `2026-06-01-router-discipline-plan-anchor-design-notes.md` (6 групп / 24 пункта) и в мастер-карте `2026-06-03-router-mentor-master-roadmap.md` §«МАШИНА 3». Этот документ фиксирует ДВЕ вещи, решённые после сборки Машины 2: (1) разрешение мины K4, (2) разбивку Машины 3 на под-планы и порядок сборки.

**На чём стоит:** Машина 1 (фундамент, собрана) + Машина 2 (стена + замок плана + две печати + закрытая дверь, собрана 2026-06-04, коммиты `599dca15`/`8d9ca65c`/`cfbfd9c6`/`ec4733f7`).

---

## 🚨🔴 K5 → МАШИНА 4 (СУДЬЯ, ГЕЙТ-2) — НЕ ПРОПУСТИТЬ ПРИ СБОРКЕ СУДЬИ. БЕЗ ЭТОГО ВСЁ РУШИТСЯ.

> **ПРАВИЛО СУДЬИ №2 — записано отдельным аварийным блоком СПЕЦИАЛЬНО, чтобы при сборке Машины 4 это нельзя было забыть. При написании чертежа Машины 4 этот контракт ОБЯЗАН попасть в её аварийный блок (как K1–K4 в чертеже Машины 2).**
>
> **Судья судит ПЛАН — а план это БУДУЩЕЕ, ничего ещё не исполнено.** Поэтому:
> 1. Судья проверяет, что каждый шаг-исход **объявляет конкретный проверяемый КРИТЕРИЙ приёмки** («приёмка: тест Y проходит» / «баланс сходится до копейки»), и оценивает **наличие + конкретность критерия** — да/нет.
> 2. Судья **НИКОГДА не трактует план как уже выполненный.** Слова «сделано»/«проверено» в тексте плана судья читать как ФАКТ **не имеет права** (план — будущее).
> 3. Реальный статус «проверено» ставит **только рантайм-сентинел при исполнении** (Машина 5: настоящий GREEN + мутация; надзор A2) — ПОСЛЕ и НЕЗАВИСИМО от судьи.
>
> **Инструкция судьи (жёстко):** «План — будущее. Вопрос один: объявлен ли проверяемый критерий и конкретен ли он? done-статус НЕ оцениваю, слово „проверено“ за факт НЕ принимаю.»
>
> **Пропустишь → судья усыпляется словом „проверено“ в плане и штампует GO на ИМИТАЦИЮ проверяемости → весь смысл факт-сверки (234а спеки) рушится.** Источник — брейншторм 2026-06-04 (раздел §6.4 ниже).

---

## 1. Решение мины K4 — материализация артефакта через узкую разрешённую запись (Вариант А)

### Проблема (из аварийного блока чертежа Машины 2)
В разговорном режиме стена Машины 2 (`decideMode`) закрывает свободный Write/Edit (мутирующий → блок; проходят только семена + зелёный проход). Но роутер рекомендует думательные навыки-семена (`brainstorming` / `writing-plans` / `discovery-interview`), которые **сами пишут файлы** (спеку / план). Если «починить» широким Write — откроется ровно тот обход, которого боится K4: freestyle-артефакт, написанный мимо думанья.

### Ключевое различение
«Артефакт» — это ДВЕ разные вещи:
1. **Читаемый .md-файл** (спека/план на диске) — просто текст; его читают человек и навыки.
2. **Печать (seal)** — отдельный подписанный объект (`frozen-artifact-<sess>.json`), на который ССЫЛАЕТСЯ план стройки; именно печать «разрешает» строить.

**Опасна именно печать, не читаемый файл.** Печать всегда идёт через канал одобрения (контракт K1; HMAC-ключ контроллеру недоступен — реализуется на Машине 4, гейт-1). Читаемый .md сам по себе безвреден: его опасность («спека от балды мимо думанья») полностью ловится ниже — судья гейт-1 проверяет полноту артефакта против контрактов скилов + ревью владельца; мусорная спека не печатается → стройки нет.

### Решение (Вариант А, одобрено 2026-06-04)
Стена Машины 2 (`decideMode`, разговорная ветка) получает **одно узкое исключение**: Write/Edit пропускается, ЕСЛИ выполнены ОБА условия:
1. **Семя активно** — в текущем ходе реально вызван думательный навык-семя (`brainstorming` / `writing-plans` / `discovery-interview`), проверка по **фактическому журналу вызовов Skill** (как контракт K2: по журналу, не по тексту/слову контроллера).
2. **Канонический путь** — целевой путь = канонический выходной путь активного семени: `docs/superpowers/specs/*.md` (brainstorming) / `docs/superpowers/plans/*.md` (writing-plans) / `docs/discovery/*.md` (discovery-interview). Точный набор путей-под-семя фиксируется при реализации 3-D. Любой иной путь (прод-код, нормативка, runtime, прочее) — НЕ под исключение → блок.

Всё остальное в разговорном режиме (прод-код, иные пути, Write без активного семени) — блокируется как сейчас. **Печать (seal) этим исключением НЕ открывается** — остаётся только через канал одобрения (K1 / Машина 4).

### Почему это безопасно (защитные слои)
- Машинно-проверяемое И узкое исключение: оба условия (семя-активно + канонический-путь) детерминированны (принцип «умный не баран» — тупо-механическая проверка стены).
- Прод-код и любые другие пути в разговоре по-прежнему закрыты.
- Реальный барьер против фальшивки — печать (K1) + судья гейт-1 (полнота против контрактов) + ревью владельца. Даже спека, написанная «для галочки» мимо думанья, не пройдёт гейт-1 → не запечатается → не станет фундаментом стройки.

### Где и когда реализуется
Поправка к `tools/enforce-supreme-gate.mjs` (`decideMode`, разговорная ветка): рядом с `isSeed || isObserveOnly` добавляется проверка «активное-думательное-семя + канонический-путь артефакта → allow». Реализуется на этапе **под-плана 3-D** (когда роутер заводит семена), НЕ раньше. Под-планы 3-A / 3-B / 3-C от K4 не зависят (там нет записи артефактов-через-Write) → фундамент строится без этой поправки.
- **ВКЛЮЧАТЬ исключение можно только ПОСЛЕ того, как K1/M4 реальны** (печать гейтится одобрением + ключ недоступен контроллеру). Включишь раньше — либо инертно (печатать некому → стройка всё равно не идёт), либо дыра (фальшивый артефакт некому отбраковать). Порядок жёсткий: сначала K1/M4, потом активация K4-исключения. (Находка 4 ревью.)

### Остаточные стыки (не в Машине 3)
- Триггер «владелец одобрил на гейте-1 → `freezeArtifact`» + сам канал печати — Машина 4 (гейт-1) + канал Машины 1. Примитив `freezeArtifact`/`saveFrozenArtifact` уже есть (Машина 2).
- «Сухой канал» (анти-инъекция) для передачи содержания на одобрение — в Варианте А не нужен (навык пишет .md напрямую под узким исключением; на одобрение/печать идёт уже файл, который судья читает).

---

## 2. Форма Машины 3 — пять под-планов, «механическое отдельно от думающего»

Машина 3 — НЕ один чертёж: она покрывает несколько независимых подсистем (требование Scope Check навыка writing-plans → декомпозиция). Принцип «умный не баран» задаёт естественную границу: половина ЗАЩИТЫ/ПРОВЕРОК — тупо-механическая (чистый TDD), половина РАССУЖДЕНИЯ — у модели (тестируем построитель промпта + механические проверки, сам вызов мокается).

### Механический фундамент (чистый TDD, как Машина 2)
- **3-A «Контракты скилов»** (C-13 + L-серия) — схема контракта `{needs / produces / constraints + preview-form / defaults / key-decisions / acceptance-criteria}`; свои скилы — пишем контракт сами; чужие (маркетплейс) — тонкий файл-адаптер рядом + гард-рейлы G1–G6, ключевой G4 (хеш-страж дрейфа: версия+хеш чужого скила, расхождение → громкий флаг + откат на мягкое рассуждение). Фундамент для машины охвата.
- **3-B «Граф узлов из реестра»** (3.1/3.2/3.3 + 3.6) — стабильная карта инструментов из РЕЕСТРА (НЕ graphify): узлы = скилы/MCP/агенты, рёбра = альтернативы/«близнецы» / связи-подсказки / конфликты (подсказки, не рецепты). Заземление ОВ-Д2: скил механически резолвится в реальный узел. Чувство свежести 3.6: сверка даты каталога/памяти против даты правки реестра.
- **3-C «Машина охвата A/B/C/D»** (C-14) — на контрактах (3-A) + графе (3-B): A граф зависимостей (узлы=скилы, рёбра=needs↔produces; декомпозиция=связные группы, порядок=топосортировка, дыра=нужда-без-producer, цикл=флаг); B двусторонний реестр нужды↔решения (дыра / сирота-скоупкрип); C чек-лист «просьбы цели → план» (мягкий край на извлечении просьб); D ограничения как полноправные нужды. Хребет — буквальный чек-лист готовности (галочки + указатели §).

### Думающая голова (LLM)
- **3-D «Движок роутера»** (Группы 1/2/5/6 + look-ahead + L-ядро) — выбор скила по смыслу рассуждением по ПОЛНОМУ графу+каталогу (через кэш промпта) + вшитый брейнсторм (2–3 варианта → спор → выбор) + видимая трасса 5.1 со структурными слотами + **механический валидатор трассы** (пустой слот = красный флаг) + воздержание 5.2 / нюх 5.3 / самопроверка 5.4 + интервьюер 4.4 + look-ahead (тащит вопросы вызываемых скилов вперёд) + L-ядро (L1 образец / L3 дефолт-на-вето / L4 порядок по влиянию / L5 ограничения-пре-мортем / L7 критерии приёмки) + риск-фильтр W1+W2 (роутер сперва сам чинит) + деньги 6.1 (цена = разделитель равноценных, не глушилка) + 6.2 (выжимка, кроме графа). Здесь же реализуется **поправка K4** к стене Машины 2 (узкое исключение записи артефакта).
  - **Перенос «волн» из Машины 2** (D6/OQ1): линейный указатель шага `decide`/`runGate` → дерево указателей (ветвление под-плана). Делается здесь, где роутер собирает/разбивает планы (D34/D35). Трогает код Машины 2.

### Служебка (механическое, переиспользует существующее)
- **3-E «Очередь одобрений + ручка разведки»** (3.4/3.5 + #3 крит-разбор) — механизм обучения роутера: очередь-файл сильных кандидатов → раздел «На одобрение» в `/brain-retro` → сигнал «ждут: N» в STATUS.md → одобрение пачкой. **Наполнение фонда примеров (3.4) и долгой памяти (3.5) — ТОЛЬКО по явному «да» владельца, ИНАЧЕ НИКАК** (hard-rule: без авто-обучения, без тихого накопления). Ручка «% разведки» (0 по умолчанию) + счётчик использования узлов + проба = вопрос владельцу с обоснованием/риском.

### Порядок сборки
3-A → 3-B → 3-C (фундамент) → 3-D (голова; здесь же K4-поправка + перенос волн) → 3-E (доставка). Каждый под-план — свой детальный TDD-чертёж (через writing-plans) и своя сборка (через subagent-driven-development по факту: контроллер строит сам, т.к. субагент-исполнитель не проходит TDD-гейт — урок Машины 2).

---

## 3. Как тестируется думающая часть (3-D)

Образец — существующий `tools/router-classifier.mjs` (Sonnet 4.6 через `callAnthropicAPI`, кэш промпта):
- **Построитель промпта** (граф+каталог+контракты+слоты трассы) — чистая функция → тестируется детерминированно (тот же вход → тот же промпт-текст).
- **Сам вызов модели** — мокается в тестах (инъекция `llmCall`), как в существующих хуках-судьях.
- **Механические проверки** — обычный TDD: валидатор трассы (пустой слот → флаг), заземление скила в реальный узел графа (выдумка → отклонение), риск-триаж (структура), сравнение цены (разделитель равноценных).

Принцип «умный не баран»: свежее рассуждение — у модели (не тестируем «правильность мысли» юнитом), а все ПРОВЕРКИ/ЗАЩИТЫ вокруг — тупо-механические и покрыты тестами.

---

## 4. Границы — что НЕ в Машине 3

- **Печать + судейство артефакта/плана (гейт-1/гейт-2) + апелляционный цикл (3 раунда сухой петли)** → Машина 4. Машина 3 отдаёт замороженный план со скилами + трассу; печать ставит канал одобрения (K1), судит — Машина 4.
- **Наполнение** очереди обучения (3.4/3.5) → только по «да» владельца (механизм строим в 3-E, наполнение — нет).
- **Защитный пол** (секреты/runtime/нормативка/force-push) → Машины 1/5, независим от роутера.

---

## 5. Контракты соседних машин (повтор для удобства, канон — аварийный блок чертежа Машины 2)

- **K1 → Машина 4 (гейт-1):** печать ставит ТОЛЬКО процесс одобрения; артефакт всегда доводится до владельца (замена снятой D29).
- **K2 → Машина 4 (A2):** «взял ли навык» — по фактическому журналу вызовов, не по тексту TodoWrite/coverage. Тот же журнальный принцип использует условие 1 поправки K4 (семя-активно).
- **K3 → Машина 5 (`classifyBashCommand`):** консервативный readonly. Уже соблюдён (Машина 2 `isObserveOnly` использует `classifyBashCommand` reason `readonly|reading`).
- **K4 → ЗДЕСЬ (решено Вариантом А):** артефакт материализуется через узкое исключение записи (семя-активно + канонический-путь), печать — через одобрение. Реализуется на 3-D.
- **K5 → Машина 4 (гейт-2):** судья проверяет ОБЪЯВЛЕННЫЙ критерий приёмки, не done-статус; слово «проверено» в плане за факт не принимает. Полный текст — аварийный блок K5 вверху. Реальное «проверено» = рантайм-сентинел (Машина 5).

---

## 6. Дисциплина роутера (брейншторм 2026-06-04, всё зафиксировано)

> Роутер — тоже ИИ и может халтурить «как Claude». Главный принцип: **сила дисциплины = насколько вывод роутера можно СВЕРИТЬ с фактами, которых он сам не сочиняет** (узлы / рёбра-близнецы / рёбра-конфликты / расчёт охвата). Где сверяемо — механика; где нет — оценщик постфактум (M4) + владелец. Честный потолок ~0.5%: качество мысли ВНУТРИ заполненных слотов механически не гарантируешь.

### 6.1 Несущие правила дисциплины (Находка 1 ревью — были пропущены в первой версии, восстановлены)
- **P16-e** — роутер работает по СЫРОЙ просьбе владельца (берёт её из переписки напрямую), НЕ по пересказу Claude.
- **P16-c / OQ7** — `no_skill_found` = СТОП к владельцу, НЕ «свобода делать без скила».
- **P16-g** — высокий риск → навык ОБЯЗАТЕЛЕН независимо от уверенности ИИ.
- **P16-h** — missed-activation = БЛОК (не флаг) на высокорисковых классах.
- **«Высокий риск» — ДЕТЕРМИНИРОВАННО** (по путям/типу/прод-выкату/многошаговости; прецедент `enforce-semgrep-security` SECURITY_PATH_PATTERNS). LLM-оценка риска — только совет, НЕ триггер блока (жёсткий блок нельзя вешать на догадку модели).
- **Структурное принуждение роутера (Находка 5 ревью):** отдельный механизм «заставить советоваться с роутером» НЕ нужен. Роутер **ОБЯЗАТЕЛЕН на детерминированно-высоком риске** (P16-h missed-activation = блок; «роутер задействован» = машинный факт журнала, P16-b) → обход на высоком риске ловится журналом. На **низком риске** роутер advisory; плохой план (даже мимо роутера) ловит **судья** факт-проверкой (охват/ссылки/узлы). Стена остаётся жёстким полом (без опечатанного плана не строишь).

### 6.2 Дисциплина самого роутера (Находка 2)
- **A. «Схема = метод».** Роутер обязан выдать машинно-парсимую 3-слойную структуру; пустой/невалидный слот → невалидно, результата нет (прецедент: фикс классификатора `task_type`).
- **B. Валидатор — ОТДЕЛЬНЫЙ код**, не сам роутер (аналог A0 Машины 2: подсудный не судит себя).
- **Пропуск слоя — только категорией из ЗАКРЫТОГО списка** (свободный текст → отклонён) + **G. счётчик частоты пропусков** (прецедент `enforce-override-limit`).
- **Оценщик постфактум** (правдивость заявленной категории) → Машина 4 (D31), не M3.

### 6.3 Три слоя = ТРИАЖ + обязательная делегация РЕАЛЬНЫМ узлам (усиление через действующие узлы)
Inline-метод роутера (один вызов) обманываем. Глубина+дисциплина приходят от РЕАЛЬНЫХ узлов #19 (superpowers), не от one-call:
- **Слой 1 (пути)** → делегация в реальный `brainstorming` / `discovery-interview`.
- **Слой 2 (план)** → делегация в реальный `writing-plans` (свой self-review) + `test-driven-development`.
- **Слой 3 (выбор скила)** → машина охвата 3-C (НЕЗАВИСИМЫЙ верификатор, рычаг E) + рёбра-близнецы 3-B (рычаг D: есть близнец → «почему не близнец» обязан быть).
- Делегация **журнал-проверяема** (рекомендовал → должен быть реальный вызов узла; иначе missed-activation = блок) и **обязательна на высоком риске**. Ложится на каноническую цепочку реестра `brainstorming → writing-plans → subagent-driven` (`docs/registry/nodes.yaml:1721`).
- **C. Все кандидаты трассы заземлены в реальные узлы** (не только выбранный); причина выбора ссылается на реально существующий факт графа; выдумка → отклонение.

### 6.4 Имитация скила роутером (спека 234/236) — ЗАКРЫТИЕ
Спека прямо: стр. 236 «**Роутер не ЗАПУСКАЕТ скилы — впитал их СТАНДАРТ**»; стр. 234а впитанный write-plans-стандарт форматирует план «**даёт судье факт-сверку**». Это имитация скила (тот же класс, что K2 у Claude): роутер может СЫМИТИРОВАТЬ формат проверяемости без реального backing'а.
- Впитанный стандарт **понижен с ПРОИЗВОДИТЕЛЯ плана-для-судьи до линзы-критики.**
- План-для-судьи **производит реальный `writing-plans`** (Claude вызывает, журнал-проверяемо, обязательно на риске); роутер критикует результат, а не «изображает write-plans».
- Судье-формат (зачем / тег «как-сверх» / ссылка на §) — **механически обязателен** (код + `refResolves` уже есть), не «роутер хорошо отформатировал».
- **«Проверяемый исход» — будущий КРИТЕРИЙ, не прошедшее «проверено».** В плане слова «проверено» НЕТ — есть критерий приёмки. Реальное «проверено» = рантайм-сентинел (Машина 5: RED→GREEN + мутация, неподделываемо). См. аварийный блок **K5** вверху (правило судьи №2 — чтобы судью не усыпило слово «проверено»).

### 6.5 Сила проверки по фазе (асимметрия по конструкции, C-10)
- **Разговорный режим** (производит артефакт, кода нет, стена пускает только семена/зелёный проход): Слой 1 + look-ahead-форма Слоя 3 + урезанный Слой 2 (захват критериев приёмки L7 / ограничений L5 / scope→владелец в артефакт). **Доказательство GREEN недоступно** (нечего и нечем тестировать) → бэкстоп судья гейт-1 + владелец.
- **Исполнительный режим** (опечатанный план): все 3 слоя + неподделываемый GREEN + независимый охват + стена-матч шага.
- Это та же асимметрия C-10 (план судим ДО / фиксирован; разговор судим ПОСЛЕ / по продукту-артефакту) → два гейта судьи. Не дефект — конструкция.

### 6.6 Куда что садится при сборке
6.1–6.4 (правила + дисциплина роутера + делегация + анти-имитация) → под-план **3-D**. 6.3 опирается на **3-A** (контракты) + **3-B** (граф+близнецы) + **3-C** (машина охвата как верификатор). K5 + оценщик роутера/судьи → **Машина 4**. Неподделываемый GREEN + мутация → **Машина 5** (уже спроектировано).

---

## СЛЕДУЮЩИЙ ШАГ
По одобрению владельцем этого документа — детальный TDD-чертёж под-плана **3-A «Контракты скилов»** через `superpowers:writing-plans`, затем сборка. Дальше по порядку 3-B → 3-C → 3-D → 3-E.
