From fecb5885d0663a7d0d15239c6afa608693a49172 Mon Sep 17 00:00:00 2001 From: DCCONSTRUCTIONS Date: Sun, 19 Jul 2026 01:07:33 +0300 Subject: [PATCH] docs(milestone): record K1 control and archive acceptance --- README.md | 36 +++--- docs/01_IMPLEMENTATION_PLAN.md | 68 ++++++----- docs/05_K1_MQTT_STREAM_PROFILE.md | 65 +++++++---- docs/06_K1_LIVE_VIEWER.md | 13 ++- docs/07_MISSION_CORE_MONOREPO.md | 49 ++++---- .../0012-device-bound-k1-command-authority.md | 43 +++---- ...K1_CONTROL_ACCEPTANCE_20260718.redacted.md | 88 +++++++++++++-- ...NICAL_CONTROL_ARCHIVE_20260719.redacted.md | 106 ++++++++++++++++++ plugins/xgrids-k1/README.md | 18 +-- 9 files changed, 353 insertions(+), 133 deletions(-) create mode 100644 docs/lab/004_K1_CANONICAL_CONTROL_ARCHIVE_20260719.redacted.md diff --git a/README.md b/README.md index 2b29e62..be2402a 100644 --- a/README.md +++ b/README.md @@ -27,8 +27,9 @@ The K1 acquisition now also requires an operator project name. Frontend and backend normalize it with NFKC plus surrounding-whitespace trimming, reject control/surrogate characters and values above 96 Unicode characters, and preserve it as local session/catalog display metadata. It is never used as a -filesystem path. Because K1 command publishing is disabled, the current runtime -does not claim that this value has been transmitted to the scanner. +filesystem path. The physically accepted interactive control path carries the +same validated value in its single canonical START; there is no separate +project-name write. Plugin SDK v0alpha2 now provides executable, vendor-neutral identity, session, operation, runtime-action, stream, evidence and compatibility contracts. Every @@ -42,10 +43,10 @@ normalizer to produce transport-neutral local consumer views; portable SDK stream envelopes, process isolation, durable operations, multi-device routing and the remote Edge split remain later gates. -The current runtime cannot read K1 firmware automatically. It keeps the exact -profile inactive until the operator explicitly attests firmware `3.0.2` and -direct-LAN topology; state records that basis as `operator-attested`, not as -device-derived evidence. +The application-control bootstrap reads and correlates live `DeviceInfo` before +START. The exact profile requires model `LixelKity K1`, observed platform type +`A4`, activated state, firmware `3.0.2`, and direct-LAN topology. The UI selects +that profile but does not ask the operator to attest firmware manually. The repository now contains one narrowly gated state-changing command: `ble wifi-configure`. It accepts only the reviewed firmware-3 provisioning @@ -138,7 +139,8 @@ local reception; plugin-commanded v0.5.0 acquisition uses the separately gated canonical K1 START/STOP dialogue. The exact recovered `ModelingRequest` start/stop encoder, response correlator -and device-status state machine are implemented as inert protocol components. +and device-status state machine are installed in the operator-gated interactive +control path. The plugin also contains the exact ten-request pre-START bootstrap recovered from retained LixelGO traffic. Its first `DeviceInfoRequest` has no device ID; the response supplies live vendor identity, serial, model, activation and @@ -157,7 +159,7 @@ keepalive 60, exact response subscriptions, QoS2 completion and the five response-gated batches. It consumes operation keys before publish and poisons unknown outcomes without retry. One background owner services that socket through response-gated -connection, workspace, project, START, STOP and steady-green stages. The normal +connection, workspace, project, START, STOP and device-standby stages. The normal UI collapses only the pre-START controls into one explicit operator intent; navigation cannot emit a command. The first operator-present physical attempt on 2026-07-18 emitted only the first six bootstrap requests, then failed closed while correlating the third @@ -172,11 +174,13 @@ workspace-entry request 7, project-prompt reads 8–10, user-confirmed START 11, immediate status read 12 and state-gated reads 13–14 onto one continuously owned MQTT session. No captured operator delay is a protocol timer: the final reads wait for live `SCANNING`, project binding and `init_ready`, while STOP/save waits -for live `READY` plus physical standby confirmation. Standalone START and STOP +for live unbound `READY`. Standalone START and STOP are both rejected. The same socket is serviced throughout launch and STOP confirmation, and no captured human delay is replayed as a protocol timer. -Plugin v0.5.0 wires this executor to the facade and plugin UI; physical command -acceptance remains an operator-run gate. +Plugin v0.5.0 wires this executor to the facade and plugin UI. The full staged +START/live/STOP/save cycle is physically accepted on the reviewed unit. START +and STOP each retain an explicit operator action; final local sealing now follows +the scanner's protocol-reported unbound READY without a redundant second click. This locked bootstrap is repeatable in the current workspace, not yet a standalone release install. The frontend consumes sibling `file:` packages from @@ -314,7 +318,9 @@ present. - [Device-plugin observation runtime and K1 extraction](docs/adr/0009-device-plugin-observation-runtime-and-k1-extraction.md) - [Plugin-owned frontend device workflows](docs/adr/0010-plugin-owned-frontend-device-workflows.md) - [Laboratory plugin runtime handshake and transport seam](docs/adr/0011-laboratory-plugin-runtime-handshake-and-transport-seam.md) +- [Device-bound K1 command authority](docs/adr/0012-device-bound-k1-command-authority.md) - [Redacted live lab report](docs/lab/001_K1_LIVE_MQTT_20260715.redacted.md) +- [Canonical control and durable archive milestone](docs/lab/004_K1_CANONICAL_CONTROL_ARCHIVE_20260719.redacted.md) - [Session manifest schema](schemas/session-manifest.schema.json) - [Reference input provenance](docs/reference/README.md) @@ -330,9 +336,11 @@ capture of traffic to or from the confirmed K1 address, and offline analysis of owned artifacts. The reviewed provisioning write requires its named profile and explicit operator -confirmation. Application command publishing remains disabled: physical -double-click is the verified start/stop mechanism. Any future MQTT publisher, -router configuration change or new BLE write requires its own evidence and +confirmation. The interactive application-control publisher is enabled only for +the exact K1/A4/FW 3.0.2 direct-LAN profile and only inside one operator-opened, +response-gated session; physical double-click remains the independent fallback. +The legacy shadow publisher remains structurally disabled. Any broader firmware, +topology, scanner-family or command surface requires its own evidence and reviewed step. Random writes, fuzzing, brute force, firmware operations, destructive file access and credential guessing remain out of scope. diff --git a/docs/01_IMPLEMENTATION_PLAN.md b/docs/01_IMPLEMENTATION_PLAN.md index 2bdc2bc..3e4b228 100644 --- a/docs/01_IMPLEMENTATION_PLAN.md +++ b/docs/01_IMPLEMENTATION_PLAN.md @@ -19,46 +19,47 @@ Each gate produces evidence and an explicit GO, PAUSE or BLOCKED result. | Stage 5 camera | GO (live) — left/right RTSP/H.264 preview observed, read-only runtime adapter and physical UI acceptance completed | | Stage 6 live viewer | GO — React Control Station, embedded self-hosted Rerun cloud/trajectory, plugin-owned spatial controls and live device/Mac metrics | | Stage 7 observation archive | GO (point/pose/telemetry contract) — durable catalog, recovery, capture-clock-bounded RRD preparation, archived metric time series, saved-session timeline and atomic playback are implemented | -| Stage 7 recorded cameras | GO (contract), acceptance pending — acquisition-owned fMP4 archive and player are implemented/tested; one real archived K1 camera plus point-cloud session has not passed playback yet | +| Stage 7 recorded cameras | GO — the accepted physical session sealed real fMP4 camera data, produced two digest-bound recorded sources and passed manifest/init/segment range admission alongside a 107 MB RRD; browser QA opened real frames from the 170 MB camera epoch at multiple shared-timeline positions | | Plugin isolation | GO (laboratory control plane) — vendor backend/frontend and optional scene controls are plugin-owned; manifest/runtime descriptor parity, versioned handshake, lifecycle health and transport correlation fail closed while execution remains in-process | -| K1 application control | OPERATOR ACCEPTANCE READY — the failed protocol-collapsed path and standalone START/STOP remain disabled. Plugin v0.5.0 installs one continuous control-session owner; one explicit UI launch intent advances connection, workspace, project and START only across live response barriers, while STOP and steady-green confirmation remain separate. No wall-clock transition, automatic retry, navigation-triggered command or repository-test equipment I/O exists. A full operator-run physical cycle and native-project verification remain open | +| K1 application control | GO (physical staged cycle) — after fixing the PCAP-proven `sint64` time field, one explicit UI launch completed all 14 canonical operations on one control session, reached live `SCANNING + project + init_ready`, displayed real points, then one explicit STOP returned K1 to unbound `READY`. No retry or fallback command was sent. Native-project reuse through LixelGO/USB remains an independent verification | | Stage 8 product storage | PAUSE — retention, replication, encryption, capacity monitoring and long-run browser/WASM stress remain deployment gates | USB project copying remains optional ground truth rather than a blocker for the now-verified network path. Owner-operated LixelGO traffic verifies the MQTT start/stop mapping and RTSP camera transport. The exact start/stop protobuf -encoder, response correlator and device-status state machine now exist without a -publisher. Retained PCAP plus client static analysis prove that OpenAPI is one +encoder, response correlator and device-status state machine now run in the +separately gated interactive publisher; the legacy shadow publisher remains +disabled. Retained PCAP plus client static analysis prove that OpenAPI is one private application-level value in this LixelGO build, not a per-scanner credential. The selected BLE peripheral returns its own LAN IP; the initial unbound `DeviceInfoRequest` then returns vendor ID, serial, model, activation and version facts for that live K1. Mission Core's shadow bootstrap reproduces the -10 observed pre-START requests byte-for-byte across five recovered batches: -initial DeviceInfo binding; ModelingStatus plus RTK read; time sync plus -DeviceInfo/RTK; NTRIP read; then cloud/RTK/DeviceInfo reads. The first +10 observed pre-START requests byte-for-byte across four response windows and +five observed publish groups: initial DeviceInfo binding; then the ordered +ModelingStatus/RTK and time-sync/DeviceInfo/RTK groups without an invented +response barrier between them; NTRIP read; then cloud/RTK/DeviceInfo reads. The first ModelingStatus request has no mandatory synchronous response barrier; readiness is separately attested through live DeviceStatus. A fixed macOS Keychain loader now reads the exact 36-byte authority without environment/file/browser fallback. The response orchestrator correlates required headers/results and rejects -identity/profile drift. The installed publish boundary is a separate -write-disabled type that cannot call its injected sink. A dormant coordinator -is now wired into the XGRIDS facade and plugin manifest. Explicit operator arm -loads the Keychain value into a bounded 15–300 second process-memory lease; -expiry, disarm, reprovision, acquisition preparation and shutdown drop both the -lease and orchestrator. Public state contains only lease timing/booleans. There -is deliberately no batch-emission method, live MQTT sink or UI button in the -installed runtime. A separate physical-acceptance-only transport and dialogue -executor now implement the reviewed MQTT exchange without facade/UI wiring. -Each operation key is consumed before publish, automatic reconnect and -application retry are forbidden, and any unknown outcome poisons the transport. +identity/profile drift. The legacy shadow publisher remains a separate +write-disabled type that cannot call its injected sink. Its dormant coordinator +is wired into the XGRIDS facade only for redacted planning/state. Separately, +plugin v0.5.0 installs the reviewed physical-acceptance transport behind explicit +operator actions and one continuous background session owner. Each operation +key is consumed before publish, automatic reconnect and application retry are +forbidden, and any unknown outcome poisons the transport. Public state contains +only bounded lifecycle, counter and failure metadata; authority and device +identity remain private. The one-time `k1link authority provision` command delegates secret entry to the macOS Keychain TTY prompt and validates through the production loader without receiving the value in argv/environment/file/browser state. During the first physical attempt that CLI loader did not receive macOS approval, so a temporary process-local Security.framework lab adapter supplied the already reviewed value. The transport emitted bootstrap ordinals 1–6 and received all five -required responses through batch 3, but the orchestrator raised -`ApplicationBootstrapError` while correlating that batch. No START was emitted; +required responses through the old third window, but topic-only routing +misassociated the unbound and bound RTK responses and the orchestrator raised +`ApplicationBootstrapError`. No START was emitted; live DeviceStatus stayed READY and the local point/pose counts remained zero. The local capture was sealed and the temporary Keychain item was deleted. The second physical attempt then correlated all ten bootstrap requests and one @@ -77,10 +78,15 @@ START confirmation. Captured human delays are not replayed or treated as minimum timeouts. After the immediate operation-12 read, operations 13–14 wait for the same bound K1 to report `SCANNING`, a bound project and `init_ready=true`. The same transport is then serviced until an explicit STOP request; post-STOP -ownership waits for live `READY` plus physical standby confirmation. System-error -and status reports are decoded into redacted safety state. This path is not -wired into the plugin runtime/UI and has only synthetic regression coverage; -physical STOP/save remains untested and the button is the safe fallback. +ownership waits for live unbound `READY`. System-error +and status reports are decoded into redacted safety state. The next staged +physical attempt, after correcting the protobuf `sint64` time field, completed +all 14 canonical operations, reached live scanning with real point/pose data and +then completed one explicit STOP. K1 returned to unbound `READY`; no retry or fallback device command was +sent. The durable local session is catalogued as ready/replayable, its RRD and +two camera sources pass digest-bound range admission, and physical double-click +remains the fallback. Reuse of the vendor-native project is still verified +separately through LixelGO or USB. The Stage 6 live path uses a bounded raw-first bridge: loss in the visualization queue cannot discard MQTT evidence. The queue holds four preview messages; @@ -110,8 +116,9 @@ saved-session switching, persisted replay reattach and manual source input/apply/reset until that acquisition has been finalized. The successful automatic-source action is an internal start-result boundary and intentionally does not masquerade as an operator source switch. The K1 scene-level stop -control is plugin-owned; with the active read-only profile it stops and seals -local reception only and never claims to stop the scanner. +control is plugin-owned. A plugin-commanded acquisition sends one canonical STOP +and seals locally after protocol-reported standby; an operator-manual acquisition +still stops and seals only local reception and reports scanner state as unknown. ## Stage 0 — repository and host baseline @@ -297,11 +304,10 @@ useful stream is decoded or structurally identified. - automated scan-button electronics; - OpenWrt/monitor-mode infrastructure; - firmware or internal-Linux analysis; -- physical end-to-end shared-timeline playback for a newly archived session - containing point cloud plus one selected K1 camera; +- browser-visible end-to-end shared-timeline playback of the accepted archive + containing point cloud plus one selected K1 camera (backend preparation and + digest-bound byte admission are already accepted); - OS-independent plugin/edge authority provider, PCAP-to-executor transcript - regression, runtime ownership integration, a separately reviewed and newly - permitted operator-present START/STOP attempt, and stable-artifact proof after - STOP; + regression and runtime ownership integration; - long-running large-session WebViewer/WASM memory telemetry; - production retention, replication, encryption and cross-platform packaging. diff --git a/docs/05_K1_MQTT_STREAM_PROFILE.md b/docs/05_K1_MQTT_STREAM_PROFILE.md index 56048e8..0b65f25 100644 --- a/docs/05_K1_MQTT_STREAM_PROFILE.md +++ b/docs/05_K1_MQTT_STREAM_PROFILE.md @@ -186,10 +186,16 @@ special time-sync session is exactly `${device_id}:DeviceConfigRequest:Publish_Proto_DeviceConfig_SetTime`. The repository shadow bootstrap reproduces all ten retained payloads and their topic order byte-for-byte. Time sync is the only mutation before START; the -other nine requests are reads. +other nine requests are reads. Its Unix timestamp is protobuf `sint64`, not +`int64`/`uint64`: the retained value `3568430060` ZigZag-decodes to +`1784215030` (`2026-07-16 15:17:10 UTC`). The runtime encoder must therefore +ZigZag-encode the current epoch before writing field 1 of the nested time +configuration. -The first ten requests use five response-barrier batches, but those barriers are -not the whole application lifecycle. Two independent owner-operated START +The first ten requests contain five observed publish groups but only four +application-response windows. The initial DeviceInfo response is the identity +binding barrier; ordinals 2–6 then retain their exact publish order without an +invented response barrier between ordinals 3 and 4. Two independent owner-operated START captures contain the same 14-operation order: the ten requests above, START, one bound `ModelingStatus` read, then a bound `DeviceInfo` plus `ModelingStatus` refresh about 24–25 seconds after START. The first capture @@ -198,11 +204,15 @@ reached it after 54.130 seconds. This variation is operator/UI time, while the stage order is invariant. In both captures the original control MQTT connection remained open throughout initialization and the later refresh; no DISCONNECT or UNSUBSCRIBE occurred. DeviceInfo response establishes identity before later -bound requests. Required response barriers are correlated by topic, exact +bound requests. Required response barriers are correlated by operation key, topic, exact session, vendor identity, application authority and numeric success. The initial and immediate post-START ModelingStatus reads are intentionally not -treated as mandatory synchronous responses. Readiness belongs to live -DeviceStatus plus point/pose observation. +treated as mandatory synchronous responses. In both retained captures operation +12 has no application response; the single bound ModelingStatus response in +that part of the lifecycle arrives only after operation 14 and belongs to it. +An unanswered optional operation therefore cannot reserve FIFO ownership over +the required operation-14 response. Readiness belongs to live DeviceStatus plus +point/pose observation. The UI/event correlation is also fixed by the retained capture. Requests 1–6 follow successful data connection. Entering the scan workspace causes request @@ -221,7 +231,7 @@ from `SCANNING` with a bound project. It emits only a non-executable digest and wire metadata, uses QoS 2 with retain false, and declares automatic retry forbidden. It has no MQTT publish dependency and cannot send a command. -Publishing remains deliberately disabled. The exact 36-byte authority has a +Legacy shadow-plan publishing remains deliberately disabled. The exact 36-byte authority has a read-only macOS Keychain loader with no environment, file, browser or API fallback. A facade-owned dormant coordinator can arm it only after explicit operator confirmation, a connected/attested K1, idle runtime and no active @@ -230,8 +240,9 @@ seconds and is revoked by expiry, disarm, reprovision, acquisition preparation or shutdown. The current one-shot boundary is structurally write-disabled, exposes no emission method and cannot touch its injected sink. -A separate physical-acceptance-only implementation now exists outside the -facade/runtime. Retained-PCAP re-audit fixes its MQTT contract at 3.1.1, +A separate operator-driven physical-acceptance implementation is installed in +plugin v0.5.0 through the facade/runtime. Retained-PCAP re-audit fixes its MQTT +contract at 3.1.1, `clean_session=false`, keepalive 60, the three ordered 9/5/42-topic control subscription groups, separation from the point-cloud client, QoS 2 request/PUBCOMP completion and @@ -240,12 +251,14 @@ consumes every ordinal/action operation key before publish, never reconnects or retries, rejects stale/duplicate/unexpected responses and poisons every unknown post-publish outcome. A 15–120 second permit requires explicit operator-present, owner-controlled-device, LixelGO-closed, battery/storage and expected-state -confirmations. START additionally requires the complete five-batch bootstrap; -STOP requires its own separate permit. This code is not installed as a plugin -action. On 2026-07-18 its first operator-present physical attempt made one +confirmations. START additionally requires the complete four-window bootstrap; +STOP requires its own separate permit. No plugin state read, poll, navigation or +automatic lifecycle event may invoke either action. On 2026-07-18 its first +operator-present physical attempt made one connection and emitted bootstrap ordinals 1–6. All six QoS 2 publishes completed -and five required responses were collected, but exact correlation rejected one -response in batch 3. The executor stopped before building or publishing START; +and five required responses were collected, but the old topic-only collector +misrouted one of the two `GetRtkAdvance` responses in its third window. The +executor stopped before building or publishing START; K1 remained `READY`, project binding stayed absent and point/pose remained zero. No automatic retry was attempted. A second explicitly permitted attempt then correlated all ten bootstrap responses and one START success response, with 11 @@ -265,8 +278,9 @@ observed connection, workspace-entry and project-prompt checkpoints instead of wall-clock floors, sends the immediate post-START ModelingStatus read, services the same MQTT socket until live `SCANNING + project + init_ready`, then emits the DeviceInfo/ModelingStatus refresh. It continues servicing that socket until an -explicit STOP request and afterwards until live `READY` plus operator-confirmed -standby. System-error and DeviceStatus reports are decoded into redacted safety +explicit STOP request and afterwards until live unbound `READY`. That device +status is the canonical standby evidence; no second visual acknowledgement is +required. System-error and DeviceStatus reports are decoded into redacted safety state; a fault forbids further automatic action. Standalone START/STOP are disabled. MQTT keepalive/report processing also continues while the operator is between UI actions; the 15–120-second command permit is created at the actual @@ -284,13 +298,18 @@ one-shot process and deleted immediately afterward. It is not the product authority architecture. The acceptance executor now records only ordinal, message type, response topic, payload size, SHA-256 and a safe correlation reason; it never exposes response bytes or authority in diagnostics. The -retained clean-cycle still completes all nine bootstrap barriers offline, so -the open issue is a live batch-3 response divergence. The complete stop/save -sequence has not physically proved a durable vendor project. A -correlated STOP success, stream quiescence, return to -`READY`/steady-green hardware state and appearance of a reusable native project -are separate gates. The verified physical double-click remains the acquisition -control until a separately reviewed one-shot write gate closes. +retained clean-cycle now completes all nine bootstrap barriers offline while +ordinals 3 and 6 are simultaneously in flight and routes them by exact +session/device identity. After repairing the PCAP-proven protobuf `sint64` time +field, the next operator-run physical cycle completed all 14 canonical requests +on one socket, reached `SCANNING + project + init_ready`, delivered real +point/pose data and completed one correlated STOP. Streams quiesced, K1 returned +to unbound `READY`; no retry or fallback STOP was sent. The operator also +observed stable green, but that observation is not a second protocol gate. The +local archive sealed and passed digest-bound RRD and recorded- +camera admission. Appearance and reuse of the vendor-native project through +LixelGO or USB remains a separate gate. Physical double-click remains the +operational fallback. ## Decoder and raw-capture bounds diff --git a/docs/06_K1_LIVE_VIEWER.md b/docs/06_K1_LIVE_VIEWER.md index dad5fa6..d20d73d 100644 --- a/docs/06_K1_LIVE_VIEWER.md +++ b/docs/06_K1_LIVE_VIEWER.md @@ -134,8 +134,10 @@ directly and use their sibling metadata receive timestamps when present. from a browser timer or accumulated across a device counter reset. 10. Choose **Остановить устройство и запись** in the scene. The plugin-commanded path emits one canonical STOP on the original socket, - waits for live unbound READY, and asks the operator to confirm the constant - green indicator before capture, camera archive and summaries are finalized. + waits for live unbound READY, then finalizes capture, camera archive and + summaries automatically. The UI does not ask for a redundant green-indicator + confirmation because READY plus cleared project binding is already the + scanner's protocol evidence. Each new live run creates a direct child below `MISSIONCORE_EVIDENCE_DIR`, or `.runtime/mission-core/evidence/sessions/` by default, with raw MQTT frames, @@ -336,9 +338,10 @@ listener and its process memory must be closed unconditionally. left/right compressed RTSP preview and acquisition-owned fMP4 archive use a separate generic media path. Historical sessions predating that archive have no recoverable video. -- Physical double-click remains the K1 scan start/stop control. Any MQTT command - promotion needs reviewed Keychain item provisioning, operator-present use of - the uninstalled response-gated transport and durable-save proof. +- Physical double-click remains the independently verified device-local fallback. + Mission Core also contains the installed response-gated operator-present + acceptance transport for the exact K1/A4/FW 3.0.2 profile; its full + START-to-STOP durable-save cycle was physically accepted on 2026-07-18/19. - No terrain map, elevation model, obstacle segmentation, localization fusion, mission planner or vehicle control is implemented by this viewer milestone. - Exact coordinate axes and the scanner-to-vehicle transform remain a mounting diff --git a/docs/07_MISSION_CORE_MONOREPO.md b/docs/07_MISSION_CORE_MONOREPO.md index 495827b..5852445 100644 --- a/docs/07_MISSION_CORE_MONOREPO.md +++ b/docs/07_MISSION_CORE_MONOREPO.md @@ -128,15 +128,14 @@ requires every model to be covered by a reviewed, plugin-local, path-confined compatibility profile. The current XGRIDS profile matches exactly: - XGRIDS LixelKity K1; +- wire-level platform type `A4`; - firmware `3.0.2`; - direct-LAN topology; - one retained physical laboratory evidence scope. -Unknown or unattested firmware fails closed. The current runtime does not read -firmware from the device: it activates this limited, read-only profile only -after explicit operator attestation of firmware `3.0.2` and direct-LAN topology, -and records the basis as `operator-attested`. That claim is not device-derived -proof. The profile independently records observation, decode, replay, +Unknown or mismatched firmware fails closed. The UI selects the profile and the +canonical bootstrap verifies model, platform type, activation and firmware from +a correlated live `DeviceInfo` before START. The profile independently records observation, decode, replay, physical-verification and write evidence. Loading it cannot authorize a transport mutation. BLE Wi-Fi provisioning and application control retain separate explicit operator gates. @@ -149,30 +148,30 @@ is one private application-level authority; vendor ID and serial come from the BLE-selected live K1 and are cross-checked against status. Plugin v0.5.0 owns a single interactive MQTT session from connection through STOP/standby, with one explicit UI action per recorded lifecycle boundary and no automatic retry. A -fixed Keychain loader and dormant shadow coordinator remain present. Stable -physical proof after STOP remains unresolved; write capability is exposed only -while that interactive socket owner is active. +fixed Keychain loader and dormant shadow coordinator remain present. The staged +physical START/live/STOP/unbound-READY cycle is accepted on the reviewed unit; +write capability is exposed only while that interactive socket owner is active. ## Semantic lifecycle The transitional facade now creates separate provisional device, device-session, acquisition and operation IDs. Acquisition can be prepared, wait for receiver readiness, then wait for an external physical start, and become acquiring only after real point -data, wait for an externally confirmed stop, finalize and complete. Capture-only -stop reports the K1 physical state as unknown. +data. Plugin-commanded STOP finalizes automatically after the same bound control +session reports unbound READY. Operator-manual capture-only stop still reports +the K1 physical state as unknown. Preparation requires a project name. The frontend and backend both apply NFKC normalization plus surrounding-whitespace trimming, reject control/surrogate characters and names above 96 Unicode characters, and store the result as -session/catalog display metadata. It is not a path component. Because command -publishing is off, the current integration does not claim that the name reaches -K1. +session/catalog display metadata. It is not a path component. The accepted +interactive START carries this exact validated value to K1. The K1 contribution may mount a `SpatialControlsView` beside the host-owned -viewport. It presents plugin lifecycle wording, the local stop action and live -`ModelingReport` scan time, route distance and speed. Under the current -capture-only profile the stop action seals local reception; it does not claim a -device stop. `ModelingReport` is consumed before the visual preview queue through +viewport. It presents plugin lifecycle wording, the stop action and live +`ModelingReport` scan time, route distance and speed. In plugin-commanded mode +the stop action sends the canonical device STOP; in operator-manual mode it +seals only local reception. `ModelingReport` is consumed before the visual preview queue through an injected observer, preserving the generic normalizer/Rerun boundary. The operation journal is bounded and in memory. It records IDs, idempotency, @@ -180,9 +179,9 @@ declared deadlines, progress and terminal results without action parameters or s It is not durable, distributed or recoverable after process restart. Semantic acquisition actions coexist with legacy `stream.*` actions for -v1alpha1/UI compatibility. On this profile, start and stop operate the local -receiver and operator workflow only. K1 scanning is still started and stopped -by physical double-click; no modeling request is published. +v1alpha1/UI compatibility. On the exact accepted profile, a plugin-commanded +acquisition owns canonical START and STOP plus local reception. Physical +double-click remains the independently verified device-local fallback. Left/right camera preview transport, endpoint paths and H.264 framing are now observed under the exact compatibility profile. The local read-only adapter @@ -190,8 +189,8 @@ copy-remuxes one selected RTSP producer into bounded fMP4/WebSocket delivery for the generic MSE UI. New acquisitions archive selected-camera init/segments/index independently of browser delivery. The generic recorded player, manifest-v2 validation and shared `session_time` controls are connected; historical sessions -created before this archive contract contain no recoverable video, so physical -recorded-camera acceptance remains open. Portable FFmpeg packaging, disk-backed +created before this archive contract contain no recoverable video. The TEST007 +recorded-camera package and browser playback are physically accepted. Portable FFmpeg packaging, disk-backed browser buffering, fan-out and remote delivery also remain open. Device calibration command and sensor-to-vehicle extrinsics are unavailable. @@ -223,9 +222,9 @@ views. 4. Physically accept a newly archived left/right K1 session, then package the read-only RTSP/H.264 adapter for each target OS, add disk-backed sealed media caching and evolve same-host MSE delivery toward an authenticated Edge media - plane. Keep the modeling-command publisher disabled until operator-owned - Keychain item provisioning, physical acceptance of the reviewed uninstalled - transport and durable-save confirmation gate. + plane. Keep modeling commands limited to the installed operator-present, + exact-profile acceptance transport until durable-save confirmation is + physically accepted. Complex equipment will likely be assembled from separately useful component plugins into configured hardware packs, while standalone equipment remains diff --git a/docs/adr/0012-device-bound-k1-command-authority.md b/docs/adr/0012-device-bound-k1-command-authority.md index d1b1ff7..7f838c1 100644 --- a/docs/adr/0012-device-bound-k1-command-authority.md +++ b/docs/adr/0012-device-bound-k1-command-authority.md @@ -41,7 +41,9 @@ K1 application control is exact-profile, live-bound and fail-closed. boundaries and one continuous control MQTT session. The first ten operations are pre-START; operation 11 is START; operation 12 is a bound ModelingStatus read; operations 13–14 are the post-initialization DeviceInfo/ModelingStatus - refresh. The only preparatory mutation is time/timezone sync. No stage is + refresh. Operation 12 is response-free in both retained captures; the sole + later ModelingStatus response follows and belongs to required operation 14. + The only preparatory mutation is time/timezone sync. No stage is collapsed, skipped or automatically retried. Captured wall-clock gaps are operator/UI timing, not protocol delays. Stage progression uses explicit UI actions and live K1 state reports. @@ -55,9 +57,10 @@ K1 application control is exact-profile, live-bound and fail-closed. new operator-authorized attempt. 8. No firmware, activation, account, update or vendor-cloud mutation belongs to this path. `GetCloudServerConfig` is a local K1 read. -9. STOP completion has separate gates: correlated result, local stream - quiescence/evidence sealing, READY plus steady green, then independent native - project verification. +9. STOP completion has separate gates: correlated result, protocol-reported + unbound READY, then local stream quiescence/evidence sealing and independent + native-project verification. Stable green is useful physical corroboration, + not a second operator acknowledgement in the application lifecycle. ## Recovered START sequence @@ -85,7 +88,9 @@ captured special relation ## Current implementation boundary `application_bootstrap.py` provides DeviceInfo decoding, the exact ten-request -shadow plan and a five-batch response-barrier orchestrator. Its private retained +shadow plan and a four-window response-barrier orchestrator. The initial +DeviceInfo response binds identity; ordinals 2–6 then remain ordered in one +window so ordinal 3 does not create a barrier absent from the captures. Its private retained regression completes with 10/10 request payload/topic matches and correlated required responses. `ModelingStatusRequest` remains non-blocking exactly where the capture had no synchronous response. `application_authority.py` reads the @@ -101,11 +106,11 @@ its injected transport sink can be called. Both shadow paths remain blocked by `vendor-writes-disabled` and `publisher-not-installed`; no MQTT publisher or automatic retry path exists. -`application_execution.py` adds the dormant facade boundary. An +`application_execution.py` defines the legacy dormant shadow boundary. An operator-confirmed arm may retain authority for 15–300 seconds in a non-exportable process-memory lease and construct the shadow orchestrator. The lease and orchestrator are dropped together on expiry/disarm and also before -reprovision, acquisition preparation or shutdown. Plugin v0.4.0 exposes only +reprovision, acquisition preparation or shutdown. The prior plugin v0.4.0 exposed only shadow arm/disarm/state actions and redacted snapshots. The coordinator has no request-emission method and the installed sink is explicitly uninstalled; this runtime wiring does not widen write authority. @@ -123,15 +128,14 @@ the same operation key can never be attempted again by that transport. The acceptance executor requires a 15–120 second single-action permit backed by five explicit operator confirmations. After the failed 2026-07-18 physical -attempt proved that five response batches alone are insufficient, the collapsed -bootstrap entry point and standalone START/STOP were disabled. The uninstalled -replacement binds requests 1–6 to connection, request 7 to scan-workspace entry, +attempt exposed topic-only response routing and an invented ordinal-3 barrier, the collapsed +bootstrap entry point and standalone START/STOP were disabled. Their staged +replacement, installed in plugin v0.5.0, binds requests 1–6 to connection, request 7 to scan-workspace entry, requests 8–10 to project-prompt entry and START to a separate operator permit. There is no separate project-name mutation; the validated name is carried by START. Operations 13–14 are gated by bound `SCANNING`, project presence and `init_ready`, not by the observed 24–25-second duration. The same owner services -MQTT through explicit STOP and waits for live READY plus operator-confirmed -standby. Fault/status observations are redacted and any fault forbids automatic +MQTT through explicit STOP and waits for live unbound READY. Fault/status observations are redacted and any fault forbids automatic continuation. The socket remains serviced during operator/UI waits, and each short action permit is created at its button confirmation rather than at connection time. @@ -142,10 +146,10 @@ touch the control MQTT client. The standard UI turns one explicit launch intent into response-gated REST actions for session open (1–6), workspace entry (7), project preparation (8–10) and START. This is control compression, not protocol compression: each next action waits for the exact server/device phase, and -local polling never retries or times a K1 write. STOP and steady-green -confirmation remain separate operator actions. Preparing local reception happens before the -START event is released. After STOP, local capture remains owned until live -unbound READY and explicit visual confirmation. Page close, model switching, +local polling never retries or times a K1 write. STOP remains a separate explicit +operator action; the subsequent READY/unbound transition completes without a +second click. Preparing local reception happens before the START event is released. +After STOP, local capture remains owned until that live protocol state. Page close, model switching, polling and service state reads cannot emit START/STOP; model switching is blocked while the socket is open. Repository tests replace the transport with in-memory fakes and perform no equipment I/O. @@ -159,8 +163,8 @@ command has not been executed in this milestone. ## Promotion gate -Promotion now requires operator-present physical acceptance of the uninstalled -transport: +Promotion now requires operator-present physical acceptance of the installed, +explicitly staged transport: 1. provision the reviewed private authority into the fixed local Keychain item; 2. confirm battery/storage and select one K1 over BLE; @@ -171,7 +175,8 @@ transport: reads and observe calibration plus first point/pose/camera data; 7. send one STOP without retry and correlate its response; 8. seal local evidence while accepting the bounded stream tail; -9. wait for READY and steady green; +9. wait for protocol-reported unbound READY and record stable green as physical + corroboration; 10. verify the native project through the vendor-supported workflow. Any unknown response, identity change, fault, low battery/storage or unexpected diff --git a/docs/lab/003_K1_CONTROL_ACCEPTANCE_20260718.redacted.md b/docs/lab/003_K1_CONTROL_ACCEPTANCE_20260718.redacted.md index c30cf31..2c50bc1 100644 --- a/docs/lab/003_K1_CONTROL_ACCEPTANCE_20260718.redacted.md +++ b/docs/lab/003_K1_CONTROL_ACCEPTANCE_20260718.redacted.md @@ -2,7 +2,7 @@ - Date: 2026-07-18 - Device scope: one owner-controlled LixelKity K1, firmware `3.0.2` -- Result: **PAUSE — START acknowledgement is not lifecycle acceptance** +- Result: **GO — staged START, live acquisition, STOP and READY recovery accepted** This report contains no device identity, application authority, address, credential, raw MQTT payload or project contents. Private evidence remains in @@ -22,6 +22,12 @@ completed and five required responses arrived, but the batch-3 response did not pass exact correlation. The executor stopped before START. K1 remained READY and steady green; point/pose counts stayed zero. +Subsequent comparison with the independent fast capture proved that ordinal 3 +is not an application-response barrier: ordinals 4–6 may be published before +its response. Ordinals 3 and 6 share a response topic but use distinct unbound +and bound sessions. The repaired collector therefore routes by operation plus +session/device identity and waits for the combined ordinal 2–6 response window. + ## Attempt 2 After adding redacted live-response diagnostics, one new explicit permit was @@ -37,6 +43,65 @@ The bounded decoder maps the observed namespace/value as `0x32040000 + 307 = ALGORITHM_ERROR`. A normal operator power cycle restored steady green. No guessed STOP or repeated START was sent. +## Attempt 3 + +The production plugin UI completed BLE selection and one reviewed Wi-Fi +provisioning operation, then opened the staged control session from one explicit +operator launch intent. The MQTT owner completed six QoS2 publishes and +correlated five required responses. K1 remained in `READY`; no ModelingRequest, +START or STOP was emitted. The session failed closed on ordinal 4 +`DeviceConfigRequest`, whose correlated response carried result `0x32040002`. +Automatic and same-session retry remained disabled. + +Re-reading the original clean-cycle PCAP exposed an encoder defect rather than +a lifecycle-order failure. The captured time value is protobuf `sint64`: wire +varint `3568430060` ZigZag-decodes to Unix epoch `1784215030` (`2026-07-16 +15:17:10 UTC`). Mission Core had encoded the current positive epoch directly as +an unsigned varint. The timezone and surrounding request structure matched, but +the device therefore received the wrong timestamp semantics and rejected the +time-sync request. The encoder now applies canonical `sint64` ZigZag encoding, +with an exact captured-value regression test. A new physical attempt remains +operator-gated and requires a fresh steady-green check. + +## Attempt 4 + +After fresh provisioning and an operator-confirmed steady-green check, one +explicit plugin UI launch used the repaired staged session. All 14 canonical +requests completed on one MQTT connection: 14 QoS2 transactions, 12 correlated +application responses and the two evidence-backed optional-response cases. K1 +reported `SCANNING`, a bound project and `init_ready=true`; the live receiver +decoded point cloud and pose data and the operator saw the scene on screen. No +device system error was reported. + +The operator then issued exactly one STOP from the plugin UI. Its QoS2 and +correlated application response completed on the same control session. K1 +reported `READY`, cleared its project binding and initialization flag, stopped +the live streams, saved, blinked during finalization and returned to a stable +green indicator. No retry, fallback STOP or second device command was sent. + +The local evidence session sealed with 6,088 raw MQTT messages and 73,260,759 +payload bytes, including 2,529 point-cloud and 2,680 pose messages. The durable +manifest recorded 7,670,356 decoded points, zero decode errors, 36.029 m of +route and a 302.677 s observation interval. Background preparation produced a +107,002,392-byte digest-bound Rerun recording and admitted two recorded-camera +sources. Ranged reads of the RRD, camera manifests, MP4 initialization data and +media segments all passed their generation and content-digest checks. + +Natural RTSP closure during K1 STOP exposed a local finalization race: the +camera gateway initially classified the expected source end as an acquisition +failure before the control owner could enter its standby-confirmation phase. +The raw capture and all committed camera segments were already durable, and the +device STOP had succeeded. The gateway now marks device-STOP source termination +as expected, closes that camera generation as complete and preserves the +separate unexpected-EOF failure path. A recovery boundary also permits the +already-observed unbound READY state to retire an already-terminal local +acquisition without ever sending a second STOP. Synthetic regression coverage +exercises both paths. + +One independent product check remains outside this control acceptance: confirm +that the vendor-native project is reusable through LixelGO or USB. The +application START/STOP, local archive and offline byte-serving gates are closed. + ## Canonical-diff finding Re-audit of two independent owner-operated LixelGO START captures found the @@ -62,7 +127,11 @@ The first retained capture reached START at `+202.423 s`; the faster one at Both preserved the stage order, sent operation 12 within about one second of START, sent operations 13–14 about 24–25 seconds after START and kept the same control MQTT connection open throughout. Neither capture disconnected or -unsubscribed during initialization. +unsubscribed during initialization. Neither capture contains a response to +operation 12; each contains exactly one bound ModelingStatus response in this +interval, immediately after operation 14. The repaired correlator therefore +retires an unanswered optional operation-12 owner before admitting required +operation 14. The same re-audit shows that those wall-clock gaps are not protocol timers. Requests 1–6 follow connection, request 7 follows explicit workspace entry, @@ -83,9 +152,14 @@ The legacy collapsed `run_bootstrap()` executor now rejects before emission. The replacement acceptance-only executor uses explicit connection/workspace/ project-prompt checkpoints with no captured-delay replay. It owns operations 1–14, gates the final refresh on live K1 state, surfaces redacted system errors, -keeps the same socket serviced through explicit STOP and waits for READY plus -operator-confirmed standby. The socket is also serviced between every UI action; +keeps the same socket serviced through explicit STOP and waits for unbound +READY. The socket is also serviced between every UI action; START/STOP permits begin only at their respective confirmations. Standalone -START/STOP are rejected. This remains an -uninstalled synthetic-test-only boundary; no new physical attempt is authorized -by this implementation. Physical double-click remains the canonical fallback. +START/STOP are rejected. Plugin v0.5.0 installs the staged boundary behind +explicit operator UI actions; no state read, poll, navigation event or test may +authorize a physical attempt. Attempt 4 proved that path through live scanning, +one explicit STOP and stable-green standby. A 2026-07-19 UX review removed the +post-READY button because the live READY/unbound report already proves the state; +the explicit pre-STOP operator action remains. Physical double-click remains the +operational fallback; native-project reuse is still checked separately. The +follow-up archive/UX findings are recorded in Lab 004. diff --git a/docs/lab/004_K1_CANONICAL_CONTROL_ARCHIVE_20260719.redacted.md b/docs/lab/004_K1_CANONICAL_CONTROL_ARCHIVE_20260719.redacted.md new file mode 100644 index 0000000..00633e0 --- /dev/null +++ b/docs/lab/004_K1_CANONICAL_CONTROL_ARCHIVE_20260719.redacted.md @@ -0,0 +1,106 @@ +# Lab 004 — canonical K1 control and durable archive milestone + +- Date: 2026-07-19 +- Device scope: one owner-controlled LixelKity K1, platform `A4`, firmware `3.0.2` +- Topology: direct LAN after BLE Wi-Fi provisioning +- Result: **GO — Mission Core START/live/STOP/save and recorded replay accepted** + +This milestone contains no device identity, application authority, Wi-Fi +credential, address, raw MQTT payload, image or project contents. Private raw +evidence remains in ignored runtime storage. Lab 003 retains the failed attempts +and the exact protocol corrections that preceded this result. + +## Accepted operator path + +The operator selected the BLE-visible K1, provisioned it onto the existing LAN, +and launched one project from the plugin UI. One continuously owned MQTT 3.1.1 +session performed the staged 14-operation dialogue. Every required response was +correlated to its operation, session, device binding and authority. START was +sent exactly once with QoS 2 and retain false; automatic retry and reconnect were +disabled. K1 reached bound `SCANNING` with `init_ready=true`, and Mission Core +displayed real point-cloud and pose data. + +The operator then selected **Остановить устройство и запись** exactly once. STOP +was sent on the same control session and its response was correlated. K1 blinked +while saving, stopped its live streams, cleared the project binding, reported +`READY`, and returned to stable green. No fallback or repeated device command +was sent. TEST008 repeated the complete product path after the earlier TEST007 +acceptance and again produced a catalogued, viewable session. + +The explicit STOP click remains a safety boundary. The former post-STOP button +“Индикатор постоянно зелёный — завершить запись” was redundant: it was rendered +only after the same bound K1 had already reported `READY` with no project. The +current lifecycle therefore finalizes local receiver, camera and capture clock +automatically on that protocol evidence. Stable green remains useful physical +corroboration, not a second source of application state. + +## Durable TEST007 package + +The accepted TEST007 session contains a `107,002,392`-byte digest-bound RRD and +two recorded-camera sources. The larger camera source contains `170,457,493` +bytes across two source epochs: approximately `5.497 s` and `206.073 s`, with +`2,117` committed media segments in total (`56 + 2,061`). The second camera +source contains `5,373,206` bytes over approximately `6.695 s`. + +The browser admitted the RRD plus every declared camera as one generation. Real +frames from the large camera source were presented at shared-session positions +approximately `82.58 s` and `98.68 s`; the native player reported ready state 4 +and the expected seekable ranges. This closes the earlier transport-only camera +qualification. Historical captures created before camera archival still cannot +acquire video retroactively. + +## Archive lifecycle corrections + +The saved-session catalog now lists the complete bounded page rather than three +hard-coded rows, refreshes while the menu is open, prepares cold recordings in a +single backend worker, and exposes the ready session without a manual server +repair. Deletion uses the standard Foundry confirmation modal and removes both +the catalog entry and server evidence/cache. + +One launch lease originally remained pinned for a fixed 120 seconds after the +launch document. This caused a false “recording is open” conflict when the +operator opened TEST008, switched to another session, and immediately deleted +TEST008. The launch-to-GET lease is now consumed by the first matching RRD GET +after that response acquires its own lifetime pin. A completed transfer releases +the response pin normally; deletion may also release an unused launch lease. +An actually streaming response remains protected. Regression tests cover both +the manager pin handoff and the complete HTTP replay/open/delete sequence. + +The session header now names the active archive, for example +`Пространственная сцена: CAM_REC_TEST`. Trash controls retain a transparent +background on hover/focus instead of a red pill. An intentional canonical STOP +is presented as a neutral disconnected source rather than a source error. + +## Browser and memory finding + +The first product attempt to open TEST007 rejected its valid 170 MB camera epoch +because the frontend had a 128 MiB per-source admission cap. The reviewed caps +are now 256 MiB per camera and 512 MiB per session, still bounded before fetch. +The complete epoch then exceeded practical Media Source Extensions buffering on +this browser. Because the archive is immutable and already fully digest-verified, +the player now presents it as one fMP4 Blob while keeping bounded admission and +generation checks. This is a local browser presentation decision, not a change +to captured evidence. + +## Current supported choices + +- Connection: direct LAN is active; alternative connection modes remain disabled + UI anchors until independently accepted. +- Mount/scan carrier: handheld is active. Ground UGV and aerial UAV choices are + visible but disabled anchors. +- GNSS: no RTK is the active default. RTK is visible but disabled and optional; + unanswered optional RTK reads do not authorize guessed configuration. +- Hardware: one K1/A4/FW 3.0.2 unit is physically accepted. Live DeviceInfo still + binds vendor ID/serial dynamically so the implementation is not hard-coded to + this unit, but a second scanner and other firmware remain unaccepted. +- Camera: one live camera producer is selected at a time. A recording may contain + multiple camera sources or epochs after operator switching. +- Native vendor project reuse through LixelGO or USB remains an independent check. + +## Verification boundary + +Repository verification covers protocol correlation, no-retry safety, automatic +READY/unbound completion, expected RTSP end, archive sealing, digest/range +admission, launch-lease handoff, immediate deletion, session naming and the +absence of the redundant standby control. It does not simulate equipment I/O. +The physical claims above come only from the owner-operated TEST007/TEST008 runs. diff --git a/plugins/xgrids-k1/README.md b/plugins/xgrids-k1/README.md index 90f3f01..0e9afe6 100644 --- a/plugins/xgrids-k1/README.md +++ b/plugins/xgrids-k1/README.md @@ -34,7 +34,7 @@ The plugin owns: acquisition pipeline UI. - the interactive canonical application-control session: one socket owner, one operator launch intent, response-gated workspace/project/START stages, a - separate STOP confirmation, live status gates and no automatic retry. + separate explicit STOP action, live status gates and no automatic retry. The plugin does not own: @@ -74,11 +74,10 @@ in-process and its health is lifecycle-only; process isolation, crash/restart containment and signed deployment remain later supervisor gates. The compatibility profile is descriptive and cannot itself authorize a vendor -write. The current runtime cannot inspect K1 firmware: it keeps the profile -inactive until the operator explicitly attests firmware `3.0.2` and direct-LAN -topology, and records that basis as `operator-attested` rather than -device-derived evidence. Validate the current exact-match profile without -device I/O with: +write. The UI selects the exact firmware `3.0.2` / direct-LAN profile; the +canonical bootstrap then requires a correlated live `DeviceInfo` match for +model `LixelKity K1`, platform type `A4`, activation and firmware before START. +Validate the current exact-match profile without device I/O with: ```bash uv run python plugins/xgrids-k1/profile_loader.py @@ -92,12 +91,13 @@ START carrying the project name. Local state polling controls only when the next reviewed action may be requested; it never schedules a device command by elapsed time. START waits for bound `SCANNING + project + init_ready` before operations 13–14. STOP is separately permitted, never retried, and keeps the same socket until K1 -reports unbound READY and the operator confirms a steady green indicator. The +reports unbound READY. That protocol state automatically completes local sealing; +stable green is physical corroboration rather than a second UI gate. The admin CLI still provisions the fixed Keychain item through Apple's hidden prompt without accepting the private value as an argument. No physical command is emitted merely by loading the plugin, opening the page, navigating, polling -state or running repository tests. Full v0.5.0 physical acceptance remains an -operator-run gate. +state or running repository tests. The full v0.5.0 START/live/STOP/save path is +physically accepted on the reviewed K1/A4/FW 3.0.2 unit. The optional owner-controlled iPhone/LixelGO observation tool lives under [`lab/iphone-capture/`](lab/iphone-capture/). It pins `pymobiledevice3` in a