ADR 0095: Три уровня Health — Workspace, Solution, IDE (таксономия каналов)¶
Статус: Accepted (частично: WorkspaceHealth MFD + каналы; полная трёхуровневая таксономия — по ADR)
Дата: 2026-04-24
Обновлено: 2026-04-25 — TOML-ключи IDE Health: ide_health_*. Подробности — § История.
Связанные ADR¶
| ADR | Роль |
|---|---|
| 0089 | продуктовое имя IDE Health и типы IdeHealth*; не снимает смешение сигналов по смыслу |
| 0097 | CCU / вычислительный блок: где живёт свёртка входов в DTO при сохранении stratum |
| 0102 | DAL: где добываются внешние данные до CCU |
| 0021 | канал vs слот презентации; глоссарий |
| 0036 | канал → CDS → композитор → поверхность |
| 0023 | Канал «готовность окружения» (glance) — отдельно от IDE Health |
| 0022 | лексикон и эволюция имён |
| 0019 | Git как сквозной контур |
| 0062 | GitMap — файловая/git-геометрия отдельно от кода решения |
| 0052 | снапшоты MCP — при сплите уровней потребуются явные секции или версия схемы |
Резюме¶
- Три уровня Health: Workspace · Solution · IDE; поле
stratum. - Strangler от монолитного «workspace health»; TOML
ide_health_*(0010).
Вне ADR¶
| Документ | Роль |
|---|---|
environment-readiness-glance-v1.md |
канал готовности окружения — уже ближе к уровню IDE |
workspace-health-implementation-map-v1.md |
текущая карта полосы IDE Health |
Контекст¶
После 0089 канал в продукте называется IDE Health, но по смыслу в один пользовательский образ (полоса, кокпит, снапшот для агента) по-прежнему попадают сигналы разной природы:
- Файловая и VCS-стихия — корень открытого workspace, git status/ветка/удалённость, субмодули, «грязь» дерева; часть этого не исчезает при смене solution внутри того же каталога и не является диагностикой компилятора.
- Жизнь решения / проекта — результат MSBuild, счётчики/статус тестов, ошибки компиляции, Roslyn-диагностики в привязке к открытому solution; меняется при смене
.sln/ конфигурации / целевого фреймворка. - Жизнь процесса IDE и окружения — LSP (C#, Markdown, …), MCP-транспорты, выбранный режим AI, доступность
dotnet/инструментов из 0023; остаётся истинным, если закрыть solution, но не переустанавливать IDE.
Смешение уровней мешает:
- агенту и MCP — в одном JSON легко принять «состояние папки» за «состояние сборки» или наоборот;
- CDS и будущим каналам — один «health» без тега уровня плохо масштабируется на новые инструменты (0036);
- UX — оператору нужны разные контексты внимания (см. 0021): «что на диске», «что с билдом», «что с хостом IDE».
Этот ADR вводит нормативную таксономию трёх уровней и направление на разведение каналов / секций данных; он не обязан в одном коммите переписать всю реализацию IdeHealth* (ключи TOML контура в UiModes — ide_health_*, 0010).
Решение: три уровня (семантика)¶
Зафиксировать три оси смысла для Health и аналогичных каналов наблюдаемости:
| Уровень | Рабочее имя в текстах | Вопрос «о чём речь?» | Типичные сигналы (примеры, не исчерпывающе) |
|---|---|---|---|
| A | Workspace | Каталог(и) workspace на диске и VCS вокруг него | путь корня, git branch/ahead/behind, чистота рабочего дерева, субмодули (0062), конфликты merge |
| B | Solution (или Solution / project) | Открытое решение и артефакты сборки/тестов | статус/текст сборки, тесты (пройдено/упало), ошибки компиляции, целевая TFM/конфигурация, при необходимости — выбранный startup project |
| C | IDE | Процесс IDE, хосты и окружение, не дерево исходников | LSP alive, MCP подключения, режим AI, проверки PATH/EXE из 0023, внутренние сервисы |
Инвариант: любой новый «health» или канал наблюдаемости объявляет, к какому уровню (A/B/C) он относится; запрещено silently смешивать уровни в одном DTO без явной структуры или дискриминатора.
Имя поля в машинных контрактах (JSON, MCP, CDS): рекомендуется ключ stratum со значениями workspace | solution | ide в паре с дискриминатором источника сигнала (например diagnostic_source для Roslyn-ветки). Ось A/B/C не называть в контракте level: слово чаще читается как приоритет, глубина стека или severity и хуже дискриминируется в логах и UI.
Представление (UI): три уровня не означают автоматически три отдельные полосы на экране. Допустимы: одна составная полоса с внутренней группировкой по уровням; несколько инструментов в одном якоре (0063); отдельные страницы MFD. Норматив — семантика данных, а не конкретная вёрстка v1.
Направление на реализацию (strangler)¶
- CDS / снапшоты: при эволюции контракта кабины (
cds-contract-v0.md) — секции или подканалы с полемstratum(workspace|solution|ide) либо отдельные каналы с явными именами; детальный JSON не фиксируется этим ADR. - MCP /
get_ide_state: при расширении ответа — не добавлять поля «в общую кучу»; новые блоки должны быть помеченыstratum(и при необходимости источником, напримерdiagnostic_source) или вынесены в отдельные тулы, если смешение сохраняет путаницу (0089, 0052). - Код текущего IDE Health: поэтапно разнести сборку входного снимка (
workspace-health-implementation-map-v1.md) на провайдеры по уровням A/B/C с одной точкой композиции для UI; wire-ключи режимов для контура —ide_health_*(0010). Архитектурная роль «свёртки» в снимок/DTO — см. 0097.
Пример: отдельные вычислители по стратам (не God-object)¶
Один God-object, который тянет и Git, и MSBuild, и LSP в одном методе, не целевой паттерн. Нормативное направление — несколько cockpit compute units (CCU) с узким контрактом входа/выхода и одна точка композиции для канала/UI. Ниже — рабочие инженерные имена-сокращения (обсуждения, ревью, комментарии); не требование так назвать типы в C# в ближайшем коммите.
| Уровень | Рабочее имя (англ.) | Сокращение | Типичный смысл свёртки |
|---|---|---|---|
| A | Workspace Status Computation Unit | WSCU | каталог(и) workspace, VCS, субмодули, «грязь» дерева |
| B | Solution Status Computation Unit | SSCU | открытое решение, сборка, тесты, TFM/конфигурация |
| C | IDE Status Computation Unit | ISCU | процесс IDE, LSP, MCP, окружение (0023) |
ISCU — про уровень C и статус хоста/IDE; не путать с IDS (0079 — Ide Display System, оверлеи). При письме «в одном предложении с IDS» лучше писать ISCU полностью или явно дискриминировать аббревиатуру.
Границы и открытые вопросы¶
Границы (не цели этого ADR):
- Конкретные имена типов (
IWorkspaceHealthChannelvs три интерфейса), дальнейшая эволюция схемы DTO, немедленный сплит AXAML на три контрола. - Отладка как отдельный продуктовый контур (0002) — ортогональна; связь с уровнем B/C (сессия решения vs процесс IDE) уточняется при моделировании, без подмены этого ADR полным debug-ADR.
Открытые вопросы:
- Git одновременно относится к A (ветка, ahead/behind) и может отражать состояние билда в смешанных сценариях — нужны правила приоритета и дубликатов в UI.
- Roslyn: часть диагностик — про решение (B), часть — про анализаторы/окружение (C); см. уточнение ниже.
- Несколько корней на диске — как сопоставить уровень A (VCS/файлы), когда в одном окне не один смысл «папка на диске»; см. уточнение ниже.
Уточнение: Roslyn — B vs C и единый вывод в UI¶
Сводный UI для пользователя (одна полоса, один список диагностик) ничему не противоречит и согласуется с абзацем «Представление (UI)» в таблице уровней: три уровня A/B/C — про семантику данных, а не обязанность трёх отдельных визуальных полос.
Для реализации граница B/C по Roslyn часто извлекаема из модели (компилятор vs идентификатор анализатора, проект, правила), но не всегда однозначна по смыслу: одна и та же ошибка в UI может отражать и код, и окружение (восстановление пакетов, TFM, SDK); анализаторы из пакетов решения формально относятся к B, а ощущаются как «политика/настройка»; сбой загрузки анализатора — уже явный C.
Для пользователя граница когнитивно часто неочевидна: всё сливается в «IDE ругается», растёт риск неправильной атрибуции (чинить код вместо среды). Поэтому в контрактах снимка для CDS/MCP/агента полезно сохранять stratum и источник (например diagnostic_source), даже если в штатном UI показ объединённый; при необходимости — лёгкие маркеры в UI (группа «среда» vs «код») или раскрытие «подробности».
Уточнение: «зонтичное» решение и настоящий multi-root¶
Один файл .sln / .slnx как точка входа, в котором перечислены проекты с относительными путями, выходящими за каталог этого файла, — для уровня B штатная ситуация: граф сборки и тестов задаётся манифестом решения целиком, независимо от того, что часть исходников физически лежит «сбоку» от каталога файла решения.
Для уровня A тот же сценарий не подменяет собой multi-root окна: вопрос сводится к геометрии git — один репозиторий, охватывающий все задействованные пути (тогда A один: один worktree и одна картина «грязи»), либо несколько вложенных/соседних репозиториев по разным корням (тогда возможны несколько источников A и нужна явная политика: приоритетный корень сессии, вторичные, агрегат без silent merge в одно поле).
Multi-root окна в смысле «несколько независимых корней без единого файла решения как точки входа» — другой продуктовый режим; он остаётся открытым по UX и по тому, какой каталог считать единственным «корнем» для снимка A, но не смешивается в этом ADR с зонтичным решением выше.
Отклонённые альтернативы¶
- Оставить один канал «IDE Health» без внутренней таксономии — отклонено как накопление технического долга для CDS, MCP и новых каналов.
- Переименовать уровни в «Workspace Health / Solution Health / IDE Health» как три продукта — отклонено: слово workspace в пользовательском имени снова тянет путаницу с каталогом (0089); в продуктовых строках предпочтительны формулировки вроде «состояние папки и Git», «сборка и тесты», «среда IDE» при сохранении уровней A/B/C как внутренних идентификаторов и ключей контракта.
Последствия¶
- Новые фичи и ADR, затрагивающие наблюдаемость, ссылаются на этот ADR и явно указывают уровень A/B/C (или осознанное нарушение с обоснованием).
- Рефакторинг
IdeHealth*становится планируемым с трекингом по уровням, а не только косметическим переименованием.
История изменений¶
| Дата | Изменение |
|---|---|
| 2026-04-25 | ссылки на TOML: ключи IDE Health в UiModes — ide_health_* (0010); формулировки про миграцию workspace_health_* приведены в соответствие с репозиторием. |