felhom.eu/STATUS.md

STATUS — what works, what's broken, what's next

Updated 2026-08-08.

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 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.md files 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.)

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.)

What's broken

• An app's own first-login password is still sitting in a page's HTML, behind a Reveal button that only hides it visually — the same fault we just fixed for the configuration passphrase, in a different place, with a real per-install secret. Found by looking for it rather than by an incident. (R-254)
• 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

• A password was living in the page source, and we went looking for others. The configuration passphrase was written into the settings page on every load and merely hidden with styling — it is now fetched only when asked for, and the asking is recorded. (R-249, fixed.) The search that fix required turned up two more places doing the same thing, one of them a real per-install app password. (R-254, not fixed — recommended next.)
• The record was a day behind itself. The recovery row still recorded only what was proven on 4 August. Corrected, with both halves and both dates. A sweep of all 146 register rows found no other entry whose state disagrees with its own body.

What we're working on

• Getting the remaining two secrets out of page sources, the same way. (R-254)
• 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 baked and approved the same day, so a machine installed now receives this week's fixes — including getting the password out of the page source. (R-242 — the bake half done; what remains is ours, not yours.)

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)