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

Fixed today — the thrown-away sentence, and a check so there is no next one

We could not tell whether your engineer could get into a machine. The machine says so every few minutes; the hub had nowhere to put the sentence and discarded it on arrival, so a box with the door open, the lock working and no key issued was reported as fine. Not a wrong answer — an answer to a question nobody was asking. Fixed, and the alert now names the missing key instead of saying "access degraded". (R-260, R-247 — closed; hub v0.99.0, controller v0.209.0.)

The check was built first and watched failing on 40 facts, before a single one was fixed — the night before, an off-the-shelf tool for a neighbouring shape was rejected for failing exactly that test. Of the 40: three now change what we are told, sixteen are genuinely redundant, and twenty-one are recorded as undecided rather than quietly waved through (R-264) — the strongest being per-guest network health, which we already lost 1 h 15 m to once.

What we're working on

• Widening the check so a fourth secret-in-a-page is caught by a machine. (R-255) · Deciding the twenty-one — each gets a reader, or stops being sent. (R-264)
• Proving the hub really keeps the old sealed key when a machine re-seals. (R-198) · Still open from the overnight sweep, none urgent: (R-256…R-259, R-261…R-263)

Waiting on you

• One approval, and now it is the only one: the new base image. Baked, published, byte-checked — and installations receive an older version until you press Save. Hub → Configuration → Day-0 artifacts → Golden 0.209.0 → Save. One field moves, the other two were checked and are right, and it is reversible. It supersedes last night's unvouched 0.208.0, so this is one decision, not two. (R-242)
• Fourth time in three days, so worth a minute. A check now catches the baking being forgotten — it caught it again today and refused the push until it was done. Nothing catches the approval being forgotten. Two ways to close that are written up, neither built. (ROADMAP G-8)

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 keeps every copy inside the same box, and is silent when it fails. (R-232)
• 193 old images exist only on this machine, ~27 GB against 199 GB free — clutter, not space. (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), and the instruction-file follow-ups each need a decision rather than an edit (R-229, R-230).