Перейти к содержанию

ADR 0093: Встроенный просмотр URL запуска на MFD (расширение к профилям и launchBrowser)

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

Связанные ADR

ADR Роль
0090 семантика launchBrowser и URL из Kestrel / ASPNETCORE_URLS
0002 один смысл запуска — разные поверхности просмотра, без второго «типа» отладки
0075 страницы MFD / слоты
0021 кокпит: стек, лог, гипотезы + контент сессии рядом
0091 PFD vs Mfd

Контекст

В 0090 зафиксированы Kestrel-профили, импорт из Properties/launchSettings.json и смысловой флаг открыть браузер после старта процесса. В реализации baseline это внешнее открытие URL (системный браузер), что совпадает с привычным поведением Visual Studio и не требует встраивать движок рендеринга.

Одновременно продуктовая линия CIDE — кокпит (MFD, отладка, агент): разработчику и агенту выгодно не покидать IDE, чтобы видеть отрисованную страницу по тому же http(s)://…, что отдаёт Kestrel, — рядом со стеком, точками останова и каналом отладки. Вопрос не в замене MSBuild/DAP, а в третьей оси после «какой профиль / какой URL»: где показать тот же URL.

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

  1. Не заменять внешний браузер: он остаётся каноничным default для launchBrowser (OAuth, расширения, привычные DevTools, изолированные профили). Встроенный просмотр — дополнение, включаемое явно.
  2. Опция UX (имя ключа в настройках workspace или пользователя — детализация при реализации), например смыслы: внешний | MFD | спросить один раз / per-session. Семантика запуска и env не меняется: меняется только поверхность навигации после успешного LaunchAsync.
  3. Источник URL — тот же, что для текущей логики KestrelLaunchBrowser / launchBrowser: первый подходящий http/https из эффективного окружения (в т.ч. ASPNETCORE_URLS после мерджа с профилем). Паритет «что открыли» с внешним режимом обязателен.
  4. Размещение: отдельная страница или регион MFD (см. 0075), в типичном сценарии рядом с DebugStack / инструментацией, без перехвата PFD-зоны целиком (ср. 0091).
  5. Технология встраивания — вынести в отдельный подпункт реализации: на Windows — естественный кандидат WebView2; кросс-платформенная матрица (Linux/macOS) — отдельный срез (не блокирует Proposed-решение, но влияет на roadmap).
  6. Паритет агента (MCP): контракт debug_launch / профилей не обязывает знать о MFD. Агент по-прежнему оперирует workspace + target + профилем; выбор внешний vs MFD — настройка IDE для человека (и опционально идемпотентный хинт в settings, если когда-либо понадобится в протоколе — только как необязательное расширение).

Последствия

  • Появляется зависимость от встраиваемого web runtime и политик безопасности (навигация, mixed content, localhost TLS) — бюджет сопровождения отдельно от «просто Process.Start».
  • Нужны правила жизненного цикла: смена URL при перезапуске отладки, закрытие вкладки при debug_stop, отсутствие «зависшего» web view без сессии.
  • Документация User Guide: когда предпочесть MFD, когда внешний браузер (коротко, продуктовый слой).

Отклонённые / вне scope

  • Только встроенный браузер без внешнего пути — отклонено: ломает типичные сценарии логина и привычный DevTools-контур.
  • Полный паритет с Chrome DevTools внутри IDE — вне scope. Для v1 встроенного режима достаточно обычного рендеринга страницы по тому же URL (как во внешнем браузере: разметка, стили, скрипты на странице), без панели Network, Application, Performance и остального контура DevTools.
  • Удаление launchBrowser: false при выборе MFD — неверно: флаг остаётся про «надо ли открывать URL вообще»; поверхность — второй уровень.

Статус внедрения

  • Не реализовано. Текущий baseline: внешний браузер по 0090. Настоящий ADR фиксирует направление и границы, чтобы не смешивать с рефакторингом DAP/профилей.

Implementation checklist (когда возьмём в работу)

  1. Настройка поверхности (external / mfd / ask) и маршрутизация из того же пути, что сейчас ведёт к KestrelLaunchBrowser.
  2. MFD: страница + web host (WebView2 и т.д.); согласовать с 0075.
  3. События жизненного цикла отладки: старт, стоп, смена профиля — обновить или очистить view.
  4. Тесты: по возможности headless/интеграционные на уровне «URL передан view», без полного E2E браузера в CI (уточнить в пайплайне).
  5. User-facing: одна мини-секция в User Guide, ссылка из 0090 / этот ADR.