# REPORT — restore edges, the escrow timeout, the host OOM count: on main, NOT released (night 2026-10-28 → 29, unattended)

**Plain words first.** Four commits are on main, each with CI green and each new test seen failing first. Nothing is
released: the night brief allowed no release. The controller release goes on the morning list. It needs no new MinAgent:
with an older agent the OOM count answers 404 and the controller waits 10 minutes before it asks again.

**Decided by CC unattended — operator may reverse:** an unused restore copy goes after 14 days (options: 14 days, for
ever, 3 days; `07` §6.3 [DESIGN] 2026-10-28). H4 and H5's failed-stop branch keep only test proofs; their live proof is
owed to an attended session (or revert those two branches of `342a394`).

## Commits

| Commit | CI (run id / #) | What |
|---|---|---|
| `342a394` | 2469 / #532 green | **R-1256** four restore edges. H4: an off-site restore whose definition write fails writes the LIVE definition back before the start; a failed write-back holds the app. H5: a put-back whose stop fails pours nothing, keeps the copy, holds the app; a failed definition write-back keeps the copy (D20); a `volume rm -f` that fails fails that volume (no merge on top of the old content). H6: a restore begins in ONE step with the check for a restore, the backup run and a second-drive copy (`TryBeginRestoreOp`); every restore button and both kept loads begin that way. H8: `SweepUnusedRestoreCopies`, every 6 h. |
| `e33cffa` | 2472 / #533 green | **R-1254** controller half: escrow claim/confirm wait 60 s (the agent's own upload wait is longer than the old 15 s); an unknown outcome is 504 `api.escrow.confirm_store_unknown` („keep both codes"), hu + en. |
| `eed23e7` | 2474 / #534 green | **R-528**: the 30-s OOM scan also reads the host's per-container `oom_kill` (agent `GET /guest/oom-kills`); a counted kill raises `app_oom` whatever Docker's flag says; `source` in the details. |
| `20c5877` | 2475 / #535 green | An action on a name that is no app answers 404, not „settings cannot be saved" (found walking the capability map). |

Red-proofs: felhom.eu `documentation/audits/night-2026-10-28/redproofs/README.md`.

## Live proof (test build `0.347.0-rc.n1028`, local tag only, never pushed)

- **H5, scratch 9202:** vikunja's first volume held by a created-only container, the household's restore pressed through
  the page: „Failed to remove volume vikunja_vikunja_data before the restore … (not written into)", the restore failed,
  the put-back poured the live copy of both volumes, the app ran, no hold; a project from before the restore point AND
  one from after it read back.
- **H8, scratch 9202:** three copies planted by hand (2026-10-01, 2026-10-05, 2026-10-28); the first sweep at 03:29 UTC
  removed the two older than 14 days and kept the young one (8 ms). The young one was then removed by hand.
- **R-528, Tester 1:** one `app_oom` „seen by docker,cgroup", one mail with `"source":"docker,cgroup"`.
- **Not live:** H4 (off-site only; 9202 has no off-site target), H5's failed stop and crash put-back, H6 (the old
  code also refused at the early check, so a live press cannot tell the two apart). Tests only.

Both boxes put back after. **Scratch 9202** (2026-10-29 04:14 UTC): controller 0.346.1 healthy, the test image removed, the
live catalog (config byte-identical to the saved copy), no throwaway app, no planted restore copy, no volume made
tonight. **Tester 1** (2026-10-28 23:30 UTC): controller 0.346.1, agent 0.167.0 (sha256 `28bdd282…`), the test app
removed. The bench is stopped. Hub: nothing provisioned.

Evidence: felhom.eu `documentation/audits/night-2026-10-28/` (`r1256-restore/`, `r528-oom/`).