felhom.eu/STATUS.md

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

**Updated 2026-08-09 (evening).**

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

## Both machines are home, unmuted and healthy — one thing still needs you

**Back online 2026-08-10 ~09:26 CEST**, both unblocked on the hub, both reporting **OK** on the
approved pair (agent 0.128.0, controller 0.210.0). No false alarm fired on power-up. `drill-r50` is
untouched and still blocked, as intended.

**demo-hp is in good shape.** Its off-site repository still opens with the machine's own key —
**18 snapshots, including yesterday's rehearsal files** — so the tier is credentialed and ready; its
first scheduled run since the rebuild is tonight at 04:15. Two apps it had before the rehearsal
(opengist, privatebin) were never reinstalled; only Calibre-Web was, as the walk needed.

**demo-felhom is protected again — and the recovery you authorised turned out to be impossible.** Before running it I checked, and the sealed package holds *the same key the machine already had* — a key that provably does not open its own backup store. Recovering it would have handed back something useless. The store was written under an older key whose sealed copy was **not retained** (the retention fix landed hours too late for it), so **those 1.2 GB are permanently unreadable by anyone, including us**.

So I took your stated fallback: the old store was **moved aside, not deleted** (`/home/felhom-repo.orphaned-20260810`), a fresh one was created under the current key, and a real backup ran — **succeeded in 10 seconds**, and I listed what is inside it rather than trusting the green tick: OpenGist's configuration, its manifest and its data volume. **The week without off-site protection is over.** *(R-278 closed.)*

**One thing that needs your judgement, not mine.** The card that offered this told the customer their set-aside backups *may be restorable later with their recovery code*. For these ones that is simply untrue, and it is said to precisely the people who have just lost their history. *(R-202 — now evidenced.)*

## Can anyone else lose their history the way demo-felhom did? No.

**One read of the hub's own records, no machine touched.** The hub holds backup keys for exactly
**three** machines. Both demo boxes lost their old key in the same four-hour window on 4 August,
before the retention fix was in force — that is the whole population of the problem, and it is
entirely ours. **The tester's machine has no record at all**, so it cannot be affected; and anything
enrolled from now on is covered, because the fix has been in force since 4 August.

I ran a control before trusting the query: it had to say *material present* for a machine known to
have it and *absent* for one known not to. It did both.

## Three green dots came back, nine stayed grey, and one rule finally fired

**The nine greys are the honest number.** For those, no document anywhere walks the claim, and saying
so is more useful than a dot nobody can defend.

- **Back to green**, each citing the document that walked it: the drive wizard (a live drive taken
  through scan → format → mount → enrol), the on-box app backups (an overnight destructive campaign
  across both machines), and the lost-recovery-code case — which we then proved the hard way this
  morning.
- **One claim stayed grey for a new reason, and it is the interesting one.** The unattended
  restore-proof *does* have a receipt from 28 July — but demo-hp's restore-test failed on 5 August and
  the machine has since been wiped and rebuilt. It is a claim about something that keeps happening, so
  an old observation cannot carry it. **This is the first time that rule has fired**; two nights ago it
  fired zero times out of twelve.

## The prune mystery is solved, and the answer was written down all along

Who deleted the old versions: **you did, on 4 August evening, on your own rule** — 33 deletions, keep
set asserted first, every one a clean 204. **It was recorded inside the row about the Configuration
page being slow**, because pruning artifacts is what made that page fast. Two sessions failed to find
it. **You are no longer blocked** on establishing something that was already on file.

I also got a number wrong yesterday and it is corrected: I said the container packages held nineteen
versions and used that to argue against the prune. Counted properly — with pages — they hold 270 and
169, and the two that *were* pruned sit at exactly ten each.

## The sentence we should stop saying

When a machine's off-site history is set aside, the card tells the customer it *may be restorable
later with their recovery code*. **The machine showing that card cannot know whether it is true** —
the fact lives on the hub and is not sent to the box. For anything set aside before 4 August it is
simply false. **The replacement wording is written and waiting**
(`documentation/design/SPEC-orphan-card-copy-2026-08-10.md`); it ships with the next controller
release so one image bake and one approval cover it, rather than costing you two of each.

## 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. 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**,
in 72 seconds. The two rough edges that walk found are also gone. *(R-201, R-252, R-253 — closed.)*

## Shipped 2026-08-09 — the guards, and the rehearsal that earned them

**An approval that cannot be installed is now refused** at the moment you press Save: the hub checks
the version's git label and that its file downloads, and refuses with a message naming the fix. A
second machine catches it a step earlier in the agent repo. Both were owed after every install in
existence failed for hours on 2026-08-09. **Hub v0.102.0 is live.**

**The reinstall rehearsal:** a demo machine was wiped and put back. All four test files returned
**byte for byte**, accented Hungarian filenames included, checked as raw bytes. But it only finished
because a terminal was available twice — the install died on a missing version label *(R-273, now
guarded)* and **a reinstalled machine still cannot re-attach its own data drive** *(R-280 — the one to
fix before the tester's visit)*. Detail: `documentation/audits/REHEARSAL-byo-reinstall-2026-08-09.md`.

## What's broken

- **Nothing else new is broken.** The *check* against a fourth secret-in-a-page covers 4 pages of 27, and
  the cheap one covering all of them is blind to the shape that shipped. *(R-255)*
- **An already-paired box is still told to pair itself**, 25 minutes on. *(R-214, R-235)*
- **A backup that covered nothing still calls itself „Sikeres".** *(R-240)*
- **A machine waiting for its recovery code can stop backing up off-site without alarming us.** *(R-243)*
- **The card offering to reopen set-aside backups promises more than we can deliver.** *(R-202)*
- **Deleting a customer leaves rows behind** while reporting a clean teardown — no secrets, but it
  accumulates. *(R-244)*
- **Putting restored files back where they belong is still manual.** *(R-213)*

## Three rulings, written down so they stop living in a conversation

- **The managed-update floor.** It is deliberately parked, and the trigger to raise it is **the first
  machine that is not ours**; after that it moves with the publish train. Worth knowing alongside it:
  the updater always aims at the floor, never at the newest, so a machine at or above the floor
  updates to nothing. **Correction to the number that was going round: the floor is live at 0.200.0,
  not 0.156.0** — checked twice today, on the hub page and in both machines' own logs.
- **R-264 is decided.** Build a reader for guest-network health, the staged-update pair, the
  restore-test depth pair, and the two backup-integrity timestamps. Record a stated "no reader
  wanted" for the repaired-recently flag, the tier-applied timestamp, the config fingerprint, the
  per-stack object and the drive-migration marker. Decide the reporting-disabled flag on its own
  merits — if that is a state we support, it must be visible or a staleness alarm will one day fire
  on a machine that is fine. A "no" ends by changing the allowlist reason from *arguably owed* to
  *deliberately not consumed* — not by ripping out an emitter, which is a two-repo change that also
  breaks a shared fixture. **The implementation is its own session.** And **it is twenty facts, not
  twenty-one**.
- **R-268 is closed** — the leaked key is rotated, and the rotation is proved in both directions
  rather than assumed.

## Fixed 2026-08-08 — four things the machine knew and did not say

A rebuilt machine can set up its own recovery again *(R-221, agent 0.128.0 — proved on hardware)*; an
unreadable disk is no longer drawn as a healthy empty one *(R-259)*; a backup tick now answers about
*that* app *(R-258)*; our own alarm no longer points at a log that may not exist *(R-265)*. Still true
and not glossed: a failed disk reading still reaches us as "0 of 0 GB" — the quiet direction, it can
only miss a true alarm, never raise a false one *(R-266)*.

## What we're working on

- **Widening the check** so a fourth secret-in-a-page is caught by a machine. *(R-255)* · **R-264 is
  now decided** (above); building the readers is a session of its own.
- **Proving the hub really keeps the old sealed key** when a machine re-seals. *(R-198)* · Still open,
  none urgent: *(R-256, R-257, R-261…R-263, R-266)*

## Waiting on you

- **Nothing blocking.** The rehearsal is finished and demo-hp is back in service: agent 0.128.0,
  controller 0.210.0, claimed, off-site backups unlocked and intact.
- **One decision worth taking before the tester comes:** whether to fix the drive wall *(R-280)* now.
  It is the only finding that would stop his visit outright, and it is the difference between "his
  data comes back" and "his data comes back if someone types a path for him."
- **Two guards are still owed** so the install cannot break the same way twice: refuse to vouch a
  version whose label does not resolve, and check that a published version and its label ship
  together. *(R-273's tail.)*

## 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 — 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)*
- **After DooPlex next restarts**, read `/var/log/felhom-store-postboot-check.log` — the second-SSD
  move has never survived a reboot; on PASS, 34 GB comes back. *(R-209a)*
- **Backup scripts on DooPlex are unversioned host state** *(R-231)*, and the instruction-file
  follow-ups each need a decision rather than an edit *(R-229, R-230)*.
- **The Configuration page is fixed: 26 s → 0.14 s.** It was never hashing anything — the hashes
  are already stored and simply read. It was making 42 calls one after another. Now they overlap,
  connections are kept, the answer is held for a minute, and the old artifacts are gone. Worst case
  is 5 s, once a minute at most. **Your instinct to prune was right and my measurement said
  otherwise** — trimming to ten of each halved the slow path. *(R-267 — closed.)*
- **The access token I printed into a log yesterday is rotated**, and I checked it both ways: the old
  one is refused, the new one works, and the machine's own channel is back up. *(R-268 — closed.)*
- **Our build-check alarm has one gap left.** A run that hangs is now cut off after five minutes and
  the mail says how long it took — but **whether the alarm fires at all when the machinery kills a
  run outright is still unverified**, and we have not claimed otherwise. *(R-265)*