ADR 0096: Intercom — сводка на карточке темы (картотека) и сквозная линия продукта (spine)¶

Статус: Accepted · Implemented
Дата: 2026-04-24

Связанные ADR¶

ADR	Роль
0072	topic cards, overview/detail, drill-in/back, main thread как одна из карточек; keyboard intents
0080	Intercom как канал, не «окно к боту»
0116	дерево сессии, steer/follow-up — ортогонально карточкам тем
0057	chat surface pipeline
0045	события и проекции — куда класть summary и метки линии
0048	чат в IDE; что попадает в контекст агента — политика поверхности
0021	зона Mfd / внимание
0095	пример сквозной продуктовой линии в одной сессии работы
0119	Слэш-команды в чате (`/card`, `/spine`) — локальные действия Intercom
## Резюме

Intercom: карточка темы = заголовок + сводка (картотека).
Product spine ортогонален main thread; дополняет 0072.

Отношение к 0072: 0072 остаётся каноном навигации (overview карточек тем ↔ detail треда, intent-команды, привязка к ChatSurfaceLayout). 0096 фиксирует продуктовую семантику содержимого карточки и вторую ось — сквозную линию (spine) работы над продуктом / проектом сессии поверх тем — без замены pipeline и без отмены drill-in/back. Cascade IDE (CIDE) в тексте ниже — типичный пример для основного репозитория; в другом workspace spine — та же абстракция для его продуктовой линии.

Контекст¶

В обсуждении Intercom уточнено: карточка темы — это не сжатый плоский пузырь последнего сообщения, а картотечная запись: заголовок темы (например «Пресеты MFD», «Разведение каналов / stratum», «System.Threading.Channel») плюс краткая сводка — что за тема и где мы в ней остановились, до провала в полный тред.

Параллельно темы в одной сессии часто относятся к одной продуктовой линии — например работа над одним продуктом или репозиторием (в этом репо типичный образ — Cascade IDE: ADR, кокпит, MCP, инфраструктура; в другом проекте — своя линия). Только набор карточек рискует дать «острова» без связки; оператору нужна ещё сквозная линия (spine): куда в целом движется работа над этой линией, даже когда в фокусе другая карточка темы.

Решение (направление)¶

1. Карточка темы = заголовок + summary (картотека)¶

Заголовок — человекочитаемая метка темы (из ThreadNode.Title, переименование треда, или политика генерации из первого якоря — как в 0072).
Сводка (summary) — короткий текст на карточке (ориентир: одна–три строки в типографике overview), не замена detail-таймлайна: при drill-in показывается полная переписка темы.
Источник summary на v1+ — направление реализации: явное поле в метаданных треда / проекция из последнего значимого сообщения / краткая ручная фиксация; детальный контракт событий — 0045. Не-цель: обязательный NLP-автосводчик как база UX (0072 § не-цели).

2. Сквозная линия продукта (spine) ортогональна main thread чата¶

Main thread в смысле 0072 §1 — это один из тредов сессии (линия переписки).
Spine — продуктовый нарратив сессии над выбранной линией: куда в целом движется работа (вехи, цепочка ADR/задач, «сейчас фокус — …» — контент зависит от проекта). Это не обязано совпадать с хронологией main thread один в один; может отображаться как:
закреплённая полоса или карточка-якорь в overview;
или свёрнутая хронология вех со ссылками на артефакты (документы, коммиты) — конкретная вёрстка не фиксируется этим ADR.
Инвариант: spine не подменяет карточки тем и не дублирует весь главный тред; он отвечает на вопрос «в каком месте общей траектории продукта мы», а карточки тем — на «что обсуждаем по отдельным нитям». Для Cascade IDE spine и темы часто совпадают по «полю боя» (один репозиторий) — это частный случай, не определение spine вообще.

3. Связь с кодом (текущее и следующий шаг)¶

Пайплайн 0057 уже выделяет overview: ChatThreadOverviewItem в ChatSurfaceSnapshot — естественное место для поля summary (и при необходимости метки привязки к spine / продуктовой линии) при реализации 0072 план.
ChatPanelViewModel: режим overview/detail (IsChatOverviewMode, выбранный тред) — расширяется под визуал картотеки и отдельный UI-контур сквозной линии после стабилизации карточек по 0072.

4. Spine и контекст агента: не раздувать промпт по умолчанию¶

Spine полезен оператору как компас; у агента контекст ограничен и дорогой, поэтому UX и политика подачи в ACP/MCP (0048) должны расходиться с «положить всё в один тред».

Перенос зафиксированных решений из spine в тред — в обсуждении с агентами кратко называют carry-forward: не дублировать весь spine, а вынести в тему сжатую формулировку уже принятого (часто со ссылкой на якорь spine или ADR).

По умолчанию в рабочий запрос к агенту разумно класть активную тему: последние реплики / выделение / summary карточки — не полную историю spine и не все параллельные темы.
Spine в промпте — сжатый срез (текущая веха, 1–3 буллета «что уже решили», блокеры) или включение по явному действию оператора («добавить линию в контекст», отдельный intent) — детали реализации не фиксируются здесь, принцип: spine не обязан автоматически дублироваться целиком в каждый вызов.
Перенос зафиксированных решений из spine в тред (carry-forward): когда в spine зафиксировано решение, в связанном треде достаточно краткого мостика (одно–три предложения + ссылка на ADR/коммит/якорь spine), чтобы агент работал в теме без обязательного «переключения» в отдельный контур spine; spine остаётся каноническим местом вехи, тред — рабочей памятью с локальным контекстом.
Артефакты вне чата (ADR, тикет) уже разгружают чат: в промпт — ссылка и одна строка резюме, а не вставка полного текста документа, если только оператор не выбрал иное.

Примеры (не исчерпывают реализацию):

Ручной перенос решения в тему (тот же carry-forward). В треде «Пресеты MFD» оператор пишет: «По линии продукта зафиксировали: spine показываем как карточку-якорь, не второй таймлайн — см. 0096 §2. Здесь продолжаем только вёрстку пресета.» Агент в этом треде не обязан заново читать весь spine.
Явный протокол суммаризации (уже есть для чата). Длинный тред или длинный фрагмент spine → экспорт через ide_execute_command с command_id chat_export_readable → краткое резюме → согласование с оператором → вставка сжатого текста в тему или в .cascade-ide/agent-notes.md (ide_append_agent_notes и т.д.), без подмены сырого экспорта «чёрным ящиком». Канон сценария: MCP-PROTOCOL.md (раздел «Подведение итогов сессии чата»); плейбук агента: knowledge/playbook-session-summary-and-chat-export-v1.md (репозиторий agent-notes). Тот же паттерн применим к переносу решения из spine в другую тему: сначала явный шаг «сжать и зафиксировать», потом короткая цитата в треде.
Только ссылка в запросе к агенту. «Открой docs/adr/0095-…md, нас интересует только подпункт про umbrella .sln; в ответе — три буллета и риск для CDS.» Полный файл не попадает в контекст, если агент не прочитал его инструментом осознанно.
Опциональное включение spine. Оператор жмёт «добавить сквозную линию в контекст» (или intent в духе 0072) — в пакет уходит ограниченный срез (например последние N вех или одно поле «текущий фокус линии»), а не вся история сессии.

Не-цели¶

Заменить 0072 или 0057.
Ввести в этом ADR полный JSON-схему событий или MCP-поля для spine.
Обещать паритет с внешними продуктами (Comet и т.д.) — см. 0072 Provenance.
Считать, что полный текст spine обязан неявно входить в каждый запрос к агенту — напротив, это анти-паттерн для объёма контекста (см. §4).
Дублировать длинный spine в каждую связанную тему без сокращения объёма (ни короткого мостика, ни явной суммаризации по протоколу вроде экспорта → согласованное резюме): иначе снова «острова» из объёма, а не из смысла.

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

При реализации topic overview карточка трактуется как заголовок + summary, а не как последний bubble.
Появляется явный продуктовый слой spine (сквозная линия продукта) в UX-доках и backlog, согласованный с Intercom (0080); для репозитория Cascade IDE CIDE остаётся удобным рабочим именем примера, не жёсткой привязкой схемы данных.
Расширение ChatThreadOverviewItem (или эквивалента) и тестов overview — ожидаемый шаг после/вместе с 0072 план внедрения.
Политика подачи контекста агенту (что из spine/summary/треда попадает в ACP по умолчанию и по команде) должна быть явной в продукте и в связке с 0048, иначе spine рискует раздувать промпт (см. §4).

Обновлено¶

2026-04-24 — каноническое имя файла ADR: 0096-intercom-topic-card-summary-and-product-spine.md (нейтральный slug product-spine). Прежнее имя файла оставлено как короткий stub для внешних закладок.
2026-04-25 — §4: spine vs контекст агента; перенос зафиксированных решений из spine в тред (carry-forward); не-цели и последствия по объёму промпта; блок Примеры (ручной мостик, chat_export_readable / плейбук, ссылка-only, опциональное включение spine).