ADR 0092: Трек Visual UI (дизайнер разметки) — отдельная крупная программная линия CIDE¶

Статус: Accepted (направление)
Дата: 2026-04-24

Связанные ADR¶

ADR	Роль
0022	Визуальная поверхность разработки UI (AXAML / Blazor) — ориентир WinForms, размещение на MFD
---

Контекст¶

Визуальный дизайнер / live preview для Avalonia (AXAML), Blazor и (опционально) Razor — по объёму не «одна фича на спринт»: хост превью, изоляция, синхронизация с текстом, дерево, property grid, по мере зрелости — drag-and-drop. Ему нужны свой горизонт планирования и явная нарезка MVP, иначе он конкурирует за внимание с критичным путём IDE или, наоборот, теряется без владельца.

Отдельное обсуждение (2026-04-24): зафиксировать трек в ADR, чтобы в бэклоге и обсуждениях было ясно — это CIDE Visual UI track (условное имя), а детали UX и размещения остаются в 0022.

Решение¶

Принять направление отдельной крупной программной линии (трек) Visual UI в рамках Cascade IDE: визуальная работа с декларативной разметкой пользовательского UI (в первую очередь .NET-стек в фокусе CIDE), с бэклогом и критериями готовности по фазам, согласованными с 0022.

Канонический ADR по продукту/UX для этой линии — 0022 (модель внимания, MFD, отсутствие второго TopLevel под превью, фазы MVP / следующий шаг / дальше, не-цели). 0092 отвечает на вопрос «как это вести как трек», а не «как выглядит в кокпите» — при противоречии приоритет у 0022 для продуктовых правил.

Порядок стеков (план приоритета, не сроки):
Первая волна (ориентир): Avalonia / AXAML — ближе к существующему хосту CIDE, предсказуемый контур превью.
Вторая волна: Blazor — отдельный хост (браузер / WebView / изолят), сложнее границы design-time; сценарий пользователя тот же на уровне IDE (0022 п. 4).
Razor (MVC/Pages) и смежное: не часть обязательного MVP трека; отдельное решение (spike / отдельная эпик-задача), т.к. чаще HTML+шаблоны, а не дерево визуальных контролов — иначе размытие границ трека.

Связь с агентом и контрактом: трек ортогонален 0008 и 0052: по мере появления стабильных снимков/команд для design surface (файл открыт, режим превью, выбор узла) — расширения MCP/CLI вносятся сознательно, с тем же требованием паритета JSON, без дублирования логики. До появления таких API трек не блокируется на «сначала все тулы агента».

Граница с другими треками: не относить к этому трёку EICAS/HUD, «облачный inline» и прочие контуры, перечисленные в 0022 как не-цели с точки зрения зоны внимания; не путать Cockpit UI (приборы CIDE) с дизайнером пользовательского приложения — см. 0066.

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

Плюсы	Минусы / риски
Ясная корзина задач: легко говорить «в треке Visual UI / вне трека»	Нужна дисциплина не раздувать трек «всё про UI в мире»
0022 остаётся единым местом продуктовых правил; 0092 не дублирует таблицу фаз	Два ADR вместо одного — зато меньше дрейфа «процесс vs продукт»
Порядок Avalonia → Blazor → (опц.) Razor снижает риск одновременного взрыва стеков	Открытые вопросы 0022 (минимальный v1 по технологиям, вкладка MFD, двусторонняя синхронизация) — по-прежнему в 0022; трек не закрывает их автоматически

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

Явные имена в бэклоге/метках (одна линия GitLab / теги) — на усмотрение репо; в ADR зафиксировано смысловое имя Visual UI / design surface в связке с 0022.
SDK / плагины (0024): если дизайнер когда-либо вынесется в расширение, это отдельное ADR, не 0092.

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

Считать дизайнер только «частью» Markdown preview или WebView-ADR — отклонено: слишком разный предмет (авторский Markdown vs пользовательский AXAML/Blazor).
Расширять 0022 таблицей «как вести бэклог» — возможно, но вынесено в 0092, чтобы 0022 оставался коротким продуктовым ADR.