felhom.eu/STATUS.md

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

**Updated 2026-08-22 — the off-site restore now works for all 53 apps, not 13. It is released and
NOT yet delivered: two steps below are yours.**

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

*This section is allowed to be longer than one screen, and each item says what happens if you do
nothing.*

1. **Vouch the golden carrying controller 0.219.0** — Hub → Configuration → Day-0 artifacts.
   **It is baked, published and round-trip verified** (`documentation/tests/golden-0.219.0-2026-08-22/`);
   only the vouch is left, and only you can do it. **It is a THREE-field save, not one:**
   `golden_version` → **0.219.0**, `agent_version` → **0.130.0**, `min_agent` → **0.129.0**. Moving
   `golden_version` alone ships this controller onto an agent older than it declares it needs.
   **If you do nothing:** a machine installed today still receives 0.218.0 — the image exists, on the
   shelf, undelivered. Reversible: re-select the old values and Save.
2. **Then raise the auto-update floor to 0.219.0 — last, in a separate save.** It acts within seconds.
   **If you do nothing:** every existing machine stays on 0.218.0, so the fix below reaches nobody and
   40 of 53 apps stay un-restorable on the actual fleet. *(register: R-343's rule)*
3. **Whether to change the hub password** (R-350). I printed it into my own session log on 20 August.
   Not in git, not in any saved file — in the log on this machine. **If you do nothing:** it stays as
   it is, at the risk you accept by leaving it. I can change it without ever showing you the new one.
4. **`demo-hp`'s network setup does not match our own notes** (R-338) — the machine works, the page is
   wrong, or the other way round. **If you do nothing:** the page keeps misleading the next session,
   as it misled one by an hour.

## Decided — and what would reopen each

- **Getting old backups back yourself: NOT BUILT, deliberately.** **Reopens if:** a real customer
  asks. *(R-312)*
- **The unopenable old copy on `demo-felhom`: KEPT as a test fixture** — the only state in existence
  where a set-aside store is present and cannot be opened. **Delete when:** that work ships or is
  abandoned. *(R-313)*
- **A machine in two kinds of trouble says both things: LEFT AS IT IS.** **Reopens if:** observed
  outside a constructed test. *(R-303)*

## What works

Both demo machines are home, healthy and reporting — agent **0.130.0** published and running on both.
`demo-hp` runs controller **0.219.0**; the fleet floor is still **0.218.0** (see item 2 above).
Off-site is credentialed on `demo-hp` and its store opens with the machine's own key.

**The fleet, because two summaries have been misread:** five customer records, three machines.
`demo-felhom` and `demo-hp` are ours and disposable; `drill-r50` is a nested drill VM, reverted and
off. **`peti-felhom` is a real machine we have not heard from since 15 July** and has no host record.
**`tester-1` is a record with no machine.**

## Shipped

- **The off-site restore now works for the other 40 apps** (R-356, controller 0.219.0, proven on
  `demo-hp`). It used to refuse before starting, tell the customer a running app „nincs telepítve",
  and send them to reinstall it "to the same place" — a place those 40 apps never offer, because they
  were never given a drive to choose. It was asking one question to answer two. Proven today on
  `privatebin`: data planted through the app itself, backed up, **deleted**, restored — **all 15 files
  back byte for byte**, Hungarian accented names included, message „0 fájl és 1 adatkötet
  visszaállítva". The 13 apps that do have a drive are unchanged, checked the same way.
- **The off-site restore gives an app's data back at all** (R-354, controller 0.218.0). It used to say
  „0 fájl visszaállítva", report success, and the folder was simply not there. It now names what came
  back, because a restore that mentions only its file count is how a silent loss reads as a success.
- **Paperless's database is in the backup, and restoring it takes an undo copy first** (R-355,
  controller 0.218.0). The dump was landing in a folder named after an app that does not exist. **One
  app of 53 was affected**, established with a check first proved able to catch a planted second case.
- **The system tells you when it cannot see the off-site copies** (R-339) — a mail after ~30 minutes,
  hourly while it lasts, one all-clear. **Caveat:** it watches whether the machine answers, so it
  would *not* have caught the 18 August fault, where one service was wedged and the machine stayed
  healthy.
- **The connection leak was ours and is fixed** (R-344). Our agent opened a connection to the off-site
  box every 15 minutes and never closed it; the idle timer was switched off. Proved by fixing one
  machine and leaving the other: same work, 4 more leaked on the untouched one, none on the fixed one.
  The off-site box is back to **17** open connections from **415**.
- **A dated check can no longer be quietly missed** (R-341) — but it speaks on the next push, not on
  the day. **A machine we tell to be quiet is no longer reported as dead** (R-321). **One name per
  secret** (R-295, R-323). **The hub's own words are under a guard** (R-324). **Removal reverses the
  installation** (R-316). **A correct recovery code is no longer called wrong** (R-311). **The drive
  can be re-attached after a reinstall** (R-280).

## Broken, or knowingly incomplete

- **Nothing ever checks that the off-site store is still readable** (R-359). Not the controller, not
  the agent. We find out at restore time. A deliberately corrupted copy was caught instantly by the
  standard tool — which we never run.
- **A restore that returns nothing still reports success** (part of R-354's neighbourhood, not fixed
  today) and **verification copies have no delete guard**. Both deliberately left for their own rows.
- **We ask the off-site box a question about once a second** (R-336) — ~85,000 a day for a box we
  write to weekly. The leak that made this dangerous is fixed (R-344); the volume is not. The ceiling
  is **under a year** away on the corrected measurement, not two.
- **Peti's machine has no recovery route at all.** A real machine belonging to a real person, silent
  since 15 July, no key, no off-site copy, no local backup. **If that drive fails, everything on it is
  lost.** First act of any visit: copy the ~3.6 GB off before anything is reinstalled.
- **The agent picks dnsmasq by looking at a file another package owns** (R-317) — one line; LAN name
  resolution goes missing quietly.
- **Three facts the machines send still have no reader** (R-264); **the storage page has its own
  reason for an empty list** (R-298); **two thirds of the standing picture is unproven** (R-326:
  23 of 55 claims walked — `python3 scripts/unproven.py`); **the picture still describes one defect we
  fixed twice** (R-327).

## Working on next

The 2026-08-09 batch (R-279 … R-292), still untriaged; the three remaining R-264 readers; R-317 (one
line in the agent); R-327 (decide the naming claim's status); R-359 (nothing reads the off-site store).