docs(milestone): record K1 control and archive acceptance

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