ADR 0073: PFD instrument deck — каталог вариантов состава и поверхностей (SA)¶
Статус: Proposed
Дата: 2026-04-19
Связанные ADR¶
| ADR | Роль |
|---|---|
| 0021 | модель внимания PFD/MFD |
| 0037 | строгая PFD-поверхность, [PfdStrict] / PfdStrictControl; не синоним всей географии колонки PFD |
| 0063 | instrument deck как именованная композиция в одном якоре; ось ContentRepresentation |
| 0064 | примитивы / палитра отрисовки приборов |
| 0066 | Cockpit UI vs presentation IDE |
| 0050 | [instrument_routing], слоты pfd_primary / … |
| 0047 | Instrument, CockpitInstrumentDescriptor |
| 0008 | MCP / паритет с командами |
| 0011 | SA в отладке — родственная ось «осведомлённость» |
| 0061 | ADR-карта и индикатор на PFD — кандидат в ту же колоду |
Резюме¶
- Каталог вариантов PFD instrument deck (SA, metrics, semantic map, ADR indicator…).
- Критерии «PFD vs по запросу»; живой черновик до выбора пресета.
Вне ADR¶
| Документ | Роль |
|---|---|
| §3 | §3 |
| Назначение ADR: зафиксировать рабочее место для перебора вариантов — какие инструменты и в каком режиме имеют смысл на PFD (первичный скан, тактика), не смешивая с MFD/палитрой без явного решения. Это не дублирует норматив 0063 по терминам; здесь — предметный список кандидатов и открытые развилки. |
Контекст¶
PFD в 0021 — зона первичного внимания (дерево решения, навигация, тактические инструменты). Instrument deck 0063 описывает форму композиции («несколько приборов на одном экране»), но не закрывает какой набор для PFD продуктово оправдан.
Отдельно обсуждалось: ситуационная осведомлённость (SA) — сводки о контексте работы (объём кода, сложность, карта знаний). Часть сигналов уже есть вне PFD (например бейдж LOC / уровень Low·Medium·High в task cockpit; пороги [loc_limits] в workspace.toml). Code metrics через MCP (get_code_metrics) отдаёт JSON по scope — удобно агенту и сценариям, но не отвечает само по себе на вопрос «где это показать пилоту».
Нужен накопительный документ: варианты PFD instrument deck и критерии «здесь / по запросу / не PFD».
1. Инварианты (не обсуждаются в этом ADR как «новая ось»)¶
- Слоты и merge TOML — 0050; дескриптор инструмента — 0047.
- EICAS (W/C/A) и ось LOC (Low/Medium/High по
[loc_limits]) — разные семантики; не смешивать цвета/лейблы без легенды (см. обсуждение в продукте; бейдж LOC — отдельная ось «величина файла»).
1.1. Продуктовый ориентир: Strict и Glass Cockpit¶
Идеал для приборной части PFD: поведение ближе к read-only и строгому контракту в смысле 0037 — компоненты с [PfdStrict] / PfdStrictControl: ограничения по вводу (Input Lock), весу (Weight), каналам данных; без «офисного» тяжёлого интерактива внутри маркированной приборной поверхности.
Визуальный стиль: ориентир glass cockpit — тёмное поле приборов, светящиеся индикаторы, читаемость в боковом зрении; детали примитивов и палитры — 0064. Не смешивать с хромом shell / оверлеями presentation IDE (0066).
Важный нюанс 0037: географическая зона PFD не равна «вся колонка read-only». Навигация (дерево решения, выбор файла, раскрытие узлов) остаётся интерактивной — это контекст «где я», а не приборная строгость. Строгий контракт навешивается на явно помеченные индикаторы/тактические приборы, а не на всё, что нарисовано слева.
1.2. Пример составного индикатора: LOC (черновик)¶
Целевое представление LOC (непустые строки, пороги [loc_limits]) — два канала в одном приборе, по аналогии с реальной авионикой (метафора не смешивается с EICAS W/C/A):
| Канал | Роль | Образ |
|---|---|---|
| Зонированная шкала | Где файл относительно Low / Medium / High | Glide slope (или локальный горизонт): полоса с тремя сегментами, маркер положения (не «курс» в навигационном смысле — в tooltip зафиксировать, что это эвристика по размеру). |
| Число | Точное значение LOC, без потери точности на границах зон | Altimeter: крупный цифровой/барабанный readout рядом или внутри того же виджета — как у приборов: и шкала, и значение. |
Практика: без цифры на границе medium_min / high_min пользователь не видит «насколько» внутри зоны; без шкалы теряется мгновенный скан «зелёный/жёлтый/красный» коридора. Детали примитивов — 0064.
2. Критерии отбора (черновик)¶
| Критерий | Вопрос |
|---|---|
| Скан | Укладывается ли сигнал во взгляд 1–2 с без drill-down? |
| Тактика | Относится ли к текущему файлу/узлу/курсору (vs стратегия всего решения)? |
| Частота | Нужен ли постоянно на PFD или достаточно по команде / на MFD? |
| Паритет | Должен ли человек и агент видеть тот же снимок (0008)? |
3. Каталог вариантов (наполняется)¶
Статусы: идея | кандидат PFD | скорее не PFD | отклонено / отложено.
| # | Элемент | Суть | Черновой вердикт | Заметки |
|---|---|---|---|---|
| A | Solution Explorer / дерево | Навигация по проекту | Уже якорь PFD по умолчанию | — |
| B | Semantic Map (control flow) | Поток управления в методе | Кандидат PFD (0053) | Тактика, курсор |
| C | LOC / размер файла | Непустые строки, уровень L/M/H | Скорее не отдельный прибор PFD v0 — уже бейдж в task cockpit; дубль на PFD только при явной политике «всё SA на левом краю» | [loc_limits]; целевой вид прибора — §1.2: BarWithLevels + маркер (образ glideslope) + число (образ altimeter). |
| D | Code metrics (get_code_metrics) |
LOC, классы, методы, cyclomatic, hot_methods |
Скорее по запросу (палитра, MCP, опционально компактная панель) или MFD для scope=solution; мини-сводка на PFD — только если закрепить «текущий файл only» | Не раздувать PFD полным JSON |
| E | ADR / knowledge indicator | Карта путь → ADR, intent | Кандидат (0061) | SA по документации |
| F | Git / статус | Изменённые файлы | Часто MFD или полоса WH; на PFD — если слот свободен и продукт выберет «git рядом с деревом» | Пересечение с Git в других зонах |
| G | (запасная строка) | — | — | Добавлять новые строки снизу |
Правило редактирования: новые идеи — новая буква или подпункт; не переписывать историю без пометки внизу ADR (дата, что изменилось).
4. Открытые вопросы¶
- Нужен ли единый пресет «PFD = навигация + один тактический прибор» vs «PFD = плотная колода из N ячеек» (0063 § Page + deck)?
- Должен ли code metrics для current file дублироваться визуально на PFD, если MCP уже отдаёт те же числа агенту?
- Граница PFD vs Forward (0021) для мини-индикаторов SA — не съесть ли центральный редактор.
Решение¶
Зафиксировать как Proposed: вести этот ADR как живой каталог вариантов PFD deck и критериев; не считать строку таблицы §3 принятой продуктовой нормой, пока не переведено в отдельное Accepted решение или не реализовано в коде с отсылкой сюда.
Следующий шаг (вне этого файла): по мере зрелости — вынести отдельные строки в UiModes / пресеты / [instrument_routing] (0050) с ссылкой на номер строки §3.
Последствия¶
- Документ может часто меняться (таблица §3); стабильные определения терминов — по-прежнему в 0063 и 0021.
- Реализация конкретного ряда приборов на PFD — отдельные коммиты и при необходимости узкий ADR «как именно» (layout, CDS), не раздувая 0073.
История изменений (кратко)¶
| Дата | Изменение |
|---|---|
| 2026-04-19 | Первичная фиксация: контекст, критерии §2, стартовая таблица §3, открытые вопросы §4. |
| 2026-04-19 | §1.1: ориентир Strict + Glass Cockpit; разводка с полностью read-only колонкой — по 0037. |
| 2026-04-19 | §1.2: LOC — составной индикатор: шкала с зонами + маркер (образ glideslope) и числовой readout (образ altimeter); строка C §3. |