felhom.eu/STATUS.md

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

Updated 2026-09-20 (evening) — every app in the catalog now describes itself in English, and every box can read it.

Ready for a volunteer: yes.

What changed. This morning an English dashboard still showed Hungarian app text — each app's description, its „what is it for" list, its „first steps", the labels under every install setting. That text lives in the app catalog, and the catalog was Hungarian only.

All 53 apps now carry an English version beside the Hungarian one, in the same file. 1 031 of the 1 032 pieces of text are done. You read three of them at lunchtime and said go; the other fifty follow that same voice.

The one piece left is not an oversight. One app's install page explains a security key with the sentence that belongs on a different field — it is wrong in Hungarian. I am not allowed to change Hungarian words in this kind of release, and translating a wrong sentence would spread the mistake into a second language. So that one line still shows the Hungarian. There is a row open to fix the Hungarian first.

What I checked, on the real boxes. The English app list shows no Hungarian app text at all, across all 53. The Hungarian pages are identical to before, down to the byte. I checked the same on a second box that was deliberately left on an older version — it simply ignored the new text, which is what lets this be safe.

I raised the box floor to the new version, as you asked. The second demo box picked it up by itself in under twelve seconds, came back healthy, and then showed the English text. Two machines that are switched off — the tester's box and one other — will take it when they next come on.

Two things are still Hungarian on an English app page, and both come from the box's own code rather than the catalog: the small „up to date" tag on each app, and the sentence under a data folder that says whether it is backed up. Rows are open for both. The second matters more, because it makes a promise about somebody's files.

Rows. Six opened today, one of them already closed.

Needs you — nothing urgent. The only open question is whether to change the shared demo password.

If you do nothing: nothing breaks.

Previous note

Updated 2026-09-18 (night) — the new installer is published, and the box's screen speaks English too.

Ready for a volunteer: yes.

What changed. Two screens a person meets before they ever see a dashboard were Hungarian only: the text on the box's own monitor while it waits to be paired, and the download page. Both are now bilingual — Hungarian exactly as before, then the same thing in English under it. The boot menu too.

felhom.eu/en/download is live, and both download pages now point at the new installer.

The new installer is published: version 1.29.0. I installed from the finished file twice — once from each boot-menu choice — on throwaway machines, let each one boot and then rebooted it, and checked the screen every time. Both showed the bilingual text, no Proxmox address, and the pairing code readable in both languages. Then I downloaded the published file back and checked it is byte-for-byte the one I tested.

Something was wrong and I caught it by looking. The first build's second menu line was too long for the box GRUB draws, so its English half was chopped off mid-word on the boot screen. I shortened it and built again; the published image is the fixed one. The Hungarian is what may never change, so the English is the half that gave way.

Two things were already broken before I started. The installer's own test suite had been failing for two days and nobody saw — it is not part of any automatic check. And the release checklist still said every screen must be Hungarian, which would have blocked exactly what you asked for; your September ruling replaced that, so I rewrote the checklist item rather than skipping it.

Rows. Three opened, one closed, one half-done.

Needs you — nothing for the installer. It is done and live. The old version stays online, so going back is one edit if anything looks wrong.

Still open from earlier today: raise the box floor to 0.256.1 (so English households get English alerts everywhere), and whether to change the shared demo password.

Previous note

Updated 2026-09-17 (night) — English, step 3 of 3 done: every dashboard page speaks English, and the language switch is there for everyone.

Ready for a volunteer: yes, unchanged. A Hungarian household will see one new thing: a small „Magyar / English" switch at the bottom of the menu. Nothing else on the Hungarian pages changed.

Decisions I took. None. (The old choice to hide the switch was mine; the plan said to undo it now, and I did.)

What I exercised, on the demo HP box. The last eleven pages speak English: storage, network storage, the two drive helpers, sharing, sign-in, the set-password page, the guest launcher, its password page, the "no such app" page, and the debug page. I saved the Hungarian pages before and after the update. The only change is the new switch, plus live numbers. The sign-in pages did not change at all. I switched the box to English and back with the real switch. The hub saw Hungarian, English, Hungarian.

What broke, and whether it is fixed.

• Six small Hungarian words were still on the English pages („mp", „db", „FIGYELEM"…). No test saw them; I found them by reading. Fixed, and filed that the test cannot see such words.
• My test cases used made-up page titles. I fixed them to the real ones and re-took those snapshots from the old code.
• Found, not fixed, filed: three browser-tab titles with an app name stay Hungarian; the drive helper pages do not light up the Storage menu; the two disks on the dashboard swap places between visits.

Rows. One closed (localisation step 1), four opened. The register went from 260 to 263 open rows.

Needs you. Nothing. You told me to raise the floor, and I did: the fleet floor is now 0.250.0 (declared agent requirement 0.131.0, the release header's). The demo N100 box took it by itself in about a minute — nobody deployed to it — and its Hungarian launcher now shows the switch. The HP demo box has its own per-box floor and was already on 0.250.0 by hand. The other three boxes are down or blocked, so they take it when they come back. The vouched golden is still 0.246.0, so a NEW box installed today starts on 0.246.0 and then updates itself to 0.250.0.

---

Previous note

Updated 2026-09-17 (evening) — English, step 2 of 3 done: the backup pages too.

Ready for a volunteer: yes, unchanged. A Hungarian household still sees nothing new.

Decisions I took. None.

What I exercised, on the demo HP box. Ten more pages speak English: the dashboard, the app list, an app's install and settings page, logs, the system monitor, import, export and the three settings pages. I saved each page in Hungarian before the update and after it. Only live numbers differ (CPU, memory, log lines). I switched the box to English and back with the real switch.

What broke, and whether it is fixed.

• One page decides something by reading its own Hungarian word („Fut", running). Translating that word would quietly break the English page. I left the word Hungarian and filed it.

• A new check found two text pieces on last release's pages that no test ever showed. Fixed.

• Step 2: the seven backup pages speak English, and the Hungarian pages again did not change. The check that stops a promise we cannot keep now reads English too — and English showed it had been missing some Hungarian sentences (verbs split in two). Filed.

Rows. Two opened. The register went from 258 to 260 open rows.

Needs you. Nothing yet. Steps 2 and 3 follow (backups; storage, sharing, sign-in, and the switch for everyone).

---

Previous note

Updated 2026-09-17 (afternoon) — the dashboard can speak English on three pages, and the Hungarian pages did not change by a single byte.

Ready for a volunteer: yes, unchanged. A household sees nothing new. English is switched on per box and covers the launcher, the backup overview and an app's page. No recruiting sentence yet: English is a proof of the method, not a feature.

Decisions I took (you may reverse either):

1. How the text is stored. One word list per language, filled into the page before the page is built. The other way changes Hungarian characters on the page, so it breaks the „Hungarian must not change" rule.
2. The language switch is hidden on Hungarian pages for now. Only three pages are English, so showing it to every household would put a half-English dashboard one click away. It appears once the rest of the pages are done.

What I exercised, on the demo box.

• I saved the three pages in Hungarian before the update and again after it. They are the same, except the version number and a security token.
• I switched the box to English with the real switch. The pages came up in English. The hub received „en" in the box's report. I switched it back; the pages are Hungarian again and the hub received „hu".
• What stays Hungarian on the English pages: some messages built by the program, and the app descriptions from the catalog. Both are later steps of the plan.

What broke, and whether it is fixed.

• Moving the text out of the pages made one copy check fail and three others blind to it (for example the check that stops a promise we cannot keep). Fixed in the same release; each check was shown to catch a planted mistake in the moved text.
• My text-moving tool missed eight Hungarian words that have no accents. I found them by reading the result, and fixed the tool.
• The hub's field check passed the new field for a wrong reason (the word appears in a comment). Filed, not fixed.
• The count of all Hungarian text: about 1 900 strings in the pages, 1 100 in the program, 65 in the hub e-mails, 830 in the app catalog, and a 1 600-word guide. The prompt's two rough counts were not reproduced; the difference is named in the inventory.

Rows. Ten opened, none closed. The register went from 248 open rows to 258 (the register gate's count). Six of the ten are the plan's steps; one is four places where the program decides something by reading Hungarian words — those must be fixed before any program text is translated.

Needs you. Nothing. You answered both questions:

1. The console screen and the download page are in scope. They stay late in the plan.
2. Screen names translate („Indítópult" is „Launcher"). Every later step follows this.
3. For information: the demo HP box runs the new controller, put there by hand. The other boxes stay on the previous version until you raise the floor. Nothing changes for them if you do not.

---

Previous note

Updated 2026-09-17 (midday) — the four things chaos night found are fixed, and three of them were proven on the demo box.

Ready for a volunteer: yes. Nothing here was blocking; all four made the box more honest or less noisy. The recruiting sentence: if the power fails in the middle of a restore, the box now says so and tells you to run it again; and it no longer asks for the recovery code before it can take it.

Decisions I took. None under the unattended rule. I carried out your three rulings: the quiet-box alarm waits three report cycles; the restore record is kept on disk; the slow crash-loop warning. I signed the agent update onto the two demo boxes under yesterday's ruling.

What I exercised, on real boxes.

• The hub now waits 45 minutes before „the box went quiet" and 90 before „the box is down". The running hub prints both numbers when it starts. A dead box now pages you 15 minutes later — your ruling's accepted cost.
• I started a restore on the demo box and killed the controller two seconds in. It came back by itself. The restore page then said „A visszaállítás megszakadt — indítsd el újra", and the hub got the event. Restoring again cleared the note.
• I killed the demo box's controller five times, about eight minutes apart. The agent restarted it every time, the fast brake never fired, and on the fifth exactly one warning mail reached you (09:29). That was the test — no need to act on it.

What broke, and whether it is fixed.

• Nothing in the product broke.
• One thing I could not prove live: the recovery-code reminder waiting for the box. No demo box is in that state today. It is proven by tests, and chaos night already measured the 17-minute wait live.
• I found one small gap in my own new code: if a household removes an app instead of restoring it again, its „interrupted" note never goes away. Filed, not fixed — the release was already built.

Rows. Two opened, four closed. The register went from 215 open rows to 213.

Needs you. Nothing. Both of your „yes" answers are done:

1. All boxes get the new controller. The floor is raised to 0.246.0; the N100 took it within seconds and the HP already had it. Peti's box is offline on the hub, so it gets it when it next reports.
2. Fresh installs get today's fixes. The hub would only vouch the new agent together with a newer golden, so I baked golden 0.246.0 (your choice) and vouched both. A brand-new box now installs controller 0.246.0 and agent 0.132.0.
3. For your information: the demo box's slow crash-loop warning stays raised until tomorrow 11:22, because I caused it on purpose. It cannot mail you again before then.

---

Previous note

Updated 2026-09-17 (morning after chaos night) — twelve rounds of a household under accidents; the box healed itself every time.

Ready for a volunteer: still yes. For a night I did random household things on a fresh box while random things went wrong: a power cut in the middle of a restore, the reset button four seconds into another, a full disk, a dead tunnel, Docker restarting, the internet cut three times, and the data drive pulled out of the running machine for twenty minutes. No customer data was lost, and the box put itself back together every time without anyone touching it. Seventeen alarms went off. All seventeen were true, none were missing, and every one reached your mailbox.

Decisions I took. None under the unattended rule. Two judgement calls are logged in the drill record: one round ran „use" instead of the drawn „update" because the app catalog's own checks could not vouch for the update; and I did not touch the box at all during the final control round.

What I exercised. A new golden was baked and published. A fresh box installed itself from the public installer image and bound itself with no press from anyone — both emergency presses I was allowed stayed unused, and the automatic re-issue after a deleted box was seen working live for the first time. Then twelve rounds, drawn in advance from a fixed seed and written down before the first one started.

What broke, and whether it is fixed. Nothing in the product broke. Three things are worth fixing, all filed, none fixed tonight (no product code was allowed):

• If the machine stops during a restore, nothing ever tells the household whether it finished.
• The „this box has gone quiet" alarm allows exactly two report cycles, so one missed report uses the whole allowance — tonight a healthy box came within one second of paging you.
• A disk that fills up and empties again between the daily checks is never mentioned to anyone. Two smaller ones were filed earlier in the night: the first-hour guide asks for the recovery code about seventeen minutes before the box can accept it, and a small-disk box keeps retrying a local backup that can never fit (the off-site copy still worked). Most of what broke tonight was my own measuring. Eleven times a check of mine gave a confident wrong answer; each is written down with its fix. The worst one delayed the last cleanup step by six hours.

Rows. Five opened, none closed. The register went from about 212 open rows to about 217 (my own count this morning reads 215; the difference is how closed rows are counted, not a missing row).

What I could not test. Restoring a single app from the off-site copy. This box was a rebuild of an existing customer, so its old off-site app backups belong to a key it no longer has — correct and by design, and the box told you so within seconds. The whole-machine off-site copy is there and intact, but I only listed it; I did not restore from it.

Cleanup. The test machine is gone, its space is back, both demo boxes are still running, and the off-site backups are untouched. The deleted box's record is gone from the hub; its key is held in retained custody, as designed, and the customer account is untouched.

Needs you.

1. Nothing blocking. A volunteer can start.
2. The quiet-box alarm margin. Pick one: wait three report cycles instead of two, or retry a failed report once straight away. If you do nothing: one network hiccup at the wrong moment pages you about a box that is fine.
3. The restore record. If you do nothing: a household whose power fails mid-restore is never told whether their restore happened.
4. Single-app restore from off-site is still unproven on this release. If you do nothing: it stays unproven until a box that is not a rebuild is used for a drill.

---

Previous note

Updated 2026-09-16 (late evening) — the box now asks for the recovery code, and the page stops promising a copy that has not run.

Ready for a volunteer: yes. The one thing standing in the way this morning is fixed. On a new box the off-site copy is switched on but paused until the household writes down their recovery code — that pause is deliberate and correct, because that code is the only key and we cannot open their copies without it. What was wrong is that nothing asked them. Now every page says so until they do it, and the backup page says „would protect" instead of „protects" while it waits.

What changed today (this note). A reminder bar on every page of the dashboard: „the off-site backup is paused until you create your recovery code", with the button that does it. The sentence under each app's local backup now tells the truth about the state it is in — protected, waiting, or no copy at all — instead of promising the same thing in all three. The first-hour guide asks for the code right after the dashboard password and before the first app, and says plainly that we cannot get it back for them. The operator step for rebuilding an existing customer's box is written down where it was missing: normally nothing to press, but one press when the old box was not deleted through the acknowledged flow.

What I proved on real boxes. On a box whose recovery code exists: no bar anywhere, and the page says the files are protected. On a box waiting for the code: the bar on every page, an off-site run refused with „waiting for the key to be placed in escrow" and no copy written, and an app's row reading „would be protected … paused until you create the recovery code". Both boxes were running today's build. The throwaway app and the test setup were removed afterwards and checked gone.

Decisions I took. None under the unattended rule.

Needs you.

1. Nothing blocking. The installer image you approved is published and live on the download page, and the recovery-code gap is closed. A volunteer can start.
2. The slow-crash-loop counter (the ruling of 2026-09-15) is still owed, and is a job for the nightly. If you do nothing: a box that keeps crashing slowly is still reported as healthy for longer than it should be.
3. One small thing worth knowing, not doing: there is no button that forgets an off-site destination once set — only one that disables it. Written down as a low-priority job. If you do nothing: a household that types the wrong address keeps the old one on the box, switched off.

---

Previous note

Updated 2026-09-16 (drill on a fresh box) — the fixes hold; the backup promise does not.

Ready for a volunteer: NO — one reason, and it is new. On a brand-new box with one drive, the household's own files are in no backup at all, and the backup page says they are. I deleted five photos the way a child would, restored from the box's own backup, and the folder came back listing all five photos — none of which opens. The bytes had never been copied. The app's own wastebasket still held them, and the restore made that unreachable too.

What I proved on a fresh box. The installer downloads and installs; the box lands on the golden this drill baked (checked by checksum, not by trust); the connect e-mail and the bind page work; the dashboard opens through the tunnel from outside; the file manager has its own password and „admin/admin" is refused; four apps installed and were used; the backup page tells the truth per tier; „Mentés most" stopped the apps for 26 seconds, inside what the button promises.

The five faults. A controller killed during an install: back in 37 seconds. Two reboots a minute apart: everything back in 124 seconds, and the box did not count the reboots against its own safety brake. Wrong passwords five times: the app lets you keep trying, the box's own setup code locks for 15 minutes after two and e-mails you — correctly. Memory pressure: the box still cannot see it (second box, same result). The deleted photo folder: see above.

The automatic connect e-mail: it works. I deleted the box's record on the hub and the „connect your Felhom box" e-mail reached the customer one second later, naming the reason. That was the last thing waiting to be proven with a real mailbox.

Decisions I took. None under the unattended rule.

Needs you.

1. Say whether the backup page may keep promising what it does not hold. Today, a new box with one drive backs up its apps' settings and databases — not the household's own files. The page says otherwise, and a restore then reports success while the files are gone. If you do nothing: the first volunteer can lose their photos and be told everything is fine. I can fix the wording and the refusal in the controller; the real protection needs a second drive or the off-site copy switched on.
2. Grant the off-site server one permission. The re-issue fails on a missing grant, so a rebuilt or new box gets no off-site copy at all. If you do nothing: the third backup level stays unavailable for every new box, and the fix already written stays dead.
3. Rule on the restart brake. The box stops retrying after three restarts in fifteen minutes. I measured that a controller dying every twenty minutes is restarted forever, and the only trace is a note that e-mails nobody. Options: leave it (the box heals itself and the timeline records it); add a second, slower counter that raises a warning; or make the fifth restart in a day a warning. My pick: the second counter — it keeps the healing and ends the silence. If you do nothing: a slowly failing box stays invisible until someone reads the timeline.

---

Previous note

Updated 2026-09-15 (P1 fixes) — the big night's blockers, fixed and shipped.

Ready for a volunteer: almost. The file manager has a real password, the backup page tells the truth, the installer is published with its download page, and a dead controller now comes back by itself — proven on the HP. Two things still stand in the way: a volunteer's own tunnel is unproven until their box exists, and every box except the HP still runs the old agent until you sign its update.

Decisions I took. None under the unattended rule. Three things I did not do, each with its reason: I did not send a real connect e-mail to test it, because deleting a test customer would touch the off-site server; I did not build a „release PBS token" button, because the off-site server has no way to remove only the token; the memory warning does not say „restarted", because nothing restarts the app.

What I exercised, on the HP. Killed the controller: back in 59 seconds. Parked it: it stayed off. Killed it during an update: the update rolled itself back. After three kills in 13 minutes the box stopped retrying for 30 minutes and you were e-mailed — that is the safety brake, and it worked. When the brake ended, it started the controller again by itself, and told you that too. File manager: a new box gets its own password; the HP, where you set one, was left alone. Backup page: correct on the HP. Vaultwarden refuses strangers. Paperless took 20 documents at once without losing one.

What broke, and whether I fixed it. The backup tile printed „0 B" after an agent restart — fixed, ships next release. The memory-warning check sees nothing inside our guests, because Docker reports nothing there — not fixed, filed.

Rows. Closed 9, opened 9. Register: 232 before, 232 after.

Needs you.

1. Sign the agent update for the N100 (and later Peti's box). If you do nothing: the N100 keeps the old agent, its dead controller does not restart, and its controller update stays held.
2. Say where your signing keys live between sessions. They were readable by other users on DooPlex; I tightened them. If you do nothing: the keys stay on the build server.
3. When the next box for „Tester 1" exists, check the tunnel opens from outside. If you do nothing: the „No TLS Verify" fix stays unproven.
4. Allow one test customer to be deleted (it resets on the off-site server), or accept the unit test. If you do nothing: the automatic connect e-mail is untested with a real mailbox.

---

Previous note

Updated 2026-09-15 (morning note) — the big night: a household's first month on one fresh box.

Ready for a volunteer: not yet — three things stop them. The dashboard link still does not open through the tunnel. A box installed for an existing customer gets no bind e-mail. And every box's file manager opens with the login „admin" / „admin" — on the HP that login page is reachable from the internet.

Decisions I took. None under the unattended-decision rule. Two things I did not do, each with one reason: I did not switch on the paid off-site storage for „Tester 1" (it costs money), so this box had no off-site copy and the off-site restore could not be walked. I stopped injecting faults after the ninth, because the brief's stop rule was met.

Interventions (first hour + moving in): 2. (1) No bind e-mail came for 10 minutes; I pressed the operator's „send link" button. (2) The tunnel answered 502; I used the home-network address for the rest of the night.

Alarm truth table, in five lines.

1. Every alarm that fired was true. None was false.
2. Missed: the Paperless crash, the broken tunnel, the dead controller, the full disk, and the second drive loss.
3. Three of those were missed because a 30–60 minute mail cooldown silenced a new incident.
4. One drive loss sent five operator mails; the household got no mail for anything all night.
5. The customer's pages were honest about drives, and wrong about backups twice.

What broke, and whether the box healed itself. Power cuts (three, one during a backup, one during an update): healed in about four minutes, same versions, data intact. Drive pulled and returned: healed in 91 seconds, data intact. Internet gone: the tunnel came back by itself in 9 seconds. Disk 95 % full: the box kept working. Controller killed: it did not heal — no dashboard for 33 minutes, nobody told, only a reboot brought it back. That was the stop. Also: Paperless silently lost 20 uploads to memory; the backup page claimed a remote backup that does not exist; the whole-system backup stopped every app for 8 minutes while promising „a few seconds"; after I reverted a test update in the catalog, the box offered the downgrade as an update. Nothing lost data that a restore could not bring back. I fixed nothing tonight.

Rows. Opened 16, closed 0. Register: 221 rows before, 237 after.

The one sentence for recruiting. Felhom survived power cuts, a pulled drive and a lost internet by itself tonight, but do not invite anyone until the tunnel works, the file-manager password is changed on every box, and a dead controller restarts itself.

Needs you.

1. Change the file manager's admin password on the HP now (and on the N100). If you do nothing: anyone on the internet who tries „admin" / „admin" at the HP's files address can read its data drive.
2. Tick „No TLS Verify" on the „Tester 1" tunnel route in Cloudflare. If you do nothing: no volunteer can open their dashboard from outside their home.
3. Decide whether a box installed for an existing customer should get the bind e-mail automatically, or you press the button each time. If you do nothing: each new install waits for you.
4. Say whether installer 1.27.1 should be published. My recommendation: yes, publish it — nothing tonight was the installer's fault; the install, first screen and bind all worked. The three blockers above are on the tunnel, the controller and the file manager, and they block inviting people, not the installer. If you do nothing: the old installer with the English admin line stays online.
5. Decide what to do with „Tester 1"'s old off-site data on ep0 (still there, kept tonight) and its stuck DR tier. If you do nothing: the data stays, and every new box for this customer gets a failed whole-system backup alarm.

---

Updated 2026-09-14 (evening) — the doorstep: installer fixed, walked again, NOT published.

Ready for a volunteer: not yet — one thing stops them. On the test customer you chose, the dashboard link does not open from our network: the box's Cloudflare tunnel connects but gets no routes (12 of 12 tries failed). Your phone reaches it, so something differs between connectors — only you can see that in Cloudflare. Everything this task changed works.

Decisions you took today. Keep the installer interactive (a person chooses the disk). Every customer has their own domain; you create the tunnel. Use the „Tester 1" record for the walk.

What I did. The box's first screen is now Felhom's in Hungarian, from the very first boot — the first build still showed the English admin line on that boot, so I fixed it again and rebuilt (1.27.1). The passphrase has one name everywhere, and the hub now tells you, when you create a customer, to hand it over in person. That hub change is live. The installer was built and checked against the release gate, then walked end to end: install on a three-disk and a one-disk machine, apps, backup, restore (byte-identical), removal, power cut, wrong code. Nothing was published.

What broke on the way. The test customer has no e-mail, so no code or link could be sent. The tunnel has no routes for a new box. I could not drive the graphical installer screen with my tools, only the text one. One of our install documents wrongly says the controller creates the web addresses.

Rows. Opened 7, closed 1 (the passphrase hand-over). Three more are fixed and close when you publish.

Needs you. (1) Look at the „Tester 1" tunnel in Cloudflare: which connectors are there, and does it have public hostnames? If you do nothing: a volunteer on a network like ours cannot open their dashboard. (2) Put the volunteer's e-mail on their customer record. If you do nothing: they get no setup code. (3) Say yes or no to publishing installer 1.27.1 — only after (1) is sorted, by the rule you set. If you do nothing: the old installer stays online, with the English admin line on screen. (4) The test left backup data for „Tester 1" on the off-site server, written by its DR setting from the test box (now destroyed); removing it the product's way would also remove the customer's tunnel. If you do nothing: it stays and uses a little space on the off-site server.

---

Updated 2026-09-14 (afternoon) — the first-hour drill on a fresh box.

Ready for a volunteer: not yet. Two things would stop a stranger before their first app: there are no instructions anywhere telling them where the installer is or what to type, and the link in the "your server started" e-mail does not open for a new customer, because nobody creates its web address automatically. Everything after that point worked.

What I exercised. A brand-new machine on the HP, installed from the public installer, connected to a new test customer, claimed, two apps installed and used (a family wiki with a Hungarian page and an attachment, and an encrypted note), a manual backup, one app removed with its data, the other restored after I deleted its page, a power cut, and a mistyped code. The new golden image was built first, as the weekly rule says, and the fresh box landed on today's release by itself.

What broke. Nothing lost data: the restore brought the deleted page back byte for byte, and the power cut brought every app back on the same version with no false alarm. What a stranger would trip on: no instructions (I wrote a Hungarian draft for you to approve); the dashboard address; the installer refusing its own default machine name; the box's screen first telling people, in English, to open the admin page they must never use; the five-word passphrase that no e-mail ever delivers; one backup page wrongly saying "already covered, nothing to do"; app pages saying "open wiki.DOMAIN" literally; and the dashboard showing the backup two hours off from the backup page. I reached the dashboard once in a way a volunteer could not — that is the single intervention. I fixed nothing; this run only records.

Rows. Opened 9 (eight from the walk, one about how I check the build server), closed 0. Register table rows: 200 before, 209 after.

Needs you. (1) Decide how a new customer reaches their dashboard: the hub creates the web address automatically, or the box offers a home-network address that works with no setup. If you do nothing: every volunteer needs you to create their address by hand before they can log in. (2) Read and approve the Hungarian volunteer instructions, and choose how they are sent. If you do nothing: there is nothing to send a volunteer. (3) Hand the five-word passphrase to each volunteer yourself until an e-mail does it. If you do nothing: they cannot connect their box.

---

Updated 2026-09-14 (morning note, the second night) — the scratch guest is built, one controller release, the rotation restarted.

Decisions I took. (1) The scratch guest on the HP was built as you ruled: a second guest under the HP's own customer, on the fast internal disk, sized like the main one, kept on purpose and written up in all three places. Two properties of it were my call and you may reverse them: it never sees your real data drive, and it never starts the public tunnel — a second connector would serve the public domain from a throwaway. (2) A finding I had already listed as fixed turned out half-fixed when measured live, and the rule is one release per night, so I kept the line open with the exact measurement instead of shipping a second release. (3) The removed-app listing was a medium-priority line, but it needed no ruling, touched no customer data and was the rotation's own finding, so I took it into tonight's release.

What I exercised. The rotation restarted from its first standing app on the scratch guest: front door, use, backup, second copy, remove-with-data, full restore from the second copy, the guarded update, remove-everything — all clean. Then a throwaway app for the release proof.

What broke, and whether I fixed it. Six lines fixed and shipped in one controller release, delivered by the floor in 16 and 17 seconds, proven on the scratch guest: an app you removed while keeping its backup now shows on the backup pages with a button that reinstalls it (before, the way back existed only as a hidden endpoint, and a backup kept on a data drive could not be found at all); a removal now clears the "held after a failed update" mark; the memory card on the monitoring page can render; the second copy is dated by its data rather than by a file that only moves when the app's definition changes; and a boot rule is now pinned by a test. Half-fixed: the removal's list of deleted volumes is right for a freshly installed app and empty for one that came back from a restore, because the restore recreates the volume without the label the list looks for. Measured, kept open. One security slip to know about: while building the scratch guest, the HP's retrieval passphrase was printed once into a tool output here on DooPlex. Nothing left the machine.

Rows. Opened 1 (delete the empty drive-path setting nothing reads any more). Closed 6 (the scratch guest, the removed-app listing, the hold left behind, the monitoring card, the second-copy date, the boot rule). Re-scoped 1 (deleted-volume list). Register: 210 open / 194 closed before, 205 open / 200 closed after.

Needs you. (1) Open the backup page once in a browser after removing a throwaway app with its backup kept, and press the new button — strict screen coverage is yours. If you do nothing: the feature stays proven at the endpoint level only. (2) The passphrase slip: re-issue the HP's retrieval passphrase from the hub when convenient. If you do nothing: the old one stays valid; the exposure is one line in this session's local record. (3) The scratch guest stays up and idle. If you do nothing: it costs the HP about one and a half gigabytes of memory and nothing else.

---

Updated 2026-09-13 (evening, before the night) — your four items.

Decisions I took. (1) The rules file now sits in the workspace root and all three repos, byte-identical; the gate that checks instruction files required three lines at its top saying it loads in every session on purpose, so all four copies carry them. (2) The photo fix was applied to your own test instance on the HP through the Update button, not by hand, and I added one test account with one photo there.

What I did. The rules file: done. The photo problem: the app's backend serves photos itself, through a small web server inside its own image; our template sent every request to the front page server, which has no photos. Fixed in two cuts — the second one because the first spoke to the wrong port and got empty pictures. Proven without a browser: a photo now comes back as a real image through the public address, and you confirmed it in your browser at 21:49. The tier-order ruling: built as controller 0.241.0 — an app whose data lives in mounted folders now prefers the remote copy over its own-drive copy, and the hold message ends with what the chosen copy holds. Live on both machines (0.241.0, delivered by the floor in 16 and 18 seconds) and proven on the HP with a throwaway Nextcloud.

What broke on the way. Nothing standing. One new finding: after an app is removed, its "held after a failed update" mark stays behind, so a reinstall would start blocked. Cleared by hand, filed (R-491) for the next release. Register: 206 open / 191 closed.

Needs you. The scratch guest: the ruling as written cannot be built — the hub ties one box to one customer, and a second enrolled customer on the HP would replace the HP's own enrolment. Two options: a second guest under the HP's own customer (reversible, tonight-ready, but its reports would clash with the HP's page unless it stays unenrolled), or a nested appliance VM enrolled as its own box (fully enrolled, hours to build). My pick: the first, unenrolled. If you do nothing: tonight's rotation keeps restoring in place and skips the standing nine.

Updated 2026-09-14 (the night of 13→14 — "be a customer for the night", first run). Written in the order the rules ask for.

Decisions I took, so you can undo them. (1) The rules file your brief named (.claude/rules/unprompted-work.md) exists in no repo, and its text did not reach me, so I could not create it; I worked to the fences written in the brief itself. (2) The nine standing apps cannot be the night's throwaway on the same guest (same name), so the rotation starts after them (R-481). (3) There is no scratch guest, so the restore was done in place: remove the app, keep its backups, restore, read the data back. (4) One controller release (0.240.0), two catalog changes, no hub change.

What I exercised. AdventureLog as a family: install, sign-up, a Balaton trip with three places, visits, a packing note, an edit and a delete — all through the app's own API; backup now + second copy; remove with "delete my data"; restore; the guarded Update; remove with "delete backups".

What broke. The second-drive restore was refused after a removal that kept the backups (the box had forgotten the copy existed). The PostGIS database was not treated as a database, so it had no proper dump. The backup card said "no backups" over 484 MB. A removed app is invisible on both backup pages. "Delete backups" left everything behind. The app served Django debug pages to the internet. Photo upload fails from any non-browser client. A glance fresh install crash-looped.

What I fixed and proved live. Controller 0.240.0 (delivered by the floor in 16 s and 18 s): the forgotten copy, the PostGIS dump, the backup card, "delete backups" now deletes, the stale failure sentence, the slow off-site check, the old-install copy. Catalog: DEBUG off for AdventureLog; glance now lands healthy on a fresh install. Docs and gates: the observations gate reads every section; the target-selection runbook names real paths; the catalog now refuses an image move that forgets its catalog_since date.

What I filed. R-481 (scratch guest, your decision), R-483 (photo upload needs a browser check), R-487 (removed apps invisible on the backup pages), R-488 (a 5-minute test package), R-489 (the removal reports null over volumes it removed), R-490 (the monitoring page's memory card has never shown, its data call is answered 404).

Register. Before: 432 156 bytes open / 120 598 closed (212 / 177 rows). After: see the top of OPEN-ITEMS.md — 206 open / 190 closed (R-465 audited and closed, R-490 opened).

Needs you. (a) The rules file text — paste it and I create it in all three repos. If you do nothing: nights run on the brief's fences, as tonight. (b) R-481: how to make a scratch guest (a second enrolled LXC, or an ISO appliance per night). If you do nothing: restores stay in-place and the nine standing apps are never walked. (c) R-483: open AdventureLog in a browser and add a photo to a place. If you do nothing: we do not know whether households can upload photos. (d) R-479 from the afternoon still waits.

Updated 2026-09-13 (fourth pass) — you decided both things. New releases reach the demo machines by themselves again, and an app with any backup can now be updated. Both are live and proven on the HP. Nothing needs you.

Updated 2026-09-13 (third pass) — the Update button now takes a backup first and tells the truth. It is live on both machines and I walked every case on the HP, including putting a broken update back from its backup. TWO THINGS NEED YOU: item 15 (the demo machines no longer get new releases by themselves between golden images) and item 16 (apps with no second-drive copy cannot be updated). Both done the same afternoon.

Updated 2026-09-13 (second pass) — you decided both open items. The database engine now finishes its own conversion on the four MariaDB apps; the upgrade machine proved it and it landed on the HP without a ripple. Goldens are now weekly and before any install, not per release, and the gate knows: it reads a dated permission slip that runs out after 14 days. Today's golden (0.236.0) is baked and live. Nothing needs you.

Updated 2026-09-13 — "delete my data too" now deletes the data, or tells you it could not. Until today the box said it worked and left everything on the drive. Live on both machines (0.236.0), proven on the HP with a throwaway Nextcloud. Nothing needs you. Item 7 is closed: you decided it on 2026-09-02 and the page still listed it open.

Updated 2026-09-06 (third pass) — I chased down the BookStack database problem I found this morning. Good news: it does not get worse, and fixing it costs seven seconds and loses us nothing. The catch I expected — that fixing it would stop us being able to go back — turned out not to be real. TWO THINGS NEED YOU: item 11 (how wide to take the upgrade testing) and item 12 (one small yes/no on the database setting).

Earlier 2026-09-06 (second pass) — I built a machine that upgrades a real app with real data in it and then asks the app whether the data is still there. Three apps, five real upgrades: the data survived every time. It also found a genuine problem in our own BookStack setup.

Earlier 2026-09-06 — a restart no longer changes which version an app runs. Fixes still arrive every 15 minutes, and a broken app definition still repairs itself. Only the Update button moves a version now. Live on the HP (0.235.0). Two old items closed: the Hetzner e-mails are answered, and the Docker Hub login is in place.

Earlier 2026-09-03 — you spotted that OpenGist had no label. You were right, and it was a real gap: the label only appeared on apps something had restarted. Fixed and live (0.234.0). Every app on both machines now carries one.

Earlier 2026-09-02 — the box now writes down which version of each app it is running, and shows one small label saying whether it is up to date: „Naprakész" or „Frissítés elérhető — 52 napja". No version numbers, and nothing about updating changed.

Earlier 2026-09-01 (third pass) — the backup work is FINISHED for beta, and I have written down where it stops. One alarm that was telling you something untrue is fixed and live (hub 0.111.1). ONE THING is waiting on you: two short e-mails to Hetzner, drafted and ready to paste.

Earlier 2026-08-31 — I measured whether the box could test its own remote restore without you, then built the narrow version you picked. The measurement is why it is 3 seconds a night and not an evening's work.

A view, not a source. documentation/backlog/OPEN-ITEMS.md is the authority; this page restates part of it in plain words, and nothing may exist only here. Items, not paragraphs. One screen. If it does not fit, it belongs in the register instead.

Waiting on you

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

1. Two things are waiting on you: item 11 (how wide to take the upgrade testing) and item 12 (a small yes/no about the database setting — I have measured both costs). Item 4 (the Hetzner e-mails) is answered and is being handled in a separate session. Item 7 — the safety-copy decision — was ruled on 2026-09-02 and is now marked closed below (it was not urgent any more: the thing that made it urgent was that a restart could upgrade an app behind your back, and as of today it cannot. Item 10 is new and needs nothing from you. Item 5's alarm mail can now be ignored for good. Otherwise: Both problems the overnight test found are fixed and proven on the real machines:

   • the background job that could delete a live restore's lock now waits its turn — and the check that finds the next one like it is a test, not a comment, so it cannot come back quietly;
   • the nightly backup check now runs on demo-felhom. It said pass there this morning, on a machine where it could not start at all yesterday. The golden carrying both is baked, vouched, and the floor is raised. demo-felhom picked it up by itself in about 20 seconds.

2. Whether to keep the test app bentopdf on demo-hp. I deployed it last night because it is the ONLY app of our 53 with neither a database nor stored files — which makes it the only way to prove the new check does not cry wolf on an app that legitimately has nothing. It passed silently, which is what we needed to see. My pick: keep it, as a permanent control. If you do nothing: it stays, using almost no space. Say the word and I remove it.

3. Nothing else about this release. Everything in 0.232.0 ships in the controller image plus two register lines in the hub (already live). No customer action, no data migration, no credential change.

4. Please send two short e-mails to Hetzner. DONE — you sent them and Hetzner replied (2026-09-06). The reply is being worked in a separate session; nothing about it belongs to the update work. The background below is kept because it is why the questions were asked. felhom.eu/documentation/runbooks/provider-questions-2026-09-01.md — open it, copy, send. No password or key is in that file, and none should be added.

   Why. Yesterday I told you the snapshots make a wiped backup survivable: lose about a day, copy the rest back file by file. The first half is still true. The second half is not, and I found that out by trying it. I tried 777,600 snapshot names on the storage, over nine days, in Hetzner's own naming style. None of them opened. Then I found why: your data and the snapshot door sit on two different drives inside the storage, and the door for your data does not exist at all. So there is no way in from the machines.

   What is still true, and it matters: a machine that wipes its own backup still cannot touch the snapshots of it. The older copy is there. What we do not have is a way to reach it.

   The two questions. One: can the main account pull single files out of a snapshot? Two: on one of Hetzner's own tools, is a "cannot delete" switch forced by them, or chosen by the machine? The second one could remove the whole problem — no new hardware, no moving anyone's data.

   If you do nothing: we cannot finish this. The backups keep working and keep being checked; we simply cannot say what a wiped backup costs, and I would then put this risk back near the top of your list. My pick: send both. It is five minutes and it decides an evening's work.

5. You will have received an alarm email from me today about demo-hp losing 65 backups. It is a test and nothing is wrong. I built the new "someone deleted the backups" alarm and had to fire it once for real to prove it reaches you. Subject: [Felhom] 🔴 demo-hp: offsite_snapshots_dropped. No backups were deleted. If you do nothing: nothing — but please do not act on that one mail. Closed now: that was the only such mail, it was a test, and the alarm's wording has since been corrected (item under Decided below). Nothing further is needed from you here.

6. Whether to change the hub password (R-350). I printed it into my own session log on 20 August. Not in git, not in any saved file — in the log on this machine. If you do nothing: it stays as it is, at the risk you accept by leaving it. I can change it without ever showing you the new one.

7. CLOSED 2026-09-13 — you decided this on 2026-09-02, and the page kept listing it open. The ruling is recorded in documentation/architecture/09-update-architecture.md §3: the safety copy is a verified recent backup as a precondition, not a new copy made for the update; the guest-snapshot idea is to be spiked before anything is built on it. The text below is kept as the record of what was asked.

   Original question: Where should the safety go before an app updates? This is the one decision from today's measurement, and it is a design choice, not a bug report.

   What I measured. The box downloads new app versions by itself every 15 minutes and writes them into the customer's files, whether the app is running or not. Nothing tells the customer. Then the Restart button — not just Update — installs that new version. I watched it download a version that was not on the machine and swap the app onto it in 18 seconds. And the box does it on its own when an app fails to come back after a crash: nobody pressed anything.

   One fear is smaller than we thought, and you should have that too. A plain power cut does not upgrade anything. The apps come back on their old version. It only happens when an app fails to return.

   One fear is bigger. I tested whether we can undo an app update. We cannot. Once an app has moved its data to the new version, putting the old version back gives an app that will not start at all. So "rollback" is the wrong word and I have struck it. The only way back is to restore the customer's data from a copy taken before the update — and today no update takes one.

   The decision, in one sentence: should the safety copy sit under the Update button only, or under everything that can install a new version?

   • Under the button only. Cheap and quick. Covers the case a customer causes. Leaves the unattended path uncovered — the one where an app that failed to come back is upgraded with nobody watching.
   • Under everything. Covers all of it. Costs more, and it has a hard limit I measured: for a big app a copy is roughly 30 minutes and about twice the app's size, against a standard box that ships with 20 GB. A copy of a large app does not fit. So this option cannot be built without also answering where the copy lives.

   My pick: under everything — but decide the "where does it live" question first, because the answer decides whether the rest is even buildable.

   If you do nothing: nothing breaks today, and no customer is at risk this week — the fleet is young and its running versions match the catalog. But the exposure is real and dated: Peti's box has a one-major upgrade of rallly queued behind its next boot, from a catalog change made three days after it went quiet. Who else is blocked: nobody can spec the safe-update work until this is answered, because the two options produce different products.

   Full measurement, with the controls and the quoted output: felhom.eu/documentation/audits/SPIKE-app-update-2026-09-01.md.

8. Nothing here needs you. Two things I got wrong, both now fixed.

   You found the first one. OpenGist showed no label. That was not a misunderstanding — the label only appeared on an app that something had restarted, so an app that simply runs showed nothing, possibly for months. On a quiet machine that is every app, which is exactly the machine we most want to be able to look at. Now the box reads what every app is on when it starts up, and writes it down. It only looks — it starts nothing and changes no app. Live on both machines: all nine apps on the HP now carry a label, and so does OpenGist.

   One thing to expect, so it does not look broken: the label says „Naprakész" when an app is on the newest version, with no number at all. A number only appears when the app is behind — and then it is how long the newer version has been waiting, not how old the running one is. That was your ruling and I think it is still the right one.

   The second one was mine and smaller: a test I wrote pinned a date and an age, so it passed the day I wrote it and failed the next morning. Fixed, and I have written down that the same trap may sit in six other test files — named, not accused; someone has to read them.

   The box now writes down which version of each app it is really running, and shows the customer one small label: „Naprakész" or „Frissítés elérhető — 52 napja". No version numbers — a household cannot act on 26.05.2.

   Both halves are proven on the real machine. I made two apps fail to come back, the box repaired them itself and wrote down exactly what it installed — one line per container, with the fingerprint that cannot lie. I checked those fingerprints against the machine independently and they match. Then I opened the real customer pages and read the labels off them.

   Where I went wrong, because you should not have to spot it twice. I told you the saved password no longer worked on either machine. It worked fine. I read it out of the file wrongly — the value is wrapped in quote marks and I only removed one kind. You caught it in one line. The machine told me "wrong password", which was true, and I took it to mean the password was wrong when it meant what I sent was wrong. I have filed that as a small job for myself: one shared way of reading that file, so the next session cannot get it half right.

   If you do nothing: nothing. This one is closed.

9. Nothing here needs you. The version of an app is now frozen, and only the Update button moves it.

   What used to happen. The box downloaded the catalog every 15 minutes and wrote each app's new definition straight over yours — including a new version. From then on, thirteen different things could install that new version: the Update button, the Restart button, or one of eleven repairs the box performs on its own. Nobody had to press anything.

   What happens now. The version is pinned to what you have. Only a deliberate Update moves it.

   What deliberately did NOT change, because it was worth keeping. Corrections to an app's definition — a fixed health check, a memory limit, a new setting — still arrive on the same 15-minute cycle, and a broken definition still repairs itself. That was a real benefit of the old behaviour and it is intact. In one sentence: while the catalog offers the same version you are running, its fixes reach you; the moment it moves to a newer version, you stay where you are until you choose to update.

   Proven on the real machine, twice over: I pushed a genuine catalog change with no version in it and watched it arrive on the normal cycle; then I pushed a version change and watched the app refuse it.

   Two things this did NOT do, so they are not read as done. The Update button is exactly as safe as it was yesterday — no backup, no undo. That is the next piece of work, and it is item 7. And an app the box could not confidently pin would have been left behaving exactly as before, loudly; on the HP that was none of the nine.

   One rough edge I chose to write down rather than fix: a frozen app still receives the small metadata file that carries its health check, so it can be given a check written for a newer version and look unwell when it is fine. It cannot lose data — the worst case is a false alarm. Freezing that file too would break the „Frissítés elérhető" label, which is a worse trade.

10. How wide should I take the upgrade testing? DECIDED 2026-09-13: as wide as possible, through the nightly unattended sessions. Every app gets its turn as the nightly rotation reaches it, one hand-written way in per app. The apps that can only be reached through a browser wait for the sessions that run on your Windows machine with Chrome, where the machine can click. Written into the update architecture as decision 6. Nothing to do.

11. Shall I tell the database engine to finish its own conversion? DECIDED YES 2026-09-13, and shipped the same day. The four MariaDB apps — BookStack, Kimai, Nextcloud, RomM — now carry one setting that lets the engine convert its own files when it moves to a new major version. Seven seconds, and it backs itself up first. Proven before it shipped: the upgrade machine re-ran the BookStack edge and this time the engine says, in its own words, that it is already upgraded — the "skipped" line is gone, and the data read back afterwards. Watched as it landed: the change reached the HP on the normal 15-minute cycle, nothing restarted by itself, and one deliberate restart came back clean with the app serving. The rule until the next piece is built: the Update button still takes no backup, so no app may move a database engine across a major version until it does — a gate refuses such a change at push time. Nothing to do.

12. "Delete my data too" now deletes the data — or tells you it could not. Until today, when a customer removed an app and ticked the box, the box said it worked and left everything on the drive (128 MB of a Nextcloud on 2026-09-01). The cause: the removal asked one global setting for the drive, and no machine fills that setting in. Every other part of the box already asks the app itself where its data is. Now the removal does too. If the box cannot work out where the data is, it refuses and keeps the app, so you can try again — it never again reports success over data left behind. Proven on the HP with a throwaway Nextcloud: 63 MB the app wrote itself was gone after removal, and the answer listed it; the refusal was shown with the app still in place; an app with no drive data gets a plain "nothing to delete" note. Live on both machines (0.236.0). No standing app was touched. If you do nothing: nothing to do.

13. The Update button now takes a backup first, and tells the truth. Nothing needs you. Before today, pressing Update pulled the new version at once, checked nothing, and said "done" while the app could already be crashing. Now:

    • It refuses first if it must: the app is held, a backup is running, or memory or disk is short. It also refuses if the app has no backup it could be put back from.
    • If the backup is older than a day, it makes a fresh one first.
    • It waits for the app to actually be healthy before it says it worked. The button shows each step.
    • If the new version does not come up, the app is stopped and held. The page names the backup to restore it from. The box never puts the old version back by itself, because we measured that this works for some apps and breaks others.

    Proven on the HP with a throwaway app: a real upgrade, a stale backup, a version that does not exist, a version that never starts, and the restore from the named backup back to the old version. One problem showed up during the test and is fixed: while an update was waiting to see if the app came up, the regular backup copied the broken version into the app's local backup. It now leaves an app alone while it is updating. Live as 0.238.1.

14. New releases reach the demo machines by themselves again. You decided this, and it is done. When I raise the floor for a release, I now also type which agent that release needs. The hub then moves the machines past the golden image. If I leave that value out, the hub refuses to save. Release 0.239.0 reached both machines this way in 15 seconds. Nothing needs you.

15. Apps with no copy on a second drive can now be updated. You decided this, and it is done. The update now uses any backup: the second drive first, then the app's own copy, then the remote copy. If none is younger than a day, it makes a fresh one first. If the new version fails, the page names which backup to restore from. Proven on the HP: an app with only its own copy updated, a broken update was held, and it came back from its own copy. Nothing needs you. Four small things turned up and are written down: the remote check can take 15 seconds (R-477), a leftover backup of a removed app counted as a fresh one (R-478), for some apps their own copy holds only settings (R-479), and the card keeps the old failure sentence after a good restore (R-480).

16. demo-hp's network setup does not match our own notes (R-338) — the machine works, the page is wrong, or the other way round. If you do nothing: the page keeps misleading the next session, as it misled one by an hour.

Decided — and what would reopen each

• GOLDENS ARE NOW WEEKLY AND BEFORE ANY INSTALL, NOT PER RELEASE — AND THE GATE KNOWS. DECIDED 2026-09-13. In August I baked 25 goldens in 26 days, almost one per release, because the check trips on every release on purpose. From today: one golden a week, and always before a drill or a fresh install. Correction, same day: I wrote that every release would still reach both demo machines in about 20 seconds between bakes. That was wrong at first: the hub would not move the machines past the golden image. It is true again since the afternoon: the floor now carries the release when I type which agent it needs (item 15). Release 0.239.0 arrived in 15 seconds. The check now reads a dated permission slip that runs out after at most 14 days; while it is valid the check warns instead of refusing, and when it runs out the check is red again until someone bakes or renews. A dated slip cannot be forgotten — it just expires. Today's golden (0.236.0) is baked, checked three ways, and live. Reopens if: the first outside customer installs (the slip is retired then), or a fresh install ever lands on a golden older than the week.

• THE BACKUP AND RESTORE WORK IS FINISHED FOR BETA. DECIDED 2026-09-01. What is done, and proven on the real machines: everything you or a customer does alone — getting deleted files back, getting an app's data back, getting a whole app back, and losing a drive. The restore tells you what it put back, refuses if there is no room, will not accept a half-copy, and puts your own data back if it fails. What is parked until after beta: everything only I do, with you — rebuilding a machine as itself, losing a whole box, recovering from ransomware, restoring the hub, and losing Hetzner. Six of these have never been timed, and the hub has never been restored. They are written down, they are real, and none of them stops a beta customer. Reopens if: something a customer does for themselves turns out to be broken; or Hetzner's two answers change what the snapshots are worth; or a real customer's data is at stake in one of the parked items.

• The alarm that promised too much: FIXED and live (hub 0.111.1). DECIDED 2026-09-01. Yesterday's alarm mail said a deleted backup was "recoverable file-by-file". We now know it is not. I removed the promise rather than writing a new one, so the sentence stays true whatever Hetzner answers. It no longer says the data is lost either — that is still usually untrue. Reopens if: Hetzner's answers give us a real route back; then the alarm can name it.

• The missing-golden warning is now pointed at the people who can act on it (R-404). DECIDED 2026-09-01, and built the same day. The warning was aimed at the wrong repository: the one where a release actually happens never checked at all, while the one that only holds documents was refused on every push — including the push that RECORDS a golden bake, which is the very act that clears the warning. So the check was blocking its own cure, and we had skipped it thirteen times. What changed: the release repository now prints a reminder the moment a release is committed (it never blocks — you cannot bake a golden for a version you have not pushed yet), and the documents repository still runs the check on every push and still says so loudly, but only refuses a push that touches real code. Every other check still blocks everything, always. Nothing was silenced and no product code changed. Reopens if: a release ever ships without a golden and nobody noticed — that would mean the reminder is not reaching anyone, and the answer would be to make the release repository refuse rather than remind.

• Getting old backups back yourself: NOT BUILT, deliberately. Reopens if: a real customer asks. (R-312)

• The unopenable old copy on demo-felhom: KEPT as a test fixture — the only state in existence where a set-aside store is present and cannot be opened. Delete when: that work ships or is abandoned. (R-313)

• A machine in two kinds of trouble says both things: LEFT AS IT IS. Reopens if: observed outside a constructed test. (R-303)

What works

Both demo machines are home, healthy and reporting — agent 0.130.0 published and running on both. Which controller each box runs, and where the floor sits, is item 1 above and is not restated here — R-395: this paragraph carried a second copy of those numbers, it went stale by seven releases, and the page then disagreed with itself about the thing an operator checks first. Ask the hub (/hosts, /configs) or the box for what is live; a doc is never the authority on a version. Off-site is credentialed on demo-hp and its store opens with the machine's own key.

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

Shipped

• Something finally checks that the off-site copies are still there and readable (R-359 + R-397, controller 0.227.1, proven on demo-hp). Until today nothing did — not the box, not the agent. The whole-machine backups had their own checks; the copies holding your customers' documents and photos had none, so we would have found a problem at restore time, with a customer waiting. Now the box checks its own off-site store about once a week and tells you only if something is wrong. A pass sends no e-mail, on purpose — a weekly "everything is fine" is how people stop reading their alerts. It also catches itself up: it asks „has it been more than seven days?", not „is it Sunday?", so a machine that was switched off on its check day is checked the next day. And it never gets in the backup's way — if a backup or restore is running, the check steps aside and tries again tomorrow. That is not politeness: the tool would otherwise clear a lock that a live backup was holding. Proven live, twice over — a real check against your real store (35 seconds), and a second check fired during the first, which correctly stepped aside without doing anything. Read item 2 under „Waiting on you" for what this check does NOT see.

• The product stopped claiming a check it never ran. The monitoring page said an integrity check ran every Sunday. It did not exist. The e-mail text, the settings checkbox, the hub's side of it and a debug button were all built and wired to nothing (R-397). They now have the missing piece.

• Taking the safety copy no longer destroys the app's own backup (R-361, controller 0.221.1, proven on demo-hp). Before every restore the machine saves a copy of your live database. To do that it called the ordinary backup routine — which always writes to the app's normal backup filename first — so the app's real backup was overwritten and then renamed away. Until the next nightly run the app had no database backup of its own, and a local recovery in that window would have told you the app never had a database. A comment in the code said this could not happen; it could, and had been happening for four months. Proven fixed the only way it can be: the app's own backup file is now byte-identical before and after a restore, on both database types.

• A failed database restore now puts your data back by itself (R-379/R-380, controller 0.220.2, proven on demo-hp). Until today, if a restore of an app's database went wrong, the machine had already taken a copy of your live database — a good copy — and nothing in the product could put it back. You were shown a filename. On one of the two database types it was worse: part of the restore applied, part did not, and the dashboard said the app was healthy. Now the machine puts your own copy back automatically and says plainly: the restore failed, your data is as it was, the app is running. Proven on both database types, byte-identical both times. If even that fails, the app is deliberately stopped and held rather than started — a running app on a half-written database lets you type into it and makes the damage permanent — and you are told to contact us. That was your ruling this morning. Two things also stopped: the error no longer pastes raw database text at you (it was 615 bytes once, including rows out of your own database), and the undo copies no longer pile up forever — three per app, and they were being copied off-site permanently.

• An empty package can no longer wipe out a good one (R-403, controller 0.230.0). Yesterday we wrote this down as suspected and said plainly it had not been tested. We tested it first, and it was real. On a demo machine, on yesterday's build: an app's copy on the second drive went from 120 MB — four database backups and three data archives — to 7 KB, nothing left, in a single nightly run, and the run reported success. The cause was that the nightly job only asked does the folder exist before copying over it, and an empty package is a folder that exists. Now the nightly job refuses to replace a complete package with an empty one. It keeps what it has, says so on the app's own backup page, and carries on with everything else. Proven on the same machine, in the same state: all seven files still there, byte for byte. Two more things came with it. The page no longer calls that copy fresh when the run did not refresh it — it names the real date of the package instead. And after a restore from the second drive, the first drive's package is filled back in immediately, so the empty state that started all this cannot happen again. A copy that legitimately gets smaller still gets smaller; only the one dangerous case is fenced.

• The copy on the second drive can now bring an app back (R-102 + R-103, controller 0.229.0, proven on demo-hp, and delivered — golden 0.229.0 is vouched and the fleet floor is raised, so a machine installed today has it). Every night the box copied each app's whole recovery package onto the second drive — its settings, its database and its data. It did that for months. Nothing could open those copies. No button, no screen, no command. That mattered most in the one fault the second drive exists for: if the first drive dies, the package on it dies too, and the copy that survived could not be read. For 45 of the 53 apps that is everything they own. Now the same restore that always worked from the first drive can read the copy on the second one, and the button is on the app's own backup row. Proved with the first drive's package taken away: Docmost came back in 29 seconds — its database, all three data volumes, a file with a Hungarian accented name back byte for byte, and the app then read its own rows with its own password. Done again with the app's password file also taken away: the copy carried the passwords too (2 of 2). The screen that used to say „press that other button on another page" now offers the action itself. It says plainly that this one overwrites what is there — the gentle „Fájlok visszaállítása" beside it still only adds back missing files — and it names the date of the copy, so nobody puts last week over today by accident.

• We counted the apps this affects, and settled it. Two of our own notes disagreed — 43 or 45. The answer is 45, counted with the product's own rule against the live catalogue. The older count missed radarr and sonarr.

• The off-site restore now works for the other 40 apps (R-356, controller 0.219.0, proven on demo-hp). It used to refuse before starting, tell the customer a running app „nincs telepítve", and send them to reinstall it "to the same place" — a place those 40 apps never offer, because they were never given a drive to choose. It was asking one question to answer two. Proven today on privatebin: data planted through the app itself, backed up, deleted, restored — all 15 files back byte for byte, Hungarian accented names included, message „0 fájl és 1 adatkötet visszaállítva". The 13 apps that do have a drive are unchanged, checked the same way.

• The off-site restore gives an app's data back at all (R-354, controller 0.218.0). It used to say „0 fájl visszaállítva", report success, and the folder was simply not there. It now names what came back, because a restore that mentions only its file count is how a silent loss reads as a success.

• Paperless's database is in the backup, and restoring it takes an undo copy first (R-355, controller 0.218.0). The dump was landing in a folder named after an app that does not exist. One app of 53 was affected, established with a check first proved able to catch a planted second case.

• The system tells you when it cannot see the off-site copies (R-339) — a mail after ~30 minutes, hourly while it lasts, one all-clear. Caveat: it watches whether the machine answers, so it would not have caught the 18 August fault, where one service was wedged and the machine stayed healthy.

• The connection leak was ours and is fixed (R-344). Our agent opened a connection to the off-site box every 15 minutes and never closed it; the idle timer was switched off. Proved by fixing one machine and leaving the other: same work, 4 more leaked on the untouched one, none on the fixed one. The off-site box is back to 17 open connections from 415.

• A dated check can no longer be quietly missed (R-341) — but it speaks on the next push, not on the day. A machine we tell to be quiet is no longer reported as dead (R-321). One name per secret (R-295, R-323). The hub's own words are under a guard (R-324). Removal reverses the installation (R-316). A correct recovery code is no longer called wrong (R-311). The drive can be re-attached after a reinstall (R-280).

Broken, or knowingly incomplete

• We do not know what the deep check costs on a BIG store (R-401). Since 0.228.0 the weekly check re-reads all your stored data, not just the list of it. We had to: a copy was damaged in a way that left its size unchanged, and the old shallow check said „no errors were found". Only the deep check caught it. The cost we measured was four seconds — 35.0 s before, 39.2 s after — but that was on a 134 MB store, and it will not stay four seconds. So the box now tells us: any check that takes longer than five minutes writes a warning naming this item. If you do nothing: every machine re-reads its whole store every week, however large it grows, and the first person to notice would be a customer whose upload is busy. The warning is there so that does not happen.
• We ask the off-site box a question about once a second (R-336) — ~85,000 a day for a box we write to weekly. The leak that made this dangerous is fixed (R-344); the volume is not. The ceiling is under a year away on the corrected measurement, not two.
• Peti's machine has no recovery route at all. A real machine belonging to a real person, silent since 15 July, no key, no off-site copy, no local backup. If that drive fails, everything on it is lost. First act of any visit: copy the ~3.6 GB off before anything is reinstalled.
• The agent picks dnsmasq by looking at a file another package owns (R-317) — one line; LAN name resolution goes missing quietly.
• Three facts the machines send still have no reader (R-264); the storage page has its own reason for an empty list (R-298); two thirds of the standing picture is unproven (R-326: 23 of 55 claims walked — python3 scripts/unproven.py); the picture still describes one defect we fixed twice (R-327).

Working on next

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