SILVER/NODEDC_MISSION_CORE
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

fix(k1): settle same-process standby checkpoint

Browse Source
This commit is contained in:
DCCONSTRUCTIONS
2026-08-14 21:32:26 +03:00
parent 986ea69610
commit 321cde70e8
4 changed files with 134 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/runbooks/K1_OPERATOR_FLOW_INCREMENTAL_ACCEPTANCE.md
+79
View File
@@ -0,0 +1,79 @@
# K1 operator flow: incremental acceptance
Status: working acceptance ledger, 2026-08-14.
This is the short regression anchor for changes to the existing K1 operator
flow. The authoritative connection and safety model remains
[`../20_K1_CONNECTION_SUPERVISION_CANON.md`](../20_K1_CONNECTION_SUPERVISION_CANON.md).
Every K1 fix must name one row below, add a reducer test, and preserve all
previously accepted rows. No change in this ledger authorizes a new K1 command.
## Non-negotiable device boundary
- START and STOP keep the captured vendor payload, topic, QoS and one-shot
dispatch contract. No automatic replay, substitute command or inferred ACK.
- Reconnect and Verify are read-only. Scenario reset changes local Mission Core
state only; it sends no BLE, Wi-Fi, START or STOP operation.
- `READY` / `SCAN_OVER` from a fresh, identity-bound, non-retained status is
physical standby truth. Local recovery state must converge to that fact
before a new START can be admitted.
- An unknown command outcome is never presented as success. A later exact
read-only reconciliation may settle it, but may not rewrite its audit history.
## Operator-state contract
| State | Stable operator surface | Required feedback | Accepted exit | Forbidden |
| --- | --- | --- | --- | --- |
| Saved connection needs checking | Saved K1 card plus `Переподключиться` and `Подключить новый K1` | None before action | One explicit action | Hidden Scan, Verify or reconnect |
| Reconnect in progress | The same saved K1 card and same button geometry | Disabled action with canonical `ActivityIndicator`; neutral copy `Переподключение` | Connected or an actionable terminal result | Replacing the whole panel, blank wait state, first-person copy |
| Bluetooth search | The same connection step | Visible activity and search phase | Results or terminal no-result state | Empty disabled panel with no progress |
| Device selected | Selected-device card and network fields | None while editing | One explicit Apply or choose another device | Background provisioning or hidden second discovery |
| Apply in progress | The same selected-device/network form | Disabled Apply with canonical `ActivityIndicator` and named phase | `network_applied`, or a truthful terminal failure | Container-size jumps, screen substitution, automatic Apply replay |
| Network applied, control checking | Connection card remains visible | Passive `Подтверждение управления` activity | Control ready or explicit recovery choice | Calling the provisioning result a network failure |
| Ready to start | Project form | No activity | One explicit START | Green readiness without exact control authority |
| START in progress | The same project form | Disabled START with named phase | Active acquisition or truthful terminal state | Second START, unexplained switch to viewer |
| Active acquisition | Spatial viewer and one stable STOP action | Stream/visualizer status separately | One explicit STOP | STOP enabled/disabled oscillation before click |
| STOP in progress | Same viewer and same STOP position | Disabled STOP with named phase | Physical standby or explicit outcome-unknown recovery | Second STOP or button disappearance |
| Physical standby | Clean local idle/new-session state | None | Reconnect or new acquisition | Active recovery checkpoint blocking a proven `READY` |
## Presentation invariants
- Any operator-owned operation lasting longer than one rendered frame has an
`ActivityIndicator`, visible neutral process noun, `aria-busy`, and a stable
action/container position.
- Pending copy describes the process, not the application or operator:
`Переподключение`, `Поиск устройства`, `Подтверждение управления`,
`Подготовка приёма`, `Остановка записи`.
- One action never flashes an unrelated complete screen between its pending and
terminal states.
- Wi-Fi mutation, control bootstrap, physical command and visualization are
separate facts. Failure of a later fact must not relabel an earlier success.
- If decoded PCL frames exist but the browser has not admitted the exact Rerun
store, the viewer remains `Подключение визуального источника` and must become
an actionable visualization error at its deadline. It must not show
`Визуализатор готов` over an empty scene.
## Increment gate
For each patch, record four facts in the handoff:
1. **Fix** — one named broken transition.
2. **Reducer** — the smallest offline sequence that failed before the patch.
3. **Visual acceptance** — exactly what the operator should see.
4. **Not accepted yet** — adjacent known violations that remain out of scope.
Current violations observed on 2026-08-14:
- `K1-P0-CHECKPOINT`: fresh standby reconciliation left an ACTIVE recovery
checkpoint and blocked the next connection. Code fix and same-process/restart
reducers are green. Live startup convergence accepted: checkpoint revision 16
is `ceased`, physical head remains `physical-standby-observed`, and the public
policy again admits Scan plus read-only configured-device observation.
- `K1-P0-RERUN-ADMISSION`: backend decoded and published PCL, but the browser
never admitted the active Rerun store; camera/counters were visible over an
empty point scene. Not fixed in the checkpoint increment.
- `K1-P1-STOP-STABILITY`: STOP authority visibly oscillated before the operator
clicked. Not fixed in the checkpoint increment.
- `K1-P1-PENDING-FEEDBACK`: reconnect/search/select/provision transitions replace
panels or show disabled controls without an activity indicator. Not fixed in
the checkpoint increment.