ADR 0021: PFD / MFD — модель внимания кокпита Cascade IDE¶

Статус: Accepted
Дата: 2026-04-06
Обновлено: 2026-04-15 — отсылка к 0037 (география PFD vs строгая поверхность). Подробности — § История.

Поглощает: concept-pfd-mfd-cascade-v1.md (черновик концепта → формализован здесь).

Связанные ADR¶

ADR	Роль
0010	режимы UI, TOML
0012	плавающий хром
0013	команды и discoverability
0017	мультиоконность
0016	ACP / внешний агент
0005	плагины отложены; когда появятся — §«Плагины и модель внимания» ниже
0022	лексикон имён

Вне ADR¶

Документ	Роль
`power-mode-concepts-v1.md`	UX: режимы Power
`cascade-ide-ui-layout-v1.md`	UX: раскладка UI
`concept-to-implementation-map-v1.md`	Карта концепт → код
`command-palette-ux-concept-v1.md`	UX Command Palette
`workspace-health-implementation-map-v1.md`	Карта реализации IDE Health / EICAS

Резюме¶

PFD / Forward / MFD / EICAS / HUD — якоря внимания и политика плотности UI, не обещание «встроить все приложения мира».
Пресеты (TOML, 0010) задают где инструменты; режимы Focus/Balanced/Power — как управлять потоком внимания поверх якорей.
EICAS — единый сводный канал оповещений; подсистемы подают события, а не конкурируют toast’ами в лобовом редакторе.
Идеи ARINC 661 — один композитор и границы зон; сертификация и полный профиль 661 вне scope.
Внешние агенты и чаты — мосты (0016), без второго «кокпита» в зоне PFD.

Контекст¶

Разработчик в IDE оперирует десятками сигналов: код, сборка, тесты, агент, git, безопасность. Без явной модели приоритетов внимания интерфейс скатывается к двум крайностям: «всё спрятано» (Focus без обратной связи) или «всё видно» (Power с баннерной слепотой).

Авиация решила эту задачу разделением приборных панелей по роли в управлении вниманием: PFD (первичный полётный дисплей), MFD (мультифункциональный дисплей), EICAS/CAS (система оповещения экипажа). Этот ADR переносит модель в контекст IDE и фиксирует принципы, дизайн-критерии и открытые решения.

Философия: переключение контекста и устойчивый контур внимания¶

Главный налог на продуктивность разработчика — переключение контекста и вынужденный выход из IDE: не только Alt-Tab, но и потеря потока, «где я смотрел», какой канал коммуникации сейчас актуален. По-хорошему IDE стремится к единой сцене: код и рядом — минимум необходимого для текущей задачи и коммуникации, чтобы таких переключений было меньше.

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

PFD / MFD / HUD / EICAS в этом ADR направлены не на обещание «встроить всё», а на устойчивый контур внимания: предсказуемые якоря взгляда, что видно по умолчанию, что — осознанным переключением в MFD, что остаётся снаружи (второй монитор, внешний клиент) и связывается мостом (ADR 0016, буфер, deep link) без дублирования полного второго «кокпита» в зоне PFD. «Одно окно» в зрелом смысле — это согласованный контур, а не монолит всех приложений мира.

Когнитивная нагрузка и нейроотличие (продуктовая связка, не медицина)¶

Зачем упоминать в ADR: принципы выше принимаются по эргономике внимания и снижению переключений контекста. Отдельно фиксируем продуктовую линию: у части пользователей те же переключения и конкурирующие сигналы стоят дороже — в том числе при СДВГ и других нейроотличиях. Это не утверждение о «лечении» интерфейсом, не добавляет технических инвариантов к §1–§18 и не меняет критерии §18; это обоснование, почему тема уместна в онбординге, пресетах и дисциплине плотности UI (см. §16, §19).

Связь с моделью (идея, не норма): явная иерархия якорей (лобовое / PFD / MFD), сводный канал оповещений (EICAS), HUD внутри лобового и Dark Cockpit в штатном режиме направлены на снижение лишнего трения при возврате в поток после прерывания и при сортировке сигналов. Индивидуальные различия велики; пресеты, гибкость и отключение шума остаются обязательными.

Связанный публичный эскиз (вне этого репозитория, краткий нарратив для читателя): Attention, friction, and neurodivergence in the IDE (EN); Внимание, трение и нейроотличие в IDE (RU). Длинную продуктовую дискуссию не дублировать в ADR — только указатель.

Идеи из ARINC 661 (переносимые, не копия стандарта)¶

В авионике ARINC 661 задаёт интерфейс между прикладными системами и системой отображения (CDS, Cockpit Display System): данные и команды идут в общий контур, а композиция экрана, слои и приоритеты — у одного дисплейного рантайма. Cascade не реализует профиль 661 и не требует сертификации под него; переносим архитектурные принципы, которые снижают риск «каждая подсистема рисует своё поверх всего».

Идея 661	Как используем в этом ADR
Один композитор «стекла» — много источников данных	EICAS и размещение каналов внимания — единый контур; сборка, Git, агент, MCP и т.д. подают события и состояние, а не владеют отдельным слоем toast’ов поверх редактора без правил (см. §5, §6).
Границы ответственности	Зоны `forward` / `pfd` / `mfd` / `eicas` и пресеты (§2, §2.1): что может оказаться в PFD vs только в MFD — политика, а не гонка плагинов за z-order.
Приоритет и слои как схема	Уровни Warning / Caution / Advisory (§5) и правило Dark Cockpit (§6): иерархия внимания задаётся явно, а не порядком инициализации расширений.
Декларативное описание + привязка к данным	Ориентир для `workspace.toml`, `AttentionZonePanelRuntime` и будущего merge слоёв: что на экране и откуда значения — проще согласовать с репо и тестировать, чем разрозненная императивная раскраска.

Не переносим: требования сертификации, совместимость с поставщиками авионики, полнота модели виджетов 661 как таковой. DO-178C (процесс доказательства безопасности ПО на борту) в продукт не импортируем — при необходимости отдельные части контура агента могут позже жить под иной дисциплиной гарантий; это вне scope данного ADR.

Архитектура зон (зафиксированные выводы)¶

Якоря и поток внимания (не смешивать)¶

Пространственные якоря — где в окне (или на каком мониторе) находится зона: три региона лобовое / PFD / MFD, плюс отдельно канал EICAS и слой HUD внутри лобового. Пресет задаёт размещение инструментов в этих регионах. Несколько панелей, отнесённых к одной зоне (например обе к pfd), по этой модели должны составлять содержимое одного якоря — композиция внутри региона (вкладки, страницы, стек), а не две независимые позиции на экране, которые лишь помечены тем же id. Строковый id зоны не кодирует «слева / центр / справа» (см. §«Идентификаторы зон» ниже) — геометрию задают каркас окна и пресет — но семантика id — именно «какой регион якоря», ожидаемое место на сцене, а не произвольная метка только в данных без соответствующего региона на экране (цель реализации — явная привязка лэйаута к якорям).

Attention flow (поток внимания) — как управляются фокус и приоритет: режимы Focus / Balanced / Power, полоса EICAS, escalation, осознанный переход во вторичное. Это политика поверх якорей; ею нельзя заменять физическую расстановку зон и нельзя смешивать с ней в документации и коде.

На одном экране целевая модель внимания — три зоны (три «якоря» взгляда), без разбегания по произвольному числу окон. Содержимое зон не переносится из PFD в MFD и обратно в рантайме: роль каждой зоны задаётся пресетом (например TOML, ADR 0010) с возможностью переопределения пресета — пользовательского и/или на уровне workspace репозитория (см. §2.1), а не свободного драг-н-дропа между семантиками.

Зона	Роль	Содержание (ориентир)
Лобовое	Доминирует по времени и площади; объект работы	Редактор (активный документ). HUD (§9) — не отдельная зона: inline-подсказки, диагностика по месту, ghost text и т.п. обогащают лобовое, не добавляют четвёртый якорь внимания.
PFD	Текущий контекст полёта: где мы в workspace, над чем работаем, что мешает	Обозреватель решения, позиция/контекст в решении, задача/сессия как «маршрут», Problems/diagnostics при наличии, при необходимости — компактные индикаторы «что сейчас критично» (детали — в пресете).
MFD	Всё вторичное, переключаемое осознанно	Git, вспомогательная информация, документация, встроенный браузер, полный чат/trace, терминал, длинные логи, отладка, расширенные операции агента — по списку пресета.

География зоны PFD ≠ один инженерный контракт на все панели в колонке. Регион внимания PFD может одновременно содержать интерактивную навигацию (например обозреватель решения) и компактные «приборы» (статус агента, EICAS, здоровье workspace). Строгие инварианты кода (input lock, weight, каналы) применяются только к компонентам, явно помеченным как строгая PFD-поверхность; см. 0037 § Зона внимания и строгая поверхность.

Содержимое якорей PFD/MFD не исчерпывается одним контуром IDE Health. В регионе якоря по пресету может быть любой инструмент, согласованный с ролью зоны (контекст полёта vs вторичное): сводка build/tests/debug/git в виде страницы вместо полосы, схема зависимостей, обозреватель символов, встроенный браузер, Git и т.д. — в том числе рядом (вкладки, стек, split внутри региона). Термин Page в конфигурации канала IDE Health (ide_health_surface → dedicated page vs strip; чертёж workspace-health-implementation-map-v1.md) означает только выбор слоя представления для этого канала (крупная область в якоре вместо нижней полосы), а не определение «что вообще может жить в PFD/MFD».

EICAS (§5) — канал оповещений и приоритизации (W/C/A), а не третья «колонка» рядом с лобовым / PFD / MFD. Размещение на экране — открытый выбор пресета: горизонтальная полоса, оверлей, компактный список или иной вариант разметки представления; на маленьком экране критично не смешивать роль канала с конкретной геометрией одной реализации.

Мультимонитор: те же три семантики физически разносятся по дисплеям. Маленький экран: мало площади — допускаются режимы, стек панелей, сворачивание без смешения ролей зон и без переноса инструментов между PFD и MFD без смены пресета.

Плагины и модель внимания (будущее)¶

Когда появятся плагины / сторонние расширения UI (0005 — сроки открыты), они не могут быть «просто ещё одним окном поверх всего» без семантики: иначе модель PFD/MFD/EICAS/HUD теряет смысл и снова возникает гонка за z-order и внимание, от которой этот ADR уводит продукт.

Правило: всё, что расширение хочет показать в интерфейсе IDE, обязано быть привязано к модели внимания — явно: к якорю (forward / pfd / mfd), к каналу (например EICAS, IDE Health) или к слою (HUD на лобовом), в рамках пресета (0010, §2.1). Формулировка для автора расширения: «реши, чем ты являешься в кокпите» — иначе интеграция не проходит контракт.

Следствия: контракт загрузки расширения включает декларацию роли (не только технический entry point); произвольная плавающая панель без привязки к зоне — не целевой паттерн.

1. Термины (авионика → IDE)¶

Авионика	Определение	Аналог в Cascade
Лобовое (не авиационный термин; здесь — роль зоны)	Прямой обзор «наружу» — главный фокус	Редактор; внутри него — HUD (§9)
PFD (Primary Flight Display)	Показатели, нужные для удержания контекста и безопасного продолжения работы без потери ориентира	Зона текущего контекста: решение, где мы, над чем работаем, проблемы/диагностика (см. таблицу выше)
MFD (Multi-Function Display)	Тяжёлые переключаемые виды, не конкурирующие с первичным контекстом и лобовым за постоянный фокус	Git, доки, браузер, длинные логи, чат/trace, терминал и т.д. — по пресету
EICAS / CAS (Crew Alerting System)	Консолидированный список сообщений с приоритизацией	Единая сводка оповещений (§5); не «четвёртая зона» в смысле трёх якорей § выше
КВС (командир воздушного судна, Pilot in Command)	В авиации — лицо, несущее ответственность за безопасность полёта и решения экипажа	Метафора в документации Cascade: человек-оператор в контуре IDE (не агент), владеющий итоговым решением. Не синоним PF (§1.0: «руки на штурвале» / активное ведение). Формулировки вроде «сигналы КВС» при Incapacitation / присутствии относятся к состоянию оператора (присутствие, внимание), ортогонально телеметрии репозитория (IDE Health, канал EICAS про код/сборку).
HUD (Head-Up Display)	Проекция на лобовое стекло без отвода взгляда	Только внутри редактора (§9); отдельной зоны не образует

1.0 PF/PM как Driver/Navigator (ментальная модель)¶

PF/PM из авиации почти напрямую сопоставляются с парным программированием:

PF (Pilot Flying) ≈ Driver: “руки на штурвале” — активные действия и быстрый цикл правок. В IDE это прежде всего лобовое/редактор и минимальные HUD-подсказки по месту.
PM (Pilot Monitoring) ≈ Navigator: удержание общей картины, риски, чеклисты, координация и контроль отклонений. В IDE это прежде всего PFD/MFD/EICAS как вторичные поверхности: диагностики, план, логи, Git, trace агента — по пресету.

Это сопоставление используется как язык для обсуждения компромиссов: что должно оставаться PF/Driver‑friendly (не конкурировать с лобовым), а что является PM/Navigator‑инструментом и живёт во вторичных зонах.

1.1 Канал, слой представления, имена в коде (канон)¶

Ориентир для чертежей реализации и комментариев в коде: одни и те же слова — одни и те же смыслы. Три разных «хоста» не смешивать: см. строку ProcessHost и примечание про канал vs View.

Термин	Значение
ProcessHost	Внешний процесс-хост, который поднимает или подключается к CascadeIDE (например Cursor/IDE, запуск IDE с `--mcp-stdio` для MCP, клиент ACP). Контур жизненного цикла процесса и транспорта, не разметка окна и не канал EICAS / IDE Health. В доках по MCP/ACP/stdio — при необходимости говорить явно ProcessHost, чтобы не путать с суффиксом `Host` у контролов.
Канал	Семантический контур данных и приоритета: что показываем и зачем (например канал EICAS — W/C/A; канал IDE Health — build/tests/debug/git, отдельно от CAS). Канал — не имя UserControl и не геометрия экрана.
Слой представления	Как и где в разметке показать те же данные: полоса (Strip), страница зоны (Page), оверлей, карточка — по пресету (`ide_health_surface`, AXAML). Не шина событий, не маршрутизация сообщений, не «хост событий».
`EicasAlertsBar` / `eicas_alerts_bar`	Стабильные идентификаторы в коде и TOML: включить слот представления для канала EICAS в текущей раскладке. Контрол: `EicasAlertsBarView`. Это не сам канал: канал — предупреждения W/C/A и их приоритет; тип — контейнер UI. Имя без суффикса Host, чтобы не путать с ProcessHost; «Channel» в имени View не используем — в коде Channel ожидают у модели/провайдера, а не у AXAML-контейнера.
`WorkspaceChromeBandView`	Контейнер полосы хрома над нижним доком: сетка как у `MainGrid`, сверху слот `EicasAlertsBarView`, ниже `IdeHealthStripView`. По смыслу — разметка для канала IDE Health (сегменты собирает `IdeHealthSurfaceCompositor`) и слота EICAS; см. чертёж реализации.
CDS (контракт кабины)	В авионике CDS (Cockpit Display System) — система отображения; в Cascade в контрактном смысле — согласованное описание семантики кабины: зоны внимания, топология презентации (`presentation`), какие `TopLevel` задействованы, активная страница вторичного контура, видимость регионов — без перечисления каждого контрола. Не синоним «одного класса в коде» и не замена каналам (IDE Health, EICAS, readiness). Детали и эволюция полей — `cds-contract-v0.md`.
`UiLayoutSnapshot` / `ide_get_ui_layout`	Снимок дерева визуальных элементов (в т.ч. несколько окон, роли `main` / `mfd_host` / …) для инспекции и автоматизации. Ортогонален CDS: тот же экран описывается и семантикой кабины, и деревом контролов; назначения разные (внимание vs поиск по имени/иерархии). Реализация: `Cockpit/Surface/UiLayoutSnapshot.cs`; см. 0017.

Канал vs контейнеры в коде: доменный канал — про смысл и поток сообщений; EicasAlertsBarView, WorkspaceChromeBandView — про где нарисовать в окне. Переименовать их в *Channel* было бы вводящим в заблуждение: в коде Channel ожидают у модели/провайдера, а не у AXAML-контейнера. Для канала IDE Health смысл уже в типах IIdeHealthChannel / IdeHealthInputSnapshot / IdeHealthSurfaceCompositor.

1.2 Слот презентации и канал содержимого (два уровня)¶

В обсуждении и в документации полезно не смешивать два уровня абстракции.

Уровень	Вопрос	Примеры формулировок
Слот презентации (поверхность региона)	Где и какого размера показываем инструмент: полоса, полная страница региона MFD, карточка, оверлей?	«полная страница MFD», «нижняя полоса IDE Health», MFD full-page surface
Канал / содержимое	Какой поток данных или инструмент заполняет слот?	IDE Health (build/tests/debug/git), оповещения EICAS, статус окружения (LSP, модель, транспорт агента), Git, чат

Разговорная «отдельная страница» чаще всего относится к первому уровню (крупный слот вместо полосы). Что именно на этой странице — второй уровень; другая страница MFD (например окружение vs IDE Health) — это другой канал, а не другой тип слота.

Имя в конфиге и коде: значение вроде DedicatedPage у ide_health_surface / IdeHealthUiSurface.DedicatedPage задаёт слой представления только для канала IDE Health (те же сегменты, что у полосы, в разметке страницы вместо IdeHealthStripView — см. чертёж). Это не синоним «любой полноэкранной страницы MFD»; для ясности в текстах можно говорить «страница IDE Health (режим Page)» или «IDE Health на полной странице MFD». Другие полноэкранные виды (окружение, доки и т.д.) именуются по содержимому, а не через перегрузку DedicatedPage.

Готовность окружения (отдельный канал от IDE Health): быстрый ответ «всё ли ок» — LSP, транспорт агента, доступность нужных исполняемых файлов (в т.ч. через PATH на Windows/Linux), и только те переменные окружения / пути, которые IDE сама использует; не дамп всего environ. Не замена экрана настроек при редактировании. ADR: 0023; чертёж: environment-readiness-glance-v1.md.

IDE Health — каноническое имя этого канала в продукте и ADR после 0089 (ранее Workspace Health; опора сильнее, чем у размытого «telemetry»). Реализация в типах IdeHealth* (см. чертёж реализации). В русских подписях UI рядом уместно состояние IDE. Ранние черновики: «телеметрия работы», затем «операционная телеметрия». Сводный лексикон и таблица эволюции имён: 0022.

2. Соответствие зонам Cascade¶

Источник имён панелей и режимов: cascade-ide-ui-layout-v1.md, ui-modes-overview-v1.md, ADR 0010.

Слой	Роль в IDE	Кандидаты в Cascade
Лобовое	Объект работы; доминирует	Активный документ, курсор; HUD: inline diagnostics, ghost text, gutter (§9)
PFD	Контекст полёта без охоты по вкладкам	Solution Explorer; breadcrumbs / положение в решении; задача/сессия; Problems; компактные индикаторы следующего шага / подтверждения агента — если пресет помещает их сюда, а не в EICAS/MFD
MFD	Исследование и вторичные потоки	Git; полный чат/trace; нижний док (терминал, build output, тесты, отладка); доки; встроенный браузер; расширенные Agent Operations в Balanced/Power
EICAS	Консолидация предупреждений	Один канал W/C/A (§5); визуально — список, полоса или оверлей по пресету, не четвёртая колонка инструментов

Правило отсечения: если элемент не нужен для удержания контекста и ориентира в workspace (где мы, что ломает работу, что правим) и не относится к объекту правки в редакторе — по умолчанию это MFD или EICAS, не дублирование в PFD. Перенос панели между PFD и MFD — только сменой пресета (или пользовательского оверрайда пресета), не drag-and-drop в сессии.

Правило стабильности ролей: пресет задаёт, какой инструмент в какой семантической зоне; не «подвинуть Git в PFD на день» без изменения конфигурации.

Идентификаторы зон (machine-readable)¶

Для данных (ADR 0010), кода и будущей привязки панелей к семантике используются стабильные строковые id (нижний регистр, латиница, без пробелов). Геометрия «слева / центр / справа» не кодируется в id: она задаётся каркасом окна и пресетом.

Идентификатор	Назначение	Тип
`forward`	Лобовое: область редактора (активный документ)	Пространственная зона (якорь №1)
`pfd`	PFD: текущий контекст workspace	Пространственная зона (якорь №2)
`mfd`	MFD: вторичные инструменты и длинные потоки	Пространственная зона (якорь №3)
`eicas`	EICAS / CAS: оповещения и приоритизация	Канал внимания, не третья колонка в том же смысле, что `pfd`/`mfd`; может быть полосой, оверлеем, компактным списком (§5)
`hud`	Inline-слой на редакторе	Слой внутри `forward`, не равноправная «четвёртая зона» с `pfd`/`mfd`

Правила именования

В конфигах и API использовать только канонические id из таблицы; не вводить синонимы (primary_flight, lobovoe, cas как замена eicas) в том же поле без явной миграции схемы.
Смена значения id или смысла — breaking change для бандла UiModes/ → инкремент schema_version в индексе (ADR 0010).
Привязка конкретной панели к зоне в TOML — отдельная задача реализации (например ключ attention_zone = "pfd" у записи панели); этот ADR фиксирует словарь допустимых значений.

Минимальный набор для карты внимания: forward, pfd, mfd; опционально eicas и привязка слоя hud к forward.

Реализация в коде:

Features/UiChrome/AttentionZone.cs — константы AttentionZoneIds, перечисление AttentionZone, AttentionZoneExtensions.TryParseCanonicalId / ToCanonicalId, флаги IsSpatialAnchor / IsAlertingChannel / IsHudLayer.
Features/UiChrome/AttentionPanelIds.cs — стабильные id поверхностей для ключей в workspace.toml.
Features/UiChrome/AttentionZonePanelRuntime.cs — карта поверхность→зона: дефолты в коде, переопределение секцией [attention_zone_panels] в UiModes/workspace.toml (загрузка вместе с метриками хрома).

2.1 Слои конфигурации: продукт, пользователь, workspace (репозиторий)¶

Помимо личных предпочтений (глобальные настройки, пользовательский бандл UiModes, если он предусмотрен политикой установки) имеет смысл выделять проектный слой: в разных репозиториях оптимальная расстановка одних и тех же инструментов по зонам PFD/MFD/EICAS может отличаться (монорепо vs библиотека, сервис с обязательным чатом агента vs утилита командной строки, команда договорилась держать тесты «ближе к контексту» и т.д.). Это не нарушает модель внимания — меняется наполнение зон в рамках тех же семантических ролей.

Слой	Назначение	Пример
Дефолты кода	Безопасные значения без конфига	`AttentionZonePanelRuntime`
Бандл продукта	Единая база для всех установок	`UiModes/workspace.toml` в поставке Cascade
Пользователь	Личный flow, доступ к подмене бандла	Пользовательский каталог `UiModes` / оверрайд, если поддержан
Workspace репозитория	Соглашение команды, едет с кодом	Фрагмент TOML с `[attention_zone_panels]` (и при необходимости метриками хрома), привязанный к открытому solution/workspace

Контракт слияния (целевой): при наличии нескольких источников для одной и той же поверхности приоритет выше у более «локального» контекста задачи: workspace репозитория → пользовательский бандл → бандл продукта → дефолты кода. Семантика зон (pfd / mfd / …) не меняется; переопределяется только какая панель с каким id к какой зоне отнесена, в пределах стабильных AttentionPanelIds.

DX-смысл: снижение трения «каждый раз настраивать под репо» и выравнивание онбординга новых участников с принятым в проекте кокпитом — аналогично тому, как .editorconfig задаёт стиль в репозитории.

Реализация на сегодня: при старте загружается UiModes/workspace.toml из каталога бандла приложения (UiModeCatalog), без автоматического слияния с файлом из открытого репозитория. Следующий шаг: определить стабильный путь к пер-repo конфигу (кандидат: .cascade/workspace.toml в корне репозитория или рядом с .sln), парсинг той же схемы UiWorkspaceToml и merge поверх значений бандла при смене активного workspace. До появления merge команды может опираться на общий бандл или дублировать нужную секцию вручную.

3. Связь с режимами Focus / Balanced / Power¶

Режимы сдвигают баланс «минимум шума» vs «полный кокпит» (power-mode-concepts-v1.md). Семантика трёх зон (лобовое / PFD / MFD) не меняется; меняется видимость и площадь MFD и плотность хрома.

Focus — максимум площади под лобовое; PFD — компактно; MFD (чат, док, Git) — по запросу или скрыт; HUD в редакторе — по политике режима.
Balanced — лобовое + видимый PFD + один слой MFD по умолчанию (например чат с Agent Operations).
Power — явный кокпит: больше одновременно открытого MFD и индикаторов IDE Health, при этом лобовое остаётся доминирующим, PFD — читаемым; это не «раздуть PFD чужим содержимым», а больше вторичных слоёв по пресету.

4. Агент и MCP¶

Краткий следующий шаг, уровень безопасности (L1–L3), подтверждение опасных операций — в лобовом (рядом с кодом / HUD) и/или в PFD (контекст), по пресету; не размазывать по MFD без осознанного переключения.
MFD-уровень: полная переписка, trace timeline, длинные логи tool calls, обзор workspace вторично.

ProcessHost (MCP / ACP): сторона, которая запускает процесс IDE или держит транспорт (stdio, сокет) к агентным протоколам — это §1.1 ProcessHost, не EicasAlertsBarView и не слой представления кокпита.

Контракты MCP и имена контролов — в cascade-ide-ui-layout-v1.md; этот ADR фиксирует приоритеты внимания, не протокол.

5. EICAS / CAS — канал оповещений¶

EICAS — не четвёртый якорь наряду с лобовым / PFD / MFD и не синоним «нижней полосы»: это канал оповещений с приоритизацией (W/C/A). Его можно оформить полосой, оверлеем, компактным списком или иначе — см. §«Расположение» ниже. В коде и TOML включение представления этого канала задаётся как EicasAlertsBar / eicas_alerts_bar (§1.1). Это не определение «полосы»: полоса — лишь один из вариантов разметки. На маленьком экране размещение и минимальная заметность — отдельное UX-решение (см. также Dark Cockpit, §6).

Проблема¶

Системные сбои (MCP disconnect, build failure, agent safety breach, test regression) сейчас разнесены по разным вкладкам и бейджам. Пользователь может пропустить критичное событие, если смотрит не в ту панель.

Решение: три уровня анноцирования¶

По аналогии с EICAS, все системные сообщения стекаются в единый приоритизированный список:

Уровень	Цвет	Поведение в IDE	Примеры
Warning (красный)	Немедленное действие	Появляется в зоне EICAS или оверлеем поверх лобового/PFD по пресету; блокирует автономные действия агента до подтверждения	MCP-сервер отключился при L3; сборка упала с ошибкой в файле, который агент сейчас меняет
Caution (янтарный)	Осознание, не блокировка	Бейдж в полосе IDE Health меняет цвет; запись в CAS-список	Тесты частично упали; агент превысил бюджет tool-calls
Advisory (нейтральный)	Информация	Только в CAS-списке, не в PFD	Git: upstream обновился; LLM latency выше обычного

Бытовые слова (как у диагностик IDE), EICAS и AnnunciatorLampLevel: отдельный ярус «I» не вводим — Information = Advisory (A). Цвета ламп — CockpitPrimitivesPalette.Annunciator (ADR 0064).

Бытовое слово (IDE, доки)	EICAS	`AnnunciatorLampLevel`	Цвет / роль
Error; критичная поломка / недоступность сервиса	Warning (W)	`Critical`	Красный
Warning в смысле «обрати внимание», не катастрофа	Caution (C)	`Caution`	Янтарь
Information	Advisory (A)	`Advisory`	Синий

TCAS (другой контур, та же авиация): Traffic Advisory (TA) предупреждает о близком трафике («Traffic, Traffic»); Resolution Advisory (RA) требует немедленного манёвра («Climb, Climb»). В нашем каноне W/C/A RA ближе к Warning (W) / Critical (действие сейчас), TA — к Caution (C) / Caution (осознание угрозы без того же уровня принуждения, что у RA). Не путать с колонкой EICAS Advisory (A).

Почему и там, и там «Advisory»: это не один и тот же знак в разных шкалах. В английском advisory — обычное слово («рекомендация», «предупреждение в общем смысле»); TCAS назвал уровень Traffic Advisory так исторически. В EICAS буква A — это именно третий, самый мягкий ярус системных сообщений (W/C/A). Слово совпало, слоты приоритета — нет: TA по срочности ближе к Caution, чем к EICAS Advisory (A).

Историческая справка (зачем так сложилось):

ACAS / TCAS (ICAO). В нормативных текстах Airborne Collision Avoidance System описывают выдачу экипажу как два вида advisories — Traffic Advisory и Resolution Advisory (определения — например ICAO Annex 10 Vol. IV). Здесь advisory — общий термин: «указание экипажу» от борта по столкновениям; приставки Traffic / Resolution как раз и разводят раннюю подготовку (TA) и разрешённый манёвр/ограничение (RA). Это другая ось, не ярусы EICAS.
EICAS. Система централизованных сообщений о двигателях и бортсистемах (поколение glass cockpit, коммерческая авиация 1970–80-х и далее) с самого начала строилась на иерархии предупреждений экипажа: красный Warning, янтарный Caution, и отдельный, более «бытовой» по смыслу слой Advisory — рутинное доведение состояния, без той же немедленности, что у W/C. Буква A в аббревиатуре W/C/A — про этот третий ярус системных сообщений, а не про TCAS.
Итог: совпало английское слово из двух разных стандартов (столкновение в воздухе vs интегрированное табло). В нашем ADR канон W/C/A — про EICAS-подобный канал IDE; TCAS упоминаем только как антипример путаницы имён.

Расположение¶

Один из вариантов v1: компактный блок между полосой IDE Health (IdeHealthStripView) и нижним доком — не единственно возможное размещение представления канала. Альтернативы: выплывающий overlay поверх PFD/лобового при Warning, отдельная карточка в MFD, и т.д. Не постоянная панель — появляется только при наличии активных оповещений (Dark Cockpit, §6).

Escalation¶

Цель: если Warning означает «риск при текущей автономности агента», а пользователь не взял на себя ответственность (явно) и условие не снялось само — система не оставляет агента в полном автономном режиме бесконечно. Аналог dead-man / acknowledgement в авиации, не «наказание за пропущенный баннер».

Что считается «подтверждено» (ack):

Явное действие в UI — кнопка вида «Понял / Снизить автономность / Продолжить осознанно» (точный копирайт — UX), которая фиксирует: пользователь увидел Warning и принимает дальнейшее поведение при текущем риске; или
Автоматическое снятие Warning — причина устранена (MCP снова доступен, сборка прошла, конфликт разрешён и т.п.): таймер сбрасывается, escalation не срабатывает.

«Не подтверждён за N секунд» означает: Warning остаётся активным (критичное условие по-прежнему истинно), и за N секунд не произошло ни ack, ни авто-снятия.

Таймлайн (логика):

Момент	Поведение
T=0	Появление Warning в EICAS/оверлее; при политике — блок опасных автономных шагов агента до ack или до снятия причины.
0…N	Визуал (и опционально звук по §5) дозванивают внимание; без бесконечного мигания (§6).
T=N при всё ещё активном Warning и отсутствии ack	Downgrade уровня безопасности агента (например L3→L2 или по ступеням L3→L2→L1), остановка автономных действий до следующего явного повышения уровня. Это инвариант безопасности, не удаление кода и не скрытый merge.

N не обязан быть одним числом для всех классов событий: для «MCP offline» может быть короче, для «сборка упала» — длиннее, если политика допускает спокойное исправление без немедленного downgrade.

Связь с merge и прочими потоками: merge/Git — отдельный контур, пока политика явно не связывает его с EICAS (например «блок merge при активном Warning от агента»). Таймер N относится к тому же Warning, а не к merge как к отдельному таймеру.

Ограничение: без дополнительных сигналов система не отличает «ушёл за кофе» от «осознанно принял риск». Поэтому дефолт безопаснее выражать как downgrade автономности, а не как необратимые действия с файлами. Полная автоматика escalation и точные N — после ручного подтверждения уровней в ранних версиях (см. §16 «Не цели v1»).

Голосовые оповещения (мотив GPWS / TAWS)¶

В авиации GPWS/TAWS — не «атмосфера», а обучаемый контур безопасности: короткие стандартизированные фразы, приоритет над прочим аудио. Перенос в IDE оправдан только как опциональный аудио-слой к той же приоритизации, что и EICAS, а не как отдельная фича «ради звука» или атмосферы.

Когда уместно: дозвать внимание при Warning, если пользователь не смотрит в зону EICAS; перед подтверждением опасного шага агента; доступность (голосовой дубль критичного сообщения — при качественном TTS и языках). Когда нет: дублирование Advisory/Caution голосом, произвольное чтение длинного лога, любой звук «для настроения».

Контракт (если делать):

По умолчанию выкл; включение — явный opt-in в настройках.
Гейтинг по серьёзности: в обычном режиме только Warning (или согласованное подмножество критичных событий); не превращать голос в второй поток спама рядом с CAS.
Короткие фиксированные фразы или узкий набор шаблонов — не TTS всего текста оповещения.
В копирайте настроек учитывать открытый офис и соседей (социальная цена звука).

Статус: не цель v1; сначала стабильный визуальный EICAS и замеры §18 — затем отдельное UX-/продуктовое решение, нужен ли аудио-канал и на каких условиях (см. §16).

6. Dark Cockpit Principle¶

Принцип¶

В нормальном полёте кокпит тёмный — лампы не горят, пока всё штатно. Индикатор привлекает внимание только при отклонении.

Применение в IDE¶

Зоны PFD и полоса IDE Health (где она по пресету) в нормальном состоянии — спокойные: нейтральные бейджи, отсутствие лишних цветовых акцентов, CAS-список пуст и скрыт.

При проблеме — активное привлечение внимания: - Бейдж Build/Test/Debug → цветовой сдвиг (нейтральный → Warning/Caution). - CAS-список появляется с кратким описанием. - Один пульс анимации (не бесконечное мигание — это вызывает привыкание и игнорирование).

Дизайн-правило¶

Каждый элемент первичного контекста (PFD и при необходимости компактная полоса IDE Health по пресету) должен иметь два визуальных состояния: «норма» (тихий, почти невидимый) и «отклонение» (заметный). Если элемент всегда выглядит одинаково — это не часть дисциплины внимания, а декорация.

Представление канала EICAS и настройки¶

Слой представления канала EICAS/CAS (полоса, вкладка или страница MFD, оверлей, компактные индикаторы, выделенная зона в «тяжёлом» пресете) в перспективе может задаваться пресетами и пользовательскими предпочтениями — это вопрос плотности экрана и привычки; семантика канала (§5) от этого не меняется.

Инварианты, не сводимые к вкусу: Dark Cockpit в норме (тихо, пока штатно) и заметность эскалации при Warning/Caution — критичное оповещение не должно теряться из-за «убрал панель ради минимализма». Политика приоритетов W/C/A и требование видимости при эскалации — §5–§6; конкретная геометрия — пресет.

7. Scan Pattern (паттерн сканирования)¶

Концепция¶

Пилотов обучают предсказуемому маршруту глаз по приборам (T-scan / cross-check). Раскладка IDE должна поддерживать, а не ломать естественный scan pattern.

Целевой scan pattern Cascade (три зоны + HUD)¶

Базовая модель — три якоря внимания на одном экране (порядок слева/справа задаётся пресетом):

  [ PFD: контекст ]    [ Лобовое: редактор + HUD ]    [ MFD: вторичное ]
        ↑                        ↑                            ↑
   короткие взгляды      основное время работы      осознанные переключения

PFD — «где я в решении, что ломает работу»: обозреватель, Problems, компактный контекст задачи; без охоты по вкладкам внутри этой семантики.
Лобовое — доминирует; HUD усиливает его, не добавляя отдельного окна для взгляда.
MFD — Git, длинные логи, полный чат, доки, браузер: не требует постоянного сканирования в одном ряду с кодом.

EICAS при активных предупреждениях встраивается в scan как короткая ось (полоса/бейдж/оверлей), не как четвёртая постоянная колонка инструментов.

Дизайн-критерий¶

При ревью любого нового UI-элемента: «В какой из трёх семантических зон (или EICAS) это живёт по пресету? Ломает ли оно предсказуемость взгляда?» Если элемент требует постоянного взгляда мимо лобового и PFD без осознанного переключения на MFD — пересмотреть размещение или пресет.

8. Mode Awareness и Mode Confusion¶

Проблема¶

Mode confusion — одна из опаснейших проблем в авиации: пилот думает, что автопилот в одном режиме, а он в другом. Несколько катастроф произошли из-за этого.

В IDE: пользователь может не осознавать, что агент работает в L3 Autonomous, или не заметить переключение Focus → Power.

Меры¶

Peripheral cue: каждый режим имеет свой акцентный цвет окантовки окна (частично реализовано в Power с неоновыми каймами). Работает на периферийное зрение без прямого взгляда на бейдж.
Transition handoff: при переходе в сторону большей автономии агента (L1→L2→L3, Focus→Power) — краткий «handoff callout» (тост или анимация бейджа), как в авиации «my controls» / «your controls». Переход в обратную сторону (L3→L1) — тише (снижение автономии безопасно).
Alertness check: если пользователь долго (настраиваемый порог) не взаимодействует в L3 Autonomous — сигнал в PFD или EICAS (по пресету): «Agent is running autonomously. Still monitoring?» Аналог dead-man's switch. Нет ответа → автоматический downgrade до L2.

9. HUD-слой в редакторе¶

Концепция¶

В авиации HUD проецирует критичные данные прямо на лобовое стекло — пилот не отводит взгляд от внешнего мира.

В IDE: PFD-информация может быть наложена прямо на редактор, без необходимости смотреть в боковые панели.

Кандидаты для HUD¶

Элемент	Расположение	Назначение
Inline diagnostics	В теле кода	Ошибки / предупреждения по месту (частично реализовано)
Ghost text агента	В теле кода	Предлагаемое следующее изменение
Gutter agent indicator	Рядом с номером строки	Иконка: «агент собирается изменить этот файл / эту область»
File-level banner	Над текстом, под вкладкой	«Agent is actively editing this file» — тонкая полоска, как в collaborative editing

Терминология (уточнение): продуктовое имя Editor HUD для inline-слоя (диагностика, ghost text, gutter, подсказки у каретки / inlays) и явное отличие от HUD banner (file-level полоса над текстом) — ADR 0085.

Принцип¶

HUD-элементы не должны блокировать редактирование и должны быть визуально легче, чем основной текст. Они обогащают лобовое (и при необходимости дублируют сигнал из PFD/EICAS), а не заменяют зоны — пользователь может их отключить без потери безопасности, если критичное остаётся в PFD и EICAS.

10. Degraded Mode / Graceful Degradation¶

Принцип¶

В авиации при отказе приборов есть процедуры на каждый случай. PFD всегда показывает что-то — даже если это «последнее известное состояние».

Таблица деградации¶

Сбой	PFD-индикация	Автоматическое действие
MCP-сервер отключился	Бейдж MCP → красный/серый; last known state + таймстемп отключения	Safety auto-downgrade до L1; CAS Warning
LLM-провайдер недоступен	Чат → заглушка «offline»; план заморожен	Агент в read-only; редактор и сборка работают штатно
Build tool не отвечает	Сегмент Build в IDE Health → «stale» с таймером	CAS Caution; не блокирует редактирование
Все MCP-серверы отвалились	Полоска IDE Health → «degraded mode»	L1 принудительно; кнопка «retry all»

Дизайн-правило¶

PFD никогда не показывает пустоту или бесконечный спиннер без объяснения. Минимум: последнее известное значение + возраст данных + статус источника.

11. Situational Awareness (модель Endsley)¶

Три уровня ситуационной осведомлённости:

SA Level	Авиация	IDE	Обслуживается
L1 — Perception	Показания приборов	Build status, test count, agent state, git diff count	PFD — бейджи IDE Health, CAS-список
L2 — Comprehension	«Я слишком низко для этого этапа захода»	«3 теста упали из-за моего рефакторинга PaymentService»	PFD (краткое) + MFD (подробно)
L3 — Projection	«Через 30 секунд нужно уйти на второй круг»	«Если смержить — CI сломается»	MFD — Agent plan, dependency graph, чат

Дизайн-критерий для PFD-бейджей¶

PFD-бейджи должны давать не голый L1 («Build: FAIL»), а нижний L2 — кратко раскрывать comprehension:

Вместо (L1)	Лучше (L1 + L2)
Build: FAIL	Build: 2 errors in PaymentService.cs
Tests: 3 failed	Tests: 3 failed (RetryPolicy*)
Git: 5 files	Git: 5 files, 2 unstaged

Одна строка — но пользователь уже понимает смысл, а не только факт.

12. Human-Agent Resource Management (CRM → HARM)¶

Аналогия¶

В авиации Crew Resource Management чётко распределяет роли: - Pilot Flying (PF) — управляет самолётом. - Pilot Monitoring (PM) — следит за параметрами, вмешивается при отклонении.

Маппинг на Safety Levels¶

Safety Level	Роль человека	Роль агента	Авиационный аналог
L1 Read-only	PF (полный контроль)	PM (только наблюдает, подсказывает)	Manual flight, copilot monitoring
L2 Confirm edits	PM (мониторит, подтверждает)	PF (предлагает действия, ждёт OK)	Autopilot engaged, pilot confirms mode changes
L3 Autonomous	PM (мониторит, вмешивается при проблеме)	PF (действует самостоятельно)	Full autopilot, pilot ready to intervene

PFD-индикация роли¶

Зона PFD должна явно показывать текущее распределение ролей. Кандидат: компактная строка в контекстной области PFD или в бейдже Safety Level:

L1: Human: editing · Agent: advising
L2: Agent: proposing · Human: confirming
L3: Agent: acting · Human: monitoring

Это делает неявное (кто сейчас «летит») — явным и читаемым на периферийном зрении.

13. Мультиоконность и мультимонитор¶

Физическое разнесение усиливает метафору: лобовое, PFD и MFD не обязаны жить в одной колонке одного окна, если есть экраны; семантика зон сохраняется.

Типичный сценарий (три монитора)¶

Экран	Семантическая зона	Содержание (пример)
Левый	PFD	Обозреватель решения, Problems, контекст задачи, компактные индикаторы — «в углу глаза»
Центр	Лобовое	Редактор + HUD
Правый	MFD	Git, полный чат/trace, доки, терминал — переключаемые режимы по пресету

Порядок лево/право можно менять пресетом — важно не смешивать роли: лобовое остаётся редактором, PFD — контекстом полёта, MFD — вторичным.

На одном мониторе те же три семантики складываются в три региона одного рабочего стола; при маленькой диагонали — стек, табы, сворачивание без переноса инструментов между PFD и MFD в рантайме. Мультиоконность (ADR 0017) позволяет вынести, например, MFD на второй дисплей целиком.

14. Command Palette¶

Command Palette хорошо стыкуется с тремя зонами (детали: command-palette-ux-concept-v1.md):

Руки на клавиатуре — типовые действия без целения в кнопки панелей.
Палитра — временный слой поверх рабочего стола: не заменяет обозреватель (PFD) и не заменяет чат (MFD), а даёт быстрый доступ к командам.
PFD показывает контекст и состояние, лобовое — объект работы, палитра — действие без смены фокуса мышью.

Антипаттерн: тащить в палитру навигационный шум (breadcrumbs, длинный контекст файла), который должен жить в PFD. Показывать в палитре только при явном сценарии.

Политика «всё важное из палитры» снижает давление на постоянную видимость тулбаров и укладывается в ограничение числа первичных виджетов в зоне PFD.

15. Внешний агент и отдельные приложения¶

Реальная среда часто включает не только Cascade: внешний агент, Cursor, другая IDE — на отдельном мониторе.

Принципы¶

Разделение «дисплеев экипажа». Cascade отвечает за редактирование и встроенный контур. Внешний чат/агент — отдельный MFD-экран, не обязательная панель внутри Cascade.
Не конкурировать за одну полосу внимания. Если Cursor уже на правом мониторе, правый MFD в Cascade можно держать узким или под документацию — не дублировать «второй чат».
Мост без захвата лобового. Короткие сигналы от внешнего агента (подтверждение, build failure) — кандидаты в PFD или EICAS Cascade по пресету; полный диалог — во внешнем инструменте (MFD там же).
Command Palette может включать действия «открыть внешнюю сессию», «вставить из буфера» — внешний инструмент доступен с клавиатуры.

Техническая связь: Agent Client Protocol — note-acp-cascade-cursor-v1.md.

16. Risks и ограничения¶

Риск	Mitigation
Раздуть PFD до «всё сразу» — теряется метафора	Явный лимит видимых элементов контекста в PFD (5–7±2); scan pattern (§7); роли фиксируются пресетом, не drag-and-drop
Перетаскивание панелей между PFD и MFD в сессии	Запрещено по модели: только пресет / оверрайд конфигурации
Dark Cockpit → пользователь забывает про панель	CAS-список с escalation напоминает о себе; Alertness check (§8.3)
Mode confusion при частом переключении	Peripheral cue + transition handoff + бейдж режима
EICAS-зона превращается в «ещё одну панель»	Показывается только при активных оповещениях; в норме — invisible (Dark Cockpit)
HUD перегружает редактор	HUD-элементы легче основного текста; отключаемы без потери безопасности
Голосовые алерты без дисциплины	Хуже DX, чем тишина: только §5 (opt-in, Warning, короткие фразы); не «звук на каждое событие»

Не цели v1¶

Жёстко закреплять пиксели каждой панели — это через UX-ревью.
Полная автоматика CAS-escalation — сначала ручное подтверждение уровней.
Привязка пресетов к конфигурации мониторов (имя/id дисплея) — открытый вопрос для ADR 0017.
Голосовые оповещения GPWS-like — см. §5; не в v1, пока не закрыт минимальный визуальный EICAS и нет отдельного решения по opt-in и гейтингу.

17. Следующие шаги¶

~~Реализовать в TOML привязку панелей к зонам~~ — сделано: workspace.toml → [attention_zone_panels], AttentionZonePanelRuntime; дальше — использовать карту в UI (подсветка, IDE Health, ограничения dock) по мере готовности контролов, с привязкой лэйаута к пространственным якорям, а не только метаданными в данных (контекст: §«Якоря и поток внимания» в начале документа).
Согласовать короткий список инвариантов по зонам (3–5 пунктов) для Focus и Power отдельно.
Определить минимальный v1 CAS (EICAS): формат списка, где в раскладке на одном маленьком экране vs мультимонитор, какие источники.
Прототипировать Dark Cockpit transition: нормальный бейдж → Warning-состояние (цвет + анимация).
Зафиксировать scan pattern (§7) как чеклист для UX-ревью новых элементов.
При реализации L3 Autonomous — Alertness check (§8.3): порог, downgrade policy, UI.
Обновить concept-to-implementation-map-v1.md столбцом «лобовое / PFD / MFD / EICAS / HUD» для ключевых контролов.
Опционально: пресеты раскладки окон под два/три монитора (§13) — не обязательно в v1 продукта, но как целевой сценарий.
Проработать политику роутинга зон при мультиоконности — отдельное UX-решение или продолжение ADR 0017.
Зафиксировать числовые бюджеты §18 по профилированию на референсном железе; до этого §18 — чеклист без обязательных SLA.
Реализовать слияние workspace репозитория с бандлом для [attention_zone_panels] (и при необходимости метрик хрома): путь к файлу, момент загрузки при открытии solution, приоритеты §2.1.
Контент онбординга по §19: сценарии коротких роликов (зоны, режимы, агент), единая рамка «Почему / Зачем / Что я получу» в подсказках и на страницах справки; нарастающие идеи и план — onboarding-first-run-v1.md.
После стабильного EICAS: оценить голосовой слой §5 (нужен ли, opt-in, только Warning, офис/доступность) — отдельно от «атмосферы».
Скины оформления (skin bundles) — отложено; идея и границы от тем/пресетов: ADR 0024.

Редактор раскладки зон (визуальный, по мотивам FancyZones)¶

Внешний референс UX: FancyZones (PowerToys) — пользовательские макеты зон на рабочем столе и привязка окон к зонам.

В Cascade это другой слой: не замена оконному менеджеру ОС, а настройка пресета раскладки IDE (пропорции колонок, видимость хрома, IDE Health (strip vs page) и т.д. — см. 0010, чертёж workspace-health-implementation-map-v1.md). Инвариант ADR сохраняется: не перетаскивать семантику PFD/MFD/EICAS между зонами в обычной рабочей сессии — только смена пресета / конфигурации (§16).

Уровень	Содержание
MVP	Предпросмотр пресета, числовые доли / ограниченный набор шаблонов, правка через TOML с валидацией
Расширение	Упрощённый grid-редактор в отдельном режиме «настройка пресета» (не в потоке редактирования)
Не цель по умолчанию	Полный паритет с FancyZones (произвольная сетка, мультизона drag, горячие клавиши на все мониторы) — высокая стоимость и риск дублировать роль ОС и ADR 0017

Статус: решение зафиксировано на уровне принципов; детальная спецификация UI — в docs/design/, когда появится реализация. Отдельный ADR не требуется до смены инвариантов зон.

18. DX acceptance: измеримые критерии¶

Модель внимания (§1–§17) задаёт качественную планку. Для релиза и регрессий нужен мост к цифрам: что считаем «достаточно хорошим» DX помимо субъективного «удобно». Конкретные пороги ниже — черновик; финальные значения фиксируются после профилирования и пользовательских прогонов (см. §17 п. 10).

18.1 Ядро редактора (ортогонально зонам, блокирует весь DX)¶

Метрика	Цель (черновик)	Как мерить
Задержка ввода до отображения символа в лобовом	p95 ≤ 16 ms на референсной машине	Инструментирование UI thread / frame timing
Время до первой диагностики Roslyn по сохранённому файлу	p95 ≤ 500 ms (порядок; уточнить по проекту)	Лог анализатора / тестовый solution
Холодный старт до готовности ввода в открытом документе	порог TBD (секунды)	Stopwatch от запуска до editable

Если ядро медленное, кокпит и зоны не компенсируют — критерий блокирующий для «готовности к широкому использованию».

18.2 Время до «осмысленного действия» (onboarding / поток)¶

Метрика	Цель (черновик)	Как мерить
Time to first edit — от старта IDE до первого сохранённого символа в файле проекта	TBD (например до 60 с для опытного пользователя с шаблоном)	Сценарий теста / продуктовые метрики (опционально)
Time to first build feedback — от «запустить сборку» до первого сообщения в выводе/EICAS	TBD	Ручной сценарий + лог
Time to first safe agent action — от включения агента до первого подтверждённого безопасного шага (L2) или осознанного L3 с видимым бейджем	TBD	Сценарий + чеклист §8

18.3 Модель внимания (качественно + контроль регрессий)¶

Ось «где на экране (якоря)» vs «как ведёт себя внимание (flow, режимы, EICAS)» — §«Якоря и поток внимания»; при ревью не смешивать.

Критерий	Проверка
Scan	Новый элемент UI имеет зону по пресету (§7); нет обязательного постоянного взгляда «мимо» лобового+PFD без осознанного MFD.
Роли зон	Нет переноса панелей между PFD и MFD без смены конфигурации (§2, §16).
EICAS на критическом пути	Warning по агенту/сборке заметен без охоты по вкладкам (§5); при маленьком экране — явный сценарий в UX-ревью.
Dark Cockpit	В норме нет лишних цветных акцентов; при отклонении — заметный переход (§6).

Подходит для UX-ревью и чеклиста QA, не обязательно для автоматического CI в v1.

18.4 Доверие и автономность агента¶

Критерий	Проверка
Текущий уровень безопасности (L1–L3) различим без открытия MFD	Peripheral cue / бейдж (§8).
Переход L2→L3 (или Focus→Power при росте автономии) даёт краткий handoff	Не молча (§8.2).
Деградация (MCP offline и т.д.)	PFD/EICAS не пустые и не бесконечный спиннер (§10).

18.5 Discoverability (вторичный слой)¶

Критерий	Проверка
Действия без мыши	Критичные команды доступны из Command Palette или хоткеев (ADR 0013).
Навигационный шум не засоряет палитру	Как в §14.

18.6 Как использовать¶

Перед релизом: пройти §18.3–§18.5 чеклистом; §18.1–§18.2 — по возможности замерить, иначе зафиксировать «не замерено».
При споре «идеальный ли DX»: сначала ядро (§18.1), затем внимание и агент (§18.3–§18.4); §18.2 и discoverability — усиливают, но не подменяют ядро.

19. Онбординг: снижение налога на модель и диалог с аудиторией¶

Живой чертёж (идеи First Run, флаг vs режим UI, PFD + чеклист, палитра): onboarding-first-run-v1.md.

Богатая модель внимания (зоны, режимы, EICAS, уровни агента) вводит onboarding tax: время и внимание, чтобы её освоить. Снижать этот налог нужно не длинным текстом в ADR, а короткими, задачными объяснениями в продукте.

19.1 Короткие видео (ориентир — ClickUp и аналоги)¶

Формат: ролики на несколько минут каждый, один сценарий / одна идея («где контекст», «что в MFD», «как переключить режим», «что такое предупреждение в EICAS»).
Цель: показать как пользоваться кокпитом без чтения спецификации; дублировать ссылки из первого запуска, пустых состояний и справки.
Не заменяет документацию для power user и не отменяет §18 по метрикам — дополняет вход в продукт.

19.2 Обязательная рамка для любого объяснения «в лоб»¶

Без ответов на три вопроса нельзя выстроить диалог с аудиторией: пользователь остаётся в режиме «мне навязали термины». Любой заметный онбординг (видео, первая модалка, блок в справке, подсказка к зоне) должен явно или кратко закрывать:

Вопрос	Смысл
Почему?	Какую проблему решает эта часть интерфейса (перегруз, потеря контекста, небезопасный агент и т.д.).
Зачем?	Какую роль она играет в общей модели Cascade (зона внимания, канал оповещений, режим сдерживания шума).
Что мне это даст?	Конкретный выигрыш: меньше переключений, быстрее увидеть ошибку, яснее граница агента — без абстрактного «удобнее».

Проверка при ревью копирайта и сценариев роликов: если третий столбец пустой или общий — доработать, иначе онбординг не выполняет работу.

19.3 Связь с §18¶

Time-to-first-edit и time-to-first-safe-agent-action (§18.2) улучшаются, когда пользователь не обязан сначала понять авионику: видео + рамка «Почему / Зачем / Что я получу» — часть продукта, а не «документация на потом».

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

Оставить PFD/MFD как неформальный концепт без ADR — отклонено: модель внимания влияет на каждое решение по раскладке, и формализация в ADR делает принципы обязательными при ревью UI.
Отдельные ADR на каждый аспект (EICAS, Dark Cockpit, Scan Pattern и т.д.) — отклонено: все аспекты — части одной модели внимания; разбивать — терять целостность.
Сертификационная база DO-178C и буквальная реализация ARINC 661 — вне scope. Переносимые идеи 661 (композитор, контракты зон, явная иерархия) — зафиксированы в контексте выше; метафора кокпита остаётся руководством для UX, не требованием авиационного соответствия.

Статус после принятия¶

Статус Accepted; concept-pfd-mfd-cascade-v1.md получает пометку «Superseded by ADR 0021». При изменении раскладки — ревью по scan pattern (§7) и PFD-лимиту (§16) обязательно.

История изменений¶

Дата	Изменение
—	§1 таблица терминов: КВС (метафора оператора; якорь `#glossary-kvs`); связь с 0034.
—	§1.1 ProcessHost (MCP/ACP) vs UI; уточнение «канал ≠ `Host` View».
—	§1.1 словарь «канал / слой представления / имена в коде»; §5: EICAS как канал (не синоним полосы / не третья колонка); уточнение «Расположение».
—	§1.2: слот презентации vs канал; `DedicatedPage` / `ide_health_surface` (только IDE Health). Якорь: `#glossary-presentation-vs-channel`.
—	§17 подпункт «Редактор раскладки (FancyZones-аналог)»; переносимые идеи ARINC 661; §5 Escalation; голос; §2.1; §19; §16/§17; три зоны, HUD, §18 DX acceptance.
—	§19: ссылка на живой чертёж `onboarding-first-run-v1.md`.
—	§ARINC 661: расшифровка CDS (Cockpit Display System).
—	§«Архитектура зон»: содержимое якорей PFD/MFD vs термин Page у канала IDE Health (`ide_health_surface`). Ранее под §«Архитектура зон»: якоря vs attention flow (не смешивать).
—	«операционная телеметрия» / «телеметрия работы».
2026-04-06	§«Плагины и модель внимания»: обязательная привязка расширений к зоне/каналу/пресету.
2026-04-11	в тексте зафиксировано имя Workspace Health; канон сейчас — IDE Health (0089) (сборка, тесты, отладка, git); в русских подписях рядом уместно состояние IDE, избегая путаницы с каталогом workspace на диске.
2026-04-12	§1.1: термины CDS (контракт кабины) и отличие от `UiLayoutSnapshot`; живой чертёж `cds-contract-v0.md`.
2026-04-12	§Контекст: подпункт «Когнитивная нагрузка и нейроотличие» — продуктовая связка (не медицина, не новые инварианты §1–§18); ссылка на публичный эскиз на сайте автора.
2026-04-15	после таблицы зон: отсылка к 0037 (география PFD vs строгая поверхность по маркеру).