trace-first-starter

HL — TFW-14: Research Interaction Model

Дата: 2026-04-01 Автор: Coordinator (AI) Статус: 🔵 HL — Обновлён по результатам RESEARCH

1. Видение

RESEARCH stage (TFW-11) работает, но взаимодействие агента с пользователем недостаточно управляемо и прозрачно. Агент запускает стейджи слишком автономно: проводит Gather, задаёт 3 вопроса, сразу переходит к Extract — без явного перехода, без плана, без возможности пользователю повлиять на направление исследования.

Ключевая мысль: Research существует для уточнения HL — плана, фаз, целей, ценностей. Его основной выход — обновлённый HL, а не прыжок в TS.

Пользователь хочет:

Прозрачный вход — перед первым стейджем агент представляет план: что будет искать, зачем, с какими целями
Управляемые переходы — между стейджами есть осознанный шаг, а не автоматическое продолжение
Проактивность — агент задаёт наводящие вопросы, спрашивает о пожеланиях и мыслях пользователя ДО погружения в discovery
Фокус — не легкомысленный прогон по чек-листу, а вдумчивый, интерактивный процесс
Обратная связь в HL — research уточняет и обновляет HL, а не проскакивает мимо
Явное закрытие — прозрачный выход с итогом и подтверждением

2. Текущее состояние (As-Is)

Аспект	Состояние
Вход в research	Плоский: пользователь говорит «переходим» → агент сразу начинает первый стейдж
Plan preview	Нет. Агент не объясняет, что он собирается исследовать
Переходы между стейджами	Формальный checkpoint: findings + 3 вопроса → сразу в следующий стейдж
Роль пользователя перед стейджем	Реактивная — отвечает на вопросы, но не направляет
Темп	Слишком быстрый — стейджи проскакивают без ощущения глубины
Наводящие вопросы	Агент задаёт вопросы ПО итогам стейджа, но не ДО начала
Завершение research	Неявное — агент говорит «достаточно для TS», сразу идёт писать TS
HL update	Не предусмотрен — HL остаётся как было, даже если research раскрыл новые факты
Цикличность	Формально заложена (pass 2+), но нет явного self-check «хватит ли нам?»

Что происходит сейчас (по факту)

Пользователь: «переходим к research»
Агент: [выполняет Gather автономно] → «Вот findings. 3 вопроса.»
Пользователь: [отвечает]
Агент: [выполняет Extract автономно] → «Вот findings. 3 вопроса.»
...

Что теряется

Возможность пользователя повлиять на направление discovery ДО его начала
Контекст от пользователя (мысли, пожелания, догадки), который мог бы сфокусировать стейдж
Ощущение совместного исследования — вместо этого получается «агент докладывает, пользователь реагирует»
Обновление HL по итогам research — фазы и план могли измениться, но HL не трогают
Явное закрытие research — что зафиксировали, что решили, что дальше
Skip-bias — агенты слишком часто рекомендуют пропустить RESEARCH. Смысл research не только в технических неизвестных, но в слепых зонах, неожиданностях, диалоге

3. Целевое состояние (To-Be)

Аспект	Целевое состояние
Вход в research	Briefing — агент представляет план исследования, спрашивает о пожеланиях
Plan preview	Обязателен. Короткий план: что ищем, зачем, какие цели по каждому стейджу
Переходы между стейджами	Stage Handoff — после checkpoint агент предлагает план на следующий стейдж, спрашивает пожелания
Роль пользователя	Активная — направляет, дополняет, корректирует фокус
Темп	Пользователь контролирует скорость — явные точки «погружаюсь» / «давай дальше»
Наводящие вопросы	Агент задаёт ДО И ПОСЛЕ каждого стейджа
Завершение research	Closure Protocol — явный итог: что зафиксировано, обновление HL, подтверждение перехода к TS
HL update	Обязательный — research уточняет HL (фазы, подход, зависимости). HL обновляется ВСЕГДА перед TS
Цикличность	Sufficiency Check — после каждого прохода агент явно оценивает: «хватит ли для финализации HL?»

Алгоритм цикла (state machine)

┌─────────────────────────────────────────────────────────────┐
│                     RESEARCH CYCLE                          │
│                                                             │
│  BRIEFING ──→ Gather ──→ Extract ──→ Challenge              │
│     ↑          (checkpoint + stage handoff between each)    │
│     │                                          │            │
│     │                                SUFFICIENCY CHECK      │
│     │                                   │          │        │
│     │                              Нет ─┘     Да ──┘        │
│     │                               │              │        │
│     └──── новый pass ◄──────────────┘         CLOSURE       │
│                                                │            │
│                                          Обновить HL        │
│                                                │            │
│                                          User confirms      │
│                                                │            │
│                                             → TS            │
└─────────────────────────────────────────────────────────────┘

Как должно работать (To-Be)

 1. Пользователь: «переходим к research»
 2. Агент: BRIEFING
    - «Вот что я собираюсь исследовать и зачем: [план по стейджам]»
    - «Есть ли у вас мысли, пожелания, приоритеты?»
    - «Что точно не нужно трогать?»
    - 🛑 WAIT
 3. Пользователь: [даёт направление]
 4. Агент: [выполняет Gather с учётом briefing]
 5. Агент: CHECKPOINT Gather
    - Findings + вопросы
    - STAGE HANDOFF: «Для Extract планирую: [план]. Мысли?»
    - 🛑 WAIT
 6. ... (Extract, Challenge — аналогично)
 7. Агент: SUFFICIENCY CHECK
    - «Хватит ли для финализации HL? Вот что я вижу: [оценка].»
    - Если нет → новый pass (цикл к Gather с BRIEFING на новый pass)
    - Если да → CLOSURE PROTOCOL
 8. Агент: CLOSURE PROTOCOL
    - Итог: что зафиксировано, какие решения приняты
    - Обновляет HL: фазы, подход, зависимости, риски
    - Показывает diff HL пользователю
    - «HL обновлён. Переходим к TS?»
    - 🛑 WAIT
 9. Пользователь: [подтверждает / корректирует]
10. → TS пишется по обновлённому HL

Новый элемент: Briefing

Briefing — это NOT стейдж. Это протокол входа в RESEARCH. Может длиться несколько turns (раундов вопрос-ответ).

Содержание:

Research Plan — 3-5 bullet points: что агент планирует исследовать и зачем
Scope intent — что точно в скоупе, что точно нет
Наводящие вопросы (1-3 per turn) — помочь пользователю обозначить приоритеты
🛑 WAIT — агент не начинает стейджи без ответа. Briefing продолжается пока обе стороны не готовы

Turn-based ритм: ≤3 вопросов за один turn (раунд). Briefing и каждый стейдж могут длиться несколько turns. Turn = один раунд вопрос-ответ, не рестарт.

Новый элемент: Stage Handoff

Stage Handoff встроен в checkpoint. После findings и вопросов по текущему стейджу, агент добавляет:

Следующий стейдж — что планирует исследовать
Направляющий вопрос — «Что-нибудь хотите добавить? Есть мысли, которые стоит учесть?»

Это НЕ отдельный шаг, а расширение checkpoint.

Новый элемент: Closure Protocol

Closure Protocol — это протокол выхода из RESEARCH. Происходит когда Sufficiency Check = «достаточно».

Содержание:

Итог — что зафиксировано в RES: ключевые решения, закрытые вопросы
Рекомендации к обновлению HL — research-агент пишет что нужно изменить в HL (фазы, подход, зависимости, риски). Coordinator обновляет HL в своей сессии
Next step — «HL обновлён. Переходим к TS?»
🛑 WAIT — агент не пишет TS без явного подтверждения обновлённого HL

HL обновляется всегда. Research-агент пишет рекомендации в Closure секции RES, coordinator применяет их к HL. Это основной выход research.

Отдельный агент (рекомендация): Research рекомендуется запускать в отдельной сессии (/tfw-research). Research-агент пишет RES → coordinator читает RES → обновляет HL → user confirms → TS.

Новый элемент: Sufficiency Check

Sufficiency Check — это самооценка агента после каждого полного прохода (pass) через стейджи. Агент должен честно ответить на вопрос:

«Достаточно ли информации для финализации HL? Можем ли мы уверенно зафиксировать фазы, подход и зависимости?»

Это не checkpoint для пользователя, а внутренний вопрос агента, результат которого он озвучивает пользователю вместе с рекомендацией: закрыть research или начать ещё один pass.

Проверяет:

Есть ли незакрытые Open Questions в RES?
Все ли стейджи дали содержательные результаты или были формальными?
Не переусложнили ли мы решение для масштаба задачи?
Достаточно ли ясны фазы, их границы и зависимости?

4. Скоуп изменений

5 файлов, одна фаза. Структура: 2 новых элемента + 2 расширения + 1 фикс (подтверждено RESEARCH).

Изменения в `research.md`

[НОВЫЙ] Briefing Protocol — перед секцией «Process». Turn-based ритм (≤3 вопросов per turn)
[РАСШИРЕНИЕ] Checkpoint — добавить Stage Handoff (+2 строки: план следующего стейджа + вопрос)
[НОВЫЙ] Closure Protocol — после Final Checkpoint (рекомендации к HL)
[РАСШИРЕНИЕ] Sufficiency Check — усиление Final Checkpoint: «хватит ли для финализации HL?»
Hard Rules — briefing, closure, sufficiency check обязательны
Anti-patterns — briefing skip, silent closure, skipping HL update, rush-bias, skip-bias

Изменения в `RES.md` template

Секция Briefing — план, scope intent, вопросы (якорь для поведения агента)
Секция Closure — итог, рекомендации к HL, next step

Изменения в `plan.md`

Phase 3.5 — «After RESEARCH → coordinator reads RES → updates HL → user confirms → TS» + anti-pattern
Skip-bias fix — pros/cons формат, user decides. Default = recommend research

Изменения в адаптерах

.claude/commands/tfw-research.md — синхронизация с research.md (briefing, closure, turn-based)
.agent/workflows/tfw-research.md — синхронизация с research.md (briefing, closure, turn-based)

Не меняем: стейджи, лимиты, Entry Modes, Role Lock, статусы. Это фикс UX, а не переделка процесса.

5. Definition of Done (DoD)

6. Definition of Failure (DoF)

❌ 1. Briefing превращается в длинный допрос (должно быть 1-3 наводящих вопроса, не 10)
❌ 2. Stage Handoff удваивает checkpoint (это одна секция, не две остановки)
❌ 3. Closure Protocol как бюрократия (должен быть 1 сообщение: итог + вопрос про HL + «к TS?»)
❌ 4. Изменения ломают обратную совместимость со стейджами (Gather/Extract/Challenge неизменны)

При провале: упростить до минимума: briefing = план + 1 вопрос; closure = итог + «к TS?».

7. Принципы

Прозрачность > скорость — пользователь должен понимать, что произойдёт дальше, прежде чем агент это сделает
Briefing ≠ допрос — это приглашение к сотрудничеству, не серия вопросов
Research → HL — research существует для уточнения HL. Обновление HL = основной выход research, не опция
Явное закрытие — research не завершается молча; агент фиксирует итог, обновляет HL, пользователь подтверждает
Честная самооценка — агент не говорит «достаточно» по инерции; Sufficiency Check = конкретный ответ с обоснованием
Минималистичные изменения — не переписываем workflow, а дополняем протоколами (briefing + handoff + closure)

8. Зависимости

Зависимость	Статус
`research.md` (TFW-11) актуален	✅
`RES.md` template актуален	✅
`plan.md` актуален	✅
`.claude/commands/tfw-research.md` актуален	✅
`.agent/workflows/tfw-research.md` актуален	✅
PROJECT_CONFIG.yaml	Без изменений

9. Риски

Риск	Вероятность	Влияние	Mitigation
Briefing добавляет ещё одну остановку, которую пользователь начнёт пропускать	Низкая	Средняя	Briefing = 1 сообщение (план + 1-3 вопроса), не отдельный раунд Q&A
Stage Handoff раздувает checkpoint	Низкая	Низкая	2 строки: «Планирую дальше: X. Есть мысли?»
Агент игнорирует briefing (не все модели следуют)	Средняя	Средняя	Hard Rule + Anti-pattern + пример в workflow
HL Update Gate — агент всегда говорит «HL ok» по инерции	Средняя	Высокое	Конкретный вопрос: «Что именно изменилось? Фазы? Подход? Зависимости?»
Closure Protocol удлиняет процесс	Низкая	Низкая	Это 1 сообщение, не отдельный раунд
Sufficiency Check — агент всегда отвечает «достаточно»	Средняя	Среднее	Обязательно указать конкретику: что именно ясно, что нет

RESEARCH confirmed (2026-04-01): Live session reproduced all identified problems. 5 protocols simplified to 2+2+1. Scope expanded to 5 files. See RES.

*HL — TFW-14: Research Interaction Model

2026-04-01 (updated after RESEARCH)*

This site is open source. Improve this page.