felhom.eu/STATUS.md

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

Updated 2026-08-09.

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. 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, in 72 seconds. The two rough edges that walk found are also gone. (R-201, R-252, R-253 — closed.)

Broken right now — and it stops every new machine

• No machine can be set up from scratch today. The install dies four steps in, on every host, and it needs one command from you to unblock (below). Nothing already running is affected — the two demo machines and the tester's box are fine. It is only the setting-up path, which is the one his visit is made of. (R-273)
• A rebuilt machine may come back on software from last week — the install will happily reuse an old copy it finds lying on the disk, without checking it against the version you approved. The copy on the demo machine is old enough to predate the recovery screen. (R-274)
• Taking Felhom off a machine leaves the one thing that stops it going back on. We install a small network service at setup; removing Felhom restarts it without its settings, it takes over the port the next install needs, and the next install then refuses — blaming the owner's network. (R-272)
• A machine we removed keeps its private line to us open. (R-276)
• demo-felhom has not had an off-site backup in six days and is waiting for a recovery code nobody has entered. demo-hp, rebuilt the same day, recovered by itself. (R-278)

What's broken

• Nothing else new is broken. The check against a fourth secret-in-a-page covers 4 pages of 27, and the cheap one covering all of them is blind to the shape that shipped. (R-255)
• An already-paired box is still told to pair itself, 25 minutes on. (R-214, R-235)
• A backup that covered nothing still calls itself „Sikeres". (R-240)
• A machine waiting for its recovery code can stop backing up off-site without alarming us. (R-243)
• The card offering to reopen set-aside backups promises more than we can deliver. (R-202)
• Deleting a customer leaves rows behind while reporting a clean teardown — no secrets, but it accumulates. (R-244)
• Putting restored files back where they belong is still manual. (R-213)

The reinstall rehearsal — what one afternoon on one machine found

We took a working demo machine, removed Felhom, and tried to put it back the way a person with their own hardware would. It got three steps in. That is the finding: nine defects, two of which stop a visit dead, and none of them were visible from reading the code — the last three sessions of review did not see any of them.

• It stopped at the install, on a missing version label (R-273) — and the step before that had already refused, because removing Felhom leaves behind the thing that blocks reinstalling it (R-272).
• Removing Felhom also leaves five files holding old keys (R-275) and a live private line to us (R-276).
• Along the way: rotating a leaked key does not actually revoke the old one until the service is restarted (R-269), the written-down recipe for that rotation is missing a step (R-270), and the alarm it raises can never be closed because the fix it recommends is what silences the all-clear (R-271).
• It also caught me being wrong. Three separate hub screens agreed that demo-hp had no off-site backup. It had eighteen. I told you the fleet's backups were down and had to take it back an hour later — the screens were misleading, but I should have asked the machine before telling you. (R-277)

The data was never at risk and is not now: the test files sit in an off-site snapshot with their fingerprints recorded, plus two local copies. Full account: documentation/audits/REHEARSAL-byo-reinstall-2026-08-09.md.

Three rulings, written down so they stop living in a conversation

• The managed-update floor. It is deliberately parked, and the trigger to raise it is the first machine that is not ours; after that it moves with the publish train. Worth knowing alongside it: the updater always aims at the floor, never at the newest, so a machine at or above the floor updates to nothing. Correction to the number that was going round: the floor is live at 0.200.0, not 0.156.0 — checked twice today, on the hub page and in both machines' own logs.
• R-264 is decided. Build a reader for guest-network health, the staged-update pair, the restore-test depth pair, and the two backup-integrity timestamps. Record a stated "no reader wanted" for the repaired-recently flag, the tier-applied timestamp, the config fingerprint, the per-stack object and the drive-migration marker. Decide the reporting-disabled flag on its own merits — if that is a state we support, it must be visible or a staleness alarm will one day fire on a machine that is fine. A "no" ends by changing the allowlist reason from arguably owed to deliberately not consumed — not by ripping out an emitter, which is a two-repo change that also breaks a shared fixture. The implementation is its own session. And it is twenty facts, not twenty-one.
• R-268 is closed — the leaked key is rotated, and the rotation is proved in both directions rather than assumed.

Fixed 2026-08-08 — four things the machine knew and did not say

A rebuilt machine can set up its own recovery again (R-221, agent 0.128.0 — proved on hardware); an unreadable disk is no longer drawn as a healthy empty one (R-259); a backup tick now answers about that app (R-258); our own alarm no longer points at a log that may not exist (R-265). Still true and not glossed: a failed disk reading still reaches us as "0 of 0 GB" — the quiet direction, it can only miss a true alarm, never raise a false one (R-266).

What we're working on

• Widening the check so a fourth secret-in-a-page is caught by a machine. (R-255) · R-264 is now decided (above); building the readers is a session of its own.
• Proving the hub really keeps the old sealed key when a machine re-seals. (R-198) · Still open, none urgent: (R-256, R-257, R-261…R-263, R-266)

Waiting on you

• One command, and it unblocks every install. The version you approved yesterday was published as a download but never given its version label in the source repository, and the installer looks it up by that label. The code is right and already shipped; only the label is missing. cd felhom-agent && git tag v0.128.0 28ba8593b8 && git push origin v0.128.0. I did not do it myself: publishing a release label is not a thing to do quietly in the middle of a measurement. (R-273)
• Then say go, and the rehearsal resumes where it stopped. Nothing has to be redone — the test files are already in an off-site backup and their fingerprints are recorded.

(Both items previously here are done: the approval is saved — golden 0.210.0, agent 0.128.0, minimum 0.127.0 — and the recovery fix was proved on hardware.)

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 — 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)
• After DooPlex next restarts, read /var/log/felhom-store-postboot-check.log — the second-SSD move has never survived a reboot; 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).
• The Configuration page is fixed: 26 s → 0.14 s. It was never hashing anything — the hashes are already stored and simply read. It was making 42 calls one after another. Now they overlap, connections are kept, the answer is held for a minute, and the old artifacts are gone. Worst case is 5 s, once a minute at most. Your instinct to prune was right and my measurement said otherwise — trimming to ten of each halved the slow path. (R-267 — closed.)
• The access token I printed into a log yesterday is rotated, and I checked it both ways: the old one is refused, the new one works, and the machine's own channel is back up. (R-268 — closed.)
• Our build-check alarm has one gap left. A run that hangs is now cut off after five minutes and the mail says how long it took — but whether the alarm fires at all when the machinery kills a run outright is still unverified, and we have not claimed otherwise. (R-265)