ADR 0080: Intercom — имя и модель канала связи (не только «чат с агентом»)¶

Статус: Accepted (strangler: Intercom в UI и docs v1; multi-party и внешний контур — по дорожной карте)
Дата: 2026-04-20

Связанные ADR¶

ADR	Роль
0031	треды, пакеты уточнений, модель сообщений
0057	chat surface → Skia pipeline
0072	topic cards, Melody в домене чата
0096	картотека: сводка на карточке; spine продуктовой линии, CIDE — пример
0045	событийная история, проекции
0048	ACP / MCP и поверхность в IDE
0038	фасад AI, оркестрация
0066	presentation IDE vs кабина
0033	i18n
0120	Intercom в якоре Forward — agent-central layout
0122	Командная среда: станции + общий ситуационный экран (проекция линий работы)

Резюме¶

Intercom — продуктовое имя канала связи (агент + команда + система).
Внешний командный контур vs «своя гора»; strangler для legacy «чат».

Вне ADR¶

Документ	Роль
cascadeide-philosophy-v1	продуктовый нарратив
intercom-ux-reference-slack-mattermost-v1.md	UX-ориентиры Slack/Mattermost; in/out of scope для Intercom в IDE vs внешний контур

Контекст¶

В продуктовом языке слово «чат» почти неизбежно читается как диалог человек ↔ один ассистент (часто — только LLM). Это сужает дизайн: сложнее честно заложить несколько участников, системные реплики (CI, MCP, статусы репо), передачу контекста между людьми и разные политики доверия без когнитивного диссонанса («почему в чате не человек?»).

Параллельно у Cascade уже есть авиационная метафора кабины и внимания (0021, 0066). Intercom (экипажная связь, в быту — intercom) лучше передаёт идею канала, в котором могут быть разные голоса, а не одна «болталка»; при необходимости в UI можно пояснить, что речь не об аппаратной трубке, а о канале связи в IDE.

Техническая цепочка chat surface (0057), треды (0031), topic UX (0072) не обязаны совпадать с пользовательским ярлыком «Чат»: это разные слои (модель / pipeline / копирайт).

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

1. Продуктовое имя: Intercom¶

Канон письма: Intercom (латиница, одна буква m). Вариант с двумя m (Intercomm) в продуктовых строках и доке не использовать — типичная опечатка; см. §4.
Пользовательский термин для основной поверхности связи в IDE — Intercom (один капитализованный бренд в UI).
Внутренние идентификаторы (command_id, пути фич, имена типов) могут оставаться chat* на время strangler-миграции (0009); смена — поэтапно, без «большого взрыва» переименований в одном коммите.
В документации для разработки допустимо параллельно писать «Intercom (ранее в текстах — чат)» до стабилизации глоссария.

2. Ментальная модель: канал, не «окно к боту»¶

Зафиксировать намерение:

В канале могут участвовать несколько ролей: человек(и), агент, система (автоматические реплики: сборка, git, MCP-ответы как структурированные сообщения — по мере зрелости).
Один канал ≠ один собеседник; один тред (0031) остаётся линией работы внутри канала/сессии.
Политики видимости, экспорта, приглашений проектируются исходя из модели «кто в эфире», а не только «что ответил LLM».

Этот ADR не задаёт полную спецификацию мультиплеера, shared sessions и ACL — только рамку имени и семантики, чтобы последующие ADR не спорили с ярлыком «чат».

3. Discoverability и i18n¶

В UI на первых экранах — короткая подсказка вроде подзаголовка или tooltip: связь с привычным словом «чат» или с формулировкой «связь с агентом и командой» — выбор за продуктом; критерий: поиск и онбординг (0013).
Палитра команд и поиск: алиасы на «чат», «chat», «agent» → ведут на те же действия, что и «Intercom», пока не выучен бренд (0030).
Локализация (0033): либо бренд Intercom без перевода, либо отдельное обсуждение локальных заголовков; не смешивать в этом ADR детали ResX.

4. Правописание и поиск¶

Ошибочное написание: Intercomm (две m) — не использовать как бренд; в глоссарии при необходимости одна строка: канон — Intercom.
Внутренние URL/якоря ADR: файл этого ADR назван 0080-intercom-naming-… для совпадения с каноном; старые ссылки на имя файла с intercomm удалить при миграции закладок.
Внутренние якоря внутри текста ADR не переименовываются без необходимости.

5. Готовый «командный контур» vs собственная реализация¶

Полноценный межличностный канал (организация, инвайты, роли, поиск по истории, мобильные клиенты, retention, аудит, офлайн и синхронизация) — отдельный продуктовый объём, не экран в IDE. Тянуть эту гору слоёв целиком внутрь Cascade не обязательно и чаще невыгодно, если уже есть зрелая система записи для людей.

Направление по умолчанию (не привязка к вендору):

Intercom в IDE — то, что у Cascade уникально: контекст воркспейса, агент, инструменты, треды/события вокруг работы над кодом (0031, 0045, 0057).
Командный масштаб «как у Slack» — по возможности снаружи: самохост или корпоративный сервис с API, вебхуками, deep link, уведомлениями; Cascade выступает клиентом интеграции, а не переписывает сервер чата.
Встраивание полного веб-клиента чужого продукта в окно IDE (типично WebView) — допустимо только осознанно: отдельный налог на UX, версии сервера, SSO, фокус и две правды о том, где «живёт» переписка команды; см. границы веб в MFD (0035) как смежный риск, даже если первичная поверхность не MFD.

Примеры класса систем (не норматив для репозитория): Mattermost, Matrix, корпоративные API мессенджеров. Выбор провайдера и контракт интеграции — отдельный ADR или чертёж, когда появится продуктовый коммит.

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

Новые продуктовые ADR и UX-копирайт могут опираться на Intercom как на каноническое имя поверхности связи, а не как на синоним «только агент».
Рефакторинг имён в коде — отдельными шагами, согласованными с объёмом и риском для MCP/снапшотов (0008).
Дорожная карта «люди вне IDE» может явно опираться на внешний командный бэкенд (§5), не дублируя зрелый коммуникационный стек внутри Cascade без необходимости.

Не цели¶

Полная спецификация командных комнат, прав доступа и синхронизации в реальном времени.
Выбор конкретного вендора (Mattermost, Matrix, …) и схема OAuth/SSO — вне этого ADR.
Отмена термина «chat» в коде в день принятия ADR.

Идеи развития (в перспективе Intercom, без коммита на v1)¶

Ниже — направления, которые согласуются с моделью Intercom как канала с разными способами доставки сообщений; они не входят в объём принятия этого ADR и потребуют отдельных спецификаций или ADR.

Голос «пакетами» (async): пользователь записывает короткий фрагмент → распознавание речи → текст (и при необходимости вложение) попадает в тот же тред/событийную ленту, что и обычные реплики. Низкий порог для продукта: не нужен полный дуплекс и не смешивается с «радио» до явного решения.
Выразительный исходящий голос (TTS): отдельная линия работы — дать ответам агента/системы больше эмоционального и просодического разрешения (ударения, паузы, интонация), чтобы звучало естественнее в длинных ответах. В экосистеме продуктов уже есть опора на OpenTTS (самохост, политика данных); детали голосов, SSML и пресетов — не этот документ.
«Реальное радио» (duplex / низкая задержка): когда понадобится синхронный голос между участниками — другой класс требований (VAD, jitter, push-to-talk vs полный дуплекс, права, модерация). Варианты класса: готовые голосовые платформы (например TeamSpeak и аналоги), либо библиотеки и свой транспорт (типично WebRTC/Opus + сигнальный контур). Имеет смысл держать вне ядра IDE или за явным контрактом интеграции (см. дух §5: не тащить «гору» без необходимости).
Дерево сессии и перехват агента: ветвление истории Intercom (продолжить от узла, закладки), разделение steer (перехват после текущего tool) и follow-up (очередь после хода) — канон в 0116; persistence и topic cards — 0045, 0096, 0072.
Якоря на код и другое представление: реплика может ссылаться на контекст в workspace — файл, диапазон строк/столбцов, текущее выделение в редакторе — через устойчивый deep link (открыть, прыгнуть, подсветить участок, о котором речь). Параллельно — альтернативное представление того же якоря: карточка превью, мини-diff, узел/подграф на graph-backed surface, не подменяя собой каноническую модель сообщения. Пересечения: навигация и affordances (0039), контракт выделения/sync для графовых поверхностей (0067); при публикации во внешний командный контур — те же политики приватности и «две правды», что и для §5.

Критерий для будущих ADR: каждая модальность должна быть сопоставима с единой моделью сообщений/событий (0045) и политиками экспорта, а не жить параллельной «второй правдой» без осознанного решения.

Отклонённые альтернативы (кратко)¶

Оставить только «Чат»: сильнее для discoverability, слабее для расширения до «команда + система» без переосмысления.
Только внутренний код/типы под Chat*, в UI «Чат»: рассинхрон метафоры и кода для агента/доков; допустимо как переходный этап, но не как финальный канон без явного решения.

Открытые вопросы (для обсуждения)¶

Финальный заголовок в UI: один термин «Intercom» или «Intercom» + подзаголовок со словом «чат» на первый релиз?
Русская локаль: оставляем латиницу везде или есть короткий русский эквивалент в шапке панели?
Граница с ACP/Cursor (0048): где в копирайте говорим «Intercom», а где остаётся нейтральное «внешний агент»?
Системные реплики: минимальный набор в v1 (только агент + пользователь) или сразу закладывать тип сообщения «system/operator» в модель событий (0045)?
Внешний командный контур: нужен ли провайдер по умолчанию в продуктовой истории и какие критерии (self-host, API, SSO, мобильные клиенты) — до первого ADR интеграции?

Состояние¶

До статуса Accepted нужны: решение по п.1–2 (продукт), согласование с дорожной картой переименования в коде/командах (по желанию отдельный чеклист), при необходимости — одна строка в пользовательском глоссарии (вне этого ADR). П.5 — при появлении коммита на интеграции с внешней командной системой.