v0.301.0: R-518, R-638, R-717 (MinAgent 0.131.0)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

controller/README.md

@@ -1294,7 +1294,10 @@ The nightly backup has two phases that run sequentially. All paths are **per-dri
 > **Multi-tier whole-guest backup (v0.174.0, R-82 Slice B).** The agent can serve SEVERAL whole-guest
 > backup tiers with independent cadences — "local daily + PBS weekly" (agent >= v0.97.0,
 > `GET /backup/tiers`). The controller owns quiescing, so it reconciles them: it collects EVERY due
-> tier up front and runs them inside **ONE quiesce window** — one stop, N sequential backups (vzdump
+> tier up front. **Since v0.301.0 (R-518, `09` §3 decision 156) a window runs ONLY the first due tier and resumes the
+> apps at its `snapshotted`; the next due tier waits for a later cycle with its own short stop, and „Mentés most" makes
+> the LOCAL copy only (nothing, and no stop, when the local storage is absent). The rest of this paragraph is the
+> pre-v0.301.0 rule, kept for history:** it ran them inside **ONE quiesce window** — one stop, N sequential backups (vzdump
 > holds a guest lock), one resume. Two cycles on the weekly night would mean two app outages for one
 > night's work. The app stays quiesced until the **LAST** tier snapshots, so every tier is
 > app-consistent; the consequence is that both-due-night downtime is *(first tier's full backup)* +
@@ -1878,6 +1881,10 @@ appear in the restore dropdown with per-app snapshot filtering.
 
 **Tier 1 restore** (`RestoreApp`):
 - Stop app → resolve app's home drive → `restic restore <id> --target / --include <path>...` → populate Docker volumes from restored tars → restart app → health check
+- **v0.301.0 (R-638):** with a database dump, the no-manifest fallback starts ONLY the database services, replays, then
+  starts the app (before, the whole stack started at the current definition first); a dump with no identifiable
+  database service is refused before anything is touched; a failed volume step skips the replay. A unit restore whose
+  volume leg failed does not replay either.
 - Restore paths: config dir, DB dump dir, volume dump dir, HDD mounts
 - Docker volumes restored via `restoreDockerVolumes()`: `docker volume rm -f` → `docker volume create` → `docker run alpine tar xf`
 
@@ -2011,6 +2018,9 @@ that folder is never a dead end, and an install never runs into it silently (R-6
   into app.yaml + one `compose up -d`, or a command) set when the gate opens, after the block. The window lifts and the
   loop re-applies it. `POST /apps/<slug>/close-signup` for an app installed before the rule: lock record
   (`opened_by: close-signup`), block, switch; never a gate. Code: `internal/stacks/after_setup.go`.
+  **v0.301.0 (R-717):** `open_command` / `open_success` reopen a command-closed switch for the household's 15-minute
+  window (marked `opening` on disk first; a failed open closes it again and the page says so); `command` runs again at
+  the window's end, at every start and after a successful update; a failed close is retried every 2 min.
 - **The family gate (v0.287.0, decisions 63/64)** — `.felhom.yml` `family_gate: true` puts a PERMANENT door in front of
   the app: only the household's family members (each with their own name and password, „Család" card on the security
   page) and the household itself get through; `family_gate_except:` lists literal path prefixes left to the app's own