admin
b7fb2117ae
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.
3.8 KiB
REPORT — Campaign 12, the class sweep (2026-08-08, unattended)
A non-overwritten REPORT-<topic>.md sibling, per CLAUDE.md:82-87 — a parallel session shares this
clone and the shared REPORT.md was not touched.
What ran
Part 1 — the bake. 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. All acceptance markers green, Result=success,
bake VM destroyed and the drill disk restored to virgin. Token never on a command line (grep -c =
0 on the committed log, with a control proving the grep works). NOT VOUCHED — that is the one
thing awaiting the operator. Evidence: documentation/tests/golden-0.208.0-2026-08-08/.
Parts 2–4 — the sweep. Seven defect classes swept for siblings, analysis only. Report:
documentation/audits/CAMPAIGN-12-class-sweep-2026-08-08.md.
Result
Eight new register rows, R-256 … R-263 (highest ID moved from R-255), grouped by class in
backlog/OPEN-ITEMS.md. C1 produced no new instance and has no row.
The sharpest finding is R-260: the agent reports operator_key_configured on every heartbeat and
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. Seven more dropped fields are censused with it.
Part 4's ranking is the campaign's most valuable output and lives in backlog/ROADMAP.md as
G-1 … G-8. The recommendation: gate C5 (a cross-repo tag-reachability check — cheap,
--fast-eligible, and it would have caught every instance in R-260's census on the commit that
introduced them), and do not gate C6, because the standard tool was measured against a planted
probe and found blind to the exact shape both known instances have.
Controls — every class states whether its method re-found the known instances
| class | control |
|---|---|
| C1 | shipped gate 2 of 3, verified by replaying the pre-fix templates from 8dbbc98^ |
| C2 | 2 of 2, re-found as fixed |
| C3 | 2 of 3 re-found, 1 as fixed — and swept COMPLETELY (all 9 sites) |
| C4 | fix pattern (R-225 StatsKnown) re-found intact |
| C5 | re-found — and a correction owed: the task called escrow_stale closed; it is R-247, READY |
| C6 | deadcode 0 of 2 (blind spot measured with a planted probe); bespoke method 1 of 2 |
| C7 | weakest — the nine known are closed, so the sample re-finds the pattern, not the instances |
Honest limits
- C7 sampled 60 of 2652 production invariant comments and none of the 1440 test comments. The task asked explicitly for the tests' own claims; that half is owed, not done.
- C2 sampled 19 of 221 refusal strings.
- C3 and C4 covered the controller only — not the hub, not the agent.
- No finding was reproduced on a live box. Source reading only, as §6 rule 2 requires. R-258 and R-259 are the two most worth confirming live before they are fixed.
- Seven suspicions were investigated and DISPROVED, including two of my own methods; §6 of the report names each.
STATUS.mdis 100 lines, 7 over its 93-line "one screen". The overflow is the campaign's own entry plus the operator approval; the eight findings themselves are in the register, as required.- This session did not run inside
tmux, contrary to the workspaceCLAUDE.md.
Gates and hygiene
python3 scripts/repo_gates.py --fast → all 7 gates OK, including golden-currency, which was
correctly RED on arrival and is green after the bake. No --no-verify was used anywhere — the
bypass the task authorised was not needed.
No product code changed. Nothing was deployed beyond the golden. No machine was touched beyond the bake VM, which was torn down.