# 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

- **An app's own first-login password is still sitting in a page's HTML**, behind a Reveal button that
  only hides it visually — the same fault we just fixed for the configuration passphrase, in a
  different place, with a real per-install secret. Found by looking for it rather than by an incident.
  *(R-254)*
- **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

- **A password was living in the page source, and we went looking for others.** The configuration
  passphrase was written into the settings page on every load and merely hidden with styling — it is
  now fetched only when asked for, and the asking is recorded. *(R-249, fixed.)* The search that fix
  required turned up **two more places doing the same thing**, one of them a real per-install app
  password. *(R-254, not fixed — recommended next.)*
- **The record was a day behind itself.** The recovery row still recorded only what was proven on
  4 August. Corrected, with both halves and both dates. A sweep of all 146 register rows found **no
  other** entry whose state disagrees with its own body.

## What we're working on

- **Getting the remaining two secrets out of page sources**, the same way. *(R-254)*
- **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.** The new base image was baked and approved the same day, so a machine installed now
  receives this week's fixes — including getting the password out of the page source. *(R-242 — the
  bake half done; what remains is ours, not yours.)*

*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 makes every copy inside the same box, and nothing says when it fails.**
  *(R-232)*
- **193 old images exist only on this machine** and cannot be re-downloaded. About 27 GB against 199 GB
  free — clutter, not space. Nothing deleted. *(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)*