admin
a684a81796
R-191: the gate was run first and it mattered — ep0's prune jobs have run daily since 2026-07-27 (18 tasks, all OK). THREE of my own queries said the opposite and all three were broken instruments (worker-type vs worker_type, prune vs prunejob, proxmox-backup vs proxmox-backup-proxy); acting on any would have disabled the only pruning attempt while reporting that nothing prunes. R-190: the row now reflects the MITIGATION, not the cause, and says so. Includes that v0.124.0's transition record failed in production while every unit test passed, and Part 3's single pass — the token-rotation class is real and documented in our own installer but does not fit this box (same token still authenticates, the other three grants survived, no installer run evidenced); ruled out on this box, not fleet-wide. R-194: PVE caches permissions (~40s and ~16min measured), so a single permission read is a lagging indicator and may explain when R-190's refusal surfaced. 07-backup-architecture: the offsite retention row was RIGHT and the configuration disagreed with it — noted, since a doc that states a contract does not enforce it.
5.3 KiB
STATUS — what works, what's broken, what's next
Updated 2026-08-03.
A view, not a source.
documentation/backlog/OPEN-ITEMS.mdis the authority on open work; 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 — 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
- Rebuilding a machine silently takes away its off-site app-data backup. Fixed on demo-hp on 4 August (re-issued, picked up in 15 seconds, same repository, you escrowed the key), but the underlying fault stands: the password is delivered once and a rebuilt machine cannot ask again. The daily email about it also tells the wrong story. (R-193, R-192)
- (fixed 4 Aug)
The weekly off-site backup reports FAILED although it worked.It uploaded fine and then tripped on a tidy-up step it is deliberately not allowed to perform. The machine no longer asks — tidying up is the endpoint's job, and that was checked first: the endpoint has been doing it every day since 27 July. Both machines and all future ones. (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
-
A permission the machine needs can now repair itself — and it tells you it had to. Yesterday we found a permission that vanished with no reinstall and no recorded action; the machine now notices, restores it through the same controlled helper that grants it in the first place, and raises an alert saying it was missing and was restored. The alert is the point: a permission that silently fixes itself is one that can be lost over and over and never investigated. Proven twice on a demo machine by taking the permission away by hand. (R-190 — the repair; why it vanished is still open)
-
The on-machine backup copy has now been proved to restore — by the machines themselves, both of them, overnight and unasked (84 and 109 seconds). Every restore proof before this was of the off-site copy. (R-86, 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)