Forge
markdowndeeb25a2
1# Концепт PFD / MFD для Cascade IDE (v1)
2
3**Статус:** черновик концепта (не ADR). Задаёт общий язык и критерии «что первично вниманию», без фиксации каждой пиксельной политики. Конкретные решения по UI — отдельными ADR после согласования.
4
5**Дополнения:** мультимонитор и Command Palette (§6–§7), внешний агент и отдельные IDE (§8).
6
7**Термины (авионика):**
8
9- **PFD (Primary Flight Display)** — дисплей **первичного полёта**: минимальный набор показателей, без которых нельзя удерживать безопасное состояние (аттитюд, скорость, высота, курс). Всегда в одном зоне внимания, мало переключений.
10- **MFD (Multi-Function Display)** — **мультифункциональный** экран: карта, системы, двигатели и т.д. Контекст **переключают осознанно**; это не конкурирует с PFD за постоянный фокус.
11
12**Зачем перенос в IDE:** разделить «то, без чего сессия разваливается» (редактирование, критичные сигналы, следующий безопасный шаг) и «то, куда уходишь на подзадачу» (обозреватель, длинные логи, чат агента, git-диффы на весь экран).
13
14---
15
16## 1. Соответствие зонам Cascade (v1)
17
18Источник имён панелей и режимов: [`cascade-ide-ui-layout-v1.md`](cascade-ide-ui-layout-v1.md), [`ui-modes-overview-v1.md`](ui-modes-overview-v1.md), [ADR 0010](../adr/0010-ui-modes-toml-configuration.md).
19
20| Слой | Роль в IDE | Кандидаты в Cascade (не жёсткая спецификация) |
21| ------ | ---------- | --------------------------------------------- |
22| **PFD** | Постоянный «горизонт»: где я, что сейчас ломает работу, куда нажать дальше без охоты по вкладкам | Центральная **колонка редактора** (активный документ, курсор); **Task cockpit** (задача, статус, прогресс) как «режим полёта задачи»; **критичные** индикаторы следующего шага (например сборка/тесты в компактной полосе, если от них зависит продолжение); в режимах с агентом — минимальный блок **подтверждения следующего действия** там, где пользователь уже смотрит (см. Focus в [`concept-to-implementation-map-v1.md`](concept-to-implementation-map-v1.md)). |
23| **MFD** | Переключаемые тяжёлые виды: исследование, контекст, длинный вывод | **Solution Explorer** (дерево, навигация по решению); **чат** (история, план, trace — объёмно); **нижний док** (терминал, build output, тесты, отладка, события); расширенные блоки **Agent Operations / Trace** в Balanced/Power; полноэкранные или широкие сценарии настройки. |
24
25**Правило отсечения:** если элемент **не нужен для удержания «самолёта в воздухе»** (понимание текущей задачи + правка + знание, безопасно ли продолжать) — по умолчанию это **MFD**, а не дублирование в PFD.
26
27---
28
29## 2. Связь с режимами Focus / Balanced / Power
30
31Режимы уже сдвигают баланс «минимум шума» vs «кокпит» ([`power-mode-concepts-v1.md`](power-mode-concepts-v1.md)):
32
33- **Focus** — ближе к **узкому PFD**: редактор + компактный task bar + минимальный чат (план / next / confirm); обозреватель и док — по запросу.
34- **Balanced** — PFD + один слой MFD по умолчанию (например чат с Agent Operations).
35- **Power** — явный **кокпит**: много сигналов сразу; это не «больше PFD», а **больше MFD-слоёв**, собранных в одном визуальном ряду (телеметрия, trace, safety). Риск: смешать критичное и декоративное — концепт PFD/MFD требует следить, чтобы **первичная полоса внимания** оставалась читаемой (см. §4).
36
37---
38
39## 3. Агент и MCP
40
41- **PFD-уровень для агента:** краткий следующий шаг, уровень безопасности (L1–L3), подтверждение опасных операций — в зоне, куда пользователь смотрит при редактировании, а не только внизу длинного чата.
42- **MFD-уровень:** полная переписка, trace timeline, длинные логи tool calls, обзор workspace — как на «втором дисплее».
43
44Контракты MCP и имена контролов остаются в [`cascade-ide-ui-layout-v1.md`](cascade-ide-ui-layout-v1.md); этот документ не меняет протокол, только **приоритеты внимания** при доработке раскладки.
45
46---
47
48## 4. Риски и не-цели
49
50- **Риск:** раздуть PFD до «всего сразу» — тогда теряется сама метафора. Нужен явный лимит числа **первичных** виджетов на экране задачи.
51- **Не цель v1:** жёстко закреплять пиксели и видимость каждой панели — это следом через UX-ревью и ADR.
52- **Открытые вопросы:** что считать «критичной диагностикой» для PFD (только ошибки компиляции vs все squiggle); нужна ли отдельная «аварийная» зона (аналог EICAS) для глобальных сбоев MCP/сборки; **роутинг зон PFD/MFD** — насколько по умолчанию **автоматически** выбирается целевой монитор/окно для результата команды и фокуса vs сколько задаётся **явными пресетами/настройкой** (см. §6–§7).
53
54---
55
56## 5. Следующие шаги (когда созреет)
57
581. Согласовать короткий список **PFD-инвариантов** (3–5 пунктов) для Focus и для Power отдельно.
592. При необходимости вынести спорные решения в ADR (например «чат никогда не перекрывает редактор в Focus при вводе»).
603. Обновить [`concept-to-implementation-map-v1.md`](concept-to-implementation-map-v1.md) столбцом «PFD / MFD» для ключевых контролов.
614. Опционально: пресеты раскладки окон под **два/три монитора** (см. §6) — не обязательно в v1 продукта, но полезно как целевой сценарий power-user.
625. Зафиксировать в UX-обсуждении: **где по умолчанию чат агента** (встроенный MFD vs внешний монитор) для типовых персон (см. §8).
636. При появлении Command Palette в продукте — чеклист: покрытие команд меню/тулбара, конфликты хоткеев с ОС и соседними IDE (см. §7).
647. Проработать политику **роутинга** (§4): авто vs пресеты раскладки PFD/MFD при мультиоконности и мультимониторе — отдельное UX-решение или ADR, когда появится реализация окон.
65
66---
67
68## 6. Мультиоконность и мультимонитор
69
70Физическое разнесение усиливает метафору: не нужно упихивать PFD и MFD в одну колонку, если есть экраны.
71
72**Типичный сценарий (три монитора):**
73
74| Зона | Роль | Содержание (идея) |
75| ---- | ---- | ----------------- |
76| **Левый** | PFD | Task cockpit, критичные индикаторы (сборка/тесты/безопасность), подтверждения следующего шага — всё, что нужно «держать в углу глаза», не отрываясь от центра. |
77| **Центр** | Редактор | Код как основной объект внимания; минимум боковых отвлечений. |
78| **Правый** | MFD | Solution Explorer, длинный чат/trace, доки, git — переключаемые режимы на одном большом поле. |
79
80Порядок **лево/право можно менять** (PFD справа, MFD слева) — важно не смешивать роли: один экран под **первичные сигналы**, другой под **исследование и контекст**, центр под **правку**.
81
82На **одном мониторе** те же роли остаются, но складываются в колонки одного окна (как сейчас в Cascade) или в плавающие окна — мультиоконность приложения позволяет вынести, например, MFD на второй дисплей без дублирования «второго редактора».
83
84---
85
86## 7. Command Palette
87
88**Command Palette** (глобальная палитра команд по вводу с клавиатуры) хорошо стыкуется с PFD/MFD:
89
90- **Руки остаются на клавиатуре** — не нужно целиться в узкие кнопки боковых панелей для типовых действий.
91- Палитра — **слой поверх MFD**: не заменяет дерево решения или чат, но даёт быстрый доступ к командам, которые иначе спрятаны в меню или на разных вкладках MFD.
92- Сценарий: PFD показывает *состояние*, редактор — *объект работы*, палитра — *действие без смены фокуса мышью*.
93
94**Не тащить в палитру навигационный шум по умолчанию:** путь в дереве, «хлебные крошки», длинный контекст файла — это роль **MFD** (обозреватель, контекст), а не строки списка команд. Показывать что-то из этого в палитре только если есть **отдельный сценарий** (например команда явно про «текущий файл») — иначе получается шум в духе Ctrl+Shift+P в VS Code, где к командам примешивается лишняя информация. Детали отображения строк — в [`command-palette-ux-concept-v1.md`](command-palette-ux-concept-v1.md) §3.
95
96Политика «всё важное доступно из палитры» снижает давление на постоянную видимость тулбаров и укладывается в ограничение числа первичных виджетов на PFD (см. §4).
97
98---
99
100## 8. Внешний агент и отдельные приложения (Cursor и др.)
101
102Реальная среда часто включает **не только Cascade**: внешний агент (другой клиент, API), **Cursor** или другая IDE/чат, занимающие отдельное окно и монитор. Это **не ошибка** концепта PFD/MFD, если их явно не путать с внутренними зонами Cascade.
103
104**Принципы:**
105
1061. **Разделение «дисплеев экипажа».** Cascade отвечает за редактирование и встроенный контур (диагностики, MCP к IDE, подтверждения в фокусе задачи). Внешний чат/агент — отдельный **экран или монитор**, со своим MFD-характером (длинный контекст, планирование), а не обязательная панель внутри одного окна Cascade.
1072. **Не конкурировать за одну и ту же полосу внимания.** Если Cursor уже на правом мониторе, правый MFD в Cascade можно держать узким, свернутым или под документацию/логи — чтобы не дублировать «второй чат» пиксель в пиксель.
1083. **Мост без захвата PFD.** Короткие сигналы от внешнего агента (нужно подтверждение, билд упал) — кандидаты в **PFD-полосу** Cascade; полный диалог — во внешнем инструменте или по явному переходу (хоткей, монитор).
1094. **Command Palette в Cascade** может включать действия «открыть внешнюю сессию», «вставить из буфера» и т.д., чтобы внешний инструмент оставался **на клавиатуре**, а не только в мышином клике по другому окну.
110
111**Итог:** мультиоконность и три монитора усиливают PFD/MFD; внешний агент и Cursor — **соседние приборные панели**, а не обязательные элементы внутри одного макета. Концепт остаётся читаемым, если не требовать, что «весь интеллект» живёт только внутри правой колонки Cascade.
112
113**Технический слой (отдельно):** связь IDE↔внешний агент по стандарту **Agent Client Protocol** — см. заметку [`note-acp-cascade-cursor-v1.md`](note-acp-cascade-cursor-v1.md); локальный smoke без Cursor — [`samples/AcpSmoke/README.md`](../../samples/AcpSmoke/README.md).
114
View only · write via MCP/CIDE