felhom.eu/STATUS.md

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

Updated 2026-08-12 (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. Items, not paragraphs. One screen. If it does not fit, it belongs in the register instead.

Waiting on you

• Vouch golden 0.213.0 — three fields together: golden 0.213.0, agent 0.128.0, min agent 0.127.0. Both are already verified downloadable and selectable.
• Raise the floor to 0.213.0 afterwards if you want the fix on the existing machines. The floor is 0.212.0 (raised 2026-08-12; both demo boxes confirmed on it), and boxes update to the floor, never to the newest — so until you raise it, v0.213.0 reaches newly installed machines only. One field, reversible; the R-216 hold does not apply, since min agent 0.127.0 is below the vouched 0.128.0.
• R-303 — one coherence decision, ranked low: a box can still raise the "we cannot open your new backups" card while counting down to deleting the old ones. The two no longer contradict each other, but the state is odd and the wrong fix would hide a real second fault.

What works

Both demo machines are home, healthy and reporting on the approved pair. Off-site is credentialed on demo-hp and its repository still opens with the machine's own key. drill-r50 is blocked, as intended.

Shipped

• The drive can be re-attached after a reinstall (R-280). The restore page said "this is two clicks" over an empty list; it was zero clicks and needed an internal path no customer could produce.
• The orphan card stops promising that set-aside off-site copies can be reopened — twice over (R-294, then R-299, which was the same claim in the plural, in the always-visible half, missed because the guard matched one inflection of a Hungarian verb).
• The countdown banner stops promising retrieval it cannot see is still true (R-302). The promise is now conditional on the hub still holding the package it held when the customer decided — pinned then, compared now. A sweep found the same claim in five places; a fourth was fixed with it and a fifth deliberately left, because it is true where it renders.
• One name per secret, box side (R-295): the dashboard code is „Beállító kód" everywhere; „Visszaállító kód" is retired. It collided with the escrow „Helyreállítási kód" and cost a real code.

Broken, or knowingly incomplete

• The tester's machine has no recovery route at all — see the PETI row. Its host record was deleted on 15 July; there is no key, no off-site copy and no local backup. If that drive fails, everything on it is lost. First act of the visit: copy the ~3.6 GB off before anything is reinstalled — it is currently the only copy in existence. Whether it stays parked is your call and is deliberately left open.
• Two installer fixes are written but NOT published — pushing publishes nothing, and no tag is cut:
  • R-297 — an install could silently reuse an old base image lying on the machine, including one too old to run the recovery screen.
  • R-300 — our own uninstall left dnsmasq holding :53, so our own next install refused and blamed the household's network. Both are unpublished for the same reason: neither fault has been watched happening. One session on drill-r50 covers both, and that is the right order.
• The hub half of the naming is undone (R-295 PARTIAL): the emails still use the retired name and send people to a page a rebuilt machine does not show.
• The storage page has its own separate reason for showing an empty list (R-298), untouched.

Working on next

The drill-r50 session that unblocks both installer fixes; then the hub naming; then the 2026-08-09 batch (R-279 … R-292) which is still untriaged against everything since.