admin
3f4fb3825f
Capability map: the unaided-recovery row turns FAILED -> PROVEN-LIVE, scoped, with what it still does not claim stated in the row itself: shape (c) did not fire positively (with the mint guard holding there is no local key, so the offer comes from shape (a)); and 'unaided' here means possible-without-a-shell, not obvious, because two obstacles are unsignposted. OPEN-ITEMS: R-201 closed with its evidence. Five new rows R-249..R-253 (the retrieval passphrase in page HTML; the host-key scan ladder vs AAAA settle; the listing's per-tag rows; the two unsignposted restore steps). R-243 annotated rather than re-filed: on a REBUILD offsite_delivery_stuck does not skip, so the row's gap is narrower than it reads. STATUS.md: headline changed, and trimmed 97 -> 92 lines rather than extended, per its own header. Teardown recorded as OWED with its before-measurements, the stop-and-age gate, and the positive controls that must survive.
5.8 KiB
STATUS — what works, what's broken, what's next
Updated 2026-08-07.
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-07, from 258 lines. The old "what shipped recently" log 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, and so is getting the data back yourself. A machine has been destroyed on purpose and its files came back byte for byte identical — four times now, including a filename with Hungarian accents. On 2026-08-07 the household's own journey passed for the first time: someone with a browser and their recovery code got everything back with no command line inside the machine at any point. From logging in to seeing what is in the store took 72 seconds. (R-201 — closed. Two rough edges remain, below.)
What's broken
- The recovery works, but two steps are unsignposted, and one of them the machine gets wrong. After a rebuild the restore stops with "no data drive available" and never says the drives must be re-attached (R-252); then it refuses because the app is not installed — on a page that says, three lines above, that the restore will reinstall it (R-253). Both are fixable from the dashboard in a couple of minutes. Neither is something a household would work out on its own.
- The passphrase that fetches a customer's whole configuration is sitting in the page's HTML, behind a Reveal button that only hides it visually. Anything that reads the page rather than looking at it gets it, with no record that it was read. (R-249)
- 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)
- 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
- The recovery walk passed — see above. It also turned up five things: the retrieval passphrase sitting in the page HTML (R-249), a customer create that can fail on a fresh sub-account's DNS and only says "try again" by not saying anything (R-250), a recovery listing that shows the household an "app" they never installed (R-251), and the two unsignposted restore steps (R-252, R-253).
- The leftover flag that had been switching off recovery detection on one demo machine since 4 August was cleared with your approval, and the fresh machine built for the walk confirmed it cannot reach that state. Still owed: 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
- Smoothing the two rough edges the walk found, so the recovery reads as one path rather than three. (R-252, R-253)
- 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 blocking. One thing is owed by us, not you: the walk's machine (
walk5, VM 325) is still standing as the evidence and needs tearing down.
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.
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 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)