# Роутер-наставник — разговорный слой: журнал решений

> **Живой документ.** Заполняется по ходу brainstorming-сессии. Сюда вносим
> ИТОГОВЫЕ решения сразу, как только их приняли, чтобы не забыть между ходами.
> Финальная спека будет отдельным `*-design.md` после закрытия всех вопросов.
> Кодовая фраза: «роутер-наставник».

**Дата старта:** 2026-06-14
**Ветка/копия:** основная копия `c:\моя\проекты\портал crm\Документация`
**Статус:** 🟡 brainstorming, вопросы открыты

---

## 0. Зачем (переформулировка задачи)

Разговорный слой роутера сейчас спроектирован как **гейт дисциплины**: «задача →
скил реализации, иначе напомни про coverage и молчи». Цель пересмотра — развернуть
его в **думающего партнёра**: в фазе обсуждения он должен распознавать стадию
разговора и подключать мыслительные скилы (`brainstorming`, `discovery-interview`,
`product-management:brainstorm` и др.), а не глушить обсуждение как «болтовню».

Ключевой тезис заказчика: **болтовни у нас нет — всё по делу.** То, что
классификатор метит `question/conversation`, — это фаза обсуждения перед
реализацией, и именно там думающие скилы приносят пользу.

Триггер пересмотра: на реплику «может, модуль плохо работает?» контроллер на
автомате предложил *сэкономить* (заглушить болтовню в $0), а не *расширить* и
сделать полезным. Это и есть ошибка фрейма, которую чиним.

---

## 1. Код-обоснованный baseline (ФАКТЫ, не передоказывать)

Разговорный слой = **2 UserPromptSubmit-хука** (те самые «последние 2», после
включения которых слой ожил):

1. **`tools/router-prehook.mjs`** — на каждый промпт зовёт `classify()`, пишет
   `~/.claude/runtime/router-state-<session>.json`, на stdout `{}`. **Молчит** —
   контроллеру ничего не показывает, только готовит state.
2. **`tools/enforce-prompt-injection.mjs`** — заголовок «Rule #1 — Mandatory
   re-classification injection». Читает router-state, строит блок
   `## §17 Coverage / Discipline Reminder` (функция `buildReminder`, строки 30–62)
   и впрыскивает его контроллеру через `hookSpecificOutput.additionalContext`.
   **Это единственный хук, который "говорит" с контроллером.**

`tools/router-tool-gate.mjs` — PreToolUse-стена реализационного слоя; к разговору
отношения не имеет.

**Что `buildReminder` выдаёт СЕЙЧАС** (и почему пусто на обсуждении):
- строка `coverage: <channel>:<id>`
- `task_type=X, confidence=Y`
- `recommended_node` / `recommended_chain` (голое эхо классификатора)
- «Plan required» для `feature|bugfix|refactor|cleanup`
- флаги рационализации с прошлого хода

→ Это **эхо классификатора**, без стадии и без думающего скила. На обсуждении
показывает `task_type=question, chain=<пусто>` = шум.

**Что скармливается классификатору сейчас:**
- `classify(userPrompt, …)` получает **только текущий промпт** + `prevState`
  (1 предыдущий ход, для continuation/наследования).
- **`transcript_path` приходит в событии, но ни один хук его не читает** →
  истории диалога классификатор не видит вообще (кроме одного хода назад).

**Точки правки для усиления:**
- `tools/router-classifier.mjs` — научить выдавать стадию + предложение скила.
- `tools/enforce-prompt-injection.mjs` (`buildReminder`) — научить это показывать.

**Прочее:**
- Реализационный слой (стена M1–M7) заказчиком считается «допинанным»; сейчас
  занимаемся разговорным слоем.
- Кеширование классификатора работает (`cache_control: ephemeral`, 5-мин TTL);
  9 ₽ vs 2 ₽ — это честный кеш-промах после паузы >5 мин, не баг.

---

## 2. ПРИНЯТЫЕ решения

| # | Решение | Дата | Примечание |
|---|---------|------|------------|
| D1 | Разговорный слой переосмысляется в «думающего партнёра», а не гейт-молчун | 2026-06-14 | §0 |
| D2 | Триггер — по **варианту C**: роутер распознаёт **стадию диалога** (discovery / design / decision) и подбирает думающий скил под стадию | 2026-06-14 | заказчик «склонен к C» |
| D3 | **Сигналы для стадия-детекции = Hybrid:** дешёвый детерминированный гейт **B+C+D** ($0, без передачи текста) → **A (transcript, последние N реплик)** вызывается ТОЛЬКО когда дешёвый гейт сказал «похоже на design/decision». B = наличие spec/plan по теме; C = траектория (сколько ходов крутимся вокруг темы); D = лингвистические маркеры в промпте | 2026-06-14 | закрывает Q1. Разбор на живом диалоге: **C (траектория) — ключевой дешёвый сигнал**, он ловит design-разворот из слабой фразы («может плохо работает?»), который B+D в одиночку промахивает (и реально промахнул в этой сессии). A в одиночку **переоценивает** — на info-вопросах/действиях видит дизайн везде → шум. Поэтому A — только подтверждение, не основной детектор |
| D4 | **Где живёт рассуждение = Split (вариант C), но выход переформулирован.** Дешёвый детерминированный слой (B+C+D) решает ось + грубую цель ($0); LLM (+ transcript A) уточняет ТОЛЬКО при неоднозначности и только на think-моментах. **Выход детектора — не одна статичная «стадия», а «когнитивная потребность ХОДА»**, пересчитываемая каждый ход (хук и так срабатывает per-prompt) → последовательность brainstorm→interview→research возникает сама, отдельный планировщик стадий НЕ нужен. **Две оси выхода:** (1) **think** — brainstorm/interview/decide; (2) **read/research** — Read(известный файл)/graphify #86(структура кода)/context7 #60(API библиотек)/perplexity·exa·firecrawl(внешний research)/Boost #10(Laravel·БД). C(траектория)+prevState дают память о прошлом режиме для плавных переходов | 2026-06-14 | закрывает Q2. Расширено замечаниями заказчика: разговор идёт по стадиям (брейншторм→интервью→research), и «ответить» часто = «прочитать», а подход к чтению зависит от цели (спека ≠ код ≠ внешка) |
| D5 | **СДВИГ SCOPE: главная цель — построить БАЗУ ЗНАНИЙ (корпус), не разговорный слой как таковой.** Источник: перемолоть **ВСЕ скилы** (не только маркетинг) + **копии/дубли наших скилов** (добывать даже 5% уникального — цель полнота/качество, не экономия) + **веб #87-89** на пробелы. Охват — **все ОБЩИЕ сферы бизнеса** (маркетинг / бизнес-процессы / экономика-финансы / бухгалтерия / автоматизация / …), кроме узкоспециального (инженерия машин и т.п.). **Декомпозиция на 2 подпроекта:** (A) База знаний = фундамент снабжения Q10; (B) Разговорный слой (повестка+ведение, D1-D4 + Q6-Q11) = потребитель базы. (B) без (A) пуст → фокус на (A). Скилы-как-знание: **библиотеки** (ui-ux-pro-max/marketingskills/architecture-patterns) читаем как корпус; **процессы** (discovery-interview/brainstorming) запускаем. | 2026-06-14 | поправка заказчика: «исследование не для лендинга, а для базы знаний». Лендинг — лишь иллюстрация. Остаёмся read-only/brainstorming — стройку (A) не начинаем до дизайна |

---

## 3. ОТКРЫТЫЕ вопросы (в работе)

| # | Вопрос | Варианты | Статус |
|---|--------|----------|--------|
| Q1 | Что даём классификатору, чтобы он видел стадию? | ~~A vs B+D vs B+C+D vs Hybrid~~ | ✅ **закрыт → D3 (Hybrid: B+C+D → A по требованию)** |
| Q2 | Где живёт стадия-рассуждение — в классификаторе (LLM) или в reminder-слое (детерминированно)? | ~~A / B / C~~ | ✅ **закрыт → D4 (Split, выход = «когнитивная потребность хода» по 2 осям)** |
| Q3 | Мягкость: роутер предлагает / поднимает флаг / требует? | — | ⚪ не дошли |
| Q4 | Карта «думать»: discovery→interview, design→brainstorm, decision→? (product-management / decision-analysis?) | — | ⚪ не дошли |
| Q5 | Анти-шум: как не предлагать скил, когда мы уже внутри него / на инфо-вопросе | — | ⚪ не дошли |
| Q6 | Прогрессия режимов: детектору достаточно независимой per-turn детекции, или нужен prevState (прошлый режим) для плавных переходов brainstorm→interview→research? | независимый per-turn / per-turn + prevState-bias | 🔴 на очереди |
| Q7 | Карта «читать/исследовать»: цель → инструмент (известный файл→Read / структура кода→graphify #86 / API→context7 #60 / внешка→perplexity·exa·firecrawl / Laravel·БД→Boost #10). Как детектор определяет ЦЕЛЬ чтения дёшево? | — | 🔴 на очереди |
| Q8 | **«План разговора» (повестка).** Разговор = растущее дерево вопросов, не линия (ответ на 1 спавнит 5). Разговорный слой держит **повестку задачи** (артефакт-файл, как этот журнал) и ведёт по ней; D4 (think/read per-turn) = как двигаемся по каждому пункту. **Лёгкая версия:** повестка=артефакт (сигнал B), спавн вопросов делают существующие скилы (discovery-interview/brainstorming/writing-plans), роутер лишь поднимает следующий открытый пункт. **Под-развилка:** роутер по повестке (а) мягко напоминает об открытых пунктах / (б) активно ведёт, держит фокус. Риск: не раздуть в полноценный диалог-менеджер (YAGNI). | мягко / активно | 🔴 кандидат в стержень слоя |
| Q9 | **Мутация повестки.** Повестка не растёт, а МУТИРУЕТ: ответ частично закрывает другой пункт (cross-resolution), ответы бывают частичными (не open/closed, а «на 40%»), углубление частичного спавнит новую проблему. Даже РЕШЕНИЯ мутируют (D4 переформулировал D2). Нужна модель состояний пункта (`open/частично/closed/superseded` + cross-links). **Кто держит граф когерентным** — контроллер/скил каждый ход (LLM-работа, не детерминированный append). **Граница мутации** (анти-каша/анти-круги): липкий хребет §2 Решения vs текучее поле §3 Вопросы — уже в структуре журнала. Центр тяжести и главный риск дизайна — ЗДЕСЬ (поддержание повестки честной), не в роутере. | — | 🔴 зафиксирован, требует модели |
| Q10 | **Сеяние повестки из экспертизы (заказчик ≠ всезнайка).** Заказчик знает WHAT (лендинг, продать услугу), но не WHICH-QUESTIONS (сегмент? аудитория? копирайт? каналы? аналитика?) — повестку сеет СИСТЕМА, не он. **Две модели:** извлечение (discovery-interview — вытащить то, что в голове заказчика) vs **снабжение** (экспертные скилы marketing/design/ux-copy/product-management — дать то, чего в голове НЕТ). Тупому заказчику нужно снабжение → discovery-interview сцепляется с экспертными скилами, которые ОТВЕЧАЮТ. **Top-down seed:** тип проекта → экспертный шаблон повестки. **Дисциплина:** генерим широко, показываем узко (1 вопрос/ход), ведём рекомендацией-с-дефолтом, а не «расскажите вашу стратегию». | — | 🔴 кандидат в стержень слоя |
| Q11 | **Research-модели как ДВИЖОК снабжения (#87/#88/#89, ADR-019, live в сессии).** #87 perplexity = ответ-с-источниками; #88 exa = семантическое обнаружение; #89 firecrawl = глубокое чтение/обход; research chain #87→#88→#89. Дают Q10-снабжению ЖИВОЕ конкретное наполнение (примеры лендингов из ниши, копирайт-тренды 2026, сегменты услуги), а не generic. Ложатся в read/research-ось D4 / карту Q7. **Все платные** → ось ранжируется по цене: Read<graphify<context7<**research**. **Развилка:** КОГДА стреляет research — проактивно при сеянии повестки (богато/дорого) vs по требованию на пункте, где заказчик уперся «не знаю» (гейченно). | проактивно / по-требованию | 🔴 на очереди |
| Q12 | **Форма базы знаний (подпроект A).** Консолидированная (активная сборка: перемолоть каждый скил +5%-дубли +веб → дедуп → разложить по сферам в чистый корпус; макс. полнота, большая стройка) vs Индекс-на-месте (graphify индексит скилы+веб, lazy-запрос; дёшево, но знание разбросано, 5%-инкременты теряются). Посыл заказчика (качество/полнота) → консолидированная. **Первый scoping-артефакт:** карта сфер (сфера → покрывающий скил → дубли/пересечения) до глубокой перемолки. **Открыто:** где живёт корпус (файлы по сферам / graphify-граф / гибрид), как обновляется. | консолидир. / индекс | 🔴 на очереди (стержень подпроекта A) |

---

## 4. Журнал хода (хронология)

- **2026-06-14** — старт brainstorming. Зафиксированы D1, D2 и baseline §1 по коду.
  Открыт Q1 (сигналы для стадия-детекции).
- **2026-06-14** — Q1 закрыт решением **D3** (Hybrid B+C+D → A) после разбора всех
  4 комбинаций на живом диалоге сессии. Главная находка: C (траектория) ловит
  design-разворот дёшево, A в одиночку шумит. Открыт Q2 (где живёт стадия-рассуждение).
- **2026-06-14** — Q2 закрыт решением **D4** (Split). По ходу заказчик добавил два
  расширения: (1) разговор течёт ПО СТАДИЯМ (brainstorm→interview→research) → выход
  детектора переформулирован из «статичной стадии» в «когнитивную потребность хода»,
  пересчёт per-turn; (2) «ответить» часто = «прочитать», а подход к чтению зависит от
  цели (спека ≠ код ≠ внешка) → добавлена **вторая ось read/research** с картой
  цель→инструмент. Открыты **Q6** (нужен ли prevState для плавных переходов режимов)
  и **Q7** (как дёшево определять цель чтения для read/research-оси).
- **2026-06-14** — заказчик поднял **Q8 «план разговора / повестка»**: разговор —
  растущее дерево вопросов, не линия; слой должен держать повестку задачи и вести по
  ней. **Мета-наблюдение (доказательство тезиса самим процессом):** этот журнал И ЕСТЬ
  такая повестка — ответ на Q2 породил Q6+Q7, этот ход породил Q8. То есть разговорный
  слой, который мы проектируем, — это формализация того, что мы сейчас делаем вручную
  (brainstorming-skill + журнал). Q8 — кандидат в стержень слоя; повестка садится на
  сигнал B (артефакт) из D3, спавн вопросов отдаём существующим скилам (не новый движок).
- **2026-06-14** — заказчик поднял **Q9 «мутация повестки»** (граф, не список; частичные
  ответы, cross-resolution, спавн из углубления; мутируют даже решения) и **Q10 «сеяние
  повестки из экспертизы»** (заказчик не всезнайка, не может написать повестку сам →
  система сеет; извлечение vs снабжение; тупому заказчику нужно снабжение + рекомендация-
  с-дефолтом, не допрос). Накопилось ядро D1-D4 + Q6-Q10, всё крутится вокруг ОДНОЙ
  штуки — «повестка под управлением экспертной системы». Следующий шаг-кандидат:
  промежуточная сборка картины (как D + Q складываются в один механизм) вместо новых
  мелких вопросов.
- **2026-06-14** — заказчик показал research-узлы **#87 perplexity / #88 exa / #89
  firecrawl** (ADR-019, research-tooling, live в сессии). Связаны с Q10 как **движок
  снабжения** (живое веб-наполнение vs generic-теория статических скилов) и с read/
  research-осью D4/Q7. Все платные → ранжирование по цене Read<graphify<context7<research.
  Открыт **Q11** (когда стрелять research: проактивно-при-сеянии vs по-требованию-гейченно).
  Наблюдение: на landing-промпт классификатор сам выдал экспертную цепочку
  #55+#74+#77+#46+#76 — research-узлы втыкаются в неё как поставщик фактов.
- **2026-06-14** — **крупный сдвиг scope (D5):** заказчик переформулировал — цель не
  разговорный слой и не лендинг, а построить **БАЗУ ЗНАНИЙ** из всех скилов (+ дубли на
  5% уникального) + веб, по всем общим сферам бизнеса. Задача декомпозирована на (A)
  база-корпус [фокус] и (B) разговорный слой [потребитель]. Открыт **Q12** (форма базы:
  консолидация vs индекс; первый шаг — карта сфер). Следующий read-only артефакт-кандидат
  — инвентаризация установленных скилов по сферам бизнеса.

---

## 5. Наставник-секретарь — сжатый лог диалога (точка возврата)

> **Чтобы вернуться к проекту:** скажи **«наставник-секретарь»** — читать этот файл
> (§2 решения, §3 открытые вопросы, §5 этот лог). Проект большой, многосессионный.

**Арка разговора — как мы сюда пришли:**

1. Заказчик заметил: классификатор-роутер (`Agent Router`, AITUNNEL) стреляет на КАЖДЫЙ
   промпт, жжёт 2–9 ₽, советы бесполезны. Разбор сессии: роутер 5 раз промолчал, 1 раз
   посоветовал ерунду (#34,#19) → полезным советом не воспользовались НИ РАЗУ.
2. Разворот заказчика: не экономить, а понять — «модуль интересный, может плохо работает?».
   Ключевая мысль: то, что роутер глушит как «болтовню», — это **фаза обсуждения/
   проектирования**, где думающие скилы (brainstorm/interview/research) и нужны. Роутер
   должен быть **думающим партнёром**, а не гейтом-молчуном.
3. Разбор кода: разговорный слой = 2 хука (`router-prehook` молчит + `enforce-prompt-
   injection` говорит). Классификатор видит только 1 промпт + prevState; transcript не читает.
4. Эпизод со стеной: тревога «пишешь в обход стены» → стена ЦЕЛА (`enforce-router-gate`
   Bash default-deny, `enforce-tdd-gate` на прод-код; `docs/.md` просто не protected-path).
   Ранний вывод Claude «warn-only» оказался ошибкой чтения legacy-хука `router-tool-gate`
   — снят. Не путать legacy (warn-only) с активным `enforce-router-gate` (hard).
5. Накопили дизайн (D1-D5, Q1-Q12). Сдвиги мысли: «стадия диалога» → «когнитивная
   потребность хода» по 2 осям think/read; **повестка** как стержень (растёт И мутирует);
   заказчик ≠ всезнайка → система СЕЕТ повестку и СНАБЖАЕТ знанием; research-узлы
   #87/#88/#89 — движок снабжения (ответ/обнаружение/глубокое-чтение).
6. **Крупный сдвиг (D5):** настоящая цель — построить **БАЗУ ЗНАНИЙ** (перемолоть все
   скилы + 5%-дубли + веб, все ОБЩИЕ сферы бизнеса, кроме узкоспециального).
   Декомпозиция: **(A) база-корпус [ФОКУС]** + **(B) разговорный слой [потребитель]**.

**Где остановились:** следующий read-only шаг — **карта сфер** (инвентаризация
установленных скилов по сферам бизнеса: сфера → покрывающий скил → дубли/«5%» → дыры
под веб #87-89) как scoping-артефакт ПЕРЕД стройкой базы. Открытый вопрос перед стартом:
очертить границу «общие сферы бизнеса» (что входит / что нет).

**Статус:** brainstorming, стройку (A) НЕ начинали (под hard-gate — нужен дизайн+approval).
Стержень подпроекта A = Q12 (форма базы: консолидация vs индекс). Стержень подпроекта B =
Q8 (повестка) + Q10 (сеяние из экспертизы).
- **Попутное наблюдение про стену** (не решение, на память): разговорный слой =
  2 хука (`router-prehook` молчит + `enforce-prompt-injection` говорит). Реализационная
  стена цела и enforce'ит: `enforce-router-gate` (Bash default-deny), path-deny
  (settings/runtime/секреты/нормативка), `enforce-tdd-gate` (прод-код требует
  план+тест-первым+RED). `router-tool-gate` (legacy «Stage 3») — warn-only,
  superseded → **не путать его с активным `enforce-router-gate`**. Write в `docs/.md`
  проходит легально (не прод-код, не protected-path), это граница «docs ≠ code», не дыра.
