docs(milestone): record K1 control and archive acceptance

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
+filesystem path. The physically accepted interactive control path carries the
-does not claim that this value has been transmitted to the scanner.
+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
+The application-control bootstrap reads and correlates live `DeviceInfo` before
-profile inactive until the operator explicitly attests firmware `3.0.2` and
+START. The exact profile requires model `LixelKity K1`, observed platform type
-direct-LAN topology; state records that basis as `operator-attested`, not as
+`A4`, activated state, firmware `3.0.2`, and direct-LAN topology. The UI selects
-device-derived evidence.
+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
+Plugin v0.5.0 wires this executor to the facade and plugin UI. The full staged
-acceptance remains an operator-run gate.
+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
+confirmation. The interactive application-control publisher is enabled only for
-double-click is the verified start/stop mechanism. Any future MQTT publisher,
+the exact K1/A4/FW 3.0.2 direct-LAN profile and only inside one operator-opened,
-router configuration change or new BLE write requires its own evidence and
+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.
 

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
+encoder, response correlator and device-status state machine now run in the
-publisher. Retained PCAP plus client static analysis prove that OpenAPI is one
+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:
+10 observed pre-START requests byte-for-byte across four response windows and
-initial DeviceInfo binding; ModelingStatus plus RTK read; time sync plus
+five observed publish groups: initial DeviceInfo binding; then the ordered
-DeviceInfo/RTK; NTRIP read; then cloud/RTK/DeviceInfo reads. The first
+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
+identity/profile drift. The legacy shadow publisher remains a separate
-write-disabled type that cannot call its injected sink. A dormant coordinator
+write-disabled type that cannot call its injected sink. Its dormant coordinator
-is now wired into the XGRIDS facade and plugin manifest. Explicit operator arm
+is wired into the XGRIDS facade only for redacted planning/state. Separately,
-loads the Keychain value into a bounded 15–300 second process-memory lease;
+plugin v0.5.0 installs the reviewed physical-acceptance transport behind explicit
-expiry, disarm, reprovision, acquisition preparation and shutdown drop both the
+operator actions and one continuous background session owner. Each operation
-lease and orchestrator. Public state contains only lease timing/booleans. There
+key is consumed before publish, automatic reconnect and application retry are
-is deliberately no batch-emission method, live MQTT sink or UI button in the
+forbidden, and any unknown outcome poisons the transport. Public state contains
-installed runtime. A separate physical-acceptance-only transport and dialogue
+only bounded lifecycle, counter and failure metadata; authority and device
-executor now implement the reviewed MQTT exchange without facade/UI wiring.
+identity remain private.
-Each operation key is consumed before publish, automatic reconnect and
-application retry are forbidden, and any unknown outcome poisons the transport.
 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
+required responses through the old third window, but topic-only routing
-`ApplicationBootstrapError` while correlating that batch. No START was emitted;
+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
+ownership waits for live unbound `READY`. System-error
-and status reports are decoded into redacted safety state. This path is not
+and status reports are decoded into redacted safety state. The next staged
-wired into the plugin runtime/UI and has only synthetic regression coverage;
+physical attempt, after correcting the protobuf `sint64` time field, completed
-physical STOP/save remains untested and the button is the safe fallback.
+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
+control is plugin-owned. A plugin-commanded acquisition sends one canonical STOP
-local reception only and never claims to stop the scanner.
+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
+- browser-visible end-to-end shared-timeline playback of the accepted archive
-  containing point cloud plus one selected K1 camera;
+  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
+  regression and runtime ownership integration;
-  permitted operator-present START/STOP attempt, and stable-artifact proof after
-  STOP;
 - long-running large-session WebViewer/WASM memory telemetry;
 - production retention, replication, encryption and cross-platform packaging.

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
+The first ten requests contain five observed publish groups but only four
-not the whole application lifecycle. Two independent owner-operated START
+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
+treated as mandatory synchronous responses. In both retained captures operation
-DeviceStatus plus point/pose observation.
+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
+A separate operator-driven physical-acceptance implementation is installed in
-facade/runtime. Retained-PCAP re-audit fixes its MQTT contract at 3.1.1,
+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;
+confirmations. START additionally requires the complete four-window bootstrap;
-STOP requires its own separate permit. This code is not installed as a plugin
+STOP requires its own separate permit. No plugin state read, poll, navigation or
-action. On 2026-07-18 its first operator-present physical attempt made one
+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
+and five required responses were collected, but the old topic-only collector
-response in batch 3. The executor stopped before building or publishing START;
+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
+explicit STOP request and afterwards until live unbound `READY`. That device
-standby. System-error and DeviceStatus reports are decoded into redacted safety
+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
+retained clean-cycle now completes all nine bootstrap barriers offline while
-the open issue is a live batch-3 response divergence. The complete stop/save
+ordinals 3 and 6 are simultaneously in flight and routes them by exact
-sequence has not physically proved a durable vendor project. A
+session/device identity. After repairing the PCAP-proven protobuf `sint64` time
-correlated STOP success, stream quiescence, return to
+field, the next operator-run physical cycle completed all 14 canonical requests
-`READY`/steady-green hardware state and appearance of a reusable native project
+on one socket, reached `SCANNING + project + init_ready`, delivered real
-are separate gates. The verified physical double-click remains the acquisition
+point/pose data and completed one correlated STOP. Streams quiesced, K1 returned
-control until a separately reviewed one-shot write gate closes.
+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
 

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
+    waits for live unbound READY, then finalizes capture, camera archive and
-    green indicator before capture, camera archive and summaries are finalized.
+    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
+- Physical double-click remains the independently verified device-local fallback.
-  promotion needs reviewed Keychain item provisioning, operator-present use of
+  Mission Core also contains the installed response-gated operator-present
-  the uninstalled response-gated transport and durable-save proof.
+  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

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
+Unknown or mismatched firmware fails closed. The UI selects the profile and the
-firmware from the device: it activates this limited, read-only profile only
+canonical bootstrap verifies model, platform type, activation and firmware from
-after explicit operator attestation of firmware `3.0.2` and direct-LAN topology,
+a correlated live `DeviceInfo` before START. The profile independently records observation, decode, replay,
-and records the basis as `operator-attested`. That claim is not device-derived
-proof. 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
+fixed Keychain loader and dormant shadow coordinator remain present. The staged
-physical proof after STOP remains unresolved; write capability is exposed only
+physical START/live/STOP/unbound-READY cycle is accepted on the reviewed unit;
-while that interactive socket owner is active.
+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
+data. Plugin-commanded STOP finalizes automatically after the same bound control
-stop reports the K1 physical state as unknown.
+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
+session/catalog display metadata. It is not a path component. The accepted
-publishing is off, the current integration does not claim that the name reaches
+interactive START carries this exact validated value to K1.
-K1.
 
 The K1 contribution may mount a `SpatialControlsView` beside the host-owned
-viewport. It presents plugin lifecycle wording, the local stop action and live
+viewport. It presents plugin lifecycle wording, the stop action and live
-`ModelingReport` scan time, route distance and speed. Under the current
+`ModelingReport` scan time, route distance and speed. In plugin-commanded mode
-capture-only profile the stop action seals local reception; it does not claim a
+the stop action sends the canonical device STOP; in operator-manual mode it
-device stop. `ModelingReport` is consumed before the visual preview queue through
+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
+v1alpha1/UI compatibility. On the exact accepted profile, a plugin-commanded
-receiver and operator workflow only. K1 scanning is still started and stopped
+acquisition owns canonical START and STOP plus local reception. Physical
-by physical double-click; no modeling request is published.
+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
+created before this archive contract contain no recoverable video. The TEST007
-recorded-camera acceptance remains open. Portable FFmpeg packaging, disk-backed
+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
+   plane. Keep modeling commands limited to the installed operator-present,
-   Keychain item provisioning, physical acceptance of the reviewed uninstalled
+   exact-profile acceptance transport until durable-save confirmation is
-   transport and durable-save confirmation gate.
+   physically accepted.
 
 Complex equipment will likely be assembled from separately useful component
 plugins into configured hardware packs, while standalone equipment remains

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
+9. STOP completion has separate gates: correlated result, protocol-reported
-   quiescence/evidence sealing, READY plus steady green, then independent native
+   unbound READY, then local stream quiescence/evidence sealing and independent
-   project verification.
+   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
+attempt exposed topic-only response routing and an invented ordinal-3 barrier, the collapsed
-bootstrap entry point and standalone START/STOP were disabled. The uninstalled
+bootstrap entry point and standalone START/STOP were disabled. Their staged
-replacement binds requests 1–6 to connection, request 7 to scan-workspace entry,
+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
+MQTT through explicit STOP and waits for live unbound READY. Fault/status observations are redacted and any fault forbids automatic
-standby. 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
+local polling never retries or times a K1 write. STOP remains a separate explicit
-confirmation remain separate operator actions. Preparing local reception happens before the
+operator action; the subsequent READY/unbound transition completes without a
-START event is released. After STOP, local capture remains owned until live
+second click. Preparing local reception happens before the START event is released.
-unbound READY and explicit visual confirmation. Page close, model switching,
+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
+Promotion now requires operator-present physical acceptance of the installed,
-transport:
+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

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
+keeps the same socket serviced through explicit STOP and waits for unbound
-operator-confirmed standby. The socket is also serviced between every UI action;
+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
+START/STOP are rejected. Plugin v0.5.0 installs the staged boundary behind
-uninstalled synthetic-test-only boundary; no new physical attempt is authorized
+explicit operator UI actions; no state read, poll, navigation event or test may
-by this implementation. Physical double-click remains the canonical fallback.
+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.

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.

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
+write. The UI selects the exact firmware `3.0.2` / direct-LAN profile; the
-inactive until the operator explicitly attests firmware `3.0.2` and direct-LAN
+canonical bootstrap then requires a correlated live `DeviceInfo` match for
-topology, and records that basis as `operator-attested` rather than
+model `LixelKity K1`, platform type `A4`, activation and firmware before START.
-device-derived evidence. Validate the current exact-match profile without
+Validate the current exact-match profile without device I/O with:
-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
+state or running repository tests. The full v0.5.0 START/live/STOP/save path is
-operator-run gate.
+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