docs(milestone): record K1 control and archive acceptance

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.

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.