Концепт PFD / MFD для Cascade IDE (v1)¶

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

Дополнения: мультимонитор и Command Palette (§6–§7), внешний агент и отдельные IDE (§8).

Термины (авионика):

PFD (Primary Flight Display) — дисплей первичного полёта: минимальный набор показателей, без которых нельзя удерживать безопасное состояние (аттитюд, скорость, высота, курс). Всегда в одном зоне внимания, мало переключений.
MFD (Multi-Function Display) — мультифункциональный экран: карта, системы, двигатели и т.д. Контекст переключают осознанно; это не конкурирует с PFD за постоянный фокус.

Зачем перенос в IDE: разделить «то, без чего сессия разваливается» (редактирование, критичные сигналы, следующий безопасный шаг) и «то, куда уходишь на подзадачу» (обозреватель, длинные логи, чат агента, git-диффы на весь экран).

1. Соответствие зонам Cascade (v1)¶

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

Слой	Роль в IDE	Кандидаты в Cascade (не жёсткая спецификация)
PFD	Постоянный «горизонт»: где я, что сейчас ломает работу, куда нажать дальше без охоты по вкладкам	Центральная колонка редактора (активный документ, курсор); Task cockpit (задача, статус, прогресс) как «режим полёта задачи»; критичные индикаторы следующего шага (например сборка/тесты в компактной полосе, если от них зависит продолжение); в режимах с агентом — минимальный блок подтверждения следующего действия там, где пользователь уже смотрит (см. Focus в `concept-to-implementation-map-v1.md`).
MFD	Переключаемые тяжёлые виды: исследование, контекст, длинный вывод	Solution Explorer (дерево, навигация по решению); чат (история, план, trace — объёмно); нижний док (терминал, build output, тесты, отладка, события); расширенные блоки Agent Operations / Trace в Balanced/Power; полноэкранные или широкие сценарии настройки.

Правило отсечения: если элемент не нужен для удержания «самолёта в воздухе» (понимание текущей задачи + правка + знание, безопасно ли продолжать) — по умолчанию это MFD, а не дублирование в PFD.

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

Режимы уже сдвигают баланс «минимум шума» vs «кокпит» (power-mode-concepts-v1.md):

Focus — ближе к узкому PFD: редактор + компактный task bar + минимальный чат (план / next / confirm); обозреватель и док — по запросу.
Balanced — PFD + один слой MFD по умолчанию (например чат с Agent Operations).
Power — явный кокпит: много сигналов сразу; это не «больше PFD», а больше MFD-слоёв, собранных в одном визуальном ряду (телеметрия, trace, safety). Риск: смешать критичное и декоративное — концепт PFD/MFD требует следить, чтобы первичная полоса внимания оставалась читаемой (см. §4).

3. Агент и MCP¶

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

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

4. Риски и не-цели¶

Риск: раздуть PFD до «всего сразу» — тогда теряется сама метафора. Нужен явный лимит числа первичных виджетов на экране задачи.
Не цель v1: жёстко закреплять пиксели и видимость каждой панели — это следом через UX-ревью и ADR.
Открытые вопросы: что считать «критичной диагностикой» для PFD (только ошибки компиляции vs все squiggle); нужна ли отдельная «аварийная» зона (аналог EICAS) для глобальных сбоев MCP/сборки; роутинг зон PFD/MFD — насколько по умолчанию автоматически выбирается целевой монитор/окно для результата команды и фокуса vs сколько задаётся явными пресетами/настройкой (см. §6–§7).

5. Следующие шаги (когда созреет)¶

Согласовать короткий список PFD-инвариантов (3–5 пунктов) для Focus и для Power отдельно.
При необходимости вынести спорные решения в ADR (например «чат никогда не перекрывает редактор в Focus при вводе»).
Обновить concept-to-implementation-map-v1.md столбцом «PFD / MFD» для ключевых контролов.
Опционально: пресеты раскладки окон под два/три монитора (см. §6) — не обязательно в v1 продукта, но полезно как целевой сценарий power-user.
Зафиксировать в UX-обсуждении: где по умолчанию чат агента (встроенный MFD vs внешний монитор) для типовых персон (см. §8).
При появлении Command Palette в продукте — чеклист: покрытие команд меню/тулбара, конфликты хоткеев с ОС и соседними IDE (см. §7).
Проработать политику роутинга (§4): авто vs пресеты раскладки PFD/MFD при мультиоконности и мультимониторе — отдельное UX-решение или ADR, когда появится реализация окон.

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

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

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

Зона	Роль	Содержание (идея)
Левый	PFD	Task cockpit, критичные индикаторы (сборка/тесты/безопасность), подтверждения следующего шага — всё, что нужно «держать в углу глаза», не отрываясь от центра.
Центр	Редактор	Код как основной объект внимания; минимум боковых отвлечений.
Правый	MFD	Solution Explorer, длинный чат/trace, доки, git — переключаемые режимы на одном большом поле.

Порядок лево/право можно менять (PFD справа, MFD слева) — важно не смешивать роли: один экран под первичные сигналы, другой под исследование и контекст, центр под правку.

На одном мониторе те же роли остаются, но складываются в колонки одного окна (как сейчас в Cascade) или в плавающие окна — мультиоконность приложения позволяет вынести, например, MFD на второй дисплей без дублирования «второго редактора».

7. Command Palette¶

Command Palette (глобальная палитра команд по вводу с клавиатуры) хорошо стыкуется с PFD/MFD:

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

Не тащить в палитру навигационный шум по умолчанию: путь в дереве, «хлебные крошки», длинный контекст файла — это роль MFD (обозреватель, контекст), а не строки списка команд. Показывать что-то из этого в палитре только если есть отдельный сценарий (например команда явно про «текущий файл») — иначе получается шум в духе Ctrl+Shift+P в VS Code, где к командам примешивается лишняя информация. Детали отображения строк — в command-palette-ux-concept-v1.md §3.

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

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

Реальная среда часто включает не только Cascade: внешний агент (другой клиент, API), Cursor или другая IDE/чат, занимающие отдельное окно и монитор. Это не ошибка концепта PFD/MFD, если их явно не путать с внутренними зонами Cascade.

Принципы:

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

Итог: мультиоконность и три монитора усиливают PFD/MFD; внешний агент и Cursor — соседние приборные панели, а не обязательные элементы внутри одного макета. Концепт остаётся читаемым, если не требовать, что «весь интеллект» живёт только внутри правой колонки Cascade.

Технический слой (отдельно): связь IDE↔внешний агент по стандарту Agent Client Protocol — см. заметку note-acp-cascade-cursor-v1.md; локальный smoke без Cursor — samples/AcpSmoke/README.md.