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

**Updated 2026-08-05.**

> **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 the whole backup promise is now proved.** On 4 August we destroyed a machine on purpose and
deleted a marked file from its disk. Using the recovery code you saved: the backup key came back
**identical, character for character**; the existing off-site store **opened** rather than starting
over; and the file was restored **byte for byte identical**. *(R-201)*

## What's broken

- **A customer still cannot do that recovery alone — but only one step is left.** Getting from "the
  key is recoverable" to "the file is back" took four steps that appeared in no instructions. **Three
  are fixed today** *(R-204)*: the local reset-code tool works on the first try instead of needing the
  controller restarted; re-issuing the storage credential no longer falsely marks the recovery key
  "stale" (which used to stop every off-site backup and invite the one act that would have destroyed
  the recovered key); and the everyday restore now **says in plain Hungarian that it returned the
  app's settings and database and not your documents**, and names the button that does. **The step
  that remains is the first one:** a rebuilt machine cannot get a storage credential by itself,
  because the one-time password was used up by its predecessor — so you still have to press
  Re-issue. That is a design decision waiting on you, below. *(R-193)*
- **Rebuilding a machine still throws away its off-site backup HISTORY.** The machine invents the key
  that encrypts its own off-site backups, and a rebuilt machine invents a brand-new one. Both demo
  machines did this on 3–4 August — 51 backups (~1.2 GB) between them. The old key now survives the
  recovery ceremony, and a changed key now raises an alarm the same day, but **the rebuild itself
  still starts a fresh history**. *(R-193)*
- **One screen still tells the customer something we cannot yet promise.** The „elárvult tároló" card
  says the old backups may later be restorable with the matching recovery code. That is true for
  machines that re-seal from now on and **false for anything already orphaned** — and the machine
  cannot tell which case it is in. We deliberately did **not** patch the sentence: a conditional
  promise that can still be wrong is worse there than a vague one. *(R-202)*
- **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

- **2026-08-05** — **Three of the four recovery crutches removed.** The reset code works first time;
  a credential re-issue no longer blocks off-site backups on a healthy machine; and the default
  restore no longer quietly returns the wrong thing. *(R-204 items 1–3, R-196)*
- **2026-08-04 (night)** — **The drill PASSED**, end to end, on real hardware. *(R-201)*
- **2026-08-04** — The folder-left-out-of-the-backup problem fixed both halves: the app and its backup
  look in the same directory, and a backup that misses a folder marked essential reports *incomplete*
  instead of success. *(R-203)*
- **2026-08-04** — The hub now keeps the off-site backup key when a machine re-seals, instead of only
  the whole-machine one, and a machine can fetch its own sealed package back. *(R-198, R-199)*
- **2026-08-04** — The daily false alarm about David is gone; a vanished permission now repairs itself
  **and says it had to**; the weekly off-site backup stopped reporting failure after a successful
  upload. *(R-195, R-190, R-191)*

## What we're working on

- **Next: the retention proof.** The hub keeping the old sealed key when a machine re-seals is the one
  remaining link that has **never run outside a test**. Proving it needs a second deliberate wipe on
  the spare demo machine, and it is its own procedure. *(R-198)*
- **Then:** the orphaned-backup deletion you asked for (below), and the off-site copy the machine can
  still erase. *(R-193, R-95)*

## Waiting on you

- **The one-shot credential decision — this is now the last thing between a customer and an unaided
  recovery.** A rebuilt machine has no storage credential of its own, so an operator must press
  Re-issue. Everything after that point is now self-service. Deciding how a rebuilt machine should get
  a credential is the remaining design question. *(R-193, R-204 item 4)*
- **The recovery screen you described has been priced, and it can be built.** A freshly installed
  machine that finds a sealed package waiting should say so, offer a box for the recovery code, and
  show what would come back before doing anything. One thing to weigh, deliberately not decided: that
  screen is reachable by anyone with the household's dashboard password, and the preview reveals
  backup dates and app names. *(R-193)*
- **The orphaned backups on the storage box — you said delete, and it is still owed.** About 1.2 GB
  across the two demo machines, in set-aside stores nobody can open and nothing prunes. It wants its
  own session rather than riding along with other work. *(R-193)*
- *(decided 4 Aug)* You chose **not** to keep a copy of the backup key on the Proxmox host, which
  makes the customer's own recovery code the only route back from a rebuild. *(R-193)*
- **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 version check cannot see which version you have
  told machines to install, only which ones exist. *(R-184)*