docs: R-157 A / R-170 / R-171 closed — boot recovery finished
gates / gates (push) Successful in 7s

Controller v0.190.0. Docs only here; no hub change, no hub version bump.

- audits/DIAG-bootrecon-drive-absent-2026-08-02.md — NEW. The Part 0 diagnosis,
  including the run that produced a FALSE NEGATIVE and the mechanism behind it
  (the agent re-binds an unmounted drive within ~60s, so the drive gate's startup
  reconcile restarted the apps one second before the sweep looked). Records that
  the write hazard was blocked only by an ACCIDENTAL filesystem permission that no
  code owns and no test pins.
- architecture/02 §0a — the boot-recovery contract (S-1): both gates read desired
  state; the sweep observes a SETTLED fleet and each sample must refresh first;
  nothing is started without asking, fail-safe. Plus the durable warning:
  Manager.StartStack has no gate of its own.
- 00-capability-map — the boot-recovery row, with the repeat count cited per N.5
  (6 of 6 hard resets) rather than a bare PROVEN-LIVE.
- OPEN-ITEMS / ROADMAP — R-157 CLOSED (both mechanisms), R-170 CLOSED, R-171 NEW
  and closed the same session, marked a regression from v0.189.0.
- STATUS.md — the power-cut line moved from "What's broken" to "What works right
  now" with its repeat count; one dated bullet in the change log.
- CONTEXT.md S-13 — the lessons worth carrying: "it didn't happen this time" is
  not a disproof; widening a window makes previously-unreachable overlaps
  reachable; and a settle detector is only as good as the freshness of what it
  samples — the fix's own defect, found live rather than by review.
This commit is contained in:
2026-08-02 20:38:21 +02:00
parent 5c97fbc397
commit ad28699761
7 changed files with 247 additions and 16 deletions
+14 -8
View File
@@ -16,15 +16,12 @@ home network, and open apps from a launcher or a shared link. Backups run on the
places — the machine's drive, a second drive, and an encrypted off-site copy — and a customer can
restore files and app data from the drive alone. Proven end to end on real hardware.
## What's broken
**Apps come back after a power cut.** The machine tells an app the customer switched off from one
that simply did not come back, and waits for the system to finish starting before deciding instead of
glancing once, five seconds in. Hard-reset the demo box six times in a row: everything came back every
time, and an app switched off deliberately stayed off every time.
**After a power cut, an app can stay switched off — and the machine may look too early to notice.**
It now knows the difference between an app the customer switched off and one that simply didn't come
back: the customer's choice is written down, so an app meant to be running is started again however
it went missing. What is left is timing — it looks about five seconds after starting, while the
system is still coming up, and never looks again. *(R-157; the "decided the customer switched it off"
half is fixed — R-166, 2026-08-02. The same guess still lives in one other place, for apps kept on a
plug-in drive — R-170.)*
## What's broken
**The off-site copy can be erased by the machine that made it** — the credential that writes it can
also delete it. A daily snapshot is armed as a stopgap, and we have never restored from that copy.
@@ -69,6 +66,15 @@ It notices, quickly, and tells you. *(R-29, R-161, R-168, R-169)*
## Changed since last update
- **2026-08-02** — Boot recovery finished. Both halves of the power-cut problem are closed: the
machine records what the customer asked for, and it now waits for the system to finish starting
before deciding what is missing. Six hard resets in a row, everything back every time. A hole the
previous day's change had opened — the machine would have tried to start an app whose external
drive was missing — was found by reading the code, reproduced on the demo box **before** anything
was changed, and fixed the same day. No data ever reached the wrong disk, but only because of a
filesystem accident nothing was relying on deliberately, which is why it was fixed rather than
noted.
- **2026-08-02** — Fixed and then doubled: thirteen mechanical checks had built up across the four
repositories and nothing ran most of them; two were failing quietly, one since 14 July. Both fixed.
Every repository now has one command that runs all its checks, it runs automatically before every