fix(k1): record redacted acceptance failures

docs/01_IMPLEMENTATION_PLAN.md

@@ -21,7 +21,7 @@ Each gate produces evidence and an explicit GO, PAUSE or BLOCKED result.
 | 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 |
 | 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 | PAUSE (physical-acceptance software gate complete) — plugin v0.4.0 runtime remains dormant/write-disabled; a separate uninstalled transport now enforces the retained MQTT session, exact response subscriptions, QoS2 one-shot operation keys, five response-gated batches and poison-on-unknown behavior; Keychain provisioning and physical START/STOP remain unexecuted |
+| K1 application control | PAUSE (first physical bootstrap failed closed before START) — plugin v0.4.0 runtime remains dormant/write-disabled; the uninstalled acceptance transport completed one connection, six QoS2 bootstrap publishes and five correlated responses, then rejected one live batch-3 response; K1 remained READY, START was not emitted, retry is forbidden and the temporary Keychain item was deleted |
 | 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
@@ -53,8 +53,15 @@ 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. The command has not
-been run. Physical START/STOP remain untested; the button is the safe fallback.
+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;
+live DeviceStatus stayed READY and the local point/pose counts remained zero.
+The local capture was sealed and the temporary Keychain item was deleted.
+Physical START/STOP therefore remain untested; the button is the safe fallback.
 
 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;
@@ -273,7 +280,8 @@ useful stream is decoded or structurally identified.
 - 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;
-- operator-owned Keychain item provisioning, operator-present physical use of
-  the reviewed acceptance transport and stable-artifact proof after STOP;
+- OS-independent plugin/edge authority provider, redacted live-response
+  diagnostics for bootstrap batch 3, a newly permitted operator-present full
+  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

@@ -225,13 +225,25 @@ post-publish outcome. A 15–120 second permit requires explicit operator-presen
 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 and has never emitted to the K1.
+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;
+K1 remained `READY`, project binding stayed absent and point/pose remained zero.
+No automatic retry was attempted.
 
 The one-time Keychain administration command uses `security -w` as the final
 argument so Apple's own TTY prompt receives the authority. Mission Core never
 accepts it through CLI argv and validates the resulting fixed item through the
-production loader. The command has not yet been run. The complete
-stop/save sequence has not physically proved a durable vendor project. A
+production loader. The macOS CLI approval path timed out during the first lab
+attempt; a temporary Security.framework-backed item was used only inside the
+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