# 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

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