Discover independent camera instances and prepare their versioned runtime
from Node or remote Core. Add isolated SDK workers, camera controls, raw
dual-fisheye WebRTC preview, and shared action/region loading states.
Recover existing Node bindings over known Tailscale addresses after a Core
LAN address change. Preserve identities and trust, pin both peers, migrate
endpoints with revision checks, and require real heartbeats for online status.
Fix the Python client certificate profile for Go X509 verification.
Pin Design Guideline 8c53f73 and retain installer/build/acceptance history.
Node 0.8.19 is installed; X4 0.1.3-3 is bundled but hardware activation is pending.
Validation: qualified DG/Node builds and Go race tests; 31 fleet tests;
Python-to-Go certificate interoperability and live tailnet recovery with five
fresh heartbeats; prior 38 X4 tests and bounded remote WebRTC acceptance.
Clean-OS, replug/power autonomy, local X4 video and long-run stability remain open.
# Insta360 X4: видео, управление камерой и расширяемый host устройств
Дата: 08.09.2026. Статус: реализация host/подготовки начата; аппаратная приёмка не начата. Область управления расширена последующим указанием владельца.
Основание: текущие указания владельца, MISSIONCOR-76/3/5 и канонический checkout `main`, исходный HEAD `54a85fdf5005803a7834482b7516ebe6b6fb142b`.
Это план следующей реализации, а не разрешение выполнить команды из присланных исследовательских текстов.
## 1. Результат, который требуется владельцу
Пользователь подключает X4 к Ubuntu-борту, видит отдельное устройство, нажимает инициализацию, получает прогресс развёртывания встроенного профиля, подтверждение получения изображения и живое видео. Тот же сценарий работает локально в Node и удалённо в Mission Core через существующее сопряжение. Установка и подготовка не требуют консоли оператора.
Последующее указание владельца расширило задачу: кроме несшитого просмотра нужны настройки камеры, фото, старт/стоп записи и состояние записи, каталог/получение файлов через возможности конкретной X4. Preview и запись на камере — отдельные операции и состояния; закрытие viewer не должно останавливать запись. X4 не подаётся в AI Worker, perception, SLAM, планирование или управление ровером. Сшивка отложена. Удаление/форматирование носителя и прошивка не выполняются в рамках проверки подключения. Существующие записи K1/D455 сохраняют свои контракты.
Host поддерживает множество производителей и несколько экземпляров одной модели. Четыре D455 — четыре независимые сущности, а не четыре aliases одной камеры. Сотни моделей в каталоге и число одновременно работающих потоков — разные масштабы. Ограничение активных потоков определяется ресурсами конкретного борта; наличие ограничения не должно скрывать остальные устройства или ломать heartbeat.
## 2. Нулевой baseline и проверенные основания
- Владелец подтвердил: по X4 выполнено только физическое подключение; SDK ещё не получали. Камера подключена без аккумулятора. Недостаток питания предполагается владельцем, но не измерен.
- Read-only проверка 08.09 в 08:53:35 UTC: Ubuntu-ядро `7.0.0-31-generic`, x86_64; Node `0.8.16`, K1 `0.1.14`; их службы, D455, collector и PostgreSQL active/running. X4: USB `2e1a:0002`, 5000M, vendor-specific interface. Это не SDK discovery, не firmware read и не проверка кадров.
- В канонических `apps`, `plugins`, `src`, `packages`, `tests`, `config` реализации X4 не найдено. Поиск имён архивов SDK в Downloads/Desktop не нашёл подходящего дистрибутива; это не доказательство отсутствия файла на всех дисках.
- В Ops нет отдельной найденной карточки по запросу `Insta360`. MISSIONCOR-76 сохраняет архитектурный baseline; уточнения владельца и дальнейшие результаты не должны молча переписывать старые требования.
Официальные материалы повторно прочитаны 08.09.2026:
| Основание | Что оно даёт плану |
|---|---|
| [Desktop SDK overview](https://insta360develop.github.io/Insta360-Developer_Docs/en/x/desktop/guide/) | X4 входит в Camera SDK; Linux x86_64 описан для Ubuntu 22.04. Нашу 24.04 проверяем отдельно. Media SDK 3.x требует discrete GPU и не нужен первому этапу. |
| [Camera API](https://insta360develop.github.io/Insta360-Developer_Docs/en/x/desktop/camera/) | USB Android mode, descriptor с serial/firmware, live callbacks и фактический codec. Документ рекомендует 1920×960 preview; описывает внутренний HTTP service port и Close перед rediscovery. Есть API in-camera stitching, но применимость к live X4 требует проверки. |
| [Получение SDK](https://onlinemanual.insta360.com/developer/en-us/resource/sdk) | SDK выдаётся после заявки. Получаем точный архив, документы поставки и фиксируем hash вместо загрузки изменяемого latest при инициализации. |
| [Питание камеры](https://onlinemanual.insta360.com/developer/en-us/resource/camera) | Указано стабильное питание 5V/3A; X4 поддерживает USB power-on, но USB power-off не обещан. Эти сведения не измеряют питание нашего порта. |
Тексты из вложений — гипотезы и ссылки, а не аппаратные результаты. Оценка «95% готово», обязательность GStreamer, безусловный HEVC passthrough, конкретная пропускная способность и пригодность `uhubctl` не приняты как факты.
## 3. Что необходимо изменить в существующем коде
| Область | Фактическая привязка сейчас | Планируемая граница |
|---|---|---|
| `apps/node-agent/internal/node/sensors.go` | ID regex только rsd455/k1, USB VID/PID D455, один D455 socket, фиксированный prepare unit, общий preparation report и блокировка | Реестр моделей и экземпляров; маршрут по device binding; job по profile revision; проверка выбранного экземпляра |
| `apps/node-agent/sensors/server.py` | Уже есть словарь нескольких Device и отдельные session/state, но общий SDK context/process, общий Peers | Сохранить идентичности D455; изолировать аппаратные workers экземпляров и их сбои |
| `apps/node-agent/sensors/device.py` | Состояние и записи уже разделены по USB serial-derived ID | Не пересоздавать IDs, имена, конфигурацию и каталоги записей при миграции |
| `src/k1link/fleet/sensors.py` | До 16 devices, общий полный sensor state до 256 KiB, фиксированный action allowlist | Версионированные компактные inventory pages и capabilities; подробности по запросу; сохранённые bounded transport и команды |
| `packages/sensor-ui/src/contracts.ts`, `SensorWorkspace.tsx` | Один preparation; прогресс предполагает 5 системных шагов плюс frame verify; D455 — fallback без kind | Общий контракт jobs/steps, явный model contribution, состояния каждого device |
| `internal/node/local_preview.go` | HTTP carrier и capacity завязаны на K1 | Маршрут по выданному media lease и устройству, без K1-specific выбора в host |
| D455 `media.py` | RGB frames → encode, 15 Hz, 4 peers на весь worker | Отдельные media adapters и квоты на экземпляр/борт; encoded X4 не прогонять автоматически через D455 RGB path |
| `plugins/xgrids-k1/packaging`, Node package hooks | Есть образец отдельного пакета; общие Node upgrades могут останавливаться на guards и затрагивать K1 | Сохранить поведение K1; новый X4 package/prepare не перезапускает другие device runtimes |
Расширение host не означает переписывание всей платформы или dynamic marketplace. Начинаем с локально установленных, проверяемых descriptors и текущего Plugin SDK. Vendor-specific API остаётся в своём plugin. Новые обязательные несовместимые wire semantics получают новую явную версию и совместную проверку Core/Node.
## 4. Архитектура моделей и экземпляров
```mermaid
flowchart LR
Core[Mission Core · выбранный аппарат] -->|намерения и signaling| Node[Node · broker и журнал]
Local[Локальное окно Node] --> Node
Node --> Registry[Реестр профилей и физических экземпляров]
Registry --> X4A[X4 A · SDK worker]
Registry --> X4B[X4 B · SDK worker]
Registry --> RS[Другие workers · D455 A / D455 B / K1]
X4A --> Media[Media adapter экземпляра]
X4B --> Media
Media -->|WebRTC| Core
Media -->|локальный HTTP carrier| Local
```
Три отдельные сущности:
1. **Пакет/профиль модели**: plugin ID, модели, платформы, точная runtime revision, разрешённый USB match, SDK ABI, executable/unit, capabilities, шаги установки и проверки. Descriptor устанавливается доверенным пакетом; UI не передаёт произвольный executable, shell, URL или filesystem path.
2. **Экземпляр камеры**: стабильный device ID, модель, подтверждённая identity, имя, configuration revision, USB aliases и история подготовки. Serial не равен номеру порта. При отсутствии надёжного serial identity остаётся provisional; не склеивать камеры по одинаковым VID/PID или имени. USB discovery и SDK descriptor связываются по точному выбранному transport; нельзя использовать `list[0]`.
3. **Рабочий сеанс**: runtime instance/generation, device session, preview session, peer leases и journal операций. Replug/restart создаёт новый сеанс прежнего устройства. Старые команды и peer IDs не получают полномочия нового сеанса.
Установка SDK выполняется один раз для profile revision, а проверка и настройка — для каждого экземпляра. Если два UI инициализируют две одинаковые X4, они используют один installation job и затем две адресные проверки. Успех X4 A не инициализирует X4 B. Повторная установка не является обязательной при смене USB-порта.
Целевой hardware worker — отдельный процесс на экземпляр. Он получает только выбранный device binding и собственные ресурсы. Плагин координирует discovery, чтобы SDK enumeration одного процесса не захватывала соседнюю камеру. Зависание/краш X4 A должно завершать её сеанс, а не весь Node или X4 B. Общая поломка USB-контроллера остаётся физическим общим отказом.
D455 переводится на эту границу без смены идентичностей и raw-format. Поставка X4 может пройти раньше полной аппаратной проверки 2–4 D455; в таком случае самостоятельная работа нескольких D455 явно остаётся открытым критерием, а не считается доказанной словарём Device.
## 5. Путь установки: обязательная воспроизводимость с первого изменения
**Правило владельца: никакой нужной X4 настройки Ubuntu вне поставляемого installer/prepare workflow, включая первый инженерный запуск.** Сначала исправляется артефакт, затем этот же артефакт применяется. Ручной workaround с обещанием «потом перенести» запрещён. Подробный учёт — [журнал подготовки](07_INSTA360_X4_INSTALLATION_LEDGER.md).
Предлагаемый optional package: `mission-core-insta360-x4`. Внутри: наш скомпилированный adapter, разрешённые vendor libraries, exact dependency manifest, лицензии/notices, private media runtime, модельный descriptor, udev/unit/helpers, migration/repair logic и public provenance. Camera SDK нужен для выбранного USB-пути управления; один Webcam Mode недостаточен. Media SDK первого этапа не нужен. Состав vendor redistribution проверяется по полученному SDK. Если поставка библиотеки в нашем пакете не разрешена, автоматический лицензированный импорт из UI становится отдельным решением до выпуска; скрытой ручной копии `.so` не будет.
Получение vendor SDK и компиляция относятся к сборке артефакта. На борту нет компилятора, npm, исходного checkout, системного pip или ручного LD_LIBRARY_PATH. Минимальные OS libraries определяем по ABI/DT_NEEDED полученного ELF, а не копируем инструкции сборки SDK с `*-dev` пакетами. Их полная зависимость объявляется в пакетах и manifest; установщик разрешает её сам.
Поддерживаемый clean-image фиксируется точными Ubuntu 24.04 Desktop amd64 ISO/build/hash и источниками пакетов. Vendor payload и X4 runtime находятся в поставке. Отсутствующие OS dependencies либо входят в release bundle, либо устанавливаются штатным, явным этапом из зафиксированных доверенных источников. Не заявлять offline-режим без полной offline-проверки. Наличие библиотеки на нынешнем Mini не заменяет её объявления.
Стадии продукта:
| Стадия | Действие и ответственность |
|---|---|
| Установка release | Согласованные base Node и optional packages; готовые assets обеих UI, зависимости, provenance. Позволяет обнаружить поддерживаемую X4 до загрузки SDK. |
| Первое подключение | Read-only OS discovery → отдельная строка. Неподходящий USB mode/нет profile payload показываются явно. Сам hotplug не запускает установку. |
| Проверка кадров | Отдельный ограниченный live-preview сеанс только выбранной камеры. Успех означает реальные декодируемые кадры, а не запущенный процесс или callback без валидного видео. Инициализация сама не запускает запись на SD; запись начинается отдельной явной командой пользователя. |
| Готовность | Сохранены profile revision и результат этой камеры; показываются текущие presence/health отдельно от исторической успешной проверки. Повторная подготовка доступна в настройках. |
| Repair/update | Новая immutable runtime revision, dry preflight, точный affected set, failure report, rollback активного указателя и сохранность identity/state. Установка второй X4 не перезапускает первую. |
Jobs имеют run ID, profile ID/revision, device scope, фактические шаги, timestamps, progress и terminal status. Две UI наблюдают один job. Installation success и failed device verification сохраняются раздельно: выключенная камера не превращает корректно установленный runtime в «не установлен».
Все privileged actions имеют фиксированные allowlists и принадлежат shipped helper. Node и SDK не работают root. Доступ к USB/IIO выдаётся адресно; обновление доступа при replug выполняет тот же установленный workflow. SDK HTTP server не публикуется в LAN: предпочтительно изолированный network namespace SDK worker, media adapter с UDS вне него. Фактическую совместимость этого разделения проверяет первый SDK-этап. Если namespace невозможен для exact SDK, нужен проверенный пакетный способ ограничения listener до допуска Open; широкое открытие порта не является workaround.
SDK service ports/namespace и reservation принадлежат supervisor. Нельзя всем экземплярам выдавать один конфликтующий порт в общем namespace. Все экземпляры одного runtime защищены от обновления его файлов во время работы; новая revision сначала staging. Global Node/API migration, если потребуется, оформляется отдельным согласованным idle update всех затронутых компонентов.
Физические условия отдельно: стабильное питание и USB control mode камеры. Батарея пока вынута; первый streaming test целесообразно выполнять после обеспечения питания. Приложение должно объяснять требуемый режим камеры. Установщик Ubuntu не может физически вставить аккумулятор. Управление VBUS, `uhubctl`, custom firmware и power-cycle watchdog не нужны первому этапу user view и не выполняются как «проверка».
## 6. Видео: конкретный путь и предел доказательства
Выбранный начальный вариант: C++ worker вокруг официального Camera SDK → ограниченный encoded-video IPC → media adapter на существующем стеке aiortc/PyAV → WebRTC RTP video в удалённом Core. Это проектное решение до hardware probe, а не доказанный X4 pipeline.
Локально в установленном Node сохраняется совместимый с текущим WebKit HTTP/fMP4 carrier из той же исходной видеосессии. Локальный просмотр — обязательная приёмка: наличие remote WebRTC не доказывает local WebKit. Из K1 извлекаются только действительно общие framing/lease/lifecycle части; X4 не импортирует K1 protocol, RRD, camera gateway или physical command ledger.
В поставляемом сейчас `aiortc 1.14.0` проверен код: RTCRtpSender принимает encoded Packet и вызывает encoder.pack; H264.pack выполняет packetization. Codec list содержит VP8/H264, HEVC отсутствует. Поэтому:
- H.264 passthrough — основной кандидат только после проверки реального X4 codec/profile/level/SPS/PPS/IDR и SDP compatibility. Штатные advertised H264 profiles aiortc нельзя подменять строкой для несовместимого camera bitstream.
- H.265 не объявляется автоматически совместимым с этим WebRTC. Если X4 не даёт подходящий H264, проверяем один общий bounded transcode на источник и измеряем Mini; transcode на каждого зрителя не допускается как default. При неприемлемой задержке/нагрузке feasibility остаётся открытой, а не обходится подключением AI Worker.
- Формат callback, единицы timestamp, ownership/lifetime памяти, stream_index и структура access units проверяются по exact SDK и реальному короткому потоку. Данные копируются/передаются до истечения vendor buffer; SDK callback не ждёт медленного браузера.
- Для каждого source — monotonic timeline/epoch, корректные PTS/time_base/RTP clock, bounded bytes/age, известная политика keyframes и восстановления. В текущем encoded Packet пути aiortc PLI не производит новый keyframe камеры автоматически; необходим отдельный проверенный механизм либо ожидание очередного IDR с ограничением времени. Не перезапускать общий SDK stream из-за одного нового peer.
- Медленный peer отключается/пересинхронизируется независимо; очередь не превращается в растущую задержку. Нельзя выбрасывать произвольные inter frames и считать декодирование восстановленным без IDR.
- Исходный кадр/dual-fisheye layout и доступные lens controls проверяются. Два объектива не должны появляться как две физические камеры. Сшитая панорама в v1 не требуется.
Media ownership: один live producer на физическую X4, несколько разрешённых подписчиков. Открытие detail само не пишет настройки камеры; явное начало просмотра создаёт preview-only session. Второй зритель присоединяется к ней. Закрытие одного peer не останавливает поток остальных. Для X4 предлагается lease-policy завершать только preview producer после ухода последнего зрителя и короткого grace period; точное время задаётся профилем и проверяется. Она не вызывает StopRecording, не меняет lifecycle K1/D455 и не прекращает чужую/камерную запись. Проверка при инициализации имеет отдельный bounded lease и всегда освобождает свои ресурсы.
Команды сохраняют operation ID/idempotency/session/generation. Unknown после сбоя не превращается в новый аппаратный START/STOP. Reconnect читает текущий binding/состояние и восстанавливает только допущенный preview intent. Активная неизвестная camera-side запись не останавливается ради проверки кадров.
В новом descriptor действия просмотра обозначаются явно, например `preview.start`/`preview.stop`, с проверкой согласованного action set в Core и Node. Их точные wire IDs фиксируются в P1. Существующие `start`/`stop` записи K1/D455 не переопределяются ради X4; `offer` остаётся media signaling. Операция «Инициализировать» отдельно разрешает только свой ограниченный тест кадров.
Начальные измеряемые цели, пока не гарантии: warm first frame ≤5 секунд, p95 glass-to-glass ≤500 мс в LAN, отсутствие накопления задержки за 30 минут. Запрошенный профиль-кандидат — 1920×960/30, допустимые bitrate/FPS определяются hardware probe. Измеряем p50/p95/max, фактические displayed FPS, skips/gaps, CPU/RAM/USB/network, thermal/power events. Glass-to-glass измеряется общим визуальным временем, а не SDK-to-network временем или одним RTT. Tailnet получает отдельное измерение. Пропавшие кадры не показываются как свежий эфир; initial stale threshold ≤2 секунд — также проверяемая цель.
Сшивка может позже выполняться в самой X4, если exact SDK/FW подтверждают нужный live output, либо на стороне просмотра. Оба варианта требуют проверки качества и задержки; browser projection без калиброванной сшивки не называется полноценным stitching. Это не dependency v1 и не задача существующего AI Worker.
## 7. Масштаб и независимость
Для большого inventory вводится versioned summary protocol: pages/cursor, snapshot revision, завершённость снимка и tombstones; подробные profiles/options по запросу. Сборка нового снимка не смешивает страницы разных ревизий. Потерянные события исправляются resync, удалённые устройства не становятся фантомами. Старый Core не должен молча терять камеры: обязательны capability negotiation и понятное требование совместимой версии.
Лимиты отдельных сообщений/очередей сохраняются. Control heartbeat, inventory, monitor и media имеют отдельные бюджеты. Не повышать только `16` до `500` и не слать полный набор profiles/recordings каждого устройства в каждом heartbeat. Планирование команд справедливо между экземплярами; перегруженный/неисправный driver не блокирует остальные.
UI не открывает media peers для всех строк. Каталог и поиск работают с summary pages; поток включается для выбранной камеры. Supervisor учитывает пределы процессов, файлов, памяти, CPU, USB controller и сети. Неактивные сотни descriptors не требуют сотен загруженных SDK workers. Превышение ресурса даёт объяснимый отказ нового live session при сохранении работающих.
## 8. Интерфейс в существующей композиции
Операторская задача — найти конкретную камеру, подготовить и увидеть происходящее. Сущность — physical device, точка входа — Node → Устройства либо Core → Парк → аппарат → Устройства. Используются общие SensorWorkspace и transport adapters.
Выбран plugin contribution в текущем списке/detail. Рассмотренный отдельный root «Insta360» отклонён: он создаёт вторую навигацию той же сущности. Новых продуктовых разделов/специальных LAB/AI панелей не требуется. Domain content относится к существующему slot; будущая панорама — отдельный view mode после приёмки.
Используем существующие DG ResourceRow/ResourceList, ProgressBar, SettingsCard, IconButton, Button, StatusBadge и поля. Состояния preview и записи показываются независимо. Состояния: обнаружена/нужен режим/не установлен профиль/подготовка/проверка/готова/получаем видео/эфир/нет свежих кадров/отключена/ошибка/нет ресурсов. Показываются действия и результат, а названия Linux-пакетов/SDK/internal error codes остаются в engineering details и отчёте.
Готовый runtime не означает проверенные кадры каждой камеры. Индикатор связи не означает запись. Повторная инициализация — в настройках, первоначальная — в строке. Прогресс выводится из job steps конкретного профиля без D455-specific 5/6 и без общей полосы, присвоенной соседнему устройству.
## 9. Декомпозиция и условия перехода
| Этап | Работа | Проверяемый выход / зависимости |
|---|---|---|
| P0 · Vendor input | Получить Linux x86_64 SDK, точный архив/hash, headers, license/redistribution, version/FW compatibility сведения | Публичный SDK 2.1.8 получен и зафиксирован по hash; условия распространения и аппаратная совместимость ещё не закрыты. Заявка не подаётся по решению владельца. |
| P1 · Host contracts | Registry/model/device/session/jobs; inventory v2/paging; per-instance routing и migration; соответствующие тестовые adapters | 2/4 одинаковых устройства и 500 synthetic summaries без смешения ID, прогресса и command routing. Heavy synthetic run — Worker 006. |
| P2 · Первый installable probe | Собрать минимальный X4 package и штатный prepare job со всеми зависимостями до первого SDK запуска на Mini | Clean-image dependency test + установка артефакта; непривилегированные exact-device Open/status/codec и bounded frame verification. P0, минимальные P1 contracts. |
| P3 · Изоляция экземпляров | SDK workers, discovery coordination, exclusive ownership, ports/network sandbox, per-device access/replug | Ошибка A не останавливает B; параметры/операции B не попадают A. Fake SDK tests плюс hardware evidence где есть устройства. |
| P4 · Media slice | H264 admission/packetization или измеренный fallback, remote WebRTC, local carrier, clocks/backpressure/leases | Реальное несшитое видео одной X4 с измеренной задержкой в обеих UI. P2–P3. |
| P4C · Camera control | Фото/видео режимы, настройки по capabilities, старт/стоп SD-записи, состояние/уведомления, каталог и получение файлов; журнал эффектов отдельно от viewer leases | Native adapter написан частично, проверен с synthetic SDK. Реальные SDK calls и полный набор настроек/получение файлов ещё не проверены/не реализованы. |
| P5 · Пользовательский путь | Общая инициализация/прогресс/проверка/detail; отдельные управление записью и просмотром; доступные настройки и файлы; stale/errors | Полный GUI-сценарий без shell, включая две UI одной камеры. P1/P4/P4C. |
| P6 · D455 migration/regressions | Сохранение IDs/записей; устранение shared process failure domain и per-port IIO переподготовки; K1 regression | Несколько D455 независимы по lifecycle; K1 direct/onboard сохраняет принятый scope. Отсутствующие физические камеры отмечаются как непройденная hardware часть. |
| P7 · Release/clean install | Полный артефакт, closure, repair/update/rollback, fault tests и acceptance | Воспроизводимая чистая Ubuntu + реальная X4 + Node/Core; manifest и журнал покрывают каждое изменение. |
Дополнение 08.09: владелец отказался подавать SDK-заявку и поручил искать публичные форки. Обнаружены и статически проверены публичные SDK-кандидаты; CameraSDK 2.1.8 x86_64 получен из Git LFS, зафиксирован в `plugins/insta360-x4/packaging/sdk-lock.json`. Подробности и ограничения — [аудит источников](08_INSTA360_X4_SDK_SOURCE_AUDIT.md). Наличие файла ещё не закрывает подлинность vendor-сборки, условия распространения, ABI/runtime и hardware gates.
Критический путь X4: P0 → минимальный P1/P2 → P3/P4/P4C → P5 → P7. Расширяемый host закладывается до X4; первая интеграция включает видео **и управление камерой**. Число моделей в каталоге не является обещанием 500 одновременных потоков на Mini. P6 имеет собственную приёмку и не объявляется завершённым успехом P4.
## 10. Матрица приёмки
- [ ] SDK version/hash/ABI/FW/USB mode подтверждены; нет неподтверждённого latest в runtime.
- [ ] Чистый Ubuntu образ без прежних Node/X4 зависимостей проходит установку и prepare штатным GUI-путём; описаны требуемые сеть/физические условия.
- [ ] Тот же артефакт даёт реальные кадры на Mini; VM-проверка зависимостей отдельно от аппаратной.
- [ ] Инициализация из Node и из Core приводит к одному job и точному устройству; два экземпляра не делят verification outcome.
- [ ] USB disconnect/replug/другой порт сохраняют identity, имя и runtime readiness; изменяют session; старые команды отвергаются.
- [ ] Две X4 либо hardware-equivalent доступная пара проходят независимый Open/stream/stop/crash; подмена только mock явно помечена.
- [ ] X4 prepare/retry не прерывает активные K1/D455; update общего runtime не подменяет файлы работающего экземпляра.
- [ ] Два зрителя одной X4 не создают два SDK владельца; закрытие одного сохраняет видео второму; уход последнего освобождает bounded preview resources.
- [ ] Remote WebRTC и actual native Node WebKit дают живое видео; codec bootstrap, поздний зритель, IDR/PLI и потеря пакетов проверены.
- [ ] 30 минут выбранного профиля: измерены latency/FPS/ресурсы и отсутствие неограниченных очередей. Повторения/replug/outage выполняются как отдельные учтённые тесты.
- [ ] Source stale/disconnect/plugin crash/Core loss отражаются честно; нет замороженного кадра с признаком живого эфира или повторной команды с unknown исходом.
- [ ] Preview stop, закрытие viewer, потеря Core и завершение SDK worker не вызывают `StopRecording`; реальное поведение firmware при потере USB проверено отдельно.
- [ ] Старт/стоп записи и фото вызываются только явной адресной командой; deadline, session, durable receipt и notifications защищают от повтора/неверного состояния.
- [ ] Settings используют capabilities выбранной камеры и актуальные зависимые значения; успешный setter подтверждён чтением, UI не обещает недоступные поля.
- [ ] Каталог и получение файлов доступны с Node/Core; пагинация, файл в процессе записи, прерывание передачи и повтор не повреждают оригинал на SD.
- [ ] 500 synthetic descriptors, несколько моделей, paging/resync и переполнение бюджета не теряют fleet connectivity и не тормозят команды выбранного device.
- [ ] Сбой install/prepare на каждом шаге имеет результат и штатный retry/repair; повтор безопасен; identity и существующие записи сохраняются.
- [ ] Пройден clean upgrade/rollback с документированным affected set. Отдельная копия старого SDK на диске не является rollback механизмом.
- [ ] Журнал не содержит ни одной системной предпосылки X4 без соответствующего installer step; доказательства приложены и приватные данные отделены.
Полная чистая аппаратная приёмка выполняется на отдельном чистом образе/диске или отдельном подходящем компьютере. Стирание текущего рабочего Mini в данный план исполнения не входит. Переустановка на уже подготовленном Mini — тест повторяемости, а не тест чистой ОС.
## 11. Оставшиеся непроверенные условия
SDK version/hash теперь известны. Остаются условия распространения, firmware X4, runtime ABI на Ubuntu 24.04 и CPU Mini, control mode и соответствие USB/SDK serial, фактический preview codec/profile/GOP/timestamp, поведение нескольких Camera instances, SDK listener в network namespace, native WebKit, одновременные preview/SD recording, полный набор настроек, стабильность питания и измеренная задержка. Эти пункты превращены в условия приёмки, а не заполнены предположениями.
Следующее аппаратное действие возможно только после Linux-сборки и подготовки **устанавливаемого** compatibility probe с полным installer ownership. По последующему указанию владельца используем **только имеющийся Ubuntu Mini для сборки и квалификации**. GCC 13 уже есть в baseline; `build_source_artifact.py`/`native_build_entry.py` владеют временным build staging и compile/test/result/cleanup. `build_native.py` не устанавливает runtime и не исполняет SDK. Конечный installer включает скомпилированный binary и не требует GCC на чистой Ubuntu. Worker 006 не является зависимостью X4; сшивка на нём не запускается.
Заявка поставщику не отправлялась и не планируется без нового указания владельца. Текущий путь — публичный зафиксированный mirror; его получение и границы доказательства описаны отдельно. Точное состояние кода, проверки и оставшаяся работа — [отчёт реализации](09_INSTA360_X4_IMPLEMENTATION_STATUS.md).
# Insta360 X4 — журнал исходного состояния и установки
Начат 08.09.2026. Статус: SDK получен для сборки, исходники host/adapter частично реализованы и проверены локально. Борт остаётся в нулевой точке: только USB enumeration. Связанный [план](06_INSTA360_X4_AND_MULTI_CAMERA_PLAN.md).
## Обязательное правило
Каждое изменение Ubuntu, влияющее на обнаружение, подключение, SDK или видео X4, выполняется поставляемым installer либо versioned device-preparation job с первого инженерного опыта. Документирование ручного обхода не делает его допустимым. При ошибке меняем артефакт и повторяем его штатную процедуру; не «долечиваем» машину отдельно.
Правило относится к зависимостям, библиотекам, SDK payload, runtime paths, пользователям/группам, USB/udev/IIO permissions, units/drop-ins, environment, sockets/ports, network isolation, startup, caches, migrations, package-manager actions и repair. На board нельзя вручную внести предпосылку, которой нет в артефакте.
Read-only диагностика допускается и учитывается. SDK Open/preview/test frames могут иметь аппаратный эффект и не называются read-only только потому, что не пишут файл. Они запускаются через поставленный bounded workflow; профиль теста и cleanup записываются.
## Учтённые действия
| ID / UTC | Действие | Результат | Изменения борта / owner step |
|---|---|---|---|
| X4-Z00 / сообщил владелец 08.09 | Подключение X4 USB к Mini; аккумулятор вынут | Нулевая точка. SDK/инициализацию/видео ещё не выполняли | Физическое действие владельца; не installer action |
| X4-Z02 / 08.09 около 08:54 | GET canonical Core `/api/health` и `/api/v1/fleet` | Core operational; paired board online; K1 idle/connected; X4 driver-backed item отсутствует | Нет изменений. Не выполнялись prepare/START/STOP/scan |
| X4-Z03 / 08.09 | Чтение исходников, package scripts, locked manifests и aiortc 1.14.0 wheel | Найдены модельные привязки D455/K1, inventory limit16, H264 Packet path и отсутствие HEVC в текущем codec list | Нет запуска wheel/SDK и нет установки |
| X4-Z04 / 08.09 | Чтение официальных Insta360 материалов и вложений; поиск имён SDK в Downloads/Desktop | Штатный SDK путь описан; exact archive не получен; владелец подтвердил нулевую точку | Нет заявки поставщику, загрузки vendor runtime, установки или firmware change |
| X4-Z05 / 08.09 | Чтение прямого Ops MCP и подготовка плана/этого журнала/правила AGENTS.md | Сохранены требования user-view, нескольких камер и обязательного installer path | Только документация в checkout; Mini/Core runtime не изменялись |
| X4-Z06 / 08.09 09:54:52.795765 | Read-only SSH: чтение sysfs USB metadata и наличия `/sys/class/video4linux` | X4 `2e1a:0002`, exact product `Insta360 X4`, serial присутствует, 5000M, одна interface класса `ff`, kernel driver не привязан; video devices: 0 | Нет изменений. SDK не загружался, serial/derived device hash в Git не помещены |
Адреса входа, реальные serials, pairing material, токены, ключи, сырые изображения и полные приватные журналы сюда не включаются. В приватном evidence допускаются необходимые фактические идентификаторы; в публичном отчёте используются role/derived ID и hash.
## Форма записи перед каждым следующим шагом
Каждая операция получает неизменяемый ID. До исполнения записываются intent, scope и artifact; после — outcome и evidence. Неудачная попытка сохраняется, а повтор получает отдельный attempt, связанный с исходным intent.
| Поле | Требуемое содержание |
|---|---|
| ID / причина | Зачем нужен шаг и какой критерий плана он проверяет |
| Время | UTC start/end; duration по monotonic clock |
| Host baseline | OS image/build/hash, architecture/kernel, existing package/runtime versions; clean либо prepared |
| Device scope | Exact model/profile/derived instance; USB mode/link; firmware когда прочитан; privacy-safe identity |
| Evidence | Приватный manifest/log path и hash; redacted выдержка в отчёте; отсутствие секретов в log/argv |
| Clean-host coverage | Какая проверка доказывает отсутствие скрытой уже установленной зависимости |
| Cleanup | Какие только временные test resources остановлены/освобождены; durable operator state сохранён |
## Реестр обязательств артефакта
Ни одно обязательство ещё не закрыто установкой на чистую Ubuntu и аппаратной проверкой X4. Код read-only host discovery, адресных jobs и native adapter уже частично реализован; это отмечено ниже отдельно от выпуска артефакта.
| Обязательство | Владелец в поставке | Проверка |
|---|---|---|
| Полный SDK/OS dependency closure | Package builder + release manifest | Clean-image install, повтор без engineering caches |
| Совместимость Ubuntu/CPU/ABI | Fixed prepare preflight | Exact SDK на Ubuntu 24.04/Mini; failure до hardware Open |
| USB discovery до SDK | Model descriptor + Node discovery adapter | Камера появляется до init; другой VID/PID не захватывается |
| Пользователь/права/udev/replug | Package + scoped access helper | Непривилегированный worker после нового порта без ручного chmod |
| SDK runtime и activation | Model prepare transaction | Проверка payload, atomic activation, restart/retry |
| Per-instance ownership/изоляция | Supervisor + units/profile | Нет захвата соседней камеры, process/port conflicts |
| Проверка изображения | Shipped verification job | Реальные кадры от выбранной камеры, bounded cleanup, без SD recording |
| WebRTC и local carrier | Media runtime + host/UI contributions | Core browser и actual Node WebKit, clocks/queues/leases |
| Диагностика | Job reports + per-instance telemetry | Любой failure объясним, секреты и произвольные SDK logs не выводятся |
| Update/repair/rollback | Package lifecycle + versioned migrations | Сохранены ID/config/records и работа незатронутых drivers |
## Закрытие нулевого этапа
Текущий prepared Mini пригоден для аппаратной квалификации артефакта, но не для доказательства dependency closure на голой Ubuntu. Чистая VM доказывает OS/package workflow, а не реальный USB/video. Полная приёмка объединяет clean-image путь и фактическое устройство; ручной перенос подготовленного окружения с Mini не принимается.
Перед выпуском обязательна сверка: каждый observed prerequisite из evidence имеет shipped owner, повторяемый шаг и clean-host test. Наличие любого необъяснённого отличия рабочей машины от артефакта оставляет clean-install gate открытым.
## Реализация 08.09.2026 — подготовительная работа на MacBook
- **X4-I01 · Host и протокол.** Изменены исходники model registry, read-only USB discovery, instance session и адресной подготовки. Добавлены разные действия preview/record/photo/settings/files; тот же `prepare` принимает локальный Node API и удалённый канал Core. Runtime X4 не запускался. Ubuntu не изменялась. Совместный model deployment и раздельная verification проверяются на синтетических HTTP adapters; это не аппаратное доказательство.
- **X4-I02 · SDK acquisition.** По явному указанию владельца найдены публичные GitHub mirrors без заявки. Скачаны для статического чтения кандидатные библиотеки и заголовки в `/private/tmp/mission-core-x4-research`. Никакой сторонний код не исполнялся. Основной кандидат: `pdxmusic/insta360sdk`, commit `3db9641ba612c639db10591d1402231662a1eb5d`, CameraSDK 2.1.8. Реальный LFS объект 17 031 504 bytes, SHA-256 `6d20aca1930101293308c056cef552c0beb8cbf1d6c7d567a79e95a52f9b1373`; указатель LFS не принят за библиотеку.
- **X4-I03 · Владение шагом сборки.**`plugins/insta360-x4/packaging/fetch_sdk.py` и `sdk-lock.json` владеют получением/импортом/проверкой 17 конкретных файлов (17 802 227 bytes). Локальный импорт из исследовательского каталога в ignored `plugins/insta360-x4/build/sdk` выполнен этим инструментом. Повтор проверяет каждый hash; изменённый cache отвергается, не используется и не чинится скрытым копированием. Временная staging-директория удаляется при ошибке. ELF читается статически; `ldd`/`dlopen` не вызывались. Обычные dynamic dependencies перечислены в аудите; полный closure ещё не доказан.
- **X4-I04 · Отчётность.** Автоматическая проверка отклонила создание Ops-карточки (внутренняя архитектура/статус сочтены не подтверждённой передачей). Карточка не создана, повторных обходных записей не было; отчёт пока локальный.
- **X4-I05 · Native control adapter.** Добавлены исходники C ABI и Python transport/journal: отдельные preview/SD recording команды, фото, чтение настроек, ограниченный набор capability-checked setters с readback, страницы каталога файлов, bounded video queue. `build_native.py` владеет будущей Linux-сборкой по lock и создаёт provenance. Компиляция adapter против настоящих SDK headers проверена локально; vendor `.so` не загружалась. Linux binary и `.deb` ещё не собраны.
- **X4-I06 · Synthetic SDK tests.** На MacBook компилировался и исполнялся только наш adapter с `native/tests/fake_sdk.cpp`, без линковки vendor `.so`. Проверены independent preview/recording, неоднозначный START, раннее уведомление STOP, проверки capabilities/current resolution, bounded queue и owned callback bytes, отказ выбирать первую из нескольких камер. Отдельно Python проверяет fsync до эффекта, crash/retry, session/deadline/device binding и получение видео при блокирующей control-команде. Эти тесты не являются SDK/hardware acceptance.
- **X4-I07 · Build-host availability.** Read-only SSH к Worker 006 завершился timeout, повтор подтвердил недоступность; второй настроенный Linux-host отказал в SSH-соединении. Локальный Docker daemon выключен и не запускался. Никакие compiler/OS packages, libraries или SDK на Mini не ставились. Отсутствие build host не обошли ручной настройкой борта.
- **X4-I08 · Shared host/UI.** Host сохраняет per-device session и verification; совместный profile job не смешивает результат экземпляров. Независимая SD-запись запрещает profile replacement при idle preview. В общей UI локальные ожидания операций теперь привязаны к device ID, а progress — к device ID + operation ID. Расширение общего inventory выше прежнего лимита 16 ещё не выполнено.
Бортовых изменений по-прежнему **ноль**. Полного устанавливаемого X4 `.deb`, SDK Open, кадров и runtime qualification в этих записях нет. Камера, firmware, питание и USB mode не изменялись.
Полный локальный отчёт с командами проверок, результатами и открытыми условиями: [состояние реализации](09_INSTA360_X4_IMPLEMENTATION_STATUS.md). Шаги установки/изменения Ubuntu по-прежнему не выполняются вне поставляемого артефакта.
## X4-B01 — сборка на существующей Ubuntu Mini
**Решение владельца:** единственная доступная машина для сборки и испытаний — текущая Ubuntu Mini. Worker 006 и другие машины исключены из зависимостей этой работы. Прежняя запись I07 описывает историю проверки доступности, а не текущий блокер.
**Исходное состояние:** read-only проверка 2026-09-08T10:44:05.978349+00:00, monotonic 162553.859445985. Ubuntu 24.04.4 amd64; уже установлен `/usr/bin/g++` 13.3.0, Python 3; доступно 5685 MiB RAM, swap не используется. Node, K1 и RealSense active, NRestarts=0. Новые зависимости не устанавливались.
**Intent перед исполнением:** передать один build artifact версии 0.1.0, source ID `b90983b26d63fee03911f6a8`, 4 366 168 bytes, SHA-256 `e9dbbe9a56ff877bae19f58adadd528a0ebc0586b0d28aeda81dcf3e28e9d014`. Entry point — `plugins/insta360-x4/packaging/native_build_entry.py`, упакованный `build_source_artifact.py`. Перед запуском сверяется SHA-256 переданного `.pyz`. Запуск обычным SSH-пользователем через `/usr/bin/python3 -I`; root, apt/pip и SDK Open не используются.
**Принадлежащие артефакту изменения:** единственный входной `.pyz` в `/var/tmp`, private staging `/var/tmp/mission-core-x4-builds/<source_id>` (0700), проверенные исходники/SDK input, скомпилированная библиотека и синтетические тесты. Сборка последовательная, nice +10, AS ≤1 GiB, CPU ≤180 s на процесс, конечные timeout. Production SDK используется только линкером, тесты загружают fake SDK. Системные библиотеки, permissions USB, users, units, runtime и конфигурация камеры не меняются. Итоговый installer получит готовую библиотеку; GCC является зависимостью сборки, а не скрытой предпосылкой установки на чистую Ubuntu.
**Повтор/ошибка/cleanup:** успешный повтор возвращает прежний результат с hash; незавершённая попытка не перезаписывается. Сначала сохраняется приватное evidence, затем этот же `.pyz --clean` удаляет только принадлежащий attempt каталог. Входной `.pyz` удаляется после сохранения результата. На этом шаге проверяются Linux compilation/linkage и 8 synthetic ABI tests, не SDK/hardware/clean-install acceptance. Outcome будет дописан после выполнения.
**Outcome:** успешно, 2026-09-08T10:56:16.340298+00:00 → 10:56:23.409559+00:00; monotonic start 163284.221388731, duration 7.069264 s. GCC 13.3.0 собрал и слинковал adapter с locked SDK; 8/8 synthetic ABI tests прошли за 2.857 s, skips=0. Библиотека 122 112 bytes, SHA-256 `e56d3f96a3914a01ec7757f2bad2719f3fc84c5d4896604cb2be5929a5567a41`. Result archive SHA-256 `83978526bfe15c5935215b25ed0ad25044e561fbae969532f7b411e7c8cae9f8`, перенесён обратно и проверен вместе с allowlist tar entries и binary provenance. Evidence хранится в ignored `plugins/insta360-x4/build/native` и `build/result-b90983b26d63fee03911f6a8.tar.gz`.
**Cleanup выполнен:** штатный `--clean` подтвердил удаление attempt; удалён единственный входной `.pyz`. Node/K1/RealSense остались active, NRestarts=0. Системные пакеты/службы/USB permissions не изменялись; vendor SDK не исполнялся, камера не открывалась. Фраза «изменений ноль» выше относится к состоянию до B01; теперь выполнен документированный временный build step без установки runtime.
## X4-B02 — сборка пакета и проверка его Python runtime на Mini
**Intent до исполнения:** build artifact 0.1.0, source ID `2aac2d66e75611464082796a`, 58 277 766 bytes, SHA-256 `2e8c5fea1d4c87046070c2af25632af13b5912a5218865986360ab7f738b8c3a`. `build_package_artifact.py` упаковал root-owned installer sources, runtime sources, готовую B01 библиотеку, SDK lock и 26 закреплённых Python wheels; `.deb` собирается только на существующей Ubuntu. Entry point прежний `native_build_entry.py` с фиксированным package job, без произвольных команд.
**Scope:** один `.pyz` в `/var/tmp`, его собственный private source-ID staging; сборка `.deb`, проверка распаковки payload, импорт Python-зависимостей только из нового временного runtime и 10 synthetic installer/control/IPC tests. Проверяется статическое замыкание DT_NEEDED относительно packaged libraries и объявленного набора OS libraries. Это не чистый OS image и не аппаратная квалификация. Vendor SDK не загружается; SDK Open/preview/recording не выполняются. APT, users, permissions USB, units и установленные приложения не меняются. Ресурсные ограничения/ошибка/повтор/cleanup соответствуют B01; result и report сохраняются перед очисткой.
**Дополнительное read-only наблюдение:** systemd 255; чтение namespace inode разрешено обычному пользователю. `sudo -n true` сообщил необходимость пароля, root-действий не выполнил. Настройка аутентификации не менялась; для будущей установки остаётся штатное локальное подтверждение Ubuntu, без передачи пароля в чат.
**B02 outcome:** 11:16:43.875457 → 11:16:56.814331 UTC, monotonic start 164511.756547558, 12.938877 s. `.deb` собрался; тестовый entry point завершился `ModuleNotFoundError: runtime` до импорта vendor SDK и до synthetic tests. В исходном checkout installer и runtime лежат в соседних каталогах, а installed layout объединяет их; test launcher не добавил source plugin root. Исправлен только test entry point в новом артефакте. Evidence `build/failure-2aac2d66e75611464082796a.tar.gz`, SHA-256 `68d6d3fdd04be87a43d3d6efd86dda44ea7dc095648f1648e0b0a51fc934a9aa`; сохранён перед успешным `--clean`. Входной `.pyz` удалён. Пакет на Ubuntu не установлен.
**X4-B03 intent:** повтор B02 после source correction, прежний scope/ресурсные ограничения. Source ID `7c8e6ce00d7e0cb0c63191c1`, 58 277 776 bytes, SHA-256 `8a196ee8f056f8b8be510f6c04f52fadce761b691b78e4b8c4f0154f86adfacf`. Новая попытка не изменяет и не скрывает B02 evidence.
**B03 outcome:** 11:19:25.623230 → 11:19:42.436880 UTC, monotonic start 164673.50431959, 16.813655 s. Cold Python imports прошли. Static closure отверг необъявленную в проверяемом SONAME-наборе `libmvec.so.1`; `dpkg-query -S '*/libmvec.so.1'` подтвердил поставщика `libc6:amd64`. Пакет уже декларирует libc6, новый системный пакет не нужен. Исправлен проверяемый список библиотек. Synthetic tests ещё не запускались. Evidence `build/failure-7c8e6ce00d7e0cb0c63191c1.tar.gz`, SHA-256 `1ab4c2e04a2be6543b7d64bb608750d1cd42dc00b053ae8f664069fd0aaa1300`; attempt и входной `.pyz` очищены штатно после сохранения.
**X4-B04 intent:** тот же package-only scope; source ID `24058c4606136885fe5ede42`, 58 277 781 bytes, SHA-256 `ba2675891b018a7483437b3d3d1fd0e0f5bc32614d964cb3982fab95531a7579`. Исправление только declared OS library closure; никаких ручных установок на Mini.
Read-only PATH lookup не обнаружил Go/Node.js/npm на Mini. Это не зависимость готового operator installer; для будущей сборки обновлённого Node agent/UI потребуются закреплённые build-only toolchains внутри такого же временного артефакта, не системная установка.
**B04 outcome:** 11:24:13.877860 → 11:24:30.890647 UTC, monotonic start 164961.758949017, 17.012809 s. Cold imports и static closure прошли; 9/10 synthetic tests прошли. IPC test не создал сокет: длинный source-staging path превысил предел AF_UNIX. Исправлен только test fixture: сокет остаётся в том же owned staging, путь используется через открытый directory FD `/proc/self/fd/...`. Production instance paths укладываются в Linux limit. Evidence `build/failure-24058c4606136885fe5ede42.tar.gz`, SHA-256 `73a17dbef39f1c6bdc1f58c0f435b3518a4896287313f87b5e159df8544f6ab9`. Очистка попытки и входного файла выполнена после сохранения.
**X4-B05 intent:** тот же package-only scope, включая временный Unix socket теста, закрываемый в cleanup. Source ID `984a1c41adec9353c0505ff5`, 58 277 931 bytes, SHA-256 `2973a6fb3fd8ff71516a9e729286f277614edd538a21b805ac5228109740916c`. Установленная Ubuntu и камера остаются без изменений.
**B05 outcome:** успешно, 11:28:40.819158 → 11:28:57.684590 UTC, monotonic start 165228.700247659, duration 16.865456 s. Все **10/10** runtime/installer/IPC tests прошли, skips=0. Python imports выполнены из новой распаковки: aiohttp 3.12.15, aiortc 1.14.0, av 16.1.0, pydantic 2.11.7, cryptography 50.0.1, cffi 2.1.1. Static DT_NEEDED closure прошёл для **103 ELF**; это ещё не clean-OS qualification.
Собран `mission-core-insta360-x4_0.1.0_amd64.deb`, 58 189 546 bytes, SHA-256 `a8e1663db4e0ede3587c79c8539594ff4b8ab84ab59baef0a205f22cb6afa771`, runtime revision `56818763014b906ade1d6880`. Result archive SHA-256 `2db8190da83b2c1d13a0c1de6acc0499a58f0cb98cad0532375e21328bc73211`. Перенос обратно проверен по archive/binary hash и allowlist tar members. Evidence и пакет находятся в ignored `build/package-b05` и `build/result-984a1c41adec9353c0505ff5.tar.gz`.
Cleanup attempt и входного `.pyz` выполнен через штатный entry point после сохранения. Node/K1/RealSense active, NRestarts=0. **Пакет ещё не установлен; SDK ещё не загружался, камеры не открывались.**
## X4-P01 — штатный owner installer и первый SDK status
**Intent перед передачей:** release ID `2840e5ee1d8ec075442ef32f`, self-contained installer 58 204 569 bytes, SHA-256 `5966a4def2fd1d1aa5df78798204b5481cafcd41f4e568a5eabe0147aa2c9262`. Внутри ровно прошедший B05 `.deb`, `install_release.py`, terminal launcher `install` и проверяемый manifest; wrapper — `owner_release_entry.py`. Wrapper/self/payload hashes проверяются перед распаковкой. Переданные файлы не являются незадекларированными runtime prerequisites.
**Stage и plan:** обычный пользователь распаковывает только owned release в `/var/tmp/mission-core-x4-releases/<release_id>`; `--plan` выполняет APT simulation без package mutation. `--launch` открывает штатное локальное окно GNOME Terminal. Пароль Ubuntu получает только sudo в этом окне; SSH credentials/polkit policy/sudoers не меняются.
**Разрешённый installation scope после OS authentication:** точный `.deb` снова проверяется и копируется в root-only staging; APT `--no-remove` устанавливает объявленный пакет и необходимые его зависимости. Postinst создаёт пользователя брокера и USB-группу; пакет владеет code, payload, rules и units. Затем запускается **тот же**`mission-core-node-insta360-x4-prepare.service`, который вызывает штатная model-preparation команда. Он развёртывает проверенный runtime, предоставляет model-scoped USB permissions и запускает broker/supervisor/изолированные экземпляры. Первый SDK Open исполняется только непривилегированным worker после проверки USB/network isolation, а не SDK demo или root.
**Аппаратный профиль P01:** SDK connect и чтение состояния X4. Не отправляются preview START, SD START/STOP, photo, settings mutations, firmware, format/delete или power/reset. Проверка изображения/WebRTC остаётся отдельным следующим шагом. При неуспехе сохраняются private stdout/stderr/report и установленное состояние; не выполняется ручная починка. Полный report в root-only `/var/tmp/mission-core-x4-installs/<session_id>`с UTC/monotonic и hashes; временная root package copy удаляется, release для повторного штатного запуска остаётся.
**Граница версии:** P01 квалифицирует фундамент X4 package. Установленный Node 0.8.16 ещё не содержит новых исходников model registry/UI; его следующий versioned build и local/remote GUI acceptance не заменяются этим инженерным SDK-status запуском. Восстановление/удаление осуществляется package lifecycle с защитой активной записи и сохранением журналов/файлов камеры.
**Stage/plan outcome:** remote installer SHA совпал; штатный `--plan` распаковал release и завершился успешно: 0 upgraded, 1 newly installed (`mission-core-insta360-x4`), 0 removals. Рекомендация APT про autoremove не исполнялась. `--launch` успешно запустил локальное окно, launcher stderr пуст. На 11:45 UTC dpkg ещё не знает X4 package — ожидается локальная sudo authentication владельца. В чат пароль не запрашивается. Canonical Core `/api/health` operational/HTTP 200.
## X4-B06 — проверка декодируемого изображения в исходниках
**Intent перед исполнением:** build-only source ID `d10f549d3d6b79dd06bae68c`, 58 287 076 bytes, SHA-256 `e21ecb276ae7b1432af3503a94da3b26fdf3d7384b0fcadf4394f8f5eb464996`. Будущий package 0.1.1 добавляет fixed `verify`: требуется минимум два реально декодированных кадра; временный preview закрывается отдельно от SD recording, чужой уже идущий preview сохраняется, неподтверждённый STOP не становится успехом. Первые packet bytes не считаются изображением. В проверках генерируются только синтетические чёрные H264 frames внутри временного build runtime, реальная X4 не используется.
Та же Ubuntu, тот же private staging/ресурсные лимиты/очистка. Проверки B05 плюс три сценария image verification; vendor `.so` не загружается. Это не меняет уже переданный owner release P01: окно установки содержит прежний immutable пакет 0.1.0 для первого SDK status. Новые bytes не подменяются под прежней версией.
**P01 outcome:** владелец ввёл пароль только в Ubuntu и сообщил код завершения **0**. Независимая read-only проверка подтвердила dpkg `0.1.0 install ok installed`, fixed prepare `complete` (4.415 s), broker/supervisor и один изолированный X4 worker active, worker NRestarts=0. Подтверждение SDK status пока основано на сообщённом владельцем коде: installer выдаёт 0 только после prepared+online snapshot. Root report защищён; `sudo -n` из SSH не получил локальный terminal timestamp и корректно отказал без запроса пароля. Правила sudo/права отчёта не изменялись. Реальная проверка изображения ещё не выполнялась.
**B06 outcome:** 11:56:55.246863 → 11:57:12.359414 UTC, monotonic start 166923.127952935, duration 17.112573 s. **13/13 tests**, skips=0; cold imports/static closure также прошли. Package `mission-core-insta360-x4_0.1.1_amd64.deb`, 58 191 030 bytes, SHA-256 `aa76f1147e254356e9aba966374fa8a4283b22a63af88fef78c905539c8d235e`, runtime revision `c1fce07a4d4d9574dc1dccad`. Result archive SHA-256 `678c5c1bcb1d7d197e120972025e2b88443e54110c8d4c398509fc4d8a73fd4d`. Перенос/allowlist extraction/package hash проверены, evidence сохранено в ignored `build/package-b06` и `build/result-d10f549d3d6b79dd06bae68c.tar.gz`; source staging и входной `.pyz` очищены штатно. Сборка не загружала vendor SDK и не меняла установленный runtime.
## X4-P02 — обновление 0.1.1 и проверка реального изображения
**Intent до передачи:** owner release `2bb3c75add9c7434faab936f`, 58 209 738 bytes, SHA-256 `b23707067509b97ab6333b3d6dda003ccb0983507061483cb302b92f1da6ae37`. Содержит ровно прошедший B06 пакет, новый immutable manifest, launcher и fixed installer. Stage/plan не требуют root; APT simulation, syntax checks и локальная OS authentication предшествуют изменению пакета.
**Owning steps:** package lifecycle проверяет отсутствие активного preview/SD recording и неизвестного состояния; обновляет пакет, затем postinst исполняет штатную model preparation. Owner installer проверяет совпадение revision/complete, не запускает второй prepare одновременно с подключением worker. После SDK status один подключённый X4 получает версионированный `OperationRequest(verify)` с идентичностью устройства/сессии, operation ID и deadline; runtime сохраняет durable receipt до SDK effects. Проверка включает preview START при исходном idle, требует два декодированных кадра, в finally отправляет только preview STOP. Уже активный preview не присваивается; SD recording блокирует проверку, SD START/STOP, photo, settings.apply не входят в P02. Байты реального изображения не сохраняются. Сбой/timeout/неподтверждённый cleanup не считается успехом и автоматически не повторяется.
**Evidence:** installer-owned root report с UTC/monotonic/hash остаётся private. Обновлённый terminal launcher (`bash`, часть Ubuntu base) сохраняет stdout через `tee` в своём пользовательском release directory с umask 077; sudo получает пароль только из локального TTY. Installer печатает structured result и прежние private installation reports, чтобы владелец мог видеть итог без изменения root permissions/повторной root-сессии ради чтения. Это не общий/public endpoint. Известные приватные identifiers редактируются при переносе результата в Git ledger. Повтор release проверяет hashes; повтор завершённой аппаратной проверки — отдельная явно запущенная попытка, не автоматический replay команды. Автоматического downgrade нет; сохраняются журналы и старый runtime.
**P02 outcome:** успешен, 12:07:12.456435 → 12:07:24.842294 UTC, duration 12.385862 s. APT обновил только X4 0.1.0 → 0.1.1, без новых/удалённых OS packages. SDK подтвердил X4 firmware **v1.7.18**, connected=true, preview=0, recording=0, mode=7, codec=0, отсутствие battery/storage/temperature alerts. Fixed verify подтвердил **два декодированных H.264 кадра 2880 × 1440, stream 0**; 308 ms — длительность внутренней проверки, **не** glass-to-glass/WebRTC latency. SDK отдал разрешение, отличающееся от запрошенного 1920 × 960; actual dimensions берутся из decoder, а не из запроса. SDK stitching не вызывался, визуальная раскладка изображения пока не проверена. Успех verify включает подтверждённый STOP собственного временного preview; SD команды не выполнялись. Existing Node/K1/RealSense states и restart counters совпали с baseline; дополнительная SSH проверка показала active/NRestarts=0.
Private owner log сохранён в ignored `build/p02-owner-private.log`, mode 0600, SHA-256 `9564a8e9f580ff39304df7f5726a9e72a27b86ad5bb38b87b66cb74f283660b3`. В нём также прочитан прежний root P01 report: **complete**, 11:48:41.812153 → 11:48:55.269531 UTC, 13.457389 s, SDK prepared/online/preparation_safe true, preview/recording idle, existing_services_unchanged=true. Таким образом P01 теперь подтверждён самим артефактом, а не только сообщением владельца. Авторизация sudo не ослаблялась.
**Следующий source-only шаг:** Node-owned fixed `insta360_profile.py` и отдельный `...-profile.service` устанавливают встроенный hash-pinned `.deb` до вызова model prepare. Это устраняет first-use зависимость от заранее вручную установленного X4 package. Node build 0.8.17 должен нести пакет и его declared OS prerequisites; local/remote prepare направляются на один fixed unit. Эти исходники ещё не собраны/не установлены и не считаются GUI acceptance. Профиль проверяется synthetic cold/reuse/upgrade/corrupt/newer/refusal transactions без реального APT.
## X4-B07 — private media и first-use bootstrap qualification
**Intent:** build-only source ID `a5d9c073101f279c0278517b`, 58 302 852 bytes, SHA-256 `6dfd8bd59d081db68f93cbc27ea1047cf1838331cbc9b643a0fe50d1ca826532`. Source package 0.1.2; worker получает bounded encoded fanout и binary Unix IPC, broker — отдельный per-camera decoder/частный WebRTC carrier. Без stitching или SDK control из сетевого процесса. Media opening/cleanup не вызывает preview/SD START/STOP. Source namespace не меняется. Предлагаемый view profile сохраняет пропорции кадра, ширина до 1280, отправка до 15 Hz; это ещё не hardware FPS/latency acceptance. Runtime resource admission: максимум 4 peers на Mini и 2 на один physical session; это лимит активного просмотра, не inventory singleton.
**Qualification scope:** прежние 13 runtime/installer tests, 6 synthetic Node profile transactions и 5 media/IPC tests, включая настоящий H264/WebRTC encode/decode через UDP **только 127.0.0.1** с синтетическими 32 × 16 кадрами. Ни vendor SDK, ни реальная X4 не используются. UDP/Unix sockets и test threads создаются только этой проверкой и закрываются в finally; temporary fixtures принадлежат build staging. Сборочный entry point/лимиты/сохранение evidence/cleanup прежние. Хостовые пакеты, systemd rules, USB permissions и установленная 0.1.1 не меняются. Node 0.8.17 packaging/Go/UI в этот build не входят; проверяется только fixed Python bootstrap с mock APT/systemd.
**B07 outcome:** успешно, 12:26:51.786403 → 12:27:10.081551 UTC, monotonic start 168719.667492851, duration 18.295168 s. **24/24 tests**, skips=0, 1.325 s. Настоящий синтетический H264/WebRTC обмен прошёл целиком; неправильная camera/session не закрывает чужой peer; cleanup освободил sources/peers/Unix server/producer threads. asyncio debug сообщил о 0.472 s синхронного shutdown тестового сервера; это не потеря frame/failed test. Cold imports/static closure прошли.
Package 0.1.2, 58 197 134 bytes, SHA-256 `85418d34b1fe045cdc739781475019c6b14db52c83a58b9d42181f263a183b5f`, runtime revision `76960f247cf4413fc8464df8`. Result archive SHA-256 `c46f83d0c98dd11254c2801406903df256798dadb455320854d8be84eed1a16b`; архив/allowlist members/package hash проверены. Evidence в ignored `build/package-b07` и `build/result-a5d9c073101f279c0278517b.tar.gz`. Штатный `--clean` и удаление source `.pyz` выполнены после сохранения. **Пакет 0.1.2 ещё не установлен; реальная X4 остаётся на 0.1.1.**
## X4-B08 — соответствие контракту Core и большой список камер
**Intent:** source ID `38a9e66d32d65eebe44c5477`, 58 311 151 bytes, SHA-256 `93305ec7a11cb02844d12db8e3ebfe411cfc91ce9bfcc43f35da37642c64c5b8`. Package 0.1.3. До установки B07 в общую систему выявлены пропущенные обязательные `revision`/`observed_at` и неподдерживаемое контрактом acquisition `unknown`; новый runtime формирует revisioned snapshots и отображает неподтверждённый capture как `failed`, сохраняя исходный camera_status. B07 не заменяется новыми bytes под прежней версией.
Добавлены 3 synthetic проверки **реальных**`DeviceSessionSnapshot`/Core `validate_inventory`: idle/active/unknown/offline, 500 самостоятельных идентичностей и отказ 501, cross-node/duplicate rejection. Carrier limits теперь согласованы: model inventory ≤2 MiB, sensor state ≤3 MiB, paired HTTP body ≤8 MiB (с учётом существующего дублирования devices/sensor_state). Команды по-прежнему ≤64 KiB. Broker snapshot fanout имеет общий срок 2 s; зависшие отдельные worker не растягивают каждый inventory на десятки секунд. Это функциональная проверка 500 summaries, не нагрузочный тест 500 физических камер. Прежние 24 tests повторяются из-за изменения runtime/transport. Board scope/лимиты/evidence/cleanup как B07; SDK и установленная 0.1.1 не используются и не меняются.
**Подготовка будущего Node/Core build, пока только локальные входы:** versioned `fetch_linux_toolchains.py` получил официальные архивы Go 1.26.8 linux-amd64 (66 897 291 bytes, SHA-256 `d0f743b33e8d8945e6b1f432edd15785c70507121d6e2a723b21285eddf8b57b`) и Node.js 24.9.0 linux-x64 (32 131 120 bytes, SHA-256 `f52ec50e959d72d5c680d9731420b2661cd2a8070e94c7369b6ddfcd8b7278be`). URLs/hashes закреплены в `apps/node-agent/packaging/linux-toolchains.json`. Архивы только в ignored build cache на Mac; ничего системно не устанавливается. Будущий source artifact несёт их на Mini как build-only inputs и проверяет cgroup CPU/RAM/Tasks limits до исполнения. Это не меняет требования готового Ubuntu operator installer.
**B08 outcome:** complete, 12:57:08.374814 → 12:57:26.644704 UTC, monotonic start 170536.255904509, 18.269912 s. 27/27 tests, skips=0, 1.253 s; cold imports и 103 ELF closure прошли. Package 0.1.3: 58 197 472 bytes, SHA-256 `0232f937e3173d56b76bbc53609a7719f09ce68c1b1f32130576b79a6f764251`, runtime revision `8681aaafe9a2c337dd691af1`. Result archive SHA-256 `429cadbc65a481dd5280a3d3cc0cf3382cd6d787b7622bd7593e919b7ed01147`; локально проверены hash, все пять allowlist tar members и package hash. Evidence: ignored `build/package-b08` и `build/result-38a9e66d32d65eebe44c5477.tar.gz`. Установленная X4 по-прежнему 0.1.1; B08 не является аппаратной проверкой новой версии. Разрешена штатная очистка этого attempt после сохранения evidence.
## X4-N01 — Node/Core build на той же Ubuntu
**Владелец изменений:** `apps/node-agent/packaging/build_linux_source.py`, `linux_build_entry.py`, `linux_build_job.py`. Артефакт содержит hash-pinned portable Go/Node, полный source snapshot, закреплённый DG source и runtime inputs RealSense/X4. Только private `/var/tmp/mission-core-node-builds/<source_id>` и transient user systemd unit; OS packages, работающие runtime/services/USB не изменяются. На чистой операторской Ubuntu эти toolchains не требуются: Node installer несёт готовый бинарник, UI и X4 package.
**До исполнения:** Mini имеет 6 033 448 KiB available RAM и 434 301 714 432 bytes свободного диска. Сборка последовательная, user cgroup MemoryMax=2 GiB, CPUQuota=150%, TasksMax=256, RuntimeMaxSec=1200, Nice=10; фиксированный job проверяет фактические cgroup limits прежде чем компилировать. Кэши, временные файлы и npm dependencies принадлежат attempt. `npm ci --ignore-scripts` использует только package-lock и public registry.npmjs.org; upstream toolchain extraction проверяет hashes/paths/size. Не используется Docker, Worker 006, системный apt/pip/npm или SDK Open.
**Проверки:** Go race tests, Node UI tests/typecheck/build, статический Go binary и Node 0.8.17 deb; затем Core architecture/typecheck/tests/build. X4 first-use package уже B08-qualified. Core UI расширяет существующий detail устройства через существующие DG controls; новых workspace/navigation/product roots нет. Временная попытка удаляется штатным `--clean` только после сохранения evidence; при неуспехе source snapshot не правится на борту, исправляется входной artifact.
**N01 artifact до передачи:** source ID `7a3308e89828907e30f7ccf9`, 2591 files, 307 793 017 bytes, SHA-256 `144d208f4a48eca58ac64a87e61d56114f5e1101208e2ce5fb91cdb57730047a`. B08 штатный cleanup выполнен. Canonical Core `/api/health` operational=true непосредственно перед сборкой; он остаётся работающим.
**N01 outcome:** error, 13:05:35.209654 → 13:06:58.417317 UTC, monotonic start 171043.090754359, 83.207659 s. Фактические cgroup limits соответствуют manifest. Go toolchain корректный. `go test ./...` встретил отсутствующий `web/dist` (порядок job должен сначала собирать настоящий UI), а старый `TestSensorConfiguredIdentitySurvivesRestartAndDisconnect` при read-only OS discovery увидел реальную подключённую X4 и получил два устройства вместо одного synthetic. SDK не загружался, camera command этой X4 не посылался; исправление — отдельные synthetic USB roots и mock transports всех моделей в старых sensor fixtures. Evidence сохранено в ignored `apps/node-agent/build/n01-failure` (report, qualification, stdout/stderr jobs). Установка не начиналась, runtime не менялся.
**N02 intent:** те же limits/ownership; сначала npm/Node UI build, затем Go race tests с настоящим embedded dist, Node binary/package, Core checks/build. Старые sensor fixtures теперь полностью изолированы от sysfs и private model sockets. Node package lifecycle дополнительно отказывает в обновлении во время активного fixed X4 profile job. Исправляются versioned sources на Mac, не staging на Ubuntu. Перед новой попыткой N01 удаляется штатным `--clean` после сохранения evidence.
**N02 artifact:** `cdb7d2e96a0bbe7c98bbae0a`, 307 793 942 bytes, SHA-256 `54a9a2dedf11b0f494f71e8534fdaaa51e8315a77878a85dc6f055180e27d3fd`. N01 cleanup confirmed. Установка Node/X4 по-прежнему не начинается этим build artifact.
**N02 outcome:** error, 13:11:26.638938 → 13:16:44.175522 UTC, 317.536586 s. npm скачал закреплённые tarballs с HTTP 200, но `npm ci` не завершился за 300 s; причина зависания ещё не подтверждена. Job завершён ограниченным timeout, runtime не менялся. Evidence в ignored `apps/node-agent/build/n02-failure`, включая npm log; последующая запись job state теперь отмечает timeout явно. Отдельная ревизия исходного build обнаружила пропущенные prerequisites DG: нужен его собственный workspace lock и сборка generated dist/transitive dependencies, а не symlink к node_modules потребителя. Это исправлено в источнике N03, без копирования Mac node_modules или изменения Ubuntu вручную.
**N03 intent:** тот же Ubuntu build envelope. Артефакт включает DG root package/lock/tsconfig и catalog workspace manifest; сначала `npm ci --ignore-scripts` по собственному DG lock и `build:packages`, затем прежние Node/Core jobs. Пакеты DG собираются из закреплённого source, SDK не загружается. Добавлены четыре UI model tests: отдельная SD recording при idle preview, stale/unknown status, unenrolled new camera и actual resolution labels. N02 удаляется только штатным cleanup после сохранения evidence.
**N03 artifact:** `0a8e5a51f84e8f468e80295e`, 2599 files, 307 824 740 bytes, SHA-256 `68c202a8e2d6f6377e6651e2c8316768c1aafa5dc8e169ae1fc6cbb486b669b6`. N02 cleanup confirmed. Новые Node owner-release scripts пока только source: они устанавливают готовый Node `.deb`, проверяют dpkg/UI, оставляют X4 prepare штатной кнопке приложения; пароль принимает только локальный sudo TTY. Stage/plan/hardware acceptance этой поставки ещё не выполнялись.
**N03 outcome:** error, 13:21:16.138116 → 13:22:05.805234 UTC, monotonic start 171984.019205324, 49.667122 s. DG npm ci (6.968 s), все пять package builds (17.567 s), Node npm ci (2.432 s) и Node UI boundary test прошли. Зависание npm из N02 не повторилось. TypeScript Node выявил существующую зависимость shared Rerun components от отсутствующего Core/node_modules; X4 UI ошибок типов не показал. Evidence сохранено в ignored `apps/node-agent/build/n03-failure`. SDK/runtime/OS не менялись.
**N04 intent:** прежний build envelope, исправлен Node TS path для уже объявленного `@rerun-io/web-viewer` и его Vite dedupe. Таким образом shared components используют собственный пакет Node UI, без требования установленного Core/node_modules. Dependency versions не меняются. После сохранения N03 evidence выполняется штатный cleanup, новый artifact собирается из изменённых исходников.
**N04 artifact:** `6c3d626e77e6c84c266a4ca1`, 307 825 310 bytes, SHA-256 `80547a77b09384dcf11cde30c157d82feeae34fd6ec907c19ea3fdbfcf3ef53d`. N03 cleanup confirmed; source-only изменения не объявляются установленным продуктом.
**N05 intent:** N04 снова задержался на npm transport после успешного DG build; SDK/Node runtime не меняются. Исправление ограничено объявленной командой `npm ci`: prefer-offline для существующего проверяемого integrity cache, максимум четыре соединения, 20 s fetch timeout и один retry с 1–2 s backoff. TLS и package-lock integrity не ослабляются; версии не обновляются. Новый запуск допускается после завершения/сохранения/штатной очистки N04. Приоритет владельца после замечания о длительности: один сквозной X4 → WebRTC → Core и start/stop SD recording, без добавления новых функций до этого результата.
**N04 outcome:** error, 13:26:21.780144 → 13:32:04.505728 UTC, 342.725581 s; Node npm transport timeout 300.093 s. DG ci/build прошли. Сохранены output/report/npm logs в ignored `apps/node-agent/build/n04-failure`; штатный cleanup confirmed.
**N05 artifact:** `b4926dfd7f02a24c56e140dc`, 307 825 766 bytes, SHA-256 `890a72a02d0f2995a6dcc00594b8f0d8ea5c6aa8d41a5db9d1a11073dbb1518c`. Исполняется только build artifact; установленная Node 0.8.16 и X4 0.1.1 сохраняются до отдельной поставки.
**N05 outcome:** error, 13:34:43.383352 → 13:35:38.563349 UTC, 55.180005 s. DG ci/build прошли; Node npm завершился за 12.391 s с `read ETIMEDOUT`, незавершённый fetch `react-dom` (TLSWrap). Это подтверждённая сетевая ошибка, не ошибка камеры. Evidence сохранено в ignored `apps/node-agent/build/n05-failure`. N06 допускает до трёх повторов только ETIMEDOUT/ECONNRESET/EAI_AGAIN с тем же lock/cache и отдельными логами каждого шага; остальные ошибки не повторяются. OS/runtime и версии зависимостей не меняются.
**N06 artifact:** `2ef7976017402e852b0166bc`, 307 826 401 bytes, SHA-256 `276a8a418223962e6d2b98e411abe6198339096f60efbbf0a573af9e90f2f633`. N05 штатный cleanup confirmed. Core 8000 operational и paired board online подтверждены read-only API; sandbox-denied loopback requests не являлись отказом Core. Mac swap дважды 3047.31 MiB без роста, Docker backend отсутствует; открыт один временный background Core tab без acquisition для последующей UI проверки.
**N06 outcome:** error, job 13:41:13.036082 → 13:46:43.329722 UTC, 330.293653 s. Node UI tests/build, Go race tests, binary/deb, Core architecture/typecheck прошли. Core 820 tests: 819 pass, один существующий K1 native-RRD test требует отсутствующий developer `.venv`с Python/Rerun. Не является X4 regression; отдельная K1/RRD qualification остаётся открытой. Приватные output/report сохранены в `apps/node-agent/build/n06-failure`. Установка не начиналась.
**N07 intent:** прежний artifact-owned build envelope и очистка N06 после evidence. Исправлена необходимая миграция X4 0.1.1 → 0.1.3: старый broker без revision/observed_at не должен ломать весь paired inventory Core; USB discovery сохраняет устройство и команду prepare, а отказ старого runtime прерывать acquisition сохраняется. Добавлен focused Go regression test для idle/live/unknown. Единственный K1 RRD-generator test явно исключён из этого build (имя/причина в qualification.json), остальные проверки сохраняются. Отдельное окружение Rerun не становится скрытой зависимостью X4 installer. SDK и рабочие службы не затрагиваются.
**N07 artifact:** `243ffd387bc86c6fe73a26d7`, 2599 files, 307 827 985 bytes, SHA-256 `6287665afc08121679f54d8d21d9311446848e5a41704028a7a4f14a8bccd1f2`. Только временная сборка и synthetic checks; установка/SDK-команды отдельно.
**N08 intent (после завершения N07):** N07 опять задержался в npm после получения tarballs с HTTP 200; встроенный fetch timeout не гарантирует выход самого npm. Versioned job теперь ограничивает каждый `npm ci` 45 s и допускает до трёх последовательных повторов также после subprocess timeout, сохраняя integrity cache внутри attempt. `subprocess.run` завершает и дожидается собственного npm до retry; compiled/runtime packages и камера не затрагиваются. Без сохранения N07 evidence и штатной очистки новый build не начинается. Остальные входы и проверки N07 сохраняются.
**N08 artifact:** `511010461b4f2cd4c0546af9`, 2599 files, 307 828 406 bytes, SHA-256 `bc2a1763c5696633883d513ee3ea060fa72800e73a1f9d15f300db606624bbae`. Передача допустима до завершения N07, исполнение только после его завершения и сохранения/очистки.
**N07 outcome:** error, 13:50:27.293476 → 13:55:27.394635 UTC, 300.101156 s. Первый DG npm ci завершён subprocess timeout 300.087658 s; до компиляции не дошёл. Output/report сохранены в ignored `apps/node-agent/build/n07-failure`; N08 запускается после штатного cleanup. Это build transport failure, не аппаратный тест и не изменение runtime.
**N08 outcome до recovery:** Node UI/Go race tests/package и Core architecture/typecheck прошли; 819 Core tests выполнены и прошли, один legacy K1 generator case excluded явно. Production Core build завершился кодом 134 после 109.008607 s: V8 heap 1024 MiB исчерпан. Это ограничение build job, не runtime камеры. Read-only checkpoint подтвердил неизменность всех 2599 входных файлов (`changed=[]`), source manifest SHA-256 `511010461b4f2cd4c0546af946adcb696a03d3134dc0f68c4b5c62b8bc57d766`, failed qualification SHA-256 `e5481d0cb9e2799ffe2ca4ec60390d1557e363b93e192e52df92e58fae3d21e6`. Готовый Node 0.8.17 package SHA-256 `f929c440e4965f728aa6cd00eb122e7cad09e5ade82da763cc36661f50ec66b5`; ещё не установлен.
**N08-R1 intent:** фиксированный versioned `packaging/resume_core_n08.py` допускает только этот checkpoint и неизменные исходники/Node package. Повторяется исключительно `npm run build` Core с уже установленными в attempt зависимостями. Отдельный transient user cgroup MemoryMax=3 GiB, CPUQuota=150%, TasksMax=256, RuntimeMaxSec=300; V8 heap=2048 MiB, core dumps disabled. До исполнения MemAvailable=5 957 952 KiB. Никакого apt/npm ci/Go tests/SDK/изменения системных служб. Failed qualification копируется неизменно, recovery имеет свой отчёт и UTC/monotonic timestamps; итоговый report сохраняет прежний failed step. Очистка исходного N08 attempt только после сохранения полного результата. Это восстановление build после resource limit, не повторная qualification оборудования.
**N08-R1 artifact:** 7 223 bytes, SHA-256 `8c34ac32e4653b8ba2343a2f35ded6f7228347d57669e503f73f9605c3f89d63`; hash проверяется перед исполнением на Mini. Последующий `--clean` исходного N08 и удаление точного recovery `.py` разрешены после сохранения результатов.
**N08-R1 outcome:** complete, 14:09:53.144193 → 14:10:59.729997 UTC, monotonic start 174901.025258714, 66.585874 s. Реальный cgroup memory.peak=2 758 029 312 bytes (вывод systemd после завершения не подменяет этот peak). Core production build прошёл. Result archive SHA-256 `29ee5f78e03b3eb7ba14c1c1d97aa2d4b6eb3cf924a752afbcdf4d1454624bfa`; проверены все 37 regular flat members и hashes обоих продуктов. Core dist: 23 066 271 bytes, SHA-256 `31b2e9bed932ec4c15ecdcf90e8f8e0fc6b6c6043b28e627a370d104ea6db8fa`; Node 0.8.17: 168 247 014 bytes, SHA-256 `f929c440e4965f728aa6cd00eb122e7cad09e5ade82da763cc36661f50ec66b5`. Evidence в ignored `apps/node-agent/build/qualified-n08`; original failed report сохранён, K1 RRD generator acceptance остаётся открытой.
**P03 Node owner release intent:** `mission-core-node-install-4e4bb2a5fa0336177a95e47c.pyz`, 168 261 867 bytes, SHA-256 `1df5de35d573ef6afe951bc1e8aa2331d5111776912ab55601e156453a2c2540`. Shared versioned launcher stage/plan, затем только локальный Ubuntu sudo TTY. `install_owner_release.py` проверяет Ubuntu/bytes, APT no-remove/no downgrade, существующие service guards; пакет Node обновляет бинарник/UI и несёт X4 0.1.3 в профиле. X4 init отдельно через приложение, не через SSH-команду SDK. После установки проверяются dpkg/service/local HTTP, отчёт private. Длительный APT не убивается observer timeout. Повтор штатным installer, downgrade не выполняется автоматически. Существующие Node/K1/RealSense могут штатно перезапуститься при Node upgrade, только после idle checks.
**Core activation intent (Mac):** Ubuntu-built dist заменяет исключительно canonical Core 8000 UI, предыдущий dist сохраняется в ignored `apps/node-agent/build/core-ui-before-n08`. После hash/path проверки архива выполняется замена с возвратом backup при файловой ошибке и restart точного launchd `com.nodedc.mission-core.local`, чтобы активировать изменённые Python sensor actions. Другой backend не запускается; 8000 должен быть operational после изменения. Перед browser QA memory free=53%, swap=3047.31 MiB без роста, Docker backend отсутствует, 8765 не слушает. Это не hardware acceptance.
**P03 plan / Core activation:** APT simulate: только `mission-core-node` 0.8.16 → 0.8.17; 0 new, 0 removals. Архив Core проверен, 407 regular files активированы; backup сохранён. Canonical launchd перезапущен; `/api/health` HTTP 200, `ok=true`, `readiness.operational=true`, новый единственный listener 8000 подтверждён. Первичный observer ошибочно проверял top-level operational; исправлена read-only проверка существующего nested поля, повторного рестарта не потребовалось. Пакет Node ещё не установлен. Разрешён `--launch` P03 для локальной sudo-аутентификации владельца.
**Build source follow-through:** основной будущий build entry теперь использует подтверждённый N08-R1 envelope 3 GiB и Core V8 heap 2048 MiB; npm timeout/retry уже включены. Это перенос проверенного recovery-параметра в штатную сборку, не изменение уже квалифицированных Node/Core bytes. Отдельный полный повтор не требуется: все исполняемые продуктовые исходники N08 остаются проверенными, hashes поставки прежние. P03 window открыт; пароль/ответ пользователя не читаются и не передаются через SSH. Browser reload Core успешно открыл новую production UI.
**P03 installation finding:** пароль владельца принят; dpkg сообщает 0.8.17 `half-configured`, Node/K1/RealSense уже active. Дерево процессов конкретной транзакции: installer → apt-get → dpkg → postinst → setup-monitor → runuser → psql → pager. `install-output.log` пока пуст, поскольку wrapper буферизует subprocess output. Причина остановки — интерактивный psql pager при настройке существующего monitoring DB, не X4 и не неверный пароль. Источник installer исправлен: все три штатных psql запуска имеют `-P pager=off`; owner wrapper также отключает dpkg pseudo-TTY, задаёт cat pager и печатает начало каждого шага. Это должно войти в следующую packaging revision, без пересборки уже проверенного Go/UI.
**P03 owner continuation:** владельцу предложено нажать `q` в уже открытом pager. Это завершение UI просмотра в текущей транзакции, не SIGINT/kill APT и не ручное изменение Ubuntu-конфигурации. До dpkg `install ok installed` и подтверждения завершения текущего installer X4 prepare не запускается. Исправление pager должно быть доставлено через обновлённый `.deb`, а не правкой установленного setup-monitor по SSH.
**P04 packaging-only recovery intent:** Node package `0.8.17-1` сохраняет без изменения квалифицированные N08 binary/UI/X4/RealSense payloads. Versioned `repack_node_n08.py` проверяет исходный package hash и разрешает только три `-P pager=off` вставки в setup-monitor плюс packaging provenance. Новый package: 168 247 226 bytes, SHA-256 `7033ad608765231b20773dee45edac3d8f63e65525410de2346c79b3f8756a4b`. Это Debian packaging revision, binary version остаётся 0.8.17. Полной перекомпиляции и повтора прежних UI/Go tests нет; квалификация исправления — реальное завершение installer.
**P04 owner release:** `a8499c58b36182545d940e3d`, 168 266 648 bytes, SHA-256 `bb0fa7247ca668c91e0b816b30a1ccb7f3280e81ea3f8781157dc2f517f62866`. Из-за скрытого APT pseudo-TTY клавиша q в родительском окне не достигла pager. Новый fixed root installer до своего APT допускает восстановление только подтверждённой 0.8.17 half-configured транзакции: exact SQL schema/DB socket/process ancestry, root-stage path и исходный package SHA. Через pidfd/SIGTERM закрывается исключительно дочерний pager; не APT, dpkg, psql или PostgreSQL. Затем ожидается штатное завершение прежнего dpkg (≤45 s). Любое несовпадение — отказ без сигналов. Текущие source fixes отключают paging и dpkg PTY, печатают этапы; APT lock wait=45 s. Root нужен только через новый локальный Ubuntu sudo TTY; SSH escalation не даёт sudo-права и не обходит этот контроль. X4 prepare всё ещё не запускается.
**P04 plan accepted:** APT simulate показывает upgrade только Node 0.8.17 → 0.8.17-1, 0 new/removals, и ожидаемую одну незавершённую старую установку. Recovery должен завершить её перед новым APT. Разрешён launch фиксированного release `a8499c58b36182545d940e3d`; root пароль вводится владельцем в новом локальном TTY. Пользователю прямо сообщено не запускать X4 preparation до этого завершения.
**P04 handoff state:** новое owner окно открыто; обе private output files пока без результата, dpkg по-прежнему 0.8.17 half-configured. Выполнение recovery ещё не подтверждено; root-авторизация ожидается в новом локальном TTY. Core 8000 UI и карточка отдельной X4 доступны; кнопка prepare в нашей проверке не нажималась. Все N08 temporary build sources/toolchains/cache на Mini очищены штатным artifact cleanup, qualified package/logs сохранены локально.
**P04 outcome:** complete, 14:33:05.090823 → 14:33:21.157956 UTC, monotonic start 176292.971925536, 16.067142 s. Fixed recovery закрыл только подтверждённый legacy pager; прежний 0.8.17 dpkg штатно завершился. Новый package 0.8.17-1 `install ok installed`, UI8780 ready. Node/K1/RealSense active, NRestarts=0 до/после. Новая установка не зависла на psql. Это реальная проверка исправления на той же Ubuntu через тот же owner installer. Пользователю теперь сообщено, что можно нажать подготовку X4 и закрыть console с кодом0.
**PREP01 intent:** пользователь запускает штатную кнопку «Подготовить и проверить» для обнаруженной X4 в paired Core. Команда должна пройти Core → Node → fixed bundled profile: X4 package0.1.1→0.1.3, аппаратная проверка только выбранной камеры, возвращение verified state. Предыдущий Node APT завершён. Guard профиля/пакета проверяет idle preview/recording, model bytes/hash закреплены B08; неизвестное/активное состояние отказывает в обновлении. Никаких ручных SDK/root calls через SSH. При verify временный preview должен штатно остановиться; SD запись этим шагом не начинается. Следующие отдельные live/SD tests допускаются лишь после фактического результата preparation.
**PREP01 execution routing:** после P04 completion и предоставленной пользователю возможности нажать кнопку состояние Core остаётся «Требуется подготовка», активная подготовка не отображается. В рамках ранее разрешённой реализации агент выполняет ту же штатную UI-команду Core сам; пользователю сообщено больше не нажимать кнопку. Это существующий versioned профиль, SDK binary тот же pinned/ранее открытый в P02. Аппаратные границы PREP01 не меняются.
**PREP01 outcome / D01 intent:** Core UI command reached Node; bundled platform/payload validation passed, package step failed after 1.445486 s before dpkg unpack. Installed X4 remains 0.1.1; Node0.8.17-1 and camera services active. APT simulate admits only X4 0.1.1→0.1.3, but this is not execution evidence. Exact stderr is root-private; ordinary SSH read returned Permission denied. D01 versioned read-only diagnostic `diagnose_x4_profile.py`, artifact SHA-256 `cf6513863701cd65d41cdea24209b0591855ff1837776f30ddfe52163986c439`, 4761 bytes, opens a local Ubuntu sudo TTY and reads ONLY latest failed X4 profile plus first stdout/stderr (bounded, root ownership/no-symlink checked). No apt, service, SDK or configuration change; only private owner diagnostic staging/output. Idempotent read, no rollback required. Root authentication remains with owner; private report excluded from Git. No blind preparation retry.
**D01 outcome / P05 check intent:** read-only owner diagnostic succeeded 14:55:28.952343 UTC; real stderr: `E: Internal Error, Pathname to install is not absolute` for bundled X4 0.1.3. No dpkg unpack happened. The profile now uses fixed `/usr/bin/dpkg --install` on the same hash-verified local bundle; Node declares all model OS dependencies, no downloads/removals/force options are added. Existing dependency/lock and model idle guards remain. Narrow synthetic cold-host/reuse/upgrade/corruption/downgrade/failure checks run on the same Ubuntu via disposable unprivileged artifact mission-core-x4-profile-check-a057e61cd4a8c8e2b38354a1.pyz SHA-256 011efdc28b6c2b79baba1d89de45ab7892fb6992e164cba5fe787aa43f616505. Artifact writes only private temporary test fixtures and removes them at completion; no real package manager, service or camera command. P05 will be packaging revision 0.8.17-2 with qualified binary/UI/model bytes unchanged; no full build.
**P05 package/release:** six targeted profile tests passed on Ubuntu at 14:58:44.914558 UTC, monotonic177832.795648471, duration0.435072 s; temporary fixtures removed. Package `mission-core-node_0.8.17-2_amd64.deb`:168247482 bytes SHA-256 `f257d707acdbeea6c976bcd59b73a737cf71a1a86eefb2257856c04759f4e74a`. Owner release `c6e63be6a32780e03164da33`:168266904 bytes SHA-256 `3133070baae2182f73f4d2630314a2f19d2c1fe5cf17c027c3ff10e28a3d3f17`. Repacker admits only installed profile and provenance changes relative to qualified0.8.17-1; Go binary/UI/model payload unchanged. Standard owner release stage/plan then local Ubuntu sudo install; no SSH system edits. Expected only Node0.8.17-1→0.8.17-2 upgrade, no additional packages/removals. Existing idle guards/service acceptance remain; no camera recording/view command during Node upgrade. Model preparation will be retried separately through Core only after Node install succeeds.
**P05 handoff:** APT plan confirmed only Node0.8.17-1→0.8.17-2, 0 new/removals. Fixed owner window launched; latest observer sees sudo awaiting authentication and empty installer output, no root installer child. Owner asked for local password with explanation that D01 was read-only and installation is a distinct privileged operation. Source Ruff and diff whitespace checks pass. No repeat Core prepare until successful P05 receipt. D01 private raw evidence saved in ignored build directory; only formatting of diagnostic source was subsequently changed.
**P05 outcome / PREP02 intent:** Node0.8.17-2 installation complete 15:03:15.263303→15:03:34.698069 UTC, monotonic178103.144407403,19.434769 s. Package SHA f257d707acdbeea6c976bcd59b73a737cf71a1a86eefb2257856c04759f4e74a; UI8780 ready, Node/K1/RealSense active NRestarts0. X4 broker/supervisor active NRestarts0. Agent retries the same Core UI preparation command under the corrected bundled profile. Exact X4 package0.1.3 and preparation/idle guards unchanged; temporary verification preview only, no SD recording. No new privileged shell invocation.
**PREP02 outcome / LIVE01 intent:** remote Core prepare completed; bundled profile6.346136 s, package0.1.3 installed, platform/payload/package/prepare and selected-camera verify complete. Core fresh inventory15:05:53 UTC confirms configured/prepared/verified=true, connected=true, preview=0, recording=0, mode7, battery100, no storage/temperature/battery alerts, free52,381,351,936 bytes. Private inventory receipt saved under build/acceptance-core. Agent opens existing X4 detail and starts its preview from Core, then validates actual rendered WebRTC frames. A short owned SD start/stop may follow only while recording=0 is fresh, using existing UI durable operations; files list read confirms output. Preview and recording are independent; stop only the test-owned sessions, no file deletion/settings mutation.
**LIVE01 / SD01 observed:** real browser video 1280×640, readyState4, paused=false; currentTime33.026→52.938 s after SD stop, status direct live. First viewer initially had no frames for several minutes; frames appeared during the SD test, causal link not established. Do not treat this as measured low latency or silently accept first-start behavior. SD record.start and record.stop both complete, recording=true then false; stop returned one camera file, catalogue read total2. Private receipts saved build/acceptance-core/sd01.json. Closing and reopening only viewer while preview stays active produced a new live1280×640 session (currentTime34.045 s); closing peer did not stop camera preview or start recording. Next bounded check stops owned preview and restarts it through Core with SD recording remaining0, to distinguish first-start from attachment behavior.
**LIVE02 finding / B09 intent:** a fresh preview start without SD recording reproduced no browser frames; test-owned preview stopped through Core, recording remained0. Code inspection found that a late decoder can miss initial SPS/PPS/VPS when the short media queue evicts them. B09 retains only bounded codec parameter sets per stream/generation and prefixes missing sets to keyframes; no old media replay, extra SDK commands or additional recording. Real H264 late-decoder regression plus generation/device/stream isolation and bounded HEVC parameter cases added. X4 Debian revision0.1.3-1 preserves model protocol version0.1.3 and native binary; bundle revision now also binds runtime Python source hashes. Node bootstrap accepts validated Debian revision. Versioned Ubuntu package/check artifact a6a2d4cb1256a5394f23c9e2,58313011 bytes SHA5475de668d7f05c3b1445836ff6d1191eb56539749a20a6a5410d755156c1b19; unprivileged bounded staging, no SDK/USB/system changes. Build result and logs retained privately, staging removed with artifact cleanup. Only model package checks, no full Node/Core build.
**B09 complete / P06 intent:** Ubuntu31 tests pass (including H264 late decode after initial-header eviction), cold imports and ELF closure pass;18.450341 s,15:20:00.353417→15:20:18.803735 UTC. X4 package0.1.3-1 SHA c11977a4d4c9779b96ee38ff3a474bdd820d9e3e5ecc642e7711762def14b6da,58197966 bytes, revision84fa44e75eb2f23e384d0229. Node0.8.17-3 repack changes only profile Debian-version parser, bundled model package/profile and provenance; Go/UI unchanged. Local staging-copy tail initially lacked build/model-packages directory after package/report were already complete; directory creation fixed, qualified output hashes rechecked, no Linux/package rebuild or installed-host repair. Owner release b4bda477f12f2e5327e6b14a,168267688 bytes SHA a335bcfe2fac91438f59f05b8cc8ccec9fff2e5e15c73e5b95c59cdd01c2831c. Standard stage/plan/local sudo install updates Node, then Core Settings → Update runs same fixed X4 profile. No SDK/native binary change or full build. Preview/recording must remain idle for guards. B09 temporary build tree removed through artifact cleanup.
**P06 plan/handoff:** Node package0.8.17-3 SHA00f4baefd0c6f4e8f56bbf881329dfd36935e2334f35e2d17eb685a969d4c181,168248266 bytes. APT simulate: only Node0.8.17-2→0.8.17-3,0 new/removals. Fresh Core inventory confirms preview0,recording0,online=true,preparation_safe=true. Local owner installer launched and password requested; no claim that B09 hardware fix is installed yet. Core application prepare/update will follow successful Node receipt, and hardware first-start acceptance remains open.
**P06 outcome / PREP03 intent:** Node0.8.17-3 complete15:50:50.181477→15:51:04.559699 UTC,monotonic180958.062585037,14.378230 s. Package SHA00f4baefd0c6f4e8f56bbf881329dfd36935e2334f35e2d17eb685a969d4c181; UI ready, Node/K1/RealSense active NRestarts0. Agent applies bundled X40.1.3-1 via Core device Settings→Update, then checks selected-camera verify and a fresh preview with SD recording0. Old agent browser tab was closed between turns; one new visible tab opened on canonical Core8000, no duplicate backend. No additional SD recording or root command.
**PREP03/LIVE03 outcome / B10 intent:** X40.1.3-1 profile installed successfully6.854166 s, revision84fa44e75eb2f23e384d0229; prepare+selected verify complete. Fresh preview without SD still produced no browser frames. Its private ICE sockets remained alive beyond the30s no-keepalive watchdog, and separate worker verify on the running preview failed; initial prepare-time verify had passed. B09 header retention alone did not solve hardware first-start. Test preview stopped from Core; recording0. B10 primes one decoder before explicit preview.start, shares it across viewers while capture is active, releases it after explicit preview.stop or confirmed ended/stale source; no SD or implicit camera commands. Source count≤4 is active-media resource admission, not inventory capacity. Per-device locks preserve independent control, worker operation journal still owns SDK effects. H264 codec preferences moved before SDP offer processing (prior answer could select VP8). New real loopback regression delays viewer beyond64 packets with only one initial keyframe, verifies video and peer-close/source lifetime. B10 artifact c374803e8a07c6f47fa8ddc7,58314672 bytes SHA46fea4b8c307eee96f9c08b1ffb9837830ee6f23bf49ee4c4c565e9115e79293: same bounded unprivileged Ubuntu package/test workflow, no SDK/USB/system changes during build.
**B10 complete / P07 intent:** Ubuntu33 tests passed in4.585 s; package/check job21.611715 s,16:05:44.593351→16:06:06.205046 UTC,monotonic181852.474440456. Real H264 late-viewer test uses one initial keyframe, starts decoder before capture, delays viewer beyond queue eviction, receives frames, keeps source after peer close and releases it explicitly. Broker prime→SDK START and SDK STOP→release ordering passes. X4 package0.1.3-2:58198804 bytes SHA2931a5206478fcac67f74bd1fb579b98c0fcc43eda4c05e5ac4a721947619130,revisionf78a7ae557e3371022869025. Node0.8.17-4 packaging only:168249190 bytes SHA9369c7938fec608e13a80245d6a348a776d6766fa7e167abfda62178fcab3fe5,Go/UI/bootstrap unchanged, model bundle/profile/provenance updated. Owner release038e72273d8864b3f489099d:168268631 bytes SHAd85fb448365e21c490f496c0206dfeb9b726117efc5f4595504765204b6b6603. Installer window now includes validated package version to distinguish old consoles. Standard stage/plan/local sudo, then model update via Core; idle guards retained, no SD test repeated. B10 temp tree removed by artifact cleanup. Hardware first-start acceptance remains pending.
**P07 handoff:** APT plan admits only Node0.8.17-3→0.8.17-4,0 new/removals. Fresh Core status:preview0,recording0,preparation_safe=true. Owner console with exact version in title opened; local sudo password requested. No claim that the new decoder timing is installed or hardware-qualified. Next: successful Node receipt → Core Settings/Update → initial image verify → fresh preview first-frame test without SD recording.
**P07 complete / PREP04 intent:** read-only SSH confirms Node0.8.17-4 installed; owner installer complete, 16:21:06.534073→16:21:21.144176 UTC, monotonic182774.415176486, duration14.610095 s. Package SHA9369c7938fec608e13a80245d6a348a776d6766fa7e167abfda62178fcab3fe5; UI ready and Node/K1/RealSense active, NRestarts0. X4 remains0.1.3-1 until the next model preparation. Invoke the existing Core8000 device Settings/Update operation for the selected X4; fixed profile installs bundled B10 package0.1.3-2 and performs its selected-instance verification. Then explicit preview START without SD recording, inspect actual browser video dimensions/currentTime, close/reopen viewer, and stop/start once if frames work. Stop only the owned test preview at completion. No SD/photo/settings writes, no new privileged helper or manual Ubuntu modification. Store private operation receipts outside Git; failures remain failures and do not trigger blind reinstall loops.
## PREP04 / LIVE04 — аппаратная проверка B10 прошла
Core8000 → настройки выбранной X4 → «Обновить» развернул package **0.1.3-2**, SHA-256 `2931a5206478fcac67f74bd1fb579b98c0fcc43eda4c05e5ac4a721947619130`, runtime revision `f78a7ae557e3371022869025`. Fixed profile complete, start Unix1788884870.387824, monotonic183178.268900616, duration6.955230438 s. Selected-instance verification complete: два H264 кадра2880×1440, duration317 ms; это не измерение задержки WebRTC.
После подготовки штатный preview START при SD recording0 дал **реальное браузерное видео1280×640**: readyState4, paused=false, currentTime10.173→49.014 s. Закрытие зрителя через «К устройствам» оставило capture активным; повторное открытие дало те же размеры, readyState4 и currentTime38.943 s. Затем явный preview STOP подтвердил preview0/recording0. Новый preview START без SD снова дал изображение, currentTime6.855→51.380 s. Ни SD START/STOP, ни photo/settings writes в LIVE04 не отправлялись. B10 исправил наблюдавшийся первый запуск в этой ограниченной проверке; firmware keyframe cadence и camera-to-display latency не измерялись.
Тестовый preview остановлен штатной кнопкой. Итог16:34:49.214195 UTC, Mac monotonic314411.088057958: preview0, recording0, prepared=true, online=true, обе пары START/STOP complete. Core `/api/health`: ok=true, readiness.operational=true. Node/K1/RealSense/X4 broker/supervisor active, NRestarts0; broker TasksCurrent4 после cleanup. Node0.8.17-4 и X40.1.3-2 установлены. Канонический Core8000 сохранён; отдельный backend/build/worker не запущен.
Приватные receipts и redacted browser observations сохранены0600 в ignored `plugins/insta360-x4/build/acceptance-core/`:
- `prep04-live04-start.json`: UTC16:29:36.646936, Mac monotonic314098.523338708, SHA-256 `1a2695b58ed5236685050b8ba19c5ca472cd8f9287c48b1cb39c185341e67df4`.
- `live04-restart.json`: UTC16:32:40.997348, Mac monotonic314282.872245208, SHA-256 `81e27abbba84ce8f22b520d93748ec92256d34eece13655ffed7efd101be4b4d`.
- `live04-cleanup.json`: UTC16:34:49.214195, Mac monotonic314411.088057958, SHA-256 `30521d397c87a33d57a82a84f07455716035797f6702c02c3c9d471b4a0e4ca8`.
Проверка чистого Ubuntu image, нескольких физических камер, local Node shell WebRTC, полной линейки settings/photo/download и длительного real-time поведения остаётся открытой. Документ09 переписан как актуальное состояние, чтобы прежние «не установлен»/«SD не запускали» не противоречили новым квитанциям. Все аппаратные изменения этого прохода прошли через установленный device profile и UI operations; ручного ремонта Ubuntu не было.
## UI01 / N09 — общий loading contract, intent до исполнения
Владелец подтвердил живое изображение X4 и запросил устранить свободные индикаторы под кнопками/в углу viewer на уровне Design Guideline, с общим использованием Core/Node. DG добавляет Button.loading, IconButton.loading и LoadingRegion, registry/docs/catalog/tests. Shared sensor-ui и X4 frontend связывают pending с конкретным action; video остаётся смонтированным, loader центрируется внутри области и исчезает после usable frame или конечного отказа. Существующая native Node среда без RTCPeerConnection получает явный неподдерживаемый статус. Новых SDK команд/изменений model package нет.
N09 artifact `d7aa79960717e4d62ab69633`,309597682 bytes, SHA-256 `9751fda5efa794e6c90932346fac428b9eeb5535c4a1b807129ccc0dd03c09b5`. Включает hash-bound изменённый DG source на прежнем base commit и qualified X4 package0.1.3-2 без изменения bytes. На той же Ubuntu: unprivileged private staging, pinned Go/Node, locked npm ci, последовательные DG typecheck/registry/loading tests/catalog build, Node tests/build, Core architecture/typecheck/tests/build; CPU150%, RAM3GiB, tasks256, time1200s. Node0.8.18 содержит новую embedded UI, поэтому требуется Go rebuild, SDK не пересобирается и не вызывается во время сборки. OS dependencies/установленные службы сборка не меняет; cleanup только через artifact --clean. Baseline available RAM5594MiB,swap0,free disk403GiB,Node/X4 active NRestarts0. Затем qualified Core dist активируется на существующем8000; новый Node.deb передаётся стандартным owner installer. Hardware QA только выбранный preview/verify/close, без SD/photo/settings writes; чужой текущий capture не останавливать.
**N09 checkpoint / N09-R1 intent:** DG build/typecheck/registry/4 loading tests/catalog, Node UI/Go race tests/binary и Core architecture/typecheck прошли. Core suite813/819 passed,6 failures: все в двух K1 presentation test files, regex ожидал text непосредственно перед closing button и не принимал новый внутренний content span. Изменение assertions проверяет конкретную кнопку/её текст и disabled/aria-busy/spinner containment; аппаратная логика не изменяется. Полный повтор819 тестов и Core production build выполняет fixed recovery artifact `19aff6e417960e20c180ca02`,55700 bytes, SHA-256 `2e73846f7a9fe4c2315e26fe3683a1b209d92c098344eae042673c845bf787ab`. Он сверяет original source manifest `d7aa79960717e4d62ab69633ec9ddc1ddabfa33998043635bdef2dbac807a3ca`, failure report `0d7b2390c5d546e1e442c1283afcbab6e63e03ac8f3033489f7b86cc3de71278`, Node.deb `db340f7d117a7cdf4707bbf43f58c0e8307c8ac3813b7bc7dd5ca8a4a47f73b2`, все исходные hashes; заменяет только два тестовых файла внутри собственного private build staging. Без npm install/Go rebuild/SDK/USB/installed-file edits; прежний failure report сохраняется. Лимиты3GiB/150%/256 tasks/600s. В output собирается также уже построенный DG catalog для визуальной проверки. Локально после snapshot отформатированы только build-helper Python, executable UI bytes не менялись. Ruff по новым/изменённым build helpers проходит; полный lint прежнего build_deb.py содержит существующие style violations и не объявляется зелёным. Владелец сейчас использует preview1/recording0; capture сохраняется.
**N09-R1 complete / P08 intent:** all819 Core tests pass,197.544342s; Core production build74.351850s. Recovery complete17:07:21.486437 UTC,280.677821s. Result archive SHA-256 `04232519003f999dca9d357f0f60c31d488d082f74012b06485b6ced7c805d62`,48 flat regular files extracted with bounds and hashes verified. Node0.8.18:168255272 bytes SHA `db340f7d117a7cdf4707bbf43f58c0e8307c8ac3813b7bc7dd5ca8a4a47f73b2`; Core dist23067354 bytes SHA `457c5eb08d3f49c998b7b6ee2be6fc1e388a18ae50cc53ada94585c41f2b8271`; DG catalog11024488 bytes SHA `5b78ba8b1f720a51923c1f634a1a64c69cdeed2235c18b8398a27b74d668f11a`. One pre-existing Python/Rerun-dependent case remains outside this819 suite as before; no claim that it passed.
P08 owner release `38a5e2135801b252e4e194bd`,168274705 bytes, SHA `5d7f96ae85d4306d254c69cd0fddb1490518fcdc5bf63877f8e8495005570d5b`. Standard stage→APT simulation→local owner authentication→Node package update. X4 model payload remains identical0.1.3-2; no model prepare/reinstall command. Before/after units and UI readiness recorded by installer. Mac Core: backup prior dist in ignored build, add qualified assets and atomically replace index on existing8000, retain old hashed chunks for open clients. Optional static DG catalog QA is loopback-only, its temporary server/viewer stopped afterward. No second Core backend and no user capture stop. UI checks use own peer plus read-only camera operations; original preview1/recording0 preserved.
## UI01 / P08 — поставка общего loading UI и границы проверки
Core activation complete17:09:57.437525 UTC, Mac monotonic316519.418392875. Квалифицированные407 files активированы в существующем dist; прежний dist сохранён в ignored `apps/node-agent/build/core-ui-before-n09`, старые hashed chunks оставлены для открытых клиентов. Index SHA-256 `87321f744a9cd2cecbe40a17282d99257afd338ebbc4966836782f04c824b0dd`, served module `app-intFilas.js`. Backend8000 не перезапускался. Rollback — возврат сохранённого index/dist; Node rollback только штатным отдельно проверенным owner release, автоматически не выполняется.
P08 complete17:23:23.914094→17:23:39.803770 UTC, Ubuntu monotonic186511.795227337,15.889641 s. Local owner sudo авторизация получена; Node0.8.18 установлен, package hash совпадает с N09. ui_ready=true, Node/K1/RealSense active,NRestarts0. X4 broker/supervisor/instance active, модель остаётся0.1.3-2; prepare/SDK START/STOP/SD/photo/settings writes в этом проходе не отправлялись. Повторный installer сохраняет штатные hash/APT/service guards; дополнительных системных зависимостей для этого UI изменения нет.
Browser QA до P08: initial video loading region318.875×360, overlay занимает ровно его границы. Read-only files refresh: button157.609375×46 до/во время pending, disabled=true,aria-busy=true, центр spinner dx−0.0078125 px,dy0. В движущемся1280×640 video readyState4,paused=false,currentTime54.085 и позднее179.356 s,0 loaders. Expanded viewport height961 px; восстановление кнопкой проверено. DG living catalog визуально проверен в light/dark и pink/blue accents: text button125.515625×46, icon46×46; нейтральный spinner наследует цвет, content indicator с подписью центрирован в776×92. Локальный статический сервер только127.0.0.1:57219; внешней публикации нет.
**Новая отрицательная video observation после P08:** собственный viewer после открытия получил1280×640 и остановился наcurrentTime4.846 s,paused=false; UI показал «Нет свежих кадров». Следующее открытие —0×0,readyState0. Одна штатная verify operation закончилась error с сообщением о недоступности параметра/действия в текущем режиме; settings.read и close-peer complete. Read-only broker journal за это окно пуст, службы активны; причина не установлена. Это не доказательство регрессии UI и не успешная post-upgrade stream acceptance. SDK/decoder/network/browser границы требуют отдельной диагностики. Frame freshness не восстанавливалась скрытым START/STOP или рестартом службы.
На этом отказе Button.loading находился только внутри «Проверить изображение», затем кнопка стала enabled,aria-busy отсутствует;0 content/action loaders после ошибки. Expanded→Escape дал expanded0. Закрыты только собственные peers; захват владельца сохранён. Final private snapshot17:30:24.891862 UTC,Mac monotonic317746.934770208:online=true,preview1,recording0,Core health ok=true,последний close-peer complete. Native Node visual QA/local playback не объявляются пройденными только по установленному embedded UI.
Evidence0600 в ignored `plugins/insta360-x4/build/acceptance-core/`: `ui01.json`104517 bytes SHA-256 `c58f07e5becfc7a8d381decf767d976757d6c9dd72fcaf5060d2944a4fb6aa96`; `p08-install-output.txt`2071 bytes SHA-256 `76cbdc9d18e482d748889609f06319b1a484c0d936cc2081703c52a098438760`. Private identities/SDP/receipts в Git не включаются.
Cleanup complete: catalog tab закрыта, exact temporary PID82907 на57219 завершён (exit143); N09 staging удалён штатным source artifact `--clean`, receipt `cleaned=d7aa79960717e4d62ab69633`. Все48 qualified outputs и первичные failure reports до очистки сохранены локально. Build/recovery user units отсутствуют. Canonical Core PID78006 продолжает слушать127.0.0.1:8000; listeners8765/57219 отсутствуют. Code/tests/build после QA не менялись; текущая правка — только отчётность и уточнение первого следующего пункта в document10.
Владелец08.09.2026 сообщил «нет картинки» со статусом «Нет свежих кадров». Read-only baseline17:54UTC:Node0.8.18/X40.1.3-2, camera online/preview1/recording0, X4 broker/supervisor/worker active,NRestarts0. Offer receipts complete, два verify error; общий Operations ошибочно подменяет любую error причиной unsupported parameter. Cached preview flag подтверждает принятую команду START, но не свежесть SDK callbacks.
Дальнейшая проверка в рамках запроса на исправление: сохранить текущие квитанции; один явный штатный preview STOP→START через Core API с проверкой подтверждения между командами, без SD/photo/settings writes и без служебного рестарта. Затем собственный viewer и read-only evidence. При неизвестном результате повтор не отправляется. Никакого ручного патча Ubuntu; необходимые изменения продукта сначала включаются в versioned installer/profile и synthetic tests. Установленный SDK не запускается отдельно вне worker. Root diagnostics в обход ACL не допускается.
**LIVE05 outcome:** Core API preview STOP→START оба complete,17:57:53.154423→17:58:08.368575 UTC,Mac monotonic319395.242711541,15.214178 s. После каждой команды отдельно подтверждены expected preview0/1 и recording0. Браузер после нового открытия получил1280×640,readyState4,paused=false,currentTime39.616 s,«Прямой эфир». Это восстановление, не установленный root-cause fix.
Для различения freshness источника и browser decoder выполнен один bounded приёмник на Mac из уже существующей repository .venv с aiortc/PyAV. До запуска:48% memory free,swap3039.25MiB (не выше прежнего baseline),Docker/VM/build процессы не обнаружены. Новые зависимости не устанавливались, SDK не загружался, медиабайты не сохранялись. Первый offer diagnostic client вернул unknown: его SDP содержал IPv6 вне разрешённого IPv4 transport contract; результат сохранён. После завершения клиента проверен состав кандидатов; отдельный probe с private IPv4 filter, совпадающим с broker policy, принят. Не выполнен повтор неизвестной аппаратной команды; оба probes создают только собственный viewer.
IPv4 probe18:04:44.014929→18:06:33.329416 UTC,Mac monotonic319806.118592166. За98.19 s sampling1107 decoded frames1280×640;11.28 fps между первым/последним непустыми samples,49/49 непустых samples source fresh=true. Максимальный sampled age последнего принятого кадра111 ms; это не glass-to-glass latency. На25-й секунде запущен один read-only verify: error, но source sequence и принятые frames продолжили расти до5691/1107. Вывод: отрицательный verify не доказывает отсутствие действующего video. Код verify создаёт новый decoder в середине stream, а Operations скрывает конкретный verification error; оба дефекта отмечены для исправления, не объявлены устранёнными.
Probe close-peer complete, процесс завершён. Повторное открытие обычного Core viewer после probe снова дало1280×640,readyState4,paused=false,currentTime62.747 s,live=true,stale=false. Собственный viewer закрыт через «К устройствам», захват оставлен владельцу. Службы/SDK/model payload не менялись, установки не выполнялись; наблюдаемая причина первоначального зависания остаётся открытой.
Приватное evidence0600 в ignored acceptance-core: `live05-restart.json`25340 bytes SHA-256 `21783932e3e8a654513637e52b2f551ac823489c557ef9f875abc48cd15287cd`; `live05-probe.json`10479 bytes SHA-256 `287ced0627b6e161701e2708c5e8fe3ce06dee484c255d495f52e8790abf7acf`; `live05-probe-ipv4.json`31399 bytes SHA-256 `50194b8f8df9c2a04659983276d8ff14948229fb5953fe3f98f67c3f756a2ddf`. Исходники обоих bounded probes сохранены рядом, их SHA включены в reports; SDP/instance IDs не перенесены в Git. Product code в LIVE05 не менялся, unit/build rerun не требуется; изменены только инженерные документы.
LIVE05 final snapshot18:09:36.719216 UTC,Mac monotonic320098.829150541:preview1,recording0,online=true,Core operational=true. Private `live05-cleanup.json` SHA-256 `dbf95f18661ea5d6af30f64f059ef701085cfc665edc6714ef8605df6dc7497a`. Собственная browser tab закрыта, оба приёмника завершены; оператор может продолжать отдельные действия из своего клиента.
## B11 — повторный START и active-preview verification, intent09.09.2026
Confirmed source defect: Control.call выполнял Feed.change для повторного preview.start при уже активном native preview. Native START в этом состоянии idempotent/no-op, но Feed.change очищал queue/codec parameters и менял generation; существующий decoder терял начало потока без нового camera START/keyframe. Исправление сохраняет feed generation при подтверждённом уже достигнутом состоянии. Broker также не освобождает существующий decoder, если повторный START вернул unknown. Это конкретный воспроизводимый дефект; связь с каждым прежним hardware freeze не считается доказанной заранее.
Active-preview verify теперь адресует существующий shared decoder и требует два новых свежих кадра за bounded8s. Не создаёт поздний второй decoder, не отправляет SDK START/STOP. Idle verify сохраняет прежний bounded worker check. Broker verification journal общий для обоих состояний и сериализован с переходами preview; retry той же operation возвращает receipt даже при изменении preview state. SD recording/unknown status по-прежнему блокируют проверку. Публичные error messages задаются allowlist, неизвестный vendor text не выводится и не подменяется ошибкой параметра.
Build/test intent: X4 package0.1.3-3 через существующий hash-bound package builder на той же Ubuntu, unprivileged staging, без SDK/USB/system modifications. Проверки включают real-codec late-viewer stream с одним initial keyframe и повторным START, два новых кадра shared verify, stale/foreign source refusal, дедупликацию active↔idle verification и сохранение error privacy. Node пакет получает только новый model bundle/profile/provenance; UI/Go/SDK native bytes остаются квалифицированными. Затем owner installer и штатная model preparation. Перед подготовкой — явный preview STOP с подтверждением recording0, после неё — аппаратный повторный START/verify/просмотр. Установленная Ubuntu вручную не патчится.
**B11 complete / P09 intent:** source artifact5f443c98d7e603da77b1cae4,58317574 bytes,SHA-256 `a1361ac5807fd48929103fb6864cc21fd546a8ec8c7ce1f87ef3f319114bd129`. Build03:58:40.226971→03:59:02.791045 UTC09.09,Ubuntu monotonic224628.108059906,22.564079 s;38 tests passed4.667 s, cold imports/static ELF closure passed. Result archive SHA-256 `441a1df0ecdd56e59286fed09ddcfac8810df5135544493cfc6181a9dad18e70`; пять regular flat outputs проверены и сохранены в ignored package-b11. X40.1.3-3:58199970 bytes,SHA-256 `c10f9c1e7f8237d9df202bc29483d61f27280920d76611b1aa1c4f3a72332540`,revisionb291418f2a404cbdafc57431. Source artifact --clean удалил только собственный B11 staging.
Fixed repack_x4_n09.py проверяет qualified Node0.8.18 SHA-256 и неизменность bootstrap/всех посторонних payload paths; заменяет X4 bundle/profile и добавляет packaging provenance. Node0.8.18-1:168257000 bytes,SHA-256 `9e5aaff4a8e4a2ed24cef56bcc9bd9721971df3154fa48be8595fef8591bdbb3`. Binary/UI0.8.18 без изменения; SDK native .so также прежний. Full UI/Go tests не повторяются для неизменных bytes. Mac перед packaging75% memory free; Docker/worker/new backend не запускаются.
P09 owner releasee2518e34a8fb154cd5d7dad4,168276441 bytes,SHA-256 `2aa98190bcc504f5677f9211a3948b1302d001d84500424bf2469bc64d95a9db`. Stage→APT plan→local owner terminal для Node package; X4 replacement затем только штатным Core/Node preparation. Без повторной авторизации действий, уже входящих в задачу; OS root password остаётся локальным контролем Ubuntu и не передаётся в SSH. Новая версия должна быть проверена до заявления об установленном исправлении.
P09 plan: only mission-core-node0.8.18→0.8.18-1,0 new/removals. SHA verified on Ubuntu, local installer window «Mission Core Node · 0.8.18-1» opened. Owner asked for one local OS password entry; no repeated X4 preparation/test requested from owner. Awaiting installed receipt before Core model update. Handoff timestamp 2026-09-09T04:03:40.427453+00:00. Ruff scoped checks and git diff --check pass; build staging cleaned, existing Core8000/runtime preserved.
Read-only inspection около02:01 UTC подтверждает завершение P09: owner installer04:14:37.827372→04:14:52.735120 UTC09.09, monotonic225585.708478301, duration14.907733 s, state complete, ui_ready=true. Установлен Node0.8.18-1, package SHA-256 `9e5aaff4a8e4a2ed24cef56bcc9bd9721971df3154fa48be8595fef8591bdbb3`. Node/K1/RealSense active, NRestarts0 в квитанции. X4 остаётся0.1.3-2: новый bundle включён в Node, но model preparation B11 ещё не выполнялась. Источник — штатный install-output.log releasee2518e34a8fb154cd5d7dad4; прежний pending handoff сохранён выше как история.
По сообщению владельца о Rover006 offline проверены только известный SSH endpoint Ubuntu, systemd status, текущие адреса Mac, listener Core, health/fleet API и один ограниченный TCP connect с Ubuntu к сохранённому Core endpoint. Ubuntu доступна, Node active/running с07:14:46 MSK09.09, NRestarts0; канонический Core8000 operational=true. Последний heartbeat в Core:09.09.2026 11:50:06 UTC (14:50:06 MSK), более семи часов после P09.
Причина недоступности: текущий LAN IPv4 Mac отличается от сохранённого Core endpoint. Core channel listener также остаётся привязан к прежнему IPv4; соединение Ubuntu к этому endpoint не установилось за3 s. Код registry.start/listen/reconcile повторно использует сохранённый core_address, Node pairing_transport отправляет heartbeat на сохранённый CoreBinding.Endpoint. Автоматической миграции адреса в этом пути нет. Точное время и причина смены DHCP адреса не установлены; private addresses, node identity и host inventory сюда не перенесены.
Это дефект восстановления канала после смены адреса Core, не свидетельство сбоя X4 или неуспешной установки. Перезапуск Node не изменит сохранённый endpoint. Связь в этом проходе не восстановлена; следующий шаг требует штатного восстановления адреса с сохранением trust/identity перед model preparation и аппаратной проверкой B11. Установка, сетевые изменения, перепривязка, SDK/SD команды и рестарты не выполнялись; состояние камеры из последнего heartbeat считается устаревшим. Изменены только инженерные документы, runtime и Core8000 оставлены работающими.
**NET01 уточнение Tailscale по вопросу владельца:** собственный `tailscale status --json --peers=false` на обеих машинах показал Running/Online=true; вывод ограничен состоянием и собственными адресами, peer inventory не читался. SSH с Mac к известному Tailscale IPv4 того же Ubuntu Node успешно установился с проверкой прежнего host key. При этом повторный GET Core fleet по-прежнему возвращает offline и прежний LAN endpoint. Это подтверждает доступность борта через Tailscale отдельно от неработающего прикладного канала на LAN. Код `trust.node_request` берёт обратный адрес из socket.getsockname(), `registry.preview/add` фиксирует его в endpoint; Node UI допускает выбор LAN или tailnet и не обеспечивает предпочтение Tailscale. Документ04 прямо описывает фиксированные адреса протокола v1 и LAN в первоначальной GUI-проверке. Следующий ремонт должен направить прикладной канал через доступный Tailscale с сохранением криптографической привязки, а не считать наличие Tailscale автоматическим переключением сохранённого LAN URL. Настройки Tailscale, привязка, службы и устройства не менялись.
## NET02 / Node0.8.19 — intent восстановления канала10.09.2026
Владелец прямо поручил исправление. В продукт добавлены: предпочтение tailnet IPv4 в существующем выборе адреса Node; отдельный paired recovery endpoint на собственном tailnet IPv4:8781; восстановление Core по максимум двум ранее полученным в аутентифицированном host inventory адресам Node. Никакого сканирования tailnet/LAN или API провайдера. TLS1.3 recovery требует клиентский сертификат от сохранённого CA и точный Core public-key identity; Node client certificate того же CA не даёт Core полномочий. Core проверяет сохранённый Node key до application request. Новый Core endpoint обязан совпадать с tailnet source IP этого TLS-сеанса. CAS прежнего endpoint/revision и монотонная revision защищают от повторов, старого heartbeat и потерянного ack; обычный mTLS heartbeat доказывает новое online-состояние. При отзыве authority перепроверяется даже для ранее открытого TLS. Идентичности, CA, vehicle/device IDs и client credential сохраняются.
Сборка тем же source artifact с новым фиксированным node-only profile: DG/Node UI и Go race tests, Node.deb0.8.19. Core frontend не меняется и не пересобирается; focused Core fleet suite30 passed. Включён прежний bundled X40.1.3-3, установленный model0.1.3-2 не обновляется этим ремонтом. Новых OS packages/dependencies нет. Native SDK/USB/preview/SD команды не выполняются. До сборки02:20:35.582488 UTC, Mac monotonic432510.916253333: Core8000 operational, Ubuntu Node active0.8.18-1/X40.1.3-2, available RAM5469MiB/swap0/free disk401GiB. Mac67% free, swap1538.38MiB; Docker/build не запущены.
После квалификации: штатный owner installer Node, перезапуск только канонического Core8000 для загрузки Python recovery code, health и fresh authenticated heartbeat с прежним binding/vehicle/node identity. Recovery сам сохраняет endpoint через существующий durable store; ручного изменения БД или core-binding.json нет. Rollback: прежний квалифицированный Node package через owner release и прежний Core source snapshot; версия JSON остаётся совместимой, перенесённый endpoint сохраняется. Смена обоих tailnet identities/адресов одновременно и expired client certificate не объявляются автоматически восстановимыми; это отдельные условия восстановления доверия.
NET02 source artifact `4cb9d399568aa06680ee4657`,309635590 bytes,SHA-256 `0f763d9e3adb668d5b7bb0937e7dc0aef9555dbf93b0badc927c06eba8170922`;2709 inputs, node-only profile. Передача по известному tailnet SSH endpoint с прежним host-key pin; исполнение только artifact entrypoint в private unprivileged staging, cgroup3GiB/150% CPU/256tasks/1200s. Build/tests не открывают SDK/USB и не изменяют установленную систему.
**NET02 checkpoint:** DG build/typecheck/registry/loading/catalog и Node UI tests/build завершились успешно. Первый build остановился на `gofmt -d`: exit1 с diff форматирования трёх новых/изменённых Go-файлов, stderr пуст; Go tests/binary/package ещё не запускались. Форматирование выполнено тем же pinned formatter из артефакта через stdin/stdout без записи на Ubuntu; изменены только локальные source files. Новый source artifact `9a2f6d7e27b3eeba40211a04`,309637281 bytes,SHA-256 `24741bb2022d956eed48832080af67d264ed7cc516fa2d0d6793949b271ee634`, запускается отдельным полным node-only проходом. Предыдущий failure report сохраняется; это не повтор неизменного неуспешного артефакта.
Первый Core kickstart имел слишком короткий observer timeout10s. Попытка немедленного rollback kickstart получила37 (переход launchd ещё выполнялся); после завершения перехода read-only проверка подтвердила Core8000 operational с прежними исходниками. Новые исходники восстановлены из hash-bound NET02 source artifact; повторная активация ждала реального нового PID/health и сохранила identity digest. NET02-Core-2 complete02:28:12.722157→02:28:43.449579 UTC,Mac monotonic432968.055854083,30.727476s,launchctl exit0,Core operational. Backup/оба attempt reports в ignored `apps/node-agent/build/core-net02-before`. Привязка/БД/сертификаты вручную не менялись, камера не затрагивалась. Node ещё0.8.18-1, поэтому recovery на борту пока не доступен.
**NET02 build complete / P10 intent:** второй node-only build02:33:10.005328→02:37:33.619642 UTC,263.614309s. Первый npm fetch имел timeout45s; предусмотренный builder retry завершился за5.700275s с тем же lock. DG/Node UI checks/build, Go formatting, все Go race tests и binary/package complete; Go internal/node tests1.815s, полный test step с cold compilation67.461182s. Result archive SHA-256 `17a12086eb95f18b6dbb849ccb3206a116a186d30701c1669774798102d8330c`;34 flat regular outputs проверены и сохранены0600 в ignored qualified-net02. Node0.8.19:168260174 bytes,SHA-256 `e3334171b64e949eb435ea868ce275d32c8d063b3a471662991f791b138fd78d`.
P10 owner release `901a51d90299a44418ec7684`,168279607 bytes,SHA-256 `df36cd3e29b35eef34d6114fec08133b542639f3cd7d7a1da07f2c7e40e90b8b`. Штатный stage→APT plan→local owner authentication→Node package update, затем автоматический NET02 recovery и Core heartbeat acceptance. Проверяется сохранение Core/node/vehicle identity, tailnet endpoint, несколько новых heartbeat и Node service/no crash. X4 model preparation/SDK operations этим шагом не запускаются. Первый failed source staging очищен только original artifact --clean после сохранения reports: qualification SHAdbaacfadc8a192571033a046a25bc0c2ce85533d054705430e39b4be885e7ef8, outer report SHAfa89fdab020cc9bf8521cdd78383ba12d7270f07d53b13e25a15c37e22299221.
Дополнительная адресная read-only проверка из repository Python runtime Core подтвердила TCP к известному tailnet Node с tailnet source IP Mac; SSH_CONNECTION и системный маршрут согласованы. Один предшествующий TCP probe из другого системного Python завершился timeout; причина единичного timeout не установлена, это не доказательство отказа Tailscale. Никакие маршруты, VPN-настройки или адреса ОС не менялись.
**P10 pending owner authentication:** SHA проверен на Ubuntu. APT plan: только mission-core-node0.8.18-1→0.8.19,1 upgrade/0 new/0 remove. Открыто одно штатное окно «Mission Core Node · 0.8.19», launcher.stderr пуст, install-output.log создан; владелец получил один запрос на локальный OS password. Последняя проверка: квитанции завершения ещё нет, Node0.8.18-1/X40.1.3-2. Восстановление связи пока не принято; новая установка не объявлена завершённой.
Package scope сравнен с прежним qualified0.8.18-1: меняются только control version, Node binary и provenance; прежний packaging-revision.json удаляется. Все остальные payload bytes/modes совпали, включая model.deb/profile, SDK/sensor scripts и maintainer scripts. Оба source staging очищены только соответствующими artifact --clean; временных сборочных процессов не оставлено. Owner release и квалифицированные пакеты/отчёты сохраняются. Следующий шаг после пароля: прочитать P10 result/version, дождаться автоматического authenticated recovery, сверить прежние identities и новый tailnet endpoint, проверить несколько свежих heartbeat. Повторно открывать установщик или просить ещё одну подготовку X4 не требуется.
После ввода владельцем пароля P10 complete05:16:37.944641→05:16:52.757461 UTC,Ubuntu monotonic315705.82574643,14.812812s. Установлен Node0.8.19, SHA-256 `e3334171b64e949eb435ea868ce275d32c8d063b3a471662991f791b138fd78d`; Node/K1/RealSense active,NRestarts0,UI ready. X4 остаётся0.1.3-2. Однако Core offline: Node слушает tailnet:8781 и каждые30s отклоняет Core TLS с `x509: certificate signed by unknown authority`. Установка успешна, аппаратная приёмка NET02 не прошла.
Read-only сравнение публичных сертификатов из Core registry и recovery-client.pem: CA совпадает byte-for-byte, public key совпадает, подпись leaf подтверждается сохранённым CA. Причина в новом Python certificate profile: recovery leaf и CA имеют одинаковые Subject/SPKI и оба без SAN. Pinned Go1.26.8 `crypto/x509/verify.go:alreadyInChain` считает такую пару циклом и пропускает доверенный root. Исходный server leaf отличается IP SAN, поэтому прежний heartbeat не имел этого дефекта. Go unit fixture использовал другой Subject leaf и не покрывал фактический Python output; этот пробел приёмки признан.
NET03 меняет только Subject recovery client leaf на «Mission Core channel recovery», сохраняя issuer, CA, Core key и проверку mTLS.31 Core fleet tests passed. До активации запускается versioned interop artifact `9beb166a140dcbb75711f9e4`,66911019 bytes,SHA-256 `9ad9734f73b3ee70a61b5085372c41ebb327396d50fd69b152358aa25fa2aff5`: публичные синтетические CA/legacy/fixed certificates, выпущенные тем же Python кодом, проверяются pinned Go1.26.8. Отрицательный контроль обязан воспроизвести UnknownAuthorityError; исправленный leaf обязан пройти и сохранить public key. Артефакт не содержит реальных ключей/сертификатов и не открывает SDK/USB. Unprivileged staging/cgroup1GiB/150% CPU/128tasks/180s; зависимостей ОС/установленных файлов не меняет, Go network downloads отключены.
После успешного interop — обновление только канонического Core8000 с наблюдением фактического завершения restart до55s. Node0.8.19 повторно не устанавливается; старые ключи/привязка сохраняются, новый краткоживущий leaf выпускает сам Core при запуске. Затем требуется настоящее восстановление и несколько свежих mTLS heartbeat, с сохранением identity и tailnet endpoint. Камера/model preparation остаются вне NET03.
Первый interop artifact остановился до запуска Go: guard распаковки не допускал корневой directory member `go` без завершающего slash. Установленная система не менялась; failed staging сохранён как свидетельство. Guard теперь проверяет компоненты пути, запрещает absolute/parent traversal и допускает штатный корень. Начальный report записывается до распаковки. Новый artifact `47a5142c4707d4b54693fdc6`,66911479 bytes,SHA-256 `3354f56e1024a5f549d38c04a7af6fd00340014ec9f15d1cfb81568cfe981d51`; прежние resource limits/negative control сохранены. Это исправление test harness, не дополнительная установка Node.
**NET03 interop complete:**05:33:51.694243→05:34:17.728311 UTC,Ubuntu monotonic316739.575316337,26.034068s,exit0. Legacy profile воспроизвёл UnknownAuthorityError, fixed profile принят, Core public key сохранён. stderr пуст. Report сохранён0600 локально; успешный staging удалён только своим artifact --clean. Первый failed staging с публичными synthetic inputs сохранён без активных процессов; установленная система и SDK не затрагивались.
**NET03 Core activation complete:**05:35:10.596393→05:35:42.362973 UTC,Mac monotonic438990.62500025,31.766344s. Один штатный launchd kickstart, exit0; новый канонический процесс Core8000 operational, прежние identities совпали. Source recovery.py SHA-256 `c83ece4b01ddf9ddb47e1cb0be992ec42cf481ea67b8da34222d783b2b409c36`. Node повторно не устанавливался. Authenticated inspect после активации подтвердил сохранённый Node tailnet endpoint и revision1, прежний binding; TLS rejection исчез.
Первый heartbeat acceptance05:36:13→05:36:31 UTC ещё показал offline. Read-only диагностика: один обратный TCP connect к Core8782 завершился timeout3s; Tailscale ping к тому же Mac прошёл, собственный клиент Running/Online, ShieldsUp=false, macOS firewall disabled. Просмотр сокетов и секундный sample собственного Core процесса сохранили свидетельство; настройки сети/ACL/служб не менялись. К05:39 UTC heartbeat восстановился автоматически. Причина дополнительной задержки не локализована; мгновенное восстановление и полная fault matrix не заявляются. Отдельный TCP timeout не приписывается автоматически Tailscale или firewall.
**NET03 hardware channel acceptance passed:**05:40:08.583622→05:40:32.647644 UTC,Mac monotonic439288.609984333→439312.673681458. Пять последовательных snapshots online, пять разных свежих heartbeat, tailnet endpoint/revision1; CoreID/NodeID/vehicleID и SHA существующего bindingID совпали с baseline. Node0.8.19 active/running,NRestarts0; X4 остаётся0.1.3-2. Final check05:42:00 UTC: Core8000 operational, Rover006 online со свежим heartbeat, Core channel слушает собственный tailnet IPv4:8782; на8765 backend отсутствует. UI build не повторялся для неизменных frontend bytes. Scoped Ruff и git diff --check passed.
Private evidence в ignored `apps/node-agent/build/core-net03-before`,0600: interop-report.json SHA-256 `c323c06fe884ef1b33bf531f93e61b71625f1cd30ad9be396596daa96437311e`; activation.json `a5f52b13c67585fda13121e76fe38baabc4b1a5a45ce2e1ba4803951e581d0d6`; первая failed heartbeat-acceptance.json `cc1f5cb186b7e2d6a157dc5c91123861e9dc5afe391a58268cfd10ec832f4bf3`; принятая heartbeat-acceptance2.json `7ad1c0e85a1074ecf77ef58f5678d42522d68ef2aad5ff472b0c0a82bb26f61b`; core-sample.txt `d2eb0da65b56c22d14b66333787877b1e81b20f979277f4686dee83c50d4fa66`. Привязка/БД вручную не изменялись; временных работающих проверок не осталось. Пароль больше не требуется. Следующий камерный шаг — подготовка B11 из bundled model и аппаратная проверка видео; NET03 не отправлял SDK/preview/SD commands и не закрывает эту отдельную приёмку.
## AUT01 — оценка автономности и USB power,10.09.2026
По запросу владельца проведены только read-only действия: текущие health/fleet API,
код supervisor/worker/bridge и pinned SDK headers, DMI/sysfs/lsusb известного Ubuntu,
официальные инструкции X4 и README uhubctl. Борт Macmini6,2; X4 напрямую на xHCI
USB3,5000M. Есть kernel per-port disable и USB2/USB3 peer mapping, но это не
08.09.2026. Владелец отказался от заявки поставщику и поручил искать публичный GitHub-вариант. Позднее расширил scope с просмотра до управления камерой: запись/стоп, фото, настройки, состояние и работа с файлами. Ниже — статический аудит, без запуска SDK и без изменений Ubuntu.
## Найденные варианты
| Источник | Проверенное содержимое | Решение |
|---|---|---|
| [pdxmusic/insta360sdk](https://github.com/pdxmusic/insta360sdk/tree/3db9641ba612c639db10591d1402231662a1eb5d) | CameraSDK 2.1.8, Linux x86_64; получены реальные 17 031 504 bytes из публичного Git LFS, hash совпал с pointer; заголовки и JSON конфигурации | Основной кандидат для дальнейшей квалификации |
| [giacomotambe/INSTA360-X4-ROS2](https://github.com/giacomotambe/INSTA360-X4-ROS2/tree/c4cc029cffba14f5cbc4d34f3dfaaeb7c5b4a55f) | Настоящая x86_64 библиотека 11 518 472 bytes и заголовки X4; SHA-256 `e1341d1921b6f207d506df293ab5f33039af1da6bb06843b77a13e1b13b13d01` | Резервный кандидат; не смешивать его headers с 2.1.8 |
| [Exusiai-R/Insta360Playground](https://github.com/Exusiai-R/Insta360Playground/tree/23aebf21ca2f6a2813e89c68c82a442cbe44ea92) | Библиотека 11 872 744 bytes, ELF machine 183 (AArch64); SHA-256 `01d59fc508fb8eb77a1e8726f6ffae960fb5b084c7c82eddddab7a2625b11c8b` | Не подходит Intel Mini |
| [caxapok44/CameraSDK-Cpp](https://github.com/caxapok44/CameraSDK-Cpp/tree/853f2c5efbd18383f2d8fa795c8eb6b72324cc20) | В дереве есть `.so`, но enum CameraType в комплектных headers заканчивается X3 | Не выбран для X4 |
| [ai4ce/insta360_ros_driver](https://github.com/ai4ce/insta360_ros_driver) и современные непосредственные forks Desktop-CameraSDK-Cpp | Wrapper/demo/docs; актуальный upstream ROS требует отдельно добавить SDK | Сам по себе не решает получение runtime |
| [xaionaro-go/insta360ctl](https://github.com/xaionaro-go/insta360ctl/tree/f94193ce03c5af0921a9992bfd1af6bd946150d0) | Исходники Go BLE control и Wi-Fi streaming, X4 в model table; подробная аппаратная документация преимущественно GO 3 | Исследовательский резерв. Это не проверенный USB X4 adapter; не выполнять GO 3 команды на X4 по совпадению номеров |
| [kashmir2003/insta360-usb-native](https://github.com/kashmir2003/insta360-usb-native/tree/44204912a756325bf7f3452c4959b20a4c0712d1) | Независимый Python USB preview для ONE R. Сам автор требует отдельного вывода протокола для X-series | Не считать drop-in драйвером X4; чужие handshake/retry/root scripts не запускались |
Проверены деревья девяти непосредственных SDK forks с изменениями 2024–2026 годов и дополнительные X4/ROS/USB проекты. Это ограниченный поиск, а не утверждение, что исследованы все GitHub репозитории.
## Основной кандидат
Источник: public third-party mirror, commit `3db9641ba612c639db10591d1402231662a1eb5d`.
Точный состав 17 файлов зафиксирован в `plugins/insta360-x4/packaging/sdk-lock.json`; бинарники в Git не добавлены.
Статическое чтение ELF64 подтвердило machine 62 (x86_64). Прямые `DT_NEEDED`: `ld-linux-x86-64.so.2`, `libc.so.6`, `libgcc_s.so.1`, `libm.so.6`, `libpthread.so.0`, `libstdc++.so.6`. Максимальные найденные ABI версии: GLIBC 2.17, GLIBCXX 3.4.30, CXXABI 1.3.13. Это проверка структуры файла; она не доказывает отсутствие runtime `dlopen`, доступ к USB, полноту dependencies или совместимость firmware.
В полученных headers доступны `StartRecording`, `StopRecording`, `TakePhoto`, `StartLiveStreaming`, `StopLiveStreaming`, `GetCameraFilesList`, `DownloadCameraFile`, параметры съёмки и per-model capability queries. `DeviceDiscovery` прямо предупреждает, что enumeration может устанавливать соединения с камерами; поэтому будущая изоляция выбранного USB-экземпляра должна действовать **до** SDK enumeration, а не только перед `Camera::Open`. В`DeviceConnectionInfo` есть opaque native pointer; нельзя переносить его между процессами или сохранять в journal.
Совпадение SHA с LFS доказывает целостность относительно публичного mirror, но не подпись производителя. В просмотренных SDK-файлах не найден документ условий распространения. Apache-2.0 у ROS wrapper не является доказательством лицензии на vendor `.so`. Внешняя поставка runtime остаётся отдельным release gate; SDK не публиковался от имени NODE.DC.
## Webcam и выбор управления
[Актуальное руководство X4](https://onlinemanual.insta360.com/x4/en-us/camera/appuse/obs) описывает USB Webcam Mode и 2880×1440/30 с OBS, с оговоркой о непроверенном другом ПО. Этот факт исправляет предположение, что X4 не даёт USB webcam video. Однако он не даёт настройки/запись/файлы через USB Camera SDK и не закрывает расширенную задачу владельца. Linux UVC, одновременная запись и webcam, аппаратная сшивка и задержка не проверены.
Выбранное направление остаётся USB Camera SDK adapter с раздельными preview/recording состояниями, общим Node-owned prepare из обеих UI, полным installer ownership и per-instance isolation. SDK Media/stitching не добавляется.
## Проверки и следующие зависимости
- Инструмент сборки `fetch_sdk.py` импортировал уже скачанный SDK по полному lock; повторная проверка не требует сети и не исполняет библиотеку.
- Не запускались `ldd`, SDK demo, SDK `Open`, запись, preview, BLE или Wi-Fi commands. Не выполнялись сторонние install scripts.
- SSH к настроенному Worker 006 для проверки Linux build runtime завершился timeout; рабочая станция сборки не изменилась. На Mini компилятора/SDK вручную не устанавливали.
- Последующая директива владельца заменила build-host выбор: всё собирается и тестируется на имеющейся Ubuntu Mini. B01 собрал native adapter; B05 собрал `.deb` и проверил cold Python imports/static closure. Компилятор уже был установлен; ничего вручную не доустанавливали. Unit/mount/USB isolation и аппаратная квалификация ещё ожидают установки P01. Актуальные hashes/attempts — в installation ledger. Полноценная готовность управления/видео не заявляется.
Подготовлен X40.1.3-3 в Node0.8.18-1.38 Ubuntu tests passed, включая real-codec stream с единственным initial keyframe после повторного START и active verify двух новых кадров общего decoder. Повторный START больше не сбрасывает generation при уже активном preview; unknown такого повторного START не закрывает существующий decoder. Idle verification остаётся в worker, active verification использует broker source; единый verification journal сохраняет дедупликацию при изменении preview state. Собственные причины ошибок доступны через allowlisted messages.
**Node0.8.19 установлен через P10; X4 model0.1.3-3 ещё не применён и аппаратно не принят.** B11 bundle сохранён в новом Node, установленный model остаётся0.1.3-2. Нужны штатный Core model update и аппаратный START→повторный START→verify→viewer reopen. Наличие конкретного исправленного дефекта не доказывает, что устранены все причины прежнего зависания.
**NET01–03,10.09: связь Rover006 восстановлена через Tailscale.** Первоначально Node сохранял прежний LAN IPv4 Mac; наличие Tailscale не меняло этот URL. P10 добавил authenticated recovery, но первая аппаратная проверка выявила несовместимый Subject нового Core client certificate с Go x509. NET03 исправил выпуск сертификата в Core, сохранив CA/ключи. Node автоматически сохранил tailnet endpoint с revision1; обычные mTLS heartbeat подтвердили online. CoreID, NodeID, vehicleID и bindingID сохранены. Подробности и границы проверки в ledger.
**P10 complete,10.09 в05:16:52 UTC; NET03 Core активирован05:35:42 UTC.**31 fleet tests passed; отдельная проверка реального Python certificate profile через pinned Go1.26.8 воспроизвела legacy failure и приняла fixed profile. Node0.8.19 прошёл DG/Node UI checks/build и все Go race tests. Первая проверка heartbeat сразу после Core restart ещё не прошла; к05:39 UTC online восстановился автоматически. Причина дополнительной задержки обратного TCP отдельно не установлена, мгновенное восстановление не заявляется. Node service active,NRestarts0. Повторный ввод пароля и переустановка не требуются.
**Установлено на имеющейся Ubuntu:** Node **0.8.19**, X4 Debian package **0.1.3-2**, model protocol **0.1.3**. P10 изменил Node binary/provenance, остальные payload bytes совпали с P09. PREP04 ранее развернул X4 из удалённого Core8000 → настройки X4 → «Обновить». Core8000 использует квалифицированный UI N09 и исправление NET03. Восстановление канала принято; устойчивость видео и применение B11 остаются открытыми.
**Новый открытый случай UI01 после P08:** собственный повторно подключённый зритель получил1280×640, затем currentTime остановился на4.846 s и появился статус «Нет свежих кадров». Следующее открытие не получило первого кадра; штатный verify завершился error. Камера продолжает сообщать online=true, preview1, recording0. Причина не установлена; временная последовательность после обновления не доказывает его причинность. Захват владельца не перезапускался, закрыты только собственные peers. Разбор этого случая становится первым следующим пунктом.
**LIVE05 восстановление после пользовательского «нет картинки»:** один явный штатный Core preview STOP→START complete восстановил браузерное1280×640 видео. Отдельный приёмник WebRTC подтвердил1107 кадров за98.19 s наблюдения,11.28 fps между первым и последним непустыми samples; все49 непустых samples имели fresh=true по телеметрии источника. Это восстановление работающего потока, а не устранение причины исходного зависания. Новый runtime не устанавливался, службы не перезапускались, SD recording0.
Во время того же успешного потока verify вернул error, видео продолжилось. Следовательно, текущий verify не является надёжным критерием отсутствия работающего preview: он открывает новый decoder посреди encoded stream. Operations дополнительно скрывает собственное сообщение verification под общей ошибкой unsupported parameter. Эти два дефекта проверки остаются открыты; error нельзя интерпретировать как отсутствие кадров в уже работающем shared decoder.
**Живое видео принято в ограниченной аппаратной проверке LIVE04:** первый запуск без SD recording дал браузеру H264 **1280 × 640**, readyState4, paused=false, currentTime10.173→49.014 s. Закрытие и повторное открытие зрителя при активном capture снова дали изображение. Явные preview STOP → START также дали изображение, currentTime6.855→51.380 s. SD recording оставалась0. Тестовый preview остановлен штатной командой. Это не измерение camera-to-display latency, не длительный soak test и не проверка чистого образа Ubuntu.
Предыдущие B09/P06/PREP03 не исправляли первый запуск: сохранения SPS/PPS оказалось недостаточно. В принятом B10 декодер запускается **до** явного preview.start и сохраняется между зрителями, пока capture активен. H264 preferences задаются до обработки offer. Операции камеры остаются в per-instance worker journal; создание и закрытие WebRTC peer не отправляет START/STOP записи. Подтверждён результат исправления; внутреннее поведение encoder firmware отдельно не измерялось.
Все версии, намерения до исполнения, ошибки и timestamps находятся в [installation ledger](07_INSTA360_X4_INSTALLATION_LEDGER.md). Private receipts, serials, media identifiers и SDP остаются в ignored build directories с правами0600. Базовый Core HEAD54a85fdf5005803a7834482b7516ebe6b6fb142b. По поручению владельца10.09 фиксируются текущие изменения Core и DG; общая loading dependency закреплена на DG8c53f73ee521561a1cc7944a7f7cf113702f40b5. Это фиксация квалифицированных исходников; исторические provenance установленных пакетов не переписываются.
## Требование владельца
X4 — операторский несшитый просмотр и управление камерой. Preview и SD recording имеют отдельные команды и lifecycle. Инициализация доступна из Node и удалённого Core. Модель и физический экземпляр разделены: несколько одинаковых камер не должны объединять identity, session или результаты операций. Stitching, AI, SLAM и управление ровером в этот этап не входят.
Каждая предпосылка Ubuntu должна исполняться через versioned installer или штатный device profile с первого эксперимента. Ручной ремонт установленной системы через apt/pip, перенос SDK libraries, chmod, environment override или patch службы не применялся. Сборки и аппаратные проверки выполнялись на той же Ubuntu Mini; отдельный Worker и Docker не использовались для X4.
## Реализация и доказательства
| Область | Реализовано | Проверено / ограничение |
|---|---|---|
| Модель и экземпляры | Registry для K1, D455, X4; X4 требует USB VID/PID и exact product. Stable instance ID; неоднозначная идентичность не допускает init. | Node установлен;500 synthetic inventory summaries проходят carrier/validator. Несколько физических камер и миграция D455 к отдельным процессам не приняты. |
| Подготовка из двух UI | Общая prepare operation, модельная установка coalesced; selected-instance verification отдельно. Прогресс связан с device/operation IDs. | Go/Core integration tests; реальное обновление из удалённого Core PREP02–04 complete. Local Node GUI first-init на чистом образе ещё не проверен. |
| Изоляция | DynamicUser per-instance worker, USB BindPaths/DeviceAllow, NoNewPrivileges, отдельный network namespace; broker вне namespace SDK. | Реальный worker прошёл admission до SDK Open. Replug и несколько реальных экземпляров остаются в acceptance matrix. |
| Операции | Device/session/deadline admission, durable UNKNOWN до эффекта, immutable digest и receipts. Per-device locks; preview и SD независимы. | Synthetic tests; на hardware подтверждены preview START/STOP, status/settings read, verify и SD START/STOP. |
| Живое видео | Bounded binary IPC, codec headers per stream/generation, ранний decoder, общий источник между зрителями, отдельный encoder peer. | LIVE04: H2641280×640 в удалённом браузере, первый старт, viewer reopen и capture restart без SD. Output ограничен≤15Hz, actual FPS/latency не измерены. |
| Ресурсные пределы | До4 активных источников, до4 peers суммарно и до2 на камеру; latest-frame slot. | Это предел активного media на Mini, а не количества устройств в реестре.500 одновременных видеопотоков не поддерживаются/не заявлены. |
| Настройки | Capabilities/readback, ограниченные video/photo resolution, mode, WB, exposure mode и ISO setters с проверкой зависимости. | Реальные чтения firmware/settings работают; writes ещё не проверены на камере. Shutter/EV setters и полный набор SDK режимов не реализованы. |
| Съёмка и файлы | SD start/stop, photo operation, bounded catalogue pages по32. | SD01: START и STOP complete, получен путь одного созданного файла. Файл оставлен на SD. Фото и download contents не приняты; download ещё не реализован. |
| Авторазвёртывание | Node.deb содержит fixed profile и model.deb; model.deb содержит native adapter, SDK и26 locked wheels. Hash-checked offline Python payload, compiled runtime. | P01–P07/PREP02–04 на текущей Ubuntu; cold imports/static ELF closure. Оператору не нужны GCC/Go/npm. Полная проверка зависимостей на чистом OS image остаётся открытой. |
Форматирование, удаление файлов, firmware update и power/reset не включены. SD recording не повторялась для запуска LIVE04. SDK boolean capture status и поведение firmware при потере USB требуют отдельной аппаратной проверки.
- PREP04 profile complete6.955230 s; selected verify:2 decoded H264 frames2880×1440,317 ms. Это длительность проверки, не WebRTC latency.
CameraSDK2.1.8 Linux x86_64 получен из [pdxmusic/insta360sdk, pinned commit](https://github.com/pdxmusic/insta360sdk/tree/3db9641ba612c639db10591d1402231662a1eb5d). Hashes всех17 файлов закреплены в sdk-lock.json. Native bridge Linux ABI собран и проверен на Mini; vendor binary не менялся в B09/B10. Mirror не заменяет vendor signature или разрешение на распространение. Источники и лицензионные неизвестные — [SDK audit](08_INSTA360_X4_SDK_SOURCE_AUDIT.md).
## Квалификация сборки
- B10:33 Ubuntu package tests, включая реальный synthetic H264 loopback с одним initial keyframe и поздним подключением зрителя, prime→SDK START, SDK STOP→release, peer/source lifecycle. Cold imports и статическая ELF closure прошли.
- N08: Node Go race tests и Node UI checks прошли; Core819 unit tests прошли, один прежний K1 RRD test исключён из-за отсутствующего Python Rerun и не считается принятым.
- N09/N09-R1: DG typecheck/registry/4 loading tests/catalog, Node UI/Go race tests/build, Core architecture/typecheck/819 tests/build прошли. Первые6 Core failures были несовместимыми HTML regex в двух K1 presentation tests; после исправления assertions полный819 suite повторён успешно. Прежний Rerun-dependent case по-прежнему не входит в эту квалификацию.
- Production Core/Node UI собраны на Ubuntu. Повторные Node revisions меняли packaging/profile/model payload; полная frontend/Go пересборка не выполнялась без необходимости. Квалифицированный Core dist используется на8000.
- Первичные scoped Python проверки:41 passed, включая control/native simulator/SDK source/fleet pairing. Native simulator не загружает vendor SDK.
- Ruff и git diff --check прошли; private build/evidence directories исключены из Git.
## Открытые границы
1. Чистый Ubuntu image: установка OS dependencies и первый prepare через UI. Нынешняя рабочая Mini не заменяет эту проверку.
2. Реальная camera-to-display latency, FPS, длительная работа, replug, disconnect и несколько физических камер.
3. Ubuntu WebKitGTK2.52.6 не предоставляет RTCPeerConnection в проверенном Node shell. Локальная подготовка/verify доступны; local UI WebRTC не принят. Удалённый Core browser подтверждён.
4. Полный набор управления камерой: hardware acceptance setters/photo и реализация download. D455 instance-process migration — отдельная незавершённая часть multi-camera архитектуры.
5. Право внешнего распространения vendor SDK. Пакет пока локальный, внешней публикации не было.
## Отчётность
В [ledger](07_INSTA360_X4_INSTALLATION_LEDGER.md) сохранены также неудачные попытки: postinst pager hang, local APT pathname failure и отсутствие первых кадров в B09. Исправлялись versioned artifacts, после чего повторялся штатный путь установки. Установленная Ubuntu вручную не патчилась.
Автоматическая проверка ранее отклонила создание Ops-карточки, сочтя передачу внутренней архитектуры/статуса в выбранный проект неподтверждённой. Карточка не создана, обходных записей не было; инженерная отчётность остаётся локально. Это ограничение публикации, не блокировка текущей установки и аппаратной проверки.
## Последующий UI-инкремент
UI01/N09 завершён как общий DG loading contract и поставлен в Core8000 и Node0.8.18: Button.loading/IconButton.loading, LoadingRegion, registry/docs/catalog и общий sensor frontend. Browser QA: initiating button сохраняет размеры, spinner центрирован; video остаётся смонтированным; overlay следует normal/expanded области; Escape восстанавливает размер. До P08 движущееся видео1280×640 подтверждено, после кадра0 loaders. DG визуально проверен в dark/light и с двумя accents. В обнаруженном после P08 отказе loader также исчезает, verify button освобождается; это подтверждение UI error lifecycle, не успешная video acceptance.
Новая embedded UI установлена на Ubuntu, но визуальный проход внутри локального Node/WebKit и локальное видео остаются открыты. Порядок дальнейшей работы: [следующие шаги](10_INSTA360_X4_NEXT_STEPS.md).
# Insta360 X4 — следующий план после первого живого просмотра
Срез10.09.2026. Основания: исходный Mission Core Node Context, разделы8/25/26/29; [план X4](06_INSTA360_X4_AND_MULTI_CAMERA_PLAN.md), [текущее доказательство](09_INSTA360_X4_IMPLEMENTATION_STATUS.md), [журнал](07_INSTA360_X4_INSTALLATION_LEDGER.md), последние решения владельца. Исторический нулевой baseline не отменяет PREP04/LIVE04; наличие live stream не закрывает весь P4/P4C/P7.
## Подтверждённая исходная точка
X4 подключена к SDK на той же Ubuntu Mini. Удалённая подготовка через Core разворачивает встроенный model package и проверяет exact instance. Без SD-записи работают первый WebRTC START, viewer reopen и STOP→START;1280×640, несшитые изображения двух объективов. SD START/STOP отдельно подтверждены ранее. Это одна физическая камера и ограниченная лабораторная проверка.
Дополнение LIVE05: пользовательский stale preview восстановился после одного явного STOP→START,100-секундный приём подтвердил свежие кадры. Причина исходного зависания ещё не исправлена. Verify во время живого потока дал ложный отрицательный результат; ближайшая реализация должна проверять свежий общий decoder при активном preview и сохранять адресную причину ошибки, не создавая второго владельца SDK/не перезапуская capture неявно. Не путать это восстановление с завершённой приёмкой устойчивости.
B11/P09,09.09: эта реализация готова и прошла38 Ubuntu tests. Дополнительно исправлен доказанный code path, в котором idempotent повторный START очищал feed без нового keyframe. Проверка10.09 подтвердила установку Node0.8.18-1; model0.1.3-3 ещё требует штатной подготовки, затем аппаратного подтверждения повторного START, live verify и повторного viewer. Остальные причины возможных разрывов и длительная устойчивость остаются в плане.
Предварительное условие NET01 закрыто NET02/NET03,10.09: Core–Node восстановили канал через Tailscale с прежними trust/identity. В Core подтверждены несколько свежих mTLS heartbeat, endpoint revision1. После восстановления заново читать актуальное состояние камеры перед любыми preview/model операциями; прежний stale inventory не подтверждает её текущее состояние.
P10 complete: Node0.8.19 установлен, X4 остаётся0.1.3-2; повторный пароль не требуется. NET03 исправил Core certificate profile, проверенный Python→Go interop и на текущей паре. Следующий шаг по камере — штатная подготовка bundled model0.1.3-3 и аппаратная проверка повторного START/live verify/viewer reopen. Дополнительная задержка восстановления после NET03 пока не локализована: мгновенное восстановление или вся fault matrix не объявляются принятыми.
## Очередь реализации
**Уточнение владельца10.09 после NET03:** ближайший приоритет после применения
B11 — автономность подключения и питание. Проверить сохранение Android-режима,
replug/cold start, автоматическое восстановление SDK и просмотра; определить
реальное VBUS switching существующего Mac mini. Это предшествует расширению
camera settings/file download. Конкретная матрица, доказательства и ограничения
в [плане автономности](11_INSTA360_X4_AUTONOMY_AND_USB_POWER.md); прежняя очередь
ниже сохраняет остальные работы.
| Порядок / связь с исходным планом | Работа | Конкретный выход |
|---|---|---|
| Завершено, P5 | Общие состояния loading в DG: pending инициирующей кнопки, центр content region, отсутствие бесконечной загрузки после ошибки. Shared frontend для Core и Node, каталог и правила. | UI01/N09 установлен в Core8000 и Node0.8.18. Сборки/819 Core tests, DG tests/catalog и Node checks прошли. Browser geometry, normal/expanded/Escape, light/dark и error lifecycle проверены. Native Node visual QA ещё открыта. |
| Первый следующий, P3/P4 | Разобрать UI01 stale-frame случай: после P08 повторный viewer застыл на4.846 s, следующее открытие без кадров, verify error при online/preview1. Сопоставить SDK packet sequence, decoder freshness, peer delivery и browser frames; воспроизведение в согласованном окне без скрытого рестарта захвата. | Локализованная причина и проверенное исправление через versioned artifact; повторный просмотр и работа после обновления/долгого capture дают свежие кадры. Не считать новый случай автоматически следствием UI или Node update. |
| Следующий, P4 + P5 | Совместимый локальный просмотр в установленном Node/WebKit. Исходный план предусматривает HTTP/fMP4 carrier от той же медиа-сессии; переиспользуются общие media lifecycle/lease части K1, без импорта K1 protocol или второго SDK владельца X4. | На Ubuntu в приложении Node есть движущееся изображение; одновременно открыт удалённый Core. Закрытие одного зрителя сохраняет другого, не меняет SD recording. Все runtime dependencies входят в .deb/profile. |
| Затем, P4C | Матрица поддержанных действий по фактическим SDK headers и capabilities: camera settings, normal photo/video, ISO/exposure/WB/resolution, отдельные SD start/stop и фото. Проверять readback, mode dependencies и отображение результата. | Явные адресные команды из обеих UI, реальные результаты на камере, неизвестный outcome не переигрывается автоматически. Не обещать все режимы SDK до их проверки; shutter/EV setters и неподдержанные поля перечисляются отдельно. |
| P4C + общий source-record workflow | Получение содержимого выбранного файла на Node и в Core, bounded transfer, прерывание/продолжение, длина/hash и происхождение. Каталог уже есть, download ещё нет. | Пользователь получает существующий файл без shell; повторы/обрыв связи не меняют оригинал на SD. Незавершённый записываемый файл обрабатывается явно. |
| P3/P4/P5 | Устойчивость:30 минут выбранного профиля, displayed FPS и glass-to-glass latency p50/p95/max, CPU/RAM/USB/network; idle/start/stop, stale, закрытие Core, loss/recovery и replug. | Измеренный профиль, честные статусы, ограниченные очереди; журнал отличает реальные тесты от synthetic. Физические отключения требуют отдельного согласованного окна, не выполняются фоном во время работы владельца. |
| P1/P3/P6 | Несколько одинаковых X4 и D455, одновременная K1, exact-device routing, isolation/crash/replug. D455 shared-process migration остаётся отдельной реализацией. |2/4 реальные камеры независимы;500 synthetic descriptors не превращаются в обещание500 потоков. Текущий admission4 sources/4 peers/2 peers per camera пересматривается только по измерениям. При отсутствии устройств hardware часть остаётся открытой. |
| P7 | Чистая Ubuntu24.04 Desktop amd64 с закреплённым образом; полный installer → discovery → prepare из обеих UI → image → управление; upgrade/repair/rollback/failure matrix. | Никакой системной предпосылки вне installer, repeat/recovery сохраняют identity/trust/recordings. Текущий рабочий диск Mini не стирается. Отдельный чистый носитель/образ — необходимое условие, не предположение о наличии второй машины. |
Критический путь следующего рабочего инкремента: **зависание свежих кадров → локальное видео Node → приёмка управления/фото → получение файлов**. Контракт и учёт clean install проверяются при каждом изменении, финальная установка на чистый носитель завершает воспроизводимость. Общее наблюдение K1/monitor и их открытые fault/backfill/source-import проверки сохраняются в исходной матрице; успех X4 их не закрывает.
Stitching не включается: текущая цель — операторский обзор с низкой задержкой. Worker, AI и управление движением не являются зависимостями. Если нужен сшитый обзор позднее, это отдельный профиль с собственной измеренной задержкой.
## Условия поставки и выполнения
Работа идёт на существующей Ubuntu Mini через versioned artifacts с hashes/UTC/monotonic, без ручных apt/pip/служебных правок. Изменённый DG сначала становится общим компонентом, затем встраивается в обе UI. Внешний релиз vendor SDK требует отдельно разрешённых условий распространения. Полный интерфейс управления не включает неоговорённые destructive operations: delete/format/firmware/power.
ограничен более новыми моделями; наличие объявления метода в общем SDK header
не означает поддержку X4. Новый SDK также описывает auto-stop recording on
disconnect для части прошивок; текущий bridge его не включает, совместимость
и требуемая политика отдельно не приняты.
[uhubctl](https://github.com/mvp/uhubctl#faq) требует аппаратной поддержки.
Даже заявленный power switching может отключать только данные, оставляя5V.
Нужна физическая проверка VBUS на точном разъёме. С аккумулятором снятие внешних
5V не даёт гарантированного полного выключения X4. Если встроенный порт не
подходит, следующий аппаратный вариант — управляемый USB-хаб с отдельным
питанием и доказанным индивидуальным VBUS switching. Покупка/изменение схемы
питания ещё не выполнялись.
## Следующий инкремент
Приоритет владельца: после применения B11 поставить автономность и питание
перед расширением настроек камеры и загрузкой файлов.
| Шаг | Проверка и результат |
|---|---|
| 1. Стабильный baseline | Штатный preview STOP при подтверждённом recording0 → model preparation B11 из Core/Node → START, повторный START, verify, viewer reopen. Сохранить timestamps и реальные кадры. |
| 2. Повторное подключение | Контролируемое USB disconnect/reconnect при открытом наблюдении: offline камеры при online Node, прежний device_id, новая session_id, отсутствие повторной установки и ручного выбора Android. Замерить время SDK-ready/первого кадра. |
| 3. Холодный запуск | Отдельно camera power cycle и reboot Ubuntu, с фиксацией battery presence, USB mode retention, wake-on-power, порядка запуска служб. Не объединять результаты этих сценариев. |
| 4. Автовосстановление | По выявленным отказам добавить bounded SDK reopen/backoff/watchdog per instance. Для включённого профиля автопросмотра хранить намерение preview отдельно от SDK-сессии и восстанавливать его после подтверждения той же камеры; UI пересоздаёт WebRTC на новой сессии. SD-запись/фото не повторяются. |
| 5. Питание разъёма | Включить адресную диагностику/действие в versioned preparation artifact. Прочитать hub capability, сопоставить USB2/USB3 пару, проверить физический VBUS off/on и сохранность остальных портов. Только после доказанного питания — сценарий без батареи и измерение потребления при запуске/preview. |
| 6. Приёмка | Несколько успешных replug/cold-start циклов,30 минут выбранного потока, измерение задержки и восстановления; все зависимости/права/правила/откаты входят в installer, чистый OS image остаётся отдельной проверкой. |
Целевой профиль: после однократной подготовки включение борта приводит к
обнаружению X4 и доступному операторскому видео без локального нажатия на
камере. Для необслуживаемого восстановления после аппаратного зависания
дополнительно нужен доказанный способ полного power cycle. Пока не пройдены
шаги2–6, этот результат не объявляется достигнутым.
Проверки отключения, reboot и VBUS выполняются в объявленном окне наблюдения.
В этом проходе они не запускались. Любое изменение Ubuntu сначала входит в
версионированный артефакт; глобальный USB controller reset и широкие права на
все хабы не используются для восстановления одной камеры.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
DCCONSTRUCTIONS