docs: Phase 2b fail-closed gate LIVE-validated on AdventureLog

Demo has no dashboard password (API open: auth+CSRF both skip in that mode), driven
via the public URL. AdventureLog's unit manifest carries data_key_env_vars=[SECRET_KEY]
(catalog->manifest live); with SECRET_KEY unrecoverable, POST /backup/restore REFUSED
with the exact fail-closed message before any compose-up. Full deploy-with-data e2e
blocked by the 8G guest rootfs (AdventureLog images too big — the Phase 3 concern, live).
CHANGELOG/REPORT/CONTEXT updated; demo left clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-13 12:35:08 +02:00
parent 1ed20c7069
commit d8fe8f5ead
3 changed files with 29 additions and 14 deletions
+11 -7
View File
@@ -71,15 +71,19 @@ persist. (This is what "self-update handles version drift" refers to.)
→proceed, values used verbatim), the full orchestration (success→recreate-with-merged-env;
data-key-missing→refused, recreate never called), and `data_key` parsing from `.felhom.yml`.
## Validation status (honest)
## Validation status
- **Unit/integration-tested (authoritative):** the fail-closed gate, the restore orchestration, secret
reconciliation (regenerate-nothing), and the catalog→metadata `data_key` flow.
- **Live-validated:** the capture side (v0.53.1, RomM — secret-free unit, NO_LEAK grep); v0.54.0 deployed
+ healthy + capture regression clean.
- **PENDING (auth-gated):** the full live **readable-data e2e** vs AdventureLog (deploy with an
encryption key → back up → restore → confirm data decrypts) needs triggering the session-authed
`/backup/restore` from the dashboard. `bootstrap.json` carries no web credential and the password is a
bcrypt hash, so this needs an operator-run (or the demo dashboard password).
- **Live-validated (guest 9201):** the capture side (v0.53.1, RomM — secret-free, NO_LEAK). For Phase 2b
on **AdventureLog** (a real data_key app): its unit manifest carries `data_key_env_vars: [SECRET_KEY]`
(catalog→manifest flow live); and with `SECRET_KEY` made unrecoverable, `POST /backup/restore`
**refused** with the exact fail-closed message **before any compose-up** (no side effects). The demo
has no dashboard password → the API is open (auth + CSRF skipped), driven via the public URL.
- **One e2e not run — environment limit, not a code gap:** the full "deploy with data → restore →
confirm decrypts" — AdventureLog's images do not fit the **8 GB guest rootfs** (deploy hit "no space
left on device"). That is precisely the Phase 3 rootfs-headroom concern, now observed live.
Key-preservation is covered by the gate's verbatim-recovery unit test. Demo left clean (AdventureLog
reverted to not-deployed, no leftovers).
## Still ahead
Phase 3 (auto off-drive Tier 2 with rootfs-headroom guard) and Phase 4 (FileBrowser scoping + deploy-UI