CAMPAIGN 12 — the class sweep: golden 0.208.0 baked (awaiting vouch), R-256..R-263 filed, gating ranked
gates / gates (push) Successful in 20s

Part 1. Golden 0.208.0 baked on the drill VM, published and ROUND-TRIP VERIFIED — 656 150 362 B,
sha256 ba668f59..5ffb82, and ./etc/felhom-controller-image read OUT of the downloaded archive says
felhom-controller:0.208.0. Acceptance markers all green (overlay2 x1, mount points x2 rootfs+mp0,
upload HTTP 201 x1, excluding/FATAL/mp1 x0), Result=success. Token file->file, read inside the VM;
systemctl show grep = 0; committed-log grep = 0 WITH a control proving the grep works. Bake VM
destroyed, drill disk restored to virgin. NOT VOUCHED — the campaign halts there deliberately.

golden_currency_gate.py was correctly RED on arrival and is green after the bake. No --no-verify
was needed anywhere in this session.

Parts 2-4. Seven defect classes swept for siblings by class rather than by feature. Analysis only:
no product code, nothing deployed, no machine touched beyond the bake VM.

Eight new rows R-256..R-263 (ceiling moved from R-255), grouped by class in OPEN-ITEMS.md. C1
produced no new instance and has no row. The sharpest is R-260: the agent reports
operator_key_configured every heartbeat, the hub has no field for it, so the check that answers
"can the operator get into this box" returns ok for a box with no operator key installed.

Every class states whether its method re-found the known instances, because a method that cannot
re-find them has not been shown to work: C1 2/3 (verified by replaying the pre-fix templates),
C2 2/2, C3 2/3 + 1 as fixed, C4 fix-pattern re-found, C5 re-found, C6 deadcode 0/2 and bespoke 1/2,
C7 weakest and said so. Blind spots stated per class; seven suspicions investigated and DISPROVED,
including two of my own methods.

Part 4's ranking is in ROADMAP.md as G-1..G-8. Gate C5 (cross-repo tag reachability — cheap,
--fast-eligible, would have caught every R-260 instance on the introducing commit). Do NOT gate C6:
golang.org/x/tools/cmd/deadcode was measured against a PLANTED probe and is blind to unreachable
METHODS on widely-used types, which is exactly the shape both known instances have.

R-242's untouched half is recorded, not built: this bake demonstrated it, the currency gate flipping
green the moment the evidence DIRECTORY existed, before the round trip finished and with no vouch
near it.

Correction the campaign owed its own brief: escrow_stale was described as closed; it is R-247 and
READY. The live repo is the source.

Sampled rather than swept, exactly: C7 60 of 2652 production invariant comments and NONE of the 1440
test comments (that half is owed); C2 19 of 221 refusals; C3/C4 controller only. No finding was
reproduced live. STATUS.md is 100 lines against its 93-line one screen.
This commit is contained in:
2026-08-07 23:07:42 +02:00
parent 59527d00f9
commit b7fb2117ae
7 changed files with 1038 additions and 35 deletions
+41 -35
View File
@@ -1,6 +1,6 @@
# STATUS — what works, what's broken, what's next
**Updated 2026-08-08.**
**Updated 2026-08-08 (overnight — Campaign 12).**
> **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority; this page restates
> part of it in plain words, and **nothing may exist only here**. Not `CONTEXT.md`, which is technical
@@ -24,59 +24,65 @@ time**: someone with a browser and their recovery code got everything back with
inside the machine at any point**. From logging in to seeing what is in the store took **72 seconds**.
*(R-201 — closed.)*
**And the two rough edges the walk found are gone.** After a rebuild the restore used to stop dead
twice — once because the machine no longer recognised its own drives, once because it refused to
restore an app that was not installed while promising, three lines above, that it would reinstall it.
Both now say what has happened, say that nothing is lost, and link to the one screen that fixes it.
*(R-252, R-253 — both closed 2026-08-08.)*
**And the two rough edges that walk found are gone** — after a rebuild the restore used to stop dead
twice; both refusals now say what happened, that nothing is lost, and link to the screen that fixes
it. *(R-252, R-253 — closed 2026-08-08.)*
## What's broken
- **Nothing new is broken.** The three known secret-in-page faults are all fixed; what remains is that
the *check* against a fourth covers 4 pages out of 27, and the cheap check that covers all of them is
blind to the exact shape that shipped. Filed rather than papered over. *(R-255)*
- **Nothing new is broken.** All three secret-in-page faults are fixed; what remains is that the
*check* against a fourth covers 4 pages of 27, and the cheap one covering all of them is blind to
the shape that actually shipped. *(R-255)*
- **The machine's own screen keeps telling an already-paired box to pair itself** — 25 minutes after it
was paired, on a screen that promises it refreshes itself. *(R-214, R-235)*
- **A rebuilt machine cannot create a new recovery code at all.** *(R-221)*
- **A backup that covered nothing still calls itself „Sikeres".** The state is honest; the word is not.
*(R-240)*
- **A machine waiting for its recovery code can stop making off-site backups without alarming us.**
Measured on 7 August: after a *rebuild* we ARE told, promptly and correctly. The gap is narrower than
it read — it is a machine that reaches the state without a working tier behind it. *(R-243)*
- **A machine waiting for its recovery code can stop backing up off-site without alarming us.** After
a *rebuild* we ARE told; the gap is a box reaching that state with no working tier behind it. *(R-243)*
- **The card offering to reopen set-aside backups promises more than we can deliver** — we keep the old
sealed package, but nothing can open it. *(R-202)*
- **Deleting a customer leaves rows behind** on every test machine ever torn down, while reporting a
clean teardown. No secrets involved, but it accumulates with each walk. *(R-244)*
- **Putting restored files back where they belong is still a manual step.** *(R-213)*
## Found today
## Found overnight — we went looking for siblings, on purpose
- **The last two passwords are out of the page source**, the same way as yesterday's: the page carries
only a yes/no, and the value is fetched when you ask for it — and the asking is now recorded, which
it never was. One of them was an app's own first-login password, read live out of the running app.
*(R-254, both sites fixed.)*
- **How much was actually exposed: nothing we can find.** The only app that generates a first-login
password isn't installed anywhere, and of the three apps actually running on the demo machine, none
uses a generated secret. **But nothing recorded reads** — that was part of the fault — so this is
"no evidence of exposure", not "proof there was none". No passwords need changing on that basis;
the call is yours.
- **One of the two turned out not to be a fault.** The deploy form's hidden password field is
deliberate: a form must submit what it saves, so the value you wrote down is the one stored.
Every fault this month came in one of seven shapes; overnight we looked for the others **by shape**
reading and counting only, nothing changed or deployed, no machine touched. Eight new items, none
urgent. Full working: `audits/CAMPAIGN-12-class-sweep-2026-08-08.md`.
- **The one that matters.** The machine tells us whether your engineer's emergency key is really
installed — and **we throw that sentence away before reading it**, so a box can read as "we can get
in" when nobody can. Same shape in seven other places. *(R-260)*
- **A green tick meaning only "a backup exists"** — any age counts, and it reddens on a problem
measured across all apps rather than that one. *(R-258)*
- **A disk we failed to measure is drawn as an empty, healthy one** — "0.0 GB / 0.0 GB (0%)" in the
normal colour, while the right pattern sits two files away. *(R-259)*
- **Two comments promise more than the code does** (one guarded by a test that cannot fail on the
thing it names), and **two refusals still stop at "no"**, one in half-English.
*(R-262, R-263, R-256, R-257)*
- **Which shapes can a machine catch from now on?** That mattered more than the list: **one is cheap
and worth doing** (the thrown-away-sentence one, which would have caught every instance on the day
it was written), two need a small decision first, and **two are honestly not automatable**
including the one that looked most automatable, where the standard tool was tested and found blind.
Recorded, not built. *(ROADMAP G-1…G-8)*
## What we're working on
- **Widening the check** so a fourth secret-in-a-page is caught by a machine rather than by
someone looking. *(R-255)*
- **Proving the hub really keeps the old sealed key** when a machine re-seals. Never run outside a
test; needs a second deliberate wipe and its own session. *(R-198)*
- **Widening the check** so a fourth secret-in-a-page is caught by a machine, not by someone. *(R-255)*
- **Proving the hub really keeps the old sealed key** when a machine re-seals — needs its own session
and a second deliberate wipe. *(R-198)*
## Waiting on you
- **Nothing blocking.** Today's release needs a new base image before installations receive it — same
as yesterday, same answer: it is ours to do, not yours. *(R-242)*
*R-245 — whether an undecided household is auto-abandoned after 30 days — was settled on 7 August: we
do not build it, and the reasoning is recorded.*
- **One approval: the new base image.** Tonight's release is baked, published and byte-checked, and
**installations still receive yesterday's version until you press Save.** Hub → Configuration →
Day-0 artifacts → Golden **0.208.0** → Save. One field moves; the other two are already right and
were checked. Reversible — re-select 0.207.0 and Save. *(R-242)*
- **Third time in three days, so worth a minute.** A check now catches the *baking* being forgotten;
**nothing catches the approval being forgotten** — tonight's bake proved it, going green before the
approval existed. Two ways to close it are written up, neither built. *(ROADMAP G-8)*
## DooPlex infrastructure — separate from the product
@@ -90,5 +96,5 @@ being readable.*
anyone else saw it. *(R-132)*
- **One thing to read after DooPlex next restarts** — the second-SSD move has never survived a reboot;
it writes PASS/FAIL to `/var/log/felhom-store-postboot-check.log`. On PASS, 34 GB comes back. *(R-209a)*
- **Backup scripts on DooPlex are unversioned host state.** *(R-231)*
- **Instruction-file follow-ups**, each needing a decision rather than an edit. *(R-229, R-230)*
- **Backup scripts on DooPlex are unversioned host state** *(R-231)*, and the instruction-file
follow-ups each need a decision rather than an edit *(R-229, R-230)*.