docs(tails): закрыть кросс-док хвосты (a-base/b/dev-env/J/hardware) + наполнить glossary

Закрыты накопленные мелкие хвосты из ревью F/J/H/G: - Stage-нормализация: Stage-0/1/2 → Stage 0/1/2 по 6 докам (a/b/f/h/j/hardware); каноническая запись Stage 0/1/2 в glossary. - a-base §8: видео-пайплайн (DMABUF камер / VPU dashcam) внесён в OOM-порядок — задняя защищена (Stage 1), dashcam/surround throttleable. - a-base §12: dashcam-медиа (отдельный носитель) + контакты/журнал (G) в список factory-reset wipe. - b §12: grace-hold резолвнут ✅ — J запросчик (J §7), B владелец/арбитр (§4 шаг 2, §7). - dev-environment: моки fake-камера (J)/аудио (H)/BT-телефон (G) + plugin-host-харнесс; just-цели plugin-dev-run/sideload. - J §3/§11/§13 + hardware §4: сигнал реверса ✅ GPIO фонаря з.х. (выбранный дефолт); CAN-gear отложен (нет gear-сигнала в E). - glossary.md: наполнен (~55 терминов в 7 областях: машина/CAN, платформа/IPC, ассистент/аудио, питание/boot, хранилище/OTA, связь/телефон, безопасность). Tier-3 capability-catalog + roadmap не трогаются — зависят от доменов I+L. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-23 12:46:36 +03:00
parent fb4e585152
commit 3fd9b42bb0
8 changed files with 132 additions and 43 deletions
@@ -132,14 +132,16 @@

 ## 8. Память (zram / OOM)

-Локальная квантованная LLM (llama.cpp) + smithay + PipeWire + ONNX STT/TTS + Vehicle-Data
-на 8–16 ГБ — реальное давление на память. Базовая политика:
+Локальная квантованная LLM (llama.cpp) + smithay + PipeWire + ONNX STT/TTS + Vehicle-Data +
+**видео-пайплайн** (DMABUF камер / VPU-кодирование dashcam, J §9) на 8–16 ГБ — реальное давление
+на память. Базовая политика:

 - **zram** (сжатый swap в RAM, lz4/zstd) — основной запас; даёт RAM без записи во
  flash (служит и цели §10-износа).
 - **Swap-на-flash (eMMC/SD) — запрещён** (убивает flash, нарушает §10).
 - **OOM-политика:** `systemd-oomd`/earlyoom — защищаем kernel/Power/Shell/Perm-Broker
-  (Stage-1 critical set), первыми жертвами делаем офлайн-LLM и фоновые апы.
+  (Stage 1 critical set) **+ низколатентную заднюю камеру** (J §9); первыми жертвами — офлайн-LLM,
+  фоновые апы, **throttleable dashcam/surround** (J §9 — деградируют видимо, не stall).
 - **cgroup `MemoryMax/MemoryHigh`** на App-Host и тяжёлые апы. 8 ГБ — впритык, 16 ГБ —
  целевой для одновременной локальной LLM (см. выбор модели — d-assistant).

@@ -175,7 +177,8 @@
 ## 12. Factory reset (сброс к заводским)

 Атомарная очистка/реинициализация **только `/data`** (wipe поддеревьев apps-storage,
-память водителя `.md`, токены, Settings; RO base-образ/BSP/device-identity сохраняются).
+память водителя `.md`, **контакты/журнал (G, в apps-storage)**, токены, Settings, **dashcam-медиа
+(J §4 — на отдельном носителе/разделе)**; RO base-образ/BSP/device-identity сохраняются).
 Зачем: продажа/передача авто (стереть ПДн — security-privacy §7), recovery после порчи
 конфигурации, UX-выход из неработоспособности. Из recovery-режима + подтверждение
 (защита от случайного). Отличать от `Settings.Reset(key)` (один ключ). При шифровании
@@ -208,7 +211,7 @@ reference-таргет — first-party**, остальное — порты.
 | systemd-таргеты/оркестрация | **MVP** | — | v0 |
 | Board-support: один reference-BSP | **MVP** | hardware HAL | v0 |
 | Локаль базы (ru_RU.UTF-8, tzdata, кириллич. шрифты, keymap) | **MVP** | — | v0 |
-| Stage-0 boot-инфра раннего пути задней камеры | later | architecture §6, J/B | v2 |
+| Stage 0 boot-инфра раннего пути задней камеры | later | architecture §6, J/B | v2 |
 | OTA (RAUC A/B incl ядро/dtb, signed, bootcount+mark-good, rollback) | later | — | v4 |
 | Secure boot (verified boot, OTP-eFuse, key-mgmt) | later | hardware | v4 |
 | At-rest шифрование `/data` (fscrypt, eFuse-bound) | later | secure boot | v4 |
@@ -137,7 +137,7 @@ power-эффектом; ни одно SoC-сообщение не должно (
 ## 7. Sleep / wake и защита АКБ

 - **Низкопотребление** при заглушённом двигателе (быстрый/scheduled wake).
- **Источники пробуждения:** ACC-on, таймер, **реверс-передача** (Stage-0 камера, §4/J), опц. CAN-wakeup.
+- **Источники пробуждения:** ACC-on, таймер, **реверс-передача** (Stage 0 камера, §4/J), опц. CAN-wakeup.
 - **`battery-cutoff` (отдельно от ACC-off):** при долгой стоянке порог напряжения (раньше/выше
  operating-brown-out hardware §3 — зарезервировать энергию на запуск) → sleep → forced off;
  гистерезис на wake-on-ACC. Бюджет разряда — §12 (с hardware).
@@ -183,7 +183,7 @@ power-эффектом; ни одно SoC-сообщение не должно (
 | MCU прошивка: update path | later | hardware | v1 |
 | Sleep/wake + battery-cutoff | later | — | v1/v2 |
 | Гейт wake-word по состояниям (с D) | **MVP** | D | v1 |
-| Реверс-wake (Stage-0 камера) · scheduled/CAN-wake | later | hardware §4, J | v2/later |
+| Реверс-wake (Stage 0 камера) · scheduled/CAN-wake | later | hardware §4, J | v2/later |

 ## 11. Зависимости

@@ -199,7 +199,8 @@ power-эффектом; ни одно SoC-сообщение не должно (
  shutdown-подмножество уже специфицировано в §4/§5, остальное здесь.
 - ◻️ **Бюджет разряда АКБ** (sleep, ACC-off listening, battery-cutoff порог) — числа с hardware.
 - ◻️ **Тепловые пороги** (critical-trip + recovery-hysteresis) — согласовать с a-base §10 + hardware §1a.
- ◻️ **Удержание дисплей/камера-рейла после ACC-off** — кто арбитрит grace-hold (B состояние, C/J запрос); с реверс-камерой Stage 0.
+- ✅ **Удержание дисплей/камера-рейла после ACC-off (grace-hold):** **J — запросчик** (J §7), **B —
+  владелец/арбитр** (§4 шаг 2 grace-окно, §7) — ограничивает hold-up-бюджетом, не переопределяет PONR. С реверс-камерой Stage 0.

 ---

@@ -38,7 +38,7 @@

 App-Host из манифеста на activate ставит **cgroup-лимиты** (`MemoryMax`/`MemoryHigh`, `CPUQuota`, `pids.max`):
 дефолтный потолок + опц. больший в манифесте (виден в ревью — как дисковая квота plugin-sdk §4.4).
-В OOM-иерархии (a-base §8) сторонний плагин — **низкий приоритет** (ниже Stage-1-ядра и офлайн-LLM):
+В OOM-иерархии (a-base §8) сторонний плагин — **низкий приоритет** (ниже Stage 1-ядра и офлайн-LLM):
 убивается раньше killer-фичи → `AppCrashed` → деградация (#4). CPU-троттлинг — чтобы busy-loop не съел UI (#11).

 ## 3. Валидация манифеста (целостность — только с подписью)
@@ -153,7 +153,7 @@ capture-нода не «дакает» вывод; дакает медиа им
 - **Boot аудио-плоскости:** PipeWire+WirePlumber и статическая лестница ролей (§3) поднимаются на **Stage 1**
  (раньше Media-апа; сам Media — Stage 2, architecture §6), чтобы маршрутизация/политика были доступны до
  прогрева плеера. **До Stage 1 звука нет** (как голоса нет в boot-окне, D §8). Роль `alert` доступна с
-  поднятия WirePlumber (Stage 1); **ранний park-beep на Stage-0-реверсе** (до аудио-плоскости) — за её
+  поднятия WirePlumber (Stage 1); **ранний park-beep на Stage 0-реверсе** (до аудио-плоскости) — за её
  пределами, потребует отдельного раннего звукового пути (◻️ §15 → J/E/B; park-beep informational, #1).
 - **`ShutdownImminent`/ACC-off (ipc §3, B §4):** остановить воспроизведение, **mute amp до PONR** (порядок —
  B §4, §8), сохранить now-playing (источник/трек/позиция/очередь) в Settings.
@@ -228,7 +228,7 @@ capture-нода не «дакает» вывод; дакает медиа им
 - 🟡 **enable/mute-секвенс усилителя (anti-pop):** owner GPIO — hardware §4 (mute-GPIO), owner порядка — B §4. → hardware + B.
 - ✅ **AEC** — узел audio-plane (`module-echo-cancel`/WebRTC APM), референс = output-monitor, не в ассистенте;
  loopback-tap — §4. → резолв §4 (синхронизировано в d-assistant §10).
- ◻️ **Ранний звук на Stage-0-реверсе** (park-beep до поднятия аудио-плоскости) — нужен ли отдельный путь. → J/E/B.
+- ◻️ **Ранний звук на Stage 0-реверсе** (park-beep до поднятия аудио-плоскости) — нужен ли отдельный путь. → J/E/B.
 - ◻️ **Split политики:** сколько в статическом WirePlumber vs Rust-координаторе (+ crash-safety проактивного
  cork, тайминги гистерезиса/фейда дакинга). → реализация.
 - ◻️ **Явный focus-request API** (D-Bus) vs только неявные роли. → реализация/ipc §4.
@@ -29,9 +29,9 @@
    кадра** (Shell поднимает overlay-слот с live-видом, затем ранний клиент отпускает master). Boot-инфра — A §4.
  - **Риск (открытый):** ранний кадр до проверки подписи initramfs подрывает trust-chain, после — бьёт TTFF —
    развести minimal-trust (до) vs полный вид (после), с a-base §4.
- **Сигнал реверса:** **GPIO фонаря з.х. — рекомендуемый дефолт** (надёжнее/быстрее/Stage-0-совместим). Владелец —
+- **Сигнал реверса:** **GPIO фонаря з.х. — рекомендуемый дефолт** (надёжнее/быстрее/Stage 0-совместим). Владелец —
  **`Power` (B §7)**, J **потребляет**; CAN-gear как альтернатива требует **нового gear-сигнала в data-model/E**
-  (его сейчас нет — ветка нереализуема без этого; gear может быть не на OBD-порту, E §7). 🟡 выбрать (§10).
+  (его сейчас нет — ветка нереализуема без этого; gear может быть не на OBD-порту, E §7). ✅ **выбрано: GPIO** (§13).
 - **Парктроник-оверлей:** дистанция из E (CAN) или K (не-CAN); на `stale`/`unavailable` (E §5b) — **скрыть/пометить**
  оверлей, не рисовать last-known.
 - **Fail-safe «нет сигнала»:** per-frame timestamp + **frame-watchdog** (нет кадра N мс / потеря sync → `no_signal`);
@@ -59,7 +59,7 @@
 ## 6. Виды в shell

 - Камера-виды (steady-state, после Stage 1) — **Wayland-поверхности** в слотах shell (C §4, slot-протокол).
-  Задняя/парктроник — приоритетный/оверлейный слот (может поверх раннего Stage-0-кадра).
+  Задняя/парктроник — приоритетный/оверлейный слот (может поверх раннего Stage 0-кадра).

 ## 7. Камера и lifecycle (шов с B/E/A)

@@ -82,7 +82,7 @@

 - **Кодирование dashcam — на аппаратном VPU RK3588** (rkmpp/V4L2-M2M), не CPU (H.264/H.265). 🟡 кодек/VPU.
 - **DMABUF zero-copy** capture→encode/composite (N источников × буферы — главный член RAM).
- Внести видео-пайплайн в **a-base §8** (давление памяти + OOM-порядок: задняя — защищена у Stage-1; dashcam/surround — throttleable).
+- Внести видео-пайплайн в **a-base §8** (давление памяти + OOM-порядок: задняя — защищена у Stage 1; dashcam/surround — throttleable).
 - GPU-контеншн: surround уступает UI (#11); деградация при throttling (a-base §10) — видимая, не stall.

 ## 10. Функции
@@ -102,18 +102,18 @@
 ## 11. Dev-симулятор камер (#13)

 Fake V4L2/PipeWire-источник: тест-паттерн / реплей файла / **no-signal** (для fail-safe §3); эмуляция реверса
-**обоих путей** (GPIO-стаб И CAN-gear через vcan — выбор не сделан); Stage-0-мок (замер TTFF); отказ capture-чипа/потеря источника.
+**обоих путей** (GPIO-стаб — дефолтный путь; CAN-gear через vcan — для будущей ветки); Stage 0-мок (замер TTFF); отказ capture-чипа/потеря источника.
 Поверх существующих PipeWire/vcan/weston (dev-environment). Сценарий «реверс→камера» (e2e) — отсюда.

 ## 12. Зависимости

- **Вниз:** hardware (§4 capture/реверс/камеры; §1a тепло), A (§4 Stage-0 boot-инфра, §3 fscrypt/atomic, §8 память, §10/§12).
+- **Вниз:** hardware (§4 capture/реверс/камеры; §1a тепло), A (§4 Stage 0 boot-инфра, §3 fscrypt/atomic, §8 память, §10/§12).
 - **Вбок:** B (§7 питание/реверс-wake, §4 ShutdownImminent/grace-hold, §12), E/K (парктроник, stale), K (IMU/GPS dashcam), C (слоты/slot-протокол).
 - **Вверх:** виды камер для UI (C); расширяемо плагинами (`camera_in`).

 ## 13. Открытые вопросы

- 🟡 **Сигнал реверса** GPIO (рек.) vs CAN gear — выбрать; CAN требует gear-сигнал в data-model/E.
+- ✅ **Сигнал реверса** — **GPIO** фонаря з.х. (выбранный дефолт; §3, Журнал); CAN-gear отложен (требует gear-сигнал в data-model/E, которого нет).
 - 🟡 **DRM-master handoff** Stage 0→Stage 1 (без чёрного кадра) + trust до/после проверки initramfs — с A §4/B.
 - 🟡 **Кодек/VPU** dashcam (H.264/H.265, rkmpp) — выбрать.
 - ◻️ **Носитель dashcam** (раздел/карта; износ; retention) — с A/hardware.