felhom.eu/documentation/audits/the-28-2026-09-22/BODY-part1.md

---

What this night is, in three lines

• Interventions: SEVEN — over the brief's limit of five, and six of the seven were my own harness, not the product. Three were bugs in tonight's driver that cost apps their walk and were fixed mid-run (a missing import re; a variable that shadowed the app's metadata; a crash when the Update was refused before any phase existed). Two were deliberate method changes (recording a REFUSED restore as its own verdict; making the harness wait for a restore to settle before removing). One was a waiter that deadlocked on its own command line. The seventh was the product's: three leftovers it could not clear, which a shell had to.
• 26 of 28 deployed; 6 proven; 5 inconclusive; 14 with no upstream edge; 1 failed honestly; 2 that could not be deployed — one of those by design.
• The one result that matters most: an app with no health probe at all has its working installation stopped by a successful update. paperless-ngx was healthy on all three containers; the Update ran the full five-minute health wait and then held the app, and the controller named the reason itself — no probe container. R-630 is raised to P1.

---

The two findings that are not about any single app

R-633 — a remove sent while a restore is still running reports success and leaves an orphan

gokapi was restored from its own local copy at 11:34:07 and removed at 11:34:22. POST /backup/restore answers 302 and does its work in the background; the remove tore down what existed, and the restore's own compose up then re-created the container at 11:34:24. Both calls returned success.

Twenty-five minutes later, GET /api/stacks/gokapi reads deployed: false while docker ps -a shows gokapi Restarting (1) with its full Traefik label set still attached — including traefik.http.routers.gokapi.rule: Host(.enkisfelhom.hu), a rule with an empty subdomain, because the deploy values that filled it were deleted with the app. Its own log loops „Salt for admin password invalid… password does not appear to be a SHA-1 hash" — the volume holding its config was removed correctly, so the binary can never start.

A household can press exactly those two buttons in that order. The product accepted both and the remove reported success while leaving the orphan; nothing in the alarm ladder can fire, because 08 §4 keys on stacks the controller still knows about. This is R-626's class with the mechanism finally visible — that row saw a removed navidrome come back and could not diagnose it, because the controller had restarted and its log no longer reached the moment. Here the window is seventeen seconds and both halves are in the evidence.

The harness was then fenced against its own race, so every app after gokapi measures the product. Evidence: apps/gokapi/came-back-evidence.txt.

A restore that is REFUSED is the product being right, and nearly went down as a failure

calibre-web is a class-A app (07 §6.2): it has a readable file leg, and the local Tier-1 copy does not hold it. The restore was refused, with this sentence:

„Ez a mentés nem tartalmazza az alkalmazás fájljait, ezért nem állítjuk vissza az adatbázist föléjük — a fájlok így a helyükön maradnak. A fájlok a távoli másolatból állíthatók vissza: Biztonsági mentés → Visszaállítás, „Teljes visszaállítás (fájlok + adatbázis)"."

That is exactly what 07 §6.2 predicts, it names the action that does work, and it refuses before touching anything. The first version of tonight's harness recorded it as a failed restore. A harness that calls a correct refusal a failure buries the best result of the night, so refusals are now recorded as their own verdict and the sentence is quoted.

One real upstream edge HELD honestly — outline 1.9.1 → 1.10.1

The most valuable single result after R-630, because it is the guarded update's own promise exercised on a real upstream version rather than a staged one.

phase	at
safety-dump	0.0 s
pulling	+1.1 s
starting	+64.8 s
verifying	+65.8 s
failed	+368.6 s

The app was stopped and held, and the sentence the household reads names the tier, the date and what the copy contains:

„A(z) outline frissítése 2026-09-22 14:50-kor nem sikerült, és az alkalmazás nem indult el az új verzióval. Az alkalmazás biztonsági okból leállítva marad, hogy az adatai ne sérüljenek. Visszaállítható a Mentések oldalon ebből a biztonsági mentésből: saját meghajtó, 2026-09-22 14:44 — ez a másolat a beállításokat, az adatbázist és az adatköteteket tartalmazza."

The restore named in that sentence was then walked and the app came back. outline must not be promoted.

Two refusals that are the product guarding itself, and both name the blocker

• The Update refuses while a backup or restore runs: „A frissítés most nem indítható: mentés/visszaállítás folyamatban. Próbáld újra, ha befejeződött."
• A second restore refuses and NAMES the app that is blocking it: „Egy visszaállítási művelet (jellyfin) már fut, ezért most nem indítható újabb."

That second guard is exactly the fence R-633 is missing. The product already knows how to refuse a conflicting operation and how to say which one — for update and for restore. remove has no such guard, which is why a remove sent during a restore reports success and leaves an orphan.