docs(k1): record connection mode acceptance

README.md

@@ -130,7 +130,8 @@ uv run k1link serve
 Open `http://127.0.0.1:8000`. The static application, REST/WebSocket control
 plane and credential endpoint bind to loopback only. The current K1 adapter
 still provides real CoreBluetooth discovery, one operator-triggered reviewed
-BLE Wi-Fi provisioning write, read-only MQTT live capture, native `.k1mqtt` and
+BLE Wi-Fi provisioning write, a one-shot CoreWLAN K1-AP association path,
+read-only MQTT live capture, native `.k1mqtt` and
 reviewed-TSV replay, raw-first evidence storage, device-reported scan
 time/distance/speed and measured preview metrics. Its frontend contribution now
 also owns an optional spatial-scene control block, including acquisition phase,
@@ -138,6 +139,15 @@ telemetry and the stop action. Operator-manual acquisition still finalizes only
 local reception; plugin-commanded v0.5.0 acquisition uses the separately gated
 canonical K1 START/STOP dialogue.
 
+Plugin v0.6.0 makes the local connection direction explicit. Bridge remains the
+default; Direct Connect sends the same reviewed BLE frame with credentials for
+an already-running controller hotspot; Quick Connect sends no BLE write and
+instead associates this Mac with the K1 AP once. Each mode has a distinct
+topology attestation and no automatic retry. The Bridge path is physically
+accepted. Direct Connect and the Mission Core Quick Connect host adapter are
+implemented and offline-verified but still require their own owner-operated
+physical acceptance cycles; see [ADR 0013](docs/adr/0013-k1-local-connection-matrix.md).
+
 The exact recovered `ModelingRequest` start/stop encoder, response correlator
 and device-status state machine are installed in the operator-gated interactive
 control path.