Record B11 hardware acceptance and X4 USB reconnect failure

docs/node/07_INSTA360_X4_INSTALLATION_LEDGER.md

@@ -508,3 +508,88 @@ In Progress, существующие labels Mission Core/Plugin SDK/Status. Rea
 0df67aa2-82a6-42df-8ca2-f3a279392166 с результатами/commits/ограничениями;
 его базовое тело и критерии не изменялись. Все записи — официальными tools с
 отдельными idempotency keys, без исходных media/секретов/адресов оборудования.
+
+
+## PUSH01 / PREP05 — штатное применение B11,10.09.2026
+
+По прямому поручению владельца выполнены fetch, проверка fast-forward и обычный
+push main:main. Readback origin подтверждает DG8c53f73ee521561a1cc7944a7f7cf113702f40b5
+и Core7e257275ab607d9df184ae495523ccdc88713375. Force push и перезапуск служб не
+выполнялись. Первое чтение loopback API блокировано sandbox до доступа к Core;
+разрешённое повторное read-only чтение подтвердило Core operational, Rover online,
+X4 connected/preview1/recording0.
+
+PREP05 intent: через существующий Core fleet OperationRequest остановить preview,
+дождаться свежего idle/recording0/preparation_safe, затем один prepare с deadline350s.
+Owner step — установленный Node0.8.19 model profile; bundled X4 package0.1.3-3,
+SHA-256 c10f9c1e7f8237d9df202bc29483d61f27280920d76611b1aa1c4f3a72332540,
+revision b291418f2a404cbdafc57431. Зависимости, APT, права, службы и payload принадлежат
+уже квалифицированному профилю; ручных изменений Ubuntu не будет. Команды имеют
+отдельные persisted idempotency IDs; unknown не повторяется. При ошибке сохраняются
+receipt и фактическая версия, откат только отдельным versioned profile после
+диагностики. SD record/photo не запускаются. Private raw evidence с UTC/monotonic
+и source SHA сохраняется в ignored plugins/insta360-x4/build/acceptance-core/prep05.
+После обновления — проверка версии и WebRTC START/repeated START/active verify/reopen.
+
+
+PREP05 observer correction: preview.stop complete06:35:08.675896 UTC; worker
+штатно инвалидирует snapshot до следующего refresh. Проверка слишком рано
+потребовала online и завершилась до prepare, изменения модели не было. Failed
+report сохранён как report-first-observer.json, SHA-256
+1f63afebeefca8d8269d3af2f864eb633da116676fa103ea9e7fd27b7f1f28e9.
+Observer теперь допускает переходное состояние во время bounded25s ожидания,
+но перед prepare по-прежнему требует fresh/online/idle/recording0. Применённая
+STOP не повторяется при уже остановленном preview; новая попытка имеет отдельные IDs.
+
+
+PREP05 complete06:35:58.880788 UTC; observer06:35:43.700613→06:36:03.893209 UTC,
+monotonic442623.678362541→442643.870539625. Node0.8.19 штатно установил model0.1.3-3,
+read-only dpkg/profile/service check подтвердил версию, revision/hash и active
+broker/supervisor,NRestarts0. SDK session новая, device identity прежняя,
+preview0/recording0. Report SHA-256
+51af713e893cbad921771154eb654925373c120e92520e9c9e2fffe735097ca3.
+
+LIVE06 complete06:39:57.810416 UTC,monotonic442877.827039916: один ограниченный
+Mac WebRTC receiver из существующей repository .venv, без новых dependencies.
+Preview START, repeated START, active verify, close own peer, reopen, close own
+peer — все complete. Два зрителя последовательно получили739 и344 реальных
+декодированных кадров1280×640 в окнах70s и30s. Active verify подтвердил2 новых
+кадра за144ms, поток продолжался. Максимальный sample age полученного кадра0.160s
+не является glass-to-glass latency. Хеши выбранных decoded planes различаются;
+SD recording0, preview оставлен включённым. Private report SHA-256
+05be875744b9bf4771d33bb4ea412a39fcc4f77957862406dfc1a75936c44565.
+Долгая устойчивость и все причины исходного stale случая этим тестом не закрыты.
+
+REPLUG01 intent: включить bounded300s read-only observer Core fleet, затем попросить
+владельца вынуть только USB X4 на10s и вернуть в прежний порт при установленном
+аккумуляторе. Наблюдать Node online, disappearance/session change, прежний device_id,
+SDK ready и preview state; не посылать START/prepare автоматически, чтобы отделить
+поведение установленного продукта. Владелец сообщает о выборе USB-режима. Никакие
+порты/питание/службы программно не переключаются, SD-команды не отправляются.
+
+
+REPLUG01 completed06:41:05→06:46:06.210181 UTC,final monotonic443246.225200291:
+296 snapshots,Node online296/296; автоматическое возвращение X4 не произошло.
+Kernel disconnect06:41:44.606020 UTC; Core отразил camera offline в sample
+06:41:45.179860. Session изменился на discovery placeholder, НЕ новую открытую
+SDK session. Read-only USB inventory06:45:07 UTC не содержит X4 ни в одном режиме;
+сохранились D455 и другие USB устройства. Worker отсутствующего экземпляра inactive,
+supervisor active,NRestarts0. Kernel показывает только disconnect и xHCI WARN
+«Set TR Deq Ptr cmd failed due to incorrect slot or ep state» при отключении;
+нового attach/enumeration нет. Причинность WARN не установлена.
+
+Владелец подтвердил: после извлечения USB экран камеры вернулся к собственному
+preview; после обратной вставки кабеля этот экран остался, оба UI показывают
+отключение. Физическое возвращение кабеля подтверждено владельцем, USB enumeration
+не произошло. Это failure возврата транспорта, а не доказанный отказ SDK reopen
+или доказанная потеря сохранённого Android-режима. До новой enumeration повторение
+prepare/START не решает наблюдаемый барьер. Ответ об индикаторе внешнего питания
+запрошен; power cycle и переключение режима пока не выполнялись.
+
+Private reports0600: replug01.json SHA-256
+ a2eb5f4ee40813ddde79847044b74ab54cb24904690caf62c85c2a600249ce84;
+replug-usb-read.json SHA-256
+61ba35da06b4f3965fa087ff3c926989cda55534b4180cc767bd5e64f07418d2.
+Наблюдатель завершён, SDK commands после LIVE06 не посылались. Результаты
+PREP05/LIVE06 записаны в MISSIONCOR-77 через официальный MCP, checker B11 отмечен
+и readback подтверждён; replug/cold start/power остаются открытыми.

docs/node/09_INSTA360_X4_IMPLEMENTATION_STATUS.md

@@ -1,22 +1,22 @@
 # Insta360 X4 — состояние реализации 10.09.2026
 
-## Кандидат исправления09.09.2026 — B11/P09
+## B11 применён и проверен10.09.2026 — PREP05/LIVE06
 
 Подготовлен 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. Наличие конкретного исправленного дефекта не доказывает, что устранены все причины прежнего зависания.
+**PREP05/LIVE06 complete:** штатная подготовка из Core установила bundled X4 model0.1.3-3 через Node0.8.19 без нового пароля. Реальный WebRTC receiver получил739 и344 кадров1280×640 в двух последовательных окнах70s/30s. START→повторный START→active verify→viewer reopen прошли; verify подтвердил2 новых кадра за144ms, поток не прервался. Закрыты только собственные peers, preview оставлен включённым, SD recording0. Это ограниченная аппаратная приёмка B11; длительная устойчивость и все причины прежнего зависания остаются отдельными проверками.
 
 **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 остаются открытыми.
+**Установлено на имеющейся Ubuntu:** Node **0.8.19**, X4 Debian package **0.1.3-3**, model protocol **0.1.3**. P10 изменил Node binary/provenance, остальные payload bytes совпали с P09. PREP04 ранее развернул X4 из удалённого Core8000 → настройки X4 → «Обновить». Core8000 использует квалифицированный UI N09 и исправление NET03. Восстановление канала и ограниченная аппаратная приёмка B11 завершены; далее replug/cold start и устойчивость.
 
-**Новый открытый случай UI01 после P08:** собственный повторно подключённый зритель получил1280×640, затем currentTime остановился на4.846 s и появился статус «Нет свежих кадров». Следующее открытие не получило первого кадра; штатный verify завершился error. Камера продолжает сообщать online=true, preview1, recording0. Причина не установлена; временная последовательность после обновления не доказывает его причинность. Захват владельца не перезапускался, закрыты только собственные peers. Разбор этого случая становится первым следующим пунктом.
+**История UI01 после P08, до B11:** собственный повторно подключённый зритель получил1280×640, затем currentTime остановился на4.846 s и появился статус «Нет свежих кадров». Следующее открытие не получило первого кадра; штатный verify завершился error. Камера продолжает сообщать online=true, preview1, recording0. Причина не установлена; временная последовательность после обновления не доказывает его причинность. Захват владельца не перезапускался, закрыты только собственные peers. B11/LIVE06 выше закрывает повторный START и active verify; все причины длительного зависания этим не доказаны.
 
 **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.
+Во время того же успешного потока verify вернул error, видео продолжилось. В той версии verify открывал новый decoder посреди encoded stream и не был надёжным критерием отсутствия работающего preview. Operations дополнительно скрывал собственное сообщение verification под общей ошибкой unsupported parameter. Эти два дефекта исправлены в B11 и проверены LIVE06; в прежней версии 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.
 
@@ -38,7 +38,7 @@ X4 — операторский несшитый просмотр и управ
 | Подготовка из двух 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 не измерены. |
+| Живое видео | Bounded binary IPC, codec headers per stream/generation, ранний decoder, общий источник между зрителями, отдельный encoder peer. | LIVE04: H2641280×640 в удалённом браузере, первый старт, viewer reopen и capture restart без SD. Output ограничен≤15Hz; LIVE06 подтвердил повторный START/verify/reopen. Glass-to-glass 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 ещё не реализован. |
@@ -83,3 +83,7 @@ CameraSDK2.1.8 Linux x86_64 получен из [pdxmusic/insta360sdk, pinned co
 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).
+
+PUSH01: оба main опубликованы штатным fast-forward push и проверены по remote SHA: Core7e257275ab607d9df184ae495523ccdc88713375, DG8c53f73ee521561a1cc7944a7f7cf113702f40b5. Бинарные пакеты и SDK в Git не опубликованы. Следующий эксперимент REPLUG01 наблюдает физическое переподключение владельцем.
+
+REPLUG01 не прошёл: после подтверждённого владельцем возврата кабеля X4 не вернулась в USB enumeration; Node online296/296 snapshots. Это барьер транспорта до SDK, причина между камерой/кабелем/портом не локализована. Повторные prepare/START не запускались. Подробности в плане11 и ledger.

docs/node/10_INSTA360_X4_NEXT_STEPS.md

@@ -8,11 +8,11 @@ X4 подключена к SDK на той же Ubuntu Mini. Удалённая
 
 Дополнение 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. Остальные причины возможных разрывов и длительная устойчивость остаются в плане.
+B11/P09,09.09: эта реализация готова и прошла38 Ubuntu tests. Дополнительно исправлен доказанный code path, в котором idempotent повторный START очищал feed без нового keyframe. Первоначально model0.1.3-3 ожидал штатной подготовки; ниже зафиксирован завершённый PREP05/LIVE06 на Node0.8.19. Остальные причины возможных разрывов и длительная устойчивость остаются в плане.
 
 Предварительное условие 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 не объявляются принятыми.
+P10/PREP05 complete: Node0.8.19 и X4 model0.1.3-3 установлены штатно. LIVE06 подтвердил первый и повторный START, active verify и viewer reopen:1083 декодированных кадра1280×640, без SD записи. Следующий шаг — физический USB replug, затем отдельные cold-start сценарии. Задержка NET03 recovery и длительная video stability остаются открытыми.
 
 ## Очередь реализации
 
@@ -27,7 +27,8 @@ camera settings/file download. Конкретная матрица, доказа
 | Порядок / связь с исходным планом | Работа | Конкретный выход |
 |---|---|---|
 | Завершено, 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. |
+| B11 ограниченно принят, P3/P4 | Исправлено очищение feed при повторном START и проверка активного потока через новый decoder. PREP05/LIVE06: repeat START, live verify, viewer reopen complete. |1083 кадра1280×640; долгий capture и все возможные причины stale отдельно не приняты. |
+| Первый следующий, P3/P4 | USB replug и отдельный cold start; затем bounded SDK recovery/preview intent и адресное питание по плану11. | Возврат того же экземпляра без переустановки и ручного режима, восстановление изображения; VBUS доказан отдельным физическим тестом. |
 | Следующий, 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. Незавершённый записываемый файл обрабатывается явно. |
@@ -35,7 +36,7 @@ camera settings/file download. Конкретная матрица, доказа
 | 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 их не закрывает.
+Критический путь по последнему решению владельца: **USB replug → cold start/SDK recovery/preview intent → адресное питание → локальное видео Node → приёмка управления/фото → получение файлов**. B11 имеет ограниченную аппаратную приёмку; длительная устойчивость остаётся самостоятельным gate. Контракт и учёт clean install проверяются при каждом изменении, финальная установка на чистый носитель завершает воспроизводимость. Общее наблюдение K1/monitor и их открытые fault/backfill/source-import проверки сохраняются в исходной матрице; успех X4 их не закрывает.
 
 Stitching не включается: текущая цель — операторский обзор с низкой задержкой. Worker, AI и управление движением не являются зависимостями. Если нужен сшитый обзор позднее, это отдельный профиль с собственной измеренной задержкой.
 

docs/node/11_INSTA360_X4_AUTONOMY_AND_USB_POWER.md

@@ -8,11 +8,11 @@
 
 ## Что подтверждено
 
-- Rover006 online через Tailscale, Node0.8.19. Модель X4 установлена0.1.3-2;
-  исправление B11/0.1.3-3 входит в Node, но ещё не применено.
-- Последняя прочитанная телеметрия X4 v1.7.18: connected=true, preview=1,
-  recording=0, battery level100. Это сведения камеры; свежие отображённые кадры
-  и достаточность внешнего питания этим чтением не проверялись.
+- Rover006 online через Tailscale, Node0.8.19. Модель X4 обновлена штатной подготовкой PREP05 до0.1.3-3;
+  B11 прошёл LIVE06: repeated START, active verify и viewer reopen,1083 кадра1280×640.
+- Baseline перед REPLUG01, X4 v1.7.18: connected=true, preview=1,
+  recording=0, battery level100. LIVE06 отдельно подтвердил свежие декодированные кадры в удалённом WebRTC receiver.
+  Достаточность внешнего питания не измерялась.
 - Борт — Apple Macmini6,2. X4 подключена напрямую к xHCI USB3,5000M.
   Linux предоставляет `disable` для отдельных портов и соответствие USB2/USB3
   половин физического разъёма. Наличие файла не доказывает отключение VBUS.
@@ -20,6 +20,22 @@
   characteristics; поддержка аппаратного per-port power switching не определена.
   bMaxPower из USB descriptor не является измерением реального потребления.
 
+## REPLUG01 — возврат USB не произошёл
+
+10.09.2026,06:41–06:46 UTC: владелец вынул и вернул USB-кабель. Камера перешла
+к локальному экрану preview и после вставки осталась на нём. Linux зафиксировал
+отключение, но нового attach/enumeration не было; X4 отсутствует в lsusb.
+Rover online296/296 snapshots, D455 остаётся на USB. Supervisor остановил службу
+исчезнувшего экземпляра. Появившийся discovery session_id не означает открытия SDK.
+
+При disconnect есть xHCI warning; причинность не установлена. Барьер сейчас ниже
+SDK: прежде чем квалифицировать reopen, нужен возврат USB enumeration. Нельзя по
+этому наблюдению заключать, что прошивка забыла Android-режим. Следующая развилка:
+подтвердить внешний power indicator на X4, отдельно проверить штатное выключение/
+включение камеры при подключённом кабеле и сохранение режима; адресный host-port
+reset допускается только через versioned artifact с mapping companion ports и
+сохранением остальных устройств. Полный controller reset не выполняется.
+
 ## Поведение текущего приложения
 
 Установка драйвера сохраняется после отключения. Supervisor сопоставляет USB
@@ -72,7 +88,7 @@ disconnect для части прошивок; текущий bridge его не
 
 | Шаг | Проверка и результат |
 |---|---|
-| 1. Стабильный baseline | Штатный preview STOP при подтверждённом recording0 → model preparation B11 из Core/Node → START, повторный START, verify, viewer reopen. Сохранить timestamps и реальные кадры. |
+| 1. Стабильный baseline — PREP05/LIVE06 пройден | Штатный 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-запись/фото не повторяются. |