| 1 | # ADR 0021: PFD / MFD — модель внимания кокпита Cascade IDE |
| 2 | |
| 3 | **Статус:** Accepted |
| 4 | **Дата:** 2026-04-06 |
| 5 | **Обновлено:** 2026-04-15 — отсылка к [0037](0037-pfd-surface-invariants-and-roslyn-enforcement.md#adr0037-zone-vs-surface) (география PFD vs строгая поверхность). Подробности — [§ История](#adr0021-history). |
| 6 | |
| 7 | **Поглощает:** [`concept-pfd-mfd-cascade-v1.md`](../ui-ux/concept-pfd-mfd-cascade-v1.md) (черновик концепта → формализован здесь). |
| 8 | |
| 9 | ## Связанные ADR |
| 10 | |
| 11 | | ADR | Роль | |
| 12 | |-----|------| |
| 13 | | [0010](0010-ui-modes-toml-configuration.md) | режимы UI, TOML | |
| 14 | | [0012](0012-floating-workspace-chrome.md) | плавающий хром | |
| 15 | | [0013](0013-command-surface-and-discoverability.md) | команды и discoverability | |
| 16 | | [0017](0017-multi-window-workspace-and-agent-surfaces.md) | мультиоконность | |
| 17 | | [0016](0016-agent-client-protocol-external-agent.md) | ACP / внешний агент | |
| 18 | | [0005](0005-defer-dynamic-plugins-mef.md) | плагины отложены; когда появятся — §«Плагины и модель внимания» ниже | |
| 19 | | [0022](0022-workspace-health-lexicon.md) | лексикон имён | |
| 20 | | [naming-layers-v1.md](../design/naming-layers-v1.md) | semantic ids: verify, safety, Endsley SA, trace | |
| 21 | |
| 22 | ### Вне ADR |
| 23 | |
| 24 | | Документ | Роль | |
| 25 | |----------|------| |
| 26 | | [`power-mode-concepts-v1.md`](../ui-ux/power-mode-concepts-v1.md) | UX: режимы Power | |
| 27 | | [`cascade-ide-ui-layout-v1.md`](../ui-ux/cascade-ide-ui-layout-v1.md) | UX: раскладка UI | |
| 28 | | [`concept-to-implementation-map-v1.md`](../ui-ux/concept-to-implementation-map-v1.md) | Карта концепт → код | |
| 29 | | [`command-palette-ux-concept-v1.md`](../ui-ux/command-palette-ux-concept-v1.md) | UX Command Palette | |
| 30 | | [`workspace-health-implementation-map-v1.md`](../design/workspace-health-implementation-map-v1.md) | Карта реализации IDE Health / EICAS | |
| 31 | |
| 32 | ## Резюме |
| 33 | |
| 34 | - **PFD / Forward / MFD / EICAS / HUD** — якоря внимания и политика плотности UI, не обещание «встроить все приложения мира». |
| 35 | - **Пресеты** (TOML, [0010](0010-ui-modes-toml-configuration.md)) задают *где* инструменты; **режимы** Focus/Balanced/Power — *как* управлять потоком внимания поверх якорей. |
| 36 | - **EICAS** — единый сводный канал оповещений; подсистемы подают события, а не конкурируют toast’ами в лобовом редакторе. |
| 37 | - Идеи **ARINC 661** — один композитор и границы зон; сертификация и полный профиль 661 **вне scope**. |
| 38 | - Внешние агенты и чаты — **мосты** ([0016](0016-agent-client-protocol-external-agent.md)), без второго «кокпита» в зоне PFD. |
| 39 | |
| 40 | --- |
| 41 | ## Контекст |
| 42 | |
| 43 | Разработчик в IDE оперирует десятками сигналов: код, сборка, тесты, агент, git, безопасность. Без явной модели приоритетов внимания интерфейс скатывается к двум крайностям: «всё спрятано» (Focus без обратной связи) или «всё видно» (Power с баннерной слепотой). |
| 44 | |
| 45 | Авиация решила эту задачу разделением приборных панелей по **роли в управлении вниманием**: PFD (первичный полётный дисплей), MFD (мультифункциональный дисплей), EICAS/CAS (система оповещения экипажа). Этот ADR переносит модель в контекст IDE и фиксирует принципы, дизайн-критерии и открытые решения. |
| 46 | |
| 47 | ### Философия: переключение контекста и устойчивый контур внимания |
| 48 | |
| 49 | Главный **налог** на продуктивность разработчика — **переключение контекста** и вынужденный **выход из IDE**: не только Alt-Tab, но и потеря потока, «где я смотрел», какой канал коммуникации сейчас актуален. По-хорошему IDE стремится к **единой сцене**: код и рядом — минимум необходимого для текущей задачи и коммуникации, чтобы таких переключений было меньше. |
| 50 | |
| 51 | **«Всё в одном месте»** здесь — **цель**, а не требование буквально встроить каждый внешний сервис в бинарник. Бесконечно встраивать приложения **нельзя** по практическим причинам: только чатов существует множество разных; полная интеграция каждого ведёт к **web-вью** (ограничения и доверие), к **раздуванию** продукта (поддержка, безопасность, обновления) или к **сторонним плагинам** (граница ответственности, качество, фрагментация). Десятый чат внутри IDE не «добавляет фичу» — добавляет ещё одну модель входа и источник уведомлений. |
| 52 | |
| 53 | **PFD / MFD / HUD / EICAS** в этом ADR направлены не на обещание «встроить всё», а на **устойчивый контур внимания**: предсказуемые якоря взгляда, что видно по умолчанию, что — осознанным переключением в MFD, что остаётся **снаружи** (второй монитор, внешний клиент) и связывается **мостом** ([ADR 0016](0016-agent-client-protocol-external-agent.md), буфер, deep link) без дублирования полного второго «кокпита» в зоне PFD. «Одно окно» в зрелом смысле — это **согласованный контур**, а не монолит всех приложений мира. |
| 54 | |
| 55 | <a id="cognitive-load-neurodivergence-product-note"></a> |
| 56 | |
| 57 | ### Когнитивная нагрузка и нейроотличие (продуктовая связка, не медицина) |
| 58 | |
| 59 | **Зачем упоминать в ADR:** принципы выше принимаются по **эргономике внимания** и снижению переключений контекста. Отдельно фиксируем **продуктовую** линию: у части пользователей те же переключения и конкурирующие сигналы стоят **дороже** — в том числе при **СДВГ** и других нейроотличиях. Это **не** утверждение о «лечении» интерфейсом, **не** добавляет технических инвариантов к §1–§18 и **не** меняет критерии §18; это **обоснование**, почему тема уместна в онбординге, пресетах и дисциплине плотности UI (см. §16, §19). |
| 60 | |
| 61 | **Связь с моделью (идея, не норма):** явная иерархия якорей (лобовое / PFD / MFD), **сводный** канал оповещений (EICAS), HUD внутри лобового и **Dark Cockpit** в штатном режиме направлены на снижение **лишнего** трения при возврате в поток после прерывания и при сортировке сигналов. Индивидуальные различия велики; **пресеты**, гибкость и отключение шума остаются обязательными. |
| 62 | |
| 63 | **Связанный публичный эскиз** (вне этого репозитория, краткий нарратив для читателя): [Attention, friction, and neurodivergence in the IDE](https://karataevdmitry.github.io/writing/attention-contour-neurodivergence.html) (EN); [Внимание, трение и нейроотличие в IDE](https://karataevdmitry.github.io/ru/writing/attention-contour-neurodivergence.html) (RU). Длинную продуктовую дискуссию **не** дублировать в ADR — только указатель. |
| 64 | |
| 65 | <a id="arinc-661-borrow"></a> |
| 66 | |
| 67 | ### Идеи из ARINC 661 (переносимые, не копия стандарта) |
| 68 | |
| 69 | В авионике **ARINC 661** задаёт интерфейс между **прикладными системами** и **системой отображения** (**CDS**, Cockpit Display System): данные и команды идут в общий контур, а **композиция** экрана, слои и приоритеты — у одного дисплейного рантайма. Cascade **не** реализует профиль 661 и не требует сертификации под него; переносим **архитектурные принципы**, которые снижают риск «каждая подсистема рисует своё поверх всего». |
| 70 | |
| 71 | | Идея 661 | Как используем в этом ADR | |
| 72 | |----------|---------------------------| |
| 73 | | **Один композитор «стекла»** — много источников данных | **EICAS** и размещение каналов внимания — единый контур; сборка, Git, агент, MCP и т.д. **подают события и состояние**, а не владеют отдельным слоем toast’ов поверх редактора без правил (см. §5, §6). | |
| 74 | | **Границы ответственности** | Зоны `forward` / `pfd` / `mfd` / `eicas` и пресеты ([§2](#2-соответствие-зонам-cascade), [§2.1](#21-слои-конфигурации-продукт-пользователь-workspace-репозиторий)): что может оказаться в PFD vs только в MFD — **политика**, а не гонка плагинов за z-order. | |
| 75 | | **Приоритет и слои как схема** | Уровни Warning / Caution / Advisory (§5) и правило Dark Cockpit (§6): иерархия внимания **задаётся явно**, а не порядком инициализации расширений. | |
| 76 | | **Декларативное описание + привязка к данным** | Ориентир для `workspace.toml`, `AttentionZonePanelRuntime` и будущего merge слоёв: **что** на экране и **откуда** значения — проще согласовать с репо и тестировать, чем разрозненная императивная раскраска. | |
| 77 | |
| 78 | **Не переносим:** требования сертификации, совместимость с поставщиками авионики, полнота модели виджетов 661 как таковой. **DO-178C** (процесс доказательства безопасности ПО на борту) в продукт не импортируем — при необходимости отдельные части контура агента могут позже жить под **иной** дисциплиной гарантий; это вне scope данного ADR. |
| 79 | |
| 80 | ### Архитектура зон (зафиксированные выводы) |
| 81 | |
| 82 | <a id="anchors-vs-attention-flow"></a> |
| 83 | |
| 84 | #### Якоря и поток внимания (не смешивать) |
| 85 | |
| 86 | **Пространственные якоря** — **где** в окне (или на каком мониторе) находится зона: три региона **лобовое / PFD / MFD**, плюс отдельно **канал** EICAS и слой **HUD** внутри лобового. Пресет задаёт **размещение** инструментов в этих регионах. Несколько панелей, отнесённых к **одной** зоне (например обе к `pfd`), по этой модели должны составлять **содержимое одного якоря** — композиция внутри региона (вкладки, страницы, стек), а не две независимые позиции на экране, которые лишь помечены тем же id. Строковый id зоны не кодирует «слева / центр / справа» (см. §«Идентификаторы зон» ниже) — геометрию задают каркас окна и пресет — но **семантика** id — именно «какой регион якоря», ожидаемое **место** на сцене, а не произвольная метка только в данных без соответствующего региона на экране (цель реализации — явная привязка лэйаута к якорям). |
| 87 | |
| 88 | **Attention flow** (поток внимания) — **как** управляются фокус и приоритет: режимы Focus / Balanced / Power, полоса EICAS, escalation, осознанный переход во вторичное. Это **политика поверх** якорей; ею нельзя заменять физическую расстановку зон и нельзя смешивать с ней в документации и коде. |
| 89 | |
| 90 | На **одном экране** целевая модель внимания — **три зоны** (три «якоря» взгляда), без разбегания по произвольному числу окон. Содержимое зон **не переносится** из PFD в MFD и обратно в рантайме: роль каждой зоны задаётся **пресетом** (например TOML, [ADR 0010](0010-ui-modes-toml-configuration.md)) с возможностью **переопределения пресета** — пользовательского и/или на уровне **workspace репозитория** (см. §2.1), а не свободного драг-н-дропа между семантиками. |
| 91 | |
| 92 | | Зона | Роль | Содержание (ориентир) | |
| 93 | |------|------|------------------------| |
| 94 | | **Лобовое** | Доминирует по времени и площади; объект работы | Редактор (активный документ). **HUD** (§9) — не отдельная зона: inline-подсказки, диагностика по месту, ghost text и т.п. **обогащают лобовое**, не добавляют четвёртый якорь внимания. | |
| 95 | | **PFD** | Текущий контекст полёта: где мы в workspace, над чем работаем, что мешает | Обозреватель решения, позиция/контекст в решении, задача/сессия как «маршрут», Problems/diagnostics при наличии, при необходимости — компактные индикаторы «что сейчас критично» (детали — в пресете). | |
| 96 | | **MFD** | Всё вторичное, переключаемое осознанно | Git, вспомогательная информация, документация, встроенный браузер, полный чат/trace, терминал, длинные логи, отладка, расширенные операции агента — по списку пресета. | |
| 97 | |
| 98 | **География зоны PFD ≠ один инженерный контракт на все панели в колонке.** Регион внимания **PFD** может одновременно содержать интерактивную навигацию (например обозреватель решения) и компактные «приборы» (статус агента, EICAS, здоровье workspace). Строгие инварианты кода (input lock, weight, каналы) применяются только к компонентам, **явно** помеченным как строгая PFD-поверхность; см. [0037 § Зона внимания и строгая поверхность](0037-pfd-surface-invariants-and-roslyn-enforcement.md#adr0037-zone-vs-surface). |
| 99 | |
| 100 | <a id="anchor-pfd-mfd-content-vs-telemetry-page"></a> |
| 101 | |
| 102 | **Содержимое якорей 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`](../design/workspace-health-implementation-map-v1.md)) означает **только** выбор **слоя представления для этого канала** (крупная область в якоре вместо нижней полосы), а не определение «что вообще может жить в PFD/MFD». |
| 103 | |
| 104 | **EICAS** (§5) — **канал** оповещений и приоритизации (W/C/A), а не третья «колонка» рядом с лобовым / PFD / MFD. Размещение на экране — **открытый выбор пресета**: горизонтальная полоса, оверлей, компактный список или иной **вариант разметки представления**; на маленьком экране критично не смешивать **роль канала** с **конкретной геометрией** одной реализации. |
| 105 | |
| 106 | **Мультимонитор:** те же три семантики **физически разносятся** по дисплеям. **Маленький экран:** мало площади — допускаются **режимы, стек панелей, сворачивание** без смешения ролей зон и без переноса инструментов между PFD и MFD без смены пресета. |
| 107 | |
| 108 | <a id="plugins-attention-binding"></a> |
| 109 | |
| 110 | ### Плагины и модель внимания (будущее) |
| 111 | |
| 112 | Когда появятся **плагины / сторонние расширения** UI ([0005](0005-defer-dynamic-plugins-mef.md) — сроки открыты), они **не** могут быть «просто ещё одним окном поверх всего» без семантики: иначе модель PFD/MFD/EICAS/HUD **теряет смысл** и снова возникает гонка за z-order и внимание, от которой этот ADR уводит продукт. |
| 113 | |
| 114 | **Правило:** всё, что расширение **хочет показать** в интерфейсе IDE, **обязано** быть привязано к **модели внимания** — явно: к **якорю** (`forward` / `pfd` / `mfd`), к **каналу** (например EICAS, IDE Health) или к **слою** (HUD на лобовом), в рамках **пресета** ([0010](0010-ui-modes-toml-configuration.md), [§2.1](#21-слои-конфигурации-продукт-пользователь-workspace-репозиторий)). Формулировка для автора расширения: **«реши, чем ты являешься в кокпите»** — иначе интеграция не проходит контракт. |
| 115 | |
| 116 | Следствия: контракт загрузки расширения включает **декларацию роли** (не только технический entry point); произвольная плавающая панель без привязки к зоне — **не** целевой паттерн. |
| 117 | |
| 118 | --- |
| 119 | |
| 120 | ## 1. Термины (авионика → IDE) |
| 121 | |
| 122 | | Авионика | Определение | Аналог в Cascade | |
| 123 | |----------|-------------|-------------------| |
| 124 | | **Лобовое** (не авиационный термин; здесь — роль зоны) | Прямой обзор «наружу» — главный фокус | Редактор; внутри него — HUD (§9) | |
| 125 | | **PFD** (Primary Flight Display) | Показатели, нужные для удержания контекста и безопасного продолжения работы без потери ориентира | Зона текущего контекста: решение, где мы, над чем работаем, проблемы/диагностика (см. таблицу выше) | |
| 126 | | **MFD** (Multi-Function Display) | Тяжёлые переключаемые виды, не конкурирующие с первичным контекстом и лобовым за постоянный фокус | Git, доки, браузер, длинные логи, чат/trace, терминал и т.д. — по пресету | |
| 127 | | **EICAS / CAS** (Crew Alerting System) | Консолидированный список сообщений с приоритизацией | Единая сводка оповещений (§5); не «четвёртая зона» в смысле трёх якорей § выше | |
| 128 | | <a id="glossary-kvs"></a>**КВС** (*командир воздушного судна*, Pilot in Command) | В авиации — лицо, несущее **ответственность** за безопасность полёта и решения экипажа | **Метафора** в документации Cascade: **человек-оператор** в контуре IDE (не агент), владеющий итоговым решением. **Не** синоним **PF** (§1.0: «руки на штурвале» / активное ведение). Формулировки вроде «сигналы КВС» при [Incapacitation / присутствии](0034-pilot-incapacitation-emergency-mode-and-presence-sensing.md) относятся к **состоянию оператора** (присутствие, внимание), **ортогонально** телеметрии репозитория (IDE Health, канал EICAS про код/сборку). | |
| 129 | | **HUD** (Head-Up Display) | Проекция на лобовое стекло без отвода взгляда | Только **внутри редактора** (§9); отдельной зоны не образует | |
| 130 | |
| 131 | ### 1.0 PF/PM как Driver/Navigator (ментальная модель) |
| 132 | |
| 133 | PF/PM из авиации почти напрямую сопоставляются с парным программированием: |
| 134 | |
| 135 | - **PF (Pilot Flying) ≈ Driver**: “руки на штурвале” — активные действия и быстрый цикл правок. В IDE это прежде всего **лобовое/редактор** и минимальные HUD-подсказки по месту. |
| 136 | - **PM (Pilot Monitoring) ≈ Navigator**: удержание общей картины, риски, чеклисты, координация и контроль отклонений. В IDE это прежде всего **PFD/MFD/EICAS** как вторичные поверхности: диагностики, план, логи, Git, trace агента — по пресету. |
| 137 | |
| 138 | Это сопоставление используется как язык для обсуждения компромиссов: что должно оставаться PF/Driver‑friendly (не конкурировать с лобовым), а что является PM/Navigator‑инструментом и живёт во вторичных зонах. |
| 139 | |
| 140 | ### 1.1 Канал, слой представления, имена в коде (канон) |
| 141 | |
| 142 | <a id="glossary-channel-presentation"></a> |
| 143 | |
| 144 | Ориентир для чертежей реализации и комментариев в коде: одни и те же слова — одни и те же смыслы. Три разных «хоста» не смешивать: см. строку **ProcessHost** и примечание про **канал** vs **View**. |
| 145 | |
| 146 | <a id="glossary-cds-contract"></a> |
| 147 | |
| 148 | | Термин | Значение | |
| 149 | |--------|----------| |
| 150 | | **ProcessHost** | Внешний **процесс-хост**, который поднимает или подключается к CascadeIDE (например Cursor/IDE, запуск IDE с `--mcp-stdio` для MCP, клиент ACP). Контур **жизненного цикла процесса и транспорта**, не разметка окна и не канал EICAS / IDE Health. В доках по MCP/ACP/stdio — при необходимости говорить явно **ProcessHost**, чтобы не путать с суффиксом `*Host*` у контролов. | |
| 151 | | **Канал** | Семантический контур **данных и приоритета**: что показываем и зачем (например **канал EICAS** — W/C/A; **канал IDE Health** — build/tests/debug/git, **отдельно** от CAS). Канал — **не** имя UserControl и не геометрия экрана. | |
| 152 | | **Слой представления** | Как и где в **разметке** показать те же данные: полоса (Strip), страница зоны (Page), оверлей, карточка — по пресету (`ide_health_surface`, AXAML). Не шина событий, не маршрутизация сообщений, не «хост событий». | |
| 153 | | **`EicasAlertsBar` / `eicas_alerts_bar`** | Стабильные идентификаторы в коде и TOML: **включить слот представления** для **канала** EICAS в текущей раскладке. Контрол: `EicasAlertsBarView`. Это **не** сам канал: канал — предупреждения W/C/A и их приоритет; тип — **контейнер UI**. Имя без суффикса *Host*, чтобы не путать с ProcessHost; «Channel» в имени View не используем — в коде *Channel* ожидают у **модели/провайдера**, а не у AXAML-контейнера. | |
| 154 | | **`WorkspaceChromeBandView`** | Контейнер **полосы хрома** над нижним доком: сетка как у `MainGrid`, сверху слот `EicasAlertsBarView`, ниже `IdeHealthStripView`. По смыслу — **разметка** для **канала IDE Health** (сегменты собирает `IdeHealthSurfaceCompositor`) и слота EICAS; см. [чертёж реализации](../design/workspace-health-implementation-map-v1.md). | |
| 155 | | **CDS (контракт кабины)** | В авионике **CDS** (Cockpit Display System) — система отображения; в Cascade **в контрактном смысле** — согласованное описание **семантики кабины**: зоны внимания, топология презентации (`presentation`), какие `TopLevel` задействованы, активная страница вторичного контура, видимость регионов — **без** перечисления каждого контрола. **Не** синоним «одного класса в коде» и **не** замена каналам (IDE Health, EICAS, readiness). Детали и эволюция полей — [`cds-contract-v0.md`](../design/cds-contract-v0.md). | |
| 156 | | **`UiLayoutSnapshot` / `ide_get_ui_layout`** | Снимок **дерева визуальных элементов** (в т.ч. несколько окон, роли `main` / `mfd_host` / …) для инспекции и автоматизации. **Ортогонален** CDS: тот же экран описывается и семантикой кабины, и деревом контролов; назначения разные (внимание vs поиск по имени/иерархии). Реализация: `Cockpit/Surface/UiLayoutSnapshot.cs`; см. [0017](0017-multi-window-workspace-and-agent-surfaces.md). | |
| 157 | |
| 158 | **Канал vs контейнеры в коде:** доменный **канал** — про смысл и поток сообщений; **`EicasAlertsBarView`**, **`WorkspaceChromeBandView`** — про **где нарисовать** в окне. Переименовать их в `*Channel*` было бы вводящим в заблуждение: в коде *Channel* ожидают у **модели/провайдера**, а не у AXAML-контейнера. Для канала IDE Health смысл уже в типах `IIdeHealthChannel` / `IdeHealthInputSnapshot` / `IdeHealthSurfaceCompositor`. |
| 159 | |
| 160 | <a id="glossary-presentation-vs-channel"></a> |
| 161 | |
| 162 | ### 1.2 Слот презентации и канал содержимого (два уровня) |
| 163 | |
| 164 | В обсуждении и в документации полезно **не смешивать** два уровня абстракции. |
| 165 | |
| 166 | | Уровень | Вопрос | Примеры формулировок | |
| 167 | |--------|--------|----------------------| |
| 168 | | **Слот презентации** (поверхность региона) | *Где* и *какого размера* показываем инструмент: полоса, полная страница региона MFD, карточка, оверлей? | «полная страница MFD», «нижняя полоса IDE Health», MFD **full-page** surface | |
| 169 | | **Канал / содержимое** | *Какой* поток данных или инструмент заполняет слот? | IDE Health (build/tests/debug/git), оповещения EICAS, статус окружения (LSP, модель, транспорт агента), Git, чат | |
| 170 | |
| 171 | **Разговорная «отдельная страница»** чаще всего относится к **первому** уровню (крупный слот вместо полосы). **Что именно** на этой странице — **второй** уровень; другая страница MFD (например окружение vs IDE Health) — это **другой канал**, а не другой тип слота. |
| 172 | |
| 173 | **Имя в конфиге и коде:** значение вроде **`DedicatedPage`** у `ide_health_surface` / `IdeHealthUiSurface.DedicatedPage` задаёт **слой представления только для канала IDE Health** (те же сегменты, что у полосы, в разметке страницы вместо `IdeHealthStripView` — см. [чертёж](../design/workspace-health-implementation-map-v1.md)). Это **не** синоним «любой полноэкранной страницы MFD»; для ясности в текстах можно говорить **«страница IDE Health (режим Page)»** или **«IDE Health на полной странице MFD»**. Другие полноэкранные виды (окружение, доки и т.д.) именуются по **содержимому**, а не через перегрузку `DedicatedPage`. |
| 174 | |
| 175 | **Готовность окружения (отдельный канал от IDE Health):** быстрый ответ «всё ли ок» — LSP, транспорт агента, доступность нужных исполняемых файлов (в т.ч. через PATH на Windows/Linux), и **только те переменные окружения / пути, которые IDE сама использует**; не дамп всего `environ`. Не замена экрана настроек при редактировании. ADR: [0023](0023-environment-readiness-glance.md); чертёж: [`environment-readiness-glance-v1.md`](../design/environment-readiness-glance-v1.md). |
| 176 | |
| 177 | **IDE Health** — каноническое имя этого канала в продукте и ADR после [0089](0089-ide-omnibus-naming-and-ide-health-channel-rename.md) (ранее *Workspace Health*; опора сильнее, чем у размытого «telemetry»). Реализация в типах `IdeHealth*` (см. [чертёж реализации](../design/workspace-health-implementation-map-v1.md)). В русских подписях UI рядом уместно **состояние IDE**. Ранние черновики: «телеметрия работы», затем «операционная телеметрия». Сводный лексикон и таблица эволюции имён: [0022](0022-workspace-health-lexicon.md). |
| 178 | |
| 179 | --- |
| 180 | |
| 181 | ## 2. Соответствие зонам Cascade |
| 182 | |
| 183 | Источник имён панелей и режимов: [`cascade-ide-ui-layout-v1.md`](../ui-ux/cascade-ide-ui-layout-v1.md), [`ui-modes-overview-v1.md`](../ui-ux/ui-modes-overview-v1.md), [ADR 0010](0010-ui-modes-toml-configuration.md). |
| 184 | |
| 185 | | Слой | Роль в IDE | Кандидаты в Cascade | |
| 186 | |------|------------|---------------------| |
| 187 | | **Лобовое** | Объект работы; доминирует | Активный документ, курсор; HUD: inline diagnostics, ghost text, gutter (§9) | |
| 188 | | **PFD** | Контекст полёта без охоты по вкладкам | Solution Explorer; breadcrumbs / положение в решении; задача/сессия; Problems; компактные индикаторы следующего шага / подтверждения агента — если пресет помещает их сюда, а не в EICAS/MFD | |
| 189 | | **MFD** | Исследование и вторичные потоки | Git; полный чат/trace; нижний док (терминал, build output, тесты, отладка); доки; встроенный браузер; расширенные Agent Operations в Balanced/Power | |
| 190 | | **EICAS** | Консолидация предупреждений | Один канал W/C/A (§5); визуально — список, полоса или оверлей по пресету, **не** четвёртая колонка инструментов | |
| 191 | |
| 192 | **Правило отсечения:** если элемент **не нужен для удержания контекста и ориентира в workspace** (где мы, что ломает работу, что правим) и не относится к объекту правки в редакторе — по умолчанию это **MFD** или **EICAS**, не дублирование в PFD. **Перенос** панели между PFD и MFD — только сменой **пресета** (или пользовательского оверрайда пресета), не drag-and-drop в сессии. |
| 193 | |
| 194 | **Правило стабильности ролей:** пресет задаёт, какой инструмент в какой семантической зоне; не «подвинуть Git в PFD на день» без изменения конфигурации. |
| 195 | |
| 196 | ### Идентификаторы зон (machine-readable) |
| 197 | |
| 198 | Для данных ([ADR 0010](0010-ui-modes-toml-configuration.md)), кода и будущей привязки панелей к семантике используются **стабильные строковые id** (нижний регистр, латиница, без пробелов). Геометрия «слева / центр / справа» **не** кодируется в id: она задаётся каркасом окна и пресетом. |
| 199 | |
| 200 | | Идентификатор | Назначение | Тип | |
| 201 | |---------------|------------|-----| |
| 202 | | `forward` | Лобовое: область редактора (активный документ) | **Пространственная зона** (якорь №1) | |
| 203 | | `pfd` | PFD: текущий контекст workspace | **Пространственная зона** (якорь №2) | |
| 204 | | `mfd` | MFD: вторичные инструменты и длинные потоки | **Пространственная зона** (якорь №3) | |
| 205 | | `eicas` | EICAS / CAS: оповещения и приоритизация | **Канал внимания**, не третья колонка в том же смысле, что `pfd`/`mfd`; может быть полосой, оверлеем, компактным списком (§5) | |
| 206 | | `hud` | Inline-слой на редакторе | **Слой внутри `forward`**, не равноправная «четвёртая зона» с `pfd`/`mfd` | |
| 207 | |
| 208 | **Правила именования** |
| 209 | |
| 210 | 1. В конфигах и API использовать **только** канонические id из таблицы; не вводить синонимы (`primary_flight`, `lobovoe`, `cas` как замена `eicas`) в том же поле без явной миграции схемы. |
| 211 | 2. Смена значения id или смысла — **breaking change** для бандла `UiModes/` → инкремент **`schema_version`** в индексе ([ADR 0010](0010-ui-modes-toml-configuration.md)). |
| 212 | 3. Привязка конкретной панели к зоне в TOML — отдельная задача реализации (например ключ `attention_zone = "pfd"` у записи панели); этот ADR фиксирует **словарь допустимых значений**. |
| 213 | |
| 214 | **Минимальный набор для карты внимания:** `forward`, `pfd`, `mfd`; опционально `eicas` и привязка слоя `hud` к `forward`. |
| 215 | |
| 216 | **Реализация в коде:** |
| 217 | |
| 218 | - `Features/UiChrome/AttentionZone.cs` — константы `AttentionZoneIds`, перечисление `AttentionZone`, `AttentionZoneExtensions.TryParseCanonicalId` / `ToCanonicalId`, флаги `IsSpatialAnchor` / `IsAlertingChannel` / `IsHudLayer`. |
| 219 | - `Features/UiChrome/AttentionPanelIds.cs` — стабильные id поверхностей для ключей в `workspace.toml`. |
| 220 | - `Features/UiChrome/AttentionZonePanelRuntime.cs` — карта поверхность→зона: дефолты в коде, переопределение секцией **`[attention_zone_panels]`** в `UiModes/workspace.toml` (загрузка вместе с метриками хрома). |
| 221 | |
| 222 | ### 2.1 Слои конфигурации: продукт, пользователь, workspace (репозиторий) |
| 223 | |
| 224 | Помимо **личных** предпочтений (глобальные настройки, пользовательский бандл `UiModes`, если он предусмотрен политикой установки) имеет смысл выделять **проектный** слой: в разных репозиториях оптимальная **расстановка** одних и тех же инструментов по зонам PFD/MFD/EICAS может отличаться (монорепо vs библиотека, сервис с обязательным чатом агента vs утилита командной строки, команда договорилась держать тесты «ближе к контексту» и т.д.). Это не нарушает модель внимания — меняется **наполнение** зон в рамках тех же семантических ролей. |
| 225 | |
| 226 | | Слой | Назначение | Пример | |
| 227 | |------|------------|--------| |
| 228 | | Дефолты кода | Безопасные значения без конфига | `AttentionZonePanelRuntime` | |
| 229 | | Бандл продукта | Единая база для всех установок | `UiModes/workspace.toml` в поставке Cascade | |
| 230 | | Пользователь | Личный flow, доступ к подмене бандла | Пользовательский каталог `UiModes` / оверрайд, если поддержан | |
| 231 | | **Workspace репозитория** | Соглашение команды, едет с кодом | Фрагмент TOML с `[attention_zone_panels]` (и при необходимости метриками хрома), привязанный к открытому solution/workspace | |
| 232 | |
| 233 | **Контракт слияния (целевой):** при наличии нескольких источников для одной и той же поверхности приоритет **выше у более «локального» контекста задачи**: **workspace репозитория → пользовательский бандл → бандл продукта → дефолты кода**. Семантика зон (`pfd` / `mfd` / …) не меняется; переопределяется только **какая панель с каким id к какой зоне отнесена**, в пределах стабильных `AttentionPanelIds`. |
| 234 | |
| 235 | **DX-смысл:** снижение трения «каждый раз настраивать под репо» и выравнивание онбординга новых участников с **принятым в проекте** кокпитом — аналогично тому, как `.editorconfig` задаёт стиль в репозитории. |
| 236 | |
| 237 | **Реализация на сегодня:** при старте загружается **`UiModes/workspace.toml`** из каталога бандла приложения (`UiModeCatalog`), без автоматического слияния с файлом из открытого репозитория. **Следующий шаг:** определить стабильный путь к **пер-repo** конфигу (кандидат: `.cascade/workspace.toml` в корне репозитория или рядом с `.sln`), парсинг той же схемы `UiWorkspaceToml` и **merge поверх** значений бандла при смене активного workspace. До появления merge команды может опираться на общий бандл или дублировать нужную секцию вручную. |
| 238 | |
| 239 | --- |
| 240 | |
| 241 | ## 3. Связь с режимами Focus / Balanced / Power |
| 242 | |
| 243 | Режимы сдвигают баланс «минимум шума» vs «полный кокпит» ([`power-mode-concepts-v1.md`](../ui-ux/power-mode-concepts-v1.md)). Семантика **трёх зон** (лобовое / PFD / MFD) не меняется; меняется **видимость и площадь** MFD и плотность хрома. |
| 244 | |
| 245 | - **Focus** — максимум площади под **лобовое**; PFD — компактно; MFD (чат, док, Git) — по запросу или скрыт; HUD в редакторе — по политике режима. |
| 246 | - **Balanced** — лобовое + видимый PFD + один слой MFD по умолчанию (например чат с Agent Operations). |
| 247 | - **Power** — явный **кокпит**: больше одновременно открытого **MFD** и индикаторов IDE Health, при этом **лобовое** остаётся доминирующим, PFD — читаемым; это не «раздуть PFD чужим содержимым», а больше вторичных слоёв по пресету. |
| 248 | |
| 249 | --- |
| 250 | |
| 251 | ## 4. Агент и MCP |
| 252 | |
| 253 | - **Краткий следующий шаг, `safety_level` (`safety.observe`…`safety.autonomous`), подтверждение опасных операций** — в **лобовом** (рядом с кодом / HUD) и/или в **PFD** (контекст), по пресету; не размазывать по MFD без осознанного переключения. |
| 254 | - **MFD-уровень:** полная переписка, trace timeline, длинные логи tool calls, обзор workspace вторично. |
| 255 | |
| 256 | **ProcessHost (MCP / ACP):** сторона, которая **запускает процесс IDE или держит транспорт** (stdio, сокет) к агентным протоколам — это [§1.1 **ProcessHost**](#glossary-channel-presentation), не `EicasAlertsBarView` и не слой представления кокпита. |
| 257 | |
| 258 | Контракты MCP и имена контролов — в [`cascade-ide-ui-layout-v1.md`](../ui-ux/cascade-ide-ui-layout-v1.md); этот ADR фиксирует **приоритеты внимания**, не протокол. |
| 259 | |
| 260 | --- |
| 261 | |
| 262 | ## 5. EICAS / CAS — канал оповещений |
| 263 | |
| 264 | EICAS — **не четвёртый якорь** наряду с лобовым / PFD / MFD и **не синоним** «нижней полосы»: это **канал** оповещений с приоритизацией (W/C/A). Его можно оформить полосой, оверлеем, компактным списком или иначе — см. §«Расположение» ниже. В коде и TOML **включение представления** этого канала задаётся как **`EicasAlertsBar` / `eicas_alerts_bar`** ([§1.1](#glossary-channel-presentation)). Это **не** определение «полосы»: полоса — лишь один из вариантов разметки. На маленьком экране размещение и минимальная заметность — отдельное UX-решение (см. также Dark Cockpit, §6). |
| 265 | |
| 266 | ### Проблема |
| 267 | |
| 268 | Системные сбои (MCP disconnect, build failure, agent safety breach, test regression) сейчас разнесены по разным вкладкам и бейджам. Пользователь может пропустить критичное событие, если смотрит не в ту панель. |
| 269 | |
| 270 | ### Решение: три уровня анноцирования |
| 271 | |
| 272 | По аналогии с EICAS, все системные сообщения стекаются в **единый приоритизированный список**: |
| 273 | |
| 274 | | Уровень | Цвет | Поведение в IDE | Примеры | |
| 275 | |---------|------|-----------------|---------| |
| 276 | | **Warning** (красный) | Немедленное действие | Появляется в **зоне EICAS** или оверлеем поверх лобового/PFD по пресету; блокирует автономные действия агента до подтверждения | MCP-сервер отключился при `safety.autonomous`; сборка упала в файле, который агент сейчас меняет | |
| 277 | | **Caution** (янтарный) | Осознание, не блокировка | Бейдж в полосе IDE Health меняет цвет; запись в CAS-список | Тесты частично упали; агент превысил бюджет tool-calls | |
| 278 | | **Advisory** (нейтральный) | Информация | Только в CAS-списке, не в PFD | Git: upstream обновился; LLM latency выше обычного | |
| 279 | |
| 280 | **Бытовые слова (как у диагностик IDE), EICAS и `AnnunciatorLampLevel`:** отдельный ярус «I» не вводим — **Information** = **Advisory** (A). Цвета ламп — `CockpitPrimitivesPalette.Annunciator` ([ADR 0064](0064-deck-primitives-visual-language-render-layer-and-palette.md)). |
| 281 | |
| 282 | | Бытовое слово (IDE, доки) | EICAS | `AnnunciatorLampLevel` | Цвет / роль | |
| 283 | |---------------------------|-------|------------------------|-------------| |
| 284 | | Error; критичная поломка / недоступность сервиса | Warning (W) | `Critical` | Красный | |
| 285 | | Warning в смысле «обрати внимание», не катастрофа | Caution (C) | `Caution` | Янтарь | |
| 286 | | Information | Advisory (A) | `Advisory` | Синий | |
| 287 | |
| 288 | **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)**. |
| 289 | |
| 290 | **Почему и там, и там «Advisory»:** это не один и тот же знак в разных шкалах. В английском *advisory* — обычное слово («рекомендация», «предупреждение в общем смысле»); **TCAS** назвал уровень *Traffic Advisory* так исторически. В **EICAS** буква **A** — это **именно** третий, самый мягкий ярус системных сообщений (W/C/**A**). Слово совпало, **слоты приоритета — нет**: TA по срочности ближе к **Caution**, чем к EICAS Advisory (A). |
| 291 | |
| 292 | **Историческая справка (зачем так сложилось):** |
| 293 | |
| 294 | - **ACAS / TCAS (ICAO).** В нормативных текстах *Airborne Collision Avoidance System* описывают выдачу экипажу как **два вида advisories** — *Traffic Advisory* и *Resolution Advisory* (определения — например ICAO Annex 10 Vol. IV). Здесь *advisory* — **общий** термин: «указание экипажу» от борта по столкновениям; приставки *Traffic* / *Resolution* как раз и разводят **раннюю** подготовку (TA) и **разрешённый** манёвр/ограничение (RA). Это **другая** ось, не ярусы EICAS. |
| 295 | - **EICAS.** Система централизованных сообщений о двигателях и бортсистемах (поколение glass cockpit, коммерческая авиация 1970–80-х и далее) с самого начала строилась на **иерархии предупреждений экипажа**: красный *Warning*, янтарный *Caution*, и отдельный, более «бытовой» по смыслу слой *Advisory* — **рутинное** доведение состояния, без той же немедленности, что у W/C. Буква **A** в аббревиатуре W/C/A — про **этот** третий ярус **системных** сообщений, а не про TCAS. |
| 296 | - **Итог:** совпало **английское** слово из двух разных стандартов (столкновение в воздухе vs интегрированное табло). В нашем ADR канон **W/C/A** — про **EICAS-подобный** канал IDE; TCAS упоминаем только как **антипример** путаницы имён. |
| 297 | |
| 298 | ### Расположение |
| 299 | |
| 300 | **Один из вариантов v1:** компактный блок между полосой IDE Health (`IdeHealthStripView`) и нижним доком — не единственно возможное **размещение представления** канала. Альтернативы: **выплывающий** overlay поверх PFD/лобового при Warning, отдельная карточка в MFD, и т.д. Не постоянная панель — появляется **только при наличии активных оповещений** (Dark Cockpit, §6). |
| 301 | |
| 302 | ### Escalation |
| 303 | |
| 304 | **Цель:** если **Warning** означает «риск при текущей автономности агента», а пользователь **не взял на себя ответственность** (явно) и **условие не снялось** само — система не оставляет агента в полном автономном режиме бесконечно. Аналог dead-man / acknowledgement в авиации, не «наказание за пропущенный баннер». |
| 305 | |
| 306 | **Что считается «подтверждено» (ack):** |
| 307 | |
| 308 | - **Явное действие в UI** — кнопка вида «Понял / Снизить автономность / Продолжить осознанно» (точный копирайт — UX), которая фиксирует: пользователь **увидел** Warning и принимает дальнейшее поведение при текущем риске; или |
| 309 | - **Автоматическое снятие Warning** — причина устранена (MCP снова доступен, сборка прошла, конфликт разрешён и т.п.): таймер сбрасывается, escalation не срабатывает. |
| 310 | |
| 311 | **«Не подтверждён за N секунд»** означает: Warning **остаётся активным** (критичное условие по-прежнему истинно), и за **N** секунд не произошло ни ack, ни авто-снятия. |
| 312 | |
| 313 | **Таймлайн (логика):** |
| 314 | |
| 315 | | Момент | Поведение | |
| 316 | |--------|-----------| |
| 317 | | T=0 | Появление Warning в EICAS/оверлее; при политике — **блок опасных** автономных шагов агента до ack или до снятия причины. | |
| 318 | | 0…N | Визуал (и опционально звук по §5) дозванивают внимание; без бесконечного мигания (§6). | |
| 319 | | T=N при всё ещё активном Warning и отсутствии ack | **Downgrade** `safety_level` (например `safety.autonomous`→`safety.confirm`→`safety.observe`), **остановка** автономных действий до следующего явного повышения. Это **инвариант безопасности**, не удаление кода и не скрытый merge. | |
| 320 | |
| 321 | **N** не обязан быть одним числом для всех классов событий: для «MCP offline» может быть короче, для «сборка упала» — длиннее, если политика допускает спокойное исправление без немедленного downgrade. |
| 322 | |
| 323 | **Связь с merge и прочими потоками:** merge/Git — отдельный контур, пока политика явно не связывает его с EICAS (например «блок merge при активном Warning от агента»). Таймер N относится к **тому же** Warning, а не к merge как к отдельному таймеру. |
| 324 | |
| 325 | **Ограничение:** без дополнительных сигналов система **не отличает** «ушёл за кофе» от «осознанно принял риск». Поэтому дефолт безопаснее выражать как **downgrade автономности**, а не как необратимые действия с файлами. Полная автоматика escalation и точные N — **после** ручного подтверждения уровней в ранних версиях (см. §16 «Не цели v1»). |
| 326 | |
| 327 | ### Голосовые оповещения (мотив GPWS / TAWS) |
| 328 | |
| 329 | В авиации GPWS/TAWS — не «атмосфера», а **обучаемый контур безопасности**: короткие стандартизированные фразы, приоритет над прочим аудио. Перенос в IDE оправдан только как **опциональный аудио-слой** к той же приоритизации, что и EICAS, а не как отдельная фича «ради звука» или атмосферы. |
| 330 | |
| 331 | **Когда уместно:** дозвать внимание при **Warning**, если пользователь не смотрит в зону EICAS; перед подтверждением **опасного** шага агента; **доступность** (голосовой дубль критичного сообщения — при качественном TTS и языках). **Когда нет:** дублирование Advisory/Caution голосом, произвольное чтение длинного лога, любой звук «для настроения». |
| 332 | |
| 333 | **Контракт (если делать):** |
| 334 | |
| 335 | - По умолчанию **выкл**; включение — явный **opt-in** в настройках. |
| 336 | - Гейтинг по серьёзности: в обычном режиме только **Warning** (или согласованное подмножество критичных событий); не превращать голос в второй поток спама рядом с CAS. |
| 337 | - Короткие **фиксированные** фразы или узкий набор шаблонов — не TTS всего текста оповещения. |
| 338 | - В копирайте настроек учитывать **открытый офис** и соседей (социальная цена звука). |
| 339 | |
| 340 | **Статус:** не цель **v1**; сначала стабильный визуальный EICAS и замеры §18 — затем отдельное UX-/продуктовое решение, нужен ли аудио-канал и на каких условиях (см. §16). |
| 341 | |
| 342 | --- |
| 343 | |
| 344 | ## 6. Dark Cockpit Principle |
| 345 | |
| 346 | ### Принцип |
| 347 | |
| 348 | В нормальном полёте кокпит **тёмный** — лампы не горят, пока всё штатно. Индикатор привлекает внимание **только при отклонении**. |
| 349 | |
| 350 | ### Применение в IDE |
| 351 | |
| 352 | Зоны **PFD** и полоса IDE Health (где она по пресету) в нормальном состоянии — **спокойные**: нейтральные бейджи, отсутствие лишних цветовых акцентов, CAS-список пуст и скрыт. |
| 353 | |
| 354 | При проблеме — **активное привлечение внимания**: |
| 355 | - Бейдж Build/Test/Debug → цветовой сдвиг (нейтральный → Warning/Caution). |
| 356 | - CAS-список появляется с кратким описанием. |
| 357 | - Один пульс анимации (не бесконечное мигание — это вызывает привыкание и игнорирование). |
| 358 | |
| 359 | ### Дизайн-правило |
| 360 | |
| 361 | > Каждый элемент **первичного контекста** (PFD и при необходимости компактная полоса IDE Health по пресету) должен иметь **два визуальных состояния**: «норма» (тихий, почти невидимый) и «отклонение» (заметный). Если элемент всегда выглядит одинаково — это не часть дисциплины внимания, а декорация. |
| 362 | |
| 363 | ### Представление канала EICAS и настройки |
| 364 | |
| 365 | **Слой представления** канала EICAS/CAS (полоса, вкладка или страница MFD, оверлей, компактные индикаторы, выделенная зона в «тяжёлом» пресете) в перспективе может задаваться **пресетами и пользовательскими предпочтениями** — это вопрос плотности экрана и привычки; **семантика канала** (§5) от этого не меняется. |
| 366 | |
| 367 | **Инварианты**, не сводимые к вкусу: **Dark Cockpit** в норме (тихо, пока штатно) и **заметность эскалации** при Warning/Caution — критичное оповещение не должно теряться из-за «убрал панель ради минимализма». Политика приоритетов W/C/A и требование видимости при эскалации — **§5–§6**; конкретная геометрия — пресет. |
| 368 | |
| 369 | --- |
| 370 | |
| 371 | ## 7. Scan Pattern (паттерн сканирования) |
| 372 | |
| 373 | ### Концепция |
| 374 | |
| 375 | Пилотов обучают предсказуемому маршруту глаз по приборам (T-scan / cross-check). Раскладка IDE должна поддерживать, а не ломать естественный scan pattern. |
| 376 | |
| 377 | ### Целевой scan pattern Cascade (три зоны + HUD) |
| 378 | |
| 379 | Базовая модель — **три якоря внимания** на одном экране (порядок слева/справа задаётся пресетом): |
| 380 | |
| 381 | ``` |
| 382 | [ PFD: контекст ] [ Лобовое: редактор + HUD ] [ MFD: вторичное ] |
| 383 | ↑ ↑ ↑ |
| 384 | короткие взгляды основное время работы осознанные переключения |
| 385 | ``` |
| 386 | |
| 387 | - **PFD** — «где я в решении, что ломает работу»: обозреватель, Problems, компактный контекст задачи; без охоты по вкладкам внутри этой семантики. |
| 388 | - **Лобовое** — доминирует; **HUD** усиливает его, не добавляя отдельного окна для взгляда. |
| 389 | - **MFD** — Git, длинные логи, полный чат, доки, браузер: не требует постоянного сканирования в одном ряду с кодом. |
| 390 | |
| 391 | **EICAS** при активных предупреждениях встраивается в scan как **короткая ось** (полоса/бейдж/оверлей), не как четвёртая постоянная колонка инструментов. |
| 392 | |
| 393 | ### Дизайн-критерий |
| 394 | |
| 395 | При ревью любого нового UI-элемента: **«В какой из трёх семантических зон (или EICAS) это живёт по пресету? Ломает ли оно предсказуемость взгляда?»** Если элемент требует постоянного взгляда **мимо** лобового и PFD без осознанного переключения на MFD — пересмотреть размещение или пресет. |
| 396 | |
| 397 | --- |
| 398 | |
| 399 | ## 8. Mode Awareness и Mode Confusion |
| 400 | |
| 401 | ### Проблема |
| 402 | |
| 403 | **Mode confusion** — одна из опаснейших проблем в авиации: пилот думает, что автопилот в одном режиме, а он в другом. Несколько катастроф произошли из-за этого. |
| 404 | |
| 405 | В IDE: пользователь может не осознавать, что агент работает в `safety.autonomous`, или не заметить переключение Focus → Power. |
| 406 | |
| 407 | ### Меры |
| 408 | |
| 409 | 1. **Peripheral cue:** каждый режим имеет свой акцентный цвет окантовки окна (частично реализовано в Power с неоновыми каймами). Работает на периферийное зрение без прямого взгляда на бейдж. |
| 410 | |
| 411 | 2. **Transition handoff:** при переходе в сторону большей автономии агента (`safety.observe`→`safety.confirm`→`safety.autonomous`, Focus→Power) — краткий «handoff callout» (тост или анимация бейджа), как в авиации «my controls» / «your controls». Переход в обратную сторону — тише (снижение автономии безопасно). |
| 412 | |
| 413 | 3. **Alertness check:** если пользователь долго (настраиваемый порог) не взаимодействует в `safety.autonomous` — сигнал в **PFD или EICAS** (по пресету): «Agent is running autonomously. Still monitoring?» Аналог dead-man's switch. Нет ответа → автоматический downgrade до `safety.confirm`. |
| 414 | |
| 415 | --- |
| 416 | |
| 417 | ## 9. HUD-слой в редакторе |
| 418 | |
| 419 | ### Концепция |
| 420 | |
| 421 | В авиации HUD проецирует критичные данные прямо на лобовое стекло — пилот не отводит взгляд от внешнего мира. |
| 422 | |
| 423 | В IDE: PFD-информация может быть **наложена прямо на редактор**, без необходимости смотреть в боковые панели. |
| 424 | |
| 425 | ### Кандидаты для HUD |
| 426 | |
| 427 | | Элемент | Расположение | Назначение | |
| 428 | |---------|-------------|------------| |
| 429 | | Inline diagnostics | В теле кода | Ошибки / предупреждения по месту (частично реализовано) | |
| 430 | | Ghost text агента | В теле кода | Предлагаемое следующее изменение | |
| 431 | | Gutter agent indicator | Рядом с номером строки | Иконка: «агент собирается изменить этот файл / эту область» | |
| 432 | | File-level banner | Над текстом, под вкладкой | «Agent is actively editing this file» — тонкая полоска, как в collaborative editing | |
| 433 | |
| 434 | **Терминология (уточнение):** продуктовое имя **Editor HUD** для inline-слоя (диагностика, ghost text, gutter, подсказки у каретки / inlays) и явное отличие от **HUD banner** (file-level полоса над текстом) — [ADR 0085](0085-editor-hud-inline-layer-and-hud-banner.md). |
| 435 | |
| 436 | ### Принцип |
| 437 | |
| 438 | HUD-элементы не должны **блокировать** редактирование и должны быть визуально **легче**, чем основной текст. Они **обогащают лобовое** (и при необходимости дублируют сигнал из PFD/EICAS), а не заменяют зоны — пользователь может их отключить без потери безопасности, если критичное остаётся в PFD и EICAS. |
| 439 | |
| 440 | --- |
| 441 | |
| 442 | ## 10. Degraded Mode / Graceful Degradation |
| 443 | |
| 444 | ### Принцип |
| 445 | |
| 446 | В авиации при отказе приборов есть процедуры на каждый случай. PFD **всегда показывает что-то** — даже если это «последнее известное состояние». |
| 447 | |
| 448 | ### Таблица деградации |
| 449 | |
| 450 | | Сбой | PFD-индикация | Автоматическое действие | |
| 451 | |------|---------------|------------------------| |
| 452 | | MCP-сервер отключился | Бейдж MCP → красный/серый; last known state + таймстемп отключения | Safety auto-downgrade до `safety.observe`; CAS Warning | |
| 453 | | LLM-провайдер недоступен | Чат → заглушка «offline»; план заморожен | Агент в read-only; редактор и сборка работают штатно | |
| 454 | | Build tool не отвечает | Сегмент Build в IDE Health → «stale» с таймером | CAS Caution; не блокирует редактирование | |
| 455 | | Все MCP-серверы отвалились | Полоска IDE Health → «degraded mode» | `safety.observe` принудительно; кнопка «retry all» | |
| 456 | |
| 457 | ### Дизайн-правило |
| 458 | |
| 459 | > PFD никогда не показывает пустоту или бесконечный спиннер без объяснения. Минимум: **последнее известное значение + возраст данных + статус источника**. |
| 460 | |
| 461 | --- |
| 462 | |
| 463 | ## 11. Situational Awareness (модель Endsley) |
| 464 | |
| 465 | Три уровня ситуационной осведомлённости. Канон **`sa_level`**: `sa.perception` | `sa.comprehension` | `sa.projection` — [naming-layers-v1.md](../design/naming-layers-v1.md) §3. Legacy «SA L1–L3» **не** путать с `safety.*` и `verify_rung`. |
| 466 | |
| 467 | | sa_level | Legacy | Авиация | IDE | Обслуживается | |
| 468 | |----------|--------|---------|-----|---------------| |
| 469 | | **`sa.perception`** | SA L1 | Показания приборов | Build status, test count, agent state, git diff count | **PFD** — бейджи IDE Health, CAS-список | |
| 470 | | **`sa.comprehension`** | SA L2 | «Я слишком низко для этого этапа захода» | «3 теста упали из-за моего рефакторинга PaymentService» | **PFD** (краткое) + **MFD** (подробно) | |
| 471 | | **`sa.projection`** | SA L3 | «Через 30 секунд нужно уйти на второй круг» | «Если смержить — CI сломается» | **MFD** — Agent plan, dependency graph, чат | |
| 472 | |
| 473 | ### Дизайн-критерий для PFD-бейджей |
| 474 | |
| 475 | PFD-бейджи должны давать **не голый `sa.perception`** («Build: FAIL»), а минимум **`sa.comprehension`** — кратко раскрывать смысл: |
| 476 | |
| 477 | | Вместо (только perception) | Лучше (perception + comprehension) | |
| 478 | |-------------|------------------| |
| 479 | | Build: FAIL | Build: 2 errors in PaymentService.cs | |
| 480 | | Tests: 3 failed | Tests: 3 failed (RetryPolicy*) | |
| 481 | | Git: 5 files | Git: 5 files, 2 unstaged | |
| 482 | |
| 483 | Одна строка — но пользователь уже понимает **смысл**, а не только факт. |
| 484 | |
| 485 | --- |
| 486 | |
| 487 | ## 12. Human-Agent Resource Management (CRM → HARM) |
| 488 | |
| 489 | ### Аналогия |
| 490 | |
| 491 | В авиации Crew Resource Management чётко распределяет роли: |
| 492 | - **Pilot Flying (PF)** — управляет самолётом. |
| 493 | - **Pilot Monitoring (PM)** — следит за параметрами, вмешивается при отклонении. |
| 494 | |
| 495 | ### Маппинг на Safety Levels |
| 496 | |
| 497 | Канон **`safety_level`**: [naming-layers-v1.md](../design/naming-layers-v1.md) §2 · [0038](0038-agent-facade-ai-provider-and-tool-orchestration.md). |
| 498 | |
| 499 | | safety_level | Legacy | Роль человека | Роль агента | Авиационный аналог | |
| 500 | |-------------|--------|---------------|-------------|-------------------| |
| 501 | | **`safety.observe`** | L1 Read-only | PF (полный контроль) | PM (только наблюдает, подсказывает) | Manual flight, copilot monitoring | |
| 502 | | **`safety.confirm`** | L2 Confirm edits | PM (мониторит, подтверждает) | PF (предлагает действия, ждёт OK) | Autopilot engaged, pilot confirms mode changes | |
| 503 | | **`safety.autonomous`** | L3 Autonomous | PM (мониторит, вмешивается при проблеме) | PF (действует самостоятельно) | Full autopilot, pilot ready to intervene | |
| 504 | |
| 505 | ### PFD-индикация роли |
| 506 | |
| 507 | Зона **PFD** должна **явно показывать** текущее распределение ролей. Кандидат: компактная строка в контекстной области PFD или в бейдже safety level: |
| 508 | |
| 509 | - `safety.observe`: `Human: editing · Agent: advising` |
| 510 | - `safety.confirm`: `Agent: proposing · Human: confirming` |
| 511 | - `safety.autonomous`: `Agent: acting · Human: monitoring` |
| 512 | |
| 513 | Это делает неявное (кто сейчас «летит») — явным и читаемым на периферийном зрении. |
| 514 | |
| 515 | --- |
| 516 | |
| 517 | ## 13. Мультиоконность и мультимонитор |
| 518 | |
| 519 | Физическое разнесение усиливает метафору: **лобовое, PFD и MFD** не обязаны жить в одной колонке одного окна, если есть экраны; семантика зон сохраняется. |
| 520 | |
| 521 | ### Типичный сценарий (три монитора) |
| 522 | |
| 523 | | Экран | Семантическая зона | Содержание (пример) | |
| 524 | |------|---------------------|---------------------| |
| 525 | | **Левый** | PFD | Обозреватель решения, Problems, контекст задачи, компактные индикаторы — «в углу глаза» | |
| 526 | | **Центр** | Лобовое | Редактор + HUD | |
| 527 | | **Правый** | MFD | Git, полный чат/trace, доки, терминал — переключаемые режимы по пресету | |
| 528 | |
| 529 | Порядок **лево/право** можно менять пресетом — важно **не смешивать роли**: лобовое остаётся редактором, PFD — контекстом полёта, MFD — вторичным. |
| 530 | |
| 531 | На **одном мониторе** те же три семантики складываются в **три региона** одного рабочего стола; при **маленькой диагонали** — стек, табы, сворачивание **без** переноса инструментов между PFD и MFD в рантайме. Мультиоконность ([ADR 0017](0017-multi-window-workspace-and-agent-surfaces.md)) позволяет вынести, например, MFD на второй дисплей целиком. |
| 532 | |
| 533 | --- |
| 534 | |
| 535 | ## 14. Command Palette |
| 536 | |
| 537 | Command Palette хорошо стыкуется с тремя зонами (детали: [`command-palette-ux-concept-v1.md`](../ui-ux/command-palette-ux-concept-v1.md)): |
| 538 | |
| 539 | - **Руки на клавиатуре** — типовые действия без целения в кнопки панелей. |
| 540 | - Палитра — **временный слой поверх рабочего стола**: не заменяет обозреватель (PFD) и не заменяет чат (MFD), а даёт быстрый доступ к командам. |
| 541 | - **PFD** показывает *контекст и состояние*, **лобовое** — *объект работы*, палитра — *действие без смены фокуса мышью*. |
| 542 | |
| 543 | **Антипаттерн:** тащить в палитру навигационный шум (breadcrumbs, длинный контекст файла), который должен жить в **PFD**. Показывать в палитре только при явном сценарии. |
| 544 | |
| 545 | Политика «всё важное из палитры» снижает давление на постоянную видимость тулбаров и укладывается в ограничение числа первичных виджетов в зоне PFD. |
| 546 | |
| 547 | --- |
| 548 | |
| 549 | ## 15. Внешний агент и отдельные приложения |
| 550 | |
| 551 | Реальная среда часто включает не только Cascade: внешний агент, Cursor, другая IDE — на отдельном мониторе. |
| 552 | |
| 553 | ### Принципы |
| 554 | |
| 555 | 1. **Разделение «дисплеев экипажа».** Cascade отвечает за редактирование и встроенный контур. Внешний чат/агент — отдельный MFD-экран, не обязательная панель внутри Cascade. |
| 556 | 2. **Не конкурировать за одну полосу внимания.** Если Cursor уже на правом мониторе, правый MFD в Cascade можно держать узким или под документацию — не дублировать «второй чат». |
| 557 | 3. **Мост без захвата лобового.** Короткие сигналы от внешнего агента (подтверждение, build failure) — кандидаты в **PFD или EICAS** Cascade по пресету; полный диалог — во внешнем инструменте (MFD там же). |
| 558 | 4. **Command Palette** может включать действия «открыть внешнюю сессию», «вставить из буфера» — внешний инструмент доступен с клавиатуры. |
| 559 | |
| 560 | **Техническая связь:** Agent Client Protocol — [`note-acp-cascade-cursor-v1.md`](../ui-ux/note-acp-cascade-cursor-v1.md). |
| 561 | |
| 562 | --- |
| 563 | |
| 564 | ## 16. Risks и ограничения |
| 565 | |
| 566 | | Риск | Mitigation | |
| 567 | |------|------------| |
| 568 | | Раздуть PFD до «всё сразу» — теряется метафора | Явный лимит видимых элементов контекста в PFD (**5–7±2**); scan pattern (§7); роли фиксируются пресетом, не drag-and-drop | |
| 569 | | Перетаскивание панелей между PFD и MFD в сессии | Запрещено по модели: только пресет / оверрайд конфигурации | |
| 570 | | Dark Cockpit → пользователь забывает про панель | CAS-список с escalation напоминает о себе; Alertness check (§8.3) | |
| 571 | | Mode confusion при частом переключении | Peripheral cue + transition handoff + бейдж режима | |
| 572 | | EICAS-зона превращается в «ещё одну панель» | Показывается **только при активных оповещениях**; в норме — invisible (Dark Cockpit) | |
| 573 | | HUD перегружает редактор | HUD-элементы легче основного текста; отключаемы без потери безопасности | |
| 574 | | Голосовые алерты без дисциплины | Хуже DX, чем тишина: только §5 (opt-in, Warning, короткие фразы); не «звук на каждое событие» | |
| 575 | |
| 576 | ### Не цели v1 |
| 577 | |
| 578 | - Жёстко закреплять пиксели каждой панели — это через UX-ревью. |
| 579 | - Полная автоматика CAS-escalation — сначала ручное подтверждение уровней. |
| 580 | - Привязка пресетов к конфигурации мониторов (имя/id дисплея) — открытый вопрос для [ADR 0017](0017-multi-window-workspace-and-agent-surfaces.md). |
| 581 | - **Голосовые оповещения GPWS-like** — см. §5; не в v1, пока не закрыт минимальный визуальный EICAS и нет отдельного решения по opt-in и гейтингу. |
| 582 | |
| 583 | --- |
| 584 | |
| 585 | ## 17. Следующие шаги |
| 586 | |
| 587 | 1. ~~Реализовать в TOML привязку панелей к зонам~~ — сделано: `workspace.toml` → `[attention_zone_panels]`, `AttentionZonePanelRuntime`; дальше — **использовать карту в UI** (подсветка, IDE Health, ограничения dock) по мере готовности контролов, с **привязкой лэйаута к пространственным якорям**, а не только метаданными в данных (контекст: [§«Якоря и поток внимания»](#anchors-vs-attention-flow) в начале документа). |
| 588 | 2. Согласовать короткий список **инвариантов по зонам** (3–5 пунктов) для Focus и Power отдельно. |
| 589 | 3. Определить **минимальный v1 CAS** (EICAS): формат списка, где в раскладке на одном маленьком экране vs мультимонитор, какие источники. |
| 590 | 4. Прототипировать **Dark Cockpit transition**: нормальный бейдж → Warning-состояние (цвет + анимация). |
| 591 | 5. Зафиксировать **scan pattern** (§7) как чеклист для UX-ревью новых элементов. |
| 592 | 6. При реализации `safety.autonomous` — **Alertness check** (§8.3): порог, downgrade policy, UI. |
| 593 | 7. Обновить [`concept-to-implementation-map-v1.md`](../ui-ux/concept-to-implementation-map-v1.md) столбцом «лобовое / PFD / MFD / EICAS / HUD» для ключевых контролов. |
| 594 | 8. Опционально: пресеты раскладки окон под два/три монитора (§13) — не обязательно в v1 продукта, но как целевой сценарий. |
| 595 | 9. Проработать политику **роутинга** зон при мультиоконности — отдельное UX-решение или продолжение [ADR 0017](0017-multi-window-workspace-and-agent-surfaces.md). |
| 596 | <a id="adr0021-s17-p10"></a> |
| 597 | 10. Зафиксировать **числовые бюджеты** §18 по профилированию на референсном железе; до этого §18 — чеклист без обязательных SLA. |
| 598 | 11. Реализовать **слияние workspace репозитория** с бандлом для `[attention_zone_panels]` (и при необходимости метрик хрома): путь к файлу, момент загрузки при открытии solution, приоритеты §2.1. |
| 599 | 12. Контент **онбординга** по §19: сценарии коротких роликов (зоны, режимы, агент), единая рамка «Почему / Зачем / Что я получу» в подсказках и на страницах справки; нарастающие идеи и план — [`onboarding-first-run-v1.md`](../design/onboarding-first-run-v1.md). |
| 600 | 13. После стабильного EICAS: оценить **голосовой слой** §5 (нужен ли, opt-in, только Warning, офис/доступность) — отдельно от «атмосферы». |
| 601 | 14. **Скины оформления (skin bundles)** — отложено; идея и границы от тем/пресетов: [ADR 0024](0024-ui-skin-bundles-deferred.md). |
| 602 | |
| 603 | ### Редактор раскладки зон (визуальный, по мотивам FancyZones) |
| 604 | |
| 605 | Внешний референс UX: [FancyZones](https://learn.microsoft.com/ru-ru/windows/powertoys/fancyzones) (PowerToys) — пользовательские макеты зон на рабочем столе и привязка окон к зонам. |
| 606 | |
| 607 | **В Cascade это другой слой:** не замена оконному менеджеру ОС, а **настройка пресета** раскладки IDE (пропорции колонок, видимость хрома, IDE Health (strip vs page) и т.д. — см. [0010](0010-ui-modes-toml-configuration.md), чертёж [`workspace-health-implementation-map-v1.md`](../design/workspace-health-implementation-map-v1.md)). Инвариант ADR сохраняется: **не** перетаскивать семантику PFD/MFD/EICAS между зонами в обычной рабочей сессии — только смена пресета / конфигурации (§16). |
| 608 | |
| 609 | | Уровень | Содержание | |
| 610 | |---------|------------| |
| 611 | | **MVP** | Предпросмотр пресета, числовые доли / ограниченный набор шаблонов, правка через TOML с валидацией | |
| 612 | | **Расширение** | Упрощённый grid-редактор в отдельном режиме «настройка пресета» (не в потоке редактирования) | |
| 613 | | **Не цель по умолчанию** | Полный паритет с FancyZones (произвольная сетка, мультизона drag, горячие клавиши на все мониторы) — высокая стоимость и риск дублировать роль ОС и [ADR 0017](0017-multi-window-workspace-and-agent-surfaces.md) | |
| 614 | |
| 615 | **Статус:** решение зафиксировано на уровне принципов; детальная спецификация UI — в `docs/design/`, когда появится реализация. Отдельный ADR не требуется до смены инвариантов зон. |
| 616 | |
| 617 | --- |
| 618 | |
| 619 | ## 18. DX acceptance: измеримые критерии |
| 620 | |
| 621 | Модель внимания (§1–§17) задаёт **качественную** планку. Для релиза и регрессий нужен **мост к цифрам**: что считаем «достаточно хорошим» DX помимо субъективного «удобно». Конкретные пороги ниже — **черновик**; финальные значения фиксируются после профилирования и пользовательских прогонов (см. [§17 п. 10](#adr0021-s17-p10)). |
| 622 | |
| 623 | ### 18.1 Ядро редактора (ортогонально зонам, блокирует весь DX) |
| 624 | |
| 625 | | Метрика | Цель (черновик) | Как мерить | |
| 626 | |--------|-----------------|------------| |
| 627 | | Задержка ввода до отображения символа в лобовом | p95 ≤ **16 ms** на референсной машине | Инструментирование UI thread / frame timing | |
| 628 | | Время до первой диагностики Roslyn по сохранённому файлу | p95 ≤ **500 ms** (порядок; уточнить по проекту) | Лог анализатора / тестовый solution | |
| 629 | | Холодный старт до готовности ввода в открытом документе | порог **TBD** (секунды) | Stopwatch от запуска до editable | |
| 630 | |
| 631 | Если ядро медленное, кокпит и зоны не компенсируют — критерий **блокирующий** для «готовности к широкому использованию». |
| 632 | |
| 633 | ### 18.2 Время до «осмысленного действия» (onboarding / поток) |
| 634 | |
| 635 | | Метрика | Цель (черновик) | Как мерить | |
| 636 | |--------|-----------------|------------| |
| 637 | | **Time to first edit** — от старта IDE до первого сохранённого символа в файле проекта | **TBD** (например до 60 с для опытного пользователя с шаблоном) | Сценарий теста / продуктовые метрики (опционально) | |
| 638 | | **Time to first build feedback** — от «запустить сборку» до первого сообщения в выводе/EICAS | **TBD** | Ручной сценарий + лог | |
| 639 | | **Time to first safe agent action** — от включения агента до первого **подтверждённого** безопасного шага (`safety.confirm`) или осознанного `safety.autonomous` с видимым бейджем | **TBD** | Сценарий + чеклист §8 | |
| 640 | |
| 641 | ### 18.3 Модель внимания (качественно + контроль регрессий) |
| 642 | |
| 643 | Ось «**где** на экране (якоря)» vs «**как** ведёт себя внимание (flow, режимы, EICAS)» — [§«Якоря и поток внимания»](#anchors-vs-attention-flow); при ревью не смешивать. |
| 644 | |
| 645 | | Критерий | Проверка | |
| 646 | |----------|----------| |
| 647 | | **Scan** | Новый элемент UI имеет зону по пресету (§7); нет обязательного постоянного взгляда «мимо» лобового+PFD без осознанного MFD. | |
| 648 | | **Роли зон** | Нет переноса панелей между PFD и MFD без смены конфигурации (§2, §16). | |
| 649 | | **EICAS на критическом пути** | Warning по агенту/сборке **заметен** без охоты по вкладкам (§5); при маленьком экране — явный сценарий в UX-ревью. | |
| 650 | | **Dark Cockpit** | В норме нет лишних цветных акцентов; при отклонении — заметный переход (§6). | |
| 651 | |
| 652 | Подходит для **UX-ревью и чеклиста QA**, не обязательно для автоматического CI в v1. |
| 653 | |
| 654 | ### 18.4 Доверие и автономность агента |
| 655 | |
| 656 | | Критерий | Проверка | |
| 657 | |----------|----------| |
| 658 | | Текущий **`safety_level`** различим без открытия MFD | Peripheral cue / бейдж (§8). | |
| 659 | | Переход `safety.confirm`→`safety.autonomous` (или Focus→Power при росте автономии) даёт **краткий handoff** | Не молча (§8.2). | |
| 660 | | Деградация (MCP offline и т.д.) | PFD/EICAS не пустые и не бесконечный спиннер (§10). | |
| 661 | |
| 662 | ### 18.5 Discoverability (вторичный слой) |
| 663 | |
| 664 | | Критерий | Проверка | |
| 665 | |----------|----------| |
| 666 | | Действия без мыши | Критичные команды доступны из Command Palette или хоткеев ([ADR 0013](0013-command-surface-and-discoverability.md)). | |
| 667 | | Навигационный шум не засоряет палитру | Как в §14. | |
| 668 | |
| 669 | ### 18.6 Как использовать |
| 670 | |
| 671 | - **Перед релизом:** пройти §18.3–§18.5 чеклистом; §18.1–§18.2 — по возможности замерить, иначе зафиксировать «не замерено». |
| 672 | - **При споре «идеальный ли DX»:** сначала ядро (§18.1), затем внимание и агент (§18.3–§18.4); §18.2 и discoverability — усиливают, но не подменяют ядро. |
| 673 | |
| 674 | --- |
| 675 | |
| 676 | ## 19. Онбординг: снижение налога на модель и диалог с аудиторией |
| 677 | |
| 678 | **Живой чертёж** (идеи First Run, флаг vs режим UI, PFD + чеклист, палитра): [`onboarding-first-run-v1.md`](../design/onboarding-first-run-v1.md). |
| 679 | |
| 680 | Богатая модель внимания (зоны, режимы, EICAS, уровни агента) вводит **onboarding tax**: время и внимание, чтобы её освоить. Снижать этот налог нужно **не длинным текстом в ADR**, а **короткими, задачными объяснениями** в продукте. |
| 681 | |
| 682 | ### 19.1 Короткие видео (ориентир — ClickUp и аналоги) |
| 683 | |
| 684 | - **Формат:** ролики на **несколько минут** каждый, один сценарий / одна идея («где контекст», «что в MFD», «как переключить режим», «что такое предупреждение в EICAS»). |
| 685 | - **Цель:** показать **как** пользоваться кокпитом без чтения спецификации; дублировать ссылки из первого запуска, пустых состояний и справки. |
| 686 | - **Не заменяет** документацию для power user и не отменяет §18 по метрикам — дополняет **вход** в продукт. |
| 687 | |
| 688 | ### 19.2 Обязательная рамка для любого объяснения «в лоб» |
| 689 | |
| 690 | Без ответов на три вопроса **нельзя выстроить диалог** с аудиторией: пользователь остаётся в режиме «мне навязали термины». Любой заметный онбординг (видео, первая модалка, блок в справке, подсказка к зоне) должен явно или кратко закрывать: |
| 691 | |
| 692 | | Вопрос | Смысл | |
| 693 | |--------|--------| |
| 694 | | **Почему?** | Какую проблему решает эта часть интерфейса (перегруз, потеря контекста, небезопасный агент и т.д.). | |
| 695 | | **Зачем?** | Какую роль она играет в **общей** модели Cascade (зона внимания, канал оповещений, режим сдерживания шума). | |
| 696 | | **Что мне это даст?** | Конкретный выигрыш: меньше переключений, быстрее увидеть ошибку, яснее граница агента — без абстрактного «удобнее». | |
| 697 | |
| 698 | Проверка при ревью копирайта и сценариев роликов: **если третий столбец пустой или общий** — доработать, иначе онбординг не выполняет работу. |
| 699 | |
| 700 | ### 19.3 Связь с §18 |
| 701 | |
| 702 | Time-to-first-edit и time-to-first-safe-agent-action (§18.2) улучшаются, когда пользователь **не обязан** сначала понять авионику: видео + рамка «Почему / Зачем / Что я получу» — часть продукта, а не «документация на потом». |
| 703 | |
| 704 | --- |
| 705 | |
| 706 | ## Отклонённые альтернативы |
| 707 | |
| 708 | - **Оставить PFD/MFD как неформальный концепт без ADR** — отклонено: модель внимания влияет на каждое решение по раскладке, и формализация в ADR делает принципы обязательными при ревью UI. |
| 709 | - **Отдельные ADR на каждый аспект (EICAS, Dark Cockpit, Scan Pattern и т.д.)** — отклонено: все аспекты — части одной модели внимания; разбивать — терять целостность. |
| 710 | - **Сертификационная база DO-178C и буквальная реализация ARINC 661** — вне scope. **Переносимые идеи 661** (композитор, контракты зон, явная иерархия) — зафиксированы в [контексте](#arinc-661-borrow) выше; метафора кокпита остаётся руководством для UX, не требованием авиационного соответствия. |
| 711 | |
| 712 | --- |
| 713 | |
| 714 | ## Статус после принятия |
| 715 | |
| 716 | Статус **Accepted**; [`concept-pfd-mfd-cascade-v1.md`](../ui-ux/concept-pfd-mfd-cascade-v1.md) получает пометку «Superseded by ADR 0021». При изменении раскладки — ревью по scan pattern (§7) и PFD-лимиту (§16) обязательно. |
| 717 | |
| 718 | --- |
| 719 | |
| 720 | ## История изменений |
| 721 | |
| 722 | <a id="adr0021-history"></a> |
| 723 | |
| 724 | | Дата | Изменение | |
| 725 | |------|-----------| |
| 726 | | — | §1 таблица терминов: **КВС** (метафора оператора; якорь `#glossary-kvs`); связь с [0034](0034-pilot-incapacitation-emergency-mode-and-presence-sensing.md). | |
| 727 | | — | §1.1 **ProcessHost** (MCP/ACP) vs UI; уточнение «канал ≠ `*Host*` View». | |
| 728 | | — | §1.1 словарь «канал / слой представления / имена в коде»; §5: EICAS как канал (не синоним полосы / не третья колонка); уточнение «Расположение». | |
| 729 | | — | §1.2: слот презентации vs канал; `DedicatedPage` / `ide_health_surface` (только IDE Health). Якорь: `#glossary-presentation-vs-channel`. | |
| 730 | | — | §17 подпункт «Редактор раскладки (FancyZones-аналог)»; переносимые идеи ARINC 661; §5 Escalation; голос; §2.1; §19; §16/§17; три зоны, HUD, §18 DX acceptance. | |
| 731 | | — | §19: ссылка на живой чертёж [`onboarding-first-run-v1.md`](../design/onboarding-first-run-v1.md). | |
| 732 | | — | §ARINC 661: расшифровка **CDS** (Cockpit Display System). | |
| 733 | | — | §«Архитектура зон»: содержимое якорей PFD/MFD vs термин Page у канала IDE Health (`ide_health_surface`). Ранее под §«Архитектура зон»: **якоря vs attention flow** (не смешивать). | |
| 734 | | — | «операционная телеметрия» / «телеметрия работы». | |
| 735 | | 2026-04-06 | §«Плагины и модель внимания»: обязательная привязка расширений к зоне/каналу/пресету. | |
| 736 | | 2026-04-11 | в тексте зафиксировано имя **Workspace Health**; **канон сейчас** — **IDE Health** ([0089](0089-ide-omnibus-naming-and-ide-health-channel-rename.md)) (сборка, тесты, отладка, git); в русских подписях рядом уместно **состояние IDE**, избегая путаницы с каталогом workspace на диске. | |
| 737 | | 2026-04-12 | §1.1: термины **CDS (контракт кабины)** и отличие от **`UiLayoutSnapshot`**; живой чертёж [`cds-contract-v0.md`](../design/cds-contract-v0.md). | |
| 738 | | 2026-04-12 | §Контекст: подпункт **«Когнитивная нагрузка и нейроотличие»** — продуктовая связка (не медицина, не новые инварианты §1–§18); ссылка на публичный эскиз на сайте автора. | |
| 739 | | 2026-04-15 | после таблицы зон: отсылка к [0037](0037-pfd-surface-invariants-and-roslyn-enforcement.md#adr0037-zone-vs-surface) (география PFD vs строгая поверхность по маркеру). | |
| 740 | |