docs(milestone): record K1 control and archive acceptance

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.