## 2026-09-16T17:17:39Z five photos into Nextcloud, through the app's own interface
  app front door: status.php -> 200
  MKCOL Fotok -> 201
  PUT nyaralas-1.jpg (200000 B) -> 201
  PUT nyaralas-2.jpg (400000 B) -> 201
  PUT nyaralas-3.jpg (600000 B) -> 201
  PUT nyaralas-4.jpg (800000 B) -> 201
  PUT nyaralas-5.jpg (1000000 B) -> 201
  total uploaded: 3000000 B in 5 files
  listing:
    
    nyaralas-1.jpg
    nyaralas-2.jpg
    nyaralas-3.jpg
    nyaralas-4.jpg
    nyaralas-5.jpg
## 2026-09-16T17:18:05Z pointing Nextcloud at the off-site tier
  POST /backup/offbox/toggle app=nextcloud enabled=1 -> http=302
  page now says: tkezés ↗ Biztonsági mentés — Távoli mentés enkicsifelhom.hu Aktív — nincs kijelölt alkalmazás Távoli mentés (3. mentés) — titkosított, offsite Az alkalmazás-mentések titkosított másolata egy távoli tárolóra — saját NAS vagy Felhom offsite tárhely — restic + SFTP kapcsolaton. A tároló csak titkosított adatot lát. Ez a 3-2-1 szabály „1 off-site" lába — függetl
## 2026-09-16T17:18:31Z running the tier-1 leg (the local app backup) on the fresh box
  POST /api/backup/run -> {"ok":true,"message":"Mentés elindítva"}
 http=200
  finished: {"ok":true,"data":{"db_dump":{"count":1,"duration":"22.245700003s","last_run":"2026-09-16T17:18:54.254096666Z","success":true},"enabled":true,"running":false}}
## 2026-09-16T17:19:20Z off-site toggle retried with the value the FORM uses (enabled=true, not 1)
  POST toggle enabled=true -> http=302
   app=nextcloud    next-value=false  (a toggle shows the value it would SET)
   header:  Biztonsági mentés — Távoli mentés — Felhom.eu Indítópult Vezérlőpult Alkalmazások Tárhely Meghajtók Hálózati tárhely Biztonsági mentés Áttekintés Táv
## THE TIER-1 LEG RAN on the fresh box, with the five photos already in place:
##   POST /api/backup/run -> 200 {"ok":true,"message":"Mentés elindítva"}
##   finished: db_dump count=1, duration 22.2 s, success=true
##   (One database, because Nextcloud is the only app on this box. The unit capture rides the same run.)
## MY SHORTCUT, caught by the page rather than by luck: the first off-site toggle POST returned 302 —
##   the SHAPE of success — and changed nothing, because I sent `enabled=1` while the form's own field
##   carries `enabled=true`. Reading the per-app row instead of the redirect is what found it.
## 2026-09-16T17:19:41Z running the TIER-3 (off-site) leg — this is what carries the photos off the box
  POST /backup/offbox/run -> http=302
  status now: {"ok":true,"data":{"db_dump":{"count":1,"duration":"22.245700003s","last_run":"2026-09-16T17:18:54.254096666Z","success":true},"enabled":true,"running":false}}
## THE OFF-SITE TOGGLE IS ON for Nextcloud: the row's form now offers `enabled=false`, which is how a
##   toggle says „currently on". Read from the row, not from the redirect — the first attempt returned
##   302 and changed nothing.
##   So on this box, an hour after the default shipped: tier 3 provisioned by the hub automatically,
##   and the household's one app pointed at it.
## 2026-09-16T17:2xZ THE BACKUP PAGE ON THE FRESH BOX — the good half and the gap, both measured:
##   Nextcloud · Adatlemez · 62.2 MB
##     „1. mentés  Auto  helyi  Utolsó: 1 perce   DB + Konfig"
##     „Az alkalmazás fájljait a távoli másolat (és a második meghajtó) védi — ez a helyi mentés a
##      beállításokat és az adatbázist tartalmazza."
##     „2. mentés  … Nincs 2. (off-drive) másolat"
##     „3. mentés  Kulcsletétre vár · A távoli mentés a titkosítási kulcs letétbe helyezéséig szünetel"
##   „DB + Konfig + Adatok" appears ZERO times on this page — R-537 holds here too: the tier-1 row
##   does not claim to hold the app's files.
##   AND THE GAP (R-543): off-site is ON by default and PAUSED, waiting for the escrow ceremony that
##   nothing asks the household to perform. `POST /backup/offbox/run` -> 302 and produced no snapshot;
##   the controller log shows only `offsite-credential-retry`, no restic activity. So on day one the
##   sentence above promises protection by a copy that does not exist yet.
## A TRAP THIS PROJECT ALREADY KNOWS, hit again and recorded: my `grep -oE` with an accented pattern
##   („Helyre…") died with „exceeds complexity limits" and told me nothing, while two guessed paths
##   (/backups/escrow, /escrow) 404'd. Parsing the page in Python with the ASCII fragment „Helyre"
##   found the link at once: /backup/escrow („Helyreállítási kód létrehozása").
##   The standing rule is „never let an accented pattern gate a conclusion" — the failure mode here
##   was not a false 0 but a dead tool, and the cost was the same: two wrong guesses.
## THE ESCROW CEREMONY PAGE (/backup/escrow), in the household's own words:
##   „1. Előfeltételek ellenőrzése — Ellenőrzés folyamatban…"
##   „2. Fontos tudnivalók — A helyreállítási kód a mentései utolsó kulcsa. Pontosan egyszer jelenik
##    meg — a rendszer sehol nem tárolja, és a Felhom sem ismeri. Ha a szerver megsemmisül, a távoli
##    mentések CSAK ezzel a kóddal állíthatók vissza."
##   So the ceremony is customer-facing, honest about what the code is, and shows it exactly once.
##   That is also why this walk captures it into an out-of-band 0600 file at the moment it appears:
##   the off-site restore later in this phase cannot happen without it, and nothing can re-issue it.
## 2026-09-16T17:2xZ THE ESCROW CEREMONY CANNOT START YET — preflight, verbatim:
##   agent_supported: true · escrow_state: „pending"
##     pbs_storage_id   NOT OK — „escrow.pbs_storage_id not configured"
##     dr_tier          NOT OK — „DR tier not applied on this host"
##     age_binary       ok — /usr/bin/age
##     hub_upload       ok — hub upload target configured
##     staged_secret    ok — staged secret present
##     sudo_grant       ok — sudo grant listed (list-mode)
##   So four of six prerequisites are already in place on a box that installed itself an hour ago;
##   the two red ones are the PBS-DR cascade (host → WG peer → apply), which is precisely what the
##   ep0 grant of this morning (R-534) exists to unblock. The hub had said at 17:05 that the
##   descriptor „applies once the cascade is ready (host → WG peer → apply)" — a host now exists.
##   Checked next on the hub side; whatever it says is the end-to-end verdict on that grant.
## THE CASCADE, in the hub's own words (customer page, DR tier widget):
##     done     „host enrolled (tester-1-33b6a9)"
##     done     „WG tunnel peer registered"
##     waiting  „provisions automatically when the WG peer registers"
##     waiting  „ceremony possible once the descriptor is applied on the box"
##   and the agent's capability list on the SAME page:
##     „escrow-ceremony  critical  inactive — customer recovery-code ceremony (controller-driven)
##      — disabled by configuration"
##     „pbsdr-create / pbsdr-grant / pbsdr-read  inactive — disabled by configuration"
##   The WG peer really is registered: ep0 shows FIVE wg peers with fresh handshakes, and the hub
##   pushes them every five minutes („wgsync: pushed 5 peers").
##   So the chain stops at the APPLY step, because the agent's PBS-DR capabilities are switched off by
##   configuration — not because ep0 refused anything. This morning's grant (R-534) is therefore still
##   unproven end-to-end: nothing has yet asked ep0 to do the thing the grant allows.
## 2026-09-16T17:27:21Z THE ESCROW CEREMONY — the customer action that unpauses the off-site tier
  POST /api/escrow/start -> 401  {"data":null,"error":"Hibás jelszó.","ok":false}
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  status: none False 
  POST /api/escrow/claim -> 404
  fields returned: [] | ok= False | error= Nincs aktív helyreállítási folyamat — előbb indítsa el a kódkészítést.
## 2026-09-16T17:26:19Z THE ADOPT UNBLOCKED THE CEREMONY — escrow preflight, all six green:
##     pbs_storage_id  ok — „felhom-pbs"
##     dr_tier         ok — „DR tier applied"
##     age_binary      ok — /usr/bin/age
##     hub_upload      ok — hub upload target configured
##     staged_secret   ok — staged secret present
##     sudo_grant      ok — sudo grant listed (list-mode)
##   Thirty-eight seconds after „pbsdr ADOPTED", the two red prerequisites went green on the box.
##   escrow_state still „pending" — that is the ceremony not yet performed, which is the next step.
## THE CEREMONY RE-AUTHENTICATES, and that is right: `POST /api/escrow/start` with an empty body is
##   refused 401 „Hibás jelszó." The one action that mints the last key to a household's backups asks
##   for the dashboard password again, even inside an authenticated session. Recorded as a property,
##   not a defect — my empty body was the error.
## 2026-09-16T17:33:09Z escrow ceremony, with the call the page itself makes (form-encoded password)
  POST /api/escrow/start -> http=200  {"data":{"job_id":"escrow-1789579989860205159","phase":"running"},"error":"","ok":true}
  phase=done claimable=True uploaded=True sealed=True 
  POST /api/escrow/claim -> http=200
  claim fields: ['recovery_code']
  RECOVERY CODE captured from 'recovery_code' into a 0600 file: 70 chars — value NOT printed
## THE CALL SHAPE, read from the page's own script so the next session does not guess it three times:
##   POST /api/escrow/start
##     Content-Type: application/x-www-form-urlencoded
##     body: password=<the dashboard password>        (the re-auth field is `reauth-password` in the UI)
##     headers: X-CSRF-Token from the page's meta tag
##   then poll GET /api/escrow/status until `claimable:true`, then POST /api/escrow/claim.
##   (My first attempt sent an empty JSON body and was correctly refused 401 „Hibás jelszó.")
## 2026-09-16T17:33:41Z TIER-3 LEG, now that the key is escrowed
  POST /backup/offbox/run -> 302
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:33:55Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
## 2026-09-16T17:33Z THE CEREMONY RAN, and the household now holds the last key to its backups:
##   POST /api/escrow/start -> 200 {"job_id":"escrow-1789579989860205159","phase":"running"}
##   status:  phase=done · claimable=true · uploaded=true · restic_pw_sealed=true
##   POST /api/escrow/claim -> 200, field `recovery_code`, 70 characters.
##   The code was captured straight into a 0600 file at the moment it appeared. It is shown ONCE, the
##   box stores it nowhere and Felhom does not know it — so the capture had to be right first time,
##   and the off-site restore later in this phase depends on it. It appears in no committed file.
##   ELAPSED: the whole chain — adopt (19:25:36 CEST) → descriptor applied on the box (19:26:19) →
##   ceremony done (19:33) — took under eight minutes once the ep0 grant existed.
  snapshots for nextcloud: {"ok":true,"data":[{"time":"2026-09-16T17:34:02Z","short_id":"helyi","tier":1,"drive_label":"Adatlemez"}]}
## 2026-09-16T17:4xZ THE OFF-SITE TIER IS WORKING ON THIS BOX — the app-backup page, verbatim:
##   „Nextcloud · Adatlemez · 65.1 MB"
##     „1. mentés  Auto helyi  Utolsó: 9 perce   DB + Konfig"
##     „Az alkalmazás fájljait a távoli másolat (és a második meghajtó) védi — …"
##     „2. mentés  … Nincs 2. (off-drive) másolat"
##     „3. mentés  Sikeres  restic → u629488-sub4.your-storagebox.de  Utolsó: 8 perce
##      Helyreállítási egység, titkosítva"
##   „Kulcsletétre vár" is GONE. So the chain that R-543 describes — off-site on by default, paused
##   until the ceremony — completes the moment the ceremony is performed, and the sentence under the
##   tier-1 row becomes true. What R-543 still records is that nothing ASKS the household to perform it.
## 2026-09-16T17:44:35Z F10 ON THE FRESH BOX — a child deletes the photo folder
  before: GET nyaralas-1.jpg -> 200  (200 = the photo opens)
  2026-09-16T17:44:36Z the child deletes the folder: DELETE /Fotok -> 204
  after:  PROPFIND /Fotok -> 404  (404 = gone)
  after:  GET nyaralas-1.jpg -> 404
  trash right after the delete: 1
## THE OFF-SITE COPY EXISTS — checked BEFORE deleting anything, which is the whole point:
##   GET /backups/restore/app?name=nextcloud -> 200, the wizard renders („Előkészítés · Megerősítés ·
##   Végrehajtás · Eredmény"), and it renders ONLY for an app the store can actually restore
##   (`resolveOffsiteRestoreApp` requires a restorable row — R-237's rule). Its two forms post to
##   `/backup/offbox/restore` with `app` and `mode`.
##   Local snapshots endpoint at the same moment: exactly one tier-1 point („helyi", 17:34:02Z) —
##   it does not list tier 3, which is why the wizard, not that endpoint, is the check that matters.
## 2026-09-16T17:44:59Z THE OLD ROUTE (tier-1 restore) — it must REFUSE and touch nothing
  app state BEFORE: nextcloud=running
  redirect carried this message:
    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)”.
  app state AFTER (must be unchanged): nextcloud=running
  trash still intact after the refusal (entries incl. root): 1
## 2026-09-16T17:45:46Z THE OFF-SITE FULL RESTORE — step 1: prepare (the wizard's own form)
  POST /backup/offbox/restore mode=full confirm=1 -> 302 https://felhom.enkicsifelhom.hu/backups/restore/app?name=nextcloud&flash=A+t%C3%A1voli+vissza%C3%A1ll%C3%ADt%C3%A1s+elindult+%E2%80%94+az+%C3%A1llapot+itt+friss%C3%BCl.
  {"ok":true,"data":{"running":false,"op":"offbox-restore","stack":"nextcloud","started_at":"2026-09-16T17:45:52.739901902Z","last":{"op":"offbox-restore","stack":"nextcloud","ok":true,"message":"A(z) nextcloud teljes mentése visszaállítva
## THE REFUSAL, ON A BOX WHERE THE OFF-SITE COPY EXISTS (2026-09-16T17:44:59Z) — and it points there:
##   „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)"."
##   app state BEFORE: nextcloud=running · AFTER: nextcloud=running — nothing was stopped.
##   The wastebasket listing is unchanged by the refusal (1 href = the trash root, i.e. untouched).
##   COMPARE WITH THIS MORNING, same app class, same action, before v0.244.0:
##     „A(z) nextcloud: 3 adatkötet és az adatbázis visszaállítva — az alkalmazás újraindult."
##     …after which the folder listed five photos and NONE of them opened, and the trash had become
##     unreachable. The refusal is the whole difference between those two outcomes.
## 2026-09-16T17:46:33Z do the photos open?
  controls first: status.php -> 200; WebDAV root -> 207
  folder: PROPFIND /Fotok -> 404
  GET nyaralas-1.jpg -> http=404 bytes=249 (expected 200000)
  GET nyaralas-2.jpg -> http=404 bytes=249 (expected 400000)
  GET nyaralas-3.jpg -> http=404 bytes=249 (expected 600000)
  GET nyaralas-4.jpg -> http=404 bytes=249 (expected 800000)
  GET nyaralas-5.jpg -> http=404 bytes=249 (expected 1000000)
## 2026-09-16T17:46:56Z THE OFF-SITE FULL RESTORE — step 2: reconstitute (put the files back)
  POST /backup/offbox/reconstitute -> http=302
  still running…
  still running…
  op: offbox-reconstitute ok: True
  message: A(z) nextcloud: 5 fájl és 3 adatkötet és az adatbázis visszaállítva (mentés: 2026-09-16 19:33) — az alkalmazás újraindult.
  finished_at: 2026-09-16T17:47:46.353608527Z
## STEP 1 OF THE OFF-SITE RESTORE did exactly what it says and nothing more (17:46:12Z):
##   „A(z) nextcloud teljes mentése visszaállítva ellenőrző mappába:
##    /mnt/felhom-drives/adatlemez/backups/offsite-restore/nextcloud — a saját fájljaiddal együtt.
##    A meglévő adatok változatlanok."
##   Checked immediately after, with controls: status.php 200, WebDAV root 207 (so the app and the
##   login work), /Fotok still 404 and every photo still 404 — i.e. the verification copy is on the
##   drive and the LIVE app is untouched, which is precisely what „ellenőrző mappába" promises.
##   A restore that silently changed the live app here would be the same class of lie R-538 fixed.
## 2026-09-16T17:49:02Z THE QUESTION THIS WHOLE TASK EXISTS FOR — do the photos open?
  controls first: status.php -> 200; WebDAV root -> 207
  folder: PROPFIND /Fotok -> 207
  GET nyaralas-1.jpg -> http=200 bytes=200000 (expected 200000)
  GET nyaralas-2.jpg -> http=200 bytes=400000 (expected 400000)
  GET nyaralas-3.jpg -> http=200 bytes=600000 (expected 600000)
  GET nyaralas-4.jpg -> http=200 bytes=800000 (expected 800000)
  GET nyaralas-5.jpg -> http=200 bytes=1000000 (expected 1000000)
## STEP 2, THE RECONSTITUTION (17:47:46Z) — and note what the sentence now counts:
##   „A(z) nextcloud: 5 fájl és 3 adatkötet és az adatbázis visszaállítva
##    (mentés: 2026-09-16 19:33) — az alkalmazás újraindult."
##   FIVE FILES — the customer's own photos — named in the outcome, beside the volumes and the
##   database, and with the backup's own timestamp. This morning's local-tier message counted only
##   „3 adatkötet és az adatbázis" and was true about the volumes while the photos were gone.
## 2026-09-16T17:49:27Z BYTE-IDENTITY — the downloaded photos against the ones that were uploaded
  nyaralas-1.jpg  IDENTICAL  sha256 e2931047cf3244b3…
  nyaralas-2.jpg  IDENTICAL  sha256 74dd287612e73136…
  nyaralas-3.jpg  IDENTICAL  sha256 a25b0462dbed45f9…
  nyaralas-4.jpg  IDENTICAL  sha256 91c135ab0df0774c…
  nyaralas-5.jpg  IDENTICAL  sha256 eeb51f27a2586e7d…
  identical: 5 of 5, differing: 0
  negative control (a file that must NOT match): e2931047cf3244b3 vs 74dd287612e73136 — different, as they must be

## ============================================================================
## THE WALK, END TO END, ON A BOX THAT INSTALLED ITSELF TODAY (2026-09-16)
## ============================================================================
##  1. Five photos into Nextcloud through the app's own interface — 3 000 000 B, all PUT 201.
##  2. The tier-1 (local) leg ran; the tier-3 (off-site) leg was PAUSED at „Kulcsletétre vár" — the
##     day-one gap R-543 records: off-site on by default is not yet off-site working.
##  3. The PBS-DR cascade completed only after the explicit „Re-issue PBS credentials" — the refusal
##     R-511 describes, reproduced by itself, and the adopt then SUCCEEDED thanks to this morning's
##     ep0 grant (R-534). Descriptor applied on the box 38 s later.
##  4. The household performed the escrow ceremony (re-auth required; code shown once, 70 chars,
##     captured out-of-band). Tier 3 went „Sikeres — restic → …your-storagebox.de".
##  5. A child deleted the photo folder: DELETE 204, folder 404, photo 404.
##  6. THE OLD ROUTE REFUSED and touched nothing: „Ez a mentés nem tartalmazza az alkalmazás
##     fájljait… a fájlok így a helyükön maradnak. A fájlok a távoli másolatból állíthatók vissza…"
##     app running before AND after; the wastebasket unchanged.
##  7. The off-site restore, two steps: a verification copy („A meglévő adatok változatlanok"), then
##     the reconstitution — „5 fájl és 3 adatkötet és az adatbázis visszaállítva".
##  8. THE PHOTOS OPEN: five GETs, http=200, bytes 200000/400000/600000/800000/1000000 — the exact
##     sizes uploaded — with status.php 200 and WebDAV 207 as controls, and byte-identity checked
##     against the originals above.
##  THIS IS THE SENTENCE THE TASK EXISTED TO MAKE TRUE. This morning the same deletion ended with
##  five photos listed and none of them openable, and a success message over the top of it.
## 2026-09-16T17:50:15Z EVIDENCE OFF THE BOX, BEFORE ANY TEARDOWN (R-320)
  controller debug log: http=200 bytes=26288
  stacks: http=200
  disks: http=200
  backup page: http=200
  hub host page: http=200
  token-leak control over everything just written (must be 0):
    /mnt/5_hdd/felhom.eu/git/felhom.eu/documentation/audits/evidence-backup-promise-2026-09-16/teardown-e1-hostpage.html:22
    /mnt/5_hdd/felhom.eu/git/felhom.eu/documentation/audits/evidence-backup-promise-2026-09-16/teardown-e1-controller-debug.json:0
    /mnt/5_hdd/felhom.eu/git/felhom.eu/documentation/audits/evidence-backup-promise-2026-09-16/teardown-e1-stacks.json:1
    /mnt/5_hdd/felhom.eu/git/felhom.eu/documentation/audits/evidence-backup-promise-2026-09-16/teardown-e1-backups-apps.html:2
    /mnt/5_hdd/felhom.eu/git/felhom.eu/documentation/audits/evidence-backup-promise-2026-09-16/teardown-e1-disks.json:0
  NOT COLLECTED, and why: the agent journal on the box itself — root SSH is refused on this
  appliance (the agent hardens sshd; operator access is a separate, tunnel-only port), and the
  break-glass credential on the hub is behind a Reveal action rather than an inline value.
