admin
e3187c86d5
gates / gates (push) Successful in 8s
- OPEN-ITEMS: R-185 closed with the measurement, the corrected root cause (the installer's Scenario-F reuse arm, not PVE_STORAGES), and the live sequence. Records that demo-hp carried the same drift and was fixed too. - capability map: the whole-guest row's HOST-tier half was OPTIMISTIC and now says so — that tier was not merely unproven, it was unprovable on both demo boxes, and every live proof cited was on the offsite tier. - vzdump-target-move runbook: its item 5 predicted this; annotated (not rewritten) with what actually happened — the create arm did grant, the reuse arm did not, and it surfaced as a silent unreadable tier rather than the 403 the item expected, because vzdump writes through a root path. - CONTEXT: S-21 (an empty listing cannot distinguish forbidden from newborn; the measured trap that an ungranted path answers with INHERITED privileges) and S-22 (the Scenario-F arm must finish the job). - STATUS: rewritten for the operator, back to one screen.
5.1 KiB
5.1 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
- 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, and we have never restored from that copy. (R-95, R-87)
What shipped recently
- A backup copy the machine was never allowed to read — and could not tell you about. One demo machine kept its whole-machine backups on a dedicated storage area the agent had never been granted permission to read. Asked what was there it was told "nothing", while an administrator saw three backups. The permission was one command; the silence was the real fault — a storage that answers "nothing" looks exactly like a brand-new one, which is a normal, healthy state, so that copy had never been test-restored and nothing had ever mentioned it. The machine now checks whether it is allowed to read each copy it depends on and says so when it is not — the alert reached you by email before the permission was granted, which is the whole point. Both demo machines carried it and both are fixed, and new machines no longer inherit it. (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)
- Each backup is now proved, instead of the clock being obeyed — tested once, about a day after it is made, and not again until there is a newer one; the "not proved lately" alert learned each copy's own rhythm in the same change. (R-86)
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-03 — Found and fixed a backup copy the machine was never permitted to read, on both demo machines. The permission was one line; what mattered was that the machine now says so instead of treating "I am not allowed" and "there is nothing here yet" as the same answer. (R-185)
- 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)
- 2026-08-03 — Backups are now proved one at a time, each about a day after it is made, instead of on a timer; the "not proved lately" alert learned each copy's own rhythm. You settled that the off-site endpoint is protected. (R-86)