Отладка: единый слой для человека и агента (целевое видение)¶

Статус: зафиксированная цель продукта; реализация по мере итераций.
Связь: MCP-PROTOCOL.md, architecture-policy.md. Решение в формате ADR: adr/0002-debug-human-agent-parity.md.

Зачем¶

CascadeIDE позиционируется как IDE, которой агент управляет через MCP, при этом человек остаётся в одной среде с агентом. Для редактирования и UI это уже близко к одному каналу (тулы меняют то же окно, что видит пользователь).

Для отладки пока возможен разрыв: агент может выставлять брейкпоинты и получать стек/переменные через отдельный контур (например внешний dotnet-debug-mcp + файлы брейкпоинтов), а в самой IDE пользователь не обязан видеть те же маркеры и то же состояние остановки. Тогда совместная работа («я на строке X, переменные такие — шагаем дальше?») становится ненадёжной.

Цель (критерий «сделано»)¶

Один источник правды по состоянию отладки внутри CascadeIDE:

Брейкпоинты — те же, что в глифах редактора и в списке точек, что и те, что отражают ide_set_breakpoint и канонический snapshot/debug read API.
Останов — текущая строка и подсветка в редакторе совпадают с тем, что агент может запросить через MCP (ide_get_debug_snapshot, состояние панели отладки).
Стек и переменные — данные в UI панели отладки и данные, которые агент получает через MCP (ide_debug_stack_trace, ide_debug_variables, ide_get_debug_snapshot), согласованы (одна сессия / одна модель, а не два независимых процесса без синхронизации).

Внешние отладчики (netcoredbg, DAP) могут оставаться движком, но состояние для человека и для MCP должно проходить через слой IDE, а не расходиться «в обход».

Не цель этого документа¶

Не дублировать канон agent-notes по общему backlog MCP+IDE — только фиксация видения по отладке.
Не описывать пошаговую реализацию — её ведут задачи в коде и при необходимости отдельные ADR.

История¶

Документ введён, чтобы явно закрепить требование паритета человек/агент в отладочном контуре.