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 DEMO MACHINES ARE OFF AND MUTED — unmute them when they are home

**Powered down 2026-08-09 14:08 CEST** for the move back from the vacation home. Guests stopped
cleanly first (no vzdump was running, no locks), then the hosts. Confirmed off at the fabric, not
merely unreachable: the tailnet is healthy and both peers report *"offline, last seen 1m ago"*.

**Both customers are BLOCKED on the hub, deliberately, to stop four false alarms an hour into the
drive.** Blocking gates every monitor and the notification intake; it does **not** gate config pull or
report intake, so the boxes come back normally on power-up.

> **THE TAIL, and it is the reason this banner exists: while they are blocked, a box that FAILS to
> come back up is also silent.** When the machines are home and powered on, unblock them and confirm
> both report:
>
> Hub → Customers → **demo-hp** → Unblock, and **demo-felhom** → Unblock.
>
> Then check both read ONLINE on Hosts. **Until that is done, the hub cannot tell you either box is
> in trouble.**

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

## The guard is in. An approval that cannot be installed is now refused.

**Yesterday morning every install in existence failed for hours, and nothing would have stopped it
happening again. Now something does.** When you press Save on the Day-0 artifacts, the hub checks —
before it writes — that each version you are vouching actually has its git label **and** that its file
can actually be downloaded. If either is missing it refuses and tells you which, for which version,
and the one command that fixes it. **Hub v0.102.0 is live.**

Three details worth your knowing:
- **It checks the exact file the installer fetches first** — the one whose absence broke Friday — not
  some other file that happens to exist. A test pins that, because probing the wrong file is precisely
  how the failure stayed invisible.
- **"Could not check" also refuses**, with a different message. Saving with a warning would read as a
  success, and we have the scars. **There is no override**: the registry is on your own server, so if
  it is unreachable the approval can wait.
- **A second machine now catches it one step earlier** — the agent repo refuses to consider a release
  complete unless its label and its package both exist.

## The red repository is green, and the two rules now share one number

The tidy-up keeps the newest ten versions; the check demanded every version ever labelled still be
downloadable. Both are sensible and together impossible, so the red would have returned on your next
publish. They now read the same number from one file. **What the check no longer covers, plainly: a
version older than the ten is no longer asserted downloadable** — its label and its config files still
are — and it prints which ones it dropped on every run so this cannot go quiet.

**One thing I could not establish, and I am not guessing.** Who actually deleted the old versions is
**still unknown**. Gitea keeps no deletion trail: no cleanup rule is configured, the version table has
no deleted-marker, the activity feed shows no package operation, and the server log no longer reaches
back that far. I also **withdrew my own claim from yesterday** that the logs showed no deletion — the
logs did not cover the window, so they never said anything.

## The rehearsal finished. The data came back byte for byte; the journey did not.

**We wiped a working demo machine and put it back. All four test files returned identical — including
the two with Hungarian accents, checked as raw bytes, not as text on screen.** The unlock took 21
seconds and the restore 13. **But it only finished because I could open a terminal twice.** A
household would have stopped, twice, and the second time the screen would have told them it was easy.

**The two walls, both fixed-or-fixable, neither about the data:**

- **The install died four steps in** — the agent version you approved had been published as a download
  but never given its version label, and the installer looks it up by that label. **Now unblocked** —
  I pushed the label after checking the published file matched what you vouched. *(R-273 — closed. The
  two guards that would stop it recurring are still owed.)*
- **A reinstalled machine cannot re-attach its own data drive.** Every route is a dead end, and the
  restore page cheerfully says „**Ez két kattintás**" while pointing at an empty list. The drive is
  fine and the machine can see it — it just is not offered, because the same drive is also the backup
  target. I got past it by typing an internal path no customer could know. **This is the one to fix
  before the tester's visit.** *(R-280)*

**Also broken, found on the way:**

- **Taking Felhom off a machine leaves the one thing that stops it going back on.** We install a small
  network service at setup; removing Felhom restarts it without its settings, it seizes the port the
  next install needs, and the next install then refuses — appearing to blame the owner's network.
  *(R-272)*
- **A machine we removed keeps its private line to us open.** *(R-276)*
- **The hub said nothing at all** while a machine was wiped, rebuilt, re-claimed and had its sealed
  backups opened. No false alarm — but also no word, and the alarm that exists for "someone is opening
  this customer's backups" stayed silent through a real one. *(R-281)*
- **A rebuilt machine may still come back on software from last week** — narrower than I first wrote:
  the resumed install fetched the right version, but a fresh one takes whatever copy is newest on the
  disk without checking it against what you approved. *(R-274)*
- **demo-felhom has not had an off-site backup in six days** and is waiting for a recovery code nobody
  has entered. demo-hp, rebuilt the same day, recovered by itself. *(R-278)*
- **One code, three different names**, and the email points at a page the machine is not showing —
  this cost us a wasted code today. *(R-282, R-283)*

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

## The rest of what the rehearsal found

Sixteen findings in one afternoon, **none of them visible from reading the code** — three sessions of
review had not seen any.

- Removing Felhom leaves five files holding old keys *(R-275)*, and rotating a leaked key does not
  revoke the old one until the service restarts *(R-269)* — the written recipe for it is a step short
  *(R-270)*, and the alarm it raises can never be closed because the fix it recommends is what
  silences the all-clear *(R-271)*.
- **It caught me being wrong twice, and that matters more than the count.** I told you the fleet's
  off-site backups were down; demo-hp had eighteen snapshots and I had read three misleading screens
  instead of asking the machine *(R-277)*. And I raised a leftover permissions file as a security
  hole, then tested it and refuted myself — it is inert.

**What worked, and should not be lost in the count:** the machine came up on its own at the approved
version; the setup page appeared unprompted, in Hungarian, naming the customer; **the recovery screen
appeared without being looked for** and said plainly that unlocking changes nothing; the restore told
the truth about putting files in a checking folder rather than back in place; and no false alarm fired.

Full account: `documentation/audits/REHEARSAL-byo-reinstall-2026-08-09.md`.

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