Да, это разумный ход.

Ты сейчас предлагаешь **не добивать eval в вакууме**, а **замкнуть рабочий контур**:

* вопрос от человека;
* декомпозиция;
* выбор маршрута;
* поход в базу;
* сбор результата;
* человекочитаемый ответ в диалоговом окне.

И это реально полезнее следующего слоя “искусственной чистоты”, потому что вы уже уткнулись в потолок слепых прогонов.

## Что фиксируем по стратегии

### 1. Разметку не отменяем, а ставим на паузу

Не выбрасываем идею, а **откладываем до появления 30–40 реальных полевых вопросов**.

То есть:

* synthetic eval остаётся как вспомогательный контур;
* основной следующий шаг — не policy-lab, а **рабочий диалоговый режим**.

### 2. Новая цель этапа

Не “ещё лучше понять язык на тестах”, а:
**собрать первый end-to-end assistant loop поверх уже существующей decomposition-логики.**

### 3. Что даст этот этап

Он даст не абстрактные проценты, а понимание:

* как вообще ощущается система в диалоге;
* где она тупит реально;
* где поиск не дотягивает;
* где ответ не собирается;
* где декомпозиция полезна;
* где интерфейс мешает;
* где нужен второй проход LLM на финальную сборку ответа.

И вот это уже будет очень ценная конкретика.

---

# ТЗ: переход к диалоговому режиму поверх текущего decomposition-контура

## 1. Цель этапа

Добавить в текущую тестовую GUI **второй режим работы — Assistant Mode**, чтобы можно было:

* задать вопрос в диалоговом интерфейсе;
* прогнать его через текущую decomposition / normalization pipeline;
* выполнить поиск/маршрутизацию по существующим путям;
* собрать ответ;
* показать ответ в человекочитаемом диалоговом формате.

Текущий режим decomposition/debugging при этом **сохраняется**.

---

## 2. Что фиксируем как решение

### Решение

На текущем этапе:

* **останавливаем расширение synthetic-разметки и synthetic-eval**;
* **не тратим время на дальнейшие искусственные прогоны без боевых вопросов**;
* переключаемся на **сборку диалогового рабочего контура**;
* позже, после получения полевых вопросов, возвращаемся к:

  * разметке,
  * policy eval,
  * уточнению маршрутов и fallback’ов.

Комментарий:
Это не отказ от eval-подхода.
Это смена приоритета: сначала — usable loop, потом — field-based hardening.

---

## 3. Что должно получиться на выходе

В GUI должны быть доступны **два режима**:

### A. `Decomposition Mode`

Сохраняется текущий debug-режим:

* raw input;
* decomposition output;
* fragments;
* flags;
* route status;
* fallback status;
* trace/debug панели.

### B. `Assistant Mode`

Новый диалоговый режим:

* чатоподобное окно;
* ввод сообщения;
* отправка сообщения;
* выполнение pipeline;
* получение итогового ответа;
* отображение ответа как сообщения ассистента;
* опционально раскрытие технических деталей.

---

## 4. Главная идея Assistant Mode

Assistant Mode не должен быть “просто ещё одним текстовым полем”.

Он должен работать как поверхностный пользовательский интерфейс над уже существующей внутренней логикой:

**User message → decomposition → scope filter → route → retrieval/query → answer composition → assistant reply**

Важно:

* decomposition слой остаётся;
* deterministic routing остаётся;
* fallback policy остаётся;
* просто поверх этого появляется **человеческий вход и человеческий выход**.

---

## 5. Поведение Assistant Mode

## 5.1. Вход

Пользователь пишет сообщение в обычном диалоговом окне.

Примеры:

* один вопрос;
* длинный вопрос;
* сомнение;
* мягкая формулировка;
* несколько связанных мыслей;
* в будущем — multi-intent.

## 5.2. Внутренний пайплайн

После отправки сообщения система должна:

1. прогнать сообщение через `normalizer_v2.x`;
2. получить fragments / flags / scope;
3. отбросить out-of-scope части;
4. определить routed / no-route / clarification;
5. если есть исполнимые fragments — отправить их в backend retrieval/query layer;
6. получить промежуточные результаты;
7. собрать из них **человекочитаемый ответ**;
8. показать его пользователю в чате.

## 5.3. Выход

На экране пользователь должен видеть не JSON и не route flags, а нормальный ответ.

---

## 6. Два режима интерфейса

## 6.1. Переключатель режима

В интерфейсе нужен явный переключатель:

* `Assistant`
* `Decomposition`

Вариант реализации:

* toggle;
* tabs;
* segmented control.

## 6.2. Требование

Состояние режимов должно быть разделено, но использовать общий backend.

То есть:

* один и тот же backend pipeline;
* разные UI-представления.

---

## 7. Assistant Mode — состав интерфейса

## 7.1. Основная область

Чатоподобная лента сообщений:

* сообщения пользователя;
* сообщения ассистента;
* системные статусы по желанию.

## 7.2. Поле ввода

Обычное текстовое поле + кнопка отправки.

## 7.3. Состояния ответа

Во время выполнения показывать:

* `Разбираю запрос`
* `Проверяю контур`
* `Определяю маршрут`
* `Ищу данные`
* `Собираю ответ`

Можно в упрощённом виде.

## 7.4. Дополнительная панель

Опционально:

* кнопка `Показать разбор`
* которая раскрывает:

  * fragments,
  * route,
  * fallback,
  * scope,
  * trace id.

Комментарий:
По умолчанию это не должно мешать диалогу, но для отладки очень полезно.

---

## 8. Логика ответа в Assistant Mode

## 8.1. Если вопрос in-scope и routed

Ассистент должен сформировать ответ по результатам retrieval/query.

Ответ должен быть:

* человекочитаемый;
* собранный под вопрос;
* без сырого технического мусора.

## 8.2. Если вопрос требует clarification

Ассистент задаёт уточняющий вопрос в чат.

Пример:

* “Могу проверить это в контуре компании, но нужно уточнить период или участок учёта.”

## 8.3. Если вопрос out-of-scope

Ассистент отвечает вежливым fallback’ом.

Пример:

* “Я работаю только с данными и бухгалтерическим контуром текущей компании. Этот вопрос относится к общей бухгалтерской практике, а не к данным вашей базы.”

## 8.4. Если вопрос частично in-scope

Ассистент отвечает по допустимой части и отдельно помечает, что остальное вне доступного контура.

---

## 9. Нужен отдельный слой answer composition

Это важно.

Сейчас decomposition и routing — это ещё не финальный ответ человеку.
Нужен отдельный блок:

### `answer_composer`

Он получает:

* исходный user message;
* fragments;
* route results;
* retrieved data/result payloads;
* fallback states;

и собирает:

* один связный ответ для человека.

Комментарий:
Да, ты правильно понимаешь:
если исходное сообщение человека было многослойным, ответ не должен приходить как 5 несвязанных кусков JSON.
Нужен **второй проход на human-readable response**.

---

## 10. Что не делаем сейчас

На этом этапе **не делаем**:

* финальный production-grade assistant;
* память диалога на 100 ходов;
* суперсложную agent orchestration;
* автоматическую доразметку eval;
* полную полевую разметку synthetic наборов;
* бесконечную шлифовку policy.

Сейчас задача — **замкнуть usable loop**.

---

## 11. Что backend должен уметь

Нужен единый assistant pipeline endpoint.

Примерно так:

### `POST /api/assistant/message`

Вход:

* user message
* session id
* mode = assistant

Внутри:

* run normalizer
* resolve execution state
* route fragments
* call retrieval/query handlers
* compose answer
* return assistant response + debug payload

Выход:

```json
{
  "ok": true,
  "assistant_reply": "string",
  "conversation_item": {...},
  "debug": {
    "trace_id": "...",
    "fragments": [...],
    "fallback_type": "...",
    "route_summary": [...]
  }
}
```

---

## 12. Что сделать в GUI технически

## 12.1. Новая вкладка / режим

Добавить Assistant Mode без удаления текущего Decomposition Mode.

## 12.2. История диалога

Сделать хранение сообщений в рамках текущей сессии:

* user messages;
* assistant replies;
* debug ids.

Пока достаточно session-scoped памяти без сложного persistence.

## 12.3. Debug drawer

У каждого ответа можно открыть:

* decomposition;
* fragments;
* scope;
* routes;
* fallback;
* trace_id.

---

## 13. Что логировать

Нужно логировать для каждого сообщения:

* `session_id`
* `message_id`
* `user_message`
* `normalizer_output`
* `resolved_execution_state`
* `routes`
* `fallback_type`
* `retrieval/query payloads`
* `assistant_reply`
* `trace_id`

Комментарий:
Это потом очень пригодится, когда пойдут реальные полевые вопросы.

---

## 14. Что использовать как тестовые данные сейчас

Пока нет боевых полевых 30–40 вопросов, допускается использовать:

* уже собранные сложные synthetic вопросы;
* ваши старые troublesome вопросы;
* 10–20 кривых пользовательских формулировок.

Но это уже только для smoke test UI и pipeline, не для финального truth-eval.

---

## 15. Что будет следующим этапом после этого

После того как Assistant Mode заработает, следующий этап:

* собрать 30–40 боевых полевых вопросов;
* прогнать их уже через реальный диалоговый контур;
* сохранить логи;
* на их основе вернуться к:

  * разметке,
  * eval policy,
  * hardening маршрутов,
  * fine-tuning clarification/no-route policy.

То есть сейчас мы строим **инструмент для получения настоящей конкретики**, а не выдуманной.

---

## 16. Артефакты, которые должен выдать Codex

1. `docs/assistant_mode_spec.md`
2. обновлённый GUI с переключателем:

   * `Assistant`
   * `Decomposition`
3. backend endpoint для assistant loop
4. `answer_composer` слой
5. session-based chat history
6. debug drawer / expandable technical view
7. `docs/assistant_mode_flow.md`
8. `docs/known_limits_before_field_eval.md`

---

## 17. Критерии приёмки

Этап считается принятым, если:

1. в GUI есть два режима:

   * decomposition
   * assistant
2. assistant mode позволяет:

   * ввести вопрос,
   * прогнать pipeline,
   * получить финальный человекочитаемый ответ
3. out-of-scope / clarification / partial fallback работают в диалоге
4. decomposition mode не сломан
5. debug-информация доступна, но не мешает основному UX
6. история сообщений в рамках сессии работает
7. можно использовать контур как рабочую тестовую песочницу для будущих полевых вопросов

---

## 18. Короткий итог

Сейчас правильный ход такой:

**останавливаем blind eval hardening,
не тратим силы на synthetic-разметку,
и переводим систему в usable dialog mode,
чтобы уже на реальных вопросах смотреть, где она работает, а где нет.**

---

Если хочешь, я следующим сообщением сделаю ещё **короткую версию этого ТЗ для прямой вставки в Codex**, без пояснений и комментариев.