admin
7850469d5b
VOUCHED with the operator's approval, verified from the stored hub_settings rather than the flash: golden_version 0.205.0 -> 0.206.0, sha c85230b42f53baa9c1ee9986ac312c751d6cbc29fbe070d87bb2214429a9108e. agent_version and min_agent both stayed 0.127.0. wrapper_sha256 was carried through explicitly, because the handler CLEARS it when omitted. THE GATE WAS CONVICTED BEFORE THE BAKE AND IS OK AFTER IT - red to green on the same command, which is its proof that it measures something real. It went green on the BAKE, not the vouch; that limitation is stated in its docstring and stays open on R-242. THE STALE FLAG WAS WRONG AND IS CLEARED, with the operator's approval. One row, identity-matched on host_id and guarded on stale_at IS NOT NULL; changes() returned 1. Verified end to end, not just in the database: the hub serves the hash again, the box recorded it at 11:10:19Z, and it is byte-identical to the key that box is using - so shape (c) compares, matches and correctly stays silent. The false warning is gone, PROVEN WITH A POSITIVE CONTROL rather than an absent line: 0 escrow-confirm lines since the restart while 5 scheduler lines in the same window prove the box was logging. R-246 records the clearance and keeps the column ruling open: stale_at has NO production writer, changes what a customer is told, and can be seen by nobody who would look for it. Either give it an evidential setter or retire it. STATUS.md finished at 87 lines (from 258). Waiting-on-you is now genuinely empty: the base image is approved and live, and R-245 was re-filed as a decision taken with quota as its reopening condition. Session report: REPORT-clear-the-ground-2026-08-08.md - the six spike questions each answered with method and measurement, Q4 said plainly (only a database read), Q6 said loudly (a fresh box CANNOT reach this state, so the next walk cannot meet it), and three observations noticed but not acted on.
5.4 KiB
STATUS — what works, what's broken, what's next
Updated 2026-08-08.
A view, not a source.
documentation/backlog/OPEN-ITEMS.mdis the authority; this page restates part of it in plain words, and nothing may exist only here. NotCONTEXT.md, which is technical state written for Claude Code. Items, not paragraphs. One screen. If it does not fit, something belongs in the register instead.Rebuilt from the register on 2026-08-08. It had reached 258 lines; its "waiting on you" list asked for two things already shipped and carried a stray line reading only "Nothing."; and it mixed the DooPlex infrastructure work in with the product. The old "what shipped recently" log — 100 lines of it — is what the per-repo
CHANGELOG.mdfiles and the register are for, and is not restated here.
What works
A blank machine boots the Felhom disc, installs itself unattended, and is claimed by the customer, who sets their own password. They install apps from a catalogue of fifty-three, share files over the home network, and open apps from a launcher or a shared link. Backups run on their own to three places — the machine's drive, a second drive, and an encrypted off-site copy.
The backup promise is proved. A machine has been destroyed on purpose and its files came back byte for byte identical — three separate times, including a filename with Hungarian accents.
What's broken
- A household still cannot get their own data back unaided. Every individual link now works; no single walk has completed end to end without someone stepping in. (R-201)
- 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 raises no alarm to us. It quietly stops making off-site backups, and three separate safety nets each correctly decide it is not their business. The household can see it; we cannot. (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
- A leftover flag had been silently switching off the new recovery detection on one demo machine since 4 August — found, and cleared with your approval. A Re-issue during the recovery drill set it, using code we removed the next day. The flag is wrong — the sealed package does cover the key that machine is using, and the two fingerprints match exactly. Because of it the hub withholds a figure the machine needs, so the machine tells its owner "create a new recovery code" — the one act that would put their old backups beyond reach. A freshly installed machine cannot reach this state, because nothing has set that flag since 5 August. Cleared the same day; the machine now compares its key correctly again. What is still owed is a ruling on the flag itself: nothing sets it, nothing can see it, and it changes what a household is told. (R-246, R-247, R-248)
What we're working on
- The walk that either finishes the arc or says why not. It needs the base image current (done today) and a machine whose recovery detection is not silently switched off (answered today). (R-201)
- 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)
Waiting on you
- Nothing. The new base image was approved and is live — every future installation now carries this week's fixes. (R-239, R-242)
Nothing else is pending. 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). It has been re-filed as a decision taken rather than a question sitting in your queue.
DooPlex infrastructure — separate from the product
Kept under its own heading rather than dropped: these are real asks that need you, but they concern the machine all this is built on, not what a customer receives. Mixing them in is why the page stopped being readable.
- DooPlex's own backup makes every copy inside the same box, and nothing says when it fails. (R-232)
- 193 old images exist only on this machine and cannot be re-downloaded. About 27 GB against 199 GB free — clutter, not space. Nothing deleted. (R-210)
- The hub password needs rotating — a diagnostic printed it into a session log; nothing suggests anyone else saw it. (R-132)
- One thing to read after DooPlex next restarts. The move to the second SSD has never been through
a reboot; it now writes PASS or FAIL to
/var/log/felhom-store-postboot-check.logon every start. 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)