docs(rover): record calibration control acceptance and operating boundaries

2026-09-25 16:39:19 +03:00
parent bc55901d4d
commit 6bbbd5bf7d
12 changed files with 4603 additions and 0 deletions
@@ -353,3 +353,17 @@ Before A3 or any subsequent LAB UI change:
 7. visually inspect normal and expanded modes at representative viewport sizes.
 8. verify every bounded `ENNResult.tsx` uses the v1 summary and result
   components without raw canonical report markup.
 ## Hardware synchronization feedback — owner requirement, 2026-09-25
 When an operator action must wait for equipment synchronization, preparation
 or completion of a previous operation, show its current phase next to the
 action using canonical status components. Do not silently disable the entry
 point or present an unexplained frozen control. Keep settings accessible;
 gate the actual hardware action on readiness and explain the reason.
 A busy phase uses the canonical warning status; confirmed readiness alone
 uses success. Missing/stale data or failure must say so, never imply endless
 active synchronization. Status follows real lifecycle responses, not a timer
 that pretends completion. This is an application-wide interaction requirement;
 other equipment workflows need their own lifecycle verification.
@@ -0,0 +1,331 @@
 # Rover 006 — VESC: аудит кода и план реализации
 Исторический план, составленный до реализации 23 сентября 2026. Текущий статус
 см. `../node/17_VESC_INSTALLATION_LEDGER.md` и MISSIONCOR-84.
 Результат первоначального аудита — исследование, свежий read-only
 baseline и план. Плагин ещё не реализован; конфиги контроллеров не прочитаны,
 моторы не запускались. Исторические команды и планы приложенного документа
 рассматривались как источники, а не как поручения на исполнение.
 ## 1. Целевой пользовательский результат
 После подключения контроллеров к USB бортового Mac Mini они появляются в
 «Устройствах» Node и в «Парк → Rover 006 → Устройства» основного Core.
 В карточке выбранного контроллера есть вход **«VESC Tool»**. Через него доступны
 настройка, диагностика, калибровка и остальные применимые функции Tool.
 Исполнение принадлежит борту; обе UI используют одну реализацию предметного
 интерфейса и одни операции. Полнота Tool остаётся целевым требованием,
 первый read-only выпуск является отдельным промежуточным результатом.
 Ближайшая физическая задача — разобраться с потерей оборотов одного мотора.
 Слова владельца о левом канале остаются предположением до сопоставления.
 Предыдущие наблюдения: плавный старт возможен, резкий может давать короткий
 рывок и остановку; конфигурация, датчики и управление — приоритетная ветка
 диагностики. Причина пока не измерена.
 ## 2. Что проверено сейчас
 | Объект | Факт 23.09 | Ограничение |
 | --- | --- | --- |
 | Core | Канонический localhost:8000 отвечает; Rover 006 paired/online | Не означает доступность каждого устройства |
 | SSH | Вход `dcsudo` с существующим персональным ключом работает | Старая запись `nodedc-edge` использовала `ndcsudo`; sudo не проверялся и не нужен для чтения |
 | Борт | Ubuntu 24.04.4, kernel 7.0.0-31-generic, i7-3615QM, 4 ядра/8 потоков | CPU поддерживает AVX, но AVX2 в полученном наборе флагов нет |
 | Память/диск | Около 8 GB RAM, около 6.3 GiB available; swap не занят; root 457 GiB, свободно 381 GiB | Это короткий idle-срез, не совместная нагрузочная приёмка |
 | Установка | Node 0.8.21-3, K1 0.1.14, X4 0.1.3-9 | Старый Node README с 0.6.11 не является installed baseline |
 | Службы | Node, K1, X4 broker, D455, monitor, PostgreSQL active/running, NRestarts=0 в проверенном наборе | Активный драйвер не доказывает подключение камеры |
 | База | PostgreSQL 16, cluster `ndcmonitor` online; Timescale 2.29.2 установлен | База системного мониторинга, не готовый motor recorder |
 | Реплика мониторинга | available/fresh=true, storage=ready, backlog=0; sample interval 1 s | Срез около 11:02 UTC; полевая задержка управления не измерена |
 | USB контроллеров | Два кандидата `0483:5740`, ChibiOS/RT Virtual COM Port, cdc_acm, два ttyACM | USB-дескриптор ещё не доказательство HW/FW VESC |
 | Identity | У двух кандидатов одинаковый USB serial; одна конфликтующая by-id ссылка | Нельзя использовать USB serial, by-id, tty или порядок включения как постоянную личность |
 | Права | tty принадлежат root:dialout, 0660; dcsudo не имеет read/write | Права будущего runtime поставляются профилем модели |
 | Конкурирующий опрос | ModemManager active; кандидаты имеют ID_MM_CANDIDATE=1 | Не доказано, что он уже посылал команды; нужен адресный udev ignore при подготовке модели |
 | Камеры | D455/X4 в свежем paired inventory offline | Сохранность их потоков под VESC-нагрузкой сейчас проверить нельзя |
 Портов serial не открывали; firmware/UUID, моторные и application configs,
 CAN/RC topology и физические стороны остаются неизвестными. VESC Tool не найден
 через проверенное имя `vesc_tool` в PATH; это не полный поиск всех установок.
 Подробный путь доступа: [ROVER_006_ENGINEERING_ACCESS.md](../runbooks/ROVER_006_ENGINEERING_ACCESS.md).
 Raw fleet/monitor snapshots и приватный SSH-профиль находятся вне Git в
 операторском `outputs/rover-006-vesc-context-20260923`.
 ## 3. Источники и границы исследования
 Прочитаны основной актуальный срез и VESC-handoff приложенного документа,
 профильные Node/SDK/UI материалы и релевантная история приложений. Большой
 архив планировщика/Rerun использован для контекста владельцев; повторной
 квалификации всех старых экспериментов не выполнялось.
 Через прямой Ops MCP получены живые проекты/контекст/карточки, в том числе
 MISSIONCOR-84, 76, 77, 50, 5, 2, и история комментариев 76/77/84; изучен
 архив ROBOT2B-5. Профильная карта —
 [MISSIONCOR-84](https://ops.nodedc.ru/nodedc/browse/MISSIONCOR-84), Node —
 [MISSIONCOR-76](https://ops.nodedc.ru/nodedc/browse/MISSIONCOR-76).
 Поиск GPIO в других четырёх доступных Ops-проектах совпадений не вернул;
 среди полученных Mission Core/ROBOT2B карточек подтверждённой схемы GPIO
 для этого привода не найдено. Это пробел найденных источников, не утверждение
 об отсутствии такой схемы вообще. USB достаточно для первого этапа;
 GPIO/UART/RC/аварийная цепь требуют конкретной аппаратной схемы до motor tests.
 Основная кодовая база: `NODEDC_MISSION_CORE_m5_observatory`, HEAD `2e5d525`.
 Соседние base/node checkout остаются detached `76dc9f1`. В main есть чужая
 незавершённая работа SIM/AI polygon и service recovery. Для реализации нужен
 отдельный checkout от проверенного commit; не включать эти изменения в пакет.
 Design Guideline прочитан по реестрам и документации, текущий HEAD
 `8dd9190573d6616024ef01b9b34bf90b72960f44`, рабочее дерево чистое в проверке.
 Node build_linux_source.py закреплён на `8c53f73...` и отклоняет другой HEAD.
 Перед выпуском выбрать проверенную ревизию DG и квалифицировать её в сборке;
 не снимать проверку и не брать случайные локальные dist.
 ## 4. Реальные точки расширения
 | Код | Что уже есть | Что нужно VESC |
 | --- | --- | --- |
 | `apps/node-agent/internal/node/sensor_models.go` | Registry, model actions, отдельные IPC sockets, USB discovery, provisional identity при дублях | Новый model profile; разделение attachment и protocol UUID; discovery двух плат с одинаковым USB serial |
 | `sensors.go` | Durable fsync journal, dedup, action allowlist, deadline, unknown после restart, local API | Точные VESC actions и параметры; проверка session непосредственно в адаптере; bounded результаты; не прятать моторные функции за camera `start`/`option` |
 | `sensor_preparation.go` | Профиль на модель и проверка отдельного экземпляра, shared preparation job | Device-neutral подписи и безопасная identity verification. Нельзя трактовать `verify` как motor detection |
 | `sensor_events.go` | udev events, coalescing, полные SSE snapshots | Reconnect создаёт новый session; stale GUI не получает authority над новым контроллером |
 | `pairing_transport.go` | mTLS heartbeat, commands/results/acks; периодический tick 5 s и пробуждение от событий | Существующий путь для service operations; отдельная доставка частой telemetry и будущего realtime control |
 | `src/k1link/fleet/sensors.py` | Проверки pairing/freshness/session, очередь, receipts, ограниченные payloads | Добавить явные actions; не превращать whitelist в arbitrary protocol passthrough |
 | `packages/plugin-sdk/.../v0alpha2` | Identity/session, safety/idempotency policies, commands/events | Использовать существующие contracts; motor authority/lease и конфиг revision оформить узким дополнением |
 | `packages/sensor-ui` | Общий SensorWorkspace, transport, Detail contribution, status/preparation | VESC Detail в том же slot; camera-specific поля/подписи нормализовать ровно там, где нужно |
 | `apps/node-agent/ui/src/NodeSensors.tsx` | Локальная композиция общих plugins | Зарегистрировать ту же VESC contribution |
 | `apps/control-station/src/core/fleet/sensorTransport.ts` и composition | Remote adapter общего UI | Повторно использовать; новая предметная логика в plugin, не App.tsx |
 | `plugins/insta360-x4/runtime/operations.py` | fsync receipt до физического действия, отсутствие replay, readback settings | Проверенный пример lifecycle, но motor safety проектируется отдельно |
 | Node monitor/storage и fleet monitor replica | 1 s host samples → Timescale → bounded Core replica | Не использовать этот период как осциллограф или контур stop; моторная сессия пишет данные на борту с собственной частотой |
 В этих действующих реестрах и каталогах VESC runtime отсутствует. Архитектурные
 документы старого этапа местами описывают gRPC как целевой вариант; текущая
 проверенная реализация использует JSON HTTP/Unix sockets и HTTPS heartbeat.
 ## 5. Интеграция VESC Tool
 Для аудита закреплён официальный upstream:
 [`dc53c658cbb89a947246034f7a00149cf79abdfc`](https://github.com/vedderb/vesc_tool/tree/dc53c658cbb89a947246034f7a00149cf79abdfc).
 Сохранены 17 исходных файлов с SHA-256. Этот snapshot объявляет **7.01,
 test version 1**; это исследовательская точка, не автоматически выбранный
 production release для неизвестной firmware наших плат.
 Исходники показывают:
 - `main.cpp`: CLI умеет конкретные чтения/записи config, выбор port/CAN,
  offscreen и TCP. Это не готовый полный web API.
 - `vescinterface.cpp`: autoconnect обходит serial ports и заканчивает поиск
  на первом ответе. Для инвентаризации двух плат нужен наш ограниченный поиск.
 - `commands.cpp`/`datatypes.h`: FW response содержит version, HW name, UUID
  и дополнительные признаки; набор полей зависит от ответа. HW name нельзя
  автоматически считать точной коммерческой моделью платы.
 - `configparams.cpp`/`utility.cpp`: schema выбирается по firmware, сериализация
  использует signature. Парсить конфиг произвольной новой firmware старой
  схемой и затем сохранять его нельзя.
 - `packet.cpp`: length/framing/CRC и размер пакета ограничены. Нужны tests на
  fragmented/combined/corrupt packets и truncation полей ответа.
 - `tcpserversimple.h`: default bind — все адреса. Штатный TCP server нельзя
  просто включить как удалённый продуктовый интерфейс.
 - `setupwizardmotor.cpp`: wizard содержит реальные записи конфигурации по
  ходу шагов. Его запуск/отмена не являются только локальным редактированием.
 ### Сравнение реализаций
 | Вариант | Польза | Цена/ограничение |
 | --- | --- | --- |
 | Официальный Qt Tool + локальный launcher и трансляция его окна в Core | Самый прямой путь к исходному GUI и широкому набору функций | Новый remote-app runtime, конкуренция ввода двух UI, Qt UI вне DG, передача port ownership; интерфейс сам умеет опасные команды |
 | Собственный минимальный protocol adapter | Быстрое read-only discovery/telemetry | Поддержка всех конфигов/wizards потребует дублирования большого firmware-specific слоя |
 | Бортовой service plugin с переиспользованием закреплённого upstream protocol/config engine + общий React UI | Наш UI, один owner, применимые функции Tool расширяются без второй модели состояния | Требуется проверить headless сборку/зависимости и адаптировать операции; полного готового API нет |
 **Рекомендация:** третий вариант как целевая архитектура. Первый технический
 spike проверяет сборку и выделение engine без desktop UI; fallback на
 ограниченный собственный reader допустим для первого чтения, но не отменяет
 требование функционального паритета. Оригинальный Tool полезен как инструмент
 сравнения с эксклюзивной передачей владения портом. В текущем плане нельзя
 объявить «все функции готовы», открыв только несколько полей или удалённое окно.
 Нужно отдельно различать паритет функций и показ неизменённого Qt GUI. Здесь
 принято рабочее предположение из запроса про наш интерфейс и DG: единая
 предметная UI внутри Mission Core. Если нужен именно исходный Qt GUI, меняется
 способ его доставки, а не требование единственного hardware owner.
 Upstream содержит GPL-3.0-or-later notices и отдельные правила бренда. При
 упаковке выбранного кода/бинарника проверить состав, notices, исходники и
 название распространяемого продукта. Этот аудит не делает юридического вывода
 о допустимости конкретного способа распространения.
 ## 6. Runtime и модель данных
 ```mermaid
 flowchart TD
  L[Node UI: Устройства → VESC Tool] --> N[Node API и журнал операций]
  R[Core: Парк → Rover 006 → VESC Tool] --> C[Core fleet API]
  C -->|Существующее pairing и mTLS| N
  N --> V[VESC plugin на борту: owner и арбитраж]
  V --> U[USB attachment → protocol UUID → controller/channel]
  U --> M[Мотор и подтверждённая роль]
  V --> D[Конфиги, telemetry и diagnostic session на борту]
  D --> C
 ```
 Предлагаемый bounded каталог `plugins/vesc/`: `runtime/`, `frontend/`,
 `profiles/`, `packaging/`, `tests/`, upstream lock/notice manifest.
 Названия здесь — план, каталог ещё не создан.
 Один service владеет serial. Открывает только подтверждённые candidates;
 проверяет отсутствие конкурирующего владельца и сохраняет связь порта с
 attachment generation. До FW query attachment имеет provisional identity.
 После ответа UUID связывается со стабильным controller instance. Смена порта
 не меняет подтверждённый UUID; USB/CAN aliases одной платы не создают двойник.
 Неоднозначный protocol UUID оставляет устройство без write authority.
 Особенно важно для текущих двух плат: общий Node discovery уже считает
 duplicate USB serial неинициализируемым. Нельзя просто добавить VID/PID:
 обе кнопки подготовки окажутся заблокированы. Нужен отдельный безопасный путь
 подготовки модели/identity query для provisional attachments; он разрешает
 только ограниченное чтение личности. Общую защиту камер не ослаблять.
 Role Left/Right и metadata мотора хранятся отдельно от UUID. Отключение владельцем
 одного USB при обесточенном приводе может сопоставить плату с кабелем; это само
 по себе не доказывает, какой мотор подключён к её силовым выходам. Сопоставление
 по проводке/маркировке предпочтительно; активный тест — отдельная операция.
 Конфиг имеет исходный blob, decoded fields, firmware/schema signature, hash,
 revision и timestamp. Запись использует ожидаемую revision и свежий session,
 сохраняет before/after, выполняет readback. Потеря ACK даёт unknown и
 reconciliation, а не слепой retry.
 Калибровка — бортовая операция с этапами, результатом и явно проверенной
 семантикой отмены. HTTP timeout не доказывает прекращение электрического
 измерения. Motor control дополнительно требует одного владельца управления,
 локального watchdog, известных timeout/stop свойств firmware и арбитража RC.
 Точные токи/обороты/частота не выбираются до hardware baseline.
 ## 7. Полнота функций и порядок включения
 | Группа Tool | Предметный результат | Этап и условие |
 | --- | --- | --- |
 | Discovery, FW/HW/UUID, USB/CAN topology | Независимые экземпляры и совместимость | Первый read-only slice |
 | Live values, faults, decoded PPM/ADC/Chuk input | Напряжение, токи, ERPM, температура, вход, timeout/kill flags по поддержке FW | Первый read-only slice; измерить реальную частоту |
 | Motor/app/custom configs, backup/export, сравнение | Полный применимый набор параметров по schema, неизменяемый backup | Read-only до первой записи |
 | Import, defaults, apply/restore | Предпросмотр diff и проверенный readback | После identity, backup и compatibility; restore/defaults — записи |
 | FOC/BLDC/DC setup, R/L/flux, Hall/encoder | Калибровочный workflow с результатом | Активный допуск на конкретный мотор; один шаг может подавать ток |
 | App/input setup, direction, limits | Настройка RC/ADC/UART/CAN по реальной схеме | Сначала прочитать существующий input/timeout/RC ownership |
 | Duty/current/brake/RPM/position, motor tests | Управляемый стендовый опыт | Быстрый бортовой контур; не heartbeat 5 s |
 | Samples, logging, plotting | Синхронная диагностическая запись реакции | Bounded board recorder; сводки через Core |
 | Firmware/bootloader/recovery | Exact-HW image, версия, progress и recovery | Отдельная поздняя ветка; не «обновить на всякий случай» |
 | CAN forwarding/multi-controller setup | Явный target и topology | Никаких автоматических detect-all/broadcast writes |
 | Terminal, Lisp/QML/packages, custom application | Сервисные функции выбранного устройства | Отдельный maintenance scope; чтение кода и его выполнение различаются |
 | BMS, IMU, power switch, NRF/GPD и расширения | Применимые к конкретному hardware возможности | Capability-driven; отсутствие аппаратуры не маскировать как готовую функцию |
 Перед реализацией широкой сервисной поверхности матрица уточняется по страницам
 выбранного релиза Tool и реальной HW/FW. Для каждого пункта фиксируются:
 supported/unsupported/not-implemented, операция, side effects, schema,
 readback, cancel/recovery и аппаратная приёмка. Старые настройки firmware
 не переименовываются в поддержанные только ради единого красивого UI.
 ## 8. UI brief и Design Guideline
 Задача оператора: выбрать конкретный контроллер, понять состояние, настроить
 его и проверить итог. Первичная сущность — выбранный controller/channel;
 мотор и роль — связанный контекст. Вход из существующего списка устройств.
 Выбран **plugin Detail slot** общего `SensorWorkspace`, с текстовой кнопкой
 «VESC Tool» в карточке. Внутри — обзор/диагностика, параметры и сервисные
 операции, основанные на capabilities. Нового root или LAB не требуется.
 Длинный motor workflow остаётся полноценным detail-view; компактный editor
 может использовать существующий `FeatureSettingsWindow`.
 Альтернатива отдельного глобального workspace создаёт второй вход к тем же
 устройствам и отрывает инструмент от адресной identity. Модальное окно на весь
 долгий workflow неудобно для контроля результата и закрытия/recovery.
 Показ исходного Qt GUI — иной вариант интеграции, описанный выше.
 Уже есть `ResourceRow/List`, `Button/IconButton`, `StatusBadge`,
 `SettingsCard`, `Window`, `FeatureSettingsWindow`, `SegmentedControl`,
 `TextField`, `Select`, `RangeControl`, `ConfirmationModal`, `ProgressBar`,
 `LoadingRegion`, `ToastStack`. Подходящие существующие icons: settings,
 activity, network, download, upload, refresh, alert, eye, play/stop.
 Отдельной motor-icon в просмотренном registry нет; новая не нужна для первого
 slice. Domain graph/plot остаётся кодом плагина с этими controls.
 `RangeControl.min/max` ограничивает drag, но не всякий ручной ввод: для токов
 и других bounded величин нужны `exactValueBounds` и серверная валидация.
 Safety check нельзя делегировать только форме.
 Состояния: поиск; не обнаружено; найден кандидат; требуется подготовка;
 чтение личности; unsupported/ambiguous; готов к чтению; fault; занят;
 операция выполняется; outcome unknown; связь потеряна. Свежесть контроллера
 проверяется отдельно от online борта. Браузер не принимает unknown за failed
 и не предлагает повтор опасного действия как универсальное восстановление.
 Это новое доменное содержимое существующей принятой list/detail композиции.
 Изменения global navigation и новые общие визуальные сущности не предлагаются.
 ## 9. Упаковка с первого бортового опыта
 Versioned пакет/profile устанавливает бинарник, pinned зависимости, отдельного
 непривилегированного service user, Unix socket для Node, systemd limits,
 узкие udev rules доступа и ModemManager ignore для квалифицированного профиля.
 Не добавлять весь Node или пользователя в общий dialout, не делать chmod 666,
 не отключать ModemManager глобально. Runtime не должен читать произвольные tty.
 Node сохраняет `PrivateDevices=yes`; аппаратные права принадлежат отдельному
 адаптеру. Verify после установки означает protocol identity/read capability,
 а не автокалибровку. Package qualification: повторная установка, конфликт
 портов, rollback бинарника при сохранении data/backup, холодный старт и чистая
 Ubuntu. Компилятор/Qt dev packages не становятся скрытым требованием runtime.
 ## 10. Реализация по проверяемым результатам
 1. **Контракт и build spike.** Изолированный checkout, выбранный upstream
   release/commit, DG pin, headless engine build, firmware schema closure;
   synthetic packets, IPC/action contracts. Никакого доступа к моторам.
 2. **Discovery на борту и две UI.** Поставляемый profile, два кандидата с
   одинаковым USB serial, FW/UUID handshake, session transitions, одна
   VESC contribution в Node/Core. Итог — оба контроллера видны независимо.
 3. **Read-only сервисная поверхность.** Версии/capabilities, telemetry,
   faults/input, motor/app/custom backups и semantic diff. Это первый полезный
   завершённый выпуск; статусы неподдержанной FW честные.
 4. **Диагностика проблемного канала.** Сначала сравнить конфиги, затем на
   подготовленном стенде записать плавный/резкий старт по конкретному сценарию.
   Сопоставить command/input, ERPM, currents, voltage, fault и timeout. Выбрать
   измеренную гипотезу; рабочий конфиг не копировать целиком.
 5. **Адресная настройка/калибровка.** Backup, effect preview, необходимые
   ограничения hardware, исключение конкурирующего управления, конкретная
   операция, cancel/recovery, readback и повтор исходного теста.
 6. **Остальная матрица Tool.** Дополнять функции вместе с соответствующей
   упаковкой и аппаратными критериями; FW/terminal/scripts выделены по эффекту.
 До физического теста требуются аппаратные факты о моторах/датчиках/питании,
 проводке RC/CAN и доступном аварийном останове. Выбор «левый/правый» владельцем
 выполняется позже; он не блокирует initial inventory.
 ## 11. Приёмка и тесты
 - Parser: CRC, partial/multiple packets, неверные длины/концы, timeout,
  несовместимая FW/config signature, отсутствующие optional fields.
 - Identity: одинаковые USB serial, пустой/дублированный UUID, два независимых
  контроллера, unplug/replug/reorder, замена платы, USB/CAN duplicate alias.
 - Operations: общий local/remote journal, stale session, conflict/lease,
  crash до/после dispatch, unknown outcome, readback mismatch, отсутствие
  повторного исполнения после reconnect и reboot.
 - Packaging: clean Ubuntu, narrow permissions, targeted ModemManager rule,
  занятый port, idempotency/rollback, pinned binaries/firmware schemas/DG.
 - UI: обе поверхности на одном экземпляре, одинаковые capabilities/results,
  empty/offline/fault/unknown, сохранение draft, keyboard/Escape/expand, без
  новых local controls или моторной логики в App.tsx.
 - Hardware: версии и backup обеих плат; измеренный fault/поведение;
  отдельная проверка stop/timeout на стенде до ручного управления.
 - Совместная работа: вернуть реальные D455/X4/K1 в согласованный сценарий и
  измерить ресурсы/USB/latency вместе с VESC. Их текущий offline не считается
  успешной regression-проверкой.
 Проверки кода выполнять последовательно с учётом памяти операторского Mac.
 Текущая задача не меняла runtime-код, поэтому тесты/сборки приложения не
 запускались. HTTP/SSH/API чтения и анализ исходников не являются калибровкой.
 ## 12. Следующее конкретное действие
 Реализовать и упаковать **двухэкземплярное VESC discovery + read-only identity,
 config backup и общую detail-поверхность**. Первый бортовой запуск обязан
 учесть уже обнаруженный duplicate USB serial. Это снимает неизвестность
 HW/FW и даёт основание выбирать реальную настройку проблемного мотора.
@@ -0,0 +1,176 @@
 # VESC Tool as the onboard engine
 Owner decision, 2026-09-23: Mission Core supplies the local and remote product
 interface; upstream VESC Tool supplies firmware compatibility, configuration
 schemas/codecs and motor calibration. Do not continue a separate Python
 implementation of Tool algorithms. Node 0.8.29-1's separate Hall/speed experiment
 was built but withheld before installation. Installed hardware remains on
 0.8.28-1. Calibration and sustained-rotation acceptance are still outstanding.
 ## Upstream boundary
 Use the stable [Tool 7.00 source](https://github.com/vedderb/vesc_tool/tree/01d5f10901116c311e3fb84d5a1541f663d3ce20)
 unchanged. This is a Qt application, not an existing HTTP service or a documented
 standalone SDK. A small C++ process adapter is necessary; it calls the actual
 `VescInterface`, `Commands`, `ConfigParams` and `Utility` implementations. It
 must not replace them with translations of their algorithms. Keep upstream
 license and corresponding source/build provenance with the combined payload.
 Mission Core owns device identity/position, exclusive access, operation and
 configuration history, session authority, local/paired transport and UI composed
 from Design Guideline components. Device parameter definitions, groups, labels,
 units, limits and enum options come from native `ConfigParams`; they must not
 be copied into a second permanent hand-maintained schema.
 Updates change a pinned upstream source plus its matching resources and rerun
 compatibility/replay acceptance. Neither a Tool update nor connecting to a board
 automatically authorizes firmware flashing or replacing controller settings.
 ## Verified native execution
 `plugins/vesc/native/offline_main.cpp` links the existing unmodified Tool object
 files, substituting only the application entry point. It has no admitted serial,
 TCP, Bluetooth or powered-operation entry point and does not start an event loop.
 The versioned `packaging/build_native_probe.py` / `native_probe.py` artifact
 compiles under an unprivileged 3 GiB user scope; it neither installs dependencies
 nor touches running services. Separate private Qt settings prevent inheriting an
 operator's saved connection.
 The adapter replays archived identity through native firmware negotiation,
 checks archive hash/command/length against the native firmware schema, passes
 the original configuration packets to `Commands::processPacket`, and exports
 the resulting native parameter groups and XML. Native serialization must
 reproduce the original binary configuration exactly. Unsupported firmware,
 corrupt hashes, wrong signatures and truncated payloads must fail closed.
 An offline `Commands::detectAllFoc` serialization probe also demonstrates the
 real compatibility behavior: Tool automatically halves a 100 W example to
 50 W on the wire for FW 5.02. No bytes are delivered to hardware. This correction
 comes from `VescInterface::fwVersionReceived` and `Commands::detectAllFoc`;
 implementing only the documented-looking command packet would miss it.
 Tool's own XML writer rounds floating point text (`QString::number` default
 precision). XML is suitable for native import/export but is not a byte-exact
 archive. Preserve the original binary snapshots alongside native XML. Native
 `ConfigParams::checkDifference` supplies the comparison tolerance; do not call
 XML conversion a lossless binary backup.
 This proves engine reuse and offline compatibility, not a shipped hardware
 backend. Production dependency closure, installer integration, USB ownership
 handoff, operation API and physical calibration remain separate acceptance work.
 ## Canonical calibration for this 1×1 rover
 The [upstream motor wizard](https://vesc-project.com/node/180) distinguishes
 motor setup from the [input wizard](https://vesc-project.com/node/181).
 The current desktop implementation is
 [`DetectAllFocDialog::runDetect`](https://github.com/vedderb/vesc_tool/blob/01d5f10901116c311e3fb84d5a1541f663d3ce20/widgets/detectallfocdialog.cpp),
 calling the actual
 [`Utility::detectAllFoc`](https://github.com/vedderb/vesc_tool/blob/01d5f10901116c311e3fb84d5a1541f663d3ce20/utility.cpp).
 1. Confirm each controller's own identity, take motor and application backups,
   inspect faults and retain existing battery protections. The problematic motor
   is LEFT; RIGHT works normally from RC. Do not copy right-side Hall calibration
   to the left or use software-induced right-side stops as a hardware diagnosis.
 2. Determine actual connection topology. Two motors, or a Mission Core 1×1
   layout, do not imply CAN master/slave. There are two USB connections and two
   receiver inputs (CH3 presumed left, CH2 right). Previous native CAN discovery
   returned no peers. Calibrate each directly connected device separately until
   another topology is evidenced; do not enable CAN forwarding merely because
   the rover has two motors.
 3. Choose the appropriate native motor procedure. The full auto-FOC wizard
   prepares parameters, temporarily adjusts battery cutoffs, detects R/L, flux
   and sensors, writes resulting settings, restores cutoffs and checks direction.
   It is not equivalent to invoking a Hall command or only starting a motor.
   Its `maxPowerLoss` is motor heating allowance, not rated shaft power; a
   remembered 500 W nameplate is not an instruction to pass 500 W here.
 4. For diagnosis without changing battery settings, use upstream's individual
   `measureRLBlocking`, `measureLinkageOpenloopBlocking` and
   `measureHallFocBlocking` procedures. The necessary current/start parameters
   and actual effects must be explicit. Use upstream calculation/application
   functions when measurements are accepted; never silently transplant a new
   Hall table or overwrite unmeasured settings.
 5. Inspect the resulting sensor mode and measurement status. Firmware 5.02
   autodetection can report success with a sensorless fallback when Hall/encoder
   detection fails. That is not proof that the broken Hall pin was repaired or
   that loaded low-speed startup is acceptable. Firmware Hall measurement locks
   ordinary motor controls during the cycle; do not promise an RC or USB stop
   that the firmware cannot perform.
 6. Read back and archive the applied result, then coordinate a visible direction
   and startup test. Assign the physical position in the existing Mission Core
   profile only from observation. Finish motor setup before changing receiver
   endpoints, neutral, deadband or direction. The receiver remains connected.
 7. Verify sustained rotation using native motor control with current limits and
   a speed setpoint. Requested duration means measured rotation after settling;
   startup, stalled motion and an early guard stop do not count as completed
   time. A torque/current command alone cannot promise 30 seconds of rotation.
 The full auto wizard includes configuration writes beyond measurements. In
 particular, blindly executing its battery stage from stale configuration metadata
 is unsuitable here: saved battery metadata says 3S / 6 Ah while observed input is
 about 50 V. Existing cutoffs are approximately 44.2 / 39 V. Retaining these
 settings for motor diagnosis is distinct from validating their suitability.
 Battery brand/capacity are not prerequisites for motor identification. Chemistry
 and series count are needed when recalculating voltage protection; pack/BMS
 charge and discharge ratings are needed when changing battery current limits.
 Do not block native engine preparation or motor-only diagnosis on unknown Ah.
 ## Hardware evidence and uncertainty
 Owner photos show UNITE branding and model family BM1418HQF on one motor; the
 other marking is worn. Owner recalls approximately 0.5 kW per motor, tentatively.
 The [manufacturer catalog](https://m.unitemotorco.com/brushless-motor/) lists
 350/500/650/750 W variants with several voltage options. This confirms the
 family, not the exact rating of this unit. Do not select a direct-drive hub
 profile based solely on the saved 46-pole / gear-ratio fields.
 Owner reports a nominal 48 V CATL-cell battery and a verbally ambiguous capacity
 around 120 Ah. The photo shows 13 visible cell bodies, but labels and the complete
 electrical topology are not visible. Chemistry, exact S/P count and BMS ratings
 remain unconfirmed. Raw photos, controller identities and native replay outputs
 stay in private evidence, outside normal Git/Ops.
 ## Remaining implementation acceptance
 - Carry the native engine and its qualified runtime dependencies through the
  existing versioned Node installer; no ad-hoc board package/library repair.
 - Admit one hardware owner at a time. Existing Python serial descriptors must
  not compete with VescInterface, and background polling must not interleave
  another session's calibration commands.
 - Expose explicit operation requests/results and native parameter metadata on
  the private onboard boundary; reuse the existing Node and paired Core path.
 - Keep backups, compatibility checks, timeouts, durable unknown-operation state,
  readback and observed sensor mode in the receipt. No automatic retry of motion.
 - Before each powered agent test obtain a fresh observing reply and announce
  target/parameters. Existing authorization does not establish that the owner is
  still watching after a build.
 - Qualify native device reads before calibration, then verify left and right
  startup/direction and actual sustained rotation separately. Do not mark the
  rover calibrated from offline tests.
 ## Native runtime candidate 0.4.0
 The per-device `native/engine_main.cpp` now implements bounded JSON requests
 on private inherited pipes. Native VescInterface owns and exclusively locks the
 actual serial descriptor; the service never opens a competing descriptor.
 Configuration reads verify upstream serialization against the original bytes.
 The admitted native methods cover identity/telemetry/configuration/CAN/PPM reads,
 short app-output leases, current release, bounded current and speed, volatile
 current scales, native parameter/XML export and upstream blocking Hall detection.
 No arbitrary packet, firmware flash or general command execution API is exposed.
 `runtime/native_link.py` owns subprocess lifetime and attachment checks. An
 unmatched/lost response closes the stream; no powered command is retried.
 Reconnection creates a fresh device session. Pending measurements and current
 limit restoration remain durable across process failures. During Hall detection
 only its status, telemetry/PPM reads and release/leases are allowed; none is
 represented as cancelling firmware's non-interruptible measurement.
 The versioned runtime carries private Qt/offscreen dependencies and source/license
 provenance. `native_check.py` verifies the installed files and runs the disconnected
 engine as the service account before USB discovery. Qualification and actual
 installation/measurement outcomes are recorded in the installation ledger.
 Full auto-FOC, application of measured calibration, general parameter editing
 and physical motor acceptance remain outstanding; do not equate this API with
 complete VESC Tool UI parity.
@@ -0,0 +1,99 @@
 # Калибровка VESC через Mission Core
 Проверено на Node 0.8.35-1 / VESC plugin 0.6.3, VESC Tool 7.00 и прошивке
 контроллеров 5.02. Это описание доступного процесса; журнал конкретных
 испытаний находится в `17_VESC_INSTALLATION_LEDGER.md`.
 ## Действия оператора
 Открыть «Аппараты», нужный аппарат, устройства его бортового компьютера,
 нужный VESC и «Настройка VESC». В блоке «Калибровка мотора» проверить выбранный
 контроллер, параметр допустимых потерь, подтвердить наблюдение и нажать
 «Откалибровать мотор». Дождаться результата записи, проверки конфигурации
 и снятия тока. Для второго контроллера открыть его карточку и выполнить
 отдельную калибровку. Профиль 1×1 сам по себе не запускает групповую калибровку.
 Моторы должны свободно вращаться, пульт — быть выключен. В прошивке 5.02
 нативное измерение нельзя прервать обычной кнопкой остановки или пультом;
 оператор должен иметь возможность отключить силовое питание.
 Перед процедурой сохраняются конфигурации подключённых контроллеров.
 Мастер измеряет электрические параметры выбранного мотора, определяет
 датчики, рассчитывает настройки FOC и записывает результат. Mission Core
 проверяет прочитанную обратно конфигурацию и сохраняет версии до/после.
 Настройки другого мотора, аккумулятора и приёмника защищены от незапрошенного
 изменения. Полная процедура повторно не нужна перед обычным запуском мотора.
 ## Что означает 50 Вт
 «Допустимые потери в моторе» — входной параметр штатного мастера VESC Tool.
 Он задаёт расчётные резистивные потери на нагрев при предельном токе. По нему
 и измеренному сопротивлению мастер выбирает токи измерения и рассчитывает
 сохраняемый предел тока мотора. Это не напряжение аккумулятора, не полезная
 механическая мощность и не паспортная мощность мотора. Увеличение значения
 может увеличить ток и нагрев; вводить сюда номинальные 500 Вт автоматически
 неправильно. Параметр не заменяет измерение температуры и тепловую проверку.
 В принятой калибровке двух моторов при 50 Вт мастер установил примерно
 34,21 и 34,41 А. Это результат конкретных измерений, а не универсальный
 допустимый ток всех моторов. Поправку совместимости с прошивкой 5.02
 выполняет сам VESC Tool. Она не воспроизводится отдельной формулой Mission Core.
 Источник: [объяснение автора VESC](https://www.vesc-project.com/node/1029),
 [влияние параметра на токи измерения](https://vesc-project.com/node/1640),
 `Commands::detectAllFoc` и `Utility::detectAllFoc` в закреплённом исходнике Tool.
 ## Датчики Холла и отдельное измерение
 Датчики сообщают контроллеру положение ротора. При автоопределении FOC мастер
 уже проверяет датчики и может выбрать работу без них. Успешная калибровка в
 режиме без датчиков не доказывает исправность проводки Холлов.
 Кнопка «Измерить датчики Холла» выполняет отдельную диагностику выбранного
 мотора: штатный цикл при 5 А с медленными смещениями получает таблицу
 состояний. Она не применяется автоматически, рабочая конфигурация сохраняется.
 Это проверка для поиска неисправности, а не обязательный второй этап каждой
 калибровки. Неполная таблица требует различать проблемы датчиков/соединений
 и недостаточное движение при измерении. Номер физического сломанного контакта
 не определяется по таблице без проверки распиновки и проводки.
 Для подготовки к измерению в Node 0.8.39-1 / plugin 0.6.6 оператор отдельно
 подтверждает неподвижность всех моторов. Бессенсорная прошивка может сообщать
 ненулевые ERPM и изменение тахометра при физической остановке: оба значения
 вычисляются из оценки положения ротора. Приложение сохраняет эти показания,
 а перед измерением повторно проверяет нейтраль приёмника, отсутствие PWM,
 малый ток и отсутствие ошибок. Это исключение действует только для
 наблюдаемого измерения Холлов в бессенсорном режиме, не для управления
 движением. Установка и реальные результаты новой версии фиксируются отдельно
 в журнале испытаний.
 ## Назначение и проверка вращения
 Назначение «левый/правый» связывает постоянный UUID VESC с местом мотора на
 аппарате. Оно нужно для адресного и общего управления, но не влияет на
 измеряемое сопротивление или параметр потерь. После смены USB-порта назначение
 сохраняется. Общий список назначений находится в разделе «Настройки борта»;
 это профиль аппарата, а не перечень моторов внутри одного VESC.
 «Проверка вращения» запускается отдельно от калибровки. Скорость задаётся
 в ERPM, ток задаёт верхний предел, длительность считается после разгона
 и удержания скорости. Выбор всех моторов профиля запускает совместную
 проверку; для 1×1 это два мотора. Успешная проверка на вывешенном приводе
 не заменяет проверку под нагрузкой или надёжности связи.
 ### Visible forward/reverse bench rotation
 After Hall measurement, use **Проверка вращения** for sustained visible motion.
 Select one controller or the complete assigned profile, then **Направление
 вращения → Прямое / Обратное**, speed magnitude, motor-current ceiling and hold
 duration. Direction is relative to each VESC's existing settings, not a certified
 vehicle heading. Current is an upper torque limit, not a speed setting.
 Observe all motors fully stopped, raised and free before confirming each start.
 Wait for physical stop before changing direction. There is no automatic forward/
 reverse sequence. On admitted sensorless firmware, idle ERPM alone cannot prove
 standstill; the preflight records that estimate alongside electrical checks.
 Timing begins after speed settles; preparation/ramp/gaps are excluded. Compare
 VESC observations with actual movement. This is an unloaded bench test, not
 acceptance of loaded starts or the unresolved left Hall hardware fault.
@@ -0,0 +1,145 @@
 # VESC: план привода и ограничения мощности
 Актуализация 2026-09-24 после установки: Node 0.8.38-2 установлен, Core
 принял оба VESC; владелец подтвердил появление устройств после перезапуска.
 Ниже сохранён исходный аудит сбоя загрузки и состояние ранних сборок, а не
 текущий статус установки. Последний журнал — `17_VESC_INSTALLATION_LEDGER.md`;
 текущая очерёдность диагностики, RC-перехвата и профилей —
 `23_ROVER_CONTROL_PROFILES.md`, раздел «Приёмка и порядок».
 Статус на 2026-09-24: исследование и план. Пользователь попросил разобраться
 в штатном механизме VESC Tool; управление пределами пока не реализуется и
 настройки контроллеров не меняются.
 ## Принятый результат и незавершённая работа
 - Оба мотора откалиброваны штатным нативным VESC Tool; калибровка, история
  конфигураций, назначение и одиночная/совместная проверка доступны в UI.
 - Принят совместный тест примерно 30 секунд и хороший ход обоих моторов с
  пульта по наблюдению владельца. Это проверка вывешенного привода.
 - Левый работает без датчиков, правый с Холлами. Отдельная повторная
  диагностика Холлов не завершена; повреждённый контакт не локализован.
 - Надёжность USB не принята: после успешного теста повторялись ошибки чтения.
 - Node 0.8.36-1 с исправлением проверки нейтрали PPM подготовлен и проверен,
  но не установлен. Это исправление не объявляется решением USB-сбоев.
 ## Отсутствие устройств после загрузки
 Сегодня Node 0.8.35-1 и VESC-служба активны, без автоматических перезапусков.
 Linux не перечисляет VESC среди USB-устройств; ttyACM и serial/by-id отсутствуют.
 Во время загрузки есть ошибки чтения USB-дескрипторов и адресации (-71) на
 двух портах. Дескрипторы этих устройств не получены: приписывать им личность
 VESC или конкретную причину ошибки пока нельзя. Изменение портов не должно
 менять идентичность: назначения привязаны к UUID контроллеров.
 Владелец затем подтвердил подключённые USB-кабели и успешное управление обоими
 моторами с пульта сейчас. Это подтверждает работу силового питания и моторного
 управления, но не USB-канала. Первые ошибки USB зарегистрированы около 9,124 с
 от старта, процесс VESC-службы запущен на 11,111 с, Node — на 13,430 с. Значит,
 первый сбой перечисления возник до запуска нашего прикладного драйвера в этой
 загрузке. Это не устанавливает, неисправен кабель, устройство, питание USB или
 контроллер USB Mini. Никакого ручного сброса портов в аудите не выполнялось.
 Отдельный недостаток продукта подтверждён исходниками: drive-profile.json
 сохраняется на борту, но Service.inventory публикует drive_profile только
 внутри обнаруженных устройств. Node сохраняет отсутствующие устройства через
 реестр initialized, который обновляется при prepare; автоматически обнаруженная
 личность сама в него не добавляется. В текущем Core один VESC остаётся offline,
 второго нет в inventory, хотя архивы обоих доступны. Это не потеря калибровки,
 но модель отображения известных устройств и общего профиля недостаточна.
 Нужны независимая доступность профиля аппарата и сохранённый список назначенных
 контроллеров со статусом «нет связи». Нельзя выдавать сохранённые сведения за
 свежую телеметрию или разрешать команды без нового подтверждения UUID/сеанса.
 Сохранность самого файла профиля в этом аудите напрямую не проверена: у SSH
 пользователя нет права чтения. Факт сохранения установлен по реализации и
 вчерашним квитанциям; текущие архивы обоих контроллеров прочитаны через Core.
 ## Последние подтверждённые пределы
 Данные из архивов 2026-09-23 21:05 UTC, а не новое чтение недоступных VESC.
 | Параметр | Левый | Правый |
 | --- | ---: | ---: |
 | Максимальный ток мотора | 34,2135 А | 34,4078 А |
 | Масштаб тока разгона | 100% | 100% |
 | Предел тока батареи | 55 А | 55 А |
 | Предел рекуперации в батарею | −55 А | −55 А |
 | Отдельное ограничение мощности | выключено | выключено |
 Значение watt max 1500000 соответствует выключенному ограничению в профилях
 Tool. Оно не является мощностью оборудования. Значение absolute current
 160 А — отдельный порог защиты, а не паспортный рабочий ток. Настройки батареи
 унаследованы и не подтверждают возможности BMS. Максимумы мотора около 34 А
 получены мастером при допустимых потерях 50 Вт. Этот параметр калибровки не
 является выходной мощностью. Временные 30 А и 2000 ERPM теста не являются
 постоянным ограничением ручного управления; квитанции подтверждают восстановление
 временных токовых масштабов после принятого теста.
 ## Штатный механизм
 Базовые Motor Current Max, Battery Current Max, рекуперация и другие пределы
 хранятся в конфигурации каждого VESC. Профиль Tool задаёт масштаб тока разгона
 и торможения, скорость, duty и мощность. Процент тока не равен проценту ватт:
 ток мотора в первую очередь задаёт момент, а батарейный ток относится к
 потреблению от общей батареи.
 В закреплённом Tool ProfileDisplay вызывает Commands::setMcconfTemp и предлагает
 «Use until reboot» и постоянное применение. FW 5.02 поддерживает сохранение,
 пересылку по CAN и деление ватт между обнаруженными CAN-контроллерами. Поэтому
 общий профиль возможен, но исполняют ограничения отдельные контроллеры. Их
 применение влияет и на PPM-пульт; для этого не нужна повторная калибровка.
 Временное применение не требует записи каждого движения ползунка во flash.
 В штатной пересылке подтверждение ведущего не является подтверждением каждого
 ведомого: FW подавляет ack для пересланных команд. В интеграции нужны проверка
 состава назначенных UUID и чтение результата у каждого участника. Делить бюджет
 по случайному числу отвечающих устройств нельзя: пропавший контроллер может
 снова появиться, и общий бюджет батареи будет превышен. Конкретную политику
 частичного применения и восстановления следует определить до реализации.
 ## Предлагаемая модель Mission Core
 Общий профиль привода размещается у аппарата. Он содержит уже существующую
 схему 1×1/2×2 и назначения, подтверждённый бюджет общей батареи и режим работы.
 Карточка каждого VESC хранит калибровку, паспортные основания пределов и его
 индивидуальные ограничения. Общий режим применяет согласованные значения к
 назначенным контроллерам через нативный Tool; подтверждённые ограничения
 исполняются на VESC независимо от связи с Core.
 Запас 20% рассчитывается от подтверждённых допустимых характеристик при
 реальном охлаждении и длительности нагрузки. Для каждой пары мотор–контроллер
 нужен допустимый фазный ток; для общей батареи — суммарный ток разряда и
 отдельный ток заряда/рекуперации. Пиковый ток нельзя считать непрерывным.
 Маркер прошивки 75_300_R2 не доказывает производителя и реальные характеристики
 платы, а приблизительные 500 Вт мотора не определяют допустимый фазный ток.
 Поэтому численный новый потолок пока не назначен. Нужны точные модели или
 подтверждённые характеристики от изготовителя и параметры BMS.
 ## Очерёдность
 1. Установить состояние питания/подключений и восстановить USB-обнаружение,
   затем проверить связь без вращения. Смена портов не должна требовать
   повторного назначения, перезагрузка не должна скрывать сохранённый профиль.
 2. Исправить доступ к общему профилю и отображение известных offline-устройств;
   применить и проверить подготовленное исправление нейтрали пульта через
   версионный установщик с согласованным прерыванием служб.
 3. Сверить паспорта моторов, контроллеров и BMS; сформировать индивидуальные
   пределы и общий бюджет с согласованным запасом. Затем реализовать профили
   ограничений штатными средствами Tool, с резервированием и чтением результата.
 4. Завершить отдельную диагностику Холлов, сохранив принятую калибровку.
 5. Принять работу под нагрузкой, ограничения температуры/рекуперации и
   остановку при потере связи; далее полноценное ручное удалённое управление,
   приоритет пульта и автономный режим. Общий тест пока не означает готовность
   всей системы управления к эксплуатации.
 ## Первичные источники
 - [VESC: назначение пределов тока](https://vesc-project.com/node/180).
 - [Tool: штатные профили и применение](https://github.com/vedderb/vesc_tool/blob/01d5f10901116c311e3fb84d5a1541f663d3ce20/mobile/ProfileDisplay.qml).
 - [Tool: поля профиля](https://github.com/vedderb/vesc_tool/blob/01d5f10901116c311e3fb84d5a1541f663d3ce20/mobile/ProfileEditor.qml).
 - [FW 5.02: COMM_SET_MCCONF_TEMP](https://github.com/vedderb/bldc/blob/5.02/commands.c).
 Ops MCP на момент обновления возвращает HTTP transport error; план и свежая
 диагностика в Ops не опубликованы. Частные журналы и UUID находятся вне Git
 в outputs/rover-006-vesc-context-20260923/native-probe/boot-20260924-*.
@@ -0,0 +1,95 @@
 # Подготовка окружения, автозапуск и USB при загрузке
 Требование владельца от 24.09.2026: пользователь получает сборку Node,
 открывает приложение и выполняет его настройку. Все необходимые изменения ОС
 выполняет версионированный продукт. Ручные правки Linux не являются частью
 установки, диагностики с исправлением или первого испытания.
 ## Владение настройкой
 Существующая страница «Настройка окружения → Сконфигурировать» использует
 профиль `ubuntu-24.04-amd64/3`. Добавлены два этапа в существующий список:
 - «Автозапуск приложения»: root-owned XDG entry открывает обычное окно Node
  после входа в графическую сессию. Перед запуском оно до 180 секунд ожидает
  HTTP-службу. Gtk.Application сохраняет одно окно на пользовательскую сессию.
  Авторизация локального интерфейса остаётся обычной polkit-авторизацией;
  автозапуск не выдаёт новые права и не настраивает автоматический вход в ОС.
 - «Обнаружение устройств при загрузке»: устанавливает фиксированную политику,
  включает отдельную службу на следующую загрузку и читает возможности текущих
  USB-хабов. Подготовка окружения не перезапускает USB-порты в текущей сессии.
 Системная служба Node уже включалась установщиком и работает до входа в рабочий
 стол. Открытие окна и работа борта — разные жизненные циклы. Постоянного
 интерфейса управления портами нет; обновление устройств только обновляет список.
 Политика и XDG entry создаются из шаблонов пакета. Повторное выполнение
 идемпотентно; чужие файлы/ссылки не перезаписываются. При удалении пакета
 удаляются только неизменённые принадлежащие продукту файлы, служба отключается.
 Пакет запрещает замену файлов во время переключения USB или незавершённого
 обратного включения. При откате до версии раньше 0.8.37 prerm также отключает эту службу и удаляет
 только совпадающие с шаблонами настройки, прежде чем dpkg удалит новые helper.
 Физическая проверка downgrade ещё не выполнена.
 Подтверждаемый профиль пока Ubuntu 24.04 amd64. Новые дистрибутивы и архитектуры
 должны получить собственные поддерживаемые профили и проверку dependency closure;
 этот пакет не является доказательством работы на любом Linux.
 ## Ограниченная процедура USB
 1. Служба запускается до Node и VESC, только если подготовка среды включила
   политику. После udev-settle выдерживается возраст загрузки не менее 30 секунд:
   ядро может ещё повторять обнаружение после завершения udev-settle.
 2. Из журнала **текущей загрузки**, только transport=kernel, выбираются порты с
   окончательным `unable to enumerate USB device` в первые 60 секунд. Более
   позднее подключение/отключение отменяет устаревший кандидат. Ошибка чтения
   дескриптора сама по себе не разрешает сброс.
 3. На порту и его USB 2/3 companion не должно быть дочернего устройства,
   состояния незавершённого обнаружения, отключения или зарегистрированного
   overcurrent. Встроенные hardwired-порты исключены. Проверяются взаимные peer
   ссылки, поколение/адрес хаба и нахождение атрибутов в sysfs.
 4. Дескриптор каждого хаба должен подтвердить individual port power switching.
   При ganged/no switching/нечитаемом дескрипторе порт пропускается. Поддержка
   физического отключения VBUS всё равно зависит от железа; успешный sysfs write
   не доказывает восстановление устройства.
 5. До первого изменения сохраняется root-owned журнал обратного включения.
   После повторной проверки свободных портов пара отключается на одну секунду,
   включается в `finally`; до восьми секунд ожидается новое обнаружение.
   ExecStopPost повторяет обратное включение при остановке процесса. Уже включённый
   порт не переключается повторно. Ошибка восстановления сохраняет pending и
   останавливает обработку других портов.
 6. Не более одной попытки на физическую пару за загрузку, общий бюджет 90 секунд,
   начало только в первые 180 секунд. Поздний запуск службы/перезапуск приложения
   не сбрасывает USB. Повторный запуск сохраняет исходный результат.
 До чтения дескриптора тип проблемного устройства неизвестен: это ограниченное
 восстановление ошибки Linux USB, а не угадывание VESC по пустому разъёму.
 Конкурентное физическое подключение полностью не атомарно относительно sysfs;
 проверки выполняются непосредственно перед записью. Процедура не меняет драйвер
 хост-контроллера и не сбрасывает целый USB-контроллер/хаб. Она не отправляет
 команды моторам. После обнаружения обычный драйвер сопоставляет VESC по firmware
 UUID, а не по tty, разъёму или неуникальному USB serial.
 Результаты остаются в `/run/mission-core-usb-startup/`: inspection.json,
 result.json, attempted, при незавершённом восстановлении pending.json.
 Синтетические тесты используют временный sysfs; реальное переключение в них
 не выполняется.
 ## Приёмка
 - Локально: 36 тестов подготовки/автозапуска/USB, shell syntax и diff check прошли.
 - Ubuntu qualification: 17 этапов прошли; пакет 0.8.37-1 и штатный установщик
  сформированы, APT-план проверен. Пакет установлен штатным установщиком.
  Хеши и результаты находятся в ledger.
 - Подготовка через поставляемый UI: все девять этапов завершены, XDG entry и
  USB-политика созданы, служба восстановления включена для следующей загрузки.
  Сводная проверка нашла поддержку у USB-хабов; возможности именно корневых
  портов ещё нельзя вывести из сводного статуса. Оба VESC доступны.
 - Холодная загрузка с подключёнными VESC, сохранение UUID/назначений и отсутствие
  вмешательства в камеры: ещё не приняты. Программный перезапуск службы не
  заменяет этот тест. Без владельца перезагрузка борта не выполняется.
 Основания: Linux [USB sysfs ABI](https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-bus-usb),
 [port.c](https://github.com/torvalds/linux/blob/master/drivers/usb/core/port.c),
 [USB error codes](https://docs.kernel.org/driver-api/usb/error-codes.html),
 [uhubctl: switching and USB 2/3 peers](https://github.com/mvp/uhubctl).
@@ -0,0 +1,37 @@
 # Карточка аппарата: борт, настройки и устройства
 Согласовано владельцем 2026-09-24: существующую карточку аппарата разделить
 на три независимо сворачиваемых блока; повторить композицию в Node.
 - «Бортовой компьютер»: идентичность, связь, характеристики и существующие действия.
 - «Настройки борта»: общий профиль привода, назначения UUID и чтение ограничений VESC.
 - «Устройства аппарата»: существующий инвентарь и переход к конкретному устройству.
 Используется канонический DG Inspector variant=panel. Новая навигация и новые
 визуальные сущности не вводятся. Альтернатива — дополнительные окна настроек —
 отклонена владельцем в пользу блоков на существующей карточке.
 Открытые секции сохраняются автоматически в JSON на стороне приложения:
 в Core отдельно для каждого аппарата, в Node локально для его борта. Это
 представление оператора, не конфигурация контроллера. Изменение одного блока
 не перезаписывает состояние остальных. Пустой список означает «всё свёрнуто».
 Инвентарь и выполняющиеся команды живут выше Inspector: сворачивание не
 останавливает соединения и не скрывает ошибки сохранения.
 Общий профиль и назначения используют прежние проверенные команды VESC.
 Калибровка, Холлы, тест вращения и версии конфигурации остаются в карточке
 конкретного контроллера. Чтение ограничений идёт через нативный VESC Tool,
 не меняет моторную конфигурацию и не запускает мотор. Значения являются
 настройками контроллера, а не паспортными пределами оборудования.
 Изменение рабочих пределов мощности остаётся отдельным этапом по плану 20:
 нужны подтверждённые пределы оборудования и политика согласованного применения.
 Никаких искусственных «80% мощности» или новых токовых пределов этот этап
 не записывает. Проверки: сохранение после навигации/перезагрузки, разделение
 аппаратов, конкурентные изменения секций, ошибки JSON/связи и обе поверхности.
 Последующее требование владельца: добавить здесь два режима ручного управления
 ровером. Исследование источника команд, пульта и независимого RC-пути находится
 в [плане 23](23_ROVER_CONTROL_PROFILES.md). Этот режим не совпадает со схемой
 1×1/2×2; переключатель не объявляется действующим до реализации и проверки
 реального пути команд.
@@ -0,0 +1,595 @@
 # Профили ручного управления ровером
 Актуальное решение владельца 25.09.2026: оставить работающее управление двумя
 стиками; Tank/Arcade и управление одним стиком отложить до отдельного возврата
 к задаче. Сейчас Mini получает CH2/CH3, но не горизонтальную ось выбранного
 стика; новую проводку/адаптеры владелец исключил. Прототип не включать в
 production и не показывать переключение RC-профиля как применённое.
 Требование stop → neutral → manual сохранено незавершённым.
 Полный контрольный паспорт, конфигурации, история экспериментов и чекеры
 опубликованы в [MISSIONCOR-85 — Гусеничный ровер Node 006](https://ops.nodedc.ru/nodedc/browse/MISSIONCOR-85).
 Карточка прочитана обратно через прямой Ops MCP: все 35 структурированных
 блоков совпали с подготовленным содержимым, включая 600 параметров VESC.
 Статус 2026-09-24: исследование и автономный программный прототип. Рабочие
 настройки пульта, приёмника и VESC не изменены; новый режим движения на
 оборудовании пока не реализован.
 ## Требование владельца
 В существующих «Настройках борта» нужны два профиля: независимое управление
 левым и правым бортом двумя рычагами и управление движением/поворотом одним
 двухосевым рычагом. Тот же профиль должен быть доступен локально на Node и
 через Core. Пульт должен сохранять возможность управления при отказе Mini.
 Профиль управления не заменяет схему привода 1×1/2×2 и назначения моторов.
 Последние определяют физические исполнительные устройства; профиль определяет
 смысл входных команд. Новые режимы не требуют повторной калибровки моторов.
 Уточнение владельца: при автономном движении или удалённом ручном управлении
 пульт может оставаться включённым и готовым к немедленному перехвату. Движение
 рычага за пределами проверенной нейтрали должно отбирать управление у всех
 источников Mission Core без переключения режима в интерфейсе. После перехвата
 нейтраль пульта не возобновляет прерванную задачу. Локальный оператор может
 освободить застрявший ровер даже при недоступном операторском Core; отказ самого
 Mini также не должен лишать его независимого RC-пути. Уведомления об аномалии
 и обнаружение застревания пока описывают будущий сценарий, не реализованный код.
 Следующее уточнение владельца: отдельный интерфейс переключения источника
 управления не нужен. Владелец наблюдает, что пульт работает только когда четыре
 верхних переключателя подняты, и предлагает использовать это как сигнал
 ручного перехвата. Наблюдение ещё не разделено на блокировку при включении и
 поведение уже работающего передатчика. По руководству FS-i6S, раздел 4.1,
 верхнее положение требуется при включении; раздел 2.2.3 описывает SwA–SwD как
 назначаемые переключатели. Документ не подтверждает отдельный передаваемый
 признак «все четыре подняты» или отключение радиолинка любым из них.
 Владелец затем исправил наблюдение: управление моторами сохраняется и со
 всеми четырьмя тумблерами в нижнем положении. Гипотеза «любая нижняя позиция
 выключает управление/радиосвязь» отозвана. Начальный пассивный замер был
 помечен заявленным положением SWA, но его нельзя использовать как доказательство
 влияния тумблера: синхронное сравнение состояний не завершено. Предложенное
 переключение SWA для следующего замера отменено. Проверка положений при
 включении остаётся вероятным объяснением, не подтверждённой настройкой пульта.
 Это требование к автоматическому выбору источника не отменяет ранее заказанную
 настройку Tank/Arcade: раскладка органов управления и право выдавать команду
 моторам — разные свойства. Перехват не должен требовать клика в Core.
 ## Последнее уточнение: первый ввод останавливает, следующий управляет
 Владелец изменил непосредственную реакцию на RC: первый ввод с рычага должен
 только прервать автономное/удалённое движение; последующий ввод может управлять
 моторами. Отменяются задачи автономной езды и их вычислительные исполнители,
 включая связанные с ней inference/планирование/обработку облаков. Запрет на
 выходные команды должен вступать в силу раньше и независимо от завершения
 таких задач. Нельзя ждать остановки тяжёлого вычисления, прежде чем запретить
 ему движение; запоздавшие результаты и команды теряют допуск.
 Один удерживаемый рычаг создаёт непрерывную последовательность пакетов, поэтому
 «следующий пакет» не равен второму осознанному действию. Подтверждённая владельцем
 последовательность — первый выход из нейтрали: остановка; затем оба моторных
 канала в устойчивой нейтрали; затем новое отклонение: ручное движение.
 Ответ владельца 2026-09-24: «Да: остановка → нейтраль → управление».
 Требование принято; изменение рабочего моторного runtime ещё не выполнено.
 Для этой трактовки нужны состояния прекращения команд, подтверждения остановки,
 ожидания нейтрали и ручного управления. Нельзя пропускать первое удерживаемое
 отклонение после фиксированной паузы или считать перезапуск процесса разрешением
 движения. Проверяются свежесть входа, все назначенные стороны и отзыв старых
 допусков. Длительность нейтрали и допустимое время остановки задаются после
 выбора и проверки исполнительного механизма, не случайной константой.
 Текущая прямая PWM-проводка приёмник→VESC и истечение 250 мс аренды сами по себе
 не реализуют это требование: отпустив аренду при удерживаемом RC, программа
 передаст в мотор уже первое отклонение. Нельзя выдавать существующий test latch
 за stop-first. Также удержание блокировки только на Mini не гарантирует эту
 семантику при отказе Mini. Для независимой гарантии проверка перехода должна
 жить у исполнителя либо в отдельном независимом тракте; stock FW 5.02 такой
 квалифицированной функции в нынешней схеме не имеет. Это архитектурная граница,
 не разрешение автоматически прошивать VESC или покупать новый контроллер.
 Остановка вычислительных задач не означает остановку служб приёма RC,
 контроля привода и наблюдения его состояния. Нулевая команда тока не доказывает
 физическую остановку: выбег/торможение и допустимая рекуперация требуют отдельной
 проверки. Автоматический возврат к прерванной задаче после нейтрали запрещён.
 ### Подтверждённая последовательность
 | Состояние | Событие | Требуемая реакция |
 | --- | --- | --- |
 | Движением управляет Mission Core | Первое допустимое отклонение любого назначенного RC-канала | Отозвать допуск всех остальных источников, очистить их очередь, начать согласованную остановку всех приводов и отменить задачи автономного движения. Первое отклонение не передавать как команду езды. |
 | Остановка / ожидание нейтрали | Рычаг остаётся отклонённым, приходят новые пакеты | Сохранять запрет движения; количество пакетов и прошедшее время сами по себе его не снимают. |
 | Остановка / ожидание нейтрали | Остановка подтверждена, все назначенные рычаги вернулись в подтверждённую нейтраль | Разрешить следующий осознанный RC-жест; Mission Core остаётся без допуска к движению. |
 | Пульт готов к движению | Новое отклонение рычага | Передать ручную команду назначенным приводам. |
 | Пульт управляет | Последующие отклонения и возвраты в нейтраль | Обычное ручное управление. Каждый новый жест не повторяет процедуру перехвата. |
 | Любое состояние после перехвата | Пришла запоздавшая команда отменённой задачи / восстановилась связь Core | Отклонить команду. Восстановление связи не возобновляет автономное движение. |
 Это контракт поведения, не таблица состояний установленной реализации.
 Условия свежести и нейтрали относятся ко всем назначенным каналам, независимо
 от схемы 1×1/2×2 и числа моторов. Пропавший канал не считается нейтральным.
 Ответ на USB-запрос с последним декодированным значением сам по себе не
 доказывает свежий импульс приёмника: FW 5.02 не возвращает его возраст в
 `COMM_GET_DECODED_PPM`. Нейтральный failsafe также не доказывает отпускание
 стика оператором. Эти ограничения должны быть учтены до допуска автономии.
 ### Проверка штатной FW 5.02
 Аудит выполнен по сохранённому upstream commit
 `3f670137e27e6e383fa79c50cc6b1fa85aab1554`; Git blob-хэши `app_ppm.c`,
 `app.c`, `commands.c`, `datatypes.h` совпадают с сохранённым деревом Git.
 Это проверка исходников upstream, не доказательство побайтового совпадения
 прошивки производителя в имеющихся контроллерах.
 - `applications/app_ppm.c`: вход декодируется при отключённом выходе;
  Safe Start использует счётчик нейтральных импульсов после конфигурации,
  тайм-аута приёмника или ошибки. Ветка отключённого выхода не сбрасывает
  этот счётчик. Завершение USB-аренды не создаёт новую проверку нейтрали.
 - `applications/app.c::app_disable_output`: положительное время отключает
  выход до истечения таймера; его callback просто разрешает выход. Значение
  −1 отключает бессрочно, что не подходит для независимого RC при отказе Mini.
 - `commands.c::COMM_SET_APPCONF`: перезапускает приложения и сохраняет
  конфигурацию во flash. Это не команда ручного перехвата на каждый жест.
 - `COMM_SET_CAN_MODE` может вызвать тот же перезапуск без сохранения, но
  перезапуск PPM/UART и других приложений через настройку CAN не является
  проверенным механизмом передачи управления. Такой обход не применяется.
 - Наш native `release` отправляет `setCurrent(0)`: это снятие тяги, а не
  подтверждённое торможение и не повторное включение Safe Start.
 Для исправного Mini возможен программный цикл удержания выхода до нейтрали.
 Он не обеспечивает одинаковое поведение при потере Mini/USB: таймер в VESC
 всё равно истечёт. Штатной проверенной функции для полного требования в
 текущем тракте не найдено. Нужна поддержка перехвата на исполнительном уровне
 либо другой независимый тракт. Простого изменения в одном VESC недостаточно:
 отклонение одного канала должно согласованно остановить весь борт, а топология
 межконтроллерной связи пока не подтверждена.
 Следующий этап реализации — выбрать и проверить такой механизм по имеющемуся
 железу, включая отзыв прямых USB-команд, согласование всех приводов, остановку
 и нейтраль при отказе Mini. Обновление/доработка прошивки требует отдельного
 плана совместимости и восстановления. Пока проверяются эти условия,
 не активировать автономное движение и не выдавать действующие стендовые
 тесты за принятый постоянный арбитр. Прошивки и рабочая RC-конфигурация в этом
 аудите не изменялись.
 Кандидат для следующей проверки без отдельного бортового контроллера —
 штатная LispBM-поддержка современных VESC: upstream документирует для FW 6.00+
 `get-ppm`, `get-ppm-age`, `app-ppm-detach`, `app-ppm-override`, а также доступ
 к PPM других VESC через настроенный CAN. Код исполняется в контроллере,
 не на Mini. Это возможный исполнитель подтверждённой последовательности,
 не готовая встроенная функция перехвата и не доказанная гарантия приоритета
 над прямыми USB-командами. Нужны проверка совместимости платы, согласованный
 обмен между приводами, исключение обхода арбитра, реакция на остановку скрипта
 и квалификация поведения при потере каждого соединения. Возраст PPM отличает
 отсутствие импульсов от их наличия, но не живой радиолинк от импульсов failsafe.
 Текущая версия 5.02 этой документированной LispBM-возможностью не подтверждена.
 Маркер 75_300_R2 недостаточен для выбора прошивки; у владельца запрошены
 производитель и точная модель, если известны. Обновление не запускалось.
 [Документация LispBM VESC](https://github.com/vedderb/bldc/blob/master/lispBM/README.md),
 [описание поддержки в FW 6.00 автором VESC](https://vesc-project.com/node/3385).
 ## Что подтверждено
 Приёмник на прежней фотографии — FlySky FS-iA6B. По сообщению владельца,
 левый VESC подключён к CH3, правый к CH2. Принятое вращением назначение
 контроллеров хранится по UUID, независимо от USB-порта.
 Новые фотографии пульта показывают маркировку Robcom Venom Drone. Корпус,
 две кнопки питания, сенсорный экран, расположение переключателей, задних
 кнопок и PS/2/USB совпадают со схемой FlySky FS-i6S. Это обоснованная
 идентификация семейства по внешности. Владелец сообщает о втором внешне таком
 же пульте без маркировки Robcom. Последующий осмотр About 2026-09-25 подтвердил
 сообщаемые устройством Flysky FS-i6S, прошивку 2.00 от 04-Apr-2020 и Hardware
 V_3.0; подробности видеоподтверждения приведены ниже. Это не аудит возможных
 OEM-изменений электроники.
 По руководству семейства FS-i6S, разделы 2.2.3 и 6.8, SwA/SwB/SwC/SwD —
 назначаемые переключатели: их можно связать с дополнительным каналом или
 функцией передатчика. У каждого нет постоянного назначения «камера»,
 «ручной режим» или «аварийный стоп». На дополнительном канале передаётся
 значение, соответствующее положению; смысл ему задаёт принимающая система.
 Фактические назначения конкретного пульта ещё не прочитаны. Меню Aux. Channels
 показывает назначения дополнительных каналов; функции самого передатчика
 могут использовать переключатели отдельно (например Trainer Mode, раздел 7.3).
 Текущее подключение CH2/CH3 к VESC не даёт Mini доступ ко всем этим каналам.
 В архиве конфигураций после принятого общего теста оба входа VESC настроены
 как PPM Duty Cycle. Левый использует приложение PPM, правый — PPM and UART.
 Настройки отклика различаются: разгон/сброс слева 0,4/0,2 с, справа 0,5/0,5 с;
 параметр polynomial curve слева −1, справа −1,5; deadband у обоих 0,15.
 Это сохранённые значения, не новое чтение после текущей загрузки и не
 основание автоматически уравнивать параметры. Ровное вращение на общей
 команде ERPM не означает одинаковую реакцию на одинаковое положение стиков.
 У обоих сохранён multi_esc=true. Наличие и топология физического CAN ещё
 не подтверждены. Перед изменением схемы команд надо исключить взаимную
 пересылку между левым и правым бортом; одну настройку нельзя считать схемой
 проводки. Никакого CAN broadcast или изменения multi_esc сейчас не сделано.
 ## Канонические механизмы
 В терминологии WPILib первый режим — Tank Drive, второй — Arcade Drive.
 Arcade преобразует движение и поворот в согласованную пару команд левой и
 правой стороны. Curvature Drive — отдельный вариант поведения поворота;
 его нельзя незаметно подменять под тот же профиль. Стороны могут включать
 несколько назначенных моторов. [Официальное описание WPILib](https://docs.wpilib.org/en/stable/docs/software/hardware-apis/motors/wpi-drive-classes.html).
 Микширование не должно трактовать ток как заданный радиус поворота: ток
 связан с моментом, а скорость зависит от нагрузки. Нормализация, насыщение,
 знаки, нейтраль, движение назад и разворот на месте требуют явной модели и
 приёмки. Микшер и ограничения мощности — разные части системы.
 Штатное приложение PPM прошивки VESC 5.02 читает один импульсный вход.
 multi_esc пересылает ту же команду другим контроллерам, а не вычисляет
 дифференциальное управление из двух осей.
 [Исходник FW 5.02](https://github.com/vedderb/bldc/blob/5.02/applications/app_ppm.c).
 В официальном руководстве FS-i6S есть Mix (master/slave, положительный и
 отрицательный коэффициенты), сохранённые модели и просмотр каналов. Число
 доступных независимых миксов, назначение осей и поведение их композиции в
 имеющейся прошивке ещё не проверены. Наличие пункта Mix не доказывает
 возможность получить два требуемых выхода на нынешних CH2/CH3. Меню About
 показывает модель и версии. Failsafe=Off в руководстве означает удержание
 последнего значения; выключенный передатчик нельзя приравнивать к нейтрали
 без измерения выхода приёмника. [Руководство производителя](https://www.flysky-cn.com/s/FS-i6S-User-manual-20200628-al4y.pdf), разделы 6.9, 6.10, 7.2, 7.13.
 ## Где может исполняться профиль
 1. В пульте. Сначала проверить штатное микширование на экране каналов без
   команд моторам. Такой путь сохраняет независимость от Mini. Через два
   имеющихся PWM-провода Mission Core не может читать или менять модель
   передатчика: нельзя показывать локально сохранённый выбор как применённый.
 2. На Node. Нужен полный вход с осями и явным выбором управления, например
   через приёмник iBUS и совместимый интерфейс. Разъём iBUS есть у семейства
   FS-iA6B, но соответствующего подключения к Mini сейчас не подтверждено.
   Сначала проверить уровни, адаптер, формат и режим реального приёмника.
   Текущих двух вертикальных осей недостаточно для правого двухосевого стика.
 3. Во внешнем контроллере/микшере. Это технический вариант, а не принятое
   решение: владелец хочет обойтись существующим бортовым компьютером.
 Выбор пути зависит от наблюдаемой аппаратуры. Реализацию универсального
 переключателя нельзя завершить, скрыв эту зависимость. Не прошивать пульт или
 VESC и не переподключать каналы ради проверки гипотезы без отдельного плана.
 ## Наблюдение входа и приоритет пульта: существующая граница
 Текущий native backend уже читает через VESC Tool `COMM_GET_DECODED_PPM`:
 декодированный уровень и длительность последнего импульса одного входа VESC.
 Два USB-соединения дают два подключённых канала приёмника. Это не полный
 радиообмен передатчика с приёмником, не все оси/переключатели и не подтверждение
 радиолинка. Штатный PPM-код продолжает декодировать вход при временно отключённом
 выходе приложения. Прямые команды тока/ERPM через USB уже применялись в тестах;
 воспроизведение радиопакетов или подмена PWM-проводов для этого не нужны.
 По двум нейтральным значениям CH2/CH3 нельзя различить включённый передатчик
 с отпущенными стиками и выключенный передатчик при нейтральном failsafe.
 Положения SwA–SwD тоже не следует выводить из этих значений. Для перехвата по
 переключателю нужен проверенный соответствующий канал, доступный на борту;
 для перехвата по наличию радиолинка — подтверждённый признак валидности связи.
 Подключение полного потока приёмника к Mini пока не подтверждено. Если сама
 готовность включённого пульта означает ручной режим, автономия с включённым
 готовым пультом блокируется; это отличается от предыдущего сценария перехвата
 движением рычага. До выяснения реального сигнала не менять рабочую схему.
 В `motor_test.py` и `group_test.py` проверка входа выполняется до следующей
 подачи команды. Активный канал записывает состояние `rc`, прерывает тест и
 запрещает новый запуск до явного `vesc.control.release` после нейтрали.
 `receiver.py` использует свежую конфигурацию deadband каждого VESC, а не
 считает любой ненулевой шум командой. Это действующий код коротких стендовых
 тестов, не принятый постоянный арбитр автономного движения.
 Тесты временно приостанавливают выход PPM отдельными продлеваемыми арендами
 по 250 мс. Таймер исполняется в VESC: при прекращении продления PPM возвращается
 без участия Mini. Это защита от исчезновения процесса/USB, а не гарантия
 приоритета RC при ошибочной программе, продолжающей продлевать аренду. Также
 250 мс не являются измеренной максимальной задержкой перехвата всего ровера.
 Надёжный постоянный тракт требует проверки таймаутов, возврата RC, отсутствия
 поздних USB-команд и поведения всех назначенных сторон. Гарантия при ошибочной
 программе на живом Mini потребует независимого решения у исполнительного
 уровня; наличия такой гарантии в stock FW 5.02 не установлено.
 Штатные FOC/Hall-процедуры FW 5.02 не прерываются обычной командой пульта.
 Они остаются отдельным сервисным режимом вывешенного привода и не могут
 запускаться в автономном движении под обещание постоянного RC-перехвата.
 ## Контракт реализации в Mission Core
 - Один версионный профиль борта: режим, источник входа, проверенное назначение
  осей, стороны/UUID, параметры отклика и ссылка на отдельные пределы привода.
  Хранить желаемое и подтверждённое применённое состояние раздельно.
 - Общий интерфейс в существующем блоке через компоненты Design Guideline;
  калибровка конкретного двигателя остаётся в карточке VESC.
 - Смена профиля только после нейтрали всех назначенных сторон. При частичной
  потере связи запрещено объявлять общий профиль применённым.
 - Перехват пультом фиксируется до явного возврата управления. Нулевое значение
  PWM само по себе не определяет, выключен передатчик или стоит в нейтрали.
 - На Node должен быть один владелец выхода: все команды автоматики, клавиатуры,
  удалённого джойстика и другого управления проходят через него. Перехват RC
  отзывает их допуск и отменяет очередь; опоздавшая команда старого допуска
  не может вновь включить движение. Core отображает состояние, но не является
  звеном, необходимым для локального перехвата.
 - Потеря Core, Node, входного потока или одного VESC должна иметь проверенное
  поведение. Существующая аренда отключения PPM для коротких тестов не является
  приёмкой постоянного удалённого управления. Без Mini должен сохраняться
  понятный оператору независимый путь RC, а не внезапная смена смысла стиков.
 - Нативный VESC Tool остаётся владельцем протокола и конфигурации контроллеров;
  калибровочные алгоритмы не копируются в новый модуль профилей.
 ## Приёмка и порядок
 Node 0.8.38-2 установлен; Core принял оба VESC после исправления версии драйвера.
 1. Завершить диагностику существующего привода до установки гусениц:
   подтвердить связь и сохранить свежие конфигурации; отдельно сравнить Холлы
   левого и правого мотора без замены принятой калибровки. Перед процедурой
   заново синхронизироваться с наблюдающим владельцем. Если сигнал отсутствует,
   отделить неисправность проводки/датчика от недостаточности измерения.
   Повторная калибровка не восстанавливает физический контакт.
 2. После результата проверить оба направления, старт и остановку, затем
   поведение пульта при потере связи на вывешенном приводе. При необходимости
   уточнить нейтраль и failsafe через штатные средства. Дать отдельный вывод
   о готовности к ограниченной нагрузочной проверке; существующий ровный
   тест без нагрузки и исправный правый Hall не доказывают исправность левого.
 3. Для нового управления прочитать About, меню Mix, карту каналов и failsafe
   пульта без изменения рабочей модели. Проверить точную модель VESC и
 межконтроллерную связь. Недостающая модель не блокирует диагностику текущей
   версии, но блокирует обоснованный выбор новой прошивки.
 4. Выбрать штатный исполнитель перехвата с независимостью от Mini, подготовить
   версионную интеграцию и сначала проверить переходы без движения. LispBM
   остаётся кандидатом; обновление не является обязательным следующим шагом
   и не выполняется по одному имени 75_300_R2. Приёмка включает удержание
   первого жеста, нейтраль всех входов, второй жест, запоздалые команды,
   потерю Core/Mini/USB/связи между контроллерами и отсутствие самовозврата.
 5. Реализовать Tank/Arcade и общий профиль ограничений в существующих
   «Настройках борта», с индивидуальными пределами каждого привода. Выбрать
   место микширования по реально доступным каналам. Новые численные максимумы
   и запас 20% требуют характеристик моторов, VESC и общей батареи/BMS;
   приблизительные 500 Вт и имя аппаратной прошивки их не подтверждают.
 Испытание на гусеницах зависит от результата пунктов 1–2 и допустимых рабочих
 пределов, а не от завершения будущей автономии. Новый RC-перехват и Arcade
 проверяются на вывешенном приводе до проверки под нагрузкой.
 Уточнение владельца: идентифицировать контроллеры программно; разборка ровера
 ради чтения маркировки нежелательна и сейчас не требуется. В выполненном
 аудите через установленный native Tool оба контроллера подтвердили уникальные
 UUID, FW 5.02 / 75_300_R2, штатный тип VESC, test_firmware=0 и custom_configs=0.
 С каждого считаны полные motor/app-конфигурации (151/149 параметров), вход PPM
 и телеметрия. Оба штатных CAN ping дали пустой список: межконтроллерный обмен
 не подтверждён, но отсутствие физических проводов из этого не следует.
 USB-дескрипторы и USB-серийники одинаковы; идентичность по-прежнему задаёт
 UUID VESC. Новые резервные копии есть в истории Core и совпадают с принятыми
 архивами после калибровки. Движение и изменения настроек не выполнялись.
 Аппаратная сборка не определяет коммерческую модель: сам производитель
 [Flipsky описывает разные платы серии 75 на основе 75_300_R2](https://flipsky.net/blogs/vesc-tool/tips-of-75-serise-esc).
 Это подтверждение неоднозначности, не доказательство бренда имеющихся плат.
 Ни новый образ прошивки, ни паспортные пределы не выбираются по одному этому
 имени. Продолжить неразрушающую программную диагностику и использовать
 существующую комплектацию/документацию изготовителя ровера для свойств,
 которые текущий протокол не сообщает.
 Для выбранной реализации проверить нейтраль, прямое/обратное движение,
 повороты и крайние диагонали, одинаковую ограниченную реакцию сторон, переход
 между режимами в нейтрали, RC-перехват и отказ каждого канала связи. Сначала
 без движения (преобразование входов), затем на вывешенном приводе; нагрузочные
 испытания и настройка поворота на гусеницах — отдельный этап. Успешный тест
 без нагрузки не подтверждает старт под нагрузкой с повреждённым Холлом.
 ## Comparative Hall result, 2026-09-24 12:13 UTC
 Node 0.8.39-1 / plugin 0.6.6 completed both separate canonical measurements.
 LEFT again yields only [1,3,5,7] while the owner observes movement both ways;
 RIGHT yields [1,2,3,4,5,6] and firmware success. Both configurations are unchanged
 and current release is confirmed. Hall diagnostic localization is complete:
 LEFT circuit incomplete, RIGHT six-state signal accepted. Exact broken physical
 contact is not identified and no hardware repair is claimed. Sensorless LEFT
 versus Hall RIGHT operation remains. The owner next requests visible sustained
 rotation in both directions; this is a bench-test feature, separate from RC
 Tank/Arcade profiles and the stop → neutral → manual authority contract.
 ## Прототип во время отсутствия владельца
 По прямому запросу владельца подготовлены `packages/rover-control/src/profile.ts`
 и `authority.ts`: расчёт Tank/Arcade, UUID-назначения произвольного числа моторов,
 версионный JSON желаемого профиля и модель stop → neutral → manual. В production
 runtime они не подключены. 21 направленный тест проверяет знак и пределы
 смешивания, 2/4/10 моторов, первый/второй жест, непрерывную нейтраль, потерю
 любого привода/приёмника, устаревшие данные, часы, команды и допуски после reboot.
 Оси для перехвата объявляются отдельно от осей микшера: в макете даже второй
 рычаг останавливает Core в Arcade, а пропавшая ось не считается нейтралью.
 Отдельный макет `apps/control-station/tools/rover-control-preview` использует
 канонические контролы Design Guideline, показывает расчёт и сохраняет/выгружает
 черновик. Сеть запрещена CSP; никакого обращения к роверу или новой продуктовой
 вкладки нет. Пороговые времена в моделировании — синтетические, не приёмка
 времени остановки Rover006. Алгоритмы калибровки VESC Tool не копировались.
 Контракт и ограничения: [rover-control README](../../packages/rover-control/README.md).
 ## Текущий пульт: приёмка потери сигнала завершена
 2026-09-24 владелец прочитал Failsafe: CH1…CH10 показывают 0%. После отдельной
 проверки каждого мотора с удерживаемым рычагом и извлечением батарейки пульта
 владелец подтвердил остановку обоих. Возврат питания/радиосвязи с рычагами
 в центре не вызвал движения. Журналы, ограничения измерений и отличие от
 непринятого первого опыта записаны в [протоколе 24](24_RC_FAILSAFE_ACCEPTANCE.md).
 Рабочие конфигурации не менялись; это приёмка существующего прямого RC-пути,
 не новой логики перехвата. Можно продолжать чтение Functions → Mix и карты
 каналов. Подтверждение аппаратного исполнителя профилей в Core остаётся
 обязательным до их активации: один переключатель в UI не меняет проводку.
 ## Сохранённые настройки пульта: осмотр 2026-09-25
 Владелец последовательно прочитал и затем явно подтвердил весь список: всего
 четыре правила Mix, номера 1/3/4 выключены, только Mix 2 включён. Параметры
 Mix 2: Master C3, Slave C4, Offset 0%, NEG −100%, POS −100%. Это перечень
 правил внутри текущей модели, не четыре взаимоисключающих профиля ровера.
 Настройки не меняли. Назначение C4 в конструкции пока не установлено; по
 сообщённой проводке моторные входы подключены к CH2/CH3. Нельзя приписывать
 этому миксу управление вторым мотором без проверки всей карты каналов.
 Владелец прислал видеозапись меню продолжительностью около 74 секунд.
 Выполнен локальный визуальный разбор кадров; исходное видео не изменено,
 аудиодорожка не транскрибировалась. Закрытый manifest с SHA-256 исходника,
 методом разбора и кадрами хранится вне репозитория в
 `outputs/rover-006-tx-menu-review-20260925/manifest.json` корня рабочего пространства.
 Время ниже приблизительное, это не измерение задержки управления.
 | Экран | Наблюдение |
 | --- | --- |
 | Монитор каналов, 8–13 с | Полосы CH1…CH6, затем прокрутка. Отдельных движений осей с одновременным наблюдением каналов нет. |
 | Reverse, 21–23 с | CH9 — Rev; остальные показанные каналы CH1…CH10 — Nor. |
 | End points, 28 с | CH2: 100/110%; CH3: 110/100%, в порядке двух столбцов экрана. Это диапазон сигнала пульта, не проценты мощности или тока VESC. |
 | Subtrim, 33–36 с | Видимые значения 0%. |
 | Trims, 40–42 с | Off. |
 | Rate/Exp., 45–47 с | Только показанный CH1 Normal: Rate 100, Exp. 0. Значения других каналов не проверены. |
 | Rate/Exp. switch, 50–51 с | Assign SW: Null. |
 | Throt curve, 56–57 с | График визуально прямой; численные значения всех точек не открывались. |
 | Aux. channels, 60–62 с | Channel 5 назначен SwA. Назначения SwB/SwC/SwD ещё не прочитаны. |
 | Failsafe, 66–67 с | CH1…CH10 показывают 0%, согласуется с предыдущим чтением и принятой проверкой потери связи. |
 SWA → CH5 подтверждает назначаемую функцию переключателя в текущей модели,
 но не доступ Mini к этому каналу и не аварийную остановку. Монитор каналов
 найден; повторно искать его или перебирать Mix не требуется. Следующее чтение
 — системные Sticks Mode, Output Mode и About: установить раскладку, режим
 выхода и версию устройства без изменения модели. Фактическое соответствие
 осей выходам затем проверяется отдельно; этот ролик его не доказывает.
 Никаких команд аппаратуре или изменений приложения при разборе видео нет.
 ## Системные меню и идентификация пульта, 2026-09-25
 Вторая запись владельца, около 77 секунд, содержит экран About на 72–74 с:
 Flysky FS-i6S, версия 2.00, дата 04-Apr-2020, Hardware V_3.0. Идентификация
 пульта теперь опирается на его собственный экран, а не только на форму корпуса.
 Это не идентификация VESC и не повод обновлять прошивку пульта или моторов.
 Trainer Mode показан OFF, Switch Null; Student Mode показан OFF. Попытки
 открыть Output Mode (около 22 с) и Sticks Mode (около 25 с) останавливаются
 сообщением `Turn off RX!`. Значения режима выхода и раскладки рычагов не
 открылись, поэтому нельзя объявлять Mode 2 либо конкретный PWM/iBUS режим
 прочитанными. RX здесь означает приёмник; повторное нажатие OK при работающем
 приёмнике не раскрывает заблокированные настройки. Для чтения нужен штатно
 обесточенный приёмник при оставленном включённым передатчике, без изменения
 значений или обхода блокировки. Никакого отключения во время разбора не было.
 Закрытое подтверждение с SHA-256 исходника и пятью кадрами:
 `outputs/rover-006-tx-system-review-20260925/manifest.json` корня рабочего
 пространства. Видеофайл неизменён, аудио не транскрибировалось; просмотр кадров
 не является проверкой движения или записью конфигурации. Не запускать
 Sticks Adjust, Factory Reset, RX Bind или Firmware Update ради чтения профиля.
 ## Ограничение комплектации: без нового подключения приёмника, 2026-09-25
 Владелец явно исключил подключение FS-iA6B к Mini дополнительными проводами,
 адаптером или пайкой: таких средств нет, этот вариант сейчас неприемлем.
 Прямой вход iBUS/PPM в Mini не включать в обязательный текущий план. Он не
 нужен для уже доказанного управления VESC по USB: оба существующих тракта
 сохраняются — пульт → приёмник → моторный вход VESC и Mini → USB → VESC.
 Через VESC доступны два подключённых входных канала; полный поток остальных
 осей и переключателей от этого не появляется.
 Наличие двух рабочих путей не означает приёмку их одновременных конкурирующих
 команд. Нынешний код ограниченных тестов временно удерживает выход PPM,
 продолжает читать вход и прекращает тест при RC-команде. Это не готовая
 постоянная логика «первый жест — остановка, нейтраль, второй жест — ручное
 управление» с гарантией при отказе Mini. Требование владельца сохраняется;
 нельзя объявлять его выполненным либо обещать независимую гарантию только
 потому, что USB-команды и прямой пульт по отдельности проверены.
 Продолжать аудит штатного микшера пульта и исполнительных возможностей VESC
 в имеющейся комплектации. Реализуемость Arcade на существующих моторных
 выходах, переключение его из Mission Core и независимый перехват — отдельные
 вопросы. Чтение меню пульта не доказывает дистанционную запись его профиля.
 Если точное требование недостижимо в этой комплектации, описать конкретное
 ограничение владельцу, не подменяя задачу профилем только для команд Core.
 ## Разблокированные меню после отключения батареи, 2026-09-25
 Владелец прислал ещё две записи, около 66 и 32 секунд, с отключённой, по его
 сообщению, батареей ровера. Системные страницы теперь открываются. Прочитаны:
 - Models: Model 1.
 - Output Mode: выбран PWM; отдельный Serial: выбран i-BUS. Наличие выбранного
  i-BUS не означает подключение этой линии к Mini; существующие VESC получают
  отдельные каналы PWM. Проводка остаётся прежней.
 - Sticks Mode: первоначально M2; на 37-й секунде первого ролика видно
  переключение в M1, затем на 38–39-й — возврат в M2 до выхода со страницы.
 - Базовые назначения M2 до миксов: правый горизонтальный CH1, правый
  вертикальный CH2, левый вертикальный CH3, левый горизонтальный CH4.
  Включённый Mix 2 добавляет зависимость итогового CH4 от CH3; нельзя называть
  его выход независимым сырым значением левой горизонтальной оси.
 - Throt Mode: Self centering.
 Это подтверждает, что для правого Arcade требуются две оси CH1/CH2, тогда как
 нынешние моторные подключения CH2/CH3 дают два вертикальных канала. Прямые
 команды Mini по USB остаются доступным независимым путём. Штатное микширование
 нужно проверять по фактическим выходам CH2/CH3, включая подавление ненужной оси,
 знаки, нейтраль, насыщение и сохранение рабочего Tank. Руководство описывает
 парный Master/Slave, но не доказывает конкретный порядок каскадирования миксов
 и кривых; схему нельзя объявлять рабочей только по формуле или числу слотов.
 ### Новая проверка перед возвратом к движению
 На 48-й секунде первого ролика открыт Sticks Adjust. До конца записи нет
 полного прохода всех осей/крутилок по пределам; второй ролик начинается уже
 в обычном меню. Завершение процедуры между роликами не видно. По штатному
 руководству §7.8 это калибровка аналоговых органов пульта, с сохранением через
 выход после центрирования, а не обычный монитор каналов. Нельзя гарантировать
 неизменность калибровки или объявлять её испорченной по этим кадрам.
 Перед повторным включением силового питания нужен обычный монитор CH1…CH6
 с проверкой нейтрали и отдельных полных ходов осей при выключенных приводах.
 Это проверка пульта, не повторная FOC/Hall-калибровка VESC. Не использовать
 Sticks Adjust для чтения показаний и не запускать автоматический sweep.
 В первом ролике также кратко открыт RX Bind при выключенном, по сообщению
 владельца, приёмнике; результат привязки не проверялся. Во втором открыт
 диалог Factory Reset: нажата правая кнопка и выполнен возврат в меню; нет
 подтверждения выполненного сброса. Firmware Update просмотрен до страницы
 Continue, затем закрыт; обновление на записи не запускалось. Не превращать
 обход меню в утверждение, что все действия были только чтением.
 Закрытые оригинальные хэши, кадры и метод разбора:
 `outputs/rover-006-tx-offline-review-20260925/manifest.json` корня рабочего
 пространства. Оригиналы не изменены, аудио не транскрибировалось. Со стороны
 ассистента операций с пультом, Node или VESC при разборе не выполнялось.
 ## Проверка монитора каналов после Sticks Adjust, 2026-09-25
 Следующая запись владельца, `IMG_2491.MOV`, около 41 секунды, показывает
 обычный монитор CH1…CH6 и движения сначала левого, затем правого рычага.
 Оба используемых моторных канала проходят в положительную и отрицательную
 сторону: CH3 при вертикальном движении левого рычага, CH2 — правого. После
 возврата рычагов значения визуально близки к центру, с небольшими остаточными
 смещениями. Признаков застрявшего крайнего значения или отсутствующей половины
 хода этих двух каналов в записи нет. По полоскам нельзя измерить точные
 проценты, ширину PWM-импульса или подтвердить допустимую нейтраль на VESC.
 Горизонтальные движения изменяют CH4 слева и CH1 справа; часть правого
 горизонтального прохода затемнена/перекрыта рукой. Зависимость CH4 от
 вертикального CH3 имеет противоположный знак и соответствует ранее прочитанному
 Mix 2. Неподвижное пятно на поверхности экрана возле CH4 не является показанием
 канала. Это качественная проверка раскладки M2 и моторных выходов пульта,
 не приёмка Arcade, нового перехвата, радиосвязи или failsafe после изменения
 меню. Повторное обследование меню для установления этих назначений не требуется.
 Следующий шаг после подтверждённого владельцем возврата питания на вывешенном
 ровере с рычагами в центре — прочитать фактические уровни обоих входов через
 VESC и сравнить их с сохранённой мёртвой зоной, без команд вращения. Во время
 разбора этого видео силовое питание не включалось средствами ассистента,
 команды приводам не отправлялись, калибровка VESC не менялась.
 Закрытые хэш исходника, 11 кадров и метод разбора:
 `outputs/rover-006-tx-axis-review-20260925/manifest.json` корня рабочего
 пространства. Оригинал не изменён; аудио не транскрибировалось.
 Продолжение: владелец вернул питание, проверил движение от стиков, затем
 подтвердил нейтраль и физическую остановку обоих моторов. Чтение через VESC
 подтвердило уровни справа −0.06, слева +0.068…+0.07 внутри deadband ±0.15,
 нулевые duty/ток батареи и отсутствие ошибок. Motor/application конфигурации
 обоих контроллеров побайтно совпадают с сохранёнными 2026-09-24. Проверка
 нейтрали после просмотра меню закрыта; подробности и границы результата —
 в `24_RC_FAILSAFE_ACCEPTANCE.md`, раздел «Нейтраль после возврата питания».
 Профиль одного стика и постоянный перехват этим чтением не приняты.
@@ -0,0 +1,247 @@
 # Приёмка пульта и потери сигнала
 Состояние: оба моторных канала прошли наблюдаемый вывешенный тест остановки
 при потере питания передатчика. Восстановление связи с рычагами в нейтрали
 не вызвало движения. Точное время реакции и поведение под нагрузкой не измерены.
 Node 0.8.40-1, VESC plugin 0.6.7, FW 5.02.
 Калибровка и рабочие настройки не изменяются этим исследованием.
 Обновление 2026-09-25: после просмотра системных меню передатчика и захода
 в Sticks Adjust повторно проверены монитор каналов, физическая остановка по
 сообщению владельца и фактическая нейтраль на обоих VESC. Конфигурации VESC
 побайтно совпадают с исходными от 2026-09-24. Это не повторный тест потери
 радиосвязи после действий с меню пульта; его прежняя приёмка относится к
 описанным ниже испытаниям 2026-09-24.
 ## Начальное состояние, 2026-09-24
 Владелец подтвердил: пульт выключен, оба мотора неподвижны, гусеницы сняты,
 ровер вывешен. Свежая инвентаризация Core подтверждает два прежних UUID,
 нет активного теста или RC-защёлки. Через штатные операции сохранены обе
 конфигурации и прочитаны входы/телеметрия. Никаких команд движения, аренды
 выхода, alive, записи конфигурации или прямого доступа к serial не выполнялось.
 Оба контроллера: вход PPM около +0.010…+0.012 при deadband 0.15, PWM 0,
 ток батареи 0, fault 0. Правый показывает 0 ERPM. Левый при физическом
 покое показывает -153…-165 ERPM: ранее установленный дрейф бессенсорной
 оценки, не доказательство движения.
 Сохранённые настройки: duty-cycle PPM control; Safe Start включён; timeout
 1000 мс, timeout brake current 0 A; pulse 1.0/1.5/2.0 мс; multi_esc включён.
 Слева PPM, справа PPM+UART. Плавность слева 0.4 с набор / 0.2 с сброс,
 справа 0.5 / 0.5 с. Экспонента -1.0 слева и -1.5 справа. Из этого нельзя
 делать вывод о дефекте мотора или автоматически унифицировать настройки.
 ## Граница измерения
 Декодированный PPM в FW 5.02 сообщает последнее значение и длину импульса,
 но не возраст импульса и не состояние радиолинка. Нейтраль при выключенном
 передатчике сама по себе не доказывает failsafe: передатчик мог быть выключен
 после нейтрали, а приёмник мог удержать последнее значение.
 По исходникам pinned upstream 3f670137: при утрате импульсов PPM обработчик
 проверяет их возраст и тайм-аут, снимая тягу при timeout brake current 0.
 Это не активное торможение с заданным временем остановки. Если приёмник
 продолжает выдавать ненулевое последнее значение, тайм-аут VESC не решает
 потерю радио. Руководство FS-i6S 2020-06-28, раздел 6.10, описывает Off как
 удержание последнего значения. Точная модель/настройка имеющегося передатчика
 ещё требует проверки его экрана; внешний вид не достаточен.
 ## Порядок продолжения
 1. Включение пульта с обоими рычагами в нейтрали; чтение входов и наблюдение
   отсутствия самопроизвольного движения.
 2. Чтение About, Failsafe для CH2/CH3 и карты каналов на пульте; без изменения
   текущей модели. Если выявлено удержание последнего положения, сначала
   подготовить и проверить нейтральный failsafe через штатные средства.
 3. Под наблюдением владельца проверить отклонение/возврат каждого рычага,
   соответствие стороне и исчезновение команды в нейтрали.
 4. Отдельно согласовать выключение передатчика во время ограниченного
   движения, прочитать вход и состояние обоих VESC, получить физическое
   наблюдение остановки. Возвращать радиосвязь с рычагами в нейтрали.
 5. Проверить восстановление связи и отсутствие самопроизвольного движения.
 Чтение через отдельные удалённые операции даёт около 4.8 с на полный цикл
 двух входов и двух телеметрий в начальном замере. Такой журнал фиксирует
 состояния, но не позволяет подтвердить миллисекундную задержку остановки.
 Не выдавать USB-время ответа за время реакции радиоканала. При необходимости
 точного времени добавить продуктовую бортовую запись, не обходить драйвер.
 Исходный приватный протокол rc-failsafe-d83b84fb311245e5b8a3fea31716416b.json,
 SHA-256 8098fe14a754622cb027472fa4f48f96fa9ffcb0548b16af557ac90a56ea6fb1.
 Два полных цикла чтения, оба успешны. Наблюдатель rc_failsafe_observe.py
 разрешает только input.read, telemetry.read и config.backup.
 ## Уточнение наблюдения после включения пульта
 Протокол rc-failsafe-34b93f7184024d87a8e66327f2f60649.json был изначально
 помечен `tx-on-neutral-confirmed`, но во время чтения зарегистрированы
 отклонения входов и вращение правого. Владелец уточнил: «Двигал рычаги;
 сейчас оба стоят». Поэтому этот замер содержит ручное управление и **не**
 является ни доказательством самопроизвольного запуска, ни чистой проверкой
 включения в нейтрали. Исходная метка и сырой протокол сохранены неизменными.
 SHA-256: 26dd21ffae833b4ac13aa1ceb004b97a3b58de8ea4ded9856ec616a335744d4b.
 Следующее чтение rc-failsafe-ea478fad45c047db919f892c23a34dc2.json подтвердило:
 справа вход −0.064 / 1.468 мс, слева +0.074 / 1.537 мс; оба в текущей зоне
 нейтрали ±0.15. На обоих PWM 0, ток батареи 0, fault 0. Справа ERPM 0,
 слева −156 при подтверждённом физическом покое — известная бессенсорная
 оценка. Это не подтверждает исправность левого Холла и не измеряет failsafe.
 SHA-256: 6fe3cceeae8d1afc6116048df9079001a46a1f08a8813de4782ac7433d33dab8.
 Владелец отошёл на 15 минут и разрешил независимую разработку/прототипирование.
 Моторные испытания приостановлены до его возвращения и новой синхронизации.
 Вопрос о модели в About и текущем Failsafe CH2/CH3 остаётся без ответа;
 повторно спрашивать или самостоятельно менять настройки по догадке не нужно.
 ## Возвращение владельца
 Владелец сообщил: гусеница снята, пульт включён, он рядом и готов выполнять
 действия. Запрошено оставить рычаги в нейтрали и прочитать Failsafe CH2/CH3.
 До ответа выполнены только два цикла input.read/telemetry.read: справа вход
 −0.064…−0.066, слева +0.072…+0.074; оба в текущей зоне нейтрали. PWM и ток
 батареи 0, fault 0 на обоих; справа ERPM 0, слева −159…−151 (прежняя
 бессенсорная оценка, не отдельное подтверждение физического покоя).
 Протокол rc-failsafe-b05818b1cf8a426f8dccd5e6f80b19a5.json,
 SHA-256 511257aafc9d2f000d65073438399b9f7fa52c86515f4a7e994fd28b610737bb.
 Команд движения, alive, аренды выхода или записи конфигурации не было.
 ## Экран Failsafe и первый ручной тест потери сигнала
 Владелец открыл сенсорное меню Functions после разблокировки экрана и затем
 Failsafe. Сообщил: каналы CH1…CH10, везде 0%. По официальному руководству
 семейства FS-i6S числовая позиция означает заданное положение при потере
 радиосигнала, в отличие от Off/удержания последней команды. Отдельные
 настройки не изменялись. Модель/версия из About ещё не прочитана.
 Для проверки выдано задание: на вывешенном приводе с демонтированной
 гусеницей запустить правый мотор небольшим отклонением, выключить пульт до
 возврата рычага, затем отпустить его; сообщить наблюдение остановки. Если
 вращение продолжается — вернуть рычаги в нейтраль и восстановить пульт.
 Программа при этом только читала входы и телеметрию, 13 циклов за примерно
 60 секунд. Зафиксированы правый вход +0.254, 798 ERPM и PWM 0.051; затем
 PWM 0, 72 ERPM, и в последнем цикле вход −0.064, PWM 0, ERPM 0. Fault 0
 на обоих VESC. Пары input/telemetry снимаются последовательно, не синхронно.
 Протокол rc-failsafe-fe6aea514466484aad007568c9f90cc0.json,
 SHA-256 d1c471f855f80c1715578df0bfc0e69a8c517a7cc9c2cf1aeaa09ef61e37c9a9.
 Физический результат и факт выключения при удерживаемом ненулевом рычаге
 пока ожидаются от владельца. До этого переход нельзя объявлять принятым
 failsafe; USB-наблюдение не отличает потерю радиосвязи от отпускания стика.
 Никакого испытания левого канала или восстановления радиосвязи ещё не принято.
 Уточнение владельца к первому тесту: он **сначала отпустил рычаг**, затем
 вынул батарейку пульта. Поэтому этот опыт не подтверждает остановку из-за
 потери радиосвязи. После снятия питания передатчика отдельное чтение показало
 правый вход +0.010 / 1.504 мс, левый +0.012 / 1.506 мс; PWM и ток батареи 0,
 fault 0 на обоих, ERPM правого 0. Протокол
 rc-failsafe-f99b5bb25bff471dbe017ed0b8f4632b.json,
 SHA-256 4ade3d8a2061048c67b3e21a83304fd6a9cb832942189f6a08c29792a6984adc.
 Это подтверждение нейтрального выхода при выключенном пульте после нейтрали,
 а не проверка прекращения ненулевой команды. Запущена отдельная запись для
 повтора с явным удержанием рычага до физического отключения передатчика.
 ## Правый канал: остановка при потере радио подтверждена
 Повтор rc-failsafe-b208d87fa223496ca5fffebddf4ad9be.json, 25 полных циклов,
 2026-09-24T13:39:31.281029Z…13:41:33.274243Z,
 SHA-256 00e64109018c8b815b96b5db1e69fbb32ca7ab80bd8eff672f3ac86b69caffb1.
 После восстановления пульта вход правого вышел из нейтрали, зарегистрировано
 вращение. На цикле 11 вход +0.232 / 1.616 мс, 282 ERPM, PWM 0.022;
 на цикле 12 вход +0.010 / 1.505 мс, ERPM 0, PWM 0. Левый вход также
 вернулся к прежнему значению выключенного передатчика, PWM 0. Fault 0 везде.
 Владелец подтвердил: он вращал правым рычагом, вынул батарейку, и мотор
 остановился непосредственно при её извлечении. Это исправленный повтор
 предыдущего опыта с отпусканием рычага до отключения. Для правого канала
 поведение прекращения ручной тяги при потере радиосвязи принято в рамках
 этого вывешенного теста. Точная задержка в миллисекундах не измерена;
 нагрузочный тормозной путь и будущий stop-first перехват из Core не проверены.
 Следующий запуск записи для левого был случайно прерван владельцем. Проверено:
 нового протокола не создано, процессов rc_failsafe_observe.py не осталось.
 Команд движения не было. После возобновления запущен отдельный read-only
 протокол левого и выдана та же последовательность удержания рычага до
 отключения. Его результат пока ожидается; приёмка левого не следует из правого.
 ## Левый канал: физическая остановка подтверждена владельцем
 Протокол rc-failsafe-cc289f6fce514a21af66bf7c17117e59.json завершён,
 24 полных цикла; SHA-256
 64164b2083a1b28172ebe1471a7f59df88c1d10b085db6e204f7c60f81608d11.
 На цикле 8 левый вход +0.280 / 1.640 мс, ток мотора 2.39 A; на цикле 9
 вход +0.012 / 1.506 мс, ток 0.04 A. После отключения оба PWM нулевые,
 fault 0. Сама скорость вращения левого не попала в редкие последовательные
 USB-замеры; его отрицательный ERPM при PWM 0 нельзя трактовать как движение.
 На отдельный прямой вопрос «Левый мотор действительно крутился до извлечения
 батарейки и остановился именно после него, пока рычаг оставался отклонённым?»
 владелец ответил «Да, крутился и остановился после извлечения». На основании
 этого физического наблюдения и записи возврата входа в нейтраль поведение
 левого канала при потере радио принято для данного вывешенного теста.
 Точное время остановки, нагрузка и исправность Холла этим не подтверждаются.
 Далее запущена отдельная запись восстановления пульта в нейтрали обоих рычагов.
 ## Восстановление связи и итог
 Протокол rc-failsafe-6811a6865139462cb233566fb2bead05.json завершён,
 13 полных циклов; SHA-256
 c9d36bf24ca7ae43bb51bd7777c936e58ca44f3dd3d3b3b14126f6cf8717516f.
 В ходе записи входы перешли от значений выключенного пульта около +0.01
 к его включённой нейтрали: справа −0.062…−0.064, слева +0.076. PWM 0,
 ток батареи 0 и fault 0 на обоих во всех записанных циклах. Правый ERPM 0;
 слева прежняя ненулевая бессенсорная оценка при снятой тяге.
 Владелец подтвердил: после возврата батарейки, включения и ожидания около
 пяти секунд с рычагами по центру оба мотора остались полностью неподвижны.
 Приёмка текущего RC-пути в объёме стендового сценария завершена:
 ненулевая ручная команда → полное отключение передатчика → остановка отдельно
 справа и слева; затем восстановление связи в нейтрали без самопроизвольного
 движения. Источник физического результата — наблюдение владельца; журналы
 фиксируют входы/телеметрию с последовательным USB-опросом, а не точную задержку.
 Конфигурации и калибровка не изменялись, команды движения от Core не выдавались.
 Этот результат не принимает новый stop → neutral → manual перехват из
 автономии, отказ Mini/USB, поведение восстановления с отклонённым рычагом,
 нагрузочный тормозной путь или исправность повреждённой левой цепи Холла.
 Следующий этап — чтение текущих Mix/карты каналов пульта для Tank/Arcade,
 без изменения рабочего радиопрофиля по догадке.
 ## Нейтраль после возврата питания, 2026-09-25
 После видеопроверки монитора передатчика владелец вернул питание ровера и
 сообщил, что моторы вращаются от стиков. Перед чтением отдельно подтвердил:
 пульт включён, оба стика по центру, оба мотора полностью неподвижны. Через
 канонический Core выполнены config.backup обоих VESC и два последовательных
 цикла input.read / telemetry.read. Тестов вращения, аренды выхода, alive и
 записи конфигураций не было. Оба прежних UUID в свежей инвентаризации доступны,
 активных моторных тестов нет.
 | Измерение | Правый | Левый |
 | --- | --- | --- |
 | Уровень декодированного входа | −0.059999 | +0.068…+0.069999 |
 | Импульс | 1.470 мс | 1.534…1.535 мс |
 | Настроенная зона нейтрали | ±0.15 | ±0.15 |
 | Duty / ток батареи / fault | 0 / 0 / 0 | 0 / 0 / 0 |
 | ERPM | 0 | −162…−147 |
 Оба входа внутри мёртвой зоны. Ненулевая бессенсорная оценка ERPM слева при
 нулевом выходе и подтверждённом физическом покое не является вращением.
 Сырые показания тока мотора справа −0.55…−0.79 A, слева +0.09…+0.11 A;
 не подменять их утверждением, что все датчики показывали математический ноль.
 Проверка нейтрали завершена; изменение deadband или повторная калибровка VESC
 по этим результатам не требуется. Полный цикл чтения занимает около 6 секунд
 и не измеряет задержку перехвата.
 Прочитанные motor/application payload каждого контроллера побайтно равны
 исходным из протокола `rc-failsafe-d83b84fb311245e5b8a3fea31716416b.json`.
 Рабочая FOC-калибровка, режимы sensorless/Hall, направление, токовые пределы
 и настройки PPM сохранены. Это сравнение конфигураций VESC, не всей модели
 или внутренней калибровки передатчика.
 Приватный протокол `rc-failsafe-b79d96f465f94fcb881e48a536ea0cc7.json`,
 SHA-256 `c71b9c4b805f9b7a0909e8a26355297a831224997f7cb0fd908ce08bf88960eb`.
 Отдельный результат сравнения:
 `rc-neutral-comparison-b79d96f465f94fcb881e48a536ea0cc7.json` в той же закрытой
 папке `outputs/rover-006-vesc-context-20260923/native-probe`. Наблюдатель
 завершился штатно; постоянный процесс опроса не оставлен.
@@ -0,0 +1,545 @@
 # Observation and remote control — implementation record
 Owner request: 2026-09-25. Extend the existing per-vehicle observation center.
 The operator sees cameras, map, a vehicle model and per-controller telemetry,
 then explicitly takes keyboard/pointer control. Return goes to the vehicle list.
 ## Product surface decision
 Selected: two new layers in the admitted observation composition, with the model
 below the map and telemetry alongside it. Rejected: a separate driving workspace,
 which would separate the operator from cameras and duplicate vehicle navigation.
 No primary navigation or product root changes. Layer visibility/order/splits stay
 in the existing versioned per-vehicle layout. The header host owns the back action.
 States: offline, observing, preparing, ready, driving, receiver takeover, stopped,
 fault. Showing a model, pressing a key while disarmed, or reconnecting never arms
 motion. Stale telemetry is unavailable, not zero. No fabricated position/distance
 or model motion is inferred from keyboard intent.
 Design Guideline: existing Button/IconButton/Window/Select/Switch/LoadingRegion,
 SplitPane, GlassSurface and StatusBadge. Owner explicitly approved outlined
 momentary key buttons; shared KeyButton is added to DG first. Arcade W/S+A/D;
 tank Q/A left forward/reverse, E/D right forward/reverse. Space stops/disarms.
 ## Sources
 NodeDC source: `NODEDC_ENGINE_INFRA/nodedc-source/src/viewer/playcanvas/`.
 Copy the rendering implementation, DEFAULT_POSTFX and environment atlas with
 source hashes; keep lighting/postprocessing/grid shader settings unchanged.
 Vehicle export preserves immutable Blender originals. v021 is a two-scheme
 kinematic study, not the full rover; full reconstruction is v020. Owner explicitly selected v020. The export contains all 1,426 renderable
 objects, joined into four donor material groups without geometric decimation.
 ## Control boundary
 Existing five-second inventory/operation heartbeat is unsuitable for held keys.
 Implement a separate authenticated, ephemeral command channel on the already
 paired mTLS transport. Core does not access USB. The Node relays to its single
 VESC owner. Browser, relay and native output each have bounded leases; commands
 are identity/session/sequence bound and never persist or resume after restart.
 Motion command transport is distinct from configuration/calibration operations.
 Per-wheel current is measured motor current; battery input current is separate.
 Stock FW 5.02 resumes direct PPM when its output-disable lease expires. A healthy
 board can stop on RC intent and require neutral; a failed board cannot guarantee
 the full first-gesture-stop protocol against held RC input. This limitation must
 remain explicit in acceptance and cannot be fixed by UI promises.
 ## Validation — 2026-09-25
 Core lease tests: 13 passed. VESC driver: 127 tests passed, including eight
 remote-control tests (expired/duplicate frames, terminal stop, invalid bounds,
 RC first-gesture zero hold, reversal neutral interval, one-port failure and
 unconfirmed release). Native Tool adapter compiled and passed offline archive
 and output-denial checks on Mini; no hardware access during qualification.
 Control Station: architecture checks, typecheck, 939 unit tests and production
 build passed. The active operator checkout retains its unrelated simulation and
 AI polygon changes. Canonical 8000 was restarted through its existing launchd
 service, preserving configuration and operator data.
 Browser acceptance: back returns to the fleet list; full v020 visible; model
 selection persists across reload; Tank changes the key pad to Q/E/A/D; Arcade
 restores W/A/S/D; both layers appear in Available layers; hidden telemetry stays
 hidden after leaving/re-entering, then was restored. Pane maximize/restore keeps
 the scene and canvas sizes correctly. No arm or motion command sent.
 Export correction: initial exporter unintentionally included the original
 Blender scenes; visual QA found the studio floor obscuring the rover. Export is
 now limited to the active export scene and selected joined object, verified as
 one scene, one mesh, four donor materials (54,960,576-byte GLB). Immutable v020
 source is unchanged. All donor lighting/postprocess defaults remain unchanged;
 only asset URLs, responsive hosting and model framing adapt to Mission Core.
 Node 0.8.41-1 / VESC integration 0.7.0 qualification passed and the versioned
 owner installer completed on Mini. dpkg confirms 0.8.41-1; Node/VESC services
 are active. The paired fast channel supplies fresh RIGHT telemetry with no
 control session. LEFT is absent from Linux USB enumeration, while its UUID
 assignment remains intact; kernel descriptor errors -71 occurred at 11:18–11:19
 MSK, before the installer stopped the driver at 11:20:28. The owner confirms
 USB/power was reconnected during the work. This does not establish the physical
 cause; no USB reset or ad-hoc OS change was performed. The telemetry layer now
 retains missing assigned motors, explicitly shows no connection, and never
 substitutes another UUID or zero measurements.
 Hardware motion, actual channel latency and physical stopping require a fresh
 attended acceptance test. Offline tests do not qualify loaded driving or the
 Mini-independent stop-first RC behavior described above.
 Ship every Node runtime change in the versioned installer; no ad-hoc board edits.
 ### Owner power-cycle and first admission attempt
 At 11:35 MSK the owner disconnected/reconnected the battery. Both USB devices
 then enumerated and the existing runtime recovered both assigned UUIDs without
 an application restart or agent-issued port reset. Twenty read-only samples
 (10 seconds) all contained both fresh devices, no active control session.
 After fresh owner confirmation (tracks off, raised stationary rig, TX off,
 observing), one Core API trial was armed at 11:38:46 MSK. Initial preflight
 rejected sensorless duty=0.001; no forward command, output claim or temporary
 limit application was reached. This is not a keyboard or motion acceptance.
 Source investigation: pinned FW 5.02 mcpwm_foc.c, commit
 3f670137e27e6e383fa79c50cc6b1fa85aab1554, undriven branch lines 2550–2693,
 computes duty_now from measured phase voltages/back EMF even with no driven
 output. commands.c encodes this field with scale 1000. The earlier strict
 zero-duty assumption for observed sensorless standstill was therefore incorrect.
 The new bounded tolerance is one wire quantum, abs(duty)<=0.001, only for that
 already explicitly observed sensorless case. The other current, voltage,
 temperature, fault, input-current and stable-neutral checks remain in force.
 This is an admission bound, not proof of physical stopping or a motor rating.
 New regression verifies both signs of one quantum, rejection of two quanta and
 continued rejection of unobserved speed drift. All 128 VESC tests passed.
 Node 0.8.41-2 / VESC integration 0.7.1 passed qualification and was installed
 through the owner-authorized versioned installer at 12:08:23 MSK; no ad-hoc
 runtime patch and no automatic repeat of movement.
 The same follow-up separates terminal input-lease completion from hardware
 faults: normal session end reports stopped only after cleanup; unconfirmed
 release or restoration warnings remain fault. Regression drives the actual
 output loop through the session wrapper and verifies release of both outputs.
 The preceding qualification completed, but its package was superseded before
 installation to include this correction in one owner update. Final VESC suite: 130 tests passed.
 Post-install verification: both services active, installed runtime 0.7.1, both
 assigned controller UUIDs fresh after observation refresh (14–205 ms), zero
 currents/duty/fault codes and no control session. Fresh owner observation is
 required for the next attended API trial; physical keyboard/RC acceptance remains pending.
 ### Attended retry and channel diagnostics
 At 12:18:51 MSK, the helper rejected cached device samples before sending arm.
 Read-only refresh restored both fresh UUIDs. The one armed trial at 12:19:28
 remained in preparing for about five seconds, then ended stopped before the
 helper ever sent forward demand. The browser-to-Core zero-demand heartbeat
 continued every approximately 100 ms. No service restart occurred. The current
 evidence does not distinguish a Core transport failure from a Node scheduling
 gap; it does not establish a new USB failure.
 Node 0.8.41-3 adds a bounded 32-frame in-memory channel diagnostic recorder,
 flushed to the private service journal on session transitions, transport errors
 or long gaps during a session. It records monotonic intervals, binding wait,
 Core/driver elapsed times, sequence/remaining TTL and state. It excludes trust
 material, endpoints, request bodies and raw HTTP error text. Admission, timeout,
 lease and motor-output behavior are unchanged. Qualification/installation is
 pending; no automatic physical retry.
 Node 0.8.41-3 installation completed successfully at 09:36:34 UTC in 18 seconds
 after owner-local Ubuntu authorization. Package version and active Node/VESC
 services verified. Both assigned UUIDs produce fresh readings (190/199 ms),
 zero motor current and fault codes; no control session. Owner observation is
 requested again before one bounded repeat; no motor output sent after the
 12:19 preparation abort.
 ### Recorded channel timing and operator TCP correction
 The attended 12:38:43 MSK retry again ended in preparation without forward
 demand. The new journal localizes the failure to the Core/Node transport budget:
 Core round trips commonly took 100–270 ms, driver calls 1–3 ms and initial
 binding-lock waits zero. One response explicitly expired in transit; another
 response body exceeded the 300 ms HTTP deadline. The first inferred consecutive
 command arrival gap was already greater than its remaining lease. No service
 restart occurred. This does not establish an electrical or USB fault.
 Read-only Tailscale checks confirmed DERP(hel) relay rather than a direct path.
 Five Tailscale probes: 42–120 ms; five ICMP probes: 42.8–157.5 ms, zero loss.
 No VPN, route, firewall or onboard OS settings were changed. Private network
 inventory is retained only in the private evidence directory.
 The paired Core HTTP handler used the standard TCP Nagle default while writing
 small response headers and JSON separately. Enabled its supported
 disable_nagle_algorithm option (TCP_NODELAY) to remove an avoidable buffering
 source; this does not change authentication, TTLs or output limits. All 52
 Fleet tests passed. Promoted the same narrow change to the active operator
 checkout and restarted its existing launchd service only after verifying no
 active motor session. Canonical 8000 and both fresh controller readings recovered.
 Whether this is sufficient for the current relay path still requires attended
 acceptance; no automatic motion retry.
 The 12:46:39 MSK attended retry disproved sufficiency: responses improved to
 47–70 ms at times but still reached 166 ms, and preparation ended before any
 forward command. Four armed remote-channel attempts have now failed in
 preparation; none is a motion acceptance. Subsequent motor trials are paused
 while the command delivery mechanism is corrected.
 ### Node 0.8.42: independent command stream (qualification pending)
 The paired Core endpoint now offers an authenticated NDJSON response containing
 the latest command every 50 ms. Telemetry remains a separate request/response
 channel. Certificate, binding and endpoint revision are checked on every frame.
 No command queue is introduced. Legacy Node clients retain their existing
 exchange response; new clients consume commands only from the stream.
 Core attaches a random process clock epoch and an absolute monotonic expiry to
 each command. Node estimates a conservative upper bound on Core clock offset
 using request-send time and the timestamp taken afterward at Core. It never
 assumes symmetric network latency or synchronized wall clocks. A 5 ms margin,
 1000 ppm clock-rate allowance and 25 ms private driver-call reserve reduce the
 remaining lease. The original 400 ms deadline is not extended on receipt or
 repeated frames. Clock calibration expires after two seconds; loss of return
 telemetry retires the Core session after one second. These are software timing
 bounds, not hard-real-time or field-safety certification.
 A separate local 20 Hz loop feeds only the latest unexpired intent to the
 single VESC owner. Stream silence cancels its network read after 350 ms;
 disconnect, epoch change, binding change or failed local RPC requires an
 acknowledged null command before accepting further frames. An interrupted
 session remains retired in the existing native-driver lease and cannot resume
 on reconnection. The C++ output watchdog (200 ms), PPM suppression lease
 (250 ms), firmware, calibration and output limits are unchanged.
 Qualification covers asymmetric delay, measured relay jitter, original expiry,
 replayed frames, stop-ack races, old clock epochs, stale calibration, silent
 HTTP streams, multiple frames per response and binding revocation midstream.
 Physical API motion, keyboard release/blur and RC takeover acceptance remain
 pending and require fresh owner observation after installation.
 Node 0.8.42-1 installed successfully at 10:22:27 UTC. Forty read-only samples
 over ten seconds showed observing/no active session; the last twenty contained
 both assigned controllers with ages at most 217 ms, zero current and fault.
 The freshly authorized 13:25:53 MSK API trial still ended during preparation,
 without forward demand. Unlike the previous transport, the local driver loop
 held 50–51 ms intervals and 1–3 ms responses; no stream disconnect was logged.
 In the retained timeline sequence 26 had about 29 ms remaining at local time
 218304 ms; sequence 28 reached the driver at 218355 ms. This is consistent
 with an expired previous lease despite delivery of a subsequently fresh frame.
 The driver correctly does not revive such a session. It is not evidence of a
 new USB fault or accepted movement.
 Follow-up 0.8.42-2 removes periodic-tick waiting for new intent at both ends:
 Core condition notification wakes the stream immediately on accepted input or
 stop; Node uses a one-slot wake signal and always reads the latest intent.
 The 50 ms periodic tick remains a fallback, not an input queue. Tests cover
 updates before/during wait, immediate stop, coalescing and unchanged replay.
 Original 400 ms expiry, output watchdog and current limits remain unchanged.
 The private diagnostic history expands to 128 frames, and terminal telemetry
 no longer triggers idle journal spam solely because it retains a session ID.
 Core tests: 59 passed. This follow-up requires qualification and installation
 before a separately synchronized physical retry.
 Owner OS authorization completed: final 0.8.42-2 installed at 10:47:29 UTC
 in 18.67 seconds, all installer steps exit 0; Node and VESC services active.
 Forty read-only samples over ten seconds confirmed observing/no active session.
 The final twenty contained both assigned controllers, at most 216 ms old,
 with zero motor/input current, duty and fault. Fresh owner observation has
 been requested before any new motion; the five previous failed preparation
 attempts remain failures, not movement acceptance.
 Sixth attended Core API attempt, 10:52:51 UTC, stopped before forward demand:
 "another VESC operation is running". Recorded command TTL remained 323 ms,
 so this particular failure is different from the preceding lease expiry.
 The remote observer shares operation_lock; _prepare previously attempted
 nonblocking acquisition and treated any overlapping read as a fatal conflict.
 The trace does not identify which operation held the lock; code and a
 concurrent regression reproduce this admission race without hardware.
 Candidate Node 0.8.43-1 / VESC 0.7.2 waits up to 500 ms for exclusive access,
 checks the existing input lease every 20 ms and after acquisition, and skips
 new observer cycles while the control worker is alive. It does not queue a
 future drive or extend the input lease. Tests cover completing an in-flight
 read, Stop while waiting, expiry before acquisition, bounded rejection of a
 long operation, and observer yielding. Canonical unittest discovery passes
 135 tests. A first full pytest invocation incorrectly collected the imported
 protocol helper test_packet as a fixture-based test; no product failure was
 reported, and the suite was rerun with its canonical unittest runner.
 Installation and a separately synchronized physical retry are pending.
 Node 0.8.43-1 / VESC 0.7.2 installed at 11:06:32 UTC in 18.49 s,
 all installer steps exit 0. Both services active; final 20/40 read-only
 samples contained both assigned UUIDs, age <=219 ms, zero currents/faults,
 observing/no control session. A fresh attended trial is requested separately.
 Seventh observed Core API attempt at 11:10:39 UTC reached preparing without
 the ownership fault, then stopped before forward demand. Sequence 19 arrived
 with ~313 ms remaining; sequence 20 followed ~315 ms later, consistent with
 expiry at this boundary. The old trial sent a command, synchronously fetched
 telemetry and only then scheduled its next input. Telemetry reads introduced
 periodic delays up to ~319 ms in its sample cadence. This differs from the UI,
 where the command heartbeat and telemetry poll are independent.
 The corrected attended_stream_test.py separates bounded telemetry polling
 from 100 ms command renewal, preserves the same 400 ms lease and all existing
 preflight/stop checks, and records request timing for every command. Synthetic
 checks prove blocked reads do not hold the input path, failures abort and
 reader threads terminate. This is a test-harness correction, not movement
 acceptance or proof that all transport jitter is solved. A fresh observed
 trial is requested; there is no automatic motion retry.
 Core-only timing logs were added to distinguish registry wait, archive and
 save delay. All 59 Fleet tests pass; loopback HTTP test needed sandbox network
 permission. The active Core received only this reviewed registry.py diff and
 was restarted without an active session. Read-only samples: max local GET
 179.8 ms, three of forty above 100 ms; retained registry waits 25.9–58.5 ms.
 No archive/save delay above 25 ms was reported in the initial capture. Thus a
 registry persistence bottleneck is not yet established by these measurements.
 Eighth observed trial at 11:22:27 UTC still stopped before forward demand.
 Independent input recording showed local Core command POST outliers 103.4,
 166.5, 216.1 and 127.4 ms (normally 2–10 ms). Sequence 17 reached Node with
 312.7 ms remaining; sequence 19 followed after 335 ms. Separating trial
 telemetry therefore did not by itself solve the delivery problem.
 A bounded read-only macOS sample of the operator Core found JSON encoding and
 zlib work on its ASGI main thread. The periodically polled completed planning
 report /api/v1/mission-planner/live-tests/active is 2,403,591 bytes and took
 218.5 ms for one local GET. Its endpoint fetched the dict in a worker, but
 FastAPI recursively encoded it and the middleware compressed it on the event
 loop. This shared process also admits rover commands.
 planning_live_api.py now constructs the JSON response and optional gzip body
 in the existing thread pool, preserving the full report contract and bypassing
 second compression through Content-Encoding. No polling is disabled, evidence
 is not removed, and Node, calibration, current limits and leases are unchanged.
 13 focused tests passed against development and active Core: JSON/gzip execute
 off-loop, exact content survives decompression, empty/failure contracts and
 existing planning presentation/compression behavior remain valid. Canonical
 8000 was restarted without active control. Sixty ordinary read-only rover
 samples over 15 seconds then had max 86.1 ms, p95 64.5 ms and zero over 100 ms;
 both assigned UUIDs fresh, currents/faults zero. This improves measured delay,
 but does not yet establish motion or field acceptance. A fresh observed retry
 is requested separately. Private process samples and device traces stay out
 of normal Git.
 Ninth attended Core API trial at 11:31:08 UTC passed preparation and completed
 8 seconds of forward demand at up to 2000 ERPM, with a 30 A ceiling per motor.
 The owner confirmed both motors physically rotated forward and subsequently
 confirmed both stopped. Final state stopped, release_confirmed=true, zero
 motor/input current and fault. Recorded peaks: left 2001 ERPM / 2.88 A motor,
 right 2028 ERPM / 2.81 A motor; these are sampled peaks, not current ceilings.
 During driving device ages stayed <=104 ms, all recorded fault codes zero.
 Preparation retained old motor samples up to 10.1 s while exclusive setup ran;
 those samples are not treated as live motion telemetry. Command POST max
 81.28 ms, p95 10.05 ms across 201 requests. The normal stop command was accepted.
 This accepts the observed API forward/release path on Node 0.8.43-1 / VESC
 0.7.2 and the corrected operator Core. It does not accept physical keyboard
 input, Stop/blur, channel loss, RC takeover, loaded or field operation. Those
 remain separate checks. No new calibration, firmware, USB reset or OS change
 was performed for this trial. Private raw evidence and owner notes are hashed
 in the experiment manifest; the previous eight preparation failures remain
 recorded as failures.
 At 11:38–11:39 UTC the owner physically held W in the 3D View after UI arming,
 then released it. Owner reports both motors forward, immediate perceived stop
 on release and approximately 0.5–1 s before initial motion. Exact key-event
 latency was not instrumented and is not claimed resolved. Read-only capture:
 393 samples, no request errors; driving observed for about 10 s (the requested
 hold was approximately 8 s). Sampled peaks left 2004 ERPM / 3.51 A, right
 2032 ERPM / 2.85 A; driving sample age <=113 ms, all faults zero. Release
 returned to ready with motors stopped; the UI Stop action then reached stopped,
 release_confirmed=true. Final UI explicitly says control disabled. The read-only
 recorder exited and no motion input remained active.
 This accepts actual W forward/release, separately from the prior API trial.
 Reverse/turns/Tank, Stop while moving/blur, channel-loss and RC takeover remain
 unaccepted on the new UI path. Owner startup-delay observation is retained
 for a separately instrumented check. No hardware limits or calibration changed.
 MISSIONCOR-85 now records both successful trials, their limits and the previous
 operator event-loop diagnosis while preserving all hardware/Hall history.
 Observed S/A/D session, 11:45–11:47 UTC: the owner confirmed reverse on S
 and opposite sides on A (left reverse, right forward); also reports D worked
 before the agent disabled control. The telemetry records both opposite-side
 patterns with neutral intervals. Final state stopped, release_confirmed=true.
 The owner reports a repeatable approximately two-second start delay, with
 immediate perceived release. This blocks completion of drive-response acceptance.
 Root cause in the remote output loop: it ramps the speed setpoint from zero
 at 600 ERPM/s. Both saved configurations have s_pid_min_erpm=900. Pinned
 upstream bldc mcpwm_foc.c (3f670137e27e6e383fa79c50cc6b1fa85aab1554) forces
 zero duty and resets speed-PID state for targets below that threshold. The
 result is 1.5 s of ineffective commands on each start, plus the retained
 0.5 s undriven interval when changing direction. Recorded telemetry already
 says driving while the rotor remains stopped, consistent with this mechanism.
 This delay is downstream of command admission; the exact key-to-node timing
 was not captured and no claim of zero network delay is made.
 Candidate Node 0.8.44-1 / VESC 0.7.3 starts the remote speed request at each
 controller's own read-back minimum PID speed (rounded up for native integer
 setRpm), then ramps at the existing rate above it. It does not change the
 firmware threshold, motor configuration or current ceiling. Subthreshold
 analogue requests release instead of being amplified above the request;
 invalid/unreachable thresholds reject before output claim. Zero input still
 releases immediately; expiry, RC takeover and the reversal dwell remain.
 Synthetic tests cover distinct thresholds including fractional serialization,
 first-cycle output, ramp above the threshold, turn signs, subthreshold input,
 immediate release and invalid thresholds. Physical response after installation
 requires a new observed trial; this candidate is not yet installed.
 0.8.44-1 qualification completed: all 18 Ubuntu stages succeeded in 268.87 s,
 including 140 VESC tests, Go race checks and Node UI. Source 1b1be6ef5913fd3740a11c69;
 package SHA-256 46cae05efa621a2636251f69ab8071ff4e18db67f23203eab396a71f0ef0972b.
 Owner installer bf270c06ae6d1e598e963756 launched in the local Ubuntu session.
 APT simulation changes only mission-core-node 0.8.43-1 -> 0.8.44-1, with no
 added or removed packages. Before launch Core showed stopped, release confirmed,
 both currents/ERPM/faults zero. Local OS authorization is pending; launch is
 not evidence of installation or an accepted new motor response.
 Owner authorization completed: 0.8.44-1 installed at 12:01:17 UTC in 18.56 s,
 all installer steps exit 0; Node and VESC services active. Twenty read-only
 samples captured after installation, final sample both assigned controllers
 fresh (53/63 ms), ERPM/current/fault zero and no active control. Fresh owner
 observation requested for W start/release; improved physical response is not
 yet accepted.
 Post-0.8.44-1 owner keyboard series at 12:05–12:06 UTC included repeated
 forward/reverse and both turn patterns. Owner reports delay approximately
 halved, forward-to-reverse works, but one side sometimes starts sooner.
 Read-only recording: 947 samples, no errors, all faults zero; 23 driving
 segments. First side above 300 ERPM in the same sample or 0.25–0.51 s later;
 both sides by 0–0.76 s. These are state-relative samples, not key-event timing.
 The four-minute recorder ended at ready; a separately saved final snapshot
 confirms stopped/release_confirmed, both ERPM and currents zero after UI Stop.
 Sampled peaks left 2007 ERPM / 5.04 A, right 2025 ERPM / 3.32 A.
 Asymmetry diagnosis: after a turn, the remote code held only the reversing
 motor for its 0.5 s neutral interval, while the other side immediately drove
 the new command. Trace 12:05:39 (turn -> forward): right above 300 ERPM in the
 first driving sample, left +0.763 s. The mirror transition at 12:05:33 had
 left first, right +0.511 s. This is a software coordination defect, not evidence
 that all smaller differences arise from the broken left Hall circuit.
 Candidate Node 0.8.45-1 / VESC 0.7.4 uses one reversal barrier for the entire
 assigned drive group. If any side reverses, all outputs release until all
 motors have been observed quiet and undriven for 0.5 s, then the current
 latest targets start in the same output cycle. Already observed neutral time
 counts; no extra dwell is added after a sufficiently long released pause.
 Cancelled/replaced direction requests are not queued. The per-controller PID
 threshold correction, speed ramp, immediate zero, current caps, expiry and RC
 priority remain. Synthetic regressions cover turn->straight synchronization,
 a slower coasting companion, counting an existing neutral pause and cancelling
 a pending reversal. Installed software remains 0.8.44-1 pending qualification
 and owner installation of this separate candidate.
 0.8.45-1 / VESC 0.7.4 passed all 18 Ubuntu qualification stages in 267.11 s,
 including 144 VESC tests. Source d31a8b586b9a600a2a8e61b3; package SHA-256
 af412c607fec9b34aba0af0e8e67614cd6f4d373fb641d7202341fea30be9ba1.
 Installer f1a8a72c4a1a7efc4aeebedd launched in Ubuntu. Its APT plan upgrades
 only mission-core-node 0.8.44-1 -> 0.8.45-1; no added/removed packages.
 Before launch both controllers had zero ERPM/current/fault, control stopped,
 release confirmed. OS authorization and new physical acceptance are pending.
 0.8.45-1 installed at 12:23:15 UTC after owner OS authorization, 18.56 s,
 all steps exit 0. Node and VESC services active. Twenty read-only samples;
 final both assigned UUIDs fresh (115/124 ms), zero ERPM/current/fault and
 no control session. Fresh owner observation requested for turn->forward
 transitions; physical synchrony and remaining control/RC acceptance pending.
 Observed 0.8.45-1 keyboard trial, 12:32–12:34 UTC: 545 read-only samples,
 no read errors, fault codes zero, driving sample age <=105 ms. Twelve driving
 segments; both sides above 300 ERPM in the same sample or within one 0.25 s
 sample. Peaks left/right 2014/2043 ERPM and 4.35/3.24 A. Owner reports responsive
 forward/reverse/turns. This is coarse telemetry, not exact key-to-output timing.
 CRITICAL physical acceptance failure: owner reports D continued after leaving
 the browser and releasing the physical key; later clicks recovered it. The
 trace contains prolonged D segments (22.82 and 20.56 s), but browser focus/key
 source events were not recorded, so exact focus-loss latency is unknown.
 Agent ended control through UI; stopped/release_confirmed=true and both motors
 zero ERPM/current/fault. Remote-control acceptance remains blocked by this defect.
 The UI already subscribed to blur/pagehide/visibility events. Its 100 ms
 command sender nevertheless renewed a remembered nonzero demand without a
 focus or input-freshness check; a missed browser-host event could hold it
 indefinitely. Fix uses a core-owned held-input binding, capture listeners,
 50 ms focus polling, and a guard checked at every command heartbeat. A key
 requires a fresh trusted press, then OS-repeat evidence: <=1000 ms initially,
 <=300 ms after a repeat. This fallback bounds a lost keyup even if the host
 also misses focus events. Focus loss/expiry clears all held states and disarms;
 returning focus or delivering a late repeat cannot resume movement. Continuous
 keyboard control therefore requires OS repeat within those bounds; this is
 not a global-background keyboard implementation. Pointer up/cancel/capture-loss
 and component disposal release held state. No onboard install or firmware/config
 change belongs to this UI fix. Physical focus-loss re-test remains pending.
 Owner follow-up after the first focus fix: movement now stops on focus loss,
 but terminating the control session is explicitly rejected. New required
 behavior is neutral hold with the current healthy control session preserved;
 returning focus requires a new physical press, not another arm/preparation.
 The implementation now separates input pause (clear held input, send zero,
 keep session) from explicit Stop/pagehide/unmount/fault (end session). Guards
 still run before every send; old demand is never restored on focus return.
 The periodic neutral messages maintain the session only while communication
 remains healthy. Actual background suspension/channel expiry is still a stop,
 not permission to extend the motion watchdog. Continuous keyboard holds still
 require OS repeat evidence within the bounded input lease.
 Preparation now hides key controls and renders the existing canonical warning
 StatusBadge as Подготовка управления; readiness alone admits the green state
 and key controls. Initial focus-fix physical evidence confirms stopping but
 not the requested session-preserving behavior. Revised physical test pending.
 Final revised UI qualification: 934 unit tests, architecture checks, TypeScript
 and production build pass. Canonical Core serves the exact new index/assets;
 no Node/OS/firmware change. Browser verified amber Подготовка управления with
 keys absent until ready. Owner observed the revised trial and confirmed:
 focus loss stops motors, returning allows a fresh press without another arm
 or preparation. One active session persisted throughout all six short driving
 segments. Explicit UI Stop after completion ended the session; final fresh
 telemetry confirms stopped/release_confirmed=true, both ERPM/current/fault zero.
 The private result includes UTC/monotonic traces, owner notes and SHA-256.
 This accepts focus loss/resume on the observed host. Tank, explicit Stop while
 moving, command-channel loss, RC takeover and loaded/field behavior remain
 separate outstanding physical checks. No exact key-to-stop timing is claimed.
 Startup-entry follow-up, 2026-09-25: owner reports silently disabled Manage
 and intermittent first-arm failure on a fresh Core page. The outer button
 previously depended on fresh/supported status without explaining the wait.
 A reproduced hook race allowed a poll begun during POST /arm to return the
 old controlling=false state after the arm acknowledgement and revoke the new
 session. The error path had the same missing generation guard; repeated arm
 calls before acknowledgement also escaped the session-only check. Three new
 regressions failed before the fix; actual current-generation authority loss
 already passed and must continue to end control.
 The acknowledgement now retires pre-acknowledgement reads; poll success and
 failure require the current generation. An in-flight arm guard prevents
 duplicate submission. Status reads may wait 1000 ms; command/arm 350 ms
 deadlines and all board motion watchdogs remain unchanged. Manage always
 opens settings, while actual arm waits for fresh supported idle authority.
 The dialog remains open on failed arm. Canonical amber status distinguishes
 synchronization, preparation, unavailable data and previous-session cleanup;
 ready alone shows green and motion keys. Title is now exactly
 «Центр наблюдения и управления». No board install/configuration change.
 Validation: 938 unit tests, architecture check, TypeScript and production
 build passed; final copy/color adjustment rechecked with 22 focused tests
 and production build. Fresh browser entry acquired control on its first click.
 13:20:28–13:20:38 UTC preparation was visible, then ready; no motion input
 was sent. Explicit UI Stop completed at 13:21:09 UTC, release confirmed.
 307 read-only samples, no read errors, all ERPM and fault codes zero.
 A subsequent page reload and settings reopen also passed. These are bounded
 UI/lifecycle checks, not new acceptance of driving or RC takeover. Private
 entry-startup-result.json contains UTC/monotonic evidence and SHA-256 hashes.
@@ -0,0 +1,75 @@
 # Rover 006: инженерный SSH и административные действия
 Проверено 23.09.2026 около 11:02 UTC. Источник: живой paired inventory Core,
 Tailscale, сравнение SSH host key с ранее доверенной записью и успешный SSH.
 ## Проверенный путь
 Текущий Ubuntu Mission Core Node и исторический Device Edge — разные записи
 доступа. Для текущего борта подтверждён пользователь **`dcsudo`** и основной
 персональный ключ оператора `~/.ssh/id_ed25519`. Приватный ключ не копируется.
 Обычный вход работает с `BatchMode=yes`, без ввода пароля и без `sudo`.
 Сохранённый в операторском `~/.ssh/config` alias `nodedc-edge` относится к
 прежней записи с пользователем `ndcsudo` и старым LAN-адресом. Он не является
 источником адреса/пользователя нынешнего Rover 006. Не менять его вслепую:
 другие задачи могут использовать историческую запись.
 На текущем операторском Mac создан и проверен отдельный приватный профиль:
 `/Users/dcconstructions/Downloads/mnt/NODEDC/outputs/rover-006-vesc-context-20260923/ssh-config`
 Он выбирает `rover-006`, актуальное MagicDNS-имя, `dcsudo`, персональный ключ,
 `IdentitiesOnly=yes`, `BatchMode=yes`, `StrictHostKeyChecking=yes` и прежнюю
 доверенную запись через `HostKeyAlias`. Команда проверки:
 ```sh
 ssh -F /Users/dcconstructions/Downloads/mnt/NODEDC/outputs/rover-006-vesc-context-20260923/ssh-config rover-006 'id -un; hostname'
 ```
 Адреса, полный host-key fingerprint и USB-идентификаторы не включаются в
 переносимую документацию. Приватный профиль не содержит пароля или содержимого
 ключа. Его отсутствие на другом Mac не означает отказ борта.
 ## Как восстанавливать контекст
 1. Прочитать MISSIONCOR-76 и последнее дополнение об инженерном доступе.
 2. Проверить `GET http://127.0.0.1:8000/api/v1/fleet`: выбрать именно сопряжённый
   Rover 006, проверить свежесть inventory, hostname, node identity и адреса.
 3. Сопоставить эту машину с текущим Tailscale peer. Worker 006 и старый Device
   Edge не являются бортом. Не сканировать подсеть.
 4. Использовать проверенный профиль. При новом адресе сначала сравнить ключ с
   известной доверенной записью. `ssh-keyscan` сам по себе не устанавливает
   доверие; 23.09 ключ совпал побайтово с ранее сохранённым ключом Ubuntu Mini.
 5. Если получен `Permission denied`, проверить **пользователя и выбранный ключ**
   до обсуждения пароля/sudo. Не подбирать аккаунты, не сбрасывать ключи и не
   выключать host-key checking. Если доказанного пути нет, использовать
   существующий GUI Node «Система → SSH · доверенные устройства».
 Sandbox `Operation not permitted` и отказ запуска локального Tailscale CLI
 не доказывают сетевой отказ. Повторить конкретное read-only действие с
 разрешением инструмента, не менять маршруты и VPN на основании такой ошибки.
 ## SSH не равен sudo
 Подтверждение владельцем пароля на экране Mini относится к административному
 действию Ubuntu/установщика. Оно не требуется для обычного инженерного чтения.
 Успешный SSH и членство в группе sudo не доказывают беспарольное повышение прав.
 Установка и изменения runtime выполняются штатным versioned installer/profile.
 Если такой шаг требует системного подтверждения, сначала подготовить точный
 артефакт и объяснить действие, затем использовать существующий системный диалог.
 Не просить пароль в чате; не добавлять NOPASSWD, глобальный dialout/chmod или
 новый канал обхода ради диагностики. На этапе первоначального аудита sudo не вызывался. Позднее 23.09 владелец
 ввёл пароль локально в versioned установщике Node0.8.22-1; установка
 подтверждена report.json и фактической версией пакета.
 Продуктовое управление устройствами проходит Core → mTLS → Node → plugin.
 SSH остаётся инженерным инструментом, а не транспортом моторных команд.
 ## Результат 23.09
 Подтверждены Ubuntu 24.04.4 LTS, kernel 7.0.0-31-generic, Node 0.8.21-3,
 K1 0.1.14, X4 0.1.3-9. Повторный вход через отдельный профиль вернул
 правильного пользователя и hostname. SSH/sshd, учётные записи, доверие,
 Tailscale, VPN и sudo policy не изменялись.