, треды (направление)¶

Статус: Proposed (черновик направления до переработки UI чата; детали протокола и экранов — по итерациям)
Дата: 2026-04-12
Обновлено: 2026-04-19 — chat surface на pipeline snapshot (ChatSurfaceCompositor). Подробности — § История. Обновлено (ранее): 2026-04-12 — «тема → подтемы», обзор размаха на одном экране vs глубокий скролл; смесь подзадач в одной сессии (ADR + ответвления) как норма.

Связанные ADR¶

ADR	Роль
0016	ACP / внешний агент
0017	зона MFD, `MfdShellView`, второе окно
0021	модель внимания; чат во вторичном контуре
0020	слои ответа и трасс
0008	контракты и паритет при расширении
0044	разделение Avalonia / слой отрисовки чата; Skia как гипотеза
0072	UX-модель topic cards / drill-in/back и intent-навигация по темам

Контекст¶

В истории чата с агентом естественно, что за один «ход» пользователя или агента оказывается несколько вопросов или подпунктов — это не аномалия, а нормальная плотность диалога.

Внешние продукты (в т.ч. режимы вроде Plan у Cursor) иногда показывают список уточняющих вопросов перед построением плана, но ответ часто сводят к одной короткой строке или набору жёстких да/нет. На практике ответ может быть:

сложнее бинарного (оговорки, варианты, ссылка на файл, приоритет);
связан с другими пунктами списка (ответ на один меняет смысл следующего).

Линейная лента сообщений плохо совпадает с объектом рассуждения «пакет вопросов → структурированные ответы». Текущий UI чата в Cascade (SecondaryShellPage.Chat, зона MFD) предстоит переработать; этот ADR задаёт направление, а не финальный макет.

Наблюдение (внешний опыт, напр. Cursor): чтобы вспомнить, что уже решили по уточнениям, часто приходится сильно отматывать ленту назад — структура диалога в голове есть, в UI она растворена в хронологии.

Реальные сессии распадаются на тему и подтемы: правка одного ADR, по ходу — ответвление на стороннюю идею и новый ADR, возврат к исходной линии. Это нормальная «пьеса», а не сбой процесса. Продуктовая гипотеза: у чата может быть роль показать весь этот размах на одном экране (обзор, карта, оглавление активных веток — точная форма не зафиксирована), при этом общий контекст для агента и человека остаётся единым (как сейчас по смыслу: одна сессия, одна передача контекста в модель — детали реализации не смешиваем с «две правды»).

Проблема¶

Один инпут на весь пакет уточнений не масштабируется на небинарные и многострочные ответы.
Путаница ролей: пакетные уточнения к плану/задаче — не то же самое, что разовое подтверждение опасного действия (см. PFD и request_confirmation в 0017); смешивать в одном контроле нельзя.
Без явной структуры на стороне клиента сложно воспроизводимо тестировать и давать паритет агенту/человеку (0008).
Потеря ориентации при длинной ленте: без снимка активной темы / пакета уточнений пользователь вынужден к глубокому скроллу, чтобы восстановить состояние «что мы уже ответили».

Решение (принципы)¶

Пакет уточнений (clarification batch) — осмысленная единица UI и, при согласовании с транспортом, протокола: набор пунктов с стабильными идентификаторами внутри пакета, чтобы ответы передавались как структура (id → текст или выбранное значение), а не как свободный парсинг одной строки.
Представление в UI (целевое):
карточки или блоки по одному пункту с полем ответа многострочным там, где нужно;
опционально тип ответа (краткий текст / выбор из вариантов / да–нет) на пункт;
опционально одно общее поле в дополнение к пунктам («как я хочу в сумме»), если сценарий это оправдывает.
Треды / темы — отдельная ось: это не reply-thread ради reply-thread, а карта устойчивых линий работы. ThreadNode представляет тему / ответвление / отдельное исследование; обычные шаги внутри линии — MessageNode. Для одного пакета вопросов чаще достаточно остаться внутри текущей ветки; ClarificationBatch не создаёт новую ветку автоматически.
Транспорт (ACP и др.): расширение контракта сообщений/инструментов под структурированные пакеты — в scope вместе с поставкой UI, по аналогии с правилами 0008. Каноническая правда должна жить в structured event flow (ClarificationBatchOpened, ClarificationAnswerSubmitted) и MCP entrypoints, а не только в одной схлопнутой строке.
Связь с зонами: основной чат остаётся во вторичном контуре / MFD (0021); вынесение на второй монитор — 0017. Критичные подтверждения, требующие внимания PFD, — по политике 0017 п. 6, не через замаскированный «чат-да/нет».
Обзор размаха (направление, не макет): рядом с хронологической лентой или вместо «только ленты» — представление темы → подтем / открытых вопросов / принятых решений, умещающее ширину сессии в поле зрения, чтобы не отматывать десятки экранов ради восстановления контекста по уточнениям. Смешение в одной сессии нескольких линий работ (например правка ADR и по ходу — отдельный ADR по ответвлению) отражается как ветвления, а не как потерянный шум. Единый контекст для модели и для пользователя сохраняется: обзор — проекция той же истории, а не второй несогласованный канал (детали — при проектировании хранилища диалога).

Отклонённые альтернативы (как достаточное целевое состояние)¶

Только одна строка ответа на весь список уточнений — отклонено как систематически слабое для небинарных ответов и связанных вопросов.
Один тред без структуры, полагаясь на парсинг естественного языка для извлечения ответов по пунктам — отклонено как основной путь для пакетных уточнений к плану (может остаться запасным для совместимости).

Открытые вопросы¶

Минимальный v1: только визуальное улучшение (N полей вручную в UI) vs сразу договорённость с форматом сообщений агента.
Нужны ли черновики ответов (сохранение незавершённого пакета при переключении вкладки/окна).
Границы тредов: когда заводить субтред по пункту плана vs оставить в основной ленте.
Обзор размаха: отдельная панель (оглавление, граф, «карта») vs встроенные якоря в ленте; как не дублировать источник правды с транскриптом для модели.
Как автоматически предлагать «ветку» при ответвлении (новый ADR по ходу), не ломая восприятие одной темы.

Последствия¶

Переработка Chat-поверхности и слоя состояния диалога в VM вокруг канонического snapshot, а не прямой Avalonia-ленты.
Тесты UI и сценарии агента с структурированным телом пакета уточнений.
Документация для пользователя: как отвечать на пакет вопросов, как это отличается от обычного сообщения и от подтверждений безопасности.

Статус после принятия¶

После согласования: статус Accepted, при необходимости ссылка из concept-to-implementation-map-v1.md и обновление навигатора в architecture-policy.md.

История изменений¶

Дата	Изменение
2026-04-13	v0 доменной модели пакетов уточнений и валидации в коде: `Models/AgentChat/` (`ClarificationBatch`, `ClarificationItem`, `ClarificationResponse`, `ClarificationBatchValidation`); UI чата пока не подключён.
2026-04-19	chat surface переведён на pipeline snapshot (`ChatSurfaceCompositor`: `Intent -> Declutter -> Layout -> Render`), Skia закреплён как единый продуктовый path; `ClarificationBatch` / `ClarificationResponse` подключены к реальному chat flow и MCP-командам `open_chat_clarification_batch` / `submit_chat_clarification_response`.