felhom.eu/STATUS.md

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

**Ready for the first real tester (Tester-2): yes. Tester 2 (a laptop) is off; nothing was sent to it.**

**Updated 2026-10-10 (afternoon): hub 0.146.0; demo-hp, demo-felhom and Tester 1 run agent 0.154.0 and controller
0.307.0. The open-items list is at 126 (was 138). Reports: `REPORT-register-shrink-2026-10-10.md`, `REPORT-new-apps-2026-10-10.md`, `REPORT-release-2026-10-10.md`, `REPORT-break-the-circle-2026-10-09.md`, `REPORT-dooplex-survival-2026-10-09.md`, `REPORT-day4-2026-10-09.md`.**

## Saturday 2026-10-10 (late afternoon): the list is shorter, and one sheet for you

- **The list went from 138 to 126.** 13 items closed, each with a check on a real box, the live website or the off-site server. One new item: two sessions testing at the same time can see each other's test faults in the shared folder (a design question for later).
- **Controller 0.307.0 runs on demo-hp, demo-felhom and Tester 1.** It removes an old fallback that no box needs any more, and it fixes a bug I found today: after a controller restart, the backup page listed each database several times. I checked the fix on demo-hp: 6 databases, 6 rows.
- **The website:** the phone menu now works with JavaScript off (it did not open before), and the eight dashboard pictures show today's screens. A new website check makes sure every app has its logo file.
- **The app catalog:** its slow container check now refuses to run on DooPlex, so it cannot act on the production machine again.
- **Two checks wait for tomorrow:** tonight's backup on Tester 1 must still run after the daytime press I made (it proves a fix from Thursday), and on Sunday evening the hub must mail you that Tester 2 has never made an off-site copy (it is due then, not before).
- **Good news found on the way:** DooPlex's saved login for the image registry works again, so builds push normally.
- **Not done:** no hub release and no agent release (none was needed). The R-925 work and its Secrets were not touched.

### The decision sheet (2026-10-10 afternoon) — answer „all as picked", or name the numbers you change

Each line: the question, **my pick**, what the other option costs, what happens if you do nothing. The full reasoning is in each row of `OPEN-ITEMS.md`.

| # | Row | Question | Pick | The other option | If you do nothing |
|---|---|---|---|---|---|
| S1 | R-922 | When a household clears its mail address, do we also stop mails to the address you registered for them? | **No** — the registered address is the contract contact; the privacy notice says so | B (clear both): you lose your only mail contact; kernel notices go nowhere | Behaviour is the pick, but the privacy notice does not say it |
| S2 | R-831 | The Hetzner storage token that leaked on 2026-10-03 (Secret not changed since 2026-07-09) — rotate it? | **Rotate**, after R-925's rotation is finished (~5 min: new token, patch the Secret, restart the hub Deployment, delete the old) | A (accept): a token that can create/reset/delete sub-accounts stays valid | The token stays valid |
| S3 | R-870 | Tester 1's two leaked tokens (rulings 10-04/10-05: not now) — close as accepted? | **Close as accepted**; rotate when Tester 1 is retired | B (rotate now): ~15 min in Cloudflare + the hub | Same as the pick, without the record |
| S4 | R-242 | Build a check that the newest baked golden was also vouched? | **Yes**, a hub alarm, before the first external install (~1 hub session + an attended deploy) | A (no): a forgotten vouch is found only when a fresh install lands on an old controller | Same as A |
| S5 | R-388 | Redesign the household's notification settings to „only what you can act on" before the first sale? | **Yes, design now**, build in slices (several sessions) | B (after the first customers): the first customer gets the per-detector toggle page | The page grows by one toggle per new detector |
| S6 | R-244 | May CC remove a deleted customer's id from shared app-log issue rows (and sweep once)? | **Yes**, before the first real customer is deleted (1 hub session + an attended deploy) | B (accept): one id per torn-down customer stays in aggregate rows, no secret | Same as B |
| S7 | R-264 | The six owed hub readers are already decided (2026-08-12) — may CC own the row and build them when the queue is idle? | **Yes, CC owns it** (~1 session per group, attended hub deploys) | B (drop the emitters): a two-repo change that breaks the host-report golden | Six facts stay sent and unread |
| S8 | R-698 | A restore of an app version whose maker deleted the image cannot start — accept it? | **Accept**: write it as a known limit in `07` §6.6 and close | B (mirror every installed image to DooPlex): storage + bandwidth, a new part on the recovery path | Behaviour is the pick, unwritten |
| S9 | R-255 | Build one test that renders every dashboard page with planted secrets and fails if any shows? | **Yes** (CC, one session; ~23 page fixtures) | B (no): a secret under a neutral page key can still ship unseen | A fourth leak of the R-254 shape would not be caught |
| S10 | R-266 | Carry „disk reading failed" to the hub so it is not read as an empty disk? | **Yes**, in the next hub + controller release (two-repo change) | B (no): while the disk cannot be read, the hub sees 0 % and stays quiet | A missed alarm during a fault that has louder symptoms |
| S11 | R-333 | A healthy NVMe under load can pass 60 °C and show „Hiba" — how do we band NVMe heat? | **No heat band for NVMe**; rely on the drive's own critical warning (smallest change) | A (separate NVMe bands, warn 70): one small controller change + test | A busy NVMe can raise a false drive alarm |
| S12 | R-577 | Do guest share pages get the language globe (the visitor's own cookie)? | **Yes** (CC, ~1 hour, next controller release) | B (no): a foreign visitor sees the household's language | No harm today |
| S13 | R-327 | Which status does the code-naming arc get in the capability map? | **„built"** — fixed and shipped, no customer has used it yet; CC rewrites the title | B („walked"): an over-claim | The map keeps showing a fixed defect as open |
| S14 | R-230 | May dated history entries in the memory index keep version numbers? | **Yes**; close (a) and drop the pilot (c) | B (bulk-remove them, start the pilot): one session, less detail | The gate keeps warning; no harm |
| S15 | R-719 | The expired self-bind link now offers „Új linket kérek" — accept this shape and close? | **Accept and close** | B (another shape): a new hub change | The row stays open; behaviour as built |
| S16 | R-352 | The data-placement spec: hot data in the guest, bulk on a drive is by design — close? | **Close as by-design** (the visibility fix shipped; R-368 fixed the comment) | B (keep the 5-point spec open): a P4 row nobody works | Nothing changes for a household |
| S17 | R-526 | Build a „release only the PBS token" operation on ep0 for a host delete? | **No, close** — the R-511 adopt path already reuses the kept token | B (yes): a new operation on a protected box, one session | Kept tokens stay on ep0; no customer impact |
| S18 | R-213 | When do we design „see what a restore would change"? | **After the first customers** | B (now): several sessions | Same as the pick |
| S19 | R-288 | Give CC one session to restructure the capability map (211 KB; one status line per capability + a dated pointer)? | **Yes** (documentation only) | B (accept): the map keeps growing (~75 KB in two months) and nobody can re-verify it | Same as B |
| S20 | R-231 | Put DooPlex's own backup scripts (`/opt/backup/scripts`, 16 files, changed on the box only) under version control? | **Yes** — CC copies them into a repo + an install script, you present for the install | B (accept): a DooPlex rebuild has to rewrite them from memory | Same as B |
| S21 | R-887 | CI jobs are still lost (4 today, one of them this session's — re-run once, it passed) — change DooPlex to stop it? | **Yes**: raise the act-runner fetch timeout and rate-limit the public Gitea pages the crawler walks (two DooPlex changes, yours) | B (no): sessions re-run lost jobs once; red runs with no mail | A real failure can hide among the lost ones |
| S22 | R-886 | Alertmanager cannot write its state (root-owned volume, the pod runs as nobody) — may CC add `fsGroup: 65534` on DooPlex and prove a silence survives a restart? | **Yes** (one manifest line, CC with your word) | B (no): silences and send history die at every pod restart | Same as B |
| S23 | R-211 | Prometheus has no config reloader, so an alert-rule change waits for a manual reload — may CC add the reloader sidecar on DooPlex? | **Yes** (one manifest change, CC with your word) | B (no): every rule change needs a `POST /-/reload` by hand | A rule change can sit unread with no error |
| S24 | R-770 | Add Invidious to the catalog? | **No — close** | B (go): a rolling companion image, PostgreSQL 14 near end of life, YouTube can block the household's IP for 24 h | The idea waits; nothing breaks |
| S25 | R-771 | Add moonlight-web (game streaming) to the catalog? | **No — close** | B (go): a new LAN-only publishing model (UDP/WebRTC) | The idea waits; nothing breaks |
| S26 | R-782 | Glance (the link dashboard) has no login: anyone with the address sees it. Give it one? | **Yes, behind the family gate** like Grimmory (catalog change, CC) | B (no): the household's link list is public by address | Same as B |
| S27 | R-554 | Deleting the obsolete setup wizard makes `recovery-info.txt` (on every box) point at a route that no longer exists. What should that file say instead? | **Point at the dashboard's Restore page and the recovery code** (CC writes it, you approve the Hungarian) | B (keep the wizard): obsolete code stays reachable | The obsolete wizard stays reachable |
| S28 | R-562 | Hungarian numbers and dates on the dashboard: decimal comma and `2026. 10. 10. 15:04` everywhere? | **Yes, Hungarian style in Hungarian, ISO-like in English** (CC, one controller session) | B (leave as is): pages disagree with themselves | Same as B |
| S29 | R-250 | A new customer's off-site setup can fail on its first try (the DNS/IPv6 settle is ~100 s, the scan waits 60 s) and says only „error". May CC fix it? | **Yes**: the scan prefers the IPv4 address and waits longer, and the error says „safe to press again" (CC, hub, attended deploy) | B (leave): the first thing a new customer's setup does can fail looking like an outage | Same as B |
| S30 | R-246 | The hub's `stale_at` column changes behaviour, but nothing sets it and nothing shows it. Retire it or give it a visible setter? | **Retire it** (CC, hub, small) | B (a visible setter with evidence): one hub session | A trap only a database read can spring |
| S31 | R-913 | The Cloudflare token check sees what a token can READ, not what it can WRITE. Which guard? | **(a) you mint every customer token from one recipe; the hub checks nothing more** (free) | (b) the hub mints the token itself with your account token — a new privileged secret on the hub | The check stays as built; the limit stays written in `01` §7 |
| S32 | R-521 | When a household's drive is unplugged, does the household get a mail too (today only you do)? | **Yes, one mail per lost drive in the household's language** (CC, hub + controller) | B (no): the household learns it only on the dashboard | Same as B; the hub's cooldown fix (F6/F7) is CC's either way |
| S33 | R-402 | What should the hub's host page say about the off-site integrity check (verdict + depth are sent, nothing reads them)? | **One line: „Last full check: OK/FAILED, depth N, date"** on the host page (CC, hub) | B (drop the two fields from the wire): a two-repo change | Two facts stay sent and unread |
| S34 | R-290 | 20 of 28 green capability-map rows cite no evidence file. Fold this into the map restructure (R-288)? | **Yes, fold** (one row closes) | B (fix row by row now): longer | Same as today |
| S35 | R-209a | DooPlex's SSD2 move has never been proven across a reboot, and you ruled „no reboot". Close as accepted until a planned reboot? | **Close as accepted**; the next planned reboot checks it (the mechanism is proven) | B (keep watching): a row nobody can act on | Same as B |
| S36 | R-769 | Add Pinchflat (upstream paused, no image tag)? | **No — close** | B (go via a fork): an unmaintained base | The idea waits |
| S37 | R-884 | ArgoCD shows Prometheus OutOfSync on DooPlex (cause unknown). May CC read the diff and propose git-or-live? | **Yes, read only first**, then one line for you | B (leave): drift stays unexplained | Same as B |
| S38 | R-616 | The catalog-clone credential leak is fixed and live (no box's clone holds a credential, read 2026-10-10). Was the Gitea admin token it exposed rotated in the R-925 work? | **If yes: close** | If no: rotate it (Gitea → Settings → Applications) | The row stays open |

### Your own tasks (no decision — something only you can do)

| # | Row | What is true now | What you do | Does it block the first paying customer? |
|---|---|---|---|---|
| T1 | R-789 | Tandoor is offered with no written yes from its authors | Ask the Tandoor authors for written permission for a paid service | **Blocks the first paying customer** — without a yes, CC hides Tandoor first (one catalog line) |
| T2 | R-802 | The non-OSI licence table has had no lawyer's review | Send `audits/licences-2026-10-02/TABLE.md` to a lawyer | **Blocks the first paying customer** (your ruling, decision 66) |
| T3 | R-784 | SparkyFitness's licence forbids commercial use without the author's written permission; it is offered today | Ask the author for written permission | **Blocks the first paying customer** — without a yes, CC hides it first (one catalog line) |
| T4 | R-813 | The legal pages are a closed-test version, unreviewed | When the company exists: the lawyer's review (with R-802) and the full ÁSZF + imprint | **Blocks the first paying customer** (with R-802) |
| T5 | R-923 | The break-glass sheet is not known to be printed | Print it, write the keys on it, store it away from home; say „done" | Before the first paying customer: losing DooPlex would lose the keys to its own off-site copy |
| T6 | R-924 | The two signing keys (sheet lines S6a, S6b) are not known to be printed | Print and staple them; say „done" | Not a hard block |
| T7 | R-504 | `iso.felhom.eu/` answers 404 | Add a Cloudflare redirect to `felhom.eu/letoltes` (5 min), or say „drop" | Not a block |
| T8 | R-779 | Phone sign-in over mobile data never proven | 2 minutes on your phone while CC reads the logs | Not a block |
| T9 | R-862 | Tester 2 lacks its one-time bootstrap step | When Tester 2 is on: the tunnel + three commands (`runbooks/config-bundle.md`) | Not a block |
| T10 | R-883 | 9 DooPlex Deployments + 1 Pod run a moving tag (one is Felhom's own contact-mailer) | Pin them in homelab-manifests | Not a block |
| T11 | R-814 | The old Storage Box #611421 (~€4/month) is still paid; ep0 does not mount it | Delete it in the Hetzner console | Not a block; costs money |
| T12 | R-917 | The first Facebook post goes out Monday 12 Oct 19:00 | After it goes out, pin it; CC reads it back | Not a block |
| T13 | R-902 | No source for the contact-mailer | Look for the February folder on your Windows machine; if absent, say so and CC rebuilds it | Not a block |
| T14 | R-433 | „Can the MAIN Storage Box account read single files from a snapshot?" — Hetzner said „should be possible"; nobody has tried | Read one file from a snapshot with the main account (or give CC a main-account credential for that one read) | Not a block |
| T15 | R-132 | The hub operator password was printed into a session transcript (2026-07-31, again 2026-09-18) | Rotate `HUB_PW` (after R-925's work) | Not a block |
| T16 | R-908 | An old Resend key sits in `homelab-manifests` history | Check in the Resend console that it is revoked | Not a block |
| T17 | R-232 | DooPlex's own backups: items (c)–(h) of the 2026-08-06 survey are still open | Your DooPlex list; say which you want CC to take | Not a block |
| T18 | R-882 | Longhorn's instance-manager can go stale and block volume growth | Before growing any volume: check the instance-manager's age (or have CC check it) | Not a block |
| T19 | R-919 | The rebuilt Facebook cover is not yet checked in the phone app | Upload the rebuilt cover, look at it in the Facebook app, say „whole" | Not a block |

Not on the sheet, on purpose: R-832, R-904 and R-920 are deferred by your earlier rulings; R-243 is a dated check (above); R-925 belongs to another session.

## Saturday 2026-10-10 (afternoon): two new apps in the catalogue, and one that was stopped

- **Grocy and LubeLogger are in the catalogue.** Grocy runs the household — what food is in the house, what
  runs out, the shopping list, the chores — and LubeLogger keeps the family car's services, repairs, fuel and
  costs. Both went through the whole 61-check list on the test machines; nothing was taken on trust.
- **Monica is NOT in, and that is the one thing I need you to decide.** It has had no release of any kind for
  seventeen months and no finished release for two and a half years; the branch its own README calls "the
  stable version" has not moved since May 2024; and the two commits that ended a 13-month silence add a notice
  saying the authors' own hosted service and all its data will be deleted at the end of December 2026, before a
  rewrite. Keeping it out costs us nothing we have today — no app covers a family address book either way, and
  Radicale already carries contacts to a phone. **You decided: keep it out.** Written up and closed
  (R-927) so it can be looked at again when the rewrite ships.
- **Two real faults were found and fixed before either app was offered to anyone:**
  1. LubeLogger **ships with no login at all**. On a default install a stranger who found the address could read
     the family's car records *and add to them*. I measured exactly that, and our install now turns the app's own
     login on from a generated password before the app answers its first request.
  2. Grocy **could not be updated**. Moving it from the previous version to the current one left every page
     showing an error, because the app keeps a settings file written at the first install and never updates it.
     Our install now rewrites that file at every start. The update works on both test machines after the fix,
     and the product's own "undo" was watched putting the old version back, with the data intact, before it.
- **The app count on the website moved from 56 to 58**, in both languages, everywhere it is stated.
- **One thing I could not finish and did not pretend to:** after a household removes an app keeping its backups
  and restores it, the password the app's page shows is no longer backed by anything the box stored. The data
  and the household's own login are fine — I checked both — but nobody has looked at what that page then
  displays. It is written down as an open item.
## Saturday 2026-10-10: released — the security hole is closed, and the kernel button shows

- **Hub 0.146.0 is live** (you asked for it). The System page now shows problems first, then what waits for your
  approval, then a short box table; the rest is under "Details". Checked live: the page opens, and today it says all
  four boxes need a look (three: root files older than the approved agent's; Tester 2: a restart and an old agent),
  nothing waits for you, and the Docker and Proxmox sets are still in test. Report: `REPORT-hub-system-page.md`.
- **Hub 0.145.0 is live** (you were present). One box's key could change another household's mail settings. Now it
  cannot: checked live with Tester 1's key against demo-felhom — refused (403); the same key for its own household —
  accepted. Nothing changed in either household.
- **Controller 0.305.0 runs on demo-hp, demo-felhom and Tester 1.** The agent did not change (still 0.154.0).
- **Also live:** a household's cleared mail address is deleted; a restored hub can start quiet; a backup no longer
  stops the apps while the box's other backup is still running.
- **„Approve kernel set" shows now, for 7.0.14-22** (your new rule: the newest kernel every demo box started
  healthily). Not clicked — that is yours.
- **Found on the way:** DooPlex's saved login for the image registry still has the old password (it changed
  yesterday), so builds cannot push until it is refreshed. I used a one-off login and destroyed it.

## Evening (2026-10-09): the system poster is in the repository, and staying true is now a rule

- **The poster you made is committed**, next to the architecture documents. I checked it for secrets first:
  **no addresses, no keys, no passwords** — the only "password" words on it are names of things ("the password
  manager", "the hub seal key"), and the one string that looked like a token turned out to be ordinary data
  inside the embedded font. It opens **with no internet at all**: the fonts and scripts are built into the file.
- **Your three Claude Design fixes are all in it** — the backup tier no longer carries a "WG" tag, the box-to-ep0
  arrow says "encrypted on the box, sent through WireGuard", and the household-keys sentence is a neutral note
  rather than a red "gap" box.
- **One thing on it was wrong and I corrected it.** The poster said the website is "served from DooPlex through
  Cloudflare". It is not: Cloudflare only answers the name, the traffic goes straight to your home connection.
  I measured it, and the privacy notice published this morning already says so — the poster would have
  contradicted the website.
- **The facts the poster was drawn from now live beside it** as a plain-text list, and there is a new rule: a
  session that changes one of those facts must update the list in the same commit, fix the poster's text if the
  change is small, or tell you here that the poster needs redrawing. A check warns when the list is newer than
  the drawing — **it never blocks anything**, because only you can redraw it.
- **Nothing needs redrawing right now.** My one correction was a text label, done in place.
- Also answered, an open question from the poster: **the boxes' reports do not go through Cloudflare.**
  `hub.felhom.eu` points straight at your home connection. One architecture document still said the opposite
  (it was written in July, before you had a public address) and now carries a dated correction.

## Afternoon (2026-10-09): the password manager is copied off-site; one page to print

- **Your password manager (Vaultwarden) now goes to ep0 every night**, with the code. You said yes. A test brought it
  back on a throwaway machine: it starts, with your 1 account and 797 items. Nobody opened the items.
- **The circle is broken only when you print the sheet.** The copy on ep0 opens with one key, and that key was only
  in the password manager on DooPlex. The sheet lists the keys to print, with the commands. It holds no value itself.
- **The signing keys now go off-site too** (your answer A). They were only on DooPlex, in no backup. The Sunday test
  proves each key still matches. Print them as well (lines S6a/S6b on the sheet).
- **Built, not released:** a household that clears its mail address gets it deleted on the hub (your answer A); a
  restored hub sends no mail until you release it; the backup no longer stops the apps when another backup is still
  running. Found and fixed on the way: one box's key could change another household's mail settings.

## Midday (2026-10-09): the code and the hub can now survive losing DooPlex

- **Every night at 00:20, all the code (Gitea) and DooPlex's secrets go to ep0, encrypted.** You said yes in chat.
  The key that writes the copy cannot delete or read old copies. Nothing changed on ep0.
- **Gitea was brought back from that copy on a throwaway machine** — the first real restore. All 10 repositories are
  there, the newest commits match, a file matched byte for byte, a login worked.
- **The hub was brought back from its copy into a throwaway k3s.** Same 4 customers, same 4 boxes, all 4 console
  passwords open. Found: a restored hub mails households at once. The test had no network, so nothing went out.
  The runbook now says so.
- **Every backup job on DooPlex now mails you when it fails.** A test mail reached the inbox.
- **You need to do one thing:** print the new key on paper (see the afternoon entry: the password manager runs on
  DooPlex, so it is not enough). If you do nothing, the copy on ep0 cannot be opened after DooPlex is lost.
- **Not copied on purpose:** the container registry (27.7 GB). The images rebuild from the code.

## Morning (2026-10-09): released, delivered, and four of your answers proven live

- **Last night:** demo-felhom took its new kernel; apps were down about 70 seconds. demo-hp took no kernel: a Secure
  Boot package blocked its Proxmox step. Fixed in the agent. The "Approve kernel set" button waits until both boxes run
  the same kernel.
- **A false "backup missed" alarm** came for demo-felhom at 05:00. The backup had run; the restart made the agent
  forget it. Fixed in the agent and seen working live.
- **Released and delivered** to demo-hp, demo-felhom and Tester 1: hub, agent, controller. You were present for the hub.
- **The ep0-copy clean-up job runs daily at 08:00 on DooPlex.** Its first dry run found a bug; a safety stop held, and
  nothing was deleted. Fixed. The first real run deleted nothing, as it should.
- **Proven live:** the hub buttons, "the box is off", the household health mail and the warnings in the household's
  language, and staying signed in after a restart.
- **The Cloudflare key check passed for all four stored keys** (you were present).
- **Still to prove:** the lost off-site copy alarm (Tester 1's next clean-up
  window, about 12 October), and the failed-restore hold (needs a scratch off-site store).

## Facebook is live (2026-10-09): the Page can now post in public

- **The Meta app is switched on.** Until today anything the Page posted was visible only to people with a role
  on the app — effectively nobody. It is now **Published**, so posts are public.
- What had been holding it up for a day was the terms page, which did not exist until this morning. I put both
  addresses into the app's settings, chose its category, and switched it over. **The app icon turned out not to
  be required** — Meta accepted it without one, so that item is off the list.
- **Nothing new was granted.** The app can do exactly what it could do yesterday; going live only changes who
  can *see* what it posts.
- **You can start posting whenever you like.** The two texts we parked — the long description and the four
  Messenger answers — were waiting on exactly this, and are ready to go out as posts.

## Website (2026-10-09): the header says the name once, and the footer links look like links

- The header showed „felhom.eu" twice: once baked into the logo picture and once typed beside it. Now there is
  one lockup — the symbol on its own, larger, with the name next to it **in the logo's own lettering**, not a
  typeface that merely looks similar. The footer's legal links now match every other link on the site, and no
  longer turn purple after you have read them once.

## Done and still owed (2026-10-09): the published password is dead for Gitea — but it still opens a dozen other things

Following up the finding below, I measured what that password actually was. It was **your Gitea admin login**,
published on the internet. That is push access to every repository — including the one the website is served from
and the one new boxes download their installer from. I rotated it, on your instruction.

- **Dead now:** the old password returns "unauthorized" at Gitea. The visitor counter and the health-check tool
  got fresh random passwords too. The hub no longer holds your admin password at all — it holds a **limited token**
  that can only read the things it needs.
- **I broke something briefly and fixed it, and you should know:** restarting the visitor counter to pick up its
  new password took **stats.felhom.eu down for about four minutes**. Not the password — that service had a memory
  limit it could run under for months but could never *restart* under. It is raised now, in the file as well as on
  the server, so the next restart works.
- **Still open, and this is the bigger half:** the same password is the admin password for about **a dozen other
  services** — Nextcloud, Paperless, Bookstack (that one is a *database* password), Tandoor, Calibre, qBittorrent
  and others. Rotating Gitea did nothing for those. Each needs its own new password.
- **Also:** a Gitea token of yours sits in plain text inside one local repository's settings, and I printed it to
  my own session while investigating. Worth replacing.
- **Your passwords are in a protected file on DooPlex** (`rotated-secrets-2026-10-09.txt`). Move them into your
  password manager and delete it.

## The finding itself (2026-10-09): passwords were sitting in a repository anyone on the internet can read

I found this while publishing the legal pages, not because I went looking — a security check flagged something
small in the new page, and following it led here.

- **What is true:** `gitea.dooplex.hu` answers to anyone, with no login, from anywhere on the internet. I proved
  that from outside your network, not just from DooPlex. One of the files it hands out is a manifest that
  contains **real passwords**, not placeholders: the visitor-counter's database password and app key, and the
  login for the health-check tool. I did not print or copy any of the values.
- **How bad:** not as bad as it sounds, and I want to be exact. These guard the **statistics and monitoring
  bits, not any household's data.** The database itself is not reachable from the internet — I checked. No
  customer box, no hub key, no backup key is in that file. But they are live passwords, publicly downloadable.
- **Your own runbook already says this must not happen** — "secret values are never committed to git" — so the
  rule is right and the repository is breaking it.
- **What to do, in this order:** (1) **change those passwords** — deleting them from the files changes nothing,
  the history keeps them; (2) decide whether that repository should be readable by strangers at all, bearing in
  mind the installer people download depends on something public; (3) then I move the values out properly and
  make the check refuse them in future.
- **I changed nothing.** Making the repository private could break the installer that new boxes fetch, and
  changing passwords on live services is yours to time. It is written up as a register item with the evidence.

## Legal pages (2026-10-09): the website finally says what it does with people's data

- **Two new pages are live:** <https://felhom.eu/adatkezeles> (what we do with data) and
  <https://felhom.eu/feltetelek> (what the free test is, and is not). Both in Hungarian, both short, both written
  for a household rather than a lawyer. Every page of the site now links them at the bottom.
- **You are named on them as a private person** — Nagyfenyvesi Viktor, with the e-mail address. **No home address
  and no phone number appear anywhere.** There is no company yet, and the pages say that plainly.
- **The contact form stopped telling people something untrue.** It used to say „the data is not passed to third
  parties". It is: the mail services carry the message. The new text says so, and links the notice.
- **The pages promise nothing we cannot do.** Where there is no deletion deadline today — website statistics,
  server logs, your e-mails to us — they say there is none, instead of inventing a date. Where a deadline is real,
  it comes from the configuration, and for the 30-day backup deletion I checked the job actually ran this morning.
- **Four things I measured rather than believed:** the site sets no cookies at all; the visitor counter sends no
  identifier for you; Cloudflare only answers the name, our traffic does not go through it; and the backup storage
  is in Falkenstein, Germany. These are the claims the notice stands on, so I did not take anyone's word.
- **Your next click (2 minutes, unblocks the Facebook app):** Meta app → Basic settings → Privacy Policy URL =
  `https://felhom.eu/adatkezeles`, Terms of Service URL = `https://felhom.eu/feltetelek`. **Switching the app to
  Live is a separate decision, and still yours.**
- **Still waiting, and not published:** the full ÁSZF and the impresszum — both need company details that do not
  exist yet — and **no lawyer has read any of this**. That was your decision, and it is the right way round: an
  honest notice now beats no notice at all. When the company exists, the lawyer's review comes with it.
- The two parked Facebook texts (the long description, the four Messenger answers) stay parked until posting
  starts, as you chose.

## Facebook Page (2026-10-09): the details box filled in — and two things Facebook simply will not allow

- **Your e-mail and phone were already on the Page** when I looked — you had set them yourself. I checked the
  values are the right ones (`info@felhom.eu`, the address the website uses) and left them alone. The place is
  „Budapest" as you asked, with no street address.
- **The Page now carries three labels instead of one:** Informatikai vállalat, Internetes cég, Szoftvercég. Only
  the first is shown on the Page — that is how Facebook works — the other two help people find you in search.
  There is no „IT support" or „cloud" label in Facebook's Hungarian list at all; I looked under eleven different
  words. The only real „computer help" label is „Számítógépszerviz", a repair shop, which would be misleading.
- **The Page will never show „Zárva".** Facebook will not let opening hours be set without a street address, and
  we are not giving one. That sounds like a problem and is actually the result we wanted: with no hours set, no
  „closed" sign ever appears. I checked the live Page to be sure rather than assuming it.
- **The four Messenger questions have nowhere to go (needs you, 2 minutes to decide).** Facebook has removed the
  „Gyakori kérdések" feature from this Page — there are exactly three automation types left and none of them is
  it. The four questions and answers are written and saved, taken word for word from the website's FAQ. This is
  the same thing that happened to the long description. Best use: publish them as a post once the app is „Live".
  If you do nothing: Messenger keeps answering with the welcome message alone, which is fine.
- **A small one I chose not to force:** Facebook has a „service area" field but will not accept „Magyarország",
  only towns. I left it empty rather than putting „Budapest" in, which would have told people you only serve
  the capital.
- **Sharing a felhom.eu link looks right** — correct title, text and picture, in Hungarian and in English. I
  refreshed Facebook's stored copy of both.
- Nothing posted, no advertisement, no money, no change to the app, the business or the website.

## Facebook Page (2026-10-08, evening): the Page is set up — it now answers at facebook.com/felhom.eu

- **Done tonight, through your own Chrome:** the short introduction is the new text; the button at the top of the
  Page says „További információ" and opens felhom.eu; someone who writes to the Page on Messenger now gets our
  welcome message automatically; and the Page has a name of its own — **facebook.com/felhom.eu**. You typed the
  password Facebook asked for; nothing else needed you. Each change was read back from a second place to be sure
  it really saved.
- **One text has nowhere to go (needs you, 2 minutes to decide).** The longer description we wrote cannot be put
  anywhere: Facebook has removed the long-description field from Pages — it is not in the Page, not in Business
  Suite, not in the settings. The best use for it is to publish it as the Page's first post once the app is „Live"
  (below). If you do nothing: the Page carries only the short introduction, which is fine, and the long text waits
  in the file.
- **On a computer the pictures look right** — the cover is shown whole, nothing is cut, and the round profile
  picture does not cover it.
- **On a phone the cover is cut, and we should fix it (needs a short job from me, then 2 minutes from you).**
  Facebook shows phones only the middle 57 % of the cover's width. That is narrower than we built for, so the
  first letter of a line is lost: the cover reads „aját szabályaid" instead of „saját szabályaid", and „elhom.eu"
  instead of „felhom.eu". Nobody saw this before because a normal browser window cannot show Facebook's phone
  layout; it took a phone simulator. I did **not** re-crop anything on Facebook. The fix is to rebuild the covers
  with a narrower safe middle, then you upload the new one by hand. If you do nothing: every phone visitor sees
  the cut headline.
- **Before real posts:** switch the Meta app to „Live". It needs a Terms of Service web address (the legal pages
  item). If you do nothing: posts are seen only by people with a role on the app.
- **When you have time:** the logo needs a clean vector copy, made on the machine that has its fonts. If you do
  nothing: the pictures stay as they are; large prints of the logo will be soft.
- Nothing was posted. No advertisement, no boost, no money, no change to the app or the business.

## Evening (2026-10-08): your ten answers (D1–D10) built — they ship tomorrow

- **Buttons in the hub** (D1): run an off-site backup now, run one of four checks now, stop or extend a household's
  deletion countdown. The list is fixed. No button deletes anything or shortens a countdown.
- **A switched-off box can be deleted at once** (D2), after you tick „I checked: the box is off" and the hub has heard
  nothing from it for 6 minutes. The host page shows when the box was last connected.
- **The household's „system health" mail is short** (D3): no technical note; it points to the dashboard. The dashboard
  shows every health warning in the household's language.
- **The household stays signed in** when the box restarts or updates (D4). The disk keeps only a fingerprint.
- **opengist's item is closed** (D5): the address block is enough.
- **The hub checks a pasted Cloudflare key** (D6): it must reach exactly that customer's own domain.
- **One lost off-site copy outside a clean-up window = an error mail to you** (D7).
- **A failed restore of one app keeps the app stopped** (D8) when its version or its data volumes already moved, and
  the page says it needs our help. „Put back exactly as it was" is the next step (on the list).
- **wger needs 256 MB to install** (D10). Live in the catalog; no box runs wger.
- **D9 (the DooPlex clean-up job) is tomorrow**, after the releases are read back.
- Security checks read every change. Ten problems were fixed and tested the same evening. Two stay as written limits
  (one is the cost you accepted with D2; files alone wait for D8's next step). One needs you (decision 1 below).

**Needs you:** two decisions at the end of `REPORT-day3-2026-10-08.md`.

## Afternoon (2026-10-08): your four answers built, and one sheet of decisions

- **The FAQ is honest now** (you approved the text): it says where backup copies and remote traffic go. Live.
- **Deletion times:** the hub deletes a removed customer's mail and event records 1 year after the deletion (ships
  tomorrow). The job that removes a removed customer's copy on DooPlex within 30 days is written and tested, **not
  installed** (see D9). Both times are in the privacy-notice draft.
- **You get a mail when a household's code opens, or may open, an old package** (ships tomorrow).
- **Cloudflare:** on the list as a later item.
- **Nine stuck items have a one-page design.** Two were no longer true and are closed; one lost item is back on the list.

### The decision sheet — ANSWERED 2026-10-08 14:16, all as picked (`09` §3 decisions 185–194)

| # | Question | Pick | Cost | If you do nothing |
|---|---|---|---|---|
| D1 | May the hub (with your password, no signing key) ask a box to run an off-site backup now, run a named check now, and stop or extend a household's deletion countdown? | Yes — a fixed list of safe, repeatable actions, carried in the box's report reply | ~1 session, controller + hub | A household calling in the first 14 days of a countdown needs a shell on its box; only the household can start an off-site run |
| D2 | When the hub has had no connection from a box for ~6 minutes, may „delete host" go ahead at once after you tick „I checked: the box is off"? | Yes (step 1, showing the live link on the host page, needs no answer) | ~½ session, hub | Deleting a switched-off box (and a reset) waits up to 45 minutes after its last report |
| D3 | May the household's „system health" mail drop the raw technical note and point to the dashboard for the list? | Yes (the dashboard half needs no answer; CC builds it) | ~1 h hub + a hub release | The mail keeps a curly-bracket note with English lines in it |
| D4 | May the box remember a dashboard sign-in across its own restarts (on disk only a fingerprint that cannot be used to sign in)? | Yes | ~½ session, controller | The household is logged out at every settings push and every controller update |
| D5 | Is the measured address block enough for opengist's sign-up, or should the box also close opengist's own switch? | Enough — close the item | Nothing | Same as the pick: the item closes |
| D6 | Should the hub check with Cloudflare that a pasted key reaches only that customer's own domain? | Yes (the „no duplicate or nested domain" guard needs no answer; CC builds it) | ~½ session, hub; a save fails while Cloudflare is down | A key made for the whole account by mistake could change every household's web addresses |
| D7 | Should the hub mail you an error when even one off-site snapshot disappears outside a clean-up window it opened? | Yes | ~½ session, hub | A deletion through any other key stays silent unless it removes over half of a household's history |
| D8 | After a failed off-site restore of one app: keep the app stopped for support now, and „put back exactly as it was" next? | Yes, both, in that order | ~½ session now; ~1 session + a test + disk space for one copy later | The app restarts on a mix of old files and a newer database, and the screen says all is back as it was |
| D9 | May CC install the DooPlex job that removes a deleted customer's copy (dry run first, then daily)? | Yes, after tomorrow's releases are read back | ~30 min; one new local token on DooPlex | A deleted customer's copy stays on DooPlex, and the privacy-notice line „within 30 days" is not true |
| D10 | wger's install check still assumes 100 MB; measured 250 MB with its proper server. Raise it to 256 MB? | Yes — only boxes with room can install it | One line in the catalog; a box short of memory can no longer install wger | The install check lets wger onto a box that cannot hold it (wger is hidden today, so no one meets this yet) |

Full designs: `documentation/audits/day-2026-10-08/`.

## Day (2026-10-08): fixes built for tomorrow, the old-code answer made honest, legal drafts

- **A daytime "back up now" no longer cancels the night** (your answer A). Built and tested; it ships tomorrow.
- **The old recovery code:** when the box could not try every older package, the screen no longer says the code is
  wrong. It says "we do not know" and sends the household to you. Ships tomorrow. A one-page plan has two questions.
- **New alarm:** a box with off-site on and the key step never done now mails you after 7 days. It ships tomorrow and
  will fire once for Tester 2 (its key step was never done).
- **DooPlex's own backup now mails you when it fails** (your yes). One test mail reached your inbox.
- **wger's proper web server works on the test bench** (44 % of its memory, no crash, pages and photos load). The second
  test, on the scratch box, was stopped: it needs a write to the shared test catalog that the system refused.
- **Legal pages: first drafts only**, not published: terms, privacy notice, imprint, and the contact-form consent text.

**Needs you:** see the two decisions at the end of `REPORT-day-2026-10-08.md`.

## Day (2026-10-08): the website catches up, and speaks English

- **Every claim on the site was checked against what the product really does.** Wrong numbers fixed (56 apps, not
  53 or "more than 45"). Claims nothing backs were cut (firewall, RAID, "never lose anything", a self-managed mode,
  a household VPN). What shipped since July was added (three backup levels, careful app updates, English dashboard).
- **"100% open source" was not true:** Plex and Emby are closed; five others have limits. Each now has its own badge.
- **The ten missing apps are on the apps page**, with logos and pictures. Two apps the box no longer offers are gone.
- **Every page has an English twin at felhom.eu/en/**, public now (your choice B). A small "English" / "Magyar" link
  in the menu goes to the same page in the other language.
- **A missing-page (404) page exists now.**
- **The language link is now a globe icon**, like the dashboard's: a click shows „Magyar" and „English".
- **The website now shows the dashboard**: four real pictures on the home page (and two on the technology page), Hungarian on Hungarian pages, English on English ones. Two small dashboard defects were filed.
- **Three dashboard layout fixes built and tested (ship with tomorrow's controller release):** on the Apps page the status tags no longer cover an app's name and every logo sits at the same height; on a phone the Launcher's share button gets its own line; a page no longer says „+5 more warnings" with nothing above it. The website's dashboard pictures are retaken after the release (R-910).
- **One picture viewer for the whole site:** the dashboard pictures open like the app pictures, and a click on the big picture closes it.
- **The contact form's lost program code was searched for everywhere I can reach: not found.** The running program is now saved in git, so it cannot be lost. A plan for a replacement is written. One question for you: is the February folder on your Windows computer?

**Needs you:** two choices in `REPORT-website-refresh.md`. If nothing: SparkyFitness stays listed; the contact
mailer's source stays lost.

## Morning (2026-10-08): the first real kernel night, read back

- **demo-felhom passed.** It restarted at 04:39 into the new kernel it was told about, was healthy in 38 seconds, and
  kept it. Apps away about 1.5 minutes. No alarm.
- **demo-hp did not restart.** Its nightly full backup did not run, because yesterday's daytime "back up now" press moved
  its 24-hour clock past the night. Nothing changed on it. It should go tonight (filed as a small item).
- **The reply address works:** your test reply went to admin@.

**Needs you:** one choice on the backup clock (see `REPORT.md`). If nothing: a daytime press costs one night.

## Tonight (2026-10-07 → 08): the first real kernel night

- **Both demo boxes restart tonight** for a new kernel; both households were mailed (18:12 and 18:38).
- **Three fixes went in first:** the box takes exactly the kernel named in the mail; the first backup after a restart
  waits for the drive; a household's reply goes to your address.
- **Tomorrow morning:** read back the night — new kernels, apps back, no false backup failure.

**Needs you:** press Reply on the „TEST — Reply-To check" mail once (it should go to admin@). If nothing: untested by eye.

## Evening (2026-10-07): the kernel lane is built

- **A new kernel boots once.** If it crashes, the box comes back on the old kernel by itself. If it boots well, it
  becomes the default. If it boots but the box is not healthy within 20 minutes, the box restarts once into the old
  kernel by itself. All three were proven on the Tester 1 box today.
- **The household is mailed the day before**, between 9:00 and 20:00, in its language. No mail → no restart.
- **You approve each kernel** on the System page after both demo boxes booted it well at night.
- **Tonight:** demo-felhom's household was mailed, but for yesterday's kernel; the box will safely refuse it, because a
  newer one appeared. Tomorrow both demo boxes are due for the newest kernel (filed as a small item).
- **Found:** after a restart, the first backup can fail for one app on a drive (the drive is being re-attached). Filed.

**Needs you (none urgent):** read the household mail text in `REPORT.md`. If nothing: it stays as written.

## Day (2026-10-07): your answers built, and the kernel test with real reboots

- **Proxmox now updates its own programs** after your approval of each set: tested on demo-felhom (65 packages, 70 s,
  the apps never stopped).
- **The box's helper can start only our own controller image** now; a strange image is refused.
- **RESET now deletes the household's off-site folder.** The old leftovers (~2.7 GB) are NOT deleted yet: that needs the
  pool box's main login, which this server does not have.
- **After a reinstall you get one line** when old backups use another key. Two never-built hub fields are removed.
- **Kernel test, 24 reboots and your 2 power cycles:** a new kernel that crashes falls back to the old one by itself, on
  all three boxes (two ways work). A kernel that FREEZES needs a person — the watchdog did not help on any box.

**Needs you (none urgent):**
1. May a box restart at night for a kernel update, and do we tell the household? My pick: yes, with a mail the day
   before. If nothing: kernels stay manual.
2. The pool box leftovers: delete them in the Hetzner console, or give me the main login once. If nothing: they stay.

## Morning (2026-10-07): read back, released, delivered — and the Tester 1 test passed

- **The shorter backup stop works.** Last night the apps on demo-hp were down about 1.5 minutes (it was almost
  6 minutes before). One press of „Mentés most" stopped them for about 1 minute. The page tells the truth.
- **Released and delivered to all three boxes:** hub 0.141.0, agent 0.150.0 (with its root files), controller 0.302.0,
  and the night's catalog fixes. Tester 2 was not touched (it is off).
- **The update test ran on the Tester 1 box with you present:** vaultwarden updated in 14 seconds, the test account
  survived, and the box is back as it was.
- **New rule:** every helper gets the full fence list, word for word.

**Needs you (none urgent):** the six one-page designs from the night (each has one question). If nothing: they wait.

## Night (2026-10-06 → 07): the second burn-down night — fixes on main, nothing delivered

- **Fixed in code, waiting for today's releases:** the box remembers its last backup after a restart; a reinstall
  keeps the old backup key; two quick off-site saves no longer make two accounts; the format list hides drives in use;
  22 more messages in the household's language; three more disk-health counters reach the hub.
- **Jellyfin and Emby** let an internet stranger sign in as if at home — measured and fixed on a held catalog branch.
- **Six one-page designs**, each with a pick and one question for you.
- **Did not work:** the Tester 1 update test (the key works now, but the box's dashboard password is not on this server); the hub release was
  refused by the session's safety check, so the hub is unchanged.

**Needs you (none urgent):**
1. Release order today: hub, agent, controller, then the catalog branch. My pick: yes, after Parts B and D.
2. The Tester 1 box: key and dashboard password are ready (password in `/home/kisfenyo/.felhom-tester1/.ctlpw`); the update test was refused by the session's safety check — the day session runs it.

## Night (2026-10-06): the night-free parts done; the rest after 08:30

- **demo-hp's off-site copy is NOT 10 days old** — my last report was wrong (I read a cut log). Its last off-site copy
  is from 2026-10-01; every box is within its 7 days.
- **One alarm was lost:** a failed off-site try on 2026-10-05 reached the hub, but its mail to you failed and was never
  sent again. **Fixed:** the hub now retries a failed mail. The try itself should not have happened (a design question,
  on the list).
- **The Docker update now needs a memory-kill proof** before you can approve a new set (your answer). The hub part is
  live; the box part ships tomorrow after the night read-back.
- **The Tester 1 box:** found and matched (the VM on the HP box), and the test tool knows the route. It cannot log in
  yet: my key is not on that box. See below.

**Needs you (none urgent):**
1. **R-892** — put DooPlex's SSH key on the Tester 1 box (one line, from its console), or allow me to read its
   vaulted password. Then the update test runs there. If nothing: it stays on the scratch box only.

## Evening (2026-10-06): the designs built; the list at 137

- **Safer restores:** measured first — restoring a copy after an app update brings back exactly the old database (docmost
  and romm). Two rarer restore paths now load the database before the app starts.
- **Shorter backup stop:** each backup copy now gets its own short stop, and the button makes the local copy only; the
  off-site copy follows at night. **Not yet seen live** — the first night run on the demo boxes is the proof.
- **Family sign-up window:** wishlist's own sign-up now closes after setup and opens for the 15-minute window (proven
  live). Opengist cannot do this yet.
- **wger** shows its styles and photos now (proven). It stays hidden: it still runs a development web server.
- **Out-of-memory alarm: not built.** Today's Docker reports the memory kills correctly, so the design's reason was
  gone. Your choice below.

**Needs you (none urgent):**
1. **R-528** — build the memory-kill alarm anyway? (A) No: keep watching for a box where Docker misses a kill (my pick).
   (B) Yes, as insurance (about 1.6 s of work every 5 minutes on a full box). If nothing: nothing is built.
2. **R-892** — where does the Tester 1 box run, and may CC reach it by SSH? Then the update test can run there too. If
   nothing: the update test stays on the scratch box only.

## Afternoon (2026-10-06): your two answers built; the list at 137

- **New standing rule (your answer):** a session now fixes a wrong fact in an instruction file by itself and lists the
  change in its report. It still may not loosen a safety rule. The rule is in all four copies of the shared rule file and
  in the brief template. No permission prompt came up.
- **The wrong line is fixed**, and twenty-five more wrong facts across the four repos (gate lists, paths, counts).
  Every edit is listed in the report.
- **Vaultwarden is on the update list:** its first step (1.36.0 → 1.37.4) passed on the test bench and on the scratch box,
  using the admin seed you allowed. No box runs vaultwarden today, so no household gets it now.
- **wger's two fixes are proven** on the scratch box: a stranger cannot sign up, visits make no guest accounts, and mail
  works when switched on. wger stays hidden: it still shows no styles or photos.

**Needs you (none urgent):** *(answered 2026-10-06 14:24 and done)*
1. **R-469** — the catalog's database-version check cannot be removed any more: it is now how decision 35's per-app
   proof is enforced. (A) close the row and keep the check (my pick), or (B) keep the row open. If nothing: the row
   stays open; the check works either way.

## Midday (2026-10-06): your ten answers built; the list at 142

- **All ten are done** (your „A" on each). Released to demo-hp, demo-felhom and Tester 1: hub 0.139.0, agent 0.149.0 (and
  its root files), controller 0.300.0 and a new install image.
- **The weekly disk trim works:** measured by hand first (the disk pool went from 65 % to 33 % full, the apps did not
  notice), then the box's own weekly job trimmed by itself, and the System page shows it.
- **No broken backup leftovers exist on the backup server today**, so nothing was deleted. The steps are written down
  for the day one appears.
- **Three of your answers differed from my picks (2, 8 and 9).** Your answer governs, and each is recorded.

**Needs you (none urgent):** *(both answered 2026-10-06 13:25 and done)*
1. **R-890** — a vaultwarden update can still not be written to the update list: the list needs a proof on the scratch box
   too, and your ruling keeps the admin password on the test bench only. Pick: allow it on scratch box 9202 as well. If
   nothing: vaultwarden updates stay manual.
2. **R-891** — one line in felhom.eu `CLAUDE.md` is now untrue (it says the quick test run covers every check; the new ISO
   test runs only in full runs). Only you may edit that file.

## This morning (2026-10-06): your two answers done; the list at 150

- **Installer 1.32.0 is published.** The public script reads 1.32.0 and is byte-identical to its tag.
- **The box shows the real disk use** (the number `df` gives). demo-hp's SSD went from 21 % to 23 %, the same as `df`.
  Alarm levels are unchanged, so a full disk alarms a little earlier. Released as controller 0.299.0 to all three boxes.
- **The four waiting app fixes passed on the scratch box and are live** (visitor addresses for kimai, zipline, vikunja,
  nextcloud; nextcloud's health check). Each was tested against a control.

## Tonight (2026-10-06): the list at 164

**What happened:** 36 rows closed, 1 opened. Released and delivered the normal way to demo-hp, demo-felhom and Tester 1:
hub 0.138.0 (secrets in the hub database are sealed; checked on a copy: none readable), agent 0.148.0 (+ its root
files), controller 0.298.0 and a new install image 0.298.0. The app catalog was updated. Six small decisions were taken
by CC unattended (`09` §3 decisions 131–136); each can be reversed.

**Needs you (none urgent; if you do nothing, each stays as it is):** *(items 1 and 2 answered 2026-10-06 07:45 and done; item 3 is the table above)*
1. **Publish installer 1.32.0?** Nine uninstall/pre-flight fixes wait on `main`. If nothing: new installs keep the old
   installer. Pick: yes.
2. **R-889 — the disk percentage** reads ~5 points low (not `df`'s formula), so fill alarms come late. Pick: use `df`'s
   number and keep the alarm levels.
3. **Ten rows need your answer** and **seventeen need a design** — listed in the morning note, section 6.
4. Still open from before: R-469 (one paragraph in the catalog's instruction file), R-887 (CI runner fetch timeout:
   2 more lost jobs tonight, both re-run green), R-831/R-870 (printed tokens), R-616's Gitea admin token rotation.

## Before that (2026-10-05, round 2): the list at 199

**What happened:**
- **Your answer is recorded** (below): 43 rows closed as accepted.
- **51 more rows fixed and closed**, with one release per repository, delivered the normal way: hub **0.137.0**
  (live), agent **0.147.0** (on demo-hp, demo-felhom and Tester 1, root files too), controller **0.297.0** (on all
  three), new-install image **0.297.0** (baked, checked, approved), app catalog updated.
- **R-124 is fixed** (your ruling): the recovery recipe now writes the backup-server namespace the way the server reads it.
- **The CI fault (R-887) is understood:** when Gitea is busy, the CI runner's request for work can time out after Gitea
  already gave it the job; the job is then never run and is failed 10–13 minutes later. Gitea was busy because of an
  outside web crawler and because of MY CI checks, which asked too much — mine now ask once a minute in one small request.
- **Two of my own CI misses tonight:** a new check needed Go, which the CI machine does not have (fixed); a red run was
  the fault above (re-run passed).

**The numbers:** 292 before → **199 after**; 1 opened; 94 closed.

**Needs you (none urgent; if you do nothing, each stays open as it is):** *(items 2, 3 and 5 were answered by the reviewer's picks at ~21:00 — `09` §3 decisions 128–130 — and built or closed the same night)*
1. **R-469** — a one-paragraph rewording in the app catalog's instruction file; my permission check refused editing
   instruction files. Say "go" and it is done in a minute.
2. **R-126** — should a network share be offered as an export destination? Two options in the row; pick one.
3. **R-888** — two facts the boxes report that the hub never shows (installed-app list, retired drives). Needed or not?
4. **R-887** — CI: raise the runner's fetch timeout and/or slow the crawler on Gitea's public pages. If nothing: now and
   then a CI run fails without running; it can be re-run.
5. Three more rows look „not worth doing" (R-337, R-375, R-542 — the check found each is by design or harmless). Close
   them as accepted? If you say nothing they stay.

## Your answer to the burn-down list (2026-10-05 18:23), recorded

- **43 rows closed as accepted by you**, each with its reason from the list.
- **R-124 stays open and is fixed in this session** (a recovery step that fails during a real recovery).
- **R-698 stays open as a known risk** (a backup keeps an app's image name, not the image). It is yours; nobody works on it now.
- **R-831 and R-870** (the printed tokens) stay as they are, by your earlier rulings; the rows keep their steps.
- **R-887** (the CI jobs that never ran): your screenshot shows ONE runner, online. My „old copy of the runner" guess was
  wrong; the row says so.

## Tonight, later (2026-10-05, night): the list got shorter

**Decisions:** none of mine.

**What happened:**
- **Every lower-priority row was checked against today's code** (317 rows). 24 described problems a later change had
  already fixed; 2 were duplicates. Those are closed, each with the change that fixed it.
- **19 small rows were fixed and closed** in four repositories — wrong comments and documents, missing tests, gates that
  checked less than they claimed. No release was needed: nothing that runs on a box or on the hub changed.
- **One real fix found on the way:** the hub's build script pushed a `latest` image tag on every release. Nothing used
  it; it is gone, and a test keeps it gone.
- **You got 5 „CI failed" mails tonight — my fault, fixed.** The new test gate ran one of today's test suites on the CI
  machine for the first time; it uses a different `date` tool, and 9 tests failed. Fixed; CI is green again (job 1360).
- **A separate CI fault on DooPlex (new row R-887):** two CI jobs were never run and were marked failed after ~10 minutes,
  with no log and no mail. (The „old runner copy" guess was wrong — see above.)
- **A new rule, so the list stops growing:** a small problem found during work (about 30 minutes) is fixed in that
  session and never added to the list. Every report now states four numbers: rows before, after, opened, closed.

**The numbers:** 336 before → **292 after**; 1 opened (the CI fault below); 45 closed.

## Tonight (2026-10-05, evening): the hub database off DooPlex; the cut-backup check on the scratch box

**Decisions:** none of mine. Yours (`09` 125–127): ep0 for the copy; the scratch-box restart allowed; the agent's three
by-design abilities stay. Today you also chose: grow the hub's disk to 2 GiB, and restart Longhorn's disk manager.

**What works now (proven live):**
- **The hub makes a clean copy of its database every night at 02:00** (hub 0.136.0). The first one: 353 MB, 44 s.
- **DooPlex checks it, locks it with a key ep0 never sees, and sends it to ep0 at 02:30.** First send: 7 s.
- **Every Sunday at 04:30 DooPlex takes the copy back from ep0 and checks it**: it opens, it is whole, every console
  password in it is still locked. Done once by hand today: 4 boxes, 4 locked passwords, 0 readable.
- **The two ep0 accounts can only do their one job:** the sending one cannot delete, the checking one cannot write,
  neither can see the households' backups. (The sending one can read back its own locked copies — that is how ep0 works.)
- **Your two saved keys work:** a key rebuilt from the paper copy you saved opened the copy, and your saved lock key
  opened all 4 console passwords in it (a wrong key opened none).
- **The alarm:** proven by Prometheus' own rule test; the real alarm mail is below.
- **A backup cut off by a restart is now said on the backup pages** (scratch box): the page said so, the restore point
  kept the older time of the part that was not redone, and the next full backup cleared the message.

**What broke, and what I did:**
- **The hub's disk would not grow:** Longhorn's disk manager on DooPlex was stuck. My first try (stopping the hub so the
  disk could grow offline) did not work and kept the hub **down about 9.5 minutes**. You approved restarting the disk
  manager: all 77 disks were back in under 2 minutes, and the hub's disk is 2 GiB now.
- **Zipline did not come back after that restart:** it is set to "always the newest", so it pulled a new release that
  refused its database. I pinned it to the previous release; it runs and its database is updated. 7 more apps on
  DooPlex use "always the newest" (new row).

- **The alarm mail:** I hid the "copy sent" signal on purpose; after 30 minutes the alarm fired (14:22) and the mail
  system sent it without error; a real send cleared it a minute later. **You confirmed both mails arrived:**
  "[FIRING] HubDBBackupStale" 16:22 and "[RESOLVED] HubDBBackupStale" 16:27.
- **The mail system (Alertmanager) cannot save its own notes since the Longhorn restart.** Mail still goes out; but a
  silence you set would be lost at its next restart (new row).

**Register:** 332 → 336 rows (1 closed: the cut-backup check; 5 opened: the Longhorn fault, the "always newest" apps, a
monitoring sync drift, script tests not in CI, the mail system's notes).

**Needs you:**
1. **Nothing urgent.** If you do nothing, the copy runs every night and you get a mail only if it stops.
2. **When convenient:** pin the 7 other DooPlex apps that use "always the newest" (or tell me to list them for you). If
   you do nothing, any restart may upgrade one of them by surprise, as it did zipline.
3. **Tester 2's one-time step** is unchanged (below).

## Today (2026-10-05, late afternoon): the hub's own safety; boxes left behind; the agent's admin rights

**Decisions I took myself (you may reverse each — `09` decisions 119–124):**
- A box behind the approved agent for 7 days raises an alarm to you; a global version raise that cannot move a box
  sends you one mail naming it.
- Scripts that post to the hub with the password must now send one extra header; a web page on another site cannot.
- The console passwords are locked with the same key as the off-site passwords (one key to keep safe, not two).
- The agent's rights are narrowed with exact rules and one checking helper, not one helper per command.
- A cut-off backup is shown on the backup page until a backup runs all the way through.
- A new agent whose root files add a file is delivered in two signed steps (the old box would refuse it in one).

**What works now (proven live):**
- **Form protection:** a password post without the header is refused (403); a browser on another site cannot add it.
- **Console passwords locked:** all 4 were sealed at the hub's start; the demo-hp one still opens its Proxmox (checked).
- **Boxes left behind:** the System page lists the three per-box version floors and shows Tester 2's agent 4 releases
  behind. The alarm and the mail are proven by tests only (they need 7 days / a global raise).
- **The agent cannot make itself root any more:** before, the real sudo let 23 of 29 attack commands through; now 0, on
  demo-hp and demo-felhom, and every agent feature still passes its check (67 of 67) on all three boxes.
- Agent 0.146.1, controller 0.296.0 and hub 0.135.0 on demo-hp, demo-felhom and Tester 1; new-install image 0.296.0.

**Found today:**
- **The hub database is backed up — but only inside DooPlex**, and only because a hand-set label says so; nothing tells
  anyone if that backup fails. (Your decision below.)
- **A new agent's root files could not reach any box in one step** (an older box refuses files it does not know). Fixed
  with a two-step delivery; written down for next time.
- **A security review of my own agent change found three holes** before it went to any box; fixed in a second agent
  release (0.146.1). Two agent releases today, against "one per repo" — the first was never sent anywhere.
- **The backup page already said "about 8 minutes"**, not "a few seconds". Measured today on demo-hp (9 apps): about 6
  minutes. Both figures are on the page now.

**Needs you:**
1. **(DECIDED 2026-10-05 evening: A, done — see Tonight)** **Where the hub database's off-site copy goes** (it holds every box's keys and your customers' settings):
   - **A — my pick: ep0's backup server**, encrypted on DooPlex before it leaves, with a weekly restore test and an
     alarm mail. Costs one small change on ep0 (a write-only account) and keeping two keys in your password manager.
   - **B: a separate Hetzner Storage Box account** with restic. More new parts to look after than A.
   - **If you decide nothing:** the database stays only on DooPlex. A fire or theft there loses every box's console
     password, the escrow records and the customer settings; each box would need re-pairing by hand. Steps:
     `documentation/runbooks/RUNBOOK-hub-db-offsite-backup.md`.
   - **Either way, first:** put the hub's lock key (`OFFSITE_SECRET_KEY`) in your password manager — without it a copy
     of the database cannot open the console passwords.
2. **(DONE 2026-10-05 evening — see Tonight)** **The power-cut-during-backup check (R-519) on the scratch box:** the permission check refused my restarting the
   controller in the middle of a backup. Say "go" and the next session does it once on 9202; if not, the fix stays
   proven by tests only.
3. **Three things the agent can still do, by design** (each written in `03` §3.1): pick which controller image its own
   guest runs; install the operator SSH key for the limited `felhom-op` user; see the box's backup key during the
   recovery-code ceremony. If you do nothing, they stay as they are until before the first paying customer.
4. **Tester 2's one-time step** is unchanged (below).

## Earlier today (2026-10-05, afternoon): a box that is not always on; the self-repair after a power cut

**Decisions I took myself (you may reverse each — `09` decisions 112–118):**
- The make-up run starts 15 minutes after the box comes back; a backup due within 30 minutes is left to its normal time.
- A laptop that sleeps through the night: a nightly job that wakes up more than an hour late is skipped (otherwise app
  updates would start at noon); the backups are made up instead. Tested, not measured (I may not suspend a box).
- The banner appears when the last backup is over 26 hours old; it suggests the latest evening hour the box is usually
  on (5 of the last 7 days), and nothing when the box is usually on at its backup time.
- A box that is off at the 05:00 check now raises the missed-backup alarm after 2 nights without a database backup (3
  without a whole-box backup) — not after one, so a box that broke last night gives only its "offline" alarm.
- The household hears "your server cannot be reached" at most once a week; you still hear every one.
- The restore-test's first check is 30 minutes after the agent starts (a box on for short times now gets tested).
- The update's repair step now also looks at dpkg's journal — the place the power cut left its mark.

**What works now (proven live):**
- **A missed night is made up once** (your choice A): the scratch box and demo-felhom were off across their backup time;
  15 minutes after they came back, the missed backups ran by themselves (seconds). The household's timeline got one line:
  "Kimaradt mentés pótolva: a doboz ki volt kapcsolva 10:07-kor, a mentés most elkészült." No mail.
- **The banner** (your idea) appeared on the scratch box, with the "change the backup time" button; "Close" kept it
  closed. *No screenshot: there is no browser on DooPlex; I captured the page as the box served it.*
- **The power cut, again** (demo-hp, your go): back by itself in 38 seconds; **the next update repaired dpkg by itself
  and finished — nobody typed anything.** No mail.
- **A restore-test 30 minutes after an agent start** ran and passed on demo-felhom.
- Controller 0.295.0, agent 0.145.0 (+ its root files) on demo-hp, demo-felhom and Tester 1; hub 0.134.0; new-install
  image 0.295.0 baked and approved.

**Found today:**
- **My slip from this morning:** the Tester 1 test machine did not restart after the morning crash and stayed off for
  1 h 17 min; my morning report said every box was healthy. It now starts by itself after a crash (proven by the second
  crash).
- **What the household may notice from a make-up run:** the database backup stops an app with stored files for its copy —
  1 second for opengist. The night does the same unseen; a big app may take longer, in the day (filed, small).

**Needs you:** nothing urgent. **Tester 2's one-time step** is unchanged (below). The new missed-backup alarm will be
checked at tomorrow's 05:00 run; if Tester 2 is still off, you will get its first real "backup missed" mail — that is
the fix working, not a new fault.

## Today (2026-10-05, day): the night's fixes, the power cut by day, a box that is off at night

**Decisions I took myself (you may reverse each — `09` decisions 104–108):**
- The off-site clean-up's safety line is now "the last 7 calendar days" — the same number the clean-up keeps — not
  "8 days old". It can never block an honest clean-up again.
- The image clean-up now waits while ANY app install, update, restore or undo is downloading — not only installs.
- A killed update keeps its report on the box until the hub has it; the agent looks for such reports every 5 minutes.
- **A second agent release today (0.144.1)**, against "one release per repo": the first fix for the lost report was
  proven NOT to work on demo-hp, and shipping it as it was would have been worse.

**What works now (proven live):**
- **The weekly off-site clean-up really deletes old backups.** One clean-up each by hand: demo-felhom 16 → 14, demo-hp
  145 → 127 — exactly the backups I predicted. No error mail, the hub's count check quiet, the key files clean.
  This also closes R-95 (the box can no longer delete its own off-site history, and clean-up now works).
- **A new box's first app install works the first time:** the image clean-up met an install at minute 3 on the scratch
  box, waited, and BookStack installed first try. A failed install now logs its real reason.
- **The update's disk-space check counts the real download** (12.8 MB for 13 packages; it counted 0 before).
- **A killed update still reports to the hub** (5 minutes later, once). The debug update runs with the hub away.
- Controller 0.294.0 on demo-hp, demo-felhom and Tester 1 (floor per customer; Tester 2 not moved). Agent 0.144.1
  and its root files on all three. New-install image 0.294.0 baked and approved.

**Found today (filed, not fixed):**
- **After a power cut in the middle of an update, every later update fails until someone runs one command on the box**
  (R-876, P2). The box itself comes back fine. Until the fix: `runbooks/crash-guard.md` has the command. I fix it next.
- A box that is off at night (below): no catch-up, no missed-backup alarm (R-872), a "server cannot be reached" mail to
  the household every night (R-873), restore-tests never run (R-874).

**Needs you:**

1. **[DECIDED 2026-10-05 08:42 — option A, built the same afternoon; see above]** **A box that is off every night (Tester 2) — what does the product promise?** Today such a box never gets its
   nightly database backups, second copy or off-site copy; the whole-box backup runs only about every 2 days; no
   alarm says so; the household is mailed "your server cannot be reached" every night. No design document covers it
   (R-871).
   - **A (my pick): a missed night runs once when the box comes back.** The database backups, the second copy and
     the off-site copy run a few minutes after the box is on again (they take seconds to minutes; whether
     any of them pauses an app is to be measured in the design — the whole-box backup, which does pause apps, already
     has its own catch-up). App and system updates still
     wait for a night. Costs: a design section and one controller release; the household may notice a busy disk for a
     few minutes after switching on.
   - **B: say plainly that the box must stay on at night.** The setup guide and the box's backup page say it; the
     missed-night alarm fires after 2 nights off. Costs: wording + one alarm; a laptop household gets an alarm it
     cannot fix except by changing habits.
   - **If you do nothing:** Tester 2 keeps having no database or off-site backup, nobody is told, and the household
     keeps getting the nightly "cannot be reached" mail. A restore-test alarm will fire around 2026-10-11.
2. **Tester 2's one-time step** — unchanged from yesterday (below). If you wait, it keeps working; it just cannot get
   new root files.

**Recorded, not decisions:** Tester 1's Cloudflare tokens are NOT rotated (your ruling; R-870 has the steps).

## Today (2026-10-04, night): root files for installed boxes, test approvals, Docker self-repair

**Decisions I took myself (you may reverse each):**
- The hub cancelled only the AUTOMATIC test approvals of today (guest and host fixes). Your own "Approve Docker set"
  press stays in force. From now on every approval made during a test wait gets the test mark, button or not.
- A box whose root files are behind the approved ones for 7 days sends you a mail.
- The demo boxes' controller floor is 0.293.0; the fleet floor stays 0.292.0, so Tester 2's controller did not move.

**What I did:**
- **Root files for installed boxes (your ruling):** a box's root-owned files (permissions list, helper scripts, crash
  guard) now travel as one signed package. The box checks your signature, every file and itself; on any problem it
  puts the old files back. Proven on both demo boxes: a wrong package refused, a package with one changed line
  installed and undone, a copied old job refused. New installs use the same package.
- **One catch:** a box installed before tonight cannot take the FIRST package by itself; it needs one small step by
  hand. I did it on both demo boxes. **Tester 2 needs it from you** (below).
- **Tester 2 was not as old as the brief thought:** it was installed at 18:06 local, after the crash guard and the new
  image. It already has the crash guard, live-restore and Docker 29.8.2. It lacks only tonight's Docker-update fix. I
  sent it the signed agent update.
- **Test approvals end with the test:** the hub cancelled today's 4 test approvals at its restart (you got one mail).
  Tester 2 keeps what it installed; no further box installs them. The same fixes get a real approval after 24 h + a night.
- **Docker self-repair:** if Docker's socket is re-created, the controller now restarts itself and the web router within
  about 2 minutes. Proven on the scratch box and on demo-hp, no app restarted.
- **drill-r50 is gone** from the hub. On ep0 nothing was destroyed (it had no backups there); its tunnel entry left.
- The "felhom-pbs skipped" line on Tester 2 is normal for a new box's first hour (no mail was sent).
- New-install image 0.293.0 baked and approved.

**Needs you (nothing breaks if you wait):**
- **Tester 2 is offline** since 20:06 local (and was off 19:13–20:05 local; it restarted in between). I sent it nothing
  before 20:35. My agent update for it is queued but expires at 21:20 local; when the box is back I re-send it.
  Worth asking the tester whether the box was switched off.
- **Tester 2's one-time step** (5 minutes): connect your tunnel, `ssh -p 8822 felhom-op@10.77.0.5`, reveal the root
  password in the hub (Hosts → Tester-2 → Console access; this writes one line on Tester 2's timeline), `su -`, then
  run the three commands in `documentation/runbooks/config-bundle.md` ("Tester 2"). Tell me when done; I send the package.
  If you wait: Tester 2 keeps working; it just cannot get new root files until then.
- **Found, not fixed:** the agent's permission list is wider than "minimal": a broken-into agent could become root on
  its own box. Worth fixing before the first paying customer.

## Today (2026-10-04, ~18:30): you found a bug — the Docker update blinded the box's controller

- **What happened:** the Docker update on the N100 restarted Docker itself. The apps kept running (as designed), but
  the controller and the web router kept a connection to the OLD Docker, so the controller could not see anything:
  the hub showed the N100 DOWN from 14:18 to 15:57. demo-hp had the same fault; the crash test happened to heal it.
- **Fixed (your choice):** after a Docker update the box now restarts just those two (about 10 seconds, apps untouched),
  and the update's health check now asks "can the controller really reach Docker?". Released as host agent 0.142.1,
  proven twice on demo-hp, on both demo boxes now, and approved for new installs.

## Today (2026-10-04, late evening): the System page, Docker updates, the crash restart

**Decisions I took myself (you may reverse each):**
- The box knows a crash only as "it did not shut down cleanly" (the crash memory chip saved nothing). So a power cut
  also counts as a crash.
- An "oops" (a kernel error the box survives) does not restart the box; you get a mail instead.
- Your words win where the brief disagreed: the **3rd** crash within one hour leaves the box off. Restart after 10 s,
  re-arm after 24 h. All settings.
- Only the box itself decides whether a Docker update is allowed: it checks your signature with a key file only root
  can change (not the agent's own settings, which the agent could change).
- The System page uses the alarm limits for its colours (red = an alarm would fire).

**No decision needed from you today.**

**What I did:**
- **The System tab** in the hub: per box the Proxmox, kernel (now and next boot), Debian and Docker versions, what is
  waiting, held packages, "restart needed", the crash guard and the last update run — with buttons for ring, on/off,
  "Approve now" and "Approve Docker set". The Hosts page shows Proxmox and kernel too.
- **Docker updates:** "live-restore" is on in every box (no app restarted: 24 of 24 and 5 of 5 containers kept running).
  Both demo boxes moved to Docker 29.8.2, every app kept running. I approved that set with the new button (a 0-night
  test wait, then back to 2 nights). An undo signed by your key put demo-hp back one version and forward again, apps
  running throughout. A copied (replayed) signed job was refused.
- **Crash restart (your 3 crashes on demo-hp):** crash 1 and 2 — back by itself in under a minute; crash 3 — it stayed
  off until you switched it on. You got the "guard tripped" mail. I re-armed it.
- **Found:** the hub learns about a crash up to 15 minutes late (nothing lost). After a crash, the household can also get
  an "app stopped" mail besides "restarted after a crash" — whether to calm that is a later choice for you.
- **New-install image re-made** with live-restore on and the approved Docker version, and approved in the hub with host
  agent 0.142.0. New boxes also get the crash guard (installer 1.30.0).
- **Rows:** 6 closed, 1 opened-and-closed the same day, 5 opened. The list went from 334 to 333.

**Needs you later (nothing breaks if you wait):**
- Installed boxes still get new root files only by hand (the long-standing gap; there are no other boxes today).
- Kernel updates are still not built (a hung new kernel would stay — needs a fix first).

## Today (2026-10-04, evening): host fixes, the fleet view, a true tunnel status

**Decisions I took myself (you may reverse each):**
- Only a box the installer itself recorded as "appliance" gets host updates (a record the agent cannot change).
- The four alarm times: no update run for 7 days; "reboot needed" for 14 days; the demo boxes approve nothing for 7
  days; a box has fixes nobody approved for 14 days. All four are settings.
- I released the host agent and the hub a second time today. The first release said "reboot needed" wrongly; the new
  14-day alarm would then have mailed you about boxes you had already rebooted.

**One decision for you (a safe default if you say nothing) — the Docker engine updates (designed, not built):**
1. **Turn on Docker's "live-restore" on every box.** With it, a Docker engine update restarts no app (measured: 0
   restarts). Without it, every app stops for about 30 seconds per engine update.
   - **A (my pick):** turn it on — in the new-install image and once on existing boxes. It goes on without restarting
     anything. Cost: it must never be turned off by a plain restart again (that stops every app and starts none).
   - **B:** leave it off. Every Docker update then means ~30 seconds of every app being down, at night.
   - **If you say nothing:** nothing changes; Docker updates stay unbuilt.

**What I did:**
- **The host's Debian fixes now install themselves**, after the guest's, on the same night run, only on appliances,
  never a kernel or boot package, never a reboot. Proven: demo-felhom installed 108 host fixes and stayed healthy; all
  108 came from Debian. A box made "ring 1" for a test installed exactly the one approved host version it lacked.
- **A way to put one host package back by hand** is written and proven on demo-hp (and the test taught it two fixes).
- **The fleet view** in the hub: one line per box with its updates, "reboot needed since", and the tunnel.
- **The tunnel status is now true:** running, not running, or unknown. I blocked demo-hp's tunnel: after two reports
  (about 30 minutes) you got a "tunnel down" mail; when I unblocked it, "recovered". A simply stopped tunnel heals
  itself within 5 minutes, before the hub can even see it.
- **The night run is fast:** 23–32 seconds when there is nothing to install (target was under 60).
- **The kernel test on demo-hp (your two reboots):** Secure Boot works with it, but GRUB's "boot once" does not work
  on our boxes: the second plain reboot came up on the NEW kernel again. So a new kernel that hangs would stay. That
  must be solved before kernel updates. demo-hp now runs the newer kernel, healthy. A watchdog chip exists on demo-hp.
- **Found and fixed during the live test:** "reboot needed" was wrong in two ways (fixed in the second release).
- **New-install image baked and vouched** (0.292.0 with host agent 0.141.1). The golden waiver is gone: not needed.
- **Rows:** 2 closed, 2 opened-and-closed the same day, 3 opened. The list went from 332 to 333.

**Needs you later (nothing breaks if you wait):**
- **A host that crashes does not restart by itself** (Linux's "panic" setting is off). Changing it changes how every
  box behaves, so it is your call, together with kernel updates.

## Today (2026-10-04, afternoon): the guest's security fixes install themselves

**One decision for you (a safe default if you say nothing):**

1. **Undo for a guest update that goes wrong.** I tested it first, as you asked: Proxmox cannot take a snapshot of a
   customer box at all (the box is linked to the household's drives, and Proxmox refuses). So there is no automatic undo.
   Today a failed check stops, mails you, and last night's whole-box backup (minutes old) is the undo, by hand.
   - **A (my pick):** keep it so. Nothing new to build. A restore takes about 1–3 minutes plus losing what apps wrote
     since the backup.
   - **B:** build our own disk snapshot under Proxmox. Automatic, but a new mechanism nobody has tested, with a risk to
     the disk pool.
   - **If you say nothing:** A stays.

**What I did:**
- **Your two choices are built.** A returning household's new box sets the old off-site copy aside on night one and
  starts a new one (nothing deleted). An approved version that Debian already replaced comes from Debian's dated archive.
- **Guest security fixes now install themselves.** Each night, after the whole-box backup, the demo boxes install
  Debian's fixes. When both demo boxes run the same versions healthy for 24 hours and one night, the hub approves that
  set; every other box then installs exactly those versions. Docker, the host and the kernel are not touched.
  - Proven live: each demo box installed 53 fixes and stayed healthy. With a 2-minute test wait the hub approved the
    set; then I put back 24 hours. demo-felhom, made "ring 1" for the test, installed exactly the 3 approved versions it
    lacked and nothing newer. A run where I stopped an app failed its check and mailed you (you got that mail).
  - You can switch OS updates off per box in the hub. They are ON by default. The household sees one line in its
    timeline: "System security fixes installed".
- **The tunnel and two other built-in programs are current** (cloudflared was 4 months old). A new monthly check
  catches them falling behind. The tunnel came back by itself on both demo boxes within 20 seconds.
- **Three bugs found and fixed during the live test**, before release.
- **Two gaps found, now rows:** existing boxes cannot receive the new update tool through the product (only new
  installs, or by hand — the demo boxes got it by hand); and the hub's "tunnel status" for every box always reads
  "inactive" because it checks the wrong place.
- **Rows:** 4 closed (one opened and closed the same day), 5 opened. The list went from 331 to 333.

## Today (2026-10-04, day): off-site closed, operating-system updates measured

**Two decisions for you — each has a safe default if you say nothing:**

1. **A returning household's first night.** A new box for someone who had a box before makes no off-site copy, because
   the old copy was made with a key the new box does not have.
   - **A (my pick):** the new box sets the old copy aside by itself on its first night, then starts a new one. An
     un-claimed box already does exactly this. Nothing is deleted; you can put the old copy back. Cost: a small box
     change. A household that wanted to continue the old copy with its recovery code must do that before night one.
   - **B:** ask the household on the recovery-code evening. Cost: new screens in two languages. If they skip it, the gap stays.
   - **If you say nothing:** such a household has no off-site copy until someone presses "start a new off-site backup",
     and you get a mail each time. Nobody is blocked today (no returning household is waiting).
2. **Approved OS updates, when Debian has already replaced the version.** Debian keeps only two versions of a package.
   - **A (my pick):** the box then fetches the exact approved version from Debian's own dated archive
     (snapshot.debian.org, signed by Debian). Measured: 2–3 seconds. Cost: one more outside service we rely on — but in
     3 months it would have been needed **zero** times for the packages a box has.
   - **B:** the box waits for the next approval. Cost: no new service; a box can stay unpatched for one cycle.
   - **If you say nothing:** nothing is blocked now; the first build step can start with B and switch later.

**What I did:**
- **A restored box is safe by default.** The automatic restore-test was already safe (measured). The agent's disaster
  restore now refuses to run next to a live original. Restores by hand use a new safe script: no start on boot, no link
  to the real drives, network off. All proven live on demo-hp. New agent 0.139.0 on both demo boxes.
- **The weekly clean-up cannot get stuck any more.** You can allow one bigger clean-up for one box (hub 0.129.0). Proven on
  a lab copy: 98 backups, the normal limit refused, the bigger one cleaned to 13, and the next week was normal again.
- **A dated check for 12 October** looks at the first clean-up that really deletes old backups.
- **OS updates, measured on the demo boxes (nothing built for customers):**
  - The boxes are far behind: 188 updates per host, about 59 per guest. Every guest runs a different Docker version.
  - A Debian update of the guest took 24 seconds. No app stopped. The undo (restore the guest) took 73 seconds.
  - A Debian update of demo-hp's host took 60 seconds. The guests kept running.
  - A broken (killed) update does not fix itself. Two repair commands fix it in 5 seconds.
  - A Docker update restarts every app (about 30 seconds silent). A Docker setting ("live-restore") avoids that
    completely — but switching it off again stopped every app and started none. Recorded as a trap.
  - The new kernel booted fine, and the box fell back to the old kernel on the next restart. **But** if a new kernel
    hangs, the box keeps trying it. Someone must then switch it off and on. No hardware watchdog is used.
  - About 40 packages from Proxmox have ordinary names (for example the disk system ZFS and the Secure Boot loader). So
    "which lane" must follow where a package comes from, not its name.
  - The internet tunnel program on every box (cloudflared) is 4 months old. Nothing updates it. New row.
- **Thank you for being near the box.** demo-hp restarted twice. It now runs the old kernel and starts the new one at
  its next restart.
- **Rows:** 2 closed, 5 opened. The list went from 328 to 331.

## Today (2026-10-04): off-site safety finished

- **The weekly clean-up is ON and no longer stops itself.** The fake-backup check now skips young copies that a manual
  backup replaced the same day, instead of refusing. I ran one window on demo-hp: no refusal, nothing removed
  (127 → 127), because every candidate was still young. The first real removals come when those copies are older than
  8 days — around 11 October. demo-felhom gets its first window at its next night run.
- **DooPlex keeps 8 weekly copies of ep0** (your choice). Old copies go weekly; anything ep0 deletes still never reaches
  the copy by itself. Today's nightly copy ran fine.
- **tester-1's 3 old keys are gone.** The daily alarm for tester-1 stopped. (You got one last alarm mail this morning,
  sent just before I removed them.)
- **A restore from the DooPlex copy works.** I restored demo-hp's whole box onto a scratch machine in about 3 minutes,
  read its data, then deleted it. **One trap found:** a restored box starts automatically and points at the real
  drives. Run beside the original, that would be two copies of the same box. I switched it off in time; the runbook
  now warns, and a row asks to make it safe by default.
- **"Delete my old set-aside backups" works again.** The hub does it, 7 days after the household's request; the
  household or you can cancel in that time. Tested on tester-1 with a planted test folder.
- **Your answers are recorded**, including that you keep the current Hetzner key for now (a row holds the 3 steps).
- **Rows:** 6 closed, 4 opened. The list went from 330 to 328.

## Today (2026-10-03, evening): your choices A and A — built

- **A box can no longer delete its off-site backups.** Both demo boxes now use a key that can only add. I tried a
  delete from each box: refused. Old backups all stayed (demo-felhom 11 → 13, demo-hp 91 → 100).
- **No box gets the storage password any more.** The box gives the hub only its public key; the hub puts it in the
  storage account. I asked for the password with demo-hp's own login: refused.
- **The hub keeps the passwords locked (encrypted).** A copy of the hub database no longer reveals them.
- **Every day the hub checks each storage account's key file.** It found old unlocked keys from earlier boxes:
  4 on demo-felhom's account and 5 on demo-hp's — now removed. tester-1's account still has 3 (its box is gone); you
  get a daily alarm for it until they go.
- **The weekly clean-up window works, but it is switched OFF.** I opened one window on demo-hp by hand: it opened,
  the fake-backup check refused, and it closed in 3 seconds. The check refused because I had made a manual backup
  today — it is too strict. I fix that next; until then nothing deletes old backups (there is plenty of room).
- **ep0's whole-box backups are copied to DooPlex every night.** First copy: 12 GB in 3 minutes, all 4 backups.
  DooPlex cannot read them (encrypted per household). A failed copy mails you; the test mail arrived.
- **One bug, found and fixed live:** the first new box version misread its backup count as 0, and you got one
  false alarm mail ("demo-felhom: fell from 11 to 0"). **Ignore that mail.** Fixed 15 minutes later (0.289.1).
- **Rows:** 3 closed, 6 opened, 1 opened and closed the same day. The list went from 327 to 330.

## Today (2026-10-03, later): off-site backup safety, step 1 — measured, nothing built

- **The "add only" lock works.** I tested it on tester-1's storage account (your choice; no box uses it now).
  New backups go in. Restore works. Every delete is refused. I put the account back exactly as it was.
- **But the lock alone does not protect us yet.** A broken-into box can ask the hub for the storage password.
  With that password it can log in and remove the lock. First the box must stop getting the password.
- **A second trap:** with "add only", an attacker can add fake backups dated in the future. The normal
  clean-up rule then deletes all the real backups. Any clean-up must check for this.
- **The hub keeps every storage password in plain form.** Anyone who reads the hub database can delete
  every household's off-site backups. New row.
- **ep0:** Hetzner cannot snapshot the extra disk at all. One of the three old ideas does not exist.
- **Rows:** 2 closed, 3 opened. The list went from 326 to 327 rows. The dated check for 6 October is done.

## Today (2026-10-03): the to-do list is in order — paperwork only, no machine touched

- **Finished items left the open list.** It went from 442 rows to 326. Nothing was deleted; each moved row names
  where its full text is.
- **Every open row now has one category and one severity** (P1 now · P2 before the first paying customer · P3
  during the first customers · P4 later). **No row is P1.** 27 rows are P2.
- **Two new automatic checks** refuse a finished row left in the open list, and a new row without a category or a
  severity.
- **Your four new items are on the roadmap:** security updates for the box's own system; legal pages and business
  papers; "what if the household leaves Felhom"; a second login step for the dashboard. Two of them are also real
  findings today: **a box never receives system security updates**, and **the website has no privacy notice,
  terms or imprint.**
- The ranked list and my reasoning: the triage recommendation in the audits folder.

**Tester-2 — read only, from the hub.** The customer record exists. Tester-2's box has not registered yet.

## Today (afternoon): every app checked again

- **No data-loss fault.** I checked all 58 apps with the fixed check. It made each app really save something, then
  looked where the data landed. **No app saves data where the backup does not copy it.**
- **40 apps: proven correct. 18 apps: not proven either way.** In those 18 the check could not fill every folder (for
  example an upload folder stays empty because my test saves no upload). Nothing was found outside a backed-up folder.
  I list them and work on them later.
- **papra was broken for new installs, now fixed.** It needs more memory than its limit, so a fresh install crashed in a
  loop. I measured it and raised the limit. No box runs papra.
- **plant-it's program image is gone from Docker Hub.** It is already hidden from new installs. No box runs it.

## Removing an app now tells the truth (your choice A)

- When the household removes an app, its own files (books, videos) **stay**. The dialog and the result now say so, and
  name the folder. Proven on the scratch box: the video was still there after the remove.

## Before the first paying customer

Everything here must be done before the first customer who pays:

1. **SparkyFitness:** written permission from the author (the e-mail draft is ready). If none → hidden from new installs.
2. **Tandoor:** written permission from the authors. If none → hidden from new installs.
3. **A lawyer reviews the licence list** (Tandoor, SparkyFitness, Emby, n8n, Plex, the paid "enterprise" parts, Redis).
4. **Agent updates:** I may sign agent updates only until the first paying customer; after that you sign them.

Your licence decisions are recorded: Emby, Plex and n8n stay. recipe-importer needs nothing unless we share it.

## Also today

- **New version 0.288.0 and a new golden (0.288.0).**
- **Rows.** 7 closed, 6 opened. The list went from 436 to 442 rows.

## What needs you

0. **The undo choice at the top of today's section** (A: keep the backup as the undo; B: build our own snapshot).
   If you say nothing, A stays. Earlier today's two decisions are built. The Hetzner key change stays your call.
1. **plant-it:** keep the hidden template as it is, or remove it entirely (its image no longer exists). **If you say
   nothing:** it stays hidden; nothing runs it.
2. **Send the SparkyFitness request, and ask the Tandoor authors** (the "Before the first paying customer" list).
3. **Phone test (2 minutes), only if you want it:** say so, and I put MeTube back on demo-hp with a family login.

## Standing steps

- **Monthly security re-test: last run 2026-10-01, next due ~2026-11-01.** (You start it with the standing brief.)
- **Weekly:** the golden bake (next around 9 October; today's bake was 0.288.0).
- **Registry clean-up:** only when the registry disk fills; "show me" mode first, then a person decides.