felhom.eu/STATUS.md

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

Updated 2026-08-03.

A view, not a source. documentation/backlog/OPEN-ITEMS.md is the authority on open work; 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 — keep the two separate. Maintenance: update at the end of every session in which something shipped, broke, or was decided. One screen; cut items rather than extend it.

What works right now

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 — and a customer can restore files and app data from the drive alone. Apps come back after a power cut: hard-reset the demo box six times, everything returned every time, and an app switched off deliberately stayed off. Proven end to end on real hardware.

What's broken

• One demo machine has no off-site copy of its app data, and has not since yesterday morning. The second demo machine (demo-hp) stopped reporting an off-site backup at 08:12 on 3 August and has not reported one in 108 check-ins since. The daily email you are getting about it is right that something is wrong, but its explanation is wrong — it says the password was never applied, when in fact it was applied on 23 July and then stopped working eleven days later. The automatic repair declines, correctly, because it can see it is a different problem — but says nothing about why. (R-192)
• The weekly off-site backup reports FAILED although it worked. It uploads correctly and then trips on a tidy-up step it is deliberately not allowed to perform, so the job ends in an error and you get an email. The backup itself is safe and on the endpoint. Both demo machines do it; one setting per machine fixes it. (R-191)
• The off-site copy can be erased by the machine that made it. The credential that writes it can also delete it. A daily snapshot is armed as a stopgap. (R-95, R-87)

What shipped recently

• The on-machine backup copy has now been proved to restore — by the machines themselves. Both demo machines restored their own on-machine backup into a throwaway machine overnight, booted it, checked it and destroyed it, without being asked: 84 and 109 seconds each. Every restore proof we had before this was of the off-site copy; the copy an ordinary recovery would actually use had never been tested on either machine. Both also proved their off-site copy on the same night, one after the other rather than at once, which is the machine deciding for itself what to do first. (closes the last open half of R-86/R-185)
• A backup copy the machine was never allowed to read — and could not tell you about, on both demo machines. The permission was one command; the silence was the real fault, and the machine now checks whether it may read each copy it depends on and says so when it may not. (R-185)
• Three ways the alarm system was misreporting its own work — all fixed. None of them ever risked data. (1) When the machine proved a backup restores, that result could vanish if the agent was restarted in the following quarter-hour — and yesterday's change made the gap a week rather than a day, because the machine correctly refuses to re-prove an archive it has already proven. It is now written to disk with the result and survives. This was caught happening, not predicted: a real 14.5 GB off-site restore passed and left no record at all. (2) Every release had about a fifty-fifty chance of emailing you a failure for a release that worked; the version tag is now published after the binary, and a new check catches the opposite mistake so nothing is traded away. (3) A released binary can now be rebuilt by anyone and checked against the fingerprint you approve — until today, rebuilding produced different bytes. (R-189, R-188, R-186)

What we're working on

• Now: nothing outstanding.
• Next: proving the off-site app-data copy can actually be restored — the one tier nothing tests unattended. Most of the machinery it needed arrived with the restore-test change below. (R-87)
• After: the off-site copy that the machine making it can still erase. (R-95)

Waiting on you

• A job, not a decision: the hub password needs changing. A diagnostic command printed it into a session log; nothing suggests anyone else saw it. (R-132)
• One small question, not urgent. The automatic check cannot see which version you have told machines to install, only which ones exist. Closing that needs either a password given to the build server or a check inside the hub itself. (R-184)
• Nothing else.

Changed since last update

• 2026-08-04 — Both demo machines proved their on-machine backup restores, on their own, overnight — the copy an ordinary recovery uses, never tested until now. Found while checking: the weekly off-site backup reports failure after a successful upload. (R-185, R-191)
• 2026-08-03 — Fixed three ways the alarm system misreported itself: a proof of a working backup that could vanish on a restart (seen happening), a release that emailed a failure for a release that worked, and a released binary nobody could rebuild and check. (R-189, R-188, R-186)