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

Живой документ. Заполняется по ходу 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», после включения которых слой ожил):

tools/router-prehook.mjs — на каждый промпт зовёт classify(), пишет ~/.claude/runtime/router-state-<session>.json, на stdout {}. Молчит — контроллеру ничего не показывает, только готовит state.
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 этот лог). Проект большой, многосессионный.

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

Заказчик заметил: классификатор-роутер (Agent Router, AITUNNEL) стреляет на КАЖДЫЙ промпт, жжёт 2–9 ₽, советы бесполезны. Разбор сессии: роутер 5 раз промолчал, 1 раз посоветовал ерунду (#34,#19) → полезным советом не воспользовались НИ РАЗУ.
Разворот заказчика: не экономить, а понять — «модуль интересный, может плохо работает?». Ключевая мысль: то, что роутер глушит как «болтовню», — это фаза обсуждения/ проектирования, где думающие скилы (brainstorm/interview/research) и нужны. Роутер должен быть думающим партнёром, а не гейтом-молчуном.
Разбор кода: разговорный слой = 2 хука (router-prehook молчит + enforce-prompt- injection говорит). Классификатор видит только 1 промпт + prevState; transcript не читает.
Эпизод со стеной: тревога «пишешь в обход стены» → стена ЦЕЛА (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).
Накопили дизайн (D1-D5, Q1-Q12). Сдвиги мысли: «стадия диалога» → «когнитивная потребность хода» по 2 осям think/read; повестка как стержень (растёт И мутирует); заказчик ≠ всезнайка → система СЕЕТ повестку и СНАБЖАЕТ знанием; research-узлы #87/#88/#89 — движок снабжения (ответ/обнаружение/глубокое-чтение).
Крупный сдвиг (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», не дыра.

28 KiB Raw Blame History Unescape Escape