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

**Updated 2026-08-08.**

> **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority; 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. **Items, not paragraphs. One screen.** If it does not fit, something
> belongs in the register instead.
>
> *Rebuilt from the register on 2026-08-07, from 258 lines. The old "what shipped recently" log is what
> the per-repo `CHANGELOG.md` files and the register are for, and is not restated here.*

## What works

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.

**The backup promise is proved, and so is getting the data back yourself.** A machine has been
destroyed on purpose and its files came back byte for byte identical — four times now, including a
filename with Hungarian accents. On **2026-08-07 the household's own journey passed for the first
time**: someone with a browser and their recovery code got everything back with **no command line
inside the machine at any point**. From logging in to seeing what is in the store took **72 seconds**.
*(R-201 — closed.)*

**And the two rough edges the walk found are gone.** After a rebuild the restore used to stop dead
twice — once because the machine no longer recognised its own drives, once because it refused to
restore an app that was not installed while promising, three lines above, that it would reinstall it.
Both now say what has happened, say that nothing is lost, and link to the one screen that fixes it.
*(R-252, R-253 — both closed 2026-08-08.)*

## What's broken

- **Nothing new is broken.** The three known secret-in-page faults are all fixed; what remains is that
  the *check* against a fourth covers 4 pages out of 27, and the cheap check that covers all of them is
  blind to the exact shape that shipped. Filed rather than papered over. *(R-255)*
- **The machine's own screen keeps telling an already-paired box to pair itself** — 25 minutes after it
  was paired, on a screen that promises it refreshes itself. *(R-214, R-235)*
- **A rebuilt machine cannot create a new recovery code at all.** *(R-221)*
- **A backup that covered nothing still calls itself „Sikeres".** The state is honest; the word is not.
  *(R-240)*
- **A machine waiting for its recovery code can stop making off-site backups without alarming us.**
  Measured on 7 August: after a *rebuild* we ARE told, promptly and correctly. The gap is narrower than
  it read — it is a machine that reaches the state without a working tier behind it. *(R-243)*
- **The card offering to reopen set-aside backups promises more than we can deliver** — we keep the old
  sealed package, but nothing can open it. *(R-202)*
- **Deleting a customer leaves rows behind** on every test machine ever torn down, while reporting a
  clean teardown. No secrets involved, but it accumulates with each walk. *(R-244)*
- **Putting restored files back where they belong is still a manual step.** *(R-213)*

## Found today

- **The last two passwords are out of the page source**, the same way as yesterday's: the page carries
  only a yes/no, and the value is fetched when you ask for it — and the asking is now recorded, which
  it never was. One of them was an app's own first-login password, read live out of the running app.
  *(R-254, both sites fixed.)*
- **How much was actually exposed: nothing we can find.** The only app that generates a first-login
  password isn't installed anywhere, and of the three apps actually running on the demo machine, none
  uses a generated secret. **But nothing recorded reads** — that was part of the fault — so this is
  "no evidence of exposure", not "proof there was none". No passwords need changing on that basis;
  the call is yours.
- **One of the two turned out not to be a fault.** The deploy form's hidden password field is
  deliberate: a form must submit what it saves, so the value you wrote down is the one stored.

## What we're working on

- **Widening the check** so a fourth secret-in-a-page is caught by a machine rather than by
  someone looking. *(R-255)*
- **Proving the hub really keeps the old sealed key** when a machine re-seals. Never run outside a
  test; needs a second deliberate wipe and its own session. *(R-198)*

## Waiting on you

- **Nothing blocking.** Today's release needs a new base image before installations receive it — same
  as yesterday, same answer: it is ours to do, not yours. *(R-242)*

*R-245 — whether an undecided household is auto-abandoned after 30 days — was settled on 7 August: we
do not build it, and the reasoning is recorded.*

## DooPlex infrastructure — separate from the product

*Kept under its own heading rather than dropped: these are real asks that need you, but they concern
the machine all this is built on, not what a customer receives. Mixing them in is why the page stopped
being readable.*

- **DooPlex's own backup keeps every copy inside the same box, and is silent when it fails.** *(R-232)*
- **193 old images exist only on this machine**, ~27 GB against 199 GB free — clutter, not space. *(R-210)*
- **The hub password needs rotating** — a diagnostic printed it into a session log; nothing suggests
  anyone else saw it. *(R-132)*
- **One thing to read after DooPlex next restarts** — the second-SSD move has never survived a reboot;
  it writes PASS/FAIL to `/var/log/felhom-store-postboot-check.log`. On PASS, 34 GB comes back. *(R-209a)*
- **Backup scripts on DooPlex are unversioned host state.** *(R-231)*
- **Instruction-file follow-ups**, each needing a decision rather than an edit. *(R-229, R-230)*