ADR 0084: Правки агента в редакторе как единственный текстовый источник правды; чат — намерение и статус; слой присутствия (GDocs-like, без обязательного CRDT)¶

Статус: Proposed
Дата: 2026-04-20

Связанные ADR¶

ADR	Роль
0031	чат агента, поверхность, потоки
0038	фасад агента, инструменты
0048	ACP, MCP, паритет тулов
0042	preview / review before apply — ортогонально, может совпасть по политике «ghost»
0080	Intercom как канал; масштаб «командный продукт» — вне baseline
0082	один процесс IDE ↔ MCP — хорошая база для одного буфера правды
0021	образ «как collaborative editing» для баннера активности — см. таблицу file-level feedback
0079	оверлеи IDE — возможная поверхность для присутствия
0063	Presence/Activity как продуктовый язык
## Резюме

Редактор — единственный source of truth текста; чат — намерение/статус.
Слой присутствия (курсор, «пишет»); дифф в чате не основной.

Контекст¶

В типичном UX «чат + агент» правки кода показывают в боковой панели как диффы, патчи или длинные цитаты. В полноценной IDE пользователь уже смотрит в редактор и на файловую систему: дублирование того же текста в чате съедает контекст LLM и ломает поток «я смотрю в код», а не в переписку.

Продуктовый образ совместного редактирования (курсоры, «печатает», выделение) здесь полезен как метафора UI: не обязательно полноценный multi-user CRDT как в Google Docs; достаточно одностороннего стриминга состояния агента и локального применения правок к буферу.

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

Проблема¶

Два «экрана правды»: текст правки и в чате, и в файле — конфликт внимания и риск рассинхрона с тем, что пользователь редактирует локально.
Контекст ассистента: повтор диффа в чате тратит окно контекста на то, что уже есть на диске/в буфере.
Скорость и доверие: основной способ «увидеть правку» должен быть там, где пользователь уже принялся работать — в редакторе, с ясной подсветкой активной зоны и политикой применения (см. ниже).

Решение (принципы, без привязки к стеку)¶

1. Единый источник правды — документ в редакторе¶

Итоговый видимый текст кода (и применённые правки) живёт в буфере редактора и при сохранении — в файле.
Изменения от агента моделируются как операции над буфером или поток правок с позициями, а не как «картинка патча», которой пользователь обязан верить, не открыв файл.
Инструменты редактирования (ide_*, MCP-контур) привязываются к открытым документам и к визуализации в редакторе, а не к обязательному дублю в чате.

2. Чат — канал намерения и статуса¶

В чат уходят короткие сообщения, команды, уточнения, статус («сделал X», «нужен выбор»), ссылки на файлы/диапазоны — но не основной способ читать большой дифф.
Дифф в чате допускается как опциональный свёрнутый лог (аудит, копипаст, внешний хост без доступа к IDE) — не как продуктовый default «где смотреть правки».

3. Слой присутствия (отдельный канал данных)¶

Поток, ортогональный тексту файла:

позиция курсора / выделения агента в буфере;
индикатор «пишет» (typing);
опционально имя / роль (агент, сценарий).

Это не требует «настоящего» Google Docs CRDT для двух людей: достаточно стриминга от агента + локальной проекции в оверлей/декорации редактора.

4. Политика применения: preview vs live¶

Продуктовый выбор (может комбинироваться по режиму доверия / пути):

Ghost / предпросмотр → явное «принять»; или
Live с сильным undo и историей буфера.

Связь с существующими идеями pre-flight / review — 0042; этот ADR не подменяет его, а согласуется по оси «где пользователь видит намерение».

5. Безопасность и контроль¶

Видимость правок в том же окне, что и рабочий код, снижает «сюрпризы» по сравнению с потоком только в чате.
По-прежнему нужны: стоп, откат, read-only для чувствительных путей, политика доверия — ортогонально настоящему размещению UI (см. 0071).

Риски и нюансы¶

Риск	Направление смягчения
Конфликт с одновременным редактированием человеком	Блокировка участка, явное pause agent, merge policy, или «agent lost» с повторным выравниванием
Частый review-only (мало собственного ввода в буфер)	Не снимает строку выше: политика нужна для активного набора, других участников и любых сценариев с двумя авторами правок
Большие файлы	Стримить дельты и/или видимый регион; не перерисовывать весь файл на каждый токен без необходимости
Мультивкладки	Явная привязка целевого буфера / файла к сессии агента; визуальный акцент «агент в этой вкладке»
Внешний хост (ACP без локального редактора)	Fallback: компактный дифф в чате или в отдельном viewer — не отменяет канон для полноценной IDE

Отклонённые и границы¶

Весь дифф только в чате как основной UX для IDE — отклонено для сценария «я смотрю в код» (допускается как опция/аудит).
Обязательный полноценный CRDT для двух людей в v1 — не требуется; при появлении реального multi-user редактирования — отдельное решение поверх этого ADR.
Дублировать норматив чата из 0031 — не цель; этот ADR фиксирует разделение ролей экранов (чат vs редактор).

Состояние реализации и следующий шаг¶

Реализации как единого продукта «присутствие + только редактор» в коде может ещё не быть; это ориентир архитектуры UX. Следующий шаг — сценарии (live vs preview), события (cursor, edit, save, typing), таблица «что уходит в чат vs только в редактор/оверлей», и привязка к конкретным командам MCP / слоям IDS при принятии.