R-341 check taken, and the golden-currency bypass declared

Two gates blocked the R-331 hub push. One is FIXED, one is BYPASSED, and the
difference is stated rather than blurred.

FIXED -- due-checks (R-341, 5 days overdue). The +7d measurement was TAKEN on
ep0 rather than deferred again. Precondition passed: proxy still MainPID 551655,
ps -o lstart= still 2026-08-18 09:51:04, NRestarts=0, so this is the same proxy
generation as t0 (anchor is ps, not ActiveEnterTimestamp, which reads 03:54:54Z
here -- R-346's trap).

Result: fd = 17. Not 17 more -- seventeen TOTAL, exactly the documented
baseline, against 405 at the first check. Socket histogram: one LISTEN, ESTAB 0,
CLOSE-WAIT 0.

The verdict is UNANSWERABLE, not "the upgrade fixed it". R-341 asks whether the
PBS 4.2.5-1 upgrade changed the fd slope; inside this interval we removed the
leak OURSELVES (R-344, agent 0.130.0, now live on both boxes). A slope of ~0
measures our fix, not the upgrade, and reading it the other way would credit a
changelog that was read in advance and found to contain no such mechanism. The
perturbation pre-registered for this window was Phase C at ~3%; the actual
perturbation was the removal of the entire phenomenon. Row closed as moot.

What it DOES establish is worth more than the original question: twelve days
after the R-344 fix, same proxy generation, no restart to hide behind, ep0 sits
at baseline with zero established connections. R-336's ~323-day runway concern
retires with it.

BYPASSED -- golden-currency. Controller v0.224.0 and v0.225.0 are released and
the newest golden bake carries 0.223.0, so a machine installed right now gets
neither. The gate is RIGHT. This push therefore uses `git push --no-verify`,
declared here, in hub/CHANGELOG.md, in REPORT.md and on R-242.

A BYPASS, not a waiver: the gate offers a waiver only for a release that
DELIBERATELY needs no golden, and these need one. The operator was asked and
ruled bypass-now-bake-later, on the ground that neither fix bites a day-0 box --
R-330 is a nightly false alarm about apps a new box has not installed yet, R-331
is a hub display over backups a new box has not taken yet -- and both arrive by
self-update. That ground is recorded because it is what to re-check: it does NOT
extend to a release changing first-boot behaviour.

OWED: bake a golden carrying 0.225.0 and vouch it (RUNBOOK-manual-build.md 4.1,
three-field change, MinAgent 0.129.0). Fourth bypass of this gate, and the gap
is now two releases wide rather than one.

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

.claude/rules/docs.md

@@ -0,0 +1,46 @@
+---
+paths: ["documentation/**"]
+---
+
+# Documentation — routing and register discipline
+
+`documentation/` is the **authoritative design home for the whole Felhom system**, not just this
+repo. Sibling repos point here; this is where the pointed-at thing must actually be.
+
+## Where a fact goes — one home each
+
+| Fact | Home |
+|---|---|
+| the locked design | `architecture/01..05-*.md` |
+| capability status + its evidence | `architecture/00-capability-map.md` |
+| host addresses, routes, node names, break-glass, what is provisioned | `operations/nodes.md` |
+| Tailscale topology, accept-dns/accept-routes | `operations/tailscale.md` |
+| which box may be broken, and what may be done to it | `runbooks/target-selection.md` |
+| an operational procedure | `runbooks/RUNBOOK-*.md` |
+| logging levels and phrasing | `runbooks/logging-conventions.md` |
+| a spike or campaign result | `audits/` |
+| every open finding | `backlog/OPEN-ITEMS.md` |
+| the operator's one-screen view | root `STATUS.md` |
+
+**Do not restate a fact that has a home** — point at it. Re-check an address rather than trusting one
+written down.
+
+## Register discipline
+
+The end-of-session register rules (`OPEN-ITEMS.md` first, `STATUS.md` is a view, nothing exists only
+in a report) are in the repo core `CLAUDE.md` **deliberately** — they apply to every session that
+ships or decides something, not only to sessions that touch `documentation/`, so they must load
+unconditionally. This file adds only the routing above.
+
+## The coupling rule
+
+**A recipe or contract section is a TWO-REPO change.** If a document here defines something a sibling
+consumes — a DR recipe's producers, an allow-list, an event type — the consumer's code and this
+document move in the same session, or the hub silently drops what it does not recognise.
+
+## Version literals
+
+**No component version literal in any instruction file, and none in a doc that reads as current
+fleet state.** Versions change several times a day and the fleet is not uniform. A *historical*
+citation ("fixed in hub v<X>") is fine in an audit or an HTML comment beside the rule it justifies —
+it cannot go stale the way "this box currently runs agent v<Y>" can.

.claude/rules/hub.md

@@ -0,0 +1,72 @@
+---
+paths: ["hub/**"]
+---
+
+# Hub — architecture, constraints, deploy
+
+## What the hub is
+
+Operator backend. Authors operator *intent*, mirrors box *reality*, holds **no data-plane role**, and
+**never connects inbound to a box**. If it dies, apps keep serving; only management degrades.
+
+Three inbound contracts, and one is frozen: the agent's host-domain report
+(`POST /api/v1/host-report`, the heartbeat/dead-man's-switch), the legacy controller report
+(`POST /api/v1/report`, **frozen until the slice-10 cutover — do not modify**), and structured
+controller events (`POST /api/v1/event`, gated by `allowedEventTypes`).
+
+Everything else — checkers, the two-tier notification dispatcher, the app-mail relay, customer-config
+and Day-0 artifact-manifest management, the operator UI — is mapped in **`REUSE.md`**. Full design:
+`documentation/architecture/05-hub-architecture.md`.
+
+## The two stack constraints
+
+The dependency list is `hub/go.mod`'s business and the deploy shape is `manifests/`. Only these two
+cannot be read off the code:
+
+- **No web frameworks.** Go stdlib `net/http` + `html/template`, and it stays that way.
+- **Secrets via out-of-band `secretKeyRef` — never inline `stringData`** (`REUSE.md` §3).
+
+## Deploy — GitOps, and the manifest is the truth
+
+**Full runbook: the `felhom-build-deploy` skill.** The load-bearing rules:
+
+- **A code change + CHANGELOG bump deploys NOTHING.** The running image changes only when
+  `manifests/hub.yaml`'s `image:` tag changes in git and the app is synced.
+- **Pin explicit versions, never `:latest`. Never bare `kubectl set image` / `kubectl apply`** —
+  reverted on the next sync.
+- **The live image can lag the CHANGELOG** when a bump was committed but the manifest/sync step never
+  happened — reconcile via the manifest, not the changelog.
+- Green gate before any hub commit: `go build ./... && go vet ./... && go test ./...` in `hub/`.
+
+## Rules that bite here
+
+- **Seam-wiring — it covers TEMPLATE GATES:** a feature is not shipped until its entry point is
+  reachable. Any conditional affordance (`{{if .Flag}}` around a button, form or script) ships with a
+  render test **per branch of the gate**. Handler tests that POST directly prove nothing about
+  reachability.
+- **A health check issues no block I/O.** A probe that touches a wedged device enters uninterruptible
+  sleep, survives `SIGKILL`, and cannot be recovered until the device returns or the host reboots —
+  so `systemctl restart` hangs too. A timeout protects the caller's control flow and nothing else:
+  the blocked thread remains. Liveness is decided from `/proc` and kernel state, never by reading or
+  writing the filesystem.
+- New event types must enter `allowedEventTypes` **and** `customerMessages` together, or `POST
+  /event` 400s.
+- Status logic: OK (report < 30m), WARN (30m–1h or `health=warn`), DOWN (> 1h or `health=fail`).
+  Host-liveness thresholds are **shared** between UI and checker — never invent a second definition.
+- SQLite timestamps vary in format — always `parseSQLiteTime()`.
+- **Logging**: DEBUG = flow detail, INFO = state change + duration; operator English; keys never
+  values (`documentation/runbooks/logging-conventions.md`). The bundle secret-gate fails closed.
+
+<!--
+Seam-wiring / template gates: the fourth inert seam, hub v0.70.1. The v0.70.0 ghost-delete was fully
+implemented server-side and fully dead UI because the button sat inside the wrong gate.
+
+Health check / block I/O: measured, R-117 spike §6.3
+(documentation/audits/SPIKE-r117-bind-liveness-2026-07-30.md): a probe stayed in D state 3m50s after
+kill -9; a buffered write with no fsync blocked too (O_CREAT needs journal access); and
+statfs/getdents returned HEALTHY on a namespace that EIOs every byte — fast, and wrong.
+
+This rule is duplicated in felhom-agent/.claude/rules/health-checks.md and
+felhom-controller/.claude/rules/gates.md. That is deliberate: all three write health checks, and a
+pointer to a sibling repo's rule file does not load.
+-->

.claude/rules/manifests.md

@@ -0,0 +1,33 @@
+---
+paths: ["manifests/**", "**/*.yaml"]
+---
+
+# Manifests — ArgoCD, deliberate sync, secrets
+
+## One app, and auto-sync is OFF
+
+The whole cluster is GitOps via a **single ArgoCD app `felhom`** syncing this repo's `manifests/` to
+the `felhom-system` namespace. **Auto-sync is OFF — a deploy is a deliberate manual sync.**
+
+ArgoCD's source of truth is the **manifest in git**:
+
+- Committing a manifest change deploys nothing until the app is synced.
+- **Pin explicit image versions, never `:latest`.**
+- **Never bare `kubectl set image` / `kubectl apply`** — the next sync reverts it, so the fix looks
+  like it worked and then silently disappears.
+- Sync method (hard-refresh + sync, local `sudo kubectl`): the **`felhom-build-deploy`** skill.
+
+## Secrets
+
+- **Out-of-band `secretKeyRef` only — never inline `stringData`** (`REUSE.md` §3).
+- `manifest_bearer_gate.py` fails on any bearer-shaped literal anywhere under `manifests/`. It runs
+  from `python3 scripts/repo_gates.py`.
+
+## The two git-syncs in `webpage.yaml`
+
+`manifests/webpage.yaml` runs **two** git-syncs and they track different refs: the website from
+`main`, and `/scripts/` from the tag `installer-v<SCRIPT_VERSION>`. Changing either `--ref` changes
+what real machines download — the init container **and** the sidecar both carry it, and both must
+move together. `hostinstall_gates.py` gate 6 fails if the manifest stops naming an `installer-v…`
+tag or if the website stops tracking `main`. The full publish/rollback procedure is the R-110 fence
+in the repo core `CLAUDE.md`.

.claude/rules/website.md

@@ -0,0 +1,36 @@
+---
+paths: ["website/**"]
+---
+
+# Website — build, deploy, and the encoding fences
+
+## Deploy
+
+The website **auto-deploys via git-sync from `main`** — just push, live in 1–2 min. No ArgoCD sync,
+no image build. Emergency edits: https://files.felhom.eu.
+
+**Do NOT pin the website to the installer tag.** The sparse-checkout used to cover `/website/` and
+`/scripts/` in one sync; pinning that would turn every copy edit into a release. The installer's
+tag-based publishing is a separate mechanism — see the R-110 fence in the repo core `CLAUDE.md`.
+
+## Gates
+
+Website changes go through `python3 scripts/repo_gates.py`, which runs `site_gates.py`. **A new page
+must be added to that gate's `PAGES` list** or it is unchecked.
+
+`site_gates.py` asserts: BOM, emoji, nav/footer consistency, analytics, CDN, design tokens, and
+cache-busting.
+
+## The encoding fences
+
+- **All `website/` HTML is UTF-8 *with BOM*. Preserve it.** An editor that strips the BOM is a
+  silent, whole-file change.
+- **Emoji count is zero.** The design system forbids them; the gate enforces it.
+- Cache-busting: bump the asset query string when CSS or JS changes, or browsers serve the old file
+  and the change looks like it did not deploy.
+
+## Copy
+
+Customer-facing copy is **Hungarian**, and its tone and terminology rules live in the
+**`felhom-ui-design`** skill — use it rather than inventing phrasing. Operator-facing text is
+English.

.gitea/workflows/gates.yml

@@ -21,9 +21,28 @@ on: [push]
 jobs:
   gates:
     runs-on: felhom-gates
+    # R-265: A RUN THAT HANGS MUST FAIL ITSELF, LOUDLY AND WITH A LOG.
+    #
+    # Run 264 (2026-08-08) took 834 s and was reaped by the platform, leaving NO log at all — the
+    # log fetch returns HTTP 500 "264.log.zst: file does not exist". Every honest run in that same
+    # session finished in 18–34 s, and every real gate failure finished in under 35 s WITH a log. So
+    # the alarm mail below arrived pointing at a run log that does not exist, telling the operator
+    # "the failing gate names itself in the run log" when nothing could.
+    #
+    # 5 minutes is ~9x the slowest honest run and far under whatever reaped 264, so a hang now ends
+    # as a JOB failure — which produces a log and a step record — rather than as a platform reap,
+    # which produces neither.
+    #
+    # ⚠ WHAT THIS DOES NOT ANSWER, and must not be read as answering: whether the `if: failure()`
+    # alarm step runs at all for a REAPED job is still UNKNOWN. This makes the reap unreachable in
+    # practice; it does not tell us what happens in it. Recorded as still open in R-265.
+    timeout-minutes: 5
     steps:
       - name: Fetch the pushed commit
         run: |
+          # R-265: the start stamp the alarm reports, so a mail can never again describe a run
+          # without saying how long it took.
+          echo "GATES_STARTED_AT=$(date +%s)" >> "$GITHUB_ENV"
           # Shallow, and pinned to the exact SHA that was pushed — not to the branch tip, which can
           # move under us if two pushes race. Probe P3 proved the two are equal when done this way.
           git init -q .
@@ -32,6 +51,47 @@ jobs:
           git checkout -q FETCH_HEAD
           echo "checked out $(git rev-parse HEAD)"
 
+      - name: Fetch the agent (wire-contract gate needs BOTH sibling repos)
+        # G-1's gate (scripts/wire_contract_gate.py) compares what one component EMITS against what
+        # the other can RECEIVE, so it needs the source of the controller AND the agent, not just a
+        # CHANGELOG. Without this the gate exits 2 (INCONCLUSIVE) and CI is red for ever.
+        #
+        # ⚠ THIS STEP WAS MISSING FOR ONE COMMIT AND CI WENT RED, exactly as the alarm mail below
+        # predicts: "if the local pre-push hook was GREEN, then CI and the hook disagree — that is a
+        # finding about the gates themselves". It was. The pre-push hook runs on a workstation where
+        # every sibling is a real clone, so a gate needing a sibling passes locally and is
+        # INCONCLUSIVE here; the two homes are NOT interchangeable and a new gate must be checked in
+        # both. Fixed by giving the gate what it needs — never by letting it skip, which would be
+        # the fail-open shape and would leave it running in NEITHER home (R-29).
+        run: |
+          git init -q ../felhom-agent
+          cd ../felhom-agent
+          git remote add origin http://gitea.gitea-system.svc.cluster.local:3000/admin/felhom-agent.git
+          git fetch -q --depth 1 origin main
+          git checkout -q FETCH_HEAD
+          echo "agent at $(git rev-parse --short=12 HEAD)"
+
+      - name: Fetch the controller CHANGELOG (golden-currency gate needs the sibling repo)
+        # R-242's gate compares the newest RELEASED controller against the newest golden baked here,
+        # and it reads the released version from the sibling clone's CHANGELOG.md — the same sibling
+        # assumption reuse_refs_check.py and instructions_gate.py already make on a workstation.
+        #
+        # CI checks out ONE repo, shallow, so without this the gate exits 2 (INCONCLUSIVE) and CI is
+        # red for ever. **A permanently-red CI is the detector-nobody-hears failure this whole
+        # workflow exists to prevent**, so the fix is to give the gate what it needs rather than to
+        # let it skip: a silent skip would be the fail-open shape, and the gate would then run in
+        # NEITHER of its two automated homes.
+        #
+        # Depth 1, pinned to main, and only this repo's CHANGELOG is used. If the fetch fails the
+        # gate still reports INCONCLUSIVE rather than passing — not knowing is never a pass.
+        run: |
+          git init -q ../felhom-controller
+          cd ../felhom-controller
+          git remote add origin http://gitea.gitea-system.svc.cluster.local:3000/admin/felhom-controller.git
+          git fetch -q --depth 1 origin main
+          git checkout -q FETCH_HEAD
+          echo "controller CHANGELOG at $(git rev-parse --short=12 HEAD): $(head -1 CHANGELOG.md)"
+
       - name: Run the gate entry point
         # The ONLY thing CI runs. No go build, no go test, no linting, no deploy — those are either
         # already reliably run by a person or none of CI's business. The exit code IS the result:
@@ -53,7 +113,7 @@ jobs:
           RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}
         run: |
           python3 - <<'PY'
-          import json, os, sys, urllib.request, urllib.error
+          import json, os, sys, time, urllib.request, urllib.error
 
           key = os.environ.get("RESEND_API_KEY", "")
           if not key:
@@ -65,6 +125,18 @@ jobs:
           run  = os.environ.get("GITHUB_RUN_NUMBER", "?")
           srv  = os.environ.get("GITHUB_SERVER_URL", "https://gitea.dooplex.hu")
 
+          # R-265: how long the run took, so a reap is self-identifying. An honest gate failure
+          # lands in well under a minute; a multi-minute figure means the job hit its own timeout
+          # and the interesting question is the runner, not the gates.
+          started = os.environ.get("GATES_STARTED_AT", "")
+          try:
+              # An ABSENT stamp is "unknown", never a number. Defaulting to 0 would print an elapsed
+              # of ~1.7 billion seconds, which is a confident wrong answer — the exact failure mode
+              # this whole session is about.
+              elapsed = "%d s" % (int(time.time()) - int(started)) if started else "unknown (no start stamp)"
+          except (TypeError, ValueError):
+              elapsed = "unknown (unparseable start stamp %r)" % started
+
           body = json.dumps({
               "from": "Felhom CI <monitoring@felhom.eu>",
               "to": ["admin@felhom.eu"],
@@ -73,12 +145,18 @@ jobs:
                   "The gate entry point exited non-zero.\n\n"
                   "Repository : %s\n"
                   "Commit     : %s\n"
-                  "Run        : %s/%s/actions/runs/%s\n\n"
-                  "The failing gate names itself in the run log.\n\n"
+                  "Run        : %s/%s/actions/runs/%s\n"
+                  "Elapsed    : %s\n\n"
+                  "The failing gate names itself in the run log - WHEN THERE IS ONE. A run that\n"
+                  "hung and was reaped by the platform leaves no log at all (R-265, run 264: 834 s,\n"
+                  "log fetch 500). The job now times out at 5 minutes so that case should fail as a\n"
+                  "job and keep its log; if Elapsed above is minutes rather than seconds, suspect\n"
+                  "the runner before the gates, and if the log is missing say so rather than\n"
+                  "guessing which gate it was.\n\n"
                   "If the local pre-push hook was GREEN for this commit, then CI and the hook\n"
                   "disagree - that is a finding about the gates themselves, not about CI, and it\n"
                   "outranks whatever the push was for.\n"
-              ) % (repo, sha, srv, repo, run),
+              ) % (repo, sha, srv, repo, run, elapsed),
           }).encode()
 
           req = urllib.request.Request(

.githooks/pre-push

@@ -29,6 +29,41 @@ root=$(git rev-parse --show-toplevel 2>/dev/null) || {
 }
 cd "$root" || exit 1
 
+# ── WORKSPACE-ROOT ASSERTION (2026-08-05, R-204 rider) ───────────────────────────────────────────
+# Refuse a push from a clone outside the felhom workspace.
+#
+# WHY THIS IS A HOOK AND NOT A LINE IN A DOCUMENT: the workspace root is ALREADY written down, in
+# documentation/runbooks/workspace-CLAUDE.md and in the workspace-root CLAUDE.md ("stay inside it"),
+# and work drifted into a home directory anyway. A rule that has failed once as a reminder is not
+# fixed by writing it down again — it has to be asserted where it can bite.
+#
+# A PUSH IS THE RIGHT TRIGGER, deliberately: throwaway clones under /tmp for probes and red-proofs
+# never push, so nothing legitimate breaks. Reads and builds elsewhere stay unaffected.
+#
+# Symlinks are resolved on BOTH sides before comparison, so a symlinked path neither falsely passes
+# nor falsely fails. If the workspace root does not exist on this machine the check is SKIPPED, not
+# failed — this hook must not brick a legitimate clone on a different host.
+#
+# The only bypass is the documented `git push --no-verify`, whose use is already reportable.
+FELHOM_WORKSPACE_ROOT=/mnt/5_hdd/felhom.eu
+if [ -d "$FELHOM_WORKSPACE_ROOT" ]; then
+    ws_real=$(cd "$FELHOM_WORKSPACE_ROOT" 2>/dev/null && pwd -P) || ws_real=""
+    root_real=$(pwd -P) || root_real=""
+    if [ -n "$ws_real" ] && [ -n "$root_real" ]; then
+        case "$root_real/" in
+            "$ws_real"/*) : ;;  # inside the workspace — proceed
+            *)
+                echo "pre-push: PUSH REFUSED - this clone is OUTSIDE the felhom workspace." >&2
+                echo "          clone:    $root_real" >&2
+                echo "          expected: under $ws_real (repos live in $ws_real/git/<repo>)" >&2
+                echo "          Work in the workspace clone, or bypass with 'git push --no-verify'" >&2
+                echo "          and state that you did in the session report." >&2
+                exit 1
+                ;;
+        esac
+    fi
+fi
+
 if ! command -v python3 >/dev/null 2>&1; then
     echo "pre-push: FAIL - python3 not found, so the gates CANNOT run. This is a failure, never a" >&2
     echo "          pass by default. Install python3, or push with --no-verify and say so." >&2

CLAUDE.md

@@ -1,241 +1,143 @@
-# CLAUDE.md — Project Instructions for Claude Code (`felhom.eu`)
+# CLAUDE.md — `felhom.eu`
 
-> Read automatically when Claude Code works in this repo. Stable orientation only — **current state
-> lives in `CONTEXT.md` and the tops of `hub/CHANGELOG.md` / `scripts/CHANGELOG.md` /
-> `website/CHANGELOG.md`**, never here. Cross-repo orientation (the felhom system, artifact
-> taxonomy, access): workspace-root `/mnt/5_hdd/felhom.eu/git/CLAUDE.md`; this file is
-> `felhom.eu`-specific. A versioned copy of that workspace file lives at
-> `documentation/runbooks/workspace-CLAUDE.md`.
+> Stable orientation only — **current state lives in `CONTEXT.md` and the tops of
+> `hub/CHANGELOG.md` / `scripts/CHANGELOG.md` / `website/CHANGELOG.md`**, never here. Cross-repo
+> conventions (the three-component model, artifact taxonomy, access, clean-tree gate, secrets):
+> workspace-root `/mnt/5_hdd/felhom.eu/git/CLAUDE.md`, whose versioned copy is
+> `documentation/runbooks/workspace-CLAUDE.md`. Path-scoped detail: `.claude/rules/`.
 
-## Project overview
+## What this repo is
 
-This repo contains:
-- **Website** (`website/`) — static HTML at felhom.eu, served via k3s nginx + git-sync sidecar.
-- **Hub** (`hub/`) — Go application (felhom-hub), the **operator backend**, on k3s at `hub.felhom.eu`.
-- **K8s manifests** (`manifests/`) — k3s deployment manifests for felhom-system services.
-- **Architecture docs** (`documentation/`) — the **authoritative design home for the whole Felhom
-  system**: `architecture/01..05-*.md`, `proxmox-platform.md`, `tests/phase*-findings.md`,
-  runbooks, audits. Read these before designing.
-- **Skills** (`skills/`) — the versioned source of the Claude Code skills
-  (`felhom-build-deploy`, `felhom-ui-design`, `felhom-testing`, `felhom-app-catalog`);
-  install/update with `python3 scripts/install_skills.py` (symlink into `~/.claude/skills/` on
-  POSIX, junction on Windows — either way repo edits are live immediately).
+Four surfaces in one repo, plus the design home for the whole system:
 
-See `README.md` for full architecture/DNS/email/SEO docs. See `TASK.md` for the current task (if any).
-See `REUSE.md` before writing new code.
+- `hub/` — **felhom-hub**, the operator backend (Go, k3s, `hub.felhom.eu`).
+- `website/` — static HTML at felhom.eu, served by k3s nginx + git-sync.
+- `manifests/` — k3s manifests for felhom-system, GitOps via one ArgoCD app.
+- `scripts/` — the **public installer** (`felhom-host-install.sh`) and this repo's gates.
+- `documentation/` — the **authoritative design home for all of Felhom**, not just this repo.
+- `skills/` — versioned source of the Claude Code skills; install with
+  `python3 scripts/install_skills.py` (symlink — repo edits are live immediately).
 
-## The Felhom system (so the hub's role is in context)
+## Doing X → read Y
 
-Felhom is **Proxmox-based**, with a locked **three-component model**:
-- **Hub** (this repo, `hub/`) — operator backend. Authors operator *intent*; mirrors box *reality*;
-  holds **no data-plane role** and never connects inbound to a box.
-- **Host agent** (repo `felhom-agent/`) — one per Proxmox host; owns all Proxmox interaction.
-- **In-guest controller** (repo `felhom-controller/`) — one per customer LXC; Docker-only.
+| Doing | Read |
+|---|---|
+| writing any new code | `REUSE.md` — helpers, seams, extension points, traps |
+| needing current state / roadmap | `CONTEXT.md` |
+| hub work (architecture, deploy, patterns) | loads itself: `.claude/rules/hub.md` |
+| website or installer work | loads itself: `.claude/rules/website.md` |
+| manifests / ArgoCD / secrets | loads itself: `.claude/rules/manifests.md` |
+| writing or routing a document | loads itself: `.claude/rules/docs.md` |
+| build, deploy, publish, verify a version | the **`felhom-build-deploy`** skill |
+| writing or reviewing a test, fixing a bug | the **`felhom-testing`** skill |
+| UI, tokens, badges, Hungarian copy | the **`felhom-ui-design`** skill |
+| host addresses, break-glass, node facts | `documentation/operations/nodes.md` — never restate them |
+| which box may I break | `documentation/runbooks/target-selection.md` |
+| what version is live anywhere | ask the hub (`/hosts`, `/configs`) or the box — **never a doc** |
+| the authoritative design | `documentation/architecture/01..05-*.md` |
 
-## Hub — architecture (version-free; current version = `manifests/hub.yaml` image tag)
+## Code quality
 
-The hub ingests two report streams — the agent's host-domain report (`POST /api/v1/host-report`, the
-heartbeat/dead-man's-switch) and the legacy controller report (`POST /api/v1/report`, **frozen until
-the slice-10 cutover — do not modify**) — plus structured controller events (`POST /api/v1/event`,
-gated by `allowedEventTypes`). Around them: staleness/disk/storage-fill/leaf/capability monitor
-checkers, the two-tier notification dispatcher (operator English / customer Hungarian, Resend,
-cooldowns), the app-mail relay, customer-config + Day-0 artifact-manifest management (the checksum
-trust root the host bootstrap verifies against), assets serving, and the password-gated operator web
-UI. Package map, helpers, seams, extension points: **`REUSE.md`** (e.g. new event types must enter
-`allowedEventTypes` + `customerMessages` together).
-
-## Code quality rules
-
-- Always double-check generated code for bugs, logic issues, syntax errors.
-- Handle edge cases without overcomplicating.
-- Add debug capabilities (logging, verbose output).
 - If you need more input or troubleshooting output, **ask first — don't guess**.
-- Testing doctrine (non-hollow tests, red-proofs, seams): use the `felhom-testing` skill.
-- **Seam-wiring rule — and it covers TEMPLATE GATES (fourth inert seam, hub v0.70.1):** a feature
-  is not shipped until its entry point is reachable. For UI, any conditional affordance
-  (`{{if .Flag}}` around a button/form/script) ships with a render test per branch of the gate —
-  handler tests that POST directly prove nothing about reachability. The v0.70.0 ghost-delete was
-  fully implemented server-side and fully dead UI because the button sat inside the wrong gate.
-- **A `go test -run` pattern that matches no test prints `ok` and exits 0.** Found 2026-08-02 while
-  red-proofing: `-run TestCustomerUnified` matched nothing in the target file and reported
-  `ok … 0.062s`, which was read as a passing red-proof. **A red-proof that uses `-run` must first
-  prove the filter matched something** (`-v` and look for `=== RUN`). This is the "an absent line is
-  not evidence" rule aimed at the one place a false green costs most — the proof itself. The same
-  class bit twice that day: a `| tail -5` inside a census query silently dropped rows and looked
-  exactly like a real finding. **An instrument that can drop results silently is not a measurement.**
-- **A health check issues no block I/O.** A probe that touches a wedged device enters uninterruptible
-  sleep, survives `SIGKILL`, and cannot be recovered until the device returns or the host reboots — so
-  `systemctl restart` hangs too. A timeout protects the caller's control flow and nothing else: the
-  blocked thread remains. Liveness is decided from `/proc` and the kernel's own state, never by reading
-  or writing the filesystem. Measured, R-117 spike §6.3
-  (`documentation/audits/SPIKE-r117-bind-liveness-2026-07-30.md`): a probe stayed in `D` state 3m50s
-  after `kill -9`; a buffered write with no `fsync` blocked too (`O_CREAT` needs journal access); and
-  `statfs`/`getdents` returned **healthy** on a namespace that `EIO`s every byte — fast, and wrong.
-- UI/design work (tokens, gates, copy rules): use the `felhom-ui-design` skill.
-- **Logging**: levels/English/no-secrets rules per `documentation/runbooks/logging-conventions.md`
-  (DEBUG = flow detail, INFO = state change + duration; logs are operator-tier English; keys never
-  values — the hub's bundle secret-gate blocks violating pulls fail-closed).
+- **A `go test -run` pattern that matches no test prints `ok` and exits 0.** A red-proof using `-run`
+  must first prove the filter matched something (`-v`, look for `=== RUN`). Generally: **an
+  instrument that can drop results silently is not a measurement.**
 
-## Workflow & artifacts
+<!--
+go test -run: found 2026-08-02 while red-proofing — `-run TestCustomerUnified` matched nothing in the
+target file and reported `ok ... 0.062s`, which was read as a passing red-proof. This is the "an
+absent line is not evidence" rule aimed at the one place a false green costs most: the proof itself.
+The same class bit twice that day — a `| tail -5` inside a census query silently dropped rows and
+looked exactly like a real finding.
+-->
 
-The planning/architecture assistant ("project Claude", in claude.ai) writes specs and validates
-pushes; **you (Claude Code) implement**. A file being open in the editor is NOT an instruction.
+## The installer publishes by TAG, not by push (R-110)
 
-- **`TASK.md` / `TASK-*.md`** — a spec for you to implement. Then push and update `hub/CHANGELOG.md`
-  and root `REPORT.md` per the convention below.
-- **`RUNBOOK-*.md`** — an operational procedure. CC executes the steps it has access and capability
-  for, including live validation on the demo nodes and the demo Proxmox host (CC has root@felhom-pve
-  SSH + the felhom-agent token). Mark a step HUMAN only when it genuinely needs physical presence, a
-  real-world decision, or credentials CC truly lacks.
-- Validation of a push against a spec's criteria is project Claude's job, not yours, unless asked.
-- **Browser automation is NOT available** in the DooPlex environment (`claude-in-chrome` was a
-  Windows-workstation capability). Validate at the endpoint level — invoke the exact endpoint the UI
-  invokes — and via render tests; say which method was used. The hub UI is operator-password-gated
-  anyway, so render tests were already the method for UI changes. Strict end-to-end UI coverage is a
-  manual click-through by the operator.
+This fence is in the core deliberately: its trigger is editing `scripts/felhom-host-install.sh`, and
+no path-scoped rule covers that file. It governs the one artifact that runs **as root on a virgin
+box**.
 
-> **In every repository where you make a change, update both files in that repo:**
-> - **`CHANGELOG.md`** — cumulative log, newest on top (here: per-area `hub/`, `scripts/`, `website/`).
-> - **`REPORT.md`** — **overwrite** with the most recent implementation/validation summary only.
->   **Parallel sessions:** `REPORT.md` is overwritten, so two sessions working in this repo at once
->   will clobber each other. The second session writes **`REPORT-<topic>.md`** instead and never
->   touches the shared `REPORT.md`.
->
-> **Never write secrets** into any committed file — reference them as "stored out-of-band".
+- **Pushing `scripts/felhom-host-install.sh` to `main` publishes NOTHING.** `manifests/webpage.yaml`
+  runs two git-syncs: the website from `main`, and `/scripts/` from the tag
+  `installer-v<SCRIPT_VERSION>`.
+- **To publish:** cut `installer-v<new SCRIPT_VERSION>`, bump the `--ref` in `webpage.yaml` (**both**
+  the sidecar and the init container), commit, sync.
+- **To roll back:** move the tag back and wait ~30 s. No ArgoCD sync, no deploy — that is the
+  emergency lever; fix forward afterwards.
+- **Do NOT pin the website to the tag**, and the URL never carries a ref — `felhom-bootstrap.sh` and
+  the hub's day-0 command follow the tag with no edit.
+- `hostinstall_gates.py` gate 6 fails if the manifest stops naming an `installer-v…` tag or if the
+  website stops tracking `main`.
 
-- Update `REUSE.md` if you added/changed/deprecated a shared helper or pattern (same commit).
-- **Never `git add -A` in this repo** — parallel sessions share the clone and it sweeps foreign
-  WIP (the v0.47.0 `146d165` incident: a red-proof-mutated guard got swept to `main`). Stage
-  explicit paths only, `git pull --rebase` before every push, and do not run two writing
-  sessions on one clone (use `git worktree` if truly needed).
+## Workflow — what is specific to this repo
 
-## End-of-session checklist
+- **Never `git add -A` here** — parallel sessions share the clone and it sweeps foreign WIP. Stage
+  explicit paths only, `git pull --rebase` before every push.
+- **`REPORT.md` is overwritten, so two sessions in this repo clobber each other.** The second session
+  writes **`REPORT-<topic>.md`** and never touches the shared `REPORT.md`.
+- `CHANGELOG.md` here is **per-area**: `hub/`, `scripts/`, `website/`.
 
-- **`CHANGELOG.md` + `REPORT.md`** per the rule above, in every repo touched.
-- **`REUSE.md`**, if a shared helper or pattern moved (same commit).
-- **The capability map** (`documentation/architecture/00-capability-map.md`), if a capability's status
-  changed — with its new evidence citation.
-- **The architecture doc** that owns any changed contract (S-1, `CONTEXT.md`).
-- **Root `STATUS.md`** — *update it at the end of every session in which something shipped, broke, or
-  was decided. It is a view of `documentation/backlog/OPEN-ITEMS.md` — **nothing may exist only
-  there**. One screen; cut items rather than extending it.* It is written for the **operator** in
-  plain language, and is deliberately **not** `CONTEXT.md` — do not consolidate the two.
-- **A finding goes in `OPEN-ITEMS.md` first**, never only in a report, an audit or `STATUS.md`. Four
-  items in this project were minted in a spike doc and lost (R-153/154/155, R-156/157).
-- **Confirm your own last push's CI run went green, by run ID.** CI emails on failure, which is a
-  PUSH signal — this is the PULL check that catches a lost, filtered or unread mail. Quote the run
-  id and its conclusion in the session report, e.g.
-  `curl -s "https://gitea.dooplex.hu/api/v1/repos/admin/<repo>/actions/tasks?limit=3"` → match the
-  `head_sha` to your commit. An unchecked green is an assumption, not an observation.
-
-## Tech stack (Hub)
-
-- **Language:** Go (stdlib `net/http` + `html/template`, no frameworks). **DB:** SQLite via
-  `modernc.org/sqlite` (pure Go). **Auth:** bcrypt + Bearer tokens + session cookies + CSRF.
-- **Deploy:** Docker on k3s (`felhom-system` ns). **Storage:** Longhorn PVC at `/data/` (SQLite DB).
-- **Config:** YAML via ConfigMap at `/etc/felhom-hub/hub.yaml`. Secrets via out-of-band
-  `secretKeyRef` (never inline stringData — REUSE.md §3).
-
-## Environment & access
-
-Claude Code runs **on DooPlex (192.168.0.180, Debian 13, user `kisfenyo`)** — the k3s node itself.
-Repos in `/mnt/5_hdd/felhom.eu/git/`, build dirs in `/mnt/5_hdd/felhom.eu/build/`. `kubectl` and the
-image build/push are local commands; felhom-pve is one SSH hop.
-
-| Host | Access | Role | Blast radius |
-|------|--------|------|--------------|
-| **DooPlex (this host)** | local — `/mnt/5_hdd/felhom.eu/{git,build}/` | Build + push images, `sudo kubectl` | **Tier 2 — precious.** It *is* the recovery chain (hub, Gitea, registry, PBS, k3s+Longhorn). **Never a drill target** |
-| Demo Proxmox host (N100) | `ssh felhom-pve` — via Tailscale `100.70.170.35` (location-independent); `felhom-pve-lan` = LAN `192.168.0.162` fallback | pveum/pct + live Proxmox validation | **Tier 0 — disposable** |
-| Demo Proxmox host (HP t740) | `ssh demo-hp` — via Tailscale `100.76.96.79`; `demo-hp-lan` = LAN `192.168.0.87` (ProxyJump `felhom-pve`). **No baked SSH key** — G1 break-glass password vaulted in the hub | **The designated drill + build VM host** (operator ruling 2026-07-25) | **Tier 0 — disposable. Reach here first** |
-
-**Which box do I break?** → **`documentation/runbooks/target-selection.md`** — the tiers, and per
-machine what is freely permitted / needs care / forbidden, each with its reason. Read it before picking
-a machine for a drill, a destructive test or a throwaway VM.
-
-The `felhom-pve` transport is Tailscale (the N100 is travel-portable) — topology, the accept-dns
-rule, the accept-routes spike result, rollback, and the vacation-day checklist live in
-`documentation/operations/tailscale.md`.
-
-> **Legacy: Windows workstation.** Until 2026-07-19 CC ran on Windows 11 with repos in `E:\git\`,
-> and every remote command needed `SSH=/c/Windows/System32/OpenSSH/ssh.exe` (Git Bash's ssh fails
-> silently). Retained in case that environment is revived.
-
-## Build & deploy — Hub (GitOps via ArgoCD)
-
-**Full runbook: use the `felhom-build-deploy` skill.** The load-bearing rules:
-
-The whole cluster is GitOps via a **single ArgoCD app `felhom`** syncing this repo's `manifests/`
-to `felhom-system`. **Auto-sync is OFF** — deploys are a deliberate manual sync. ArgoCD's source of
-truth is the **manifest**:
-
-- **A code change + CHANGELOG bump deploys NOTHING.** The running image changes only when
-  `manifests/hub.yaml`'s `image:` tag changes in git and the app is synced.
-- **Pin explicit versions, never `:latest`.** Never bare `kubectl set image`/`kubectl apply`
-  (reverted on next sync).
-- **The live image can lag the CHANGELOG** when a bump was committed but the manifest/sync step never
-  happened — reconcile via the manifest, not the changelog.
-- Green gate before any hub commit: `go build ./... && go vet ./... && go test ./...` in `hub/`.
-
-> **Clean-tree gate before any build:** `git status --porcelain` must be empty and
-> `git rev-parse HEAD` must equal `git rev-parse origin/main` in the repo being built. An unpushed
-> change does not exist — never build a dirty or unpushed tree. The `git pull` in the build step
-> stays (it is a no-op when you work in this tree, and load-bearing if anything was pushed from
-> elsewhere).
-
-Steps: commit+push code → `cd /mnt/5_hdd/felhom.eu/build/felhom-hub && ./build.sh <VER> --push`
-(local) → bump `manifests/hub.yaml` tag + push → ArgoCD hard-refresh + sync (kubectl-patch method in
-the skill, now local `sudo kubectl`) → verify Synced/Healthy + rollout + image + startup log.
+<!-- The sweep incident: v0.47.0, commit 146d165 — a red-proof-mutated guard got swept to main. -->
 
 ## Gates — ONE entry point
 
-**Run `python3 scripts/repo_gates.py` after ANY change in this repo.** It is the one entry point
-and runs every gate — `site_gates.py`, `hostinstall_gates.py`, `hub_confirm_gate.py`,
-`manifest_bearer_gate.py` and `reuse_refs_check.py` on this root — streaming each gate's own output
-and exiting non-zero if any fails. `--fast` selects only the gates that touch no network and no
-container runtime; today that is all of them. A missing gate script is a FAILURE, never a skip.
+**Run `python3 scripts/repo_gates.py` after ANY change in this repo.** It runs every gate —
+`site_gates.py`, `hostinstall_gates.py`, `hub_confirm_gate.py`, `manifest_bearer_gate.py`,
+`reuse_refs_check.py`, `instructions_gate.py`, `golden_currency_gate.py`, `wire_contract_gate.py`,
+`hub_copy_gate.py` and `due_checks_gate.py` — streaming each gate's own output and exiting
+non-zero if any fails. `--fast` selects the gates that touch no network and no container runtime;
+today that is all of them. **A missing gate script is a FAILURE, never a skip.**
 
-**Why a runner and not five invocations** (2026-08-02, R-29): a census of all thirteen gates across
-the four repos found that every check a `CLAUDE.md` names was passing, and two of the four nobody
-is told to run were failing — one since 14 July. The single-entry-point shape is the only one that
-demonstrably gets run here; `app-catalog-felhom.eu/scripts/catalog_gates.py` is the canonical
-version of it (R-161) and `repo_gates.py` copies it. `site_gates.py` is a *gate*, not a runner —
-do not model new work on it.
+`due_checks_gate.py` refuses the push when a dated check in `OPEN-ITEMS.md`'s `DUE-CHECKS` block has
+come due (R-341). **It is not a scheduler** — it fires on the next push, not on the date.
 
-**The pre-push hook.** `.githooks/pre-push` runs `repo_gates.py --fast` and refuses the push if it
-fails. It is **per-clone** and switched on once with `git config core.hooksPath .githooks` — a
-clone does not carry it, and any manual `repo_gates.py` run WARNS when this clone is unarmed.
-`git push --no-verify` bypasses it deliberately; **say so in the session report when you use it**.
-Both facts are why continuous integration is still owed (`OPEN-ITEMS.md` R-168) — this hook is
-local and skippable, and only CI is neither.
+`site_gates.py` is a *gate*, not a runner — do not model new work on it;
+`app-catalog-felhom.eu/scripts/catalog_gates.py` is the canonical runner (R-161).
 
-## Build & deploy — Website / Manifests
+**The pre-push hook** (`.githooks/pre-push`) runs it with `--fast` and refuses a failing push. It is
+**per-clone** — switch it on once with `git config core.hooksPath .githooks`, and a manual run WARNS
+when this clone is unarmed. `git push --no-verify` bypasses it deliberately; **say so in the session
+report when you use it** — CI re-runs the same entry point on every push and **emails the operator
+on failure**, so a bypass is noticed even though it is not blocked (R-168, CLOSED 2026-08-02; CI
+reports rather than refuses because there is no PR to gate — R-169).
 
-- **Website** auto-deploys via git-sync; just push to `main` (live in 1–2 min). Website changes go
-  through `repo_gates.py` above (it runs `site_gates.py`); new pages go into that gate's `PAGES`
-  list. Emergency edits: https://files.felhom.eu. All `website/` HTML is **UTF-8 with BOM** — preserve it.
-- **THE INSTALLER DOES NOT (R-110, 2026-08-03).** `manifests/webpage.yaml` runs **two** git-syncs:
-  the website from `main` as above, and `/scripts/` from the tag **`installer-v<SCRIPT_VERSION>`**.
-  Pushing `scripts/felhom-host-install.sh` therefore changes nothing that any machine downloads —
-  which it used to, within thirty seconds, for the one artifact that runs as **root on a virgin box**.
-  - **To publish:** cut `installer-v<new SCRIPT_VERSION>`, bump the `--ref` in `webpage.yaml`
-    (both the sidecar and the init container), commit, and sync. `hostinstall_gates.py` gate 6
-    fails if the manifest stops naming an `installer-v…` tag or if the website stops tracking `main`.
-  - **To roll back:** move the tag back to the previous commit and wait ~30 s. **No ArgoCD sync and
-    no deploy** — git-sync picks up a moved tag on its next period, measured live on 2026-08-03 in
-    both directions. That is the emergency lever; fix forward with a new version afterwards.
-  - **Do NOT pin the website to the tag.** The sparse-checkout used to cover `/website/` and
-    `/scripts/` in one sync, and pinning that would turn every copy edit into a release.
-  - The **URL never carries a ref** (`https://felhom.eu/scripts/felhom-host-install.sh`), so
-    `felhom-bootstrap.sh` and the hub's day-0 command follow the tag with no edit — do not add one.
-  - The installer's own sixteen run-time fetches are pinned separately, to `raw/tag/v$ART_AGENT_VER`
-    in the **agent** repo (R-183) — they are the agent's configs, not this repo's.
-- **Manifests** are GitOps via the `felhom` app — commit to `main`, then deliberate sync.
+<!--
+WHY A RUNNER AND NOT FIVE INVOCATIONS (2026-08-02, R-29): a census of all thirteen gates across the
+four repos found that every check a CLAUDE.md names was passing, and two of the four nobody is told
+to run were failing — one since 14 July. The single-entry-point shape is the only one that
+demonstrably gets run here.
 
-## Key patterns
+instructions_gate joined the list on 2026-08-06 (R-229 deferred leg). It is registered in the
+controller and agent runners too, and it is the SHARED copy in felhom.eu/scripts/ — never copied
+into a sibling repo, because a copy would recreate the drift it detects.
+-->
 
-- Hub status logic: OK (report < 30m), WARN (30m–1h or health=warn), DOWN (> 1h or health=fail);
-  host liveness thresholds shared between UI and checker (never invent a second definition).
-- SQLite timestamps vary in format — always `parseSQLiteTime()`.
-- Dashboard/detail auto-refresh every 60s via meta refresh. Geo-restricted to Hungary via nginx
-  ingress annotation.
-- Helpers, seams, extension points, traps: **`REUSE.md`** — the map is maintained same-commit.
+## End-of-session checklist
+
+Registers first — **a finding goes in `documentation/backlog/OPEN-ITEMS.md` first**, never only in a
+report, an audit or `STATUS.md`. Four items in this project were minted in a spike doc and lost
+(R-153/154/155, R-156/157). This applies to **every** session that ships, breaks or decides
+something, not only sessions that touch `documentation/` — which is why it is here and not in
+`docs.md`.
+
+- **`CHANGELOG.md` + `REPORT.md`** in every repo touched (see the workspace root for the rule, and
+  the parallel-session caveat above).
+- **`REUSE.md`**, if a shared helper or pattern moved (same commit).
+- **`OPEN-ITEMS.md`** — every finding, with a number.
+- **Root `STATUS.md`** — at the end of every session in which something shipped, broke or was
+  decided. It is a **view** of `OPEN-ITEMS.md`; nothing may exist only there. One screen, written for
+  the operator in plain language, and deliberately **not** `CONTEXT.md`.
+- **The capability map** (`documentation/architecture/00-capability-map.md`), if a capability's
+  status changed — with its new evidence citation.
+- **`python3 scripts/unproven.py --summary`** — one line per status, and the not-walked total. Run it
+  at the end of any session that shipped, broke or proved something, and **say in the report if a
+  number moved**. It exists because "which claims are unproven?" was answerable only by a person
+  reading a page: a session asked for "the nine grey claims" could not determine which nine and
+  rightly refused to guess (R-326). *Nine was real and answered a different question — it is the
+  count of claims the 2026-08-09 pass DOWNGRADED. Not-walked is 32 of 55.* A status that moves
+  without anyone noticing is how the picture stops being true.
+- **Confirm your own last push's CI run went green, by run ID.** CI emails on failure, which is a
+  PUSH signal; this is the PULL check that catches a lost, filtered or unread mail. Quote the run id
+  and its conclusion, e.g.
+  `curl -s "https://gitea.dooplex.hu/api/v1/repos/admin/<repo>/actions/tasks?limit=3"` → match the
+  `head_sha` to your commit. An unchecked green is an assumption, not an observation.

REPORT-agent-transport-leak.md

@@ -0,0 +1,246 @@
+# REPORT — R-344: the agent's leaked PBS connections, fixed and proven on both boxes (2026-08-20)
+
+**Outcome: the fix works, measured three independent ways; ep0 is back to its baseline of 17 file
+descriptors from 415; and 0.130.0 is now published and vouched.** Both demo boxes run the **byte-exact
+published artifact**. R-347 is CLOSED. Two new findings came out of the release itself — **R-349**
+(the fleet was briefly running a different binary under the same version name) and **R-350** (I printed
+the hub password into the transcript; rotation is your call).
+
+## 1. Confirmed baselines
+
+| repo | in | out |
+|---|---|---|
+| `felhom-agent` | `f17ed11` — v0.129.0 | **`ede49b6`** — 0.130.0, UNRELEASED |
+| `felhom.eu` | `9299f85` | docs + register only |
+
+Both clean and equal to `origin/main` before each build. Agent version in: 0.129.0 on both boxes.
+Out: **0.130.0 on both**, confirmed from the hub, not from the boxes' own `--version`.
+
+## 2. The diff
+
+| file | symbol | change |
+|---|---|---|
+| `internal/httpx/transport.go` | **new package** | `DefaultIdleConnTimeout = 90s`; `NewTransport(tlsCfg, idle)` — fresh transport per call, `<= 0` means **use the default, never "no timeout"** |
+| `internal/httpx/transport_test.go` | new | zero/negative → default; the constant is read off `http.DefaultTransport`; freshness; TLS config preserved |
+| `internal/pbs/client.go` | `Config`, `NewClient` | `IdleConnTimeout` field (tests only); transport via `httpx` |
+| `internal/pbs/client_leak_test.go` | new | Scenarios A/C + the production-default pin |
+| `internal/hub/client.go` | `NewClient` | via `httpx` — **consistency only, did not contribute to the leak** |
+| `internal/proxmox/client.go` | `NewClient` | same |
+| `cmd/felhom-agent/main.go` | `version` | 0.92.1 → 0.130.0 (ldflags default) |
+| `REUSE.md`, `CHANGELOG.md` | — | `httpx.NewTransport` entry; the release note |
+
+Commit `ede49b6` on `main`. `grep '&http.Transport{'` now matches only `httpx` itself.
+
+**A check made before trusting the fix:** `doBody` already reads the body to completion and closes it,
+so the connection genuinely reaches the idle pool. Had it not, the idle timeout would have been the
+wrong fix entirely.
+
+## 3. Tests and the red-proofs
+
+`go build ./... && go vet ./... && go test ./...` → **30 packages, 0 failures.**
+`python3 scripts/agent_gates.py` → **all 4 gates OK.**
+
+The leak test counts connections **server-side** and models what `pbsTargetsFromPVE` does — build a
+client, use it once, drop it. It deliberately does **not** assert `err == nil` or that a field holds a
+value; both were true of the leaking code (the R-224 lesson).
+
+| red-proof | mutation | seen failing with |
+|---|---|---|
+| 1 — the fix | remove `IdleConnTimeout` | *"abandoned pbs.Clients: after 5s the server still holds 5 open connection(s), want 0 (5 dialled in total)"* — the count is in the message, so it cannot be a timeout with another cause |
+| 2 — the worse fix | `DisableKeepAlives: true` | **the leak test PASSES.** Caught only by `TestPBSClient_KeepAliveStillReuses`: *"3 sequential requests over 3 connection(s), want 1"* |
+
+**Red-proof 2 is the load-bearing one: Scenario A alone would have accepted a fix that made the problem
+worse** — no leak, at the price of a fresh dial for every one of ~40,000 daily requests. Both mutations
+reverted, tree re-verified clean.
+
+## 4. §4 quoted, beside the results
+
+> **P1** — *"(i) ep0's fd count falls by ≈194 within seconds … (ii) … ≈194 sockets convert ESTAB →
+> CLOSE-WAIT … (iii) neither — the count barely moves. Then the ownership attribution is wrong and the
+> finding must be withdrawn."*
+> **P2** — *"demo-hp (fixed): ≈ 0 … demo-felhom (control, untouched): ≈ 4 per hour → ≈ 16 over 4 h."*
+> **P3** — *"ep0's overall leak rate should fall from ≈ 200/day to ≈ 100/day while one box is fixed, and
+> to ≈ 0/day after Part 5."*
+
+## 5. P1 — **outcome (i)**, in one second
+
+| | ep0 fd | ESTAB | demo-felhom | demo-hp | CLOSE-WAIT |
+|---|---|---|---|---|---|
+| T-0 `09:15:46Z` | 415 | 398 | 199 | **199** | 0 |
+| T+1s `09:15:47Z` | **216** | **199** | 199 | **0** | **0** |
+| T+60s `09:16:42Z` | 218 | 201 | 199 | 2 | 0 |
+
+**Outcome (ii) did not occur, so it gets no register row.** Not one socket converted to `CLOSE-WAIT`:
+ep0 reaps on peer FIN correctly. That also means the 543 `CLOSE-WAIT` at the 2026-08-18 wedge has some
+other explanation and is **not** evidence of a second defect on the protected machine — a finding in the
+negative, worth the sixty seconds it cost.
+
+Ownership is now proven a **third** independent way: what dies with the process, agreeing with
+`ss -tnp` and with the access-log user agent. At 133 s uptime the fixed box held **0** connections.
+
+## 6. P2 — divergence
+
+**Window 09:15:47Z → 10:17:52Z = 1.03 h. You closed the ≥4 h window early**, so no daily rate is
+extrapolated and none is needed.
+
+| box | agent | start | end | delta | per hour | predicted |
+|---|---|---|---|---|---|---|
+| `demo-felhom` CONTROL | 0.129.0 | 199 | 203 | **+4** | 3.87 | ≈4 |
+| `demo-hp` FIXED | 0.130.0 | 0 | 0 | **+0** | 0.00 | ≈0 |
+
+**The assumption-free statement.** ep0's access log counts the opportunities: each box made **exactly 4
+`/snapshots` and 4 `/version` calls** in the window.
+
+> **control: 4 cycles → 4 leaks. fixed: 4 cycles → 0 leaks.**
+
+**Positive observable (standing rule 3):** a zero leak is equally consistent with "the agent stopped
+working" — it did not; its four cycles are in ep0's log. The boxes' other traffic is near-identical
+(`libwww-perl` 924 vs 926, `proxmox-backup-client` 898 vs 898), so **the only difference between them
+is the binary**. Poisson alone gives P(0 | λ=4) = **1.8%**, which is suggestive rather than conclusive
+and is not relied on alone.
+
+## 7. P3 — the second box, and the backlog clearing itself
+
+`demo-felhom` upgraded `10:18:56Z` on your word.
+
+| | ep0 fd | ESTAB | CLOSE-WAIT |
+|---|---|---|---|
+| T-0 `10:18:55Z` | 220 | 203 | 0 |
+| **T+2s** | **17** | **0** | 0 |
+| settled 10:30–10:35Z | **17–19** | 0–2 | 0 |
+
+**17 is precisely ep0's `t0` baseline** (fd 17, ESTAB 0, 2026-08-18 09:51:22Z), and it returns to 17
+between poll cycles — the "healthy proxy near 20 fds" the incident document named. Predicted ≈0/day
+residual; **observed the baseline itself.**
+
+**A correction, made within the hour it was written.** My STOP 1 report and the first CHANGELOG draft
+said *"does not clear the 388 descriptors already stuck on ep0 — those persist until that proxy
+restarts."* **Wrong.** They were held on both sides; restarting the agents released every one. **ep0 was
+read-only throughout and its proxy PID never changed (551655).** Corrected in the CHANGELOG, the audit
+document and R-344 rather than quietly edited.
+
+## 8. Fleet sanity
+
+Hub reports **0.130.0 on both** boxes. **No `floor held`** line (0.130.0 > golden MinAgent 0.129.0).
+**No `pbsdr_box_unreachable` / `offsite_box_unreachable`** during any window. Positive observable
+rather than the absent one: the PBS-DR gauge kept refreshing (`3.7% full (3.7 GB of 97.9 GB)`) and host
+reports kept landing from both boxes throughout.
+
+## 9. What is NOT done
+
+- **Not published.** No package, no tag, no manifest or floor field touched, no self-update staged.
+  **A box installed from the current image still ships the leaking agent** — **R-347**, your call.
+- The CHANGELOG heading is `## UNRELEASED — v0.130.0 candidate`. The `release-complete` gate convicted
+  on `## v0.130.0` because there is no tag and no package, and **it was right to**. I did not use
+  `--no-verify`; I made the heading stop claiming a release that has not happened. It flips to
+  `## v0.130.0` in the same commit as the tag.
+- Poll rate unchanged (**R-336**, re-scoped). `pbsTargetsFromPVE` not refactored; no
+  `CloseIdleConnections` added. ep0 not touched.
+- **The 388 descriptors ARE cleared** — see §7. This is the one item the prompt expected to remain
+  outstanding, and it did not.
+
+## 10. Register
+
+- **R-344** — updated with the fix, P1's outcome named, and P2/P3's numbers. **Left OPEN**, because a fix
+  on two boxes by hand is not delivered.
+- **R-336 — re-scoped.** Its new next-step cell, verbatim: *"**NEW ACCEPTANCE CRITERION, since the old
+  one is void:** the fd count is NOT the observable for this row any more — that belongs to R-344 and is
+  already satisfied. Measure the REQUEST RATE at ep0's access log, and state the projected rate at the
+  target customer count."* The row now records explicitly that its old next-step **would have "fixed"
+  nothing while looking like a failed fix**, and re-scopes it to what it is: ~85,000 requests/day to a
+  weekly-write DR endpoint, ≈**25 requests/second at fifty customers** against a CX33.
+- **R-347 (new)** — the delivery gap. Owner: **Viktor decides**, CC executes.
+- **R-348 (new)** — an agent restart blanks the reported backup list for up to ~18 h, and the `Store`
+  comment calls backups *"unaffected"*. **Blinds no alarm** — checked, not assumed: the hub's
+  `backupEvidenceLookback` scans 7 days for exactly this case, and `pbs_snapshots` stayed populated.
+- **No P1(ii) row**, because outcome (ii) did not occur.
+- **R-346** — this run anchored on the measured `t0` (fd 17 at 2026-08-18 09:51:22Z), never on a systemd
+  timestamp, so the 5 h 56 m discrepancy did not touch these numbers.
+
+## 11. CI, by run ID — and the claim ledger
+
+| repo | run | sha | conclusion |
+|---|---|---|---|
+| `felhom-agent` | id **362** / run_number 50 | `ede49b610` — the fix | **success** |
+| `felhom-agent` | id **363** / run_number 51 | `7569f34ae` — the correction | **success** |
+| `felhom.eu` | id **364** / run_number 239 | `57dd62b09` — the write-up | **success** |
+
+No `--no-verify` anywhere. Both repos' pre-push hooks ran their gate entry point and passed;
+`release-complete` passes on v0.129.0, which is the honest state while 0.130.0 is unpublished.
+
+`python3 scripts/unproven.py --summary` — **unchanged: 23 walked, 32 not walked of 55.** No number
+moved, and correctly so: this run proved an engineering fact about our own connection handling, not a
+customer-facing product claim.
+
+**Closing state of ep0**, read one last time after everything:
+
+```
+t=10:40:23Z pid=551655 fd=17 estab=0 ctrl(.2)=0 fix(.3)=0 CLOSE-WAIT=0
+```
+
+`CLOSE-WAIT 0`, `ESTAB` in the low single digits, `fd` at the baseline, proxy PID **551655** — the same
+process that has been running since 2026-08-18 09:51:04, never restarted by this work.
+
+## 11b. The release (R-347, CLOSED)
+
+`bash scripts/release-agent.sh 0.130.0` — the one documented way (R-115): build, tag, publish, and
+**verify by independent download**.
+
+| | |
+|---|---|
+| tag | `v0.130.0` at `7569f34` |
+| sha256 | **`a56a92a7bd68f5b46736eaec4806c3d26c16ccb35118c4ac0e3d8094eaefabc3`** |
+| size | 14,141,158 bytes |
+| reproducible | **yes, checked** — `-trimpath -buildvcs=false` rebuild matches byte for byte |
+
+**Vouched** in the Day-0 artifact manifest: agent 0.129.0 → **0.130.0** + its sha. **Only the agent
+fields changed.**
+
+- **`min_agent` left at 0.129.0** — it states what the **golden controller** needs. Raising it to
+  0.130.0 would have made the hub **HOLD the floor** for every box below 0.130.0, which is the
+  opposite of shipping a fix.
+- **Global floor never touched** (0.216.0). On hub v0.106.0 it is a *separate form with its own
+  action*, so publish-train rule 2's "save the floor last" hazard no longer exists in the shape its
+  incident describes — the rule's reasoning holds, its mechanism has moved.
+- After: no `floor held`, no `*_unreachable`, both boxes reporting 0.130.0, artifact downloading
+  anonymously at the vouched sha.
+
+**No `--no-verify` in the train.** The heading was flipped to `## v0.130.0` only after tag and package
+existed. Flipping first and bypassing would have produced a red CI run and an alarm mail for a release
+that worked — R-168's failure mode.
+
+## 11c. Two findings from the release
+
+**R-349 — the fleet was running a different binary under the same version name.** The proof deploy was
+a hand build; the release builds `-trimpath -buildvcs=false`. Same source, same version string,
+different bytes (`256e0829…` vs `a56a92a7…`). **Self-update could never have corrected it** — the boxes
+already reported 0.130.0, so the vouched version looked installed. Every version check in the system
+compares the *string*. Fixed by installing the **downloaded** artifact on both. The proper fix already
+exists in miniature: `wrapper_sha256` does exactly this drift detection for the PBS wrapper and was
+never extended to the agent's own binary.
+
+**R-350 — I printed the hub password into the transcript.** Confirming the vouch used
+`curl -w '%{redirect_url}'`; the hub answers 303 and curl re-attaches the basic-auth credential to the
+redirect target it prints. **Not in git, not in any committed file** (checked by content), not in the
+evidence directory — it is in the session transcript on DooPlex. Every other call printed only the
+length; this came through curl's own formatting. **Rotation is your call** — I did not do it
+unilaterally, and I can do it file-to-file without printing the new value if you want. The reusable
+half: `%{redirect_url}`, `-v` and `--libcurl` all re-render a basic-auth credential.
+
+## 12. Observations
+
+- **The closure refactor is not worth doing — recommend leaving it.** With the idle timeout restored an
+  abandoned client's connection is gone in 90 s, so the standing population is bounded at about one
+  connection per box instead of growing without limit. Caching clients would add cache-invalidation
+  questions (a storage's fingerprint, token or namespace can change under it) for no observable gain.
+- **Three other `http.Transport` defaults are still missing and were left alone:** `MaxIdleConns`,
+  `TLSHandshakeTimeout` (0 = no limit; `DefaultTransport` uses 10 s) and `ExpectContinueTimeout`. None
+  accumulates, and every client bounds its request with `http.Client.Timeout`. `TLSHandshakeTimeout` is
+  the only one with a plausible failure mode — a stalled handshake over the tunnel, bounded today only
+  by the outer 30 s. Not changed, because widening the diff would have made this measurement
+  unattributable. Worth a look on its own terms; not a defect.
+- **A measurement error of mine, recorded because it nearly cost four hours.** The first P2 sampler
+  reported both per-box columns as 0 while the totals were right: `ss` prints `[::ffff:10.77.0.2]:port`
+  and my pattern expected `10.77.0.2:`. Caught 15 minutes in, because a 0/0 split cannot sum to 199.
+  Fixed, then **one sample proved by hand before committing the window** — which is what should have
+  happened first.

REPORT-campaign11-phase24.md

@@ -0,0 +1,124 @@
+# REPORT — CAMPAIGN 11, Phases 2 and 4 (2026-08-05 22:38 → 08-06 04:35, unattended)
+
+> Written as a `REPORT-<topic>.md` sibling rather than into `REPORT.md`, per this repo's
+> parallel-session rule (`CLAUDE.md:82-87`) — the brief states another session commits here.
+
+## 1. The venue's state at the end — **WORKING**
+
+`c11-36d660` **ONLINE**, agent `0.125.0`, 1/1 guests, reporting on schedule (last seen 04:29:54).
+All four containers healthy (`calibre-web`, `filebrowser`, `felhom-controller:0.201.0`, `traefik`).
+Backup target `{"degraded":false,"label":"mentes","target":"felhom-backup"}`. Off-site: **2 snapshots**,
+`last_status: ok`, `last_success 2026-08-06T02:15:24Z`, `escrow_state: escrowed`.
+
+Two things a future session must know:
+
+- **The raw `/mnt/adatok` and `/mnt/mentes` mounts are deliberately left unmounted** — R-220's
+  workaround, without which no app can be deployed on a rebuilt box.
+- **The appliance's vaulted root credential was shredded with the codes.** Re-fetch it from the hub
+  (`POST /hosts/c11-36d660/reveal-recovery-credential`) — the designed path.
+
+## 2. §4.1 and §4.2
+
+**§4.1 — MEASURED, twice, and the brief's own plan for taking it was wrong.**
+The box renders `GetFloor()` = **`0.200.0`** (`/settings`), and a **cold-started** controller logs
+`settle-gate: GO — at/above floor 0.200.0 (we are 0.201.0)` against the same line reading
+`floor still unknown after 1m30s` while the hold was in force. Both `ResolveManagedFloor` hold branches
+serve `Floor=""` (pinned by `managed_floor_test.go:94`), so a non-empty floor proves an ACK carried
+one. The hub's HELD lines ran every 15 min to 22:12:06 then stopped, with a liveness control.
+**The correction:** `SetFloor`'s line is `u.dbg(...)`, gated on `logging.level=debug` and written to
+the logger — it can **never** reach the debug ring, so the restart the brief prescribed would have
+produced nothing. Caught by running a level census on the ring first.
+
+**§4.2 — still NOT measured, deliberately.** The fix is present (`needsOffsiteCredential` now retires
+on the *target*, not the key), but the venue **has** a target, so the box correctly does not declare.
+The state that exercises it needs a rebuild. **Phase 4 did supply its negative control:** zero
+`needs_credential` and zero `offsiteheal` in five hours.
+
+## 3. Every fault
+
+| | injected? | result |
+|---|---|---|
+| F1 wrong code ×3 | yes | refused ×3, **no lockout**, **nothing written** (mtimes frozen), I4 clean — but **M4, not M1** → R-226 |
+| F2 no code | yes | **PASS** — screen states nobody can replace it, offers set-aside; empty POST → „Add meg a helyreállítási kódot." in 0.027 s |
+| F3 hub unreachable | yes (302→exit 7) | **FAIL** — M4 for a correct code in **0.0556 s** → R-224 |
+| F4 agent stopped | yes (:8443 gone) | **FAIL** — M4 in **0.0299 s**; gate answered `source=version` → R-224 |
+| F5 store unreachable | yes (TCP-OPEN→CLOSED) | **PASS** — M3, R-217's false claims absent |
+| F6 „Most nem" | yes | **PASS** — full page silenced, entry point survives, unlock still works |
+| F7 set aside + change of mind | yes | set-aside **PASS** (12 535 KB untouched); afterwards **FAIL** → R-228 |
+| F8 restart mid-unlock | yes (StartedAt moved) | no half-state ✅, raw English `Bad Gateway` ❌ → R-227 |
+| F9 never-had-off-site | precondition not staged | **PARTIAL PASS** — R-215's gate proven live |
+| F10 missing mandatory path | **NOT INJECTED** | harness — three attempts, all self-healed |
+| F11 offline a window | yes | **PASS** — stale + recovered, an operator mail each way |
+
+## 4. The four messages, as they rendered
+
+- **M1** never appeared — unreachable on this box (R-226).
+- **M2** never appeared — the capability gate passed on a cached version (R-224).
+- **M3** „A kulcs visszakerült, de a mentések listáját most nem sikerült beolvasni…" — F5, correct.
+- **M4** „Ez a kód nem nyitja meg azt a csomagot, amit most őrzünk…" — F1, F3 **and** F4. Three
+  different causes, one sentence.
+
+## 5. Invariants
+
+**I1, I5, I7 held. I4 held on the product** (breached by the harness — see §7). **I3 breached twice**
+(R-227's raw `Bad Gateway`; R-220's refusal naming an impossible action). **I6 breached twice**
+(R-224, R-225). **I2 recorded as untested**, because F10 could not be injected.
+
+## 6. Phase 4
+
+**All five daily jobs fired exactly once, on time.** The 04:15 off-site run produced
+`snapshot_count` **1 → 2** unprompted. **Nothing on the must-not list fired.**
+`tier2-backup`'s 118 ms was suspected of being a silent no-op and **DISPROVED** (818.5 KB verified on
+the backup drive). **A correction to my own pre-registration:** `backup_run_digest` is a *test
+filename*, not an event type — the real one is `backup_run_failures`, correctly silent on a clean
+night. Two absences were answered rather than assumed: the restore-test's silence was pre-registered
+as correct; the whole-guest tier's is **explicitly unresolved**, because routine local-api calls are
+invisible at INFO (a five-hour search returns 0 on a box that demonstrably served them).
+
+## 7. Harness faults, separated from the product's
+
+Five, all mine: (1) `source ~/.config/credentials` **echoed two demo-box recovery codes** into the
+transcript; (2) its values are quoted, so a bare `cut -d=` yields the wrong secret; (3) the recovery
+page carries no `<meta>` CSRF — my length check caught it; (4) **two failed reachability controls**
+(`nc` absent; the container has no IPv6 route) reported as failed controls, not results; (5) a fixed
+temp filename in my guest runner let three collectors delete each other's script, and a waiter keyed
+on `date +%H -ge 4` fired at 23:xx — both caught because the evidence contradicted the claim.
+
+## 8. Suspicions investigated and disproved
+
+The floor being still held (**disproved** — measured served); an I5 disagreement over store size
+(**disproved** — rounding); `tier2-backup` no-opping (**disproved** — the copy is real).
+
+## 9. New findings
+
+**R-224** misattributed unlock failures · **R-225** `0 snapshots · 0 GB` on an unread store ·
+**R-226** M1 unreachable after re-escrow · **R-227** raw `Bad Gateway` · **R-228** the set-aside
+history is invisible. **The highest register ID had NOT moved** — it was R-223 on arrival and R-223
+when I minted, re-checked immediately before writing.
+
+## 10. Documents
+
+`documentation/audits/CAMPAIGN-11-recovery-journey-2026-08-05.md` — the campaign document, all four
+phases, in Campaign 10's shape. It records as **still owed**: the three-layer teardown, §4.2's
+positive half, F9's literal precondition, F10's real injection, the `STALE → DOWN` arm, and **a
+re-walk** — the capability map's recovery row stays **FAIL** until one passes.
+
+## 11. Recovery codes — shredded, with the control
+
+Plant → find → shred → fail to find. **The control paid for itself immediately**: it found the Phase 0
+code in `~/.config/credentials` as `R_CAMPAIGN_11`, a copy this session did not create. Without it,
+"codes shredded" would have been **false**. That key was removed with a verified diff and `HUB_PW`
+re-tested (`hub:200`). **⚠ `/home/felhom-repo.orphaned-20260805` (12 535 KB) is now permanently
+unopenable** — as the set-aside screen promises, and teardown removes it anyway.
+
+## 12. Teardown — OWED
+
+Nothing removed. Three layers named in the campaign document §11, plus the off-site side: the
+sub-account now holds **two** repositories, and `demo-felhom`/`demo-hp` namespaces on ep0 must not be
+touched.
+
+## 13. What did not run
+
+F10 as specified, F9's literal precondition, §4.2's positive half, `STALE → DOWN`, the whole-guest
+tier's due-ness, the retained package's read path (unbuilt), and any re-walk. **No product code
+changed; no version bumped.** CI green by run ID for every push (**179–184**).

REPORT-campaign12-class-sweep.md

@@ -0,0 +1,66 @@
+# REPORT — Campaign 12, the class sweep (2026-08-08, unattended)
+
+*A non-overwritten `REPORT-<topic>.md` sibling, per `CLAUDE.md:82-87` — a parallel session shares this
+clone and the shared `REPORT.md` was not touched.*
+
+## What ran
+
+**Part 1 — the bake.** Golden **0.208.0** baked on the drill VM, published, and round-trip verified:
+656 150 362 B, sha256 `ba668f59…5ffb82`, and `./etc/felhom-controller-image` read **out of the
+downloaded archive** says `felhom-controller:0.208.0`. All acceptance markers green, `Result=success`,
+bake VM destroyed and the drill disk restored to `virgin`. Token never on a command line (`grep -c` =
+0 on the committed log, **with a control proving the grep works**). **NOT VOUCHED — that is the one
+thing awaiting the operator.** Evidence: `documentation/tests/golden-0.208.0-2026-08-08/`.
+
+**Parts 2–4 — the sweep.** Seven defect classes swept for siblings, analysis only. Report:
+`documentation/audits/CAMPAIGN-12-class-sweep-2026-08-08.md`.
+
+## Result
+
+**Eight new register rows, R-256 … R-263** (highest ID moved from R-255), grouped by class in
+`backlog/OPEN-ITEMS.md`. **C1 produced no new instance** and has no row.
+
+The sharpest finding is **R-260**: the agent reports `operator_key_configured` on every heartbeat and
+the hub has no field for it, so the check that answers *"can the operator get into this box"* returns
+`ok` for a box with no operator key installed. Seven more dropped fields are censused with it.
+
+**Part 4's ranking is the campaign's most valuable output** and lives in `backlog/ROADMAP.md` as
+**G-1 … G-8**. The recommendation: **gate C5** (a cross-repo tag-reachability check — cheap,
+`--fast`-eligible, and it would have caught every instance in R-260's census on the commit that
+introduced them), and **do not gate C6**, because the standard tool was measured against a planted
+probe and found blind to the exact shape both known instances have.
+
+## Controls — every class states whether its method re-found the known instances
+
+| class | control |
+|---|---|
+| C1 | shipped gate **2 of 3**, verified by replaying the pre-fix templates from `8dbbc98^` |
+| C2 | **2 of 2**, re-found as fixed |
+| C3 | **2 of 3 re-found, 1 as fixed** — and swept COMPLETELY (all 9 sites) |
+| C4 | fix pattern (R-225 `StatsKnown`) re-found intact |
+| C5 | **re-found** — and a correction owed: the task called `escrow_stale` closed; it is R-247, `READY` |
+| C6 | **`deadcode` 0 of 2** (blind spot measured with a planted probe); bespoke method **1 of 2** |
+| C7 | **weakest** — the nine known are closed, so the sample re-finds the pattern, not the instances |
+
+## Honest limits
+
+- **C7 sampled 60 of 2652 production invariant comments** and **none of the 1440 test comments**. The
+  task asked explicitly for the tests' own claims; that half is **owed, not done**.
+- **C2 sampled 19 of 221 refusal strings.**
+- **C3 and C4 covered the controller only** — not the hub, not the agent.
+- **No finding was reproduced on a live box.** Source reading only, as §6 rule 2 requires. R-258 and
+  R-259 are the two most worth confirming live before they are fixed.
+- **Seven suspicions were investigated and DISPROVED**, including two of my own methods; §6 of the
+  report names each.
+- **`STATUS.md` is 100 lines, 7 over its 93-line "one screen".** The overflow is the campaign's own
+  entry plus the operator approval; the eight findings themselves are in the register, as required.
+- **This session did not run inside `tmux`**, contrary to the workspace `CLAUDE.md`.
+
+## Gates and hygiene
+
+`python3 scripts/repo_gates.py --fast` → **all 7 gates OK**, including `golden-currency`, which was
+correctly **RED on arrival** and is green after the bake. **No `--no-verify` was used anywhere** — the
+bypass the task authorised was not needed.
+
+No product code changed. Nothing was deployed beyond the golden. No machine was touched beyond the
+bake VM, which was torn down.

REPORT-clear-the-ground-2026-08-08.md

@@ -0,0 +1,246 @@
+# REPORT — clearing the ground before the next walk (2026-08-08)
+
+*A sibling report: `REPORT.md` is overwritten per-session and a parallel session shares this clone.*
+
+**Golden `0.206.0` baked and VOUCHED · the R-242 gate built and shown red→green · demo-hp's stale flag
+found wrong and cleared · `STATUS.md` 258 → 87 lines. `felhom-controller` and `felhom-agent` untouched.**
+
+---
+
+## 1. Part 2's gate — FAILING first, then passing
+
+**Shown failing against today's state, before anything was baked.** That ordering was the instruction
+and it is the gate's own red-proof:
+
+```
+  newest released controller : 0.206.0
+  newest golden baked        : 0.205.0
+
+GOLDEN CURRENCY GATE FAILED: controller v0.206.0 is released and NO golden carries it (newest bake is 0.205.0).
+A machine installed right now would receive v0.205.0 — the release is written, tested and pushed, and NOT delivered.
+```
+
+Entry point exit **1**; summary `CONVICTED: golden-currency`. After the bake, the same command:
+
+```
+  newest released controller : 0.206.0
+  newest golden baked        : 0.206.0
+golden currency gate OK
+```
+
+**⚠ THE INTRODUCING PUSH USED `--no-verify`, to get past the gate's own conviction.** Stated here, in
+`scripts/CHANGELOG.md` and in the commit message rather than worked around. The alternative — baking
+first so the gate had never been seen red — was explicitly rejected: a gate that has never been seen
+failing has not been shown to work. Every later push in this session was clean.
+
+### What it does not catch, and why the design is what it is
+
+**It checks the BAKE, not the VOUCH.** Both `.githooks/pre-push` **and** CI run `repo_gates.py --fast`,
+which by contract selects only gates touching no network — so a hub-reading gate registered as
+non-fast would run in **neither**, which is exactly the R-29 census failure this runner was built to
+end. And the vouched version lives only in `hub_settings`, with no copy in git; putting one there
+would create a second source of truth that can drift, and **a green gate over a false claim is the
+worst outcome available**. So a bake without a vouch still passes. That half stays open on R-242
+rather than being papered over.
+
+**It compares versions, not behaviour**, so a release that changed nothing customer-visible also trips
+it. **Accepted deliberately, and stated because a gate that cries wolf is one people learn to bypass:**
+judging "customer-visible" by hand is precisely what failed three times (R-239, R-242, and this
+recurrence), and the cost of a false trip is one bake — the operation the project wants routine anyway.
+A waiver belongs in the register, never in a habit of `--no-verify`.
+
+Inconclusive (exit 2) on an absent controller clone or an unparseable header: not knowing is never a
+pass.
+
+---
+
+## 2. Part 1 — the stale blob, all six questions
+
+**Read-only throughout. Nothing was cleared during the spike** — the clearance in §3 came afterwards,
+on the operator's explicit approval.
+
+**Q1 — what set it, and when. MEASURED, traced to an act, to the second.** At `2026-08-04 20:15:49`
+the hub emitted `offsite_reissued` **and** `escrow_stale` in the same second — an operator **Re-issue**,
+three minutes after `escrow_blob_served` at 20:12:40 and 20:12:54, i.e. during the R-201 recovery
+drill. That is `offsite.ReissueCredentials`'s **precautionary** `MarkEscrowStale` call, which **hub
+v0.95.0 removed the next day** (R-196 / R-204 item 2) for marking healthy escrows stale. So: **the
+drill's own Re-issue, by code that no longer exists.** *(Both 4-August candidates named in the task
+were live that day; the events separate them.)*
+
+**Q2 — is the flag correct? MEASURED: NO.** The hub's blob seals
+`restic_pw_sha256 = 8a9e33aa4da6769c5aea1831f87759e10930e2ec1dea0062576484e0598d080a`; the key the box
+is actually using hashes to **the identical value**. The blob covers the key. The flag was wrong from
+the moment it was set.
+
+**Q3 — what clears it? MEASURED: nothing, by itself.** The only writer of `stale_at = NULL` is
+`SaveHostEscrow`'s `ON CONFLICT` — a **fresh escrow ceremony**, which is the one act that would
+supersede the good blob. **The only exit from the false alarm was the destructive act the false alarm
+recommends.** No timer, no self-heal, no reconciler touches it.
+
+**Q4 — who can see it? Said plainly: effectively only a database read.**
+
+| audience | what they see |
+|---|---|
+| the **customer** | a card, but stating a **false reason** (see below) and recommending the destructive act |
+| the **box** | **nothing** — `report.EscrowStatus` has no `Stale` field, so it cannot see the flag at all |
+| the **operator** | one page: the **PBS-DR** view (`hub/internal/web/pbsdr.go:487`) — the *wrong tier* for an off-site symptom |
+| **alerts / notifications** | none. The one-shot `escrow_stale` event fired on 4 August and **was never notified** — a full `notification_log` census for that customer that day returns 8 rows, none of them this one. It has fired twice ever, both on 4 August |
+
+**A flag that changes behaviour, that nothing sets, and that nobody who would look for it can see.**
+Filed as **R-248** in its own right, because it is the shape this fortnight has been about.
+
+**Q5 — what else does a stale blob suppress? Enumerated from code, not assumed.** (1) the ACK's
+`restic_pw_sha256` is withheld; (2) a **pending** box can never auto-confirm; (3) so **every off-site
+run is refused indefinitely**; (4) the customer is told to create a new code; (5) **NEW — v0.206.0's
+shape (c) is inert**, because the box records an empty hub hash and falls back to (a)/(b).
+**(2) and (3) did not bite `demo-hp`**, which was already `escrowed` before the flag landed and has
+been backing up healthily throughout — 12 snapshots, last success `2026-08-07T02:15:35Z`. (4) and (5)
+did.
+
+**Q6 — `demo-felhom`? No** — `stale_at` empty, and it records the hub hash normally. **Can a freshly
+installed box reach this state? NO, and this is the answer that matters for the next walk.**
+`MarkEscrowStale` has **no production caller anywhere in the tree** — a full census returns only its
+own definition, two comments and two test references. Nothing has set the column since hub v0.95.0
+shipped on 2026-08-05. **The next walk cannot meet this**, by any route, unless it uses `demo-hp`
+itself — and that box is now clear.
+
+### The sharpest finding: the box states four falsehoods and recommends the destructive act
+
+Live on `demo-hp`, controller v0.206.0:
+
+> `STALE escrow: the hub's current blob carries NO password hash (hash-less supersession) — the stored
+> recovery bundle does not cover the offsite password; create a new recovery code`
+
+**Every clause is false.** The hub *has* the hash and is *withholding* it; there was no supersession
+(`host_escrow_superseded` holds no row for this host); the bundle **does** cover the password.
+It raises `EscrowStale`, rendering the customer card *„A letétben lévő helyreállítási csomag nem fedi a
+jelenlegi távoli mentési jelszót. Hozzon létre új helyreállítási kódot."*
+
+**And the cause is R-241's shape for the third time.** The hub already sends `escrow_stale` on the
+wire (`json:"escrow_stale,omitempty"`); the controller's struct has **no matching field**, so
+`encoding/json` drops it silently. The box cannot tell *withheld because flagged* from *genuinely
+hash-less*, and guesses the latter. **The answer is available and discarded at the boundary** — filed
+as **R-247**, and deliberately **not fixed here** (§0 forbids a controller change this session).
+
+---
+
+## 3. The bake, the vouch, and the flag clearance
+
+| | |
+|---|---|
+| version | **0.206.0** · sha256 `c85230b42f53baa9c1ee9986ac312c751d6cbc29fbe070d87bb2214429a9108e` |
+| size | **656,750,694** bytes (uncompressed 2,003,138,560) |
+| MinAgent | 0.127.0 |
+
+**Round-trip verified, not trusted:** fetched back (HTTP 200, byte count matches), re-hashed
+independently (**matches**), `zstd -t` clean, and `tar -xO ./etc/felhom-controller-image` **out of the
+download** → `felhom-controller:0.206.0`. That last step is the one that matters, because
+`GOLDEN_VERSION` is derived from the tag argument and could be right over stale content. **Third
+witness:** the hub's own dropdown lists `0.206.0` with `data-sha="c85230b4…108e"`.
+
+All acceptance markers pass; unit `Result=success` / `ExecMainStatus=0`; bake VM purged and reverted to
+`virgin`; token-leak grep on the committed log **0**, with the instrument proven by a planted copy
+first. Evidence: `documentation/tests/golden-0.206.0-2026-08-08/`.
+
+**VOUCHED with the operator's approval.** Verified from the stored `hub_settings`, not the flash:
+
+| field | before | after |
+|---|---|---|
+| `artifact_golden_version` | `0.205.0` | **`0.206.0`** |
+| `artifact_golden_sha256` | `8f49b2e8…4ee8` | **`c85230b4…108e`** |
+| `artifact_agent_version` | `0.127.0` | `0.127.0` — unchanged |
+| `artifact_min_agent` | `0.127.0` | `0.127.0` — unchanged |
+| `artifact_wrapper_sha256` | `104db0a4…16b3` | unchanged — **carried through explicitly, because the handler clears it when omitted** |
+
+**The stale flag was cleared, with the operator's approval.** One row, identity-matched on `host_id`
+and guarded on `stale_at IS NOT NULL`; `changes()` returned **1**. **Verified end to end:** the hub
+serves the hash again, the box recorded `hub_escrow_key_sha256 = 8a9e33aa…d080a` at `11:10:19Z`, and
+that is byte-identical to the key it is using — so shape (c) compares, matches, and correctly stays
+silent. **The false warning is gone, proven with a positive control rather than an absent line: 0
+`escrow-confirm` lines since the restart, while 5 scheduler lines in the same window prove the box was
+logging and the recorded hash proves an ACK was processed.**
+
+*Method note, because it touched a production pod:* the hub pod is Alpine with no `sqlite3`; it was
+installed into the container's **ephemeral writable layer** — image and node untouched, gone on
+restart. SQLite's own file locking coordinated the write with the live hub. An earlier attempt failed
+on quoting and **changed nothing**, which is the fail-safe working.
+
+---
+
+## 4. `STATUS.md`, R-245, and the queue audit
+
+**Rebuilt from the register: 258 → 87 lines.** Not trimmed — the 100-line "what shipped recently" log
+was removed outright, because restating the CHANGELOGs here is what made the page grow back.
+
+**All three named defects fixed:** the "waiting on you" list no longer asks the operator to decide the
+**recovery screen** (shipped 2026-08-05) or to approve an orphaned-backup deletion the register
+records as **done** the same day; the stray `- **Nothing.**` line is gone; and the DooPlex
+infrastructure work is now **under its own heading** — **kept rather than dropped**, with the reason
+stated on the page: they are real asks that need the operator, but they concern the machine this is
+built on, not what a customer receives. Dropping them would have lost real work.
+
+**R-245 re-filed as a decision taken**, keeping the whole reasoning and gaining **the condition that
+reopens it: quota — old set-aside history blocking new backups. A condition, not a calendar.**
+
+**The queue audit.** Parsing the **state column exactly** (grepping for the phrase over-matches rows
+that merely mention it): **exactly one row carried `WAITING-ON-OPERATOR` — R-245 — and it was the
+settled one. So zero rows were genuinely waiting**, and the drift was caught while it was still a
+single row.
+
+---
+
+## 5. R-244 — still owed, now measured
+
+A read-only census, no truncation: `app_log_issues` holds **1309 rows**; **71 reference a torn-down
+venue**; of those **44 are orphans** (safely deletable) and **27 are shared with a live customer** and
+**must be de-referenced, never deleted**. 1238 untouched.
+
+**Not done here, and the reason is on the row:** the fix is hub code, this session's scope forbade a
+hub version bump, and a hand-run SQL mutation over 71 rows — 27 needing surgical de-referencing — with
+no tested code path and no red-proof is the shape that goes wrong on a live database. **What it
+needs:** a cascade leg that removes the customer id from `affected_customers` / `context_customer` and
+deletes only rows that become empty, plus a one-off sweep for the four venues already gone. The next
+session starts from data rather than a guess.
+
+---
+
+## 6. Registers, CI, and what was not done
+
+**Opened:** **R-246** (the flag: wrong, traced, now cleared — the column ruling still owed),
+**R-247** (the box states four falsehoods and recommends the destructive act; the ACK field it needs
+is already on the wire and dropped), **R-248** (a behaviour-changing flag visible to nobody).
+**Updated:** **R-242** (recurred within a day; bake half now gated, vouch half explicitly still open),
+**R-244** (measured), **R-245** (re-filed as decided). **Highest register ID moves R-245 → R-248.**
+
+**CI — and the gate broke it, which I caught by checking rather than assuming.** Runs **241**
+(`3ca9a7bbe6e5`) and **243** (`7850469d5b78`) **failed**. 241 is expected and correct — the gate was
+legitimately red at that commit, and CI saw it. **243 was not**: CI checks out ONE repo, shallow, so
+the gate found no sibling controller clone, exited **2 (INCONCLUSIVE)** and turned CI red on every
+push. **A permanently-red CI is the detector-nobody-hears failure that workflow exists to prevent.**
+
+**Fixed by giving the gate what it needs, not by letting it skip** (`6f25e02828c8`): a depth-1 fetch
+of the controller repo in CI, plain `git`, no JavaScript-action step. A skip would have been the
+fail-open shape this project keeps removing — and the gate would then have run in **neither** of its
+two automated homes. **Verified green: runs 244 and 245 (`6f25e02828c8`) both success.**
+
+**`--no-verify` was used exactly once**, on commit `3ca9a7bbe6e5`, to push past the gate's own
+conviction — §9.11's explicit question, answered. Every later push was clean.
+
+**No controller or agent change**, as scoped. R-247's fix is a controller change and is therefore
+filed rather than made.
+
+### Observations — noticed, NOT acted on
+
+- **`stale_at` is a column with no production writer.** It changes what a customer is told, and
+  nothing can set it. Either give it an evidential setter or retire it; leaving it is leaving a trap
+  that only a database read can spring. Recorded on R-246; not decided here.
+- **The `escrow_stale` event type appears never to be notifiable.** It fired twice and reached
+  `notification_log` neither time. I did not establish whether it is absent from the dispatcher's
+  allow-list or merely suppressed, so I have not filed it — but if R-247 is taken up, that is worth
+  five minutes first.
+- **The hub's `EscrowStatus.Stale` field is serialised and has no consumer anywhere.** It is dead
+  weight on the wire until R-247 gives it one.
+- **A new gate can break CI in a way the local run cannot show**, because CI's checkout is narrower
+  than a workstation's. That cost one red CI here and was caught only by pulling the run status. Worth
+  remembering the next time a gate reads a sibling repo — the pre-push hook and CI do **not** see the
+  same filesystem.

REPORT-golden-0.216.0.md

@@ -0,0 +1,151 @@
+# REPORT — bake and vouch golden 0.216.0, closing R-334 (2026-08-18, afternoon)
+
+**Outcome: R-334 CLOSED.** Golden **0.216.0** baked, published, and **vouched by the operator**.
+`golden_currency_gate.py` is green for the first time since 2026-08-14, and `repo_gates.py` is
+**fully green — all nine gates, rc=0**.
+
+Run against the existing `documentation/runbooks/RUNBOOK-manual-build.md` §4.0 + §4.1; the run sheet
+pinned this run's numbers and the stop. Evidence:
+`documentation/tests/golden-0.216.0-2026-08-18/`.
+
+---
+
+## 1. Baselines, re-read on the machine
+
+| item | value | source |
+|---|---|---|
+| newest released controller | **v0.216.0** | `felhom-controller/CHANGELOG.md` head |
+| its floor | **`MinAgent: 0.129.0`** | second line of that header |
+| newest agent release | **v0.129.0** | `felhom-agent/CHANGELOG.md` head |
+| newest golden before this run | **0.214.0** | `documentation/tests/golden-0.214.0-2026-08-12` |
+
+**All four match the run sheet's §1 — no disagreement to report.** All three repos were clean with
+`HEAD == origin/main` before starting.
+
+## 2. The published agent artifact exists
+
+Checked against the **package registry**, not inferred from a CHANGELOG:
+`generic felhom-agent 0.129.0` is published. Vouching `agent_version` at a version that was never
+published would point day-0 installs at a 404.
+
+**The R-216 check passed on the machine rather than on the coincidence.** `MinAgent` (0.129.0) is
+**equal to**, not above, the newest published agent (0.129.0). Had it read higher, hub v0.97.0 would
+hold the fleet against a version nobody has.
+
+## 3. Identity, and a verification beyond what was asked
+
+```
+GOLDEN_VERSION = 0.216.0
+GOLDEN_SHA256  = ac004dc90d8cefccc5448377892f9cff3a4c3e1e27d0e11129120e38ac31c34b
+URL            = https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.216.0/golden.tar.zst
+archive        = 656,970,239 bytes (rootfs 32G + ONE data volume 24G @ /var/lib/felhom)
+controller     = gitea.dooplex.hu/admin/felhom-controller:0.216.0
+template       = debian-13-standard_13.6-1_amd64.tar.zst  (listed live per §4.1 step 2, not reused)
+```
+
+The URL resolves (HTTP 206 on a range request). **I did not stop at the script's printed hash**: the
+artifact was downloaded back out of Gitea and hashed, and it matches `GOLDEN_SHA256` exactly. The
+script reporting a digest and the registry serving those bytes are two different claims, and only the
+second one is what a new install actually receives.
+
+## 4. Pass markers — the corrected list, quoted from the real log
+
+```
+ 82 :   docker OK (overlay2; data-root /var/lib/docker)
+313 : INFO: including mount point rootfs ('/') in backup
+314 : INFO: including mount point mp0 ('/var/lib/felhom') in backup
+319 : [golden]   pre-delete existing: HTTP 404 (404/204 expected)
+320 : [golden]   upload OK (HTTP 201)
+```
+
+`excluding` and `FATAL`: **absent**. There is no mp1 — R-165 collapsed the two data volumes into one,
+which is exactly why the pre-2026-08-06 marker list could never match and why R-233 rewrote it.
+
+## 5. Token handling, and why the control is not ceremony
+
+Copied **file → file** by `scp`; the runner script inside the VM read it from `/root/.gitea-token`
+itself, so the value never reached a command line or a unit's properties:
+
+```
+systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "<token>"   =  0
+```
+
+Token-leak grep on the **committed** log, positive control run **first**:
+
+```
+seeded throwaway copy  = 1     ← proves the grep can see a token when one is present
+committed bake.log     = 0     ← the real measurement, now worth believing
+```
+
+**A `grep -c` that matches nothing returns `0`, which is indistinguishable from a clean file.**
+Without the control, the `0` is an assumption wearing a number's clothes. Both figures are from the
+copy that is committed to the repository, not only the one inside the VM.
+
+## 6. Teardown
+
+`pct destroy 9100 --purge` (both LVs removed, CT purged) → `shred -u` on the token, runner,
+build script and log **after** the log was copied out (standing rule 5) → all four confirmed absent
+→ `poweroff` → waited for qemu to exit using `ps -eo comm` (**not** `pgrep -f`, which self-matches and
+reports a false "still running") → `qemu-img snapshot -a virgin`, disk reverted, snapshot list shows
+the single `virgin` entry.
+
+**Nothing was provisioned that outlives this run.**
+
+## 7. The vouch, and its verification
+
+**Performed by the operator (Viktor)** in the hub, Configuration → Day-0 artifacts. Verified
+afterwards by reading the hub's own store rather than trusting the save:
+
+| field | value | recorded |
+|---|---|---|
+| `artifact_golden_version` | **0.216.0** | 2026-08-18 11:00:59 |
+| `artifact_agent_version` | **0.129.0** | 2026-08-18 11:00:59 |
+| `artifact_min_agent` | **0.129.0** | 2026-08-18 11:01:00 |
+| `artifact_golden_sha256` | `ac004dc9…c34b` | 2026-08-18 11:01:00 |
+
+The recorded sha256 **matches the artifact I downloaded and hashed independently** — so the hub is
+vouching the bytes that are actually published, not merely a matching version string.
+
+**This separate check was necessary, and the gate says so itself.** `golden_currency_gate.py`'s own
+pass line reads *"this checks the BAKE, not the vouch"*. A green gate on an unvouched bake is exactly
+the "baked-but-unvouched golden is worse than none" state R-334 warned about, so the gate alone could
+not have closed this row.
+
+## 8. Gates
+
+```
+golden_currency_gate.py                        rc=0
+  newest released controller : 0.216.0
+  newest golden baked        : 0.216.0
+
+repo_gates.py --fast                           rc=0
+  site OK · hostinstall OK · hub-confirm OK · manifest-bearer OK · reuse-refs OK
+  instructions OK · golden-currency OK · wire-contract OK · hub-copy OK
+  all felhom.eu gates OK
+```
+
+**This is the first fully green gate run since 2026-08-14**, and it is the point of the run: the
+CI failure mail that has been arriving since then should now stop.
+
+## 9. Documentation not changed, deliberately
+
+**`documentation/architecture/00-capability-map.md` — no change, and the reason matters.** The run
+sheet said to update it *if the day-0 install row's evidence citation names the golden version*. It
+does not: that row cites `DRILL-day0-vm-2026-07-12` / `DRILL-day0-take2-2026-07-12`. The only golden
+version literal in the map is `tests/golden-0.205.0-2026-08-07` on the **recovery-journey** row,
+which is a **dated historical citation** of what a fresh install landed on during the 2026-08-07
+walk. Bumping it to 0.216.0 would falsify a record of what happened on a specific date — `docs.md`
+permits historical citations precisely because they cannot go stale.
+
+## 10. Observations, not acted on
+
+- **`min_controller_version` in the hub still reads `0.214.0`** (last touched 2026-08-12). That is a
+  different field from the three vouched here — it is the floor the fleet is held to, not the day-0
+  golden — and it was outside this run's scope. But it is now two releases behind the golden a new
+  box receives, and STATUS.md's "approved pair" line describes it. Worth a decision; **not** changed
+  here, because widening scope past the three named fields is how a vouch goes wrong.
+- **`pveam available` still offers `debian-13-standard_13.6-1_amd64.tar.zst`** — the same point
+  release the runbook recorded on 2026-07-31. Listed live rather than assumed, per §4.1 step 2; the
+  instruction stands even when the answer happens not to have moved.
+- **The bake ran in ~5 minutes** (12:49 launch → 12:54:14 archive), well inside the drill VM's normal
+  envelope; no timeout or retry was needed.

REPORT-hub-blindness.md

@@ -0,0 +1,234 @@
+# REPORT — the hub says something when it loses sight of the off-site endpoints (2026-08-18)
+
+**Shipped: hub v0.106.0, deployed and verified.** Both box checkers now carry a second, independent
+**reachability** signal with paired all-clears. The fill logic is untouched. **Part 6 was done, not
+dropped.**
+
+**NOT proven live** — see §7. No real or constructed outage has exercised the emit path.
+
+---
+
+## 1. Confirmed baselines
+
+| item | value |
+|---|---|
+| felhom.eu `main` @ start | `78a244bf0f…` — **matches the prompt's anchor** |
+| hub version in → out | **v0.105.0 → v0.106.0** (read from `hub/CHANGELOG.md` head) |
+| `scripts/` version in → out | `due_checks_gate.py v1.0.0` → **v1.0.1** |
+| highest R in use at start | R-343, so **R-339 / R-340 free** as specified |
+
+**Had the three target files moved?** No. Verified by hash before editing:
+
+```
+61a16462756099d2fa60dd0c50aeac8c  internal/monitor/pbsdr_box.go
+d12b3e665d729a0291d2397895f23d1f  internal/monitor/offsite_box.go
+702d17487ffb4ac17a9d18050bb546b7  internal/notify/dispatcher.go
+```
+
+All landmarks in §5 of the prompt resolved as described; nothing was stale.
+
+## 2. Files created / modified
+
+**Created:** `hub/internal/monitor/box_reachability_test.go`,
+`hub/internal/notify/dispatcher_box_reachability_test.go`, `REPORT-hub-blindness.md`.
+
+**Modified:** `hub/internal/monitor/pbsdr_box.go`, `hub/internal/monitor/offsite_box.go`,
+`hub/internal/notify/dispatcher.go`, `hub/cmd/hub/main.go`, `hub/CHANGELOG.md`,
+`hub/internal/monitor/{pbsdr_box_test.go,offsite_box_test.go}` (new constructor arg),
+`manifests/hub.yaml`, `CONTEXT.md`, `STATUS.md`, `documentation/backlog/OPEN-ITEMS.md`,
+`documentation/architecture/00-capability-map.md`, `scripts/due_checks_gate.py`,
+`scripts/instructions_gate.py`, `scripts/test_due_checks_gate.py`,
+`scripts/test_instructions_gate.py`, `scripts/CHANGELOG.md`.
+
+## 3. Commits pushed to `main`
+
+| commit | contents |
+|---|---|
+| `ab2262c91c1e976ae3b983e9df6b45dabfcb9d23` | the code, tests, and register/doc edits |
+| `c03f629d43ed3d175e2c8561486cadc9a432640f` | `manifests/hub.yaml` 0.105.0 → 0.106.0 — the change that actually deploys |
+| *(Part 6 commit — see §10)* | the today-override announcement + `scripts/CHANGELOG.md` |
+
+## 4. Tests and the three red-proofs
+
+**All named tests pass.** Groups A–F in `internal/monitor/box_reachability_test.go`, Group G in
+`internal/notify/dispatcher_box_reachability_test.go`:
+
+| test | result |
+|---|---|
+| `TestPBSDRBox_Unreachable_SustainedOutage` (A) | PASS |
+| `TestPBSDRBox_Unreachable_BlipBelowThreshold` (B) | PASS |
+| `TestPBSDRBox_Unreachable_Recovery` (C) | PASS |
+| `TestPBSDRBox_UsageUnsupported_IsNotBlindness` (D) | PASS |
+| `TestPBSDRBox_BornBlind_StillReports` (E) | PASS |
+| `TestOffsiteBox_Unreachable_AndRecovery` (F) | PASS |
+| `TestPBSDRBox_ZeroCapacitySuccess_ClearsBlindness` (§8 truth table) | PASS |
+| `TestBoxRecovery_ReachesTheOperatorDespiteInfoSeverity` (G) | PASS |
+| `TestBoxUnreachable_ReachesTheOperatorOnItsOwnSeverity` (G) | PASS |
+| `TestBoxRecovery_PairedWithTheCorrectDownType` (G) | PASS |
+
+**None of the three red-proofs passed on the first attempt** — each turned its test red, and each did
+so **for the reason under test**, which I checked in the message rather than in the count.
+
+**Red-proof 1 — threshold 3 → 1.** Group B seen failing:
+
+> `box_reachability_test.go:132: two failed windows emitted [pbsdr_box_unreachable pbsdr_box_unreachable], want silence below the threshold`
+
+The message names the premature events, not an incidental error. **Reverted** (`defaultBoxUnreachableWindows = 3` restored).
+
+**Red-proof 2 — remove the `ErrUsageUnsupported` counter guard** (deleted its early return so the
+branch falls through). Group D seen failing:
+
+> `box_reachability_test.go:213: ErrUsageUnsupported emitted [pbsdr_box_unreachable × 8] — an expected pre-update condition must never alert`
+
+The message names the **unexpected event type**, as the prompt required — not merely a count.
+**Reverted.**
+
+**Red-proof 3 — remove `pbsdr_box_recovered` from `recoveredPairedDownTypes`.** Group G seen failing,
+and the first failure is the **end-to-end mail assertion**, which is what proves the test exercises
+the wiring rather than the map:
+
+> `dispatcher_box_reachability_test.go:41: pbsdr_box_recovered: operator mails = 0, want 1 — the all-clear must reach the operator; 0 means the recoveredPairedDownTypes entry is missing and "info" was dropped by the severity gate`
+
+**Reverted.** `grep -rn MUTATED internal/` returns nothing.
+
+## 5. Test count
+
+`go test ./...` — **21 packages, all green** (18 with tests, 3 with none). `internal/monitor` gained 7
+tests; `internal/notify` gained 3. `go build ./...` and `go vet ./...` clean.
+
+Repo gates: **10/10 OK, rc=0**.
+
+## 6. Deployed version and the wiring evidence
+
+```
+ArgoCD app "felhom":  Synced  Healthy   rev=c03f629d43ed3d175e2c8561486cadc9a432640f
+pod:                  hub-654bbc8fbc-9wld9   1/1 Running
+running image:        gitea.dooplex.hu/admin/felhom-hub:0.106.0
+```
+
+**The required post-deploy check — both constructor log lines carrying the threshold:**
+
+```
+19:29:07 [INFO] Offsite pool-box checker initialized: box=611714 fill warn=80% crit=90%,
+                oversub warn=2.00x, unreachable after 3 consecutive failed reads, refresh 15m0s
+19:29:07 [INFO] PBS-DR box checker initialized: fill warn=80% crit=90%,
+                unreachable after 3 consecutive failed reads, refresh 15m0s
+```
+
+**Two lines, both carrying the threshold — the parameter reached both checkers.** Their absence would
+have meant the config was inert however green the tests were. Note this also exercised the
+**absent-key** path: `box_unreachable_windows` is deliberately not in any deployed config, so both
+checkers fell back to the documented default of 3, which is what the log shows.
+
+## 7. NOT yet live-validated — explicitly
+
+**No real or constructed endpoint outage has exercised the emit path end to end.** Everything in §4
+is an injected fake with a scripted error and an injected clock. What is proven: the checkers emit the
+right events with the right details, and the dispatcher routes both new `*_recovered` types to a real
+operator mail. What is **not** proven: that a genuine ep0 or Hetzner failure produces those errors in
+the shape the checkers expect.
+
+A real outage cannot be manufactured without making ep0 or the Hetzner API unreachable, and **ep0 is
+Tier 2 protected — that was not done.** The constructed-outage option, named but not performed: point
+the tenantsync client at a blackholed address on a **scratch** hub instance and let three windows
+elapse.
+
+## 8. Teardown
+
+**This run provisioned nothing.** No VM, no container beyond the hub's own rolling deployment, no
+drill target, no scratch guest. All three layers N/A. `ep0`, both demo boxes and the drill VM were
+untouched, as were the agent's credential-consume and self-heal paths.
+
+## 9. Register rows
+
+**R-339 opened and marked SHIPPED** (hub v0.106.0), with PROVEN-LIVE explicitly still owed and an
+instruction not to close it on the unit tests.
+
+**R-340 opened, READY (M)** — the honest boundary: the hub's ep0 read is the `usage` op, which rides
+the **local API daemon**, and the 2026-08-18 incident explicitly cleared that daemon while the HTTPS
+proxy on 8007 was wedged. **R-339's check would have shown green for all 9 h 37 m of the outage that
+motivated it.** Overlap with R-336's remaining half is noted so whichever runs second reuses the
+first's evidence rather than re-measuring a protected machine.
+
+**R-336's next-step cell corrected. The replacement text, verbatim:**
+
+> **CORRECTED 2026-08-18 (evening) — the easy lever named here does not exist.** This cell used to
+> read *"PVE storage status is the prime suspect, and its interval is tunable"*. **The first half is
+> right and the second half is false.** `pvestatd` stats EVERY configured storage on each 10-second
+> cycle, and Proxmox staff have stated the interval is not designed to be configurable — so there is
+> no knob to turn down. The only lever PVE actually offers is disabling the storage entry
+> (`pvesm set <id> --disable 1`) around the backup window, and that is **substantially more than a
+> tuning knob**: it collides with `felhom-agent/internal/pbsdr/manager.go`'s health model, where an
+> inactive-but-existing entry drives the consume-the-one-time-secret recovery path. So the fix is a
+> design question (does the hub still need a 15-minute fill reading at all, given R-339 now reports
+> reachability separately?), not a config edit. **Doc-only correction — no agent code was changed.**
+> The remaining step is unchanged: cut the poll rate by whatever means survives that question, then
+> confirm the fd count between restarts stops climbing — the positive observable, per standing rule 3.
+
+## 10. Part 6 — DONE, not dropped
+
+Both gates now announce the `FELHOM_GATE_TODAY` override loudly before any verdict, and
+**`instructions_gate.py` no longer swallows a malformed one** — it used to fall through to the real
+date in silence while `due_checks_gate.py` already exited 2 on the same input, so one variable had two
+gates disagreeing about what a mistake means. Both exit 2 now.
+
+Tests extended in both suites (**42** and **73** assertions, all green). Red-proof: the announcement
+was deleted from `due_checks_gate.py` and its two assertions were seen failing —
+`P6: valid override is announced` and `P6: the announcement says the real date is being ignored` —
+then reverted.
+
+## 11. Gate and CI status
+
+`python3 scripts/repo_gates.py` → **rc=0, all ten gates OK**, including `due-checks`.
+
+**The due-checks gate did NOT refuse this push.** R-341's first check comes due 2026-08-19 UTC and
+this work ran on 2026-08-18 (17:18–19:30 UTC), so the gate reported *"2 dated check(s) pending, none
+due yet"* throughout. **No row was cleared, no date edited, no `--no-verify` used.** Every push today
+went through the armed hook.
+
+**CI, by run ID — all three pushes green:**
+
+| run | head_sha | conclusion |
+|---|---|---|
+| **357** | `ab2262c91` | success — the code, tests and register edits |
+| **358** | `c03f629d4` | success — the manifest bump that deployed it |
+| **359** | `104ef34f5` | success — Part 6 and this report |
+
+(Run 356 on `78a244bf0`, the baseline, was also green — so these greens are attributable to this
+work rather than inherited from a red baseline. Per §13 of the prompt, a red run here would have been
+mine.)
+
+## 12. `unproven.py --summary`
+
+```
+where felhom stands — 55 claims, verified_on 2026-08-09
+  walked   23
+  partial  14   (6 cite evidence, 8 prose only)
+  built    14   (0 cite evidence, 14 prose only)
+  missing  4   (0 cite evidence, 4 prose only)
+  NOT WALKED: 32 of 55
+```
+
+**No number moved.** Correct: this shipped an implemented-not-proven capability, which is exactly the
+status that does not advance the walked count. Moving it would require the live validation §7 says
+has not happened.
+
+## 13. Observations — noticed, deliberately not acted on
+
+- **`make docker-push` also tags and pushes `:latest`**, which the project's own rules forbid. I used
+  `make docker` followed by an explicit `docker push …:0.106.0` instead, so no `:latest` was moved.
+  The Makefile target is a loaded gun for anyone who runs the documented command; not changed here
+  because it is outside this task's scope.
+- **`internal/monitor/storage_fill_test.go` is not gofmt-clean, and was already so at `HEAD`** —
+  confirmed by stashing my changes and re-running `gofmt -l`. Not touched; it is not mine and fixing
+  it would put unrelated churn in this diff.
+- **The two checkers are now ~95% identical in their reachability half.** A shared helper is the
+  obvious next move and was deliberately not done here, per the prompt: they have different sources,
+  different error taxonomies (one has a sentinel, one does not) and different snapshot types, and the
+  existing code keeps them separate on purpose. Worth revisiting if a third box checker appears.
+- **The first ArgoCD sync reported `Synced/Healthy` at the PREVIOUS revision** (`ab2262c`) while the
+  pod was still `ContainerCreating`. Waiting and re-reading gave `c03f629` and the correct image. A
+  sync status sampled too early is not the deploy's verdict — the running image tag is.
+- **`alerting.box_unreachable_windows` is in no deployed config file**, by design, so the live hub is
+  running on the compiled default. If the operator wants to tune it, the key has to be added to the
+  hub ConfigMap first.

REPORT-instruction-closeout-2026-08-06.md

@@ -0,0 +1,147 @@
+# REPORT — instruction arc close-out, 2026-08-06
+
+Six items. Closes **R-229(b)** and **R-230(b)**; part-actions **R-230(a)**.
+Full accounting: `documentation/audits/LEDGER-instruction-closeout-2026-08-06.md`.
+
+> Second session in this repo, so this is a `REPORT-<topic>.md`; the shared `REPORT.md` was not
+> touched.
+
+## 1. Baselines and commits
+
+Reconfirmed live, all clean and synced: `felhom.eu` `92a076c239b9`, `felhom-controller`
+`66d80efb9f20`, `felhom-agent` `5b2666e3a2ae`, `app-catalog` `459766cb1639`.
+
+| Push | Repo | What |
+|---|---|---|
+| `aa74294` | felhom-agent | core + 4 rule files |
+| `15fa527` | felhom.eu | checks 6-content and 7 |
+| `f49b1f3` | felhom.eu | symlink + check 5 two shapes |
+| `5ca5082` | felhom.eu | t740, registers, ledger, S-37 |
+
+## 2. `felhom-agent/CLAUDE.md`
+
+**175 → 99 effective lines** (207 → 103 raw; 14,093 → 6,267 B). Measured 175, not the spec's 173 —
+part 2's CI correction added two. Four new `paths:`-scoped rule files, all ≤46 effective, beside the
+existing `health-checks.md`.
+
+**Glob overlap, stated not silently resolved:** `health-checks.md` already covered
+`internal/{storage,localapi,guesthook}/**`, which `storage.md` and `localapi.md` now also cover. Both
+load; neither supersedes. Each new file says so in its own text.
+
+## 3. Hook evidence — fresh sessions, both directions
+
+Agent rules (`claude -p`, timestamps from the log):
+
+```
+2026-08-06T09:46:15Z  path_glob_match  .../rules/proxmox.md   trigger=client.go
+2026-08-06T09:46:23Z  path_glob_match  .../rules/backup.md    trigger=doc.go
+```
+
+Negative control — reading `go.mod`, which matches no rule glob: **no rule fired at all**. And each
+positive fired *only* its own rule.
+
+Symlink — all three fresh sessions logged
+`session_start  Project  /mnt/5_hdd/felhom.eu/git/CLAUDE.md` (Claude Code reports the **link** path,
+not the resolved one). Because a logged path proves discovery and not delivery, a fourth fresh
+session **with no tools at all** was asked for standing rule 1 and returned it verbatim:
+*"Never combine a test run and a commit in one command…"*. **The content reaches the model. The link
+stays.**
+
+## 4. Memory — three false statements, and a corrected premise
+
+Backup: `/mnt/5_hdd/felhom.eu/backups/claude-memory-20260806-112853` (158 files). **158 before, 158
+after. Nothing deleted. Only three lines edited.**
+
+**The premise was wrong and the error was mine.** Part 2 reported "3 expired statements"; re-run with
+the cause printed, **all three matched an ISO date inside a markdown link target — a filename** —
+while the one real expired claim was written `~08-02`, carried no ISO date, and was never matched.
+
+The three genuinely false statements, each falsified by evidence:
+
+| Line | Was | Falsified by |
+|---|---|---|
+| 17 | `R-193 decision open` | row reads `**CLOSED 2026-08-05 — controller v0.200.0**` |
+| 34 | `demo boxes REMOTE till ~08-02` | `ssh felhom-pve` answers, holding `192.168.0.162/24` on `vmbr0` |
+| 68 | `OPEN R-25b` | `**SHIPPED hub v0.69.0 (2026-07-21)**` |
+
+Line 34 kept its durable half — `ssh felhom-pve` still resolves to the **tailnet** address.
+
+## 5. Gate: check 6 content WARNings + check 7
+
+First run over the real index: **32 version literals, 4 host addresses, 0 expired, 0 stale
+citations**. The 32 and the 4 are **deliberately left** for the loop to work on.
+
+**Check 7 finds nothing across the four repos right now** — 19 citations, 0 failures — because part 2
+already fixed the four stale sentences. The red-proof, not the zero, is what shows it works:
+
+```
+CLAUDE.md:90: claims R-168 is still open, but the register says it is closed. …
+      report when you use it.** Both facts are why CI is still owed (`OPEN-ITEMS.md` R-168).
+```
+
+Restored; gate green again. **Suite 39 → 68 assertions, 0 failures.**
+
+**Two bugs found by the check's own red-proofs, both of which would have shipped.** The state marker
+is not self-closing (`**SHIPPED — …**`), so the first parser read **R-168, its own founding case, as
+OPEN**; and the CLOSED exemption was line-wide, so "shipped" in a title pardoned `OPEN R-25b`. The
+second was found *only* because the red-proof failed to go red.
+
+**Deviation from the task's literal wording, stated:** check 7 triggers on an **openness claim**, not
+on every citation of a non-open item. The literal rule fires on ~30 legitimate provenance citations
+(`(R-161)`, `R-117 spike §6.3`); a gate that noisy gets switched off, which is R-29's own lesson. The
+spec's required pass case (`R-168, CLOSED 2026-08-02`) is tested and green.
+
+## 6. Symlink
+
+Live root file → relative symlink; backup `workspace-CLAUDE.md.bak-20260806-113952`. Check 5 asserts
+per shape: link → resolves to the versioned copy (dangling case red-proofed, since a dangling link
+loads **nothing**); two files → byte-identity as before. Installer links by default, **migrates** an
+existing regular file after backing it up and says so if it differed, and keeps `--copy`.
+
+## 7. t740 — measured, then corrected
+
+`target-selection.md` said the off-site tier is the N100's and **"(demo-hp has none)"**. Measured:
+
+```
+demo-hp# LC_ALL=C pvesm list felhom-pbs
+  felhom-pbs:backup/ct/9201/2026-07-28T19:19:45Z  pbs-ct  6264034048  9201
+  felhom-pbs:backup/ct/9201/2026-08-04T19:24:16Z  pbs-ct  4637840512  9201
+ep0:/mnt/pbs-datastore/ns/  →  c11  demo-felhom  demo-hp  rewalk
+```
+
+Two snapshots in demo-hp's **own namespace**, newest two days old. **The claim is false — and it was
+true when written**, going stale when F10 resolved 2026-07-23 (first snapshot 2026-07-28). Corrected
+with the measurement kept beside it. It mattered because the sentence was the stated reason for
+steering backup-disturbing tests at the other box.
+
+## 8. context7 — nothing written
+
+**No Node.js exists on DooPlex**: `npx`, `node`, `npm` all absent from `PATH`, no package installed,
+no runtime directory. The manifest is `{"command": "npx", "args": ["-y", "@upstash/context7-mcp"]}`,
+so `ENOENT` is literal.
+
+The fix is one package install away, **but that is not this task's call**: DooPlex is Tier 2 and *is*
+the recovery chain, and adding a language runtime to it deserves its own review. Measured surface, so
+the recommendation is evidence-based: **1 direct third-party dependency in the agent, 3 in the hub, 6
+in the controller** — ~8 distinct, small, stable packages. Per §6, nothing was written.
+
+## 9. Registers
+
+**R-229(b) CLOSED** · **R-230(b) CLOSED** · **R-230(a)** part-actioned, **bulk-correction ruling
+still owed and still yours** · **R-230(c)** (spec-as-failing-test pilot) untouched · **R-231**
+untouched. **S-37** added to `CONTEXT.md`.
+
+## 10. Observations — not acted on
+
+1. **R-129 has a second dated observation.** A key authenticated to demo-hp non-interactively today,
+   2026-08-06 — that is how §7's evidence was gathered. The row is still right to be open.
+2. **`~/.ssh/config` carries the same expired vacation claim** the index did ("at the VACATION site
+   until ~2026-08-02"). Host state, outside every repo and outside scope — the same statement in a
+   third place.
+3. **The hub operator UI did not answer over its ClusterIP** this session (hung, 2-min timeout); the
+   off-site evidence came from the boxes instead. The memory note describing that access path may
+   need re-checking.
+4. **`MEMORY.md`'s header still says "felhom-controller Project Memory"** though it indexes all four
+   repos. Left for the R-230(a) ruling.
+5. **`register_state` is a reusable register parser now.** Anything else needing "is R-nnn open"
+   should call it — its two parsing traps are not obvious and were both found the hard way.

REPORT-instruction-trim-part2-2026-08-06.md

@@ -0,0 +1,182 @@
+# REPORT — instruction trim part 2: `felhom.eu`, the memory index, the versioned workspace
+
+**2026-08-06.** Closes R-229 legs (a) and (c). Opens R-230 and R-231.
+Full per-block accounting: `documentation/audits/LEDGER-instruction-trim-part2-2026-08-06.md`.
+
+> **Parallel session.** A second Claude Code session was live in these repos throughout. Per
+> `CLAUDE.md`'s rule this report is a `REPORT-<topic>.md` sibling; the shared `REPORT.md` was not
+> touched.
+
+## 1. Baselines
+
+`felhom.eu` `c21bcf84f709` · `felhom-controller` `7db42c5fec3b` · `felhom-agent` `062a7027abff` —
+all clean, all `HEAD == origin/main` at start. Only `felhom.eu` was written to.
+
+## 2. `felhom.eu/CLAUDE.md`
+
+| | before | after |
+|---|---|---|
+| raw lines | 252 | **130** |
+| **effective lines** | **227** | **115** |
+| bytes | 16,698 | 7,824 |
+
+Split into a core plus `.claude/rules/{hub,website,manifests,docs}.md` — 4 files, all
+`paths:`-scoped, all ≤60 effective lines. **`instructions_gate` is registered** in
+`scripts/repo_gates.py`: six gates, all OK. Order was load-bearing — trim first, register second,
+because a registered-but-failing gate refuses every push through `.githooks/pre-push`.
+
+Two blocks were kept in the core against §6's sketch, both to avoid rebuilding the failure class
+they prevent: **register discipline** (applies to every session, not only `documentation/**` ones)
+and the **R-110 installer fence** (triggered by `scripts/felhom-host-install.sh`, which no fixed glob
+matches). Ledger §C.
+
+## 3. Hook evidence for Scenario B — both directions
+
+Two **fresh** sessions, so the negative control cannot be explained by prior loading:
+
+| Run | File read | `hub.md` | `website.md` |
+|---|---|---|---|
+| A | `website/index.html` | — | `path_glob_match` |
+| B | `hub/internal/api/handler.go` | `path_glob_match` | — |
+
+**Why fresh sessions were required — the session's most useful negative result:** after creating
+`.claude/rules/`, in-session reads that should have matched produced **no hook line at all**. A
+directory whose instructions were already seeded is not re-scanned. A rule file can be correct, pass
+every gate, and reach the model never, purely because of when it was created.
+
+## 4. Always-loaded total
+
+Measured `/context` (operator-supplied, this session): Memory files held at **11.5k tokens** across
+three rule loads while Messages grew 8 → 105.7k. **The 11.5k baseline is unchanged by this work**,
+because `MEMORY.md` moved 17,688 → 17,977 bytes (+1.6%) — the reconciliation was net-neutral by
+design, trading 40 archived entries for 4 indexed ones plus trimmed detail. A fresh session is needed
+for a post-change token reading; the byte figures above are exact.
+
+## 5. Memory reconciliation
+
+Backup: `/mnt/5_hdd/felhom.eu/backups/claude-memory-20260806-103418` (158 files, taken first).
+
+| | before | after |
+|---|---|---|
+| `.md` files | 158 | **158 — zero deletions** |
+| orphaned | **44** | **0** |
+| indexed / archived | 113 / — | 117 / **40** |
+| `MEMORY.md` | 145 ln / 17,688 B | **150 ln / 17,977 B** |
+
+**Headroom: 50 lines and 7,622 bytes (29%)** against the 200-line / 25 KB limits. The
+index-vs-archive discriminator was the store's own `type:` field: all 4 `reference` orphans indexed,
+all 39 `project` + 1 untyped archived.
+
+## 6. Staleness diagnosis — **diagnosed, not fixed** (R-230(a))
+
+- **21 lines** carry component version literals
+- **5 lines** carry bare host addresses `nodes.md` owns
+- **3** expired temporal statements; **2** undated open items
+
+**The structural finding, not the counts:** `felhom-agent/CLAUDE.md` had its expired
+`TEMPORARY … until ~2026-08-02` block deleted in part 1 and the gate now fails any such block — while
+`MEMORY.md` still asserts *"demo boxes REMOTE till ~08-02"*. The contradiction was **moved, not
+resolved**: the hand-written half is clean, the auto-written half — which is larger and loads every
+session — still states the retired fact.
+
+## 7. Secrets scan
+
+535 keyword-matching lines across 104 files; **1** `key: value`-shaped hit, which is prose; **0**
+private-key blocks. **No credential values.** Nothing from the store was committed regardless.
+
+## 8. Gates
+
+`repo_gates.py --fast` → **6 gates, all OK, rc=0**. Test suite **20 → 39 assertions, 0 failures**.
+
+Red-proof against the **real** store, not a fixture — ceiling 200 → 100:
+
+```
+memory index             : 150 lines (ceiling 100), 17977 bytes (ceiling 25600)
+instructions_gate: 1 FAILURE(S)
+  - /mnt/5_hdd/felhom.eu/git/.claude-memory/MEMORY.md: 150 lines, ceiling 100. Content past the
+    auto-memory limit is DROPPED WITH NO ERROR — a truncated index is a silent failure with no
+    observable. …
+```
+
+Ceiling restored; gate `rc=0` and suite 39/0 again.
+
+## 9. Installer
+
+Idempotency: run 2 reported *"nothing to do"* and `settings.json` sha was **identical** before and
+after — the claim is "changed nothing the second time", not "ran twice without erroring".
+
+Merge safety: `sha256` of `settings.json` **minus `.hooks`** was `f1775e94aa9d1ca9` before and after
+the write; all 7 top-level keys, 30 permission entries, 3 plugins, `effortLevel`, `tui` and
+`additionalDirectories` survived byte-identically.
+
+## 10. Backup coverage — positive observable
+
+From the journal of the real unit:
+
+```
+Including Claude auto-memory store: /mnt/5_hdd/felhom.eu/git/.claude-memory
+start backup on [/mnt/4_hdd/data /mnt/5_hdd/felhom.eu/git/.claude-memory]
+```
+
+**Completed and verified in the repository.** Snapshot `b587f775`, 58,158 files / 405.865 GiB in
+27:56, `994.132 MiB added (77.440 MiB stored)` — 77 MiB stored for a 405 GiB re-read confirms the
+one-time cost was I/O, not storage. Contents: **161** `.claude-memory` entries — **118/118** top-level
+`.md` and **40/40** under `archive/`. The 03:07 snapshot holds `/mnt/4_hdd/data` only, so the two
+snapshots are a clean before/after in one listing.
+
+**A false alarm I raised against my own instrument.** The first check used
+`restic ls <snapshot> <path>` and reported **0 of 40** archive files — which read exactly like 40
+memories silently unprotected. It was wrong: restic 0.18.0's path filter lists entries *at* that path
+and does not recurse. The unfiltered listing shows all 40. Recorded because it is this project's own
+rule — *an instrument that can drop results silently is not a measurement* — biting a measurement made
+**to verify a safety property**.
+
+**Three caveats that make this weaker than "backed up" sounds:** the destination is on the **same
+physical disk** as the store; the DooPlex backup set has **no off-site leg**
+(`sync-hetzner-backups.sh` is jarrs.eu and pulls the other way); and `/opt/backup/scripts/` is itself
+**unversioned host state** (R-231).
+
+## 11. Rules report — first run
+
+8 events; `session_start` 4, `path_glob_match` 3, `nested_traversal` 1. **6 of 9 rule files had never
+fired.** Not a defect list: the log only covers since the hook was armed, and
+`felhom-controller/gates.md` proves the distortion — it fired at 08:11 the same day, before
+installation, and reads as silent.
+
+The hook now **self-rotates at 5 MB**, one generation.
+
+## 12. context7 — nothing written
+
+`plugin:context7:context7` is **`✘ failed`** (ENOENT on `npx -y @upstash/context7-mcp`); `/mcp` lists
+only the six Google auth stubs. Per §5 that means **write nothing**. The Go code is not the use case
+either: one direct dependency in `felhom-agent`, and the hub and controller are stdlib-only by
+standing rule.
+
+## 12b. A stale claim the checklist caught — corrected in all four repos
+
+Confirming this session's own push by run ID (checklist's last item) surfaced that **four instruction
+files claimed CI was still owed** (R-168) — and **R-168 was CLOSED on 2026-08-02**. CI exists, runs
+`repo_gates.py --fast` on every push, and emails on failure; this session's commits produced runs
+117 (`success`) and 118.
+
+One of the four was `felhom.eu/CLAUDE.md`, where **this session carried the stale sentence forward
+through the trim**. `felhom-agent/CLAUDE.md` **contradicted itself** — its release section already
+said R-168 mails the failure. Corrected in all four, pushed.
+
+**Two lessons about this task, not about CI:** a trim is a *volume* operation and carries stale
+content forward unless each claim is re-checked; and the gate cannot catch this class — "this
+register item is closed" is not mechanically checkable from the instruction file. The thing that
+caught it was the checklist item demanding a **run ID** rather than a memory.
+
+## 13. Registers
+
+- **R-229** re-scoped — legs (a) and (c) **CLOSED**; (b) remains; (d) moved to R-230.
+- **R-230** opened — the auto-written-staleness ruling, the symlink decision, the spec-as-failing-test pilot.
+- **R-231** opened — `/opt/backup/scripts/` is unversioned host state.
+- **S-36** added to `CONTEXT.md` standing rulings.
+
+## 14. Observations — not acted on
+
+`target-selection.md`'s t740 error; `felhom-agent/CLAUDE.md` at 173 effective lines; the
+`/context` Messages-accounting inference (§A of the ledger — reasoned, not measured); `MEMORY.md`'s
+header still reading "felhom-controller Project Memory" though it indexes all four repos.

REPORT-r204-item4.md

@@ -0,0 +1,219 @@
+# REPORT — R-204 item 4 / R-193 credential half (hub v0.96.0), 2026-08-05
+
+**A rebuilt box asks for its credential back, and the hub answers.** The last of the four manual
+interventions the 2026-08-04 drill needed. Controller half: `felhom-controller` v0.199.0.
+
+> **Written as `REPORT-r204-item4.md`, not `REPORT.md`.** A PARALLEL SESSION is active in this shared
+> clone — it committed `c917251` (the R-205…R-211 disk containment) between my baseline read and my
+> first commit. Per `CLAUDE.md`'s parallel-session rule the second session never touches the shared
+> `REPORT.md`. Explicit per-file staging was used throughout; verified after the fact that none of my
+> three commits carries a foreign file.
+
+## 1. Baselines, re-read on arrival — with a drift
+
+| Repo | Expected | Found |
+|---|---|---|
+| `felhom.eu` | `0dbd954fec90` / hub v0.95.0 | **DRIFTED to `ee9d9bf`** — one docs-only commit ahead (R-205…R-211 spike output). Hub code, `manifests/hub.yaml` and the deployed image were all still v0.95.0, so the drift did not affect the work. A second foreign docs commit (`c917251`) landed mid-session. |
+| `felhom-controller` | `68f195676b91` / v0.198.0 | exact match, tree clean |
+| `felhom-agent` | v0.125.0 | `3f5f61b`, clean (rider only, **no version bump**) |
+| `app-catalog-felhom.eu` | n/a | `122bbee`, clean (rider only, **no version bump**) |
+
+**The task's "highest register ID in use: R-204" was STALE.** Grepped before minting, as instructed:
+the highest is **R-211**. This session mints **R-212** (§8 below).
+
+## 2. Part 2.0 FIRST — does the stored value survive a consume? **YES.**
+
+Established from the schema and the code, deliberately **not** from the PBS analogy:
+
+- `one_time_secrets` declares `value TEXT NOT NULL` (store.go, the CREATE TABLE).
+- `ConsumeOneTimeSecret` runs `UPDATE one_time_secrets SET consumed_at = datetime('now')` — **it
+  touches nothing else.** The value column is never cleared or overwritten.
+
+**So restage-before-mint is possible**, and `RestageOneTimeSecret` mirrors `RestageHostPBSSecret`:
+clear the consumed flag, never touch the value, never bump a generation, return false when no row
+exists so the caller escalates.
+
+This is asserted rather than assumed by `TestRestageOneTimeSecret_ReArmsTheSameValue`, which checks
+the **same** value comes back — so a future hardening that cleared the column fails loudly instead of
+silently turning every rebuild into an external mint. The two secrets are different objects with
+different lifecycles, and assuming a shared shape is how two earlier sessions confused the credentials.
+
+## 3. The declared state — name, shape, and how a pre-upgrade hub treats it
+
+**Name:** `needs_credential`, on the report's existing `offsite` object (not a new top-level field).
+Constants: `backup.OffsiteStateNeedsCredential` / `offsiteheal.StateNeedsCredential`, pinned to each
+other by `TestDeclaredStateStringMatchesTheReconciler`.
+
+**Shape, as received by the hub live** (report id 16743):
+
+```json
+{"enabled": false, "escrow_state": "", "state": "needs_credential",
+ "snapshot_count": 0, "repo_size_bytes": 0, "quota_gb": 0}
+```
+
+**A pre-upgrade hub treats it as INERT, established from the readers' code rather than assumed:**
+
+| Reader | Behaviour on the declaration | Why |
+|---|---|---|
+| `OffsiteChecker.isStale` | no staleness alarm | returns early on `!off.Enabled` |
+| `OffsiteChecker.fillBand` | `bandOK` | returns OK on a zero quota/size |
+| `encoding/json` | ignores `state` | unknown field, not an error |
+| **`reportHasOffsite`** | **would have MISREAD it** | see below — the one reader that needed changing |
+
+**A configured box's report JSON is byte-identical to v0.198.0's** — `state` is `omitempty` and is
+never set on a configured box (`TestOffsiteDeclare_ConfiguredBoxJSONIsUnchanged`).
+
+## 4. The debounce: TWO distinct reports, derived not chosen
+
+The controller reports every ~15 minutes. Two distinct declarations mean the state survived a full
+report cycle, and a restart, a slow first report or a transient config read all resolve well inside
+one. **One** would act on a blip; **three** would leave a genuinely stranded customer waiting ~45
+minutes for the one thing they cannot obtain any other way. The reconciler's own sweep is 5 minutes —
+deliberately faster than the report cadence so it adds no latency of its own — and the debounce counts
+**fresh evidence, not ticks**, so a fast sweep cannot shorten it.
+
+## 5. §8.4 — is there a deliberately-unhealed state here? **Yes, and it is excluded upstream.**
+
+`pbsdrheal` refuses to heal `verify_failed` because re-staging would not help it and it must stay
+loud. The off-site analogue is the **regressed** shape: a box that HAD a working tier and lost its
+target while still holding its repository password. Re-arming a credential would not help it either.
+
+**It cannot reach this reconciler at all** — the controller's declaration predicate requires the
+repository password to be **absent**, so a box that still holds one never declares. The unhealable
+case is excluded *by construction*, upstream, rather than filtered out in a switch. Stated explicitly
+because "there is nothing like that here" is usually wrong, and this was checked rather than assumed.
+
+## 6. Files modified
+
+| File | Change |
+|---|---|
+| `hub/internal/store/store.go` | **new** `RestageOneTimeSecret`, **new** `LatestReportOffsiteDeclaration`; `reportHasOffsite` tightened to require `enabled:true` (+ its comment corrected) |
+| `hub/internal/offsiteheal/reconciler.go` | **new package** — the reconciler |
+| `hub/internal/offsiteheal/{reconciler,wiring}_test.go` | **new** — Scenarios A–F + the wiring AST test |
+| `hub/internal/store/offsite_restage_test.go` | **new** — the value-survives proof + the `reportHasOffsite` equivalence table |
+| `hub/internal/monitor/offsite_delivery.go` | `shapeDeclared` outranks both inferred shapes; `maybeHeal` stands down with a record |
+| `hub/internal/monitor/offsite_declared_test.go` | **new** — the demo-hp shape + the cross-package string pin |
+| `hub/cmd/hub/main.go` | wires + runs the reconciler (`OFFSITEHEAL_ONLY_CUSTOMER` for a supervised rollout) |
+| `.githooks/pre-push` | the workspace-root assertion (rider) |
+| `manifests/hub.yaml` | image `0.95.0` → `0.96.0` |
+
+**Commits on `main`:** `f62a115` (hub half) · `fe1e816` (rider) · `b2462b8` (CHANGELOG) ·
+`4114c5f` (manifest). **Deployed:** `felhom-hub:0.96.0`, ArgoCD **Synced/Healthy**, `deploy/hub`
+rolled out, startup log carries `offsite credential self-heal reconciler started (interval 5m,
+debounce 2 reports)`.
+
+## 7. Tests and red-proofs
+
+Green gate: `go build ./... && go vet ./... && go test ./...` in `hub/` — **rc=0**.
+`python3 scripts/repo_gates.py --fast` — **all five gates OK**.
+
+| Scenario | Test | Result | Red-proof — what was mutated | Outcome |
+|---|---|---|---|---|
+| A+D | `TestScenarioAD_DeclaringBoxIsRestagedNotMinted` | PASS | inverted `heal()` so Reissue runs before Restage | **FAILED** — *"a sustained declaration was not served: restages=0"* |
+| B | `TestScenarioB_SilentBoxIsNeverActedOn` | PASS | — | — |
+| C | `TestScenarioC_HealthyBoxIsAPureNoOp` | PASS | — | — |
+| E | `TestScenarioE_NothingToRestageEscalatesOnce` | PASS | — | — |
+| F | `TestScenarioF_BlipIsAbsorbedByTheDebounce` | PASS | `debounceReportsDefault` 2 → 1 | **FAILED** — *"a one-report blip triggered a credential action"* (and Scenario A+D also failed, *"acted on a SINGLE declaration"*) |
+| H | `TestMainWiresTheOffsiteHealReconciler` | PASS | (AST; comments dropped) | — |
+| — | `TestRestageOneTimeSecret_ReArmsTheSameValue` | PASS | — | — |
+| — | `TestReportHasOffsite_EnabledOnly` | PASS | — | — |
+| — | `TestShapeOf_DeclarationOutranksBothInferredShapes` | PASS | — | — |
+| — | `TestDisabledDescriptorIsNeverHealed`, `TestBlockedCustomerIsNeverHealed`, `TestRestageErrorDoesNotEscalate` | PASS | — | — |
+
+**A test that first passed for the wrong reason, caught and fixed.** `TestBlockedCustomerIsNeverHealed`
+initially seeded `Status: "blocked"` through `SaveCustomerConfig`, whose INSERT does not carry the
+column — so the customer was never actually blocked and the assertion would have been vacuous. It now
+goes through `SetCustomerConfigStatus` **and asserts `IsCustomerBlocked` before proceeding**.
+
+## 8. Part 4 — STOPPED, corrected, then COMPLETED with the operator's confirmation
+
+§8.7: *"If the paths do not match R-193's record exactly, STOP. A near-match on a protected endpoint
+is not a match."* **They do not match.**
+
+Measured read-only over SFTP, using each box's own credential, from inside its guest:
+
+| Customer | Path | Size | What it is |
+|---|---|---|---|
+| demo-felhom (`u629488-sub1`) | `/home/felhom-repo` | **1.2 G** | **LIVE** — the configured `repo_path`. Unopenable by the box (R-193), but NOT a set-aside store |
+| demo-felhom | `/home/felhom-repo.orphaned-20260717` | **1.4 G** | set aside |
+| demo-felhom | `/home/felhom-repo.orphaned-20260718` | **3.0 M** | set aside |
+| demo-hp (`u629488-sub3`) | `/home/felhom-repo` | **582 K** | **LIVE** |
+| demo-hp | `/home/felhom-repo.orphaned-20260804` | **43 M** | set aside |
+
+The ruling says *"~1.2 GB across the two demo boxes, in set-aside stores"*. Reality: **three** set-aside
+stores totalling **~1.45 GB** — and **the figure that matches ~1.2 GB is demo-felhom's LIVE
+`felhom-repo`**. Had the size been used to identify the target, the live repository would have been
+deleted. Filed as **R-212**, and the operator was asked with the corrected list.
+
+**The operator confirmed *delete all three*, and all three were deleted.**
+
+| Account | Deleted | Freed |
+|---|---|---|
+| `u629488-sub1` | `felhom-repo.orphaned-20260718` | 3.0 M |
+| `u629488-sub1` | `felhom-repo.orphaned-20260717` | 1.4 G |
+| `u629488-sub3` | `felhom-repo.orphaned-20260804` | 43 M |
+
+**AFTER, on each account, a full listing:** `u629488-sub1` holds `.ssh` + `felhom-repo` (**1.2 G**,
+live); `u629488-sub3` holds `.ssh` + `felhom-repo` (**582 K**, live). **Nothing outside the three named
+paths was touched**, and no prune job, datastore or live repository was involved.
+
+**Proof nothing live was caught:** a REAL off-site run triggered on demo-hp immediately afterwards
+(`POST /backup/offbox/run`, authenticated + CSRF) returned `status: "ok"`, `orphaned: false`,
+`last_error: ""`, `last_run: 2026-08-05T09:14:02Z`, `last_duration: 1m24s`, 6 snapshots.
+
+**METHOD NOTE, worth carrying forward.** The Hetzner storage box runs a **restricted shell**: no shell
+operators, no `test`, no GNU long flags. The first attempt used `test -d X && rm -rf -- X` and got
+*"Command not found. Use 'help' to get a list of available commands."* — **it failed CLOSED, verified
+by a byte-identical before/after listing.** `rm -r <path>` issued as ONE simple command is the working
+form, and the smallest store was deleted first to confirm the syntax before the 1.4 GB one.
+
+## 9. Live validation
+
+| # | What | Observable |
+|---|---|---|
+| 1 | **A healthy box: no action, no events** | demo-hp reported healthy throughout (`enabled:true`, no `state` key — report id 16742). Zero `offsite_selfheal_*` rows in the hub DB. **Honest limit:** the reconciler is silent by design on a healthy sweep, so there is no per-tick positive observable; what I have is the startup line proving `Run` was entered, the DB showing no events, and Scenario C. |
+| 2 | **The declared state, produced live without wiping a box** | demo-felhom 9201 arranged **reversibly** into the stranded shape (settings + `offbox/` backed up first; the `offbox` key removed and `repo_password` moved aside). Report **id=16743** reached the hub carrying `{enabled:false, state:"needs_credential", quota_gb:0, repo_size_bytes:0}`. Restored the same minute; report **id=16744** is healthy again. **The single declaration was absorbed by the debounce — no self-heal event fired** — which is Scenario F demonstrated on live infrastructure rather than in a fake. |
+| 2b | **The ACK field is no longer discarded** | Both demo boxes' `settings.json` now carry `hub_escrow_identity_present = true` — the recorder working on a HEALTHY box, which is the case that used to return early. |
+| 3 | **A push from outside the workspace is refused** | A scratch clone at `/tmp/.../outside-clone`: `pre-push: PUSH REFUSED - this clone is OUTSIDE the felhom workspace`, naming `/mnt/5_hdd/felhom.eu`, **before the gates run**. **Red-proof:** with the assertion removed the same push **succeeded** (`rc=0`, new branch on a throwaway bare remote). In-workspace pushes ran normally all session. |
+| 4 | **Part 4** | **Completed after the STOP and a corrected list.** Full listings before and after on both accounts; both LIVE repos intact; a real off-site run on demo-hp succeeded immediately afterwards (`status: ok`, `last_run 09:14:02Z`). |
+
+**Not fired live: the hub actually re-staging a credential.** Doing so would have re-applied
+demo-felhom's off-site target mid-session and changed the very state Part 4's listing describes. It is
+proven by Scenarios A/D/E with the store primitive proven separately against a real SQLite database.
+
+**Teardown:** the scratch clone and throwaway remote are removed; demo-felhom's `settings.json` and
+`offbox/` restored from the backup taken first (verified: `enabled=True`, `escrow_state=escrowed`,
+`repo_password present=True`); the backup copy remains at `/root/r204-backup` on the guest for
+traceability. Nothing else was provisioned.
+
+## 10. Registers
+
+- **R-204 — ALL FOUR ITEMS CLOSED.** Both 2026-08-05 rulings recorded on the row: the declared-state
+  trigger with its four-meanings-of-absence reasoning, and that the recovery preview's
+  dashboard-password exposure is **metadata, not content, and accepted**.
+- **R-193 — credential half CLOSED.** Still open under this ID: the customer-facing recovery **screen**,
+  and the ciphertext deletion (now R-212).
+- **R-192 — CLOSED, guard half by REPLACEMENT.** The counting inference is outranked by the declaration.
+- **R-202 — untouched, still open.**
+- **R-212 — NEW** (R-211 was the highest; grepped): the halted deletion, with the full measured listing.
+
+## 11. CI
+
+felhom-agent **0404f60**, app-catalog **ee2c810**, felhom-controller **992803c**, felhom.eu
+**4114c5f** — run IDs and conclusions confirmed in the controller's `REPORT.md` §11 and re-checked at
+session end. **`--no-verify` was NOT used**; every push ran the pre-push gate, including the new
+workspace-root assertion.
+
+## 12. Observations — noticed, NOT acted on
+
+- **A second, accidental barrier exists outside the workspace and should not be relied on:**
+  `felhom-agent`'s `reuse-refs` gate FAILS in a clone outside the workspace because the shared
+  `reuse_refs_check.py` lives in the `felhom.eu` sibling. That is why the first Scenario-G red-proof
+  had to be redone with `app-catalog-felhom.eu`, whose fast gate is self-contained. It is incidental,
+  repo-specific and not a substitute for the assertion.
+- **`offsite_credential_restaged` (the R-71c event) has still never fired for any customer.** The new
+  reconciler emits its own `offsite_selfheal_*` events, so the old one may now be permanently dead —
+  worth a deliberate look rather than leaving two event families for one concern.
+- **demo-felhom's live `felhom-repo` is 1.2 GB of ciphertext its own box cannot open** (0 snapshots,
+  `last_status: error`). It is not a set-aside store, so it is out of R-212's scope as filed — but it is
+  the largest single block of unrecoverable data in the fleet and nothing currently plans its disposal.

REPORT-r241-spike-golden-teardown-2026-08-07.md

@@ -0,0 +1,194 @@
+# REPORT — R-241 spike · golden 0.205.0 · finalwalk teardown (2026-08-07)
+
+*A sibling report: `REPORT.md` is overwritten per-session and a parallel session shares this clone.*
+
+**Three parts, in the order the venue's perishability required.** The spike read VM 324 before
+anything else touched the fleet; the bake and the vouch followed; the teardown went last.
+
+---
+
+## 1. THE SESSION'S ANSWER — R-241 is a MINTING defect, not a screen-predicate defect
+
+**This reverses the fix.** The recovery screen was telling the truth: there genuinely was nothing
+recoverable under the key the box held, because **the box minted that key itself, over the top of a
+sealed package it already knew the hub was holding for it.** Mending the predicate would have papered
+over a box quietly making its own backup history unopenable.
+
+**Three measurements, taken from the venue this session, not copied from last night's journal:**
+
+1. **`WriteOffboxSecrets` (`offbox.go:411`) mints on ONE input — does the file exist.** No settings
+   read at all, while its two neighbours in the same file, `OffsiteRecoveryOffer()` (`:1412`) and
+   `needsOffsiteCredential()` (`:1377`), both consult `GetHubEscrowIdentityPresent()`. **The same fact
+   is available on three paths and used on two.**
+2. **That flag was not merely available — it was the precondition of the chain that reached the
+   minting.** The 5-minute retry job logs only when `RetryIfDeclared` fires, which requires the
+   declaration, which requires the flag. The venue logged
+   `credential retry: … (the box still declares a need; retrying)` at **02:48:03Z** and five times
+   after — **thirty minutes and six ticks before the mint at 03:18:06Z.**
+3. **The box computed the right answer and threw it away.** At **03:28:03Z** — thirty-five minutes
+   before the customer looked — `EscrowAutoConfirmer.Reconcile` (`escrow_confirm.go:154`) logged
+   `the hub's escrow blob does not cover the CURRENT repo password (hub hash 30ef574fe492… != local
+   9b4a9a9dcec7…) … staying pending`. It is recomputed on every report cycle, **never persisted,
+   never surfaced.**
+
+**And the hub explicitly disclaims doing this** — `offsiteheal`'s package doc: *"it never runs, or asks
+for, an escrow ceremony… **credential automatic, key customer-present** — the ruling this session
+implements and must not quietly widen."* The repository key is created **in the seam between two sides
+that each honoured their contract**, by a helper doing exactly what its doc comment says. That is why
+it survived review: every individual comment is accurate.
+
+**Corroboration from both sides, measured independently here:** the two key hashes on the venue
+(`30ef574f…` current, `9b4a9a9d…` in `repo_password.selfheal-aside`, mtime 03:18:06) reproduce the
+journal's figures exactly; and the hub's `host_escrow` row for `finalwalk-ed05d6` seals
+`restic_pw_sha256 = 30ef574f…` with a 572-byte `identity_blob` and **no superseded row** — so the hash
+the box logged as *"hub hash"* is confirmed from the database, not inferred.
+
+**Q2 — shape (b) is structurally unreachable**, not merely unfired: `markOrphaned()` has one producer,
+`ensureOffboxRepo()`, reached only from inside a run, and every run passes `if !m.offboxEscrowed()`
+(`offbox.go:743`) **first**. The box was `pending` and could not stop being pending, because the
+auto-confirm flips only on a hash match. *Positive control, because an absent log line is not
+evidence:* the scheduler was alive throughout (241 `agent-channel-health`, 120 `stack-scan`, 48
+`offsite-credential-retry`, 16 `hub-report`), and `offbox-backup` is a `sched.Daily` leg whose slot
+fell **before** the destruction — the absence is explained, not just observed.
+
+**Q7 — the „Helyreállítási kód létrehozása" button.** It does **not** destroy the data: `SaveHostEscrow`
+demotes the current row into `host_escrow_superseded` **copy-before-delete, `identity_blob` included**
+(R-198). But the read path for a retained package is **unbuilt** (R-199), so it converts a
+one-screen-away self-service recovery into one needing an operator and tooling that does not exist.
+**And it re-enables the screen while invalidating the code that screen accepts** — a worse trap than a
+plain dead end, because it looks like progress. *(Reasoned from code and the hub schema; I did not
+press it — that is a state change and would have destroyed the evidence.)*
+
+**Two findings nobody asked for**, both filed: **R-243** (a box in this state silently stops backing up
+and **no alarm fires** — three individually-correct exclusions leave one state unobserved) and the trap
+in the obvious fix (`ResetOrphanedRepo` clears the orphan flag without a ceremony, so a hash-mismatch
+discriminator alone would re-offer the screen forever to a customer who declined the old data).
+
+**Output:** `audits/SPIKE-r241-recovery-offer-2026-08-07.md` — question/method/measurement/ruling, the
+Q4 seven-state table, ranked options, and **four operator decisions stated and left unanswered.**
+**No product code was written, in any part of this session.**
+
+---
+
+## 2. GOLDEN 0.205.0 — baked, verified, VOUCHED (R-239 CLOSED)
+
+| | |
+|---|---|
+| version | **0.205.0** · sha256 `8f49b2e8ccbc86a49df821fee9fb00c07293758811d3d0f0512dd0cf5fd54ee8` |
+| size | 656,937,561 bytes (uncompressed 2,003,343,360) |
+| MinAgent | 0.127.0 |
+
+**Round-trip verified rather than trusted:** the published bytes were fetched back (HTTP 200, byte
+count matches), re-hashed **independently of the baker** (matches), `zstd -t`'d clean, and
+`./etc/felhom-controller-image` was read **out of the downloaded archive** →
+`felhom-controller:0.205.0`. That last step is the one that matters, because `GOLDEN_VERSION` is
+derived from the tag argument and could have been right over stale content. A **third witness**: the
+hub's own dropdown lists `0.205.0` with `data-sha="8f49b2e8…"`.
+
+All acceptance markers pass (`docker OK (overlay2` ×1, `including mount point` ×2 = rootfs + mp0,
+`upload OK (HTTP 201)` ×1, and 0 each for `excluding`/`FATAL`/`ERROR:`/`WARN:`); unit
+`Result=success`, `ExecMainStatus=0`. Bake VM torn down: CT 9100 purged, secrets shredded, qemu
+observed gone via `ps -eo comm`, `drill.qcow2` reverted to `virgin`.
+
+**Secret hygiene:** token copied file→file; the invocation lives in an in-VM runner that reads the
+token itself, so it never reached a command line (`systemctl show … | grep -c -F <token>` → **0**);
+literal-value leak grep on the **committed** log → **0**, and **the instrument was proven first** —
+token appended to a throwaway copy → 1 hit → copy shredded → the 0 is a measurement.
+
+**Vouched, with the operator's approval.** In the event it was a **ONE-field change, not three** — read
+from live `hub_settings` before and after, not assumed:
+
+| field | before | after |
+|---|---|---|
+| `artifact_golden_version` | 0.203.0 | **0.205.0** |
+| `artifact_golden_sha256` | `3039c6ff…` | **`8f49b2e8…`** |
+| `artifact_agent_version` | 0.127.0 | 0.127.0 — **unchanged** |
+| `artifact_min_agent` | 0.127.0 | 0.127.0 — **unchanged** |
+
+**A trap worth naming:** `wrapper_sha256` is read from the form and **cleared when omitted**. A
+headless POST that forgets it silently drops the PBS-DR wrapper hash. It was carried through
+explicitly and verified present afterwards. **The R-120 gate passed exactly** — the newest controller
+the fleet reports is 0.205.0 (demo-hp), so a **0.204.0 golden would have been REFUSED**. Vouching is
+reversible; a bake never deletes an older golden's package.
+
+**§4.1's systemic half is recorded, NOT built** → **R-242**, with three proposed shapes and a stated
+earliest-catch (a `repo_gates.py` comparison of the manifest's `golden_version` against the newest
+released controller — it fires on the push that creates the gap, before any box is installed).
+
+---
+
+## 3. TEARDOWN — `finalwalk`, all five layers
+
+Enumerated first and cross-checked against the hub's **own** delete-preview, which agreed in every
+field. Matched on **identity**, never on size.
+
+The cascade refuses a live host, so VM 324 was stopped at 07:23:56Z (guarded on `qm config 324`
+reading `name: finalwalk-appliance` — `demo-hp` also carries a guest 9201) and aged past the 30 m
+`stale_threshold`, read from the deployed config. `POST /configs/finalwalk/delete` with all six gates
+→ the hub's leg-by-leg log shows host deleted, off-site sub-account 285071 deprovisioned, PBS
+namespace deprovisioned (`existed=true` — the positive observable), claim reset, residue purged
+(**124 rows, matching the preview exactly**), `COMPLETE … full teardown`. Then `qm destroy 324
+--purge`.
+
+**Every layer verified absent with a positive control that must survive, and does:** VM 324 gone (VM
+300 `drill-r50` remains) · all 13 hub tables at 0 including **both** escrow tables (demo-felhom 50,823
+/ demo-hp 7,640 / peti 1,827 rows remain) · Storage Box `u629488-sub4` gone (sub1/2/3 remain) · `ep0`
+namespace `finalwalk` gone (demo-felhom, demo-hp remain) · WireGuard `10.77.0.5` gone **from the live
+`wg show` on ep0, not merely from the hub DB** (`.2/.3/.4/.250` remain). **14.06 GiB reclaimed**,
+against 15 G measured before deletion.
+
+**R shredded with a planted-copy control** — plant → search finds both → shred → same search finds 0.
+The zero was not believed until the instrument was proven.
+
+### ⚠ And a correction I am reporting rather than quietly fixing
+
+A **full census** (every table, every column) after the "COMPLETE" cascade found **61 rows still
+matching `finalwalk`**. Four sources are deliberate (`events`, `notification_log`, `host_deletions`,
+`customer_resets` — the cascade's header says provenance outlives every tier). **The fifth is a gap:**
+`app_log_issues`, 29 rows, not covered by the residue purge — and **systematic**, with `c11` 40,
+`rewalk` 20 and `part4` 24 still present from the 2026-08-06 teardown, **whose ledger recorded "0
+occurrences"**. That claim used a narrower query than a census and does not hold. Both the prior ledger
+and the register now carry the correction.
+
+**No secret material is involved.** The table is a fleet-wide aggregate; 12 of the 29 rows are
+`finalwalk`-only orphans and **17 are shared with live customers and must be de-referenced, not
+deleted** — very likely why the leg was never written. Filed as **R-244**, not fixed: a cascade change
+needs its own red-proof. **The reusable lesson: a per-table absence query is not a census.**
+
+---
+
+## Register
+
+| ID | Movement |
+|---|---|
+| **R-241** | **RULED** — minting defect. Diagnosed, **not fixed**; four operator decisions owed |
+| **R-239** | **CLOSED** — golden 0.205.0 baked, verified and vouched |
+| **R-242** | **NEW** — a release is not delivered until a golden carries it; recorded, **not built** |
+| **R-243** | **NEW** — the R-241 state silently stops off-site backups with no alarm |
+| **R-244** | **NEW** — `app_log_issues` survives the delete cascade, across all four torn-down venues |
+
+**Highest register ID moved R-241 → R-244.**
+
+## Verification
+
+| | |
+|---|---|
+| commits | `71c43f87c240` (spike) · `08b75e602e01` (bake evidence) · `db578cd44d3e` (R-239 closed, map + STATUS) · this one |
+| CI | run **233** `71c43f87c240` success · run **234** `08b75e602e01` success — matched by `head_sha`, pulled not assumed |
+| `--no-verify` | **not used.** The pre-push hook ran `repo_gates.py --fast` on every push and reported `gates OK` |
+| gates | `python3 scripts/repo_gates.py --fast` → all six OK before each commit |
+
+## What did not run, and why
+
+- **No product code, deliberately** — Part 1 was a question, and the answer changes what the fix
+  should be. Beginning a candidate before the operator rules on §"THE OPERATOR'S DECISION" would
+  prejudge it.
+- **Q4 row 7 and Q7's post-button behaviour are reasoned from code, not measured.** Both need a state
+  change on the venue; either would have destroyed the evidence for everything else. They need a fresh
+  fixture and their own session — and **row 7 shapes the fix**, so it matters.
+- **R-242, R-243 and R-244 are filed and not built** — R-242 because the task scoped it record-only;
+  the other two because they surfaced inside a spike and an operation, and each needs its own
+  red-proof.
+- **The exact wall-clock at which `hub_escrow_identity_present` first became true is not measured** —
+  `SetHubEscrowIdentityPresent` writes only on change and logs nothing. The bound that matters is
+  established by control flow: true at or before **02:48:03Z**.

REPORT-register-and-floor.md

@@ -0,0 +1,333 @@
+# REPORT — dated checks that bite, the floor raise on the record, the snapshot that covers less (2026-08-18)
+
+**Three pieces of bookkeeping, no machine put at risk. The hub was READ ONLY throughout.**
+
+**The headline is that Part 3's premise was wrong.** The floor raise was *not* a no-op: it moved a
+live customer box nine seconds after the save. That is the whole reason the task said to read it back
+rather than assume it. **R-343 is therefore filed OPEN, not CLOSED**, per the task's own condition.
+
+---
+
+## 1. Confirmed baselines
+
+| item | value |
+|---|---|
+| felhom.eu `main` @ start | `f267bc047f198de4cb600068fdd8bcef557cff20` — matches the sheet |
+| clean tree at start | yes; `HEAD == origin/main` in felhom.eu, felhom-controller, felhom-agent |
+| `scripts/` version IN | `felhom-host-install.sh v1.28.0` (CHANGELOG head) |
+| `scripts/` version OUT | `due_checks_gate.py v1.0.0` (new head entry) |
+
+## 2. Files created / modified
+
+**Created:** `scripts/due_checks_gate.py`, `scripts/test_due_checks_gate.py`,
+`REPORT-register-and-floor.md`.
+**Modified:** `scripts/repo_gates.py` (registration + docstring), `scripts/CHANGELOG.md`, `CLAUDE.md`,
+`CONTEXT.md`, `STATUS.md`, `documentation/backlog/OPEN-ITEMS.md` (block + R-342 + R-343),
+`documentation/runbooks/publish-train-rules.md`.
+Commit hashes are in §9.
+
+## 3. Tests — 37 assertions, and a red-proof that caught my own test
+
+`python3 scripts/test_due_checks_gate.py` → **passed: 37, failed: 0**, groups A–G.
+
+### Red-proof 1 — the boundary. **It failed usefully: it exposed a HOLLOW assertion of mine.**
+
+**Mutation:** `due_now = [... if r[1] <= today]` → `< today`.
+**First run, before the fix:** Group C reported
+
+```
+  PASS  C: due TODAY exits 1  rc=1          <-- passed, and should NOT have
+  FAIL  C: says DUE TODAY rather than overdue
+```
+
+**The `rc == 1` assertion passed for the wrong reason.** With `<`, a row dated exactly today falls
+into neither `due_now` (`<`) nor `pending` (`>`), so `min(pending, …)` raised
+`ValueError: min() iterable argument is empty` and the **traceback** exited 1. Confirmed directly:
+
+```
+  File ".../due_checks_gate.py", line 232, in main
+    nearest = min(pending, key=lambda r: r[1])
+ValueError: min() iterable argument is empty
+RC=1
+```
+
+**An exit code alone cannot distinguish a verdict from a crash.** Two fixes, both kept:
+
+1. the test now asserts `DUE-CHECKS GATE FAILED` is in the output **and** `Traceback` is not, plus a
+   new `test_c_gate_never_ends_in_a_traceback` across overdue/future/empty inputs;
+2. the gate returns **2 (INCONCLUSIVE)** with a message if the partition is ever broken again,
+   because a crash is never a verdict.
+
+**Re-run after the fix — the mutation now bites properly:**
+
+```
+  FAIL  C: due TODAY exits 1 (boundary is <=)  rc=2
+  FAIL  C: exits 1 as a VERDICT, not a traceback
+  PASS  C: did not crash
+  FAIL  C: says DUE TODAY rather than overdue
+passed: 34   failed: 3
+```
+
+**Mutation reverted**, verified by `grep -n "MUTATED"` returning nothing and the `<=` line restored.
+
+### Red-proof 2 — the missing-block path
+
+**Mutation:** the missing-block branch `sys.exit(2)` → `sys.exit(0)`.
+**Seen failing:**
+
+```
+  FAIL  E: missing block exits 2 (NOT 0)  rc=0
+passed: 36   failed: 1
+```
+
+**Reverted**, `sys.exit(2)` restored on that branch.
+
+## 4. The gate's real output in all three states
+
+**Overdue (fixture, today=2026-08-20):**
+
+```
+DUE-CHECKS GATE FAILED: 1 dated check(s) are due or overdue as of 2026-08-20 (UTC).
+
+  R-341    due 2026-08-19   1 day(s) OVERDUE
+           measure: ep0 proxy fd count + ESTAB/CLOSE-WAIT split; PID must still be 551655
+           the command and its preconditions are in the R-341 row of documentation/backlog/OPEN-ITEMS.md
+
+Take the measurement, record the result in that R-row, then remove the row from the
+DUE-CHECKS block. Moving the date instead is allowed — state the reason in the R-row.
+NOTE: this gate fires on a PUSH, not on the date; it may be later than the date.
+```
+
+**Pending / the LIVE run against the real register today (these are the same run):**
+
+```
+due-checks gate OK — 2 dated check(s) pending, none due yet.
+  today (UTC): 2026-08-18
+  nearest: R-341 due 2026-08-19 (in 1 day(s)) — ep0 proxy fd count + ESTAB/CLOSE-WAIT split; PID must still be 551655
+  (fires on the next PUSH after a date passes, not on the date itself — by design)
+```
+
+## 5. The runner's output
+
+```
+  site               OK            (exit 0)
+  hostinstall        OK            (exit 0)
+  hub-confirm        OK            (exit 0)
+  manifest-bearer    OK            (exit 0)
+  reuse-refs         OK            (exit 0)
+  instructions       OK            (exit 0)
+  golden-currency    OK            (exit 0)
+  wire-contract      OK            (exit 0)
+  hub-copy           OK            (exit 0)
+  due-checks         OK            (exit 0)
+all felhom.eu gates OK
+```
+
+Group G asserts registration by **running the runner** and matching `due-checks` in its output, never
+by grepping `repo_gates.py`'s source — a commented-out entry still contains the string.
+
+## 6. Part 3's five reads — evidence, not summary
+
+### READ 1 — the live floor, from the store
+
+```
+  artifact_agent_version     = '0.129.0'    (updated 2026-08-18 11:00:59)
+  artifact_golden_version    = '0.216.0'    (updated 2026-08-18 11:00:59)
+  artifact_min_agent         = '0.129.0'    (updated 2026-08-18 11:01:00)
+  min_controller_version     = '0.216.0'    (updated 2026-08-18 12:36:58)
+```
+
+**The raise landed**, so Part 3 proceeded. Read from `hub_settings`, not the form.
+
+### READ 2 — per-customer overrides
+
+```
+  demo-felhom      status=active     override=''         config_version=12
+  demo-hp          status=active     override=''         config_version=5
+  drill-r50        status=blocked    override=''         config_version=1
+  peti-felhom      status=active     override=''         config_version=6
+  tester-1         status=active     override=''         config_version=1
+  -> 0 customer(s) carry a non-empty override
+```
+
+**Zero overrides**, so the global applies to everyone and no box hides behind a lower one.
+
+### READ 3 — every box's controller version. **Two are below the floor.**
+
+```
+  demo-felhom      controller='0.216.0'    last_report=2026-08-18 13:07:07
+  demo-hp          controller='0.216.0'    last_report=2026-08-18 13:01:34
+  drill-r50        controller='0.213.0'    last_report=2026-08-12 15:33:25
+  peti-felhom      controller='0.115.0'    last_report=2026-07-15 08:39:00
+```
+
+**The two REPORTING boxes are both at 0.216.0, at the floor.** The other two are below it and neither
+is a reporting box: `drill-r50` is `status=blocked`, last heard from six days ago, powered off and
+reverted; `peti-felhom`'s host row was deleted on 2026-07-15. Reported here rather than as a
+footnote, per the task's edge-case rule.
+
+*(Note: `guests.controller_version` is empty for every guest — the hub carries the controller version
+on `reports.controller_version`, not on the guest row. The first query I wrote read the guest field
+and would have reported "unknown" for every box.)*
+
+### READ 4 — directives and holds
+
+```
+2026/08/18 14:36:58 [INFO] Global controller-version floor set to "0.216.0"
+```
+
+**No `managed floor HELD` line exists** — searched over 24 h of pod logs. (Hub log lines are CEST;
+the DB stores UTC, hence 14:36:58 here and 12:36:58 above — the same instant.)
+
+### READ 5 — **THE FINDING: a controller DID auto-update after the raise**
+
+```
+2026-08-18 12:37:07 | demo-felhom | controller_updated | Controller frissítve: 0.214.0 → 0.216.0
+2026-08-18 12:37:12 | demo-felhom | controller_started | Controller elindult (0.216.0)
+```
+
+and the version trail confirms it:
+
+```
+   2026-08-18 11:14:55  controller=0.214.0
+   2026-08-18 12:37:12  controller=0.216.0
+```
+
+**`demo-felhom` had been on 0.214.0 since 2026-08-12 16:44 and the floor raise pulled it to 0.216.0
+nine seconds after the save** — exactly the "acts immediately on the next report cycle" that
+`publish-train-rules.md` rule 2 documents and that the 2026-07-11 incident was filed for.
+`demo-hp` was already on 0.216.0 (hand-deployed 2026-08-14 08:31) and did not move.
+
+**No error, warning or critical event followed** — the update completed and the controller restarted.
+So: harmless in outcome, but **not a no-op**. "Every reporting box is at or above the floor" is true
+**because of** the raise, not independently of it.
+
+**R-343 is filed OPEN.** The task's closing condition was *all five reads clean and no directive
+served*; read 5 shows a live box moved. It went well, and a record that called it inert would mislead
+the next reader.
+
+## 7. `peti-felhom` — not contacted
+
+**The machine was not contacted in any way.** Sourced from the PETI register row, quoted:
+
+> *"a report from a deleted host 401s and is not persisted"*
+
+with its host row deleted `2026-07-15 08:56:22` (`host_deletions` id=1). It therefore cannot receive a
+floor directive and the raise cannot reach it. Its `reports` row still shows controller 0.115.0 from
+its last report on 2026-07-15 08:39:00 — a stale record, not a live box.
+
+## 8. The two `build-felhom-iso.sh` facts, confirmed in the script
+
+**(a) It is a BUILD-TIME gate.** `assert_golden_ge_floor()` is defined at **`:77`** and called at
+**`:267`**, in the build flow.
+
+**(b) It FAILS OPEN with a warning when its inputs are absent** — `:78-82`:
+
+```bash
+    local golden="${FELHOM_ASSERT_GOLDEN:-}" floor="${FELHOM_ASSERT_FLOOR:-}"
+    if [[ -z "$golden" || -z "$floor" ]]; then
+        log_warn "R-71 golden>=floor gate UNENFORCED — pass FELHOM_ASSERT_GOLDEN + FELHOM_ASSERT_FLOOR to enforce (golden='${golden:-unset}' floor='${floor:-unset}')"
+        return 0
+    fi
+```
+
+Both read as the task described. **No ISO rebuild is required:** the golden is fetched at first boot
+from the hub's manifest (0.216.0 — at the floor, not below it), and this gate governs *future* builds.
+
+
+## 9. Commits and CI
+
+| commit | contents |
+|---|---|
+| `0a5e9b14dc84ecfb179b2654d079c2f6d3f15fe2` | the gate, its tests, registration, both register rows, the block, and all §5 documentation |
+
+**CI run `355`, `head_sha 0a5e9b14d`, conclusion `success`** (started 2026-08-18T13:17:04Z). The
+previous run `354` on `f267bc047` was also green, so this run's green is attributable to this change
+rather than inherited from a red baseline — and per §13 of the task, a red run here would have been
+mine to own.
+
+**The push needed no `--no-verify`.** The pre-push hook ran `repo_gates.py --fast`, including the new
+`due-checks` gate, and passed — so the gate has now run in its real place, in both homes, not only in
+its own test suite.
+
+## 10. NOT yet validated
+
+**The gate has never fired on a real overdue date in the live register.** Every conviction shown here
+is from a temp-file fixture or a `FELHOM_GATE_TODAY` override. Its first genuine firing will be the
+next push on or after **2026-08-19**, when R-341's first check comes due. Until that happens, "it
+refuses the push" is proven in fixtures and *inferred* in production — the registration test proves it
+is wired into the runner, which is the part that could silently not be true.
+
+Also unvalidated: the block's own upkeep. Nothing checks that a row removed from the block was removed
+because the measurement was *taken* rather than because it was inconvenient.
+
+## 11. Teardown
+
+**This task provisioned nothing.** No VM, no container, no machine touched. The hub was read-only —
+snapshots of `hub.db` + `-wal` were taken into the session scratchpad for querying and are not
+committed.
+
+## 12. Register rows
+
+**The block, verbatim as committed:**
+
+```markdown
+<!-- DUE-CHECKS-BEGIN — machine-readable. Parsed by scripts/due_checks_gate.py.
+     One row per dated check. The R-number must have a row above. Dates are UTC.
+     Clearing a row means the check was DONE and its result recorded in that R-row —
+     or the date was deliberately moved, with the reason stated in the R-row.
+     This block is an INDEX, not the detail: the command and the preconditions live in
+     the R-row. Duplicating them here would create the second source this design avoids. -->
+| item | due (UTC) | what to measure |
+|---|---|---|
+| R-341 | 2026-08-19 | ep0 proxy fd count + ESTAB/CLOSE-WAIT split; PID must still be 551655 |
+| R-341 | 2026-08-25 | same, +7 d |
+<!-- DUE-CHECKS-END -->
+```
+
+**R-341's dates in the register matched the sheet exactly** — no disagreement to report.
+
+**R-343's verdict cell, verbatim:**
+
+> **OPEN — NEW 2026-08-18.** Deliberately NOT closed: the task's closing condition was *all five reads
+> clean, no directive served*, and read 5 shows a live box updated. It went cleanly and is the floor
+> working as designed — but a change recorded as a no-op when it moved a customer box is exactly the
+> kind of record that misleads later
+
+**R-342** filed **READY (S)**, owner *Viktor decides; CC executes*, quoting `stop2-snapshot.txt`
+verbatim on what the snapshot covers and does not.
+
+## 13. `unproven.py --summary`
+
+```
+where felhom stands — 55 claims, verified_on 2026-08-09
+  walked   23
+  partial  14   (6 cite evidence, 8 prose only)
+  built    14   (0 cite evidence, 14 prose only)
+  missing  4   (0 cite evidence, 4 prose only)
+  NOT WALKED: 32 of 55
+```
+
+**No number moved**, correctly: this task added a gate and three register facts, and walked no claim
+in the standing picture.
+
+## 14. Observations — noticed, deliberately not acted on
+
+- **`CLAUDE.md`'s gate list named only 6 of the 10 registered gates.** It was missing
+  `golden_currency_gate.py`, `wire_contract_gate.py` and `hub_copy_gate.py` — all registered weeks
+  ago. I completed the list rather than appending a 7th name to a list that was already wrong, since
+  the section's stated job is to name each gate. Effective line count 124 → 128 against a ceiling of
+  200, so no trim was needed.
+- **`documentation/architecture/00-capability-map.md` — no change, and this is the explicit
+  statement the task asked for.** No row's evidence citation names the floor or golden *version*:
+  line 153's publish-train row cites a runbook path, and line 44's golden literal is a dated
+  historical citation on the recovery-journey row.
+- **`drill-r50` will be dragged 0.213.0 → 0.216.0 by this floor if it is ever booted and reports.**
+  Its agent (0.129.0) meets `MinAgent`, so the floor would be served, not held. That is the floor
+  doing its job; noted so it is not read as a surprise later.
+- **The hub's log timestamps are CEST while its DB stores UTC.** Not a defect, but it makes a log
+  line and an events row for the same instant look two hours apart, which is worth knowing before
+  correlating them under pressure.
+- **`min_controller_version` and `artifact_*` live in the same `hub_settings` table but are saved by
+  different actions**, two hours apart today (11:00:59 vouch, 12:36:58 floor). That separation is
+  rule 2 working, and is why reading only one of them would give a misleading picture.

REPORT-rehearsal-2026-08-09.md

@@ -0,0 +1,183 @@
+# REPORT — BYO reinstall rehearsal, 2026-08-09 (session report)
+
+*Written as `REPORT-<topic>.md` rather than `REPORT.md` per the repo's parallel-session rule.*
+
+## The answer to the runbook's question, first
+
+**Yes, the data comes back byte for byte. No, not in one sitting, and not without a shell.**
+
+All four planted files returned **BYTE-IDENTICAL** — including two Hungarian accented filenames
+verified as *raw name bytes*, not as rendered text. The unlock took **21 s**, the restore **13.2 s**.
+
+But the walk completed only because two hard stops were cleared by someone who could open a terminal
+and read source. **R-273**: the install died at step 5/8 on an agent version that was published as a
+package but never git-tagged — cleared by completing the release. **R-280**: the reinstalled machine
+could not re-attach its own data drive through any dashboard route, while the restore page said
+„**Ez két kattintás**" and pointed at an empty list — cleared by POSTing an internal path
+(`/mnt/sys_drive`) that no household could produce.
+
+Neither is a data-integrity problem. Both stop a household dead. **This is the same shape the R-201
+walks kept finding: the data half passes, the journey half fails.**
+
+## Venue
+
+**demo-hp (t740)**, operator-approved at STOP 1. It won every fidelity criterion that distinguishes
+the two demo boxes: three customer apps against one, a registered storage path against none, and a
+Secure-Boot `shim` install — the customer shape — against demo-felhom's SB-off `mkimage` firmware
+workaround. `drill-r50` (VM 300) was verified not at risk before proceeding: it is outside the
+`felhom` pool, on `local-lvm`, and `--uninstall` removes no storage and no non-pool guest.
+
+## Findings, ranked by what they cost the person in front of you
+
+**1 — stops the visit**
+- **R-273** · the vouched agent (0.128.0) had no git tag; every install died at 5/8. **CLOSED** — tag
+  pushed on your instruction after an independent sha check; install then succeeded in 3 m 49 s. The
+  two guards that would prevent a recurrence are still owed.
+- **R-280** · a reinstalled machine cannot re-attach its data drive through any route, and the restore
+  page promises „két kattintás" at an empty list. **The one to fix before the tester's visit.**
+- **R-272** · Felhom's uninstall restarts its own dnsmasq unconstrained; it grabs `:53`; the next
+  install refuses and appears to blame the owner's network.
+
+**2 — costs the visit**
+- **R-274** · a local golden is adopted with no version and no checksum check. The copy on demo-hp is
+  controller **0.192.0** against a vouched **0.210.0** — and below 0.200.0, where the recovery screen
+  the customer needs actually shipped.
+- **R-276** · an uninstalled box keeps a live WireGuard tunnel into the off-site endpoint; declared
+  in neither the KEPT nor the WIPED list.
+
+**3 — misleads**
+- **R-281** · the hub said nothing at all through the whole reinstall, and the tripwire for a
+  sealed-backup unseal did not fire on a real one.
+- **R-282 / R-283** · one code, three names; the mail points at a page the box is not showing; the hub
+  reads "Claimed 18d ago" while the box serves its setup page.
+- **R-269** · a rotated-out local-API token still authorises until an unrelated lookup forces a
+  reload. The shipped test passes only because of its lookup order.
+- **R-270** · R-268's own rotation recipe is a step short; the controller never re-reads the mount.
+- **R-271** · the `agent_channel_unauthorized` alarm can never close — its own advice silences the
+  all-clear.
+- **R-277** · three hub surfaces present a healthy off-site tier as absent. **This one caught me.**
+- **R-278** · demo-felhom has had no off-site backup for six days, waiting on a ceremony nobody ran.
+
+**4 — cosmetic / hygiene**
+- **R-275** · five orphaned 0600 credential backups survive, and uid reuse hands them to the new
+  service account. Superseded keys here; live if the backups were recent.
+- **R-279** · no operator-triggerable off-site backup exists.
+
+## What I got wrong, and corrected
+
+I reported to the operator that the off-site tier had not run on **either** box since 2026-08-03.
+That was true of demo-felhom and **false of demo-hp**, which had 18 unbroken daily snapshots. I had
+read three hub surfaces that agreed with each other and none of which said what I took them to say
+(now **R-277**). I corrected it before it changed any decision, and the operator's "repair off-site
+first" ruling turned out to be unnecessary for the chosen venue.
+
+I also raised **R-275**'s sudoers half as a likely privilege-escalation on reinstall, then **tested it
+and refuted my own hypothesis**: sudo skips filenames containing dots, so the leftover file is inert.
+`visudo -c -f` parsing a file OK is not evidence that sudo loads it.
+
+## Integrity verdict — BYTE-IDENTICAL
+
+```
+expected 4 file(s); found 4
+VERDICT: BYTE-IDENTICAL
+```
+
+Four expected, four restored, zero differences, compared against
+`evidence-rehearsal-2026-08-09/GATE0-before-manifest.json` — a manifest keyed on **raw name bytes**.
+`árvíztűrő-tükörfúrógép.txt` and `nested/őszibarack.md` came back with their name bytes intact (NFC
+preserved, `c3a1…`), which is the discriminator the Gate 0 positive control was built to enforce: the
+comparator had been watched **failing** on an NFC→NFD rename that renders identically to the eye.
+Restored out of snapshot `41c830db` into the verification folder the product names, with live data
+untouched.
+
+## Wall clocks
+
+| phase | duration |
+|---|---|
+| Pre-phase (R-268 rotation, proved both ways) | ~25 min |
+| Gate 0 (venue, dataset, positive control, off-site run, capture) | ~55 min |
+| P1 uninstall | **60 s** (08:37:23 → 08:38:23 UTC) |
+| P1 leave-behind measurement | ~12 min |
+| P2 preflight (3 runs: 2 refusals, 1 pass) | ~6 min |
+| P3 install — first attempt, FAILED | 44 s (08:51:33 → 08:52:17 UTC) |
+| P3 install — resumed, SUCCESS | **3 m 49 s** |
+| P4 first contact (box live on its own URL) | within ~4 min of install |
+| STOP 3 unlock | **21 s** |
+| app redeploy (calibre-web) | **1 m 36 s** |
+| restore prepare + execute | **8 s + 13.2 s** |
+| **bare machine → verified files** | **1 h 49 m 22 s** (08:38:23 → 10:27:45 UTC) |
+| — of which the product's own work | **≈ 7 m 47 s** |
+
+**Neither figure is the customer number.** The 1 h 49 m is dominated by the R-273 diagnosis and release
+fix (~38 min) and two waits on a human. The 7 m 47 s is what the product costs when the operator
+already knows every answer. **The honest unaided figure is undefined, because an unaided household does
+not finish.**
+
+## Steps taken off-path, and what they cost
+
+1. **R-268 rotation on demo-felhom** — required by the runbook's pre-phase; not the venue.
+2. **demo-hp's dashboard password re-set to the credentials-file value**, on operator instruction.
+   The customer-owned password was unknown to this session and no operator route to the off-site
+   button exists (R-279). Prior hash preserved in-guest; destroyed with the guest at P1. Cost: none —
+   P1 wiped it and P4 re-claims.
+3. **The off-site run was started by a script pressing the dashboard's own endpoint** with a real
+   session and CSRF token, not by a person clicking. Identical server path; only the click synthetic.
+4. **`--passphrase-file` instead of the no-echo prompt** — a first-class documented option with a
+   permission check, so the secret still never touched argv. A person would type it.
+5. **`systemctl stop dnsmasq && systemctl disable dnsmasq`** — the action the refusal message tells
+   the owner to take, used as the counterfactual that confirmed R-272.
+6. **Pushed the `v0.128.0` git tag** — outward-facing, done on your "proceed", and only after an
+   independent download proved the published package's sha256 equalled the hub's vouched value. It
+   completes a half-finished release rather than changing code; the release script's own recovery text
+   is the same line. **Cost to the walk: the install that followed was a `--resume`, not a fresh run,
+   which is why R-274 is only half-observed.**
+7. **`POST /settings/storage/add` with `/mnt/sys_drive`** — the manual escape hatch, typed. This is the
+   R-280 wall; a customer could not produce that path. **The biggest fidelity cost of the run.**
+8. **SSH into the guest to fingerprint the restored tree.** This is my *instrument*, not a customer
+   step — the customer's step (the restore) finished at the dashboard. Byte-comparison inherently needs
+   file access; nothing about the product was driven this way.
+
+Everything else after the install returned was read-only, and no repair was attempted on the box.
+
+## Teardown — all four layers
+
+1. **The machine** — nothing created beyond the half-install itself, which is **left in place
+   deliberately** for inspection and resumption (`state.json` completed: preflight, token, grows,
+   enroll). demo-hp is **not serving** right now: no guest, agent installed but no unit.
+2. **The host** — `local-lvm` 20 904 790 → 12 355 143 KiB (**≈8.5 GiB returned**); `local` ≈64 MiB;
+   NVMe unchanged, backups deliberately kept. Pre-existing leftovers found and **not** removed
+   (not this run's, recorded instead): storage `c11-scratch`, the orphaned `vzdump-lxc-9100` archive,
+   and `/root/.dpw`, `.h`, `.sec.html` in the old guest (now destroyed with it).
+3. **The hub** — **no customer or appliance record was created**; the `demo-hp` customer is retained
+   deliberately, as the runbook requires. Nothing to delete.
+4. **The off-site side** — **one write, and it was the intended one**: the Gate 0 backup that created
+   snapshots `41c830db`, `9e38b84c`, `78b93f04`. **No prune, no forget, no delete.** How I know: every
+   restic call was `snapshots`, `ls`, or the product's own `POST /backup/offbox/run`; retention runs
+   inside that product path and is ep0's server-side job (R-89, boxes keep `keep_last: 0`).
+
+## Secrets handling
+
+No secret reached stdout. Token values, the retrieval passphrase, the controller password and the hub
+DB copy were handled file→file at 0600 and shredded; the hub DB copy (which carries every host's
+break-glass credential) was shredded immediately after the one hash comparison it was taken for.
+Credential comparisons were done by sha256 prefix, never by value.
+
+## State demo-hp was left in
+
+**Back in service and healthy** — agent 0.128.0, controller 0.210.0, guest 9201 running and onboot,
+claimed, storage path registered, `calibre-web` deployed, off-site repository unlocked and intact at
+18 snapshots. `drill-r50` (VM 300) untouched throughout.
+
+**Deliberately left alone, and named rather than tidied:** the pre-existing `c11-scratch` storage and
+the three `vzdump-lxc-9100` golden archives on `local` (the teardown keeps goldens by design, and they
+now number three). The restored files sit in the product's verification folder, not back in place —
+that is R-213 and the product says so.
+
+## Still owed
+
+- **R-280** — the drive wall. The one finding that would stop the tester's visit outright.
+- **R-273's two guards** — refuse a vouch whose tag does not resolve; check that a package and its tag
+  ship together. The tag push fixed one box, not the class.
+- **R-274's missing observation** — a *fresh* (non-resume) install taking a stale local golden.
+
+Full account: `documentation/audits/REHEARSAL-byo-reinstall-2026-08-09.md`.

REPORT-spike-ep0-connections.md

@@ -0,0 +1,176 @@
+# REPORT — SPIKE: who holds ep0's connections open (2026-08-20)
+
+**Status: STOP 1 reached. Parts 0, 1 and 2 are complete. Phase C (Part 3) has NOT been run — it is your
+decision, below.** Everything done in this session was **read-only**. No machine was changed.
+
+---
+
+## ⛔ The decision waiting on you
+
+Phase C wants one overnight window on `demo-hp`. **The measurement found something that changes which
+mutation is worth running**, so there are two versions of it. Both are one mutation on a Tier-0
+disposable box, both arm a dead-man timer first, both are unattended.
+
+| | **Option A — stop `pvestatd`** (what the spike prompt specifies) | **Option B — stop `felhom-agent`** (what the evidence now points at) |
+|---|---|---|
+| what it tests | the original Q3: does the leak track the request rate? | does the leak track **our agent's** cycle? |
+| predicted result | **null** — leak unchanged at ~201.6/day, ~84 descriptors in 10 h, split evenly ~42/~42 | leak **halves** — ~101/day, ~42 descriptors in 10 h, split ~42 from `demo-felhom` and **~0** from `demo-hp` |
+| what it buys | **falsification.** If the leak *did* halve, the whole Part-1/2 attribution is wrong and must be withdrawn | **confirmation by a second, independent route.** A near-zero contribution from the quietened box is decisive |
+| cost if the attribution is right | a confirmed null — real evidence, but no new information beyond what Parts 1–2 already show | the sharpest possible confirmation |
+| risk | none beyond the window: `pvestatd` is PVE's stats daemon; the box keeps running, backups are not due until ~08-25 | slightly higher: the agent is our own product on the box. It would stop reporting to the hub for the window, and the hub's staleness watch may notice |
+
+**I would run Option A, tonight.** Two reasons. It is the mutation the prompt authorises, and standing
+rule 2 says exactly one mutation exists in this run — substituting one is my call to propose, not to
+make. More importantly, **A is the falsification test and B is the confirmation test**, and the
+attribution is already confirmed twice over (socket ownership on the boxes, and the access-log user
+agent, by completely independent routes). A test that can prove me wrong is worth more right now than a
+third test that can only agree with me.
+
+**What I need from you: "A tonight", "B tonight", "at the weekend", or "skip it".** If you pick B I will
+need you to say so explicitly, because it is a second mutation the prompt does not authorise.
+
+---
+
+## What I did, and what it found
+
+### Part 0 — the dated-check gate's first real conviction, captured before anything else
+
+The 2026-08-19 row was one day overdue. Every conviction this gate had produced before came from a
+fixture or a `FELHOM_GATE_TODAY` override; **this is its first firing on a real overdue date in the live
+register**, and it behaved correctly:
+
+- **exit code 1** — a verdict, not a crash (2) and not a pass (0);
+- the message **names R-341 and the days overdue** (`R-341  due 2026-08-19  1 day(s) OVERDUE`), so the
+  exit code is not doing the work alone — which is the failure mode this gate's own red-proof fell into
+  on 18 August;
+- inside `repo_gates.py` it is the **only** conviction: 9 gates OK, `CONVICTED: due-checks`.
+
+Captured verbatim in `part0-due-checks-gate.txt` and `part0-repo-gates.txt`. The row was **not** cleared
+to make the push work — it was cleared at Part 4, after the measurement existed and its result was
+recorded in R-341, which is the sanctioned order.
+
+### Q0 — R-341's first dated check: the slope is UNCHANGED
+
+Precondition passed: PID still **551655**, `NRestarts=0`, so the elapsed window is valid.
+
+**fd 17 → 405 over 166,251 s (46.18 h) = 201.6 fd/day**, Poisson 2σ 181.2–222.1.
+The prediction was pre-registered before the reading: **370–450**. **Observed 388.**
+Verdict: **unchanged**, the expected result, and not a failed upgrade.
+
+This settles the check on a window **88× longer** and a descriptor count **97× larger** than the
+30-minute windows the original answer rested on. Uncertainty drops from roughly ±50% to ±5%.
+
+**Composition:** ESTAB 0 → 388, and **CLOSE-WAIT is 0 — absent from the histogram entirely.** The
+incident document's original emphasis on `CLOSE-WAIT` is not merely the minority story; on this proxy
+generation that state does not occur at all.
+
+Runway to the 65536 ceiling: **~323 days (~2027-07-09)**.
+
+### Q1 — who is at the far end: exactly the two demo boxes, 194 each
+
+No third peer. Outcome (c) excluded. The identity is read from the API token name on every access-log
+line, not inferred from the address. `lsof` confirms the leak is sockets and nothing else: 390 of 405
+descriptors are TCP.
+
+**Persistence (31-minute diff of full 4-tuples): 388 in both readings, 0 closed, 4 new.** Not one socket
+closed. All carry keepalive timers with `retrans=0` — the far ends are answering, so these are not
+half-open sockets.
+
+### Q2 — outcome **(a)**, confirmed twice, exactly
+
+| instant | ep0 | `demo-felhom` | `demo-hp` | sum |
+|---|---|---|---|---|
+| 08:02:39 / 08:04:37Z | **388** | 194 | 194 | **388** |
+| 08:33:42 / 08:34:01Z | **392** | 196 | 196 | **392** |
+
+And the four sockets that appeared between the readings carry **the same four source ports** on ep0 and
+on the boxes. Both sides hold every connection.
+
+### The finding nobody predicted: the leak is ours
+
+`ss -tnp` on the boxes names the owner of **194 of 194** on each: **`felhom-agent`**, one PID per box.
+Zero are held by `pvestatd`. Zero by `proxmox-backup-client`.
+
+ep0's access log says the same thing by a completely independent route:
+
+| who | requests in the window | descriptors leaked |
+|---|---|---|
+| `libwww-perl` (pvestatd) | 81,192 | **0** |
+| `proxmox-backup-client` | 80,061 | **0** |
+| `Go-http-client` (**our agent**) | 811 (of which **387** `/snapshots` calls) | **388** |
+
+**One leaked socket per agent `/snapshots` call, within one.** 99.5% of the traffic produces 0% of the
+leak.
+
+**Mechanism, named from source** — `felhom-agent/internal/pbs/client.go:56-60` builds
+`&http.Transport{TLSClientConfig: tlsCfg}` as a composite literal, so `IdleConnTimeout` is the zero value
+(= no limit; `http.DefaultTransport` sets 90 s and a literal does not inherit it), and
+`cmd/felhom-agent/main.go:1486` builds **a fresh client every cycle**, as its own doc comment states.
+`CloseIdleConnections`, `IdleConnTimeout` and `MaxIdleConns` appear **nowhere in the agent repo**.
+Cadences reconcile without fitting: 900 s hub poll (184.7 cycles) + 6 h verify cadence (7.7) = 192.4
+predicted against **194 observed per box**.
+
+**No fix is proposed** — the spike-first gate forbids it, and the spec is a separate task. Filed as
+**R-344**, with the open design questions listed rather than pre-answered.
+
+### Control window: clean
+
+No reboots (ep0 up 17 d, boxes up 10 d), no daemon restarts (`NRestarts=0`), no agent restarts, **no
+request-rate gap** (3,536–3,553 per hour, every hour), **no HTTP errors at all** (every response 200
+except 8 expected 101s), no tunnel flap. **No backup ran inside the window** — the last offsite protocol
+upgrades were 08-18 03:57/03:58Z, *before* `t0`, and the tier is weekly with the next run due ~08-25, so
+**tonight's window is also clear of one.** Routine verify jobs and restore-test reads did occur; they are
+1.2% of traffic and are already counted inside the 194/box reconciliation.
+
+**Hub:** no `*_unreachable` or `*_recovered` event; the PBS-DR gauge refreshes on schedule and host
+reports land from both boxes. **Honest limit:** the hub pod is 39 h old, so hub-side logs cover 36.6 of
+the window's 46.2 hours; the first 9.6 h rests on ep0's own evidence.
+
+---
+
+## Register changes
+
+- **R-341** — first check recorded (taken at **+46.2 h, not +24 h**; the delay was pure elapsed time and
+  the longer window is stated as a **better** measurement, not a degraded one). **2026-08-19 row removed**
+  from `DUE-CHECKS`; 2026-08-25 kept, with the Phase-C perturbation quantified against it (**~3%** shift
+  on the 7-day slope even under the hypothesis we expect to be false — the reading stays usable).
+- **R-336** — mechanism named; **premise corrected and re-ranked**. Its recorded next step would have
+  produced a null result and read as a failed fix. The poll rate is now a scaling/cost item; the leak fix
+  is R-344. **Q3's proportionality verdict is explicitly NOT recorded** — Phase C has not run.
+- **R-340** — noted which of its wanted observations this run already produced, so the health-op task
+  reuses them rather than measuring a protected machine a third time. Only the loopback probe is still
+  owed.
+- **R-344 (new)** — the agent's per-cycle transport leak. READY (S).
+- **R-345 (new)** — `hub/Makefile` lines 21–22 tag and push `:latest`, which two rule files forbid.
+  READY (XS).
+- **R-346 (new)** — `ActiveEnterTimestamp` reads 5 h 56 m early for this proxy generation (the upgrade
+  re-exec'd rather than restarted, so `NRestarts` is still 0). Anchoring a slope on it gives ~12% low.
+  READY (XS).
+
+## Deliverables
+
+- `documentation/audits/SPIKE-ep0-established-connections-2026-08-20.md` — the findings.
+- `documentation/audits/evidence-ep0-established-connections-2026-08-20/` — 11 raw evidence files,
+  including the **pre-registered Phase C prediction**, committed before the mutation exists.
+- `documentation/backlog/OPEN-ITEMS.md`, `STATUS.md` — as above.
+
+## CI, checked by run ID
+
+**id `360` / run_number `237`, `head_sha 19672e685`, conclusion `success`**, started 2026-08-20 08:41:50Z
+— this run's own push. The four runs before it (ids 356–359) are also `success`, so the "green since run
+356" baseline in the spike prompt holds and nothing was inherited red.
+
+*Numbering note:* the API exposes two numbers per run and they differ by 123 here. The prompt's "run 356"
+matches the **`id`**, not the `run_number`; both are recorded in `evidence-…/ci-run-by-id.txt` so the
+reference is unambiguous.
+
+The pre-push hook ran `repo_gates.py --fast` and reported **all 10 gates OK** before the push proceeded —
+including `due-checks`, which convicted at Part 0 and passes now that the row is properly cleared. **No
+`--no-verify` was used**, and none was needed.
+
+## What is inconclusive
+
+**Q3 is unmeasured**, by design. Everything stated about proportionality is a labelled prediction. Also
+unexplained: why the two boxes' leaked counts are *exactly* equal at two separate instants rather than
+merely close. And whether restore-test reader connections leak too was not separated out (≤2% of the
+total, inside the noise).

REPORT-walk5-r201-2026-08-07.md

@@ -0,0 +1,221 @@
+# REPORT — the fifth walk (R-201), 2026-08-07
+
+**Runbook-style validation, supervised. One machine destroyed on purpose, with the operator's
+confirmation at the §6 STOP. No product code written.** Venue: `demo-hp` VM **325 `walk5-appliance`**,
+customer `walk5`, host `walk5-4bada5`. Full evidence: `documentation/tests/walk5-r201-2026-08-07/`.
+
+---
+
+## 1. THE VERDICT — both halves, separately
+
+### THE DATA: **PASS**
+
+All three sentinels came back **byte-identical** out of snapshot `5b0f20f7`, under the key recovered
+from the sealed package with R:
+
+```
+11eb7fb2d1891f62a685e3d9a9fda44e0a342d437d4aebaa15fcb4c0fd79d539        61  WALK5-SENTINEL-A.txt
+6b504d1e83bf4c673334d0b9e701f3e5f07311d954fdc4463a6b0a55b261ae32        66  WALK5-őrszem-ékezetes-árvíztűrő.txt
+0baaf402733e6a85f3d9ce8c4c3a57b05692f5f6733da6a23da76d2cd7635210  12582912  WALK5-SENTINEL-C-12MB.bin
+name hex  57414c4b352d c591 72737a656d2d c3a9 6b657a657465732d c3a1 7276 c3ad 7a74 c5b1 72 c591 2e747874
+```
+
+Identical to Phase A in every byte **including the accented filename's name bytes**. Read back with
+`os.listdir` on a **bytes** path, so no decode/encode round trip could launder a `U+FFFD` into looking
+correct — the check that caught this three times before.
+
+### THE JOURNEY: **PASS — the first time in five walks**
+
+**No step needed a command line inside the guest.** Everything that *progressed* the journey was an
+HTTP request a browser makes. The previous walk needed **three** guest command lines; this needed
+**zero**. The reset-code hatch was used **once, in Phase A**, where §3 permits it.
+
+**Named per §3 so the claim is not read wider than it is** — the guest command lines used were the
+`w5watch.log` sampler, `docker logs`, the settings reads, the restic listing and the final sentinel
+verification. **All instrumentation:** none changed state, none was needed to progress, and removing
+them all would have changed nothing but my ability to describe what happened.
+
+---
+
+## 2. §5's OBSERVATION — the first live exercise of R-241's fix, and it stands on its own
+
+**At 14:58:52Z, unaided, before anyone had logged in:**
+
+```
+[WARN] [offbox] NOT minting a repository password: the hub holds a sealed recovery package for this
+       box, and a fresh key would orphan the history that package protects (R-241). The transport is
+       configured; the tier stays down until the customer's recovery code places the escrowed key.
+[INFO] [offbox] apply-offsite: transport configured …, tier HELD awaiting the escrowed key
+```
+
+| §5 asks | answer |
+|---|---|
+| does it declare a need, and when is it staged/collected? | **yes** — declared `needs_credential` 14:38:49Z and 14:53:49Z; hub staged **14:56:34Z**; collected + applied **14:58:52Z**. **Zero human actions**, on a box not yet claimed |
+| **is any repository key written?** | **NO** — sampled every ~20 s from 14:24:52Z; `repo_password` absent at every sample. The directory holds `applied_marker`, `known_hosts`, `ssh_key` and nothing else |
+| what state does it report instead? | `enabled=true`, `escrow_state=pending`, no key → the derived **`awaiting_recovery_key`** holding state |
+| the two fingerprints, before login | hub's package seals `eabf427c7274…144f`; **the box holds NONE** |
+
+**Positive control, because an absent line is not evidence:** the scheduler logged
+`agent-channel-health` ×5, `stack-scan` ×2, `system-health`, `backup-cache` and
+`offsite-credential-retry` in the same window. The absence of a mint is **explained**, not merely
+observed.
+
+> **HONEST SCOPE.** With the mint guard holding there is **no local key**, so the offer fires on
+> **shape (a)**, not shape (c). Shape (c) was measured in **Phase A, in its negative half** — hub hash
+> == local hash, correctly silent. **This walk proves the mint guard positively and the discriminator
+> negatively.** A positive shape-(c) firing needs a box holding a *different* key, which v0.206.0 now
+> prevents from arising by itself.
+
+---
+
+## 3. THE RTO
+
+**71.7 s**, login (15:04:25.417Z) → open store (15:05:37.156Z). Of that, **12.44 s was the unseal
+itself**; ~22 s was **my own harness retry** (I scraped the CSRF token from a `<meta>` tag the recovery
+page does not carry, got a 403, re-read it from the form). **A customer clicking the button sees
+≈50 s.** Both numbers are given because 71.7 s is what was measured.
+
+---
+
+## 4. DEAD ENDS, in the customer's terms
+
+**By §3's definition — something needing a shell inside the guest — there were ZERO.** Two obstacles
+were met, both cleared **from the dashboard**, and **neither is signposted**:
+
+| # | what the customer sees | what got past it | known? |
+|---|---|---|---|
+| 1 | „nincs elérhető adatmeghajtó a visszaállításhoz" | Tárhely → Meghajtók → „Meglévő meghajtó csatolása" re-registers both surviving disks | **NEW — R-252** |
+| 2 | „a(z) calibre-web nincs telepítve — előbb állítsd helyre az alkalmazást" — **on a page that says three lines above „Nincs telepítve — a visszaállítás előbb újratelepíti"** | redeploy from the catalogue (~90 s), then re-run the restore | **NEW — R-253** |
+
+**So: the machinery works end to end and the data is provably safe. The unaided journey now succeeds,
+and it succeeds through two obstacles a customer must guess their way past.**
+
+---
+
+## 5. WHAT EACH INSTALL LANDED ON — and delivery is part of the pass
+
+| | vouched | first install | after the rebuild |
+|---|---|---|---|
+| agent | 0.127.0 | **0.127.0** | **0.127.0** |
+| controller | golden 0.206.0 | **0.206.0** | **0.206.0** |
+
+**No hand upgrade either time, and no downgrade on the reinstall.** This is the first walk of the five
+where the box under test **is the box a customer receives** — R-239's delivery gap, the headline of both
+previous walks, is closed for this run.
+
+---
+
+## 6. THE RECOVERY SCREEN, QUOTED
+
+Appeared **without being sought**: `/` → 302 `/launcher` → 302 **`/recovery`**.
+
+> „Ezt a gépet újratelepítették. **A korábbi, házon kívüli mentéseid megvannak** — a Felhom központi
+> rendszere őriz hozzájuk egy lezárt csomagot, amelyet **2026-08-07T12:51:02Z** zártunk le. […]
+> **A helyreállítási kódot senki nem tudja pótolni** — sem a Felhom, sem az ügyfélszolgálat, sem az
+> üzemeltető. […] Ha megadod a kódot, **feloldjuk a mentéseid zárolását és megmutatjuk, mi van
+> bennük**. **Ebben a lépésben semmit nem állítunk vissza és semmi nem változik.**"
+
+The sealed-at timestamp **matches `host_escrow.created_at` exactly**. *(Copy wart, recorded not filed:
+it is a raw ISO-8601 string on a Hungarian customer screen where every other date reads `2026-08-07 14:57`.)*
+
+---
+
+## 7. THE LISTING, against Phase A
+
+| | Phase A | the screen |
+|---|---|---|
+| app | `calibre-web` | **`calibre-web`** ✅ |
+| when | `5b0f20f7` @ 12:57:41Z | **2026-08-07 14:57** ✅ (CEST) |
+| size | 12.784 MiB | **12.8 MB** ✅ |
+
+A second row `felhom-offbox · 12.8 MB` also appears — the tier's marker tag rendered as an app, and the
+total doubled. **R-251.**
+
+---
+
+## 8. §4.6's TWO PRE-DESTRUCTION CHECKS — both pass, neither previously exercised on a clean box
+
+- **The recovery offer is NOT shown**: `/` → `/launcher`, **zero** recovery mentions on either landing
+  page, `/recovery` 302s. And the reason is measured, not assumed — box key, box's ACK-cached hub hash
+  and hub `restic_pw_sha256` are all `eabf427c7274…144f`, so **shape (c) compares equal and stays
+  silent**.
+- **The restore page lists the app with the future-backup toggle OFF** — identical rendering both ways.
+  **R-237's fix, live**; the last walk measured 0 entries and a 302 here.
+
+---
+
+## 9. PHASE A's SEVEN RECORDS
+
+Controller `0.206.0` · agent `0.127.0` · PBS wrapper **matches vouched** · guests 1/1 · DR recipe
+**present** · key escrow **present** · snapshot `5b0f20f7` · 1 snapshot · **12.0 MB** (12 611 563 B) ·
+`host_escrow` blob **383 B**, `identity_blob` **572 B**, `stale_at` **NULL**, 0 superseded rows ·
+escrowed key fingerprint `a6:86:f7:fb:…:4c:f9` · box key == hub hash == `eabf427c7274…144f`.
+
+**Sentinels listed BY NAME** out of the snapshot with `restic ls latest --long` — see §1.
+
+> **The §4.5 gate earned its place again, and this time it caught MY fault.** The first off-site run
+> reported **`ok` in 28 s with 0 snapshots**: I had sent the per-app toggle as `enabled=1`, and the
+> handler accepts only `on`/`true`, so it recorded *off* and the run correctly backed up nothing.
+> Re-toggled, selection verified in the rendered page, re-run → 1 snapshot, 12.0 MB. **A green tick is
+> not evidence a file is in a snapshot.**
+
+---
+
+## 10. R — SHREDDED, with a working control
+
+One `0600` file on **DooPlex only**, never rendered, never an argument, never a log line. Shape only:
+**82 characters, 10 hyphen-separated tokens**.
+
+```
+plant  → ~/.config/walk5/R_PLANTED_CONTROL.txt
+sweep  → 2 hits (the real file + the planted control)   ← the control PROVES the sweep works
+shred  → both, then the pattern file itself
+sweep  → 0 hits
+```
+
+**Every sweep path was asserted to exist first** — a sweep pointed at a missing path returns zero for
+the wrong reason. The appliance's copy was `shred -u`'d mid-walk and its absence verified.
+
+---
+
+## 11. NEW FINDINGS — the highest register ID moved **R-248 → R-253**
+
+| ID | |
+|---|---|
+| **R-249** | **The retrieval passphrase ships in the customer page's HTML** (`data-secret`), so any headless read puts it in a transcript — with no reveal action and **no audit event**, where the break-glass credential emits one. Found by doing it. **MEDIUM** |
+| **R-250** | **A customer create can fail fail-closed** because the host-key scan ladder (~60 s) is shorter than the fresh sub-account's DNS/**AAAA-before-A** settle (~100 s measured). Retry is safe and idempotent; nothing says so. **LOW-MEDIUM** |
+| **R-251** | The recovery listing renders **one row per restic tag**, showing the customer an "app" they never installed and their data counted twice. **Cosmetic** |
+| **R-252** | After a rebuild the restore refuses — **the drives lost their registration** — and nothing on the recovery path says to re-attach them |
+| **R-253** | The restore refuses because the app is not installed, **on a page that says the restore reinstalls it**. Two shipped sentences that contradict each other, in the customer's language, at the last step of a recovery |
+
+**Recorded against an existing row rather than minted:** **R-243** claims `offsite_delivery_stuck`
+"skips the applied shape". **On a rebuild it does not skip** — 88 s after the destruction the hub
+emitted the warning and wrote an **operator-channel** `notification_log` row naming a guest rebuild as
+the cause, correctly. The gap is real for the state R-243 describes and **not** for the state a rebuild
+produces; the row is annotated so it is not read wider than it measures.
+
+---
+
+## 12. TEARDOWN — OWED, not done
+
+The machine is the evidence until the verdict is written. Full enumeration, the "before" measurements,
+the stop-and-age gate, and the positive controls that must survive:
+`documentation/tests/walk5-r201-2026-08-07/teardown-owed.md`. **R-244's residue will grow by this
+venue.**
+
+---
+
+## 13. WHAT DID NOT RUN, AND WHY
+
+- **A positive shape-(c) firing.** Structurally unreachable on a healthy v0.206.0 rebuild — see §2.
+- **A soak / scheduled cycle.** The previous walk covered it; §7 does not ask for one and adding it
+  would have delayed the destruction past the operator's window.
+- **Any product code.** §0 forbids it: five findings were filed and the walk continued.
+- **Teardown.** §10 defers it deliberately.
+- **`felhom-offbox`'s second listing row and the raw ISO date** were observed, not chased.
+
+## Documents updated
+
+`00-capability-map.md` (the unaided-recovery row → **PROVEN-LIVE, scoped**), `OPEN-ITEMS.md`
+(**R-201 CLOSED**; R-249…R-253 filed; R-243 annotated), `STATUS.md` (headline changed; trimmed 97 → 92
+lines rather than extended), and the journal + teardown ledger.

REPORT-wire-contract-gate.md

@@ -0,0 +1,199 @@
+# REPORT — G-1: a gate for the dropped field, then the fields it found (2026-08-08)
+
+*A non-overwritten `REPORT-<topic>.md` sibling, per `CLAUDE.md:82-87` — a parallel session shares this
+clone and the shared `REPORT.md` was not touched.*
+
+## 1. The gate's output on today's tree — failing, before anything was fixed
+
+**This is the session.** Captured verbatim in
+`documentation/tests/wire-contract-gate-2026-08-08/BEFORE.md`:
+
+```
+wire-contract gate — 210 tag(s) checked across 3 declared wire(s); 51 skipped
+WIRE-CONTRACT GATE FAILED: 40 emitted field(s) cannot be received.
+```
+
+It named every one, with its emit path and its direction, and re-found **`escrow_stale`** (R-247) and
+every field R-260 listed. Had it been green, the gate would not work and *that* would have been the
+finding — which is not hypothetical: the night before, `deadcode` was rejected for the neighbouring
+C6 class for exactly that reason.
+
+**⚠ A count this session's prompt got wrong.** The prompt said *"465 emitted tags, eight
+unreachable"*. R-260's wording was "at least eight **decision-bearing** facts", never eight tags in
+total. Measured: **40** on the three declared wires. Checked against the repo, not quoted — the
+prompt's own rule 6, and the second prompt claim caught that way this week.
+
+## 2. The forty, by disposition
+
+| # | field(s) | direction | decision | what changed |
+|---|---|---|---|---|
+| 1 | `oob.operator_key_configured` | agent → hub | **receive and act** | decoded (pointer); `oobDegraded` fails on a missing key and the alert names it |
+| 2 | `oob.wg_handshake_age_s`, `oob.healed_at` | agent → hub | **receive, message only** | in `HostOOBRow` + the event payload; deliberately NOT in the predicate |
+| 3 | `escrow_stale` | hub → controller | **receive and act** | `report.EscrowStatus.Stale`; withheld-hash told apart from hash-less. **R-247** |
+| 4 | 12 host/system metric fields | both → hub | **no consumer wanted — redundant** | allowlisted: the hub bands on the `*_percent` figures from the same stanzas |
+| 5 | `guests.spec.{disk_bytes,memory_bytes}` | agent → hub | **redundant** | sizing is hub-owned intent, not mirrored reality |
+| 6 | `storage_targets.smart.model_name` | agent → hub | **redundant** | a display label; `smart.health` + every banded counter ARE decoded |
+| 7 | `wireguard.last_handshake_age_s` | agent → hub | **redundant** | wgsync reconciles from its own state |
+| 8 | 21 fields (`guest_net`+7, `selfupdate_pending`+1, `healed_recently`, `applied_at`, `mount_parity`/`_inventory`, `config_hash`, `reporting_disabled`, `stacks`, `migrated_to`, `last_db_dump`, `last_integrity_check`) | both → hub | **no consumer today, one arguably owed** | allowlisted **against R-264, OPEN**. Allowlisting is not deciding, and the entries say so |
+
+Full per-field reasons are in the gate's own `ALLOWLIST`, each a claim someone can re-check.
+
+## 3. Scenario F — the choice, and why
+
+**Unknown is reported distinctly and is never `ok`.** `operator_key_configured` decodes as a
+**pointer**: nil = the agent never said, which is not a value.
+
+The version gate the prompt thought "probably right" was **rejected on a measurement**: the field and
+the `oob` stanza that carries it shipped in the **same** agent version (v0.72.0, 2026-07-05), so a
+stanza without the field cannot come from any released agent. The live fleet is 0.113.0 and 0.127.0;
+the vouched floor is 0.127.0. Building version-gating machinery the hub does not otherwise have, for a
+state no box can be in, is cost without cover. The case is still handled explicitly and pinned by a
+test, because "cannot happen" is a claim this project has been burned by.
+
+## 4. R-247 — CLOSED
+
+The field is received, and `reconcileEscrowed` tells a **withheld** hash from a **hash-less** one.
+Controller v0.209.0.
+
+**Deliberately not folded in, and said rather than skipped:** the wrong flag on `demo-hp` is an
+operator act hub-side (**R-246**, still open), and the customer-facing Hungarian card copy is
+unchanged — that is UI work with its own review path.
+
+## 5. The gate's blind spots, and its self-test
+
+Published in the module docstring **and** in the gate's own output, because Campaign 12's C1 guard
+turned out blind to one of the three shapes it was written for:
+
+- **generic tag names are not checked** (`name`, `state`, `status`, …) — a repo-wide string test says
+  nothing about them, so a drop of a generically-named field is **missed**; the gate under-reports
+  rather than over-reports;
+- **reachability of a NAME is not use of a VALUE**;
+- **only declared ROOTS are covered** — the hub's desired-state (raw stored JSON, no typed emitter)
+  and the agent's local API (no single root) are **not**;
+- it reads source, not traffic; test files and `testdata/` are excluded on the receiving side
+  deliberately (a tag present only in a fixture is not decodable — which is R-262 exactly).
+
+`--selftest` plants an unreachable tag on a real root in a throwaway copy and asserts conviction:
+**exit 1, planted tag named**; unplanted tree **exit 0**.
+
+**THREE instrument defects this gate's own controls caught before it was trusted.** None was found
+by review; each was found by making the gate prove something.
+
+1. **A substring false negative** — `grep -F healed_at` also matched `privsep_healed_at`. R-260 named
+   `healed_at`, so its absence from the output was the tell. Whole-token now; 40, not 39.
+2. **`dr_recipe` is not wholly opaque** — its top-level section keys ARE decoded, through allow-lists
+   that already swallowed `offsite_restic` for months (R-122). Now opaque only **below depth 1**.
+3. **The search shelled out to `grep` and read its failure as a finding.** CI convicted **all 174**
+   checked tags while the pre-push hook was green. The CI runner's image carries python3 and git and
+   deliberately little else, and its `grep` does not support `--include`, so stdout was empty and
+   empty was read as "absent". **A gate that silently turns a tool failure into a finding is worse
+   than no gate**, and its green would have been as untrustworthy as its red. Removed the dependency
+   rather than working around it: the search is pure Python now, one token index per receiving repo.
+
+**The BEFORE capture was RE-VERIFIED, not re-generated** — the stronger claim. All 40 recorded fields
+were re-tested against the new implementation: **agree=40, disagree=0**, i.e. exactly the four this
+session fixed are now present and the other 36 still absent. The number stands under both
+implementations.
+
+**And the reusable half, which is about the gates and not about this gate.** The pre-push hook runs on
+a workstation where every sibling repo is a real clone; CI checks out one repo, shallow. **A gate
+that needs a sibling passes locally and is INCONCLUSIVE in CI — the two automated homes are not
+interchangeable, and a new gate must be checked in BOTH.** The workflow's own alarm mail says a
+hook-versus-CI disagreement "outranks whatever the push was for"; it did. Fixed by fetching the agent
+clone in CI (`.gitea/workflows/gates.yml`), never by letting the gate skip when a sibling is absent —
+that is the fail-open shape and would leave it running in neither home (R-29).
+
+**Cost, stated plainly:** three CI runs went red (260, 261, 262) and each sent the operator an alarm
+mail before run **263** went green. The alarm working is the system behaving correctly; the noise was
+mine.
+
+**A FOURTH red run, 264, was NOT one of mine and is filed as R-265.** It sat between two greens on a
+**documentation-only** commit, ran **834 s** against 18–34 s for every other run in the session, and
+**persisted no log at all** (`jobs/264/logs` → HTTP 500, *file does not exist*). The runner pod never
+restarted, so the job hung and was reaped rather than the runner dying. Not a gate finding — the diff
+was Markdown, the gate code was byte-identical to the two greens around it, and the same content is
+green at run 265. **The cause of the hang is undetermined and is not guessed at**; DooPlex was busy in
+that window with this session's own live-validation work, but the box has 40 cores at load ~5, so
+that is a hypothesis, not a cause. **The reusable finding is second-order:** the alarm mail tells the
+operator "the failing gate names itself in the run log", and here there is no run log — so a reap is
+indistinguishable from a conviction, and whether the alarm fired at all for a reaped job is
+**unverified**. R-265 carries it.
+
+## 6. What `oobDegraded` says when it fails
+
+```
+Host <id>: OPERATOR ACCESS DEGRADED — the operator's authorized_key is NOT installed —
+felhom-sshd is up and answering, and nobody can log in through it. The break-glass net
+(auto-heal + vaulted root@pam console) is still under the box.
+```
+
+and for the unreachable-but-handled unknown:
+
+```
+… — the agent reports operator access but is too old to say whether the operator key is
+installed (pre-v0.72.0) — treat entry as UNPROVEN, not working. …
+```
+
+`oobDegradedReason` is now the single source for both the predicate and the text, so the message can
+never name a different fault from the one that fired. The old form derived it separately and had a
+vocabulary of two.
+
+## 7. Tests and red-proofs
+
+New: `hub/internal/store/host_oob_decode_test.go` (4 tests, raw JSON at the decode boundary),
+`hub/internal/monitor/host_oob_operatorkey_test.go` (6), plus two end-to-end tests in
+`host_oob_test.go` driving JSON → store → checker → event.
+
+**Red-proofs — 8 expected outcomes, 0 wrong, each with the mutation asserted applied:**
+
+| mutation | assertion it applied | outcome |
+|---|---|---|
+| the gate on today's tree | — | **RED, naming all 40** ✔ |
+| planted unreachable tag (post-fix) | self-test reports the planted tag by name | **RED on the plant, GREEN unplanted** ✔ |
+| drop `operator_key_configured` from the decoder | json-tag occurrences in the decoder 2 → 1 | **RED — the false `ok` returns** ✔ |
+| make the check unconditional | `MUTATED unconditional degrade` marker present | **RED — a healthy box alerts** ✔ |
+| treat unknown as `ok` | `MUTATED: unknown is silently ok again` marker present | **RED — the silent pass returns** ✔ |
+| all three restored | — | **GREEN** ✔ |
+
+**The pre-existing fixture was part of the defect and was fixed too:** `oobReport()` omitted
+`operator_key_configured`, so every earlier scenario ran against a report shape **no released agent
+produces**. Same family as R-262.
+
+## 8. The capability-map row about operator access
+
+**Checked, and it was NOT claiming something untrue.** `00-capability-map.md:127` claims OOB operator
+access is *implemented*, never that it is *monitored*, so no correction was owed. What was untrue sat
+one layer down — the hub's own health check could not see the key — and the row now records that,
+with the fix and the tests that pin it.
+
+## 9. Gates, and what remains
+
+`python3 scripts/repo_gates.py --fast` → **all 8 OK**, including the new `wire-contract` and
+`golden-currency`. `go build ./... && go vet ./... && go test ./...` green in **hub** and
+**controller** (run separately from every commit). **No `--no-verify` anywhere.**
+
+**The one gate failure that remains is not a failure of this work:** golden **0.208.0** is baked and
+byte-verified but **still not vouched**, so fresh installs receive 0.207.0. That is R-242's untouched
+half and one operator Save.
+
+## 10. Register
+
+**R-260 CLOSED** (class gated + sharpest instance fixed), **R-247 CLOSED**, **G-1 CLOSED** in
+`ROADMAP.md`. **R-264 minted and OPEN** — the twenty-one facts with no consumer, split out so that
+gating the class could not be mistaken for deciding them. **Highest ID moved R-263 → R-264.**
+
+Explicitly still open: R-246, R-255, R-256, R-257, R-258, R-259, R-261, R-262, R-263, and **C7's
+test-comment half**, which Campaign 12 recorded as *owed, not done*.
+
+## 11. Observations — noticed, NOT acted on
+
+1. **`stacks` is the whole per-stack report object and the hub decodes none of it.** The largest
+   single unconsumed structure on the controller wire; folded into R-264 rather than sized here.
+2. **The hub has no version-gating machinery for report fields at all.** Not needed today (see §3),
+   but the next additive field whose emitter and stanza do *not* ship together will need it, and
+   there is no convention to reach for.
+3. **`backup.last_db_dump` / `last_integrity_check` are backup-integrity timestamps the hub cannot
+   see** — the "presence is not success" neighbourhood, and worth ranking first inside R-264 after
+   guest_net.
+4. **The gate cannot cover the hub's desired-state wire** because it is served as raw stored JSON.
+   That is the one remaining hub→box direction with no contract check of any kind.

REPORT.md

@@ -1,173 +1,150 @@
-# REPORT — RUNBOOK: the first host-tier restore-test, on both boxes
+# REPORT — R-331: the operator Backup card said every customer had no backups
 
-**Date:** 2026-08-03 → 2026-08-04 · **Repos:** `felhom.eu` docs + registers only. **Nothing was built
-and no version was bumped.** The only binary that moved is the already-published `v0.123.0`, onto the
-box that did not have it (P1). Baselines re-read and matched: `felhom-agent` `72161f6cf010` /
-`v0.123.0`; `felhom.eu` `e3187c86d58d` / hub `v0.91.1`, installer `1.24.0`. Constants re-confirmed at
-source: `defaultRestoreTestEvalInterval` **6 h**, `defaultRestoreTestSettle` **24 h**.
-
-**Outcome: four scheduled runs, all passed, nothing triggered by hand.**
+**Hub v0.109.0 (with controller v0.225.0) · 2026-08-30**
 
 ---
 
-## 1. Preconditions
+## 1. What was wrong
 
-| # | demo-felhom | demo-hp |
-|---|---|---|
-| **P1** agent | `v0.123.0` ✓ | **`0.120.0` — below the 0.121.0 floor, so it could not become due at all.** Remediated with the published `v0.123.0` (sha `74910135…`, deployed sha identical) |
-| **P2** tiers | host `felhom-backup` + offsite `felhom-pbs` (weekly) | **the same — the runbook expected demo-hp to have no offsite tier, and it has one**, active with 2 snapshots |
-| **P3** grant | `ok=70 total=70 degraded=0` | `ok=70 total=70 degraded=0` (once the probe existed) |
-| **P4** storage | `/dev/sdb → /mnt/hdd_1`, ext4, on the N100 | `/mnt/nvme-1tb` on the t740 — **different hosts, different disks ⇒ INDEPENDENT ⇒ parallel is safe** |
-| **P5** space | target 889 GB free; restore pool `local-lvm` 358 GB | target 925 GB free; restore pool `data` **53.9 G at 30.79 %** (~37 GB free) against a 2.35 GB archive — adequate, and measured *because* that pool is the over-subscribed one |
-| **P6** candidate | `…2026_08_02-04_42_14.tar.zst` (08-02) | `…2026_08_02-04_49_29.tar.zst` (08-02) — both correctly the settled archive, not the day's |
-| **P7** other heavy work | daily backup ~04:44, outside the window | daily backup ~04:49, outside the window |
-
-## 2. The due verdicts before the run, quoted
+The hub customer page's **Backup** card read, for **every customer, indefinitely**:
 
 ```
-demo-felhom  tier=felhom-backup due=true  archive="…2026_08_02-04_42_14.tar.zst"
-               reason: newest settled archive … has not been proven; nothing proven on this tier yet
-             tier=felhom-pbs    due=true  archive="…2026-07-28T04:49:43Z"
-               reason: … has not been proven (last proven archive was a different one)
-
-demo-hp      tier=felhom-backup due=true  archive="…2026_08_02-04_49_29.tar.zst"
-             tier=felhom-pbs    due=true  archive="…2026-07-28T19:19:45Z"
+Enabled  Yes        Snapshots  0
+Repo Size  0 MB     Integrity  Unknown
 ```
 
-**Both boxes had BOTH tiers due**, which made §4's ordering question live rather than theoretical.
+Measured on `demo-hp` 2026-08-30, at which moment the truth was:
 
-## 3. The runs — all four SCHEDULED, none triggered
+| source | value |
+|---|---|
+| the box's own `settings.json` | `snapshot_count: 67, repo_size_bytes: 140829678, stats_known: true` |
+| that night's controller log | `[offbox] backup OK: 8 app(s) backed up, 67 snapshot(s), 2m14s` |
+| **this hub's own Offsite page** | `0.1 GB` used of a `50 GB` quota — read from the same stored report |
 
-| box | tier | due at | archive | result |
-|---|---|---|---|---|
-| demo-felhom | **host** | 00:55:21 | `…2026_08_02-04_42_14.tar.zst` | **passed, 83.8 s**, scratch torn down 00:56:45 |
-| demo-felhom | offsite | 06:55:21 | `…2026-07-28T04:49:43Z` | **passed, 540.4 s**, torn down 07:04:21 |
-| demo-hp | **host** | 02:05:39 | `…2026_08_02-04_49_29.tar.zst` | **passed, 109.3 s**, torn down 02:07:28 |
-| demo-hp | offsite | 08:05:39 | `…2026-07-28T19:19:45Z` | **passed, 300.1 s**, torn down 08:10:39 |
+**A card that reads "no backups" over a working backup is worse than no card.** It is the R-88
+direction of failure — degrading to *no backup* rather than to *unknown* — on the one screen an
+operator consults to answer "is this customer protected?".
 
-**No box failed to fire, so Phase C was not entered and no `--selftest` was used as a proof.** The
-only selftest invocations in this session were the read-only `restore-test-due` verdict prints in §2,
-which start nothing.
+## 2. Root cause
 
-**§4's question, answered live:** each box took its **host** tier first — never-proven sorts ahead of
-proven, and ahead on the id tie-break — deferred the offsite one, and picked it up on the **following
-evaluation six hours later**. One heavy operation at a time, per box, with nobody sequencing it. That
-is R-86's oldest-proven ordering and the heavy-operation gate observed together for the first time.
+The card rendered the report's **`backup`** object. Its `snapshot_count`, `repo_size_mb` and
+`integrity_ok` fields have had **no producer** since disk-tier restic moved to the host agent (slice
+8C) — the controller's `buildBackupReport` leaves them zero *deliberately* and says so in a comment.
+The zeros were correct values for dead fields, rendered as if live.
 
-**The asymmetry worth keeping:** a host-tier restore is **83–109 s**; an offsite one **300–540 s**. The
-tier an ordinary recovery uses is also the cheapest to prove.
+**The data was never missing.** The live numbers ride in the report's **`offsite`** object, which this
+package **already** reads for the Offsite page (`offsiteUsageBytes`) and which `monitor.OffsiteChecker`
+**already** drives fill and staleness alarms from. That the Offsite page rendered demo-hp's real usage
+from the same stored report, at the same moment the Backup card said `0 MB`, is the proof the bytes
+were arriving. This is a **render fix over an existing feed**, not a new pipeline.
 
-## 4. What the runs left behind
+## 3. Why it was not a one-line template swap
 
-**Persisted state — v3, naming the archive, the tier and what was verified:**
+`snapshot_count: 0` means two opposite things — *this repository holds nothing* and *nobody has ever
+measured this repository*. **R-225 measured that confusion one layer down**: a rebuilt box rendered
+„Tarolo meret · 0 pillanatkep" over a store that really held snapshot `f3d9cd67`, and the controller's
+`StatsKnown` fixed it there. It was never on the wire, so rendering the count without it would have
+**moved R-225 up to the hub instead of fixing anything**. Controller v0.225.0 now forwards
+`stats_known`.
 
-```json
-demo-felhom  felhom-backup → {archive …2026_08_02-04_42_14.tar.zst, tier local, verified boot+running,
-                              proven_at 2026-08-03T22:56:45Z}
-             felhom-pbs    → {archive …2026-07-28T04:49:43Z,        tier pbs,   proven_at 2026-08-04T05:04:21Z}
-demo-hp      felhom-backup → {archive …2026_08_02-04_49_29.tar.zst, tier local, proven_at 2026-08-04T00:07:28Z}
-             felhom-pbs    → {archive …2026-07-28T19:19:45Z,        tier pbs,   proven_at 2026-08-04T06:10:39Z}
-```
+## 4. What changed
 
-**The hub received the host-tier proofs — R-189's path carrying one for the first time.** demo-felhom's
-latest report holds **two** entries, one per tier; the `local` one can only have come from the
-persisted state, because the in-memory store held only that morning's offsite run:
+`hub/internal/web/backup_card.go` builds a typed `backupCardView` — resolved in Go, because the card's
+whole subject is a distinction a template `{{if}}` chain over `map[string]interface{}` float64s cannot
+keep:
 
-```
-demo-felhom  tier=local pass=True archive=felhom-backup:…2026_08_02-04_42_14.tar.zst tested_at=2026-08-03T22:56:45Z
-             tier=pbs   pass=True archive=felhom-pbs:…2026-07-28T04:49:43Z          tested_at=2026-08-04T05:04:21Z
-demo-hp      tier=local pass=True archive=felhom-backup:…2026_08_02-04_49_29.tar.zst tested_at=2026-08-04T00:07:28Z
-```
+| report state | card shows |
+|---|---|
+| no `offsite` object at all | "No off-site data reported" — **and says explicitly this is not the same as "no backups"** |
+| `enabled:false` + declared `state` | the blocker by name (`needs_credential`) — a different operator action from "not enabled" |
+| enabled, `stats_known:false` | **—**, plus "never been measured". Never `0` |
+| enabled, `stats_known:true` | the real count and size, **including a real `0`** — measured empty is knowledge |
 
-**A subsequent evaluation runs nothing on a proven tier**, quoted from demo-felhom now:
+**A pre-v0.225.0 controller sends no `stats_known`, which unmarshals to false → "unknown".** That is
+the fail-safe direction: upgrading the hub ahead of the fleet must not tell the operator that every
+un-upgraded customer has zero backups. Pinned by a test.
 
-```
-tier=felhom-pbs  due=false  proven="…2026-07-28T04:49:43Z"
-  reason: newest settled archive (landed 2026-07-28T04:49:43Z) is already proven
-```
+**The Integrity row is deleted, not re-sourced.** Nothing produces it: the controller runs no integrity
+check, and `NotifyIntegrityOK` / `NotifyIntegrityFailed` exist and are **called from nowhere**. A row
+that can only ever read "Unknown" is not information, and one that could read "OK" from an unwritten
+field would be a lie.
 
-…while its **host** tier reads `due=true` again — on the **08-03** archive, which has now settled 24 h.
-That is not a defect: it is "proved daily, on its own archive", visible one day later.
+`fmtBytesAuto` is new rather than reusing `fmtBytesGB`: that one is fixed at GB because it renders
+against GB quotas, and it turns demo-hp's real 140 829 678 bytes into `0.1 GB` — which on a card whose
+entire defect was under-reporting a real backup reads as "nearly nothing".
 
-## 5. Teardown — three layers, per box
+## 5. Tests and the red-proof
 
-| layer | demo-felhom | demo-hp |
-|---|---|---|
-| the machine | `pct list` → **0** entries for 990000 | **0** |
-| the host | `lvs` → **0** volumes for 990000; `local-lvm` **1.95 % → 1.95 %** | **0**; `local-lvm` 30.79 % → 40.86 % during the offsite run → **30.83 %** after |
-| the hub | the `restore_tests[]` entries are **RETAINED DELIBERATELY** — they *are* the proof the staleness check reads, so deleting them would delete the result | same |
+`r331_backup_card_test.go` asserts the **rendered page**, using demo-hp's real reported values, so a
+regression fails against the same numbers the defect was measured against. **The defect lived in the
+template's choice of source object, so a test one layer below it would have been green against the
+shipped bug** — which is why these drive `handleCustomerUnified` and grep the HTML.
 
-Nothing else was created: no scratch customer, no fixture storage, no probe tag, no package version.
+**RED-PROOF (run 2026-08-30):** restoring the pre-fix card markup fails all four tests —
+`the rendered Backup card does not contain demo-hp's real snapshot count (67)`,
+`the card does not carry the real repository size (134.3 MB ...)`,
+`the card still shows an Integrity row`, plus every branch of the three-way ruling. Restored
+immediately; `git diff` clean.
 
-## 6. What the run surfaced — three findings, two of them corrections to my own record
+**Green gate:** `go build ./... && go vet ./... && go test ./...` in `hub/` — 18 packages, rc 0.
 
-### R-190 (new) — a storage ACL that worked in the morning was gone by mid-morning
+## 6. Deployment
 
-A `vzdump` by `felhom-agent@pve!agent` with `--storage felhom-backup` completed **OK at 04:44:50** on
-2026-08-03; the first `403 … missing privilege Datastore.Allocate` on that path is **09:24:56**, and by
-~14:50 `pveum acl list` held **no row at all** for it. Ruled out by measurement: a host reinstall
-(uptime 12 days), any `pveum`/ACL/`user.cfg` activity in syslog 04:00–10:00, any cluster-log ACL entry.
-Correlated but not established: guest 9201 was reprovisioned at 09:15–09:19, nine minutes before.
-**A permission that can vanish silently makes every ACL-based guarantee on these hosts provisional**,
-and v0.123.0's probe detects the *state* but says nothing about the *transition*.
+PENDING at the time of writing — see the follow-up commit. The two halves ship independently and in
+either order: the hub renders "unknown" for any box still on controller 0.224.0, which is correct
+rather than wrong.
 
-### R-191 (new) — every weekly offsite backup reports FAILED although it worked
+## 7. The push bypassed a gate, deliberately, and here is the declaration
 
-demo-felhom, 06:49–06:53 today: the upload **succeeded** (223 s, 629 MiB of 1.874 GiB, 67.2 % reused
-incrementally) and the job then failed on the prune —
-`missing Datastore.Modify|Datastore.Prune on /datastore/felhom-offsite/demo-felhom` → `TASK ERROR: job
-errors`, and the hub raised `whole_guest_backup_failed`. **The token behaves exactly as R-89 designed**
-(box tokens are write-only; ep0 prunes). What did not follow is the config: **both** boxes still arm
-the offsite tier with `keep_last=2 prune_pbs_allowed=true`, so every weekly run asks for a prune that
-must fail. The data is safe; the verdict and the weekly e-mail are wrong, which is the R-100 corollary
-— an alarm whose text is true and whose trigger is not the thing you would act on. **Not fixed here**
-(§6 rule 2), and the fix needs one check first: whether ep0's prune jobs actually cover these two
-namespaces.
+**`git push --no-verify` was used for this change.** `repo_gates.py`'s `golden-currency` gate was
+CONVICTED and it was RIGHT: controller **v0.224.0** and **v0.225.0** are released and the newest golden
+bake carries **0.223.0**, so a machine installed right now receives neither fix.
 
-### Two corrections to yesterday's record
+**This is a BYPASS, not a waiver.** The gate offers a waiver only for a release that *deliberately needs
+no golden*; these need one. **The operator was asked and ruled bypass-now-bake-later**, on the stated
+ground that neither fix bites a day-0 box — R-330 is a nightly false alarm about apps a new box has not
+installed yet, R-331 is a hub-side display over backups a new box has not taken yet — and both arrive by
+self-update afterwards. That ground is recorded on R-242 precisely because it is the thing to re-check:
+**it does not extend to a release that changes first-boot behaviour.**
 
-1. **The R-185 drift was NOT silent on the write path.** demo-felhom's local-api backup jobs 403'd
-   **six times** (09:24 → 17:34) on that storage and privilege, and the hub raised
-   `whole_guest_backup_failed` at the first with edge-triggering suppressing the rest. My annotation
-   said backups kept landing because writes go through a root path — wrong, and now corrected in the
-   runbook and on the row.
-2. **My "no `restore_test_*` events at all" was an instrument error.** The hub has no `/events` route;
-   I grepped a **404 page**. Read from the events table: five such events exist (2026-07-27/28), none
-   since the R-86 work — and one **more** since, below.
+**A golden carrying 0.225.0 is OWED** (`RUNBOOK-manual-build.md` §4.1; the vouch is a three-field change,
+`MinAgent 0.129.0`). This is the **fourth** bypass of this gate, and the gap it names is now two releases
+wide rather than one.
 
-**One further event, correctly raised and worth stating:** `restore_test_stale` for demo-felhom at
-2026-08-03 22:33:42 UTC — **22 minutes before** the host-tier run. It was **true**: at that moment the
-host tier had never been proven, and the hub said so on its own, without being asked. It has not
-re-fired; the signal is edge-triggered, so the return to healthy is silent by design.
+**The other failing gate was fixed, not bypassed.** `due-checks` was red on R-341's `+7 d` measurement,
+five days overdue. It was **taken** during this session — see §8.
 
-## 7. The capability map
+## 8. R-341's overdue check was taken, and its premise did not survive
 
-The unattended restore-proof row now reads **PROVEN-LIVE for the host tier, unattended, on both demo
-boxes**, with the four runs, their durations, the deferred-tier ordering, the hub-side proof and the
-teardown cited — and it states its **scope explicitly**: `demo-felhom` and `demo-hp`. The tester's box
-is untested and untouched, and one box proving something does not make it a fleet property.
+Unrelated to R-331; it blocked the same push, so it was done rather than deferred. Evidence:
+`documentation/audits/evidence-r341-plus7d-2026-08-30/step1-fd-and-sockets.txt`.
 
-## 8. Registers
+**Precondition passed**, which is what makes the reading interpretable: `proxmox-backup-proxy` still
+`MainPID 551655`, `ps -o lstart=` still `2026-08-18 09:51:04`, `NRestarts=0` — the same proxy generation
+as t0, so nothing restarted and re-based the count. (The anchor is `ps`, not `ActiveEnterTimestamp`,
+which reads 03:54:54Z here — R-346's trap, avoided.)
 
-- **R-185** — its consequence is now demonstrated; the row already closed yesterday, and carries the
-  correction in §6.
-- **R-190**, **R-191** — filed. `grep` established R-190 and R-191 were free before minting (R-189 was
-  the highest in use).
-- `ROADMAP.md` holds none of these rows, so nothing to collapse.
-- `STATUS.md` rewritten for the operator and kept to one screen (85 lines); R-191 appears under
-  "What's broken" because it produces a weekly e-mail you would otherwise learn to ignore.
+**Result: fd = 17.** Not 17 more — seventeen total, exactly the documented baseline, against **405** at
+the first check on 2026-08-20. The socket histogram holds **one LISTEN and nothing else**: ESTAB 0,
+CLOSE-WAIT 0.
 
-## 9. Observations — noticed, NOT acted on
+**The verdict is "unanswerable", not "the upgrade fixed it".** R-341 asks whether the PBS 4.2.5-1
+upgrade changed the fd slope. Inside this interval **we removed the leak ourselves** (R-344, agent
+0.130.0, now live on both boxes). A slope of ~0 measures our fix, not the upgrade — and reading it the
+other way would credit a changelog that was read in advance and found to contain no such mechanism. The
+perturbation pre-registered for this window was Phase C at ~3%; the actual perturbation was the removal
+of the entire phenomenon. The question is now **moot**, and the row is closed as such.
 
-- **demo-hp's `local-lvm` thin pool reached 40.86 %** during its offsite restore (from 30.79 %,
-  returning to 30.83 %). Comfortable, but that is the over-subscribed pool the target-selection notes
-  warn about, and the offsite archive is the larger of the two. A materially bigger guest would want
-  the restore pointed at `/mnt/nvme-1tb` instead.
-- **demo-hp has an offsite tier**, contrary to the runbook's §2 premise and to the note that it "has
-  none". Nothing depends on that assumption now, but the operations notes still carry it.
-- **The two boxes' daily archives are ~6.3 GB (demo-felhom) vs ~2.35 GB (demo-hp)** for the same guest
-  role — a 2.7× difference worth understanding before either is used to size anything.
-- **Both waiters this session produced no output** despite the runs completing; the evidence was
-  gathered by direct query afterwards. A watcher that silently produces nothing is exactly the
-  instrument class this project distrusts — the conclusions here rest on the boxes' own journals and
-  the hub's database, not on the waiters.
+**What it does establish, which is worth more than the original question:** twelve days after the R-344
+fix, on the same proxy generation with no restart to hide behind, ep0 sits at baseline with zero
+established connections. The 388-descriptor accumulation has not returned, and R-336's ~323-day runway
+concern retires with it.
+
+## 9. Not done, and why
+
+- **No staleness verdict on the card.** `monitor.OffsiteChecker` already owns that and alarms on it. A
+  second verdict over the same data is two things that can disagree — a shape this codebase has already
+  paid for (`LastRun` vs `LastSuccess`, R-100).
+- **The dead `backup` fields were not removed from the controller's wire format.** Removing them would
+  stop historical reports already in this hub's store from parsing, for no gain — nothing renders them
+  now, and a controller-side test fails if anything starts producing them.

REUSE.md

@@ -59,12 +59,13 @@
 | Symbol | File | Short signature | Use for | Gotchas |
 |---|---|---|---|---|
 | funcMap in `web.New` | hub/internal/web/server.go (~L67) | `template.FuncMap{...}` | ALL template helpers (`timeAgo`, `statusColor`, `json`, `hubVersion`…) | Add new template funcs HERE, nowhere else. Tested by hub/internal/web/funcmap_test.go + render_test.go. |
-| `inline_confirm_js` partial (v0.52.0) | hub/internal/web/templates/inline_confirm.html | `{{template "inline_confirm_js"}}` in the page `<head>` | Inline "question + Igen/Mégse" confirm for consequential buttons — `data-confirm="…"` on the button, or `felhomConfirm(el, q, onYes)` from JS | NEVER native `confirm()`/`prompt()` — OS-modals freeze browser automation (F-16). `scripts/hub_confirm_gate.py` asserts zero, but is **not wired to run** (R-29) — so the rule holds only as long as you keep it. Uses `requestSubmit` so `formaction` sub-buttons riding a parent form work. NOT for the danger-zone typed-confirm cascade. |
+| `inline_confirm_js` partial (v0.52.0) | hub/internal/web/templates/inline_confirm.html | `{{template "inline_confirm_js"}}` in the page `<head>` | Inline "question + Igen/Mégse" confirm for consequential buttons — `data-confirm="…"` on the button, or `felhomConfirm(el, q, onYes)` from JS | NEVER native `confirm()`/`prompt()` — OS-modals freeze browser automation (F-16). `scripts/hub_confirm_gate.py` asserts zero and IS wired — it is gate 3 of `scripts/repo_gates.py`, which the pre-push hook and CI both run (R-29 closed the wiring; corrected here 2026-08-06). Uses `requestSubmit` so `formaction` sub-buttons riding a parent form work. NOT for the danger-zone typed-confirm cascade. |
 | `timeAgo` | hub/internal/web/server.go (~L603) | `(t time.Time) string` | Human-relative timestamps in UI | — |
 | `statusColor` | hub/internal/web/server.go (~L630) | `(status string) string` | Status → design-system-v2 token (nominal/warn/crit/neutral) | Class SUFFIX only, never inline color (D4). Exception-color principle: healthy = blue/neutral. |
 | `(*Server).hostStatus` + `hostStatusClass`/`hostStatusLabel` | hub/internal/web/hosts.go (~L16/34/48) | `(lastReport *time.Time) string` | Host liveness badge | Uses the SAME threshold as HostStalenessChecker (down = 2× stale) — never invent a second definition. |
 | `parseSQLiteTime` | hub/internal/store/store.go (~L1160) | `(s string) time.Time` | Parsing ANY timestamp read from SQLite | modernc/sqlite returns multiple formats; raw `time.Parse` will intermittently zero out. Always use this. |
 | `compareVersions` | hub/internal/web/server.go (~L571) | `(a, b string) int` | X.Y.Z comparisons in web (floor checks, update-available) | Returns 0 on parse error — unparseable compares as "equal" (see §3). |
+| `reportBackupCard` + `backupCardView` + `fmtBytesAuto` (R-331, v0.109.0) | hub/internal/web/backup_card.go | `(reportJSON string) backupCardView` / `(int64) string` | THE customer-page Backup card — everything it shows about a customer's backups | **Reads the report's `offsite` object, NEVER `backup`.** The `backup` object's `snapshot_count`/`repo_size_mb`/`integrity_ok` have had no producer since slice 8C and rendering them told every operator every customer had `Snapshots 0` (measured on demo-hp over a repo holding 67). **Always consult `StatsKnown` before believing a zero** — absent/false means "never measured", NOT "empty", and those are opposite news (R-225 measured the same confusion one layer down). Resolved in Go, not the template, because a `{{if}}` chain over `Report`'s `map[string]interface{}` float64s cannot keep the absent/zero distinction the card is entirely about. `fmtBytesAuto` scales MB/GB/TB — do NOT swap in `fmtBytesGB`, which renders demo-hp's real 140 829 678 B as `0.1 GB`. |
 
 ### Host views & lifecycle / offsite endpoints (v0.47.0, hub/internal/web + store)
 
@@ -75,8 +76,11 @@
 | `(*Store).GetHostRecoveryMeta` + `(*Server).handleHostRevealRecoveryCredential` | hub/internal/store/host_recovery.go · hub/internal/web/hosts.go | `(hostID) (*HostRecoveryMeta, error)` · `POST /hosts/{id}/reveal-recovery-credential` | The break-glass console credential, split into a RENDER half and a RETRIEVE half (v0.84.0) | **Use `GetHostRecoveryMeta` on any page-render path** — its struct and its `SELECT` both omit the `secret` column, so it cannot leak one; `GetHostRecoveryCredential` (which does select it) belongs only to the two retrieval handlers. The reveal is POST so the ServeHTTP-level CSRF check applies and no secret is reachable by URL; it writes ONE `recovery_credential_revealed` event via `SaveEvent` and calls NO dispatcher (the `handleRequestLogTail` shape). `api/handler.go handleAdminGetRecoveryCredential` (global key) is the independent fallback for when the UI is down — never route the UI through it. Secret at rest is plaintext → R-133. |
 | `host_detail_body` sub-template | hub/internal/web/templates/host_detail_body.html | `{{template "host_detail_body" .}}` | Rendering a host's detail sections on ANY surface | One namespace across ParseFS (icons.html pattern). Renders per-host — id-suffix any new element ids with `{{.HostID}}` (the customer page renders N instances). |
 | `(*Store).ListHostsByCustomer` | hub/internal/store/store.go (~L1620) | `(customerID) ([]Host, error)` | A customer's hosts, host_id order | A LIST by design (HA-cluster roadmap) — don't collapse to GetHostByCustomer. |
+| `(*Store).HasEverBoundHost` (v0.92.0, R-195) | hub/internal/store/store.go | `(customerID) (bool, error)` | Any verdict that must not fire for a customer with **no machine ever bound** — "was anything ever expected of this customer" | `hosts` row **OR** `host_deletions` tombstone. **NOT a liveness check and never a substitute for one:** a box that was bound and went silent returns `true` and must keep alarming — that is the case any change here breaks first (pinned by `TestCheckBackupDeadlines_BoundButNeverReported_StillAlarms`). Callers **fail OPEN** on its error: an unreadable binding must never SUPPRESS an alarm. Do **not** re-derive this from report presence — `store.GetCustomers()` (and therefore the staleness checker's `down` state) is a query over `reports`, so a never-reported customer has no state at all, which is exactly how the daily false alarm reached `david`. |
 | `(*Server).configFormData` (v0.49.0) | hub/internal/web/configs.go (~L430) | `(r, isNew, cfg, overrides, errMsg) configFormView` | The ONE view-model builder for the customer config form (standalone chrome + the customer page Edit tab) | `overrides=nil` → parses the STORED cfg.ConfigJSON; pass the SUBMITTED map on the update validation-error re-render or typed values reset (red-proofed). |
 | `config_form_body` sub-template (v0.49.0) | hub/internal/web/templates/config_form_body.html | `{{template "config_form_body" <configFormView>}}` | Rendering the config form on ANY surface (config_form.html chrome + customer Edit tab) | The floor/geo/danger cards on the Edit tab are SIBLINGS after `</form>` — never nest a form inside it (breaks the offsite/PBS formaction sub-buttons). Includes the F5 in-flight `<script>`. |
+| `handleHostEscrowGet` + `escrowSelfServiceRetrieval` | hub/internal/api/handler.go | `GET /hosts/{id}/escrow` | The box-authenticated MIRROR of the escrow PUT — self-scoped by the per-host key. **`escrowSelfServiceRetrieval` is THE single decision point** for whether a box may read its own blob without operator-armed recovery mode (§8.2 vs §8.3, R-199): flip it, do not scatter the condition. **Never merge this with `dr.go`'s `handleReEnroll`/`handleGetRestoreDirective`** — those rotate the host API key and serve the K-escrow and directive too, and keep their recovery-mode gate (pinned by `TestEscrowGet_OperatorDRPathUnchanged`). Every successful retrieval MUST raise `escrow_blob_served` before the bytes leave; that audit row is the mitigation the trade rests on. |
+| `demoteCurrentEscrowTx` (+ `(*Store).SaveHostEscrow`) | hub/internal/store/store.go (~L2597/~L2612) | `(tx, hostID) (int64, error)` / `(hostID, blob, fp, posture, createdAt, resticPwSHA) (superseded bool, prevResticPwSHA string, err error)` | **THE ONE escrow row-copy routine** — used by the re-escrow retention AND by `DeleteHost`'s custody demotion; never write a second one | **It must copy BOTH sealed artifacts** — `blob` (K-escrow / PBS key) and `identity_blob` (the age bundle carrying the offsite restic repo password). Omitting the second is R-198: two months of retaining the wrong key, with the ceremony as the destroying act. **Ordering it depends on:** `SaveHostDRBundle` writes `identity_blob` AFTER `SaveHostEscrow` returns, so the demote sees the PREVIOUS generation — invert that and the retained bytes are the new blob under the old hash. Pinned by `TestSaveHostEscrow_RetainsIdentityBlob` + `TestDeleteHost_DemotesIdentityBlob` (both callers). `prevResticPwSHA` feeds R-197's changed-key signal; it is a hash and never leaves the store. |
 | `(*Store).CountHostArtifacts` / `DeleteHost` | hub/internal/store/store.go (~L1640/~L1690) | `(hostID) (HostArtifacts, error)` / `(hostID, deleteEscrow bool) error` | Host-delete impact preview + the ONE-transaction cascade | ONLINE gate lives in the handler, escrow gate in the store (`ErrHostEscrowPresent`, tx never starts). log_bundles die by `scope_id == host_id` ONLY (customer-scoped bundles survive). The wg_peers delete is INSIDE the tx — never split it out. |
 | `(*Server).commitCustomerReset` (v0.69.0) | hub/internal/web/customer_reset.go (~L165) | `(ctx, cfg, resetID int64, purgeEscrow bool) *resetLegError` | THE committed RESET sequence — external teardown FIRST (Hetzner, PBS), then claim → descriptor → DB purge, each leg stamped into the `customer_resets` journal | Owns NO gate, NO audit event, NO journal open/close, NO redirect — those are the caller's (the two callers differ there). `purgeEscrow` governs ONLY whether `PurgeCustomerResetDBState` destroys retained custody: standalone RESET passes the operator's `escrow_ack`; the DELETE cascade passes **false** so custody dies exactly once, in its leg 3. Returns a `resetLegError` carrying the leg name + the exact status/message the standalone handler has always returned — do not re-word them. |
 | `(*Store).CustomerResidue` / `PurgeCustomerResidue` (v0.70.0) | hub/internal/store/customer_delete.go | `(customerID) (*CustomerResidue, error)` / `(customerID) error` | Counting + purging the report-derived state and the credential-bearing bindings a deleted customer leaves behind | **`GetCustomers()` is REPORT-derived** — until the reports are gone the customer stays on the Customers list AND stays in the staleness/offsite checkers’ work list, so a deleted customer keeps emailing the operator. Both funcs walk ONE shared `residueQueries` list so a table can never be counted-but-not-purged. Includes `appliance_registrations` + `selfbind_tokens` (credential-bearing, not telemetry). NEVER touches `events`, `notification_log`, `host_deletions`, `customer_resets`. |
@@ -148,6 +152,10 @@
 | Seam-injected sender for tests | hub/internal/notify/dispatcher.go `sendEmailFn` (~L33) | Function-field defaulting to the real impl in the constructor; tests overwrite it. Same idea: `mailRateLimiter.now`, `mailrelay.Sender` fake. |
 | Immediate-sync notify (per plane) | agent plane: `poke.Notifier` (`web.Server.poke` / `api.Handler.poker` via `SetPoke`/`SetPoker`) — controller plane: `intent.Hub.Bump` (`web.Server.bumpIntent`, `api.Handler.intentHub`) | EVERY desired-state mutation fires the RIGHT plane's notifier AFTER the successful store write, never on an error path (fire-after-commit). Agent-plane pokes a HOST when its generation moved (`SetHostDesired`/`Bump*HostDesired`); controller-plane bumps a CUSTOMER on a controller-visible change. Both receivers COALESCE bursts — add NO hub-side dedup. Deliberate non-sites need a documented reason (undeliverable pre-tunnel, transport removed, or no generation bump → the 60 s ticker is the pickup path). Both seams nil-safe: unset = the ≤15-min cycle still reconciles. Full site inventory: REPORT.md audit table (v0.63.0). |
 | Website page | website/index.html | UTF-8 **with BOM**; shared `<nav>`/`<footer>` byte-identical across pages (only `class="active"` differs); two-tone H1 = `<h1>…<span>accent</span></h1>`; all styling in website/assets/site.css tokens (`:root`) — zero embedded `<style>`; `?v=N` cache-bust on site.css/icons.svg; umami snippet; no CDN fonts; no emoji (sprite icons.svg instead). |
+| Gate RUNNER (the entry point) | scripts/repo_gates.py | THE one entry point — runs all six gates, streams each gate's own output, non-zero if any fails. `--fast` = no network, no container runtime. A missing gate script is a FAILURE, never a skip. `.githooks/pre-push` runs it with `--fast`; CI re-runs it on every push and mails on failure (R-168). Register a new gate as a row in `GATES`; do NOT model new work on `site_gates.py`, which is a gate, not a runner (R-161). |
+| Instruction-file gate (shared) | scripts/instructions_gate.py | Registered in all four repos' runners and **never copied** into a sibling — a copy recreates the drift it detects. Checks CLAUDE.md effective length / version literals / expired TEMPORARY, `.claude/rules/*.md` scoping, workspace-copy identity, and (check 6) the auto-memory index. Effective text = HTML comments stripped, because they are stripped before injection. **Three outcomes are deliberately different**: over-limit FAILS, an orphan WARNS, an absent store PASSES *printing its reason* — and the test asserts on that reason text, since a pass with no reason is indistinguishable from a gate that stopped running. |
+| Workspace installer | scripts/install_workspace.py | Lays down the workspace-root `CLAUDE.md` (canonical source: `documentation/runbooks/workspace-CLAUDE.md`) and the `InstructionsLoaded` hook from `workspace/hooks/`. **Unlike `install_skills.py` the targets are LIVE CONFIG, not disposable**: timestamped backup before every write, `settings.json` MERGED (owns exactly one key, `hooks.InstructionsLoaded`), a diverged CLAUDE.md reported not silently resolved, an unparseable settings.json REFUSED. Idempotent — a second run writes nothing. |
+| Rule-firing report | scripts/rules_report.py | Reads the `InstructionsLoaded` hook log and cross-references every `.claude/rules/*.md` in the workspace. **The column that matters is the empty one** — a rule that has never fired is mis-globbed or dead (built-but-never-wired, applied to instructions). Prints each silent rule's `paths:` so "wrong glob" is distinguishable from "quiet month". Caveat: the log only covers since the hook was armed. |
 | Gate script | scripts/site_gates.py | Byte-level mechanical gates (BOM, emoji codepoint ranges, nav/footer diff, analytics, banned tokens, cache-bust); run `python scripts/site_gates.py` after ANY website change; non-zero exit on failure. |
 | Fetch-validate-install (shell) | scripts/felhom-host-install.sh `step_agent_install` (~L1108) | `fetch_raw` to mktemp → syntax-check (`bash -n`) → `install -m0755 -o root -g root` → only then activate; guarded-mkfs wrapper installed BEFORE the sudoers that references it (ordering is the safety property). All mutations through `run()` (dry-run aware). |
 | Install-profile gate (shell) | scripts/felhom-host-install.sh `--mode appliance\|byo` (GL-2, v1.10.0) | Mandatory-flag profile (no default), refusals at argv time BEFORE any prompt/step, risky step gated at its CALL SITE (one auditable place — never a branch inside the step), mode persisted to state.json + resume-mismatch refusal, `FELHOM_INSTALL_STATE_DIR` override for harness isolation. Harness: scripts/hostinstall-mode-harness.sh (static refusal matrix + grep-invariants + PVE dry-transcript tier; red-proofs run against a mutated scratch copy). |
@@ -167,6 +175,7 @@
 | Inline `stringData` secrets à la manifests/felhom.secret.yaml | Commits real credentials to git (healthchecks superuser pw, umami APP_SECRET/POSTGRES_PASSWORD, gitea-creds admin password still live there). | Out-of-band `kubectl create secret` + `secretKeyRef` (hub.yaml resend-api pattern; runbook documentation/runbooks/secrets.md) |
 | `kubectl apply` / `kubectl set image` on manifests/ | ArgoCD app `felhom` reverts drift on next sync; live state lies about git. | Edit manifest in git → push → ArgoCD sync (CLAUDE.md steps 3–5) |
 | `:latest` image tag in manifests | Re-push doesn't change the manifest → no redeploy; Synced/Rollback misreport. | Pinned version tag, bumped per deploy |
+| The report's `backup` object for snapshots / repo size / integrity (`snapshot_count`, `repo_size_mb`, `integrity_ok`) | **No producer since slice 8C** — the controller's `buildBackupReport` leaves all four zero deliberately and says so. Rendering them gave every customer `Snapshots 0 · Repo Size 0 MB · Integrity Unknown` indefinitely (R-331, measured on demo-hp over a repository holding 67 snapshots). `integrity_ok` is worse than stale: the controller runs no integrity check at all, so it can only ever be "Unknown" or a lie. | The report's `offsite` object (`backup.OffboxReportStatus`) via `reportBackupCard` — and check `stats_known` before trusting a zero |
 | grep/regex hunting emoji in website HTML | Windows grep false-negatives multibyte emoji (proven in D0). | `python scripts/site_gates.py` (codepoint-range check) |
 | Adding a website page without touching site_gates.py | `PAGES` list (scripts/site_gates.py ~L22) is explicit — an unlisted page is silently ungated (BOM/nav/emoji drift undetected). | Add the filename to `PAGES` in the same commit |
 
@@ -201,6 +210,7 @@
 - **New template func**: funcMap in web.New only; add a case to hub/internal/web/funcmap_test.go.
 - **New daily job**: `scheduleDaily` in hub/cmd/hub/main.go + add pruning to `pruneAll` if data grows.
 - **New site gate**: append to scripts/site_gates.py; new website pages go into its `PAGES` list.
+- **New gate of any kind**: add a row to `GATES` in scripts/repo_gates.py — a gate reachable only by being named in a CLAUDE.md is the R-29 finding. **A new `.claude/rules/*.md` needs a `paths:` list, and is NOT live in the session that created it** — verify from a fresh session (`claude -p`) and confirm with scripts/rules_report.py, never from the frontmatter.
 - **New artifact kind (Day-0)**: consts `pkg*`/`file*` (hub/internal/web/server.go ~L27), `ArtifactManifest` fields + settings keys (hub/internal/store/store.go ~L905), `handleSetArtifacts`, `artifactManifestResponse` (handler.go), and the install script's verify step.
 - **New host-install step**: `step_*` function in scripts/felhom-host-install.sh using `run()`/`fetch_raw`/`die` helpers; keep dry-run coverage.
 - **New DR-recipe section**: `hostHalfShape`/`appHalfShape` **and** `AssembledRecipe` (hub/internal/store/dr_recipe.go) — those shape structs are **ALLOW-LISTS, not forward-compat**: a section only the emitter knows about is stored intact and **silently dropped** before the operator downloads it. No error, no log, no red test. That is R-122: the controller emitted `offsite_restic` from fork-4, all three real customers had it stored, and no delivered recipe ever contained it. Then extend `TestAssembleDRRecipe_CarriesEveryEmittedSection` (same commit) and, for a host-half section, the agent's `DRRecipeHostHalf` + BOTH copies of `testdata/host-report.golden.json` (byte-identical, cross-repo).

STATUS.md

@@ -1,89 +1,125 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-08-03.**
+**Updated 2026-08-23 — you now hear about EVERY broken app, not just the first one each hour. The
+hub deployed itself; nothing is waiting on you except the floor from the last release.**
 
-> **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority on open work; this
-> page restates part of it in plain words, and **nothing may exist only here**. **Not `CONTEXT.md`**,
-> which is technical state written for Claude Code — keep the two separate. **Maintenance:** update
-> at the end of every session in which something shipped, broke, or was decided. One screen; cut
-> items rather than extend it.
-
-## What works right now
-
-A blank machine boots the Felhom disc, installs itself unattended, and is claimed by the customer,
-who sets their own password. They install apps from a catalogue of fifty-three, share files over the
-home network, and open apps from a launcher or a shared link. Backups run on their own to three
-places — the machine's drive, a second drive, and an encrypted off-site copy — and a customer can
-restore files and app data from the drive alone. Apps come back after a power cut: hard-reset the demo
-box six times, everything returned every time, and an app switched off deliberately stayed off.
-Proven end to end on real hardware.
-
-## What's broken
-
-- **Rebuilding a machine silently takes away its off-site app-data backup.** `demo-hp` was rebuilt on
-  3 August and came up without one, and stayed that way for a day. **Fixed on 4 August** — re-issued,
-  the machine picked the new password up in 15 seconds and reattached to the same repository, and you
-  escrowed the key. **The underlying fault is not fixed:** the off-site password is delivered exactly
-  once and a rebuilt machine cannot ask for another, so this will happen again on the next rebuild.
-  The other machine survived the same rebuild only because an unused password happened to be waiting
-  for it. *(R-193)*
-- **The daily email about it tells you the wrong story**, and the automatic repair that exists for
-  this declines without saying why. The message says the password was never applied; it was, on
-  23 July, and worked for eleven days. *(R-192)*
-- **The weekly off-site backup reports FAILED although it worked.** It uploads correctly and then
-  trips on a tidy-up step it is deliberately not allowed to perform, so the job ends in an error and
-  you get an email. The backup itself is safe and on the endpoint. Both demo machines do it; one
-  setting per machine fixes it. *(R-191)*
-- **The off-site copy can be erased by the machine that made it.** The credential that writes it can
-  also delete it. A daily snapshot is armed as a stopgap.
-  *(R-95, R-87)*
-
-## What shipped recently
-
-- **The on-machine backup copy has now been proved to restore — by the machines themselves.** Both
-  demo machines restored their own on-machine backup into a throwaway machine overnight, booted it,
-  checked it and destroyed it, without being asked: 84 and 109 seconds each. Every restore proof we
-  had before this was of the *off-site* copy; the copy an ordinary recovery would actually use had
-  never been tested on either machine. Both also proved their off-site copy on the same night, one
-  after the other rather than at once, which is the machine deciding for itself what to do first.
-  *(closes the last open half of R-86/R-185)*
-- **A backup copy the machine was never allowed to read — and could not tell you about**, on both
-  demo machines. The permission was one command; the silence was the real fault, and the machine now
-  checks whether it may read each copy it depends on and says so when it may not. *(R-185)*
-- **Three ways the alarm system was misreporting its own work — all fixed.** None of them ever risked
-  data. **(1)** When the machine proved a backup restores, that result could vanish if the agent was
-  restarted in the following quarter-hour — and yesterday's change made the gap a week rather than a
-  day, because the machine correctly refuses to re-prove an archive it has already proven. It is now
-  written to disk with the result and survives. This was caught happening, not predicted: a real
-  14.5 GB off-site restore passed and left no record at all. **(2)** Every release had about a
-  fifty-fifty chance of emailing you a failure for a release that worked; the version tag is now
-  published after the binary, and a new check catches the opposite mistake so nothing is traded away.
-  **(3)** A released binary can now be rebuilt by anyone and checked against the fingerprint you
-  approve — until today, rebuilding produced different bytes. *(R-189, R-188, R-186)*
-
-
-## What we're working on
-
-- **Now:** nothing outstanding.
-- **Next:** proving the off-site *app-data* copy can actually be restored — the one tier nothing
-  tests unattended. Most of the machinery it needed arrived with the restore-test change below.
-  *(R-87)*
-- **After:** the off-site copy that the machine making it can still erase. *(R-95)*
+> **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority; this page restates
+> part of it in plain words, and **nothing may exist only here**. **Items, not paragraphs. One screen.**
+> If it does not fit, it belongs in the register instead.
 
 ## Waiting on you
 
-- **A job, not a decision: the hub password needs changing.** A diagnostic command printed it into a
-  session log; nothing suggests anyone else saw it. *(R-132)*
-- **One small question, not urgent.** The automatic check cannot see which version you have told
-  machines to install, only which ones exist. Closing that needs either a password given to the build
-  server or a check inside the hub itself. *(R-184)*
-- **Nothing else.**
+*This section is allowed to be longer than one screen, and each item says what happens if you do
+nothing.*
 
-## Changed since last update
+1. **Raise the controller floor to 0.223.0** — Hub → Configuration, the global floor box, on its own.
+   You already vouched the golden (the hub reads `golden_version` 0.223.0), but the floor still reads
+   **0.222.0**, so the last step of that release is outstanding.
+   **If you do nothing:** boxes are offered 0.223.0 but nothing requires it, so a machine that misses
+   the offer stays on 0.222.0 — where an app stopped from outside is reported as if you stopped it.
 
-- **2026-08-04** — Both demo machines proved their on-machine backup restores, on their own,
-  overnight — the copy an ordinary recovery uses, never tested until now. Found while checking: the
-  weekly off-site backup reports failure after a successful upload. *(R-185, R-191)*
-- **2026-08-03** — Fixed three ways the alarm system misreported itself: a proof of a working backup
-  that could vanish on a restart (seen happening), a release that emailed a failure for a release
-  that worked, and a released binary nobody could rebuild and check. *(R-189, R-188, R-186)*
+2. **Nothing else.** This release changed only the hub, and the hub deploys itself through its
+   manifest. No golden, no vouch, no controller.
+
+3. **Whether to change the hub password** (R-350). I printed it into my own session log on 20 August.
+   Not in git, not in any saved file — in the log on this machine. **If you do nothing:** it stays as
+   it is, at the risk you accept by leaving it. I can change it without ever showing you the new one.
+4. **`demo-hp`'s network setup does not match our own notes** (R-338) — the machine works, the page is
+   wrong, or the other way round. **If you do nothing:** the page keeps misleading the next session,
+   as it misled one by an hour.
+
+## Decided — and what would reopen each
+
+- **Getting old backups back yourself: NOT BUILT, deliberately.** **Reopens if:** a real customer
+  asks. *(R-312)*
+- **The unopenable old copy on `demo-felhom`: KEPT as a test fixture** — the only state in existence
+  where a set-aside store is present and cannot be opened. **Delete when:** that work ships or is
+  abandoned. *(R-313)*
+- **A machine in two kinds of trouble says both things: LEFT AS IT IS.** **Reopens if:** observed
+  outside a constructed test. *(R-303)*
+
+## What works
+
+Both demo machines are home, healthy and reporting — agent **0.130.0** published and running on both.
+`demo-hp` runs controller **0.219.0**; the fleet floor is still **0.218.0** (see item 2 above).
+Off-site is credentialed on `demo-hp` and its store opens with the machine's own key.
+
+**The fleet, because two summaries have been misread:** five customer records, three machines.
+`demo-felhom` and `demo-hp` are ours and disposable; `drill-r50` is a nested drill VM, reverted and
+off. **`peti-felhom` is a real machine we have not heard from since 15 July** and has no host record.
+**`tester-1` is a record with no machine.**
+
+## Shipped
+
+- **Taking the safety copy no longer destroys the app's own backup** (R-361, controller 0.221.1,
+  proven on `demo-hp`). Before every restore the machine saves a copy of your live database. To do
+  that it called the ordinary backup routine — **which always writes to the app's normal backup
+  filename first** — so the app's real backup was overwritten and then renamed away. Until the next
+  nightly run the app had **no database backup of its own**, and a local recovery in that window would
+  have told you the app never had a database. A comment in the code said this could not happen; it
+  could, and had been happening for four months. Proven fixed the only way it can be: the app's own
+  backup file is now **byte-identical before and after a restore**, on both database types.
+- **A failed database restore now puts your data back by itself** (R-379/R-380, controller 0.220.2,
+  proven on `demo-hp`). Until today, if a restore of an app's database went wrong, the machine had
+  already taken a copy of your live database — a good copy — and **nothing in the product could put it
+  back.** You were shown a filename. On one of the two database types it was worse: part of the
+  restore applied, part did not, and **the dashboard said the app was healthy**. Now the machine puts
+  your own copy back automatically and says plainly: the restore failed, your data is as it was, the
+  app is running. Proven on both database types, byte-identical both times.
+  **If even that fails**, the app is deliberately **stopped and held** rather than started — a running
+  app on a half-written database lets you type into it and makes the damage permanent — and you are
+  told to contact us. That was your ruling this morning. **Two things also stopped:** the error no
+  longer pastes raw database text at you (it was 615 bytes once, including rows out of your own
+  database), and the undo copies no longer pile up forever — three per app, and they were being copied
+  off-site permanently.
+- **The off-site restore now works for the other 40 apps** (R-356, controller 0.219.0, proven on
+  `demo-hp`). It used to refuse before starting, tell the customer a running app „nincs telepítve",
+  and send them to reinstall it "to the same place" — a place those 40 apps never offer, because they
+  were never given a drive to choose. It was asking one question to answer two. Proven today on
+  `privatebin`: data planted through the app itself, backed up, **deleted**, restored — **all 15 files
+  back byte for byte**, Hungarian accented names included, message „0 fájl és 1 adatkötet
+  visszaállítva". The 13 apps that do have a drive are unchanged, checked the same way.
+- **The off-site restore gives an app's data back at all** (R-354, controller 0.218.0). It used to say
+  „0 fájl visszaállítva", report success, and the folder was simply not there. It now names what came
+  back, because a restore that mentions only its file count is how a silent loss reads as a success.
+- **Paperless's database is in the backup, and restoring it takes an undo copy first** (R-355,
+  controller 0.218.0). The dump was landing in a folder named after an app that does not exist. **One
+  app of 53 was affected**, established with a check first proved able to catch a planted second case.
+- **The system tells you when it cannot see the off-site copies** (R-339) — a mail after ~30 minutes,
+  hourly while it lasts, one all-clear. **Caveat:** it watches whether the machine answers, so it
+  would *not* have caught the 18 August fault, where one service was wedged and the machine stayed
+  healthy.
+- **The connection leak was ours and is fixed** (R-344). Our agent opened a connection to the off-site
+  box every 15 minutes and never closed it; the idle timer was switched off. Proved by fixing one
+  machine and leaving the other: same work, 4 more leaked on the untouched one, none on the fixed one.
+  The off-site box is back to **17** open connections from **415**.
+- **A dated check can no longer be quietly missed** (R-341) — but it speaks on the next push, not on
+  the day. **A machine we tell to be quiet is no longer reported as dead** (R-321). **One name per
+  secret** (R-295, R-323). **The hub's own words are under a guard** (R-324). **Removal reverses the
+  installation** (R-316). **A correct recovery code is no longer called wrong** (R-311). **The drive
+  can be re-attached after a reinstall** (R-280).
+
+## Broken, or knowingly incomplete
+
+- **Nothing ever checks that the off-site store is still readable** (R-359). Not the controller, not
+  the agent. We find out at restore time. A deliberately corrupted copy was caught instantly by the
+  standard tool — which we never run.
+- **A restore that returns nothing still reports success** (part of R-354's neighbourhood, not fixed
+  today) and **verification copies have no delete guard**. Both deliberately left for their own rows.
+- **We ask the off-site box a question about once a second** (R-336) — ~85,000 a day for a box we
+  write to weekly. The leak that made this dangerous is fixed (R-344); the volume is not. The ceiling
+  is **under a year** away on the corrected measurement, not two.
+- **Peti's machine has no recovery route at all.** A real machine belonging to a real person, silent
+  since 15 July, no key, no off-site copy, no local backup. **If that drive fails, everything on it is
+  lost.** First act of any visit: copy the ~3.6 GB off before anything is reinstalled.
+- **The agent picks dnsmasq by looking at a file another package owns** (R-317) — one line; LAN name
+  resolution goes missing quietly.
+- **Three facts the machines send still have no reader** (R-264); **the storage page has its own
+  reason for an empty list** (R-298); **two thirds of the standing picture is unproven** (R-326:
+  23 of 55 claims walked — `python3 scripts/unproven.py`); **the picture still describes one defect we
+  fixed twice** (R-327).
+
+## Working on next
+
+The 2026-08-09 batch (R-279 … R-292), still untriaged; the three remaining R-264 readers; R-317 (one
+line in the agent); R-327 (decide the naming claim's status); R-359 (nothing reads the off-site store).

documentation/PROMPT-TEMPLATE.md

@@ -130,8 +130,35 @@ never park it on a branch.
    conventions, access). Versioned copy: `felhom.eu/documentation/runbooks/workspace-CLAUDE.md`.
 2. `<repo>/CLAUDE.md` — repo build/deploy, code-quality rules, trunk-based + live-validation rules.
 3. `<repo>/CONTEXT.md` — current project state / decisions / roadmap.
-4. `felhom.eu/documentation/architecture/02-controller-module-map.md` — KEEP/PORT/DELETE/MODIFY
-   per-package classification. **Read before touching `backup/`, `storage/`, `system/`, `config/`.**
+4. **THE ARCHITECTURE DOCUMENT FOR THE AREA THIS TASK TOUCHES — NAME IT AND SAY WHAT IT SAYS.**
+   Not "read the architecture folder": name the file, and state in one line what it rules about this
+   area. **A prompt that cannot name one says so explicitly, and that absence is itself recorded** —
+   an undocumented architectural decision is how a deliberate design gets "fixed" by someone who did
+   not know it was one.
+
+   | area | file |
+   |---|---|
+   | what the platform does today, per scenario | `00-capability-map.md` |
+   | topology, trust, **app-data placement (hot vs bulk)**, backup scoping | `01-topology-and-trust.md` |
+   | controller packages: KEEP/PORT/DELETE/MODIFY | `02-controller-module-map.md` |
+   | the host agent | `03-host-agent.md` |
+   | control-plane authorization | `04-control-plane-authorization.md` |
+   | the hub | `05-hub-architecture.md` |
+   | off-site connectivity | `06-offsite-connectivity.md` |
+   | tiers, capture sets, restore paths, recovery model | `07-backup-architecture.md` |
+
+   **Three sources, in this order, before any claim: the architecture folder holds the REASONING, the
+   register holds the WORK, source holds the TRUTH.** Skipping the first is how a decision gets
+   reported as a bug.
+
+   **And the test that catches it: _is what I am about to call a defect something we chose?_** If it
+   was chosen and the choice is wrong, that is **a proposal to change a decision** — it goes to the
+   operator as a decision, not filed as a bug. **Cost of learning this (R-370):** between 19 and 22
+   August a documented placement decision was called a defect in four places, because the register and
+   live source were read and `documentation/architecture/` was not.
+
+   `02-controller-module-map.md` remains **required reading before touching `backup/`, `storage/`,
+   `system/`, `config/`.**
 5. `felhom.eu/documentation/controller/<feature>.md` — code-verified feature docs (authoritative; match
    code, not summaries, if they drift).
 6. `controller/README.md` (or `felhom-agent/README.md`) — module map, feature reference, REST API.
@@ -229,7 +256,8 @@ Then:  [exact refusal — HTTP status, error, and the proven non-effect, e.g. "m
    `go build ./... && go vet ./... && go test ./...` — all green before proceeding. The build IS the
    typecheck; do not accumulate compile errors.
 2. **Minimal changes:** build only what's listed. No "while I'm here" refactors. Note anything worth
-   fixing under "Observations" (§15) — don't act on it.
+   fixing under "Observations" (§15) — don't act on it, but **do file it**: §15.9's marker rule means
+   "not acted on" never means "not recorded".
 3. **No silent failures:** never swallow a parse/exec error — log it. Check a subprocess's **own** exit
    code; never pipe in a way that hides a 127. (The silent `.felhom.yml` quoting bug + the spike's
    exit-swallow lesson.)
@@ -347,11 +375,50 @@ or **what is open changed**), update **all four** in the SAME session:
   that changes what is open without touching it re-creates exactly the thread-loss the register was
   built to solve: `REPORT.md` is overwritten every session, so nothing durable may live only there.
 
+  > **AN ENUMERATED GAP BECOMES A ROW, IN THE SAME SESSION. PROSE IS NOT A RECORD.**
+  >
+  > This binds **surveys, inventories, spikes, reviews and diagnoses**, not only implementation
+  > sessions — those are the documents that enumerate gaps, and they are the ones that have lost them.
+  > If a document says a thing is missing, unhandled, unreachable or *"not currently filed"*, it does
+  > not leave the session as prose. It leaves as a row here, with a rank and an owner. Writing
+  > *"not filed"* is not a disposition; it is a note that the work was seen and dropped.
+  >
+  > **A row in `ROADMAP.md` alone does not satisfy this.** Both files hold open work and only this one
+  > calls itself the source of truth, so a finding recorded solely there is invisible to every
+  > standing rule that says *"grep the register before minting"* (**R-369**).
+  >
+  > **The cost, recorded so the rule can be narrowed later rather than becoming permanent by
+  > accident:** R-107 — *"no offsite action unpacks the named-volume tars Tier-3 captures"* — was
+  > enumerated on **2026-07-28**, given a number, written into `ROADMAP.md` and
+  > `07-backup-architecture.md`, and never entered here. **It was rediscovered from scratch 25 days
+  > later by an overnight drill that planted files and watched them not come back**, and shipped as
+  > R-354. The work was right the first time; only the filing was missing.
+
 **Report which `OPEN-ITEMS.md` rows the task opened, closed or re-ranked** (§15). Every row carries
 an owner — a row nobody owns is how items got lost in the first place.
 
 ### N.6 Website version bump (if controller/hub version is shown on the site).
 
+### N.7 Housekeeping — before the report, not after (2026-08-22 ruling)
+
+**Nothing was ever pruned and the numbers got bad:** the register reached 672 KB across 286 entries,
+over half of it finished work, one entry at 16 KB. **A file that cannot be read is a file that cannot
+be checked**, and this project has paid for that twice — a record nobody could find because it sat
+inside an entry about something else, and a finding rediscovered because nobody could see it.
+
+1. **Compress what this session closed.** A closed row keeps its title, the version it shipped in, its
+   evidence paths, and any sentence stating a rule. Everything else goes, and it moves to
+   `backlog/CLOSED-ITEMS.md`. **Nothing is deleted:** the compressed entry names the commit whose
+   `git show` returns the full original text. **Open rows are not touched — their detail is doing a job.**
+2. **Rehome live reasoning before compressing it away.** If a closed entry carries the reason a rule
+   exists or a fence sits where it does, that reasoning moves — to `CONTEXT.md` if it is a decision,
+   to the owning `architecture/*.md` if it is a shape. **Where it is a decision, mark the resulting
+   shape `[DESIGN]` in the architecture document and point it at the log entry** (§4's map).
+   **Losing a reason is how a deliberate design becomes a bug in someone's eyes** — that cost four
+   mis-filed defect reports in August 2026 (R-370, R-376).
+3. **State the register's size in the report, before and after.** A number every session is what makes
+   growth visible; prose about tidiness is not a mechanism.
+
 ---
 
 ## 11. Tests
@@ -476,11 +543,33 @@ Report MUST include:
 6. **Deployed versions** + `docker ps` / agent-service / hub-pod verification output.
 7. **NOT yet live-validated — awaiting supervised [Bx]:** explicit list (the real
    put-data → operate → integrity flow).
-8. **Teardown evidence — all three §13 layers**, if the run provisioned anything: the machine deleted,
+8. **Evidence copied off BEFORE each revert** — for every phase that ran on a machine, the logs were
+   pulled to the evidence directory **at the end of that phase**, before any revert, snapshot restore
+   or teardown, **including the intermediate ones**. *The intermediate revert is the one that gets
+   forgotten: two sessions lost a phase's logs to a mid-run revert to `virgin` on 2026-08-12 and
+   2026-08-13 — same machine, same point, three days apart (R-320).* **If a phase's evidence is
+   already gone, the report says so plainly and the finding is REPRODUCED independently** — that is the
+   expectation, not an improvisation. A quotation read live and no longer re-readable is named as such.
+9. **Teardown evidence — all three §13 layers**, if the run provisioned anything: the machine deleted,
    `pvesm status` before/after with the space returned, and the **hub-side record's disposition named**
    (deleted / retained-with-reason / gate-blocked-with-the-command). A run that provisioned nothing says
    so. "Teardown clean" without layer 3 is not a report — it is the `sess-c` failure.
-9. **Observations:** out-of-scope items noticed — documented, NOT acted on.
+9. **Observations:** out-of-scope items noticed. **Every item carries `FILED: R-NNN` naming the
+   register row opened for it in THIS session, or `NOT-A-FINDING: <reason>` declaring plainly that it
+   does not warrant one.** Opening the row is the default; declaring is the exception and its reason
+   is the whole of the marker.
+
+   **This wording replaces "documented, NOT acted on" (2026-08-24, R-389), and the old wording was
+   the defect.** "Documented" was satisfied by a paragraph — and `REPORT.md` is overwritten every
+   session, so a paragraph has a lifetime of one session. On 2026-08-23 a live, reproducible finding
+   (only the first broken app per hour reaches the operator) was written under Observations and
+   nowhere else; it had no register row and had to be re-derived the next day. That is the same shape
+   as R-341, and this project's own standard says **a rule without a mechanism is a wish**.
+
+   **The mechanism is gate 11** (`scripts/observations_gate.py`, registered in the repo runners),
+   which refuses a push whose `REPORT.md` carries an observation with neither marker. Note what it
+   deliberately does NOT accept: a passing mention of some other `R-NNN`. The lost item cited `R-182`
+   as an analogy, so "cites a register row" would have passed the very item the gate exists to catch.
 
 ---
 

documentation/README.md

@@ -17,6 +17,12 @@ The Docker-only app-domain controller. Full per-area docs grounded in current so
 → [`controller/README.md`](controller/README.md): module map, deploy & stack lifecycle, backup
 architecture, storage/monitoring/metrics, auth/hub/sync/integrations.
 
+### Where we stand — `architecture/where-felhom-stands.*`
+The operator's one-page picture of what is proven, built, partial and missing.
+- [`architecture/where-felhom-stands.html`](architecture/where-felhom-stands.html) — **generated**; do not hand-edit
+- [`architecture/where-felhom-stands.yaml`](architecture/where-felhom-stands.yaml) — the data behind it; every claim cites its source. Gate: `scripts/check_stands.py`; regenerate with `scripts/render_stands.py`
+- [`architecture/where-felhom-stands-2026-08-09-snapshot.html`](architecture/where-felhom-stands-2026-08-09-snapshot.html) — **a dated snapshot, NOT maintained.** The original React bundle, kept for the record; its statuses are those of 2026-08-09 before the verification pass
+
 ### Host agent & platform — `architecture/`, `proxmox-platform.md`
 The operator-tier agent and the Proxmox platform.
 - [`architecture/01-topology-and-trust.md`](architecture/01-topology-and-trust.md) — topology & trust model

documentation/architecture/00-capability-map.md

@@ -1,5 +1,20 @@
 # 00 — Felhom Capability Map
 
+> **How to read this document.** Two kinds of statement appear, and where this document marks them it
+> marks them like this — the same wording as `07-backup-architecture.md:11-17`, carried here on
+> 2026-08-22 (R-376) so a reader meets one convention and not eight:
+>
+> - **[DESIGN]** — a decision taken. Not derived from code; the code may not implement it yet.
+> - **[FACT]** — an observed property, carrying a `file:line`, a live command output or a citation.
+>
+> **Statements in this document are NOT yet all marked.** Marking them wholesale is a large judgement
+> exercise and a wrong mark is worse than none, so only what a session touches is marked (R-376).
+> **An unmarked statement therefore means "not yet classified", never "observed".** That ambiguity is
+> exactly what cost this project three sessions in August 2026: the hot/bulk placement decision sat
+> unmarked beside a marked `[FACT]`, and was read as an observation and reported as a defect.
+
+
+
 > **What this is:** the single cross-component truth table of what the Felhom platform can do
 > **today**, at what confidence level, with verifiable evidence. Rows are *scenarios* (user- or
 > operator-visible outcomes), not modules — a scenario spans agent + controller + hub + catalog,
@@ -36,9 +51,44 @@
 | Box survives a wrong-NIC install: hub-unreachable first boot → legible Hungarian console screen (NIC table + remedy) + NIC sweep self-heal (bounded DHCP + hub probe per NIC, success-only persist), and the baked root password is operator-knowable (`<iso>.rootpw.txt`) | scripts v1.24.0 (`scripts/iso/felhom-bootstrap.sh` `network_gate`/`sweep_nics`, `build-felhom-iso.sh` rootpw emission) | **PROVEN-LIVE (nested drill — nested ≠ metal: metal proof rides the next real multi-NIC install)** | `audits/SPIKE-firstboot-nic-sweep-2026-07-22.md` — dead-NIC install from the virgin v1.24.0 ISO baked the 192.168.100.2 fallback (WITH a dead default gateway), the R-59 screen painted on the console (screendump captured), and after the cable move the box swept to the working NIC, re-leased and **self-registered at the hub unaided in under a minute**; the drill also caught + fixed the stale-fallback-route trap (flush before the bounded dhclient) and verified the emitted rootpw against the installed box's shadow hash | R-59 ships as a first-boot gate, not an install-time abort (recorded deviation — the fallback is the auto-installer's own, initrd hook out of scope); sweep is structurally first-boot-only (`state.json` gate + unit done-flag condition); a box past install-start gets the screen but its interfaces are never touched |
 | Customer claim: one-time emailed code → customer sets own password (bcrypt, operator never sees it) | controller v0.122, hub v0.50 | **PROVEN-LIVE** (drill VM) | `DRILL-day0-vm-2026-07-12` §10/F-4 (gate ON via real edge; claimed, code consumed) | Never executed by a non-Viktor human → R-3. **Deliverability (R-4), gmail half DONE 2026-07-18:** the rehearsal's claim email was the first sent under the tightened DMARC `p=quarantine` and **landed in the gmail Inbox, not spam** (`tests/VALIDATION-n100-rehearsal-2026-07-18.md`). **freemail.hu remains Viktor's open half.** (Dropped mis-cited `CAMPAIGN-4` F-C — that is the escrow-claim 502, not password claim) |
 | Customer binds their own appliance (self-service): operator-sent 7-day tokenized capability link → public two-factor `/bind/<token>` (console pairing code + retrieval passphrase) → hub stages the bind, no operator | hub v0.66.0 + ISO scripts v1.20.0 | **PROVEN-LIVE** (real customer-zero bind on metal, 2026-07-18) | **`tests/VALIDATION-n100-rehearsal-2026-07-18.md`:** operator minted + emailed the link 16:28:55 (7-day TTL, expiry 2026-07-25 recorded); **the customer bound their own box at 16:29:55 with `attempts=0`, `locked=0`** — `appliance_bound` carries source **`customer_selfbind`**, and the credential was delivered **26 s later** with no operator action. Hub-side lifecycle in `hub-state.txt` (`selfbind_tokens` mint→email→consume). Prior unit evidence: hub v0.66.0 (`web/selfbind.go`, `store/selfbind.go`; Scenarios A–F + F1/F2; 4 red-proofs verified red — THE TRAP `/bind/` exemption, no-oracle, lockout, single-active); GC verdict §3 (no appliance GC → TTL stands alone) | R-27 **slice 1**. No appliance list ever rendered; wrong code == wrong passphrase (one generic failure); 5-attempt lockout → call support; expiry falls back to operator-bind. **Live first-run DONE 2026-07-18** (rehearsal; the console banner rendered on the real ISO). **R-27b** (controller second-box dismissable prompt) deferred; **multi-box-per-link** = repeated operator sends |
-| Escrow ceremony: customer-facing wizard, one-shot R claim, operator zero-knowledge | controller v0.127, agent v0.88/0.89 | **PROVEN-LIVE** (drill VM, endpoint-exact) | agent v0.88.0 REPORT (ceremony ~4s, one-shot claim 200→410, R absent from every payload); `SPIKE-controller-escrow-2026-07-13` | **Customer-facing browser wizard FIRST LIVE FIRING 2026-07-18** (`tests/VALIDATION-n100-rehearsal-2026-07-18.md`, S6): customer zero drove the wizard on the reborn box — ceremony started 16:56:29, recovery code claimed one-shot 16:56:39 (absent from logs by design), hub-verified and `EscrowState` auto-confirmed 16:56:41, **offsite runs enabled 12 s after the ceremony began**; the v0.138.0 „megerősítésre vár, legfeljebb 15 perc" awaiting card rendered and flipped on the ACK (operator screenshots: Viktor's set). Honest caveat: at a 12-second confirm the awaiting window is so short that catching *both* states on screen is luck, not procedure. Prior: endpoints driven on the drill VM. **agent v0.89.0:** `/escrow/preflight` `pbs_storage_id` row now live-reloads (reads current agent.json) — a pbsdr convergence that seeds the id flips it green with NO service restart. **hub v0.60.0 (data-first retention):** a re-escrow with a DIFFERENT sealed passphrase no longer destroys the old blob — the hub RETAINS it (`host_escrow_superseded`), so a previous passphrase stays recoverable with its recovery code (turns the reinstall-orphan incident from "history destroyed" into "history recoverable"). Guided-recovery flow = R-26. Red-proof `TestSaveHostEscrow_RetainsSuperseded`. **hub v0.60.1 — custody survives the host lifecycle:** host deletion (with the escrow ack) DEMOTES the current blob to retained custody (moved into `host_escrow_superseded`, never destroyed; existing superseded rows spared); the customer Danger-zone Delete is the one true purge point (cascades both escrow tables incl. already-deleted hosts). No operator path through host lifecycle can lose a blob. Red-proofs `TestDeleteHost_DemotesEscrowNeverDestroys` + `TestDeleteCustomer_PurgesEscrowCustody`. **agent v0.93.0 (2026-07-21) — recovery codes can no longer contain a hyphenated word.** The EFF large list holds exactly four entries containing the hyphen the words are joined with (`drop-down`, `felt-tip`, `t-shirt`, `yo-yo`); drawing one produced a code that reads as 11 words instead of 10 — ambiguous to transcribe in exactly the situation R exists for. They are now excluded **from GENERATION only**: the draw space goes 7776 → 7772 and a 10-word code 129.248 → 129.241 bits, still well clear of the 128-bit floor. **Every code already issued remains valid** — R is verified as a whole passphrase by the PBS scrypt KDF and is never re-split, so no customer needs to re-run a ceremony. This also retired the long-standing ~1/5 `TestGenerateRecoveryCode_EntropyAndFormat` flake, which was this defect and not a flaky test |
-| DR tier by default: PBS + WireGuard base infra on every install, hub-controlled activation | installer v1.15, agent v0.86, hub v0.51 | **PROVEN-LIVE** (2026-07-21) | `DRILL-day0-take2-2026-07-12` §2 (WG enabled both modes, PBS-DR descriptor auto-provisioned ~1s after WG registration, zero operator steps); ships installer v1.15/agent v0.86/hub v0.51 | Live only on demo/drill fleet. (Cited spike was slice-0 mechanics — shipped nothing; corrected.) **⚠ The candidate upgrade to PROVEN-LIVE is WITHDRAWN — the 2026-07-18 rehearsal produced a live counter-example (R-39).** On the reborn N100 the descriptor auto-provisioned and the agent reported `converged state=applied` (16:45:53), yet **the storage is dead**: `pvesm status` → `felhom-pbs: error fetching datastores - 401 Unauthorized` / `inactive`, and a direct probe with the stored credential returns **401 on every endpoint including `/version`** while the WG transport is healthy (handshake 9 s, 27.9 ms RTT) — i.e. authentication failure, not ACL scope. Root cause in the evidence: **the hub minted a SECOND token secret at 16:47:52, two minutes after the agent had applied the first, and `consumed_at` is still NULL**; the converged state machine will not re-apply, and the agent's 15-minute verify loop **cannot even read the credential to notice** (`open /etc/pve/priv/storage/felhom-pbs.pw: permission denied` — non-root agent reading a file it writes through a root wrapper). A tier that reports `applied` while silently unable to authenticate is exactly the shape that must not carry a PROVEN-LIVE badge. See `tests/VALIDATION-n100-rehearsal-2026-07-18.md` F2 and `pbs-dr-state.txt`. **agent v0.89.0 closes the F4 non-default-storage-id gap (R-22) — PROVEN-LIVE 2026-07-17:** the reconcile self-grants the ACL through the root wrapper on a pre-check 403 instead of dead-locking. Reproduced F4 on the demo (marker moved aside = reinstall fresh-state + felhom-offsite ACLs revoked) → next reconcile tick `pbsdr: pre-check 403 … self-granting … (R-22)` → `converged state=adopted` in ~3 s, ACLs self-restored, `pvesm status felhom-offsite`=active, zero operator action. No more one-shot `pveum` grant  **2026-07-21 — the R-39 fleet fix SHIPPED (hub v0.68.0 + agent v0.91.2), closing the self-heal chain end to end.** The three defects that let a box be `applied` and dead simultaneously are each addressed: the hub stamps a monotonic `secret_generation` into the descriptor so a credential re-key finally MOVES the content hash the agent re-applies on; the wrapper gains a narrow `read` verb so the non-root agent can read the credential it writes (it never could — `/etc/pve/priv` is 0700 root:www-data, which made the verify loop blind by construction); and `pbs.ProbeAuth` turns a 401 into a loud `auth_failed` that the existing `pbsdrheal` damper escalates to a fresh mint. Plus a consumed_at honesty gauge for the disagreement no single tier can see (box says `applied`, hub's staged secret never consumed). Proven live on felhom-pve: the agent read its credential through the wrapper (`rc=0`) and probed successfully (`credential probe OK storage=felhom-pbs`). **STOP-2 RAN 2026-07-21 AND THE CHAIN CLOSED — 13 SECONDS, operator click to converged.** The operator pressed **Re-issue PBS credentials**; the identical click on 2026-07-18 did nothing at all. Full chain (hub UTC / host CEST = UTC+2): `08:39:31Z` hub mints a fresh secret, **generation 0 → 1**, and the descriptor gains `"secret_generation": 1` — with `token_id` and `fingerprint` **byte-identical**, i.e. exactly the re-key shape that used to be invisible → `10:39:34` the agent READS its credential through the wrapper (leg b — the read that was impossible until v0.91.0) → `10:39:38` **`ERROR pbsdr: the DR endpoint REJECTED this box's credential — the tier is applied and DEAD` `previous_state=applied`** (leg c: the exact R-39 failure state, detected out loud for the first time ever) → `10:39:45` **`one-time token secret consumed`** `secret_len=36` (leg a: **NO short-circuit** — this is the line that never appeared on 2026-07-18) → `10:39:45` `felhom-pbs-apply reconcile` (the set-only wrapper, no `--server`) → `10:39:47` **`pbsdr: converged state=applied`**. Corroboration: the agent marker hash moved to `afbb3b41…` (it was byte-identical to the pre-reissue marker in the failure); `consumed_at` stamped `08:39:45Z`; the on-disk secret's mtime moved `2026-07-18 20:28:52` → `2026-07-21 10:39:45`; a live probe with the NEW credential returns **200**; three consecutive hub reports trace the whole state machine `applied → auth_failed → applied`; and **zero** `pbsdr_selfheal` escalations fired — the box healed through the descriptor path before the damper was ever needed, with exactly ONE mint and ONE consume and no `consumed-failed.json`. **Row upgraded to PROVEN-LIVE (2026-07-21).** Evidence: `felhom-agent/REPORT.md` (2026-07-21). |
-| **Recurring offsite (PBS) whole-guest backups actually LAND, and RESTORE** — local daily + offsite weekly as scheduled work | agent v0.97–0.103, controller v0.174/0.175, hub v0.76.0, host-install 1.20.0 | **PROVEN-LIVE (2026-07-26)** | `audits/SPIKE-r82-phase0-2026-07-26.md`; per-repo CHANGELOGs/REPORTs. **Restore round-trip on demo-hp:** `--selftest=restore-test` against `felhom-pbs:backup/ct/9201/2026-07-26T15:42:42Z` → `pass:true`, `verified:"boot+running"`, **`mount_parity:"ok"`** (`mp0=/var/lib/docker 50G`, `mp1=/mnt/sys_drive 20G`, mp8/mp9 throwaway stand-ins for the archived binds), `source_tier:"pbs"`, 4m5s restore+boot+verify+teardown, scratch band clean afterwards and the live guest untouched. | **This row is distinct from the DR-tier row above, which proves ACTIVATION, not ARRIVAL.** That tier was PROVEN-LIVE as `applied` since 2026-07-21 while demo-felhom held ONE snapshot (a healing artifact) and demo-hp held **zero, ever** — "applied and empty", the R-39 shape one level quieter. **What earns PROVEN-LIVE here:** (a) demo-hp's FIRST EVER offsite backup landed (4.25 GB into a verifiably empty namespace); (b) it **restores into a bootable, mount-complete guest** — `mount_parity` is the non-hollow half, since a boot-only verify cannot see a missing data volume; (c) **the multi-tier quiesce ran through the real UI endpoint** (`POST /api/guest-backup/trigger`, authed+CSRF) and produced **exactly ONE stop/start pair with BOTH backups inside it** — `quiescing 1 stack(s)` 17:01:39 → local done 17:02:56 *"next tier may start (app still quiesced)"* → felhom-pbs snapshotted 17:03:06 → `unquiescing` 17:03:06. **App downtime 1m27s for both tiers**, and the app came back healthy. **Known gaps, recorded not hidden:** the SCHEDULED restore-test still only selects the PRIMARY tier, so the offsite tier is never AUTOMATICALLY restore-tested (the manual/selftest path is proven, the unattended one is not); the hub infers "PBS ⇒ weekly" from storage TYPE rather than a reported cadence; the installer-default fleet flip awaits a full weekly cycle. → **R-82** |
+| Escrow ceremony: customer-facing wizard, one-shot R claim, operator zero-knowledge | controller v0.127, agent v0.88/0.89 | **PROVEN-LIVE** (drill VM, endpoint-exact) | agent v0.88.0 REPORT (ceremony ~4s, one-shot claim 200→410, R absent from every payload); `SPIKE-controller-escrow-2026-07-13` | **Customer-facing browser wizard FIRST LIVE FIRING 2026-07-18** (`tests/VALIDATION-n100-rehearsal-2026-07-18.md`, S6): customer zero drove the wizard on the reborn box — ceremony started 16:56:29, recovery code claimed one-shot 16:56:39 (absent from logs by design), hub-verified and `EscrowState` auto-confirmed 16:56:41, **offsite runs enabled 12 s after the ceremony began**; the v0.138.0 „megerősítésre vár, legfeljebb 15 perc" awaiting card rendered and flipped on the ACK (operator screenshots: Viktor's set). Honest caveat: at a 12-second confirm the awaiting window is so short that catching *both* states on screen is luck, not procedure. Prior: endpoints driven on the drill VM. **agent v0.89.0:** `/escrow/preflight` `pbs_storage_id` row now live-reloads (reads current agent.json) — a pbsdr convergence that seeds the id flips it green with NO service restart. **hub v0.60.0 (data-first retention) — ⚠ the claim as written was FALSE for the offsite tier for two months; **FIXED in hub v0.93.0 (2026-08-04), and the row below states what ships TODAY:** a re-escrow with a DIFFERENT sealed passphrase no longer destroys the old blob — the hub RETAINS it (`host_escrow_superseded`) — and **since v0.93.0 the retained row carries `identity_blob` as well as the K-escrow blob**, so a previous passphrase does now stay recoverable with the recovery code that sealed it — **OPERATOR-ONLY, and the customer-facing half of that sentence is FALSE (R-304, drill 2026-08-12).** The retention was exercised end-to-end for the first time that day and **it works**: the retained row carried the identity blob byte-identically (`sha256 a10032341c8584ed…`), the old recovery code unsealed it, and three planted files — including a Hungarian accented filename verified as raw bytes — restored **byte-identical** from a store the box itself could no longer open (negative control first: `Fatal: wrong password or no key found`). **What does not exist is the door.** `ListSupersededEscrow` (`hub/internal/store/store.go:2841`) is the only reader of a retained `identity_blob` and has **zero production callers**; the product's recovery path (`POST /escrow/recover-offsite-password` → `GetHostDRBundle`, `store.go:3152`) selects `FROM host_escrow` — the CURRENT row only. Asked with the code that demonstrably opens the retained row, the product answers **"the recovery code did not open the sealed bundle"**. So: recoverable by an operator with SQLite, `age` and a shell; **not recoverable by the customer, who is told their correct code is wrong.** — **AMENDED 2026-08-12 evening (R-311, shipped hub v0.103.0 + agent v0.129.0 + controller v0.214.0):** the customer is **no longer told their code is wrong.** The agent now tries the retained packages when the current one refuses (`GET /hosts/<id>/escrow/retained` → `ErrCodeOpensRetained` → HTTP 422), and the screen says the code is CORRECT, names the supersession date, says the earlier package is kept and the current backups are unaffected, and routes to support. **What is still true and must not be read away:** there is no in-product ROUTE to the set-aside data (R-312 — every restore entry point resolves its repository from settings and its password from one file; adding an alternative is new surface, not wiring), so the recovery itself remains operator-performed. The status of this capability is therefore **"the customer is told the truth and handed to a human"**, not "the customer can recover their old history". **What was wrong until v0.93.0, recorded because it is the ninth entry in `CLAUDE.md`'s comment-vs-code table and the first that was also customer-facing copy:** `host_escrow_superseded` had no `identity_blob` column and `demoteCurrentEscrowTx` did not copy one, so what survived a supersession was the **PBS datastore key only** — never the restic repository password, which lives in `identity_blob`. The destroying act was the **escrow ceremony** a rebuilt box asks its customer to run. Measured live 2026-08-04, before the fix: both current rows held `blob`=383 B **and** `identity_blob`=572 B; both retained rows held `blob`=383 B only. → **R-198** (SHIPPED), evidence `audits/RECON-offsite-dr-chain-2026-08-04.md` §7. **THREE SCOPE LIMITS THIS ROW MUST NOT BE READ PAST.** (1) **Nothing was backfilled and nothing could be** — rows superseded before v0.93.0 were written without the blob and their source rows are already overwritten; both demo boxes' pre-2026-08-04 repository passwords are gone permanently. (2) **A retained key is not a restore — but as of 2026-08-04 evening it IS a recovered key.** See the row below. (3) The customer-facing orphan card still promises Line truncated
+
+| **The offsite repository password can be RECOVERED from the sealed escrow with the customer's recovery code** | hub v0.94.0, agent v0.125.0, controller v0.195.0 | **PROVEN-LIVE (2026-08-04)** | On demo-felhom, through the real endpoints end to end: the box fetched its own sealed blob from the hub with its own per-host credential (hub log: *escrow blob SERVED … 572 opaque bytes, self_scope=true*), the agent unsealed it with the customer's recovery code, and the extracted repository password's sha256 was **byte-identical** to the one on disk — `c60c8bc737a6…`, which is ALSO the hash the hub had independently stored, so three sources agree. Five minutes earlier the same path with a WRONG code failed closed at age's KDF with nothing written, which proves links 6 and 7 ran independently of the success. R was searched for afterwards and found in 0 log lines and 0 files, with a positive control confirming the search would have found it. Evidence: per-repo CHANGELOGs; `audits/RECON-offsite-dr-chain-2026-08-04.md` §3 links 6–8 | **WHAT THIS ROW DOES NOT CLAIM, stated because the previous over-claim here was struck out four hours earlier.** It covers the KEY, not the DATA. **R-199 BACK-POINTER (omitted when this row was written): the recovery chain's link inventory and the per-link status live in `audits/RECON-offsite-dr-chain-2026-08-04.md` §3; links 1–8 are walked, 9–11 are not.** **Re-confirmed 2026-08-04 evening by an attempt to prove the DATA half:** the R-201 drill was prepared on demo-hp and **halted before the wipe** — the sentinel file was not in the off-site snapshot (R-203), so the wipe would have destroyed it and proven nothing. **No file has still ever been restored from an off-site backup after a wipe** (`audits/DRILL-r201-offsite-recovery-2026-08-04.md`). The install half of the chain (controller v0.196.0 `--recover-offsite-install`, R-200) is likewise unit-proven only — it has never run against a live recovery. A recovered password has never been **installed** (the diagnostic compares and refuses to write, by design), no existing repository has ever been **reopened** under one, and **no file has ever been restored** from an off-site history via a recovered key. Links 9–11 of the chain are open (R-200's remaining half, R-201). The proof also used a box whose local key still exists — the rebuilt-box case, where there is nothing to compare against, is exactly what the drill covers and it has not run || DR tier by default: PBS + WireGuard base infra on every install, hub-controlled activation | installer v1.15, agent v0.86, hub v0.51 | **PROVEN-LIVE** (2026-07-21) | `DRILL-day0-take2-2026-07-12` §2 (WG enabled both modes, PBS-DR descriptor auto-provisioned ~1s after WG registration, zero operator steps); ships installer v1.15/agent v0.86/hub v0.51 | Live only on demo/drill fleet. (Cited spike was slice-0 mechanics — shipped nothing; corrected.) **⚠ The candidate upgrade to PROVEN-LIVE is WITHDRAWN — the 2026-07-18 rehearsal produced a live counter-example (R-39).** On the reborn N100 the descriptor auto-provisioned and the agent reported `converged state=applied` (16:45:53), yet **the storage is dead**: `pvesm status` → `felhom-pbs: error fetching datastores - 401 Unauthorized` / `inactive`, and a direct probe with the stored credential returns **401 on every endpoint including `/version`** while the WG transport is healthy (handshake 9 s, 27.9 ms RTT) — i.e. authentication failure, not ACL scope. Root cause in the evidence: **the hub minted a SECOND token secret at 16:47:52, two minutes after the agent had applied the first, and `consumed_at` is still NULL**; the converged state machine will not re-apply, and the agent's 15-minute verify loop **cannot even read the credential to notice** (`open /etc/pve/priv/storage/felhom-pbs.pw: permission denied` — non-root agent reading a file it writes through a root wrapper). A tier that reports `applied` while silently unable to authenticate is exactly the shape that must not carry a PROVEN-LIVE badge. See `tests/VALIDATION-n100-rehearsal-2026-07-18.md` F2 and `pbs-dr-state.txt`. **agent v0.89.0 closes the F4 non-default-storage-id gap (R-22) — PROVEN-LIVE 2026-07-17:** the reconcile self-grants the ACL through the root wrapper on a pre-check 403 instead of dead-locking. Reproduced F4 on the demo (marker moved aside = reinstall fresh-state + felhom-offsite ACLs revoked) → next reconcile tick `pbsdr: pre-check 403 … self-granting … (R-22)` → `converged state=adopted` in ~3 s, ACLs self-restored, `pvesm status felhom-offsite`=active, zero operator action. No more one-shot `pveum` grant  **2026-07-21 — the R-39 fleet fix SHIPPED (hub v0.68.0 + agent v0.91.2), closing the self-heal chain end to end.** The three defects that let a box be `applied` and dead simultaneously are each addressed: the hub stamps a monotonic `secret_generation` into the descriptor so a credential re-key finally MOVES the content hash the agent Line truncated
+
+| **A customer's file survives a machine rebuild and comes back — the whole off-site story, end to end** | hub v0.94.0, agent v0.125.0, controller v0.197.0 | **PROVEN-LIVE (2026-08-04 night drill)** | demo-hp's controller data volume was destroyed and the sentinel deleted from disk. The customer's recovery code then produced `8a9e33aa4da6…` — **byte-identical** to the pre-wipe on-disk key and to the hub's independent record — and installed cleanly on the bare box. `identity_blob` was unchanged across the wipe (572 B, `updated_at` still 11:11:37). Evidence: `audits/DRILL-r201-night-run-2026-08-04.md` §2 | **WHAT IT DOES AND DOES NOT CLAIM.** PROVEN: after a real rebuild the key recovers byte-identical, the EXISTING repository opens (3 snapshots, 42 026 B — the pre-wipe size; not a fresh history), and the customer restore flow returns the file byte-identical. **ALL FOUR MANUAL INTERVENTIONS ARE CLOSED, AND THE CUSTOMER IS NOW OFFERED THE RECOVERY (2026-08-05). ONE QUALIFIER REMAINS AND IT IS NOT THE OLD ONE — state it precisely.** The 2026-08-04 drill needed four interventions between "the key is recoverable" and "the file is back", none of them in any design document (R-204). **Items 1–3 closed in controller v0.198.0 + hub v0.95.0** (the reset code works first time; a Re-issue no longer marks a healthy escrow stale; a unit restore states it returned the app's definition and database and NOT the customer's files). **Item 4 closed in controller v0.199.0 + hub v0.96.0** (a rebuilt box DECLARES `offsite.state=needs_credential` and `internal/offsiteheal` re-arms the stored credential before minting). **AND THE "needs someone who knows to look" HALF IS NOW GONE TOO (controller v0.200.0, R-193):** a full-page recovery screen takes over the landing pages while the hub holds a sealed package this box cannot open, explains that nobody can replace a lost recovery code, takes the code, opens the repository and lists what is in it — proven live on demo-felhom, which is genuinely in that state (`/launcher` → 302 `/recovery`; a wrong code refused with nothing written, three times, no lockout; the code found in no file, no container log and no debug ring, with a planted-copy positive control that first exposed a mis-aimed sweep). **WHAT THE QUALIFIER IS NOW, and it is narrower:** (1) **the final unlock has never been driven with a CORRECT code through the page** — no recovery code was kept for demo-felhom's orphaned history and demo-hp's is operator-held out of band, so the live run exercised the whole chain (handler → agent → hub fetch → age KDF) and stopped at the unseal; the install and listing rest on tests. (2) **putting files back in place is deliberately NOT part of this** — restore stays per-app, and the step after the listing is R-213. (3) **the journey has still not been re-walked end to end since these fixes** — the closures are proven individually, not as one uninterrupted run. That re-walk is one more drill and it is what is owed. Scope: `demo-hp`, a controller-data-volume rebuild — **NOT** a total host loss, and **NOT** a guest reprovision. **⚠ THE RE-WALK RAN ON 2026-08-05 (CAMPAIGN-11) AND IT FAILED. THIS ROW STAYS AS IT IS — it records a key recovering and a file returning, which remains true — but the JOURNEY row below is the honest verdict and this row must not be read as covering it.** The campaign built a throwaway appliance from the published ISO, destroyed it, and walked the customer's route: **the data half PASSED** (three sentinels byte-identical, including a 12 MB binary and a non-ASCII Hungarian filename, out of the pre-wipe snapshot in 16 s) and **the journey half FAILED** — four operator interventions, three needing root on the appliance, and the first of them was the machine telling the customer their perfectly correct recovery code was wrong (R-216). **R-198's retention is NO LONGER unit-proven — it was PROVEN IN PRODUCTION on 2026-08-05** (CAMPAIGN-11 Phase 3): the first supersession since the fix retained `identity_blob` at **572 B, byte-length exact**, carrying the OLD key `626e424670248db3` while the current row moved to the newly minted `e11a6c542b73477a`; `offsite_repo_key_changed` and `escrow_superseded` both fired at the instant of supersession, and the next off-site run REFUSED as `orphaned` rather than starting a fresh history. Evidence: `tests/campaign11-evidence-2026-08-05/journal.md` **RE-WIDENED 2026-08-22, and the narrowing below is now HISTORY — read both, in order.** Both defects named in the 2026-08-21 narrowing are closed and proven live: **R-354** (controller v0.218.0, `volReplay`) and **R-356** (controller v0.219.0). The **40-class end-to-end story is now WALKED**, including the hardest ten of it: `audits/DRILL-r356-hot-only-restore-2026-08-22/` proved a driveless app with NO database (`privatebin`: planted, off-sited, deleted, restored, **15/15 files byte-identical**, two Hungarian accented names), and `audits/DRILL-r356b-drivLine truncated
+It was read from source that a HELD app would raise the dead-app banner and a customer e-mail, because
+it keeps one container (its database) and so is not `StateStopped`. **It does not.** A held app
+aggregates to `unhealthy`, and `aggregateState` checks `unhealthy > 0` before the mixed-case degraded
+branch while `IsDownState` excludes `unhealthy` entirely. Measured on `demo-hp` on the shipped
+v0.220.2: hold created 21:11:19Z, dead-app scans every 30 s ran over it, and the heartbeat reported
+`0 currently down` throughout. **No suppression was built, because there was nothing to suppress.**
+The detector itself is sound — `classifyRunStates` is pure and a `degraded`/`exited` stack does raise
+the banner, pinned by `TestClassifyRunStates_PositiveControl_ADownStackDoesAlarm`. What the same
+measurement DID expose is **R-384**: an app whose database has died is `unhealthy` too, and is
+likewise silent. Evidence: `audits/DRILL-r361-2026-08-22/evidence/06-part3-decision.txt`.
+
+> **R-384 CLOSED in controller v0.222.0 (2026-08-23), proven live.** The defect was the ORDER of two
+> questions, not the `unhealthy` exclusion: `aggregateState` now asks *"is a supervised member dead?"*
+> **before** the `unhealthy`/`starting`/`restarting` returns, and "some members are up" counts any
+> member not in the down bucket rather than `running` alone. `IsDownState` is byte-identical.
+> **Measured on `demo-hp` 2026-08-23** with the same fixture that read `0 currently down` the day
+> before: `bookstack-db` stopped 05:30:07Z → `app_start_failed` fired at **05:30:14Z**, the banner read
+> *„Telepített alkalmazás nem fut: BookStack (degraded)"*, the stack read `state=degraded` **while its
+> front end was `unhealthy`**, and the heartbeat printed **`1 currently down`** against the previous
+> day's `0`. Evidence: `audits/DRILL-r384-dead-db-alarm-2026-08-23/`.
+>
+> **The HELD-app half of the paragraph above is now also covered** — a held app keeps its database
+> container, so it is the same shape and reaches the same `degraded` verdict.
+>
+> **The alarm ladder that decides all of this now has an owning document:** see
+> `08-alarm-ladder.md` (written 2026-08-23 — before that date no document owned it, and that absence
+> is why the ordering defect was legible only from source).
+
+**WHAT IS STILL NOT CLAIMED:** the FAILURE path is where this class is weak, not the success path — a corrupt dump leaves the customer with an emptied or partially-applied database and an undo copy **no product action can apply** (**R-379**), and on MariaDB it does so behind an app that reports `health=healthy` (**R-380**). The success story is proven; the recovery-from-a-bad-restore story is not.
+
+**NARROWED 2026-08-21 by the backup-truth drill — kept as history; both halves have since closed, see the entry immediately above.** Proven that night on `demo-hp` with planted, hash-recorded files: the **declared-userdata** leg of a **drive-declaring** app does come back byte-identical (`calibre-web`, 5/5 including two Hungarian accented filenames). **Two legs of the same story do NOT:** (a) the off-site restore has **no named-volume leg at all**, so an app's volume tar sits in the unit, in the snapshot and in the checking folder and is never replayed (**R-354**); (b) for the **40 of 53** apps that declare no data drive the off-site restore **refuses outright**, saying a running app „nincs telepítve" (**R-356**). Since the 40-class keeps ALL its data in named volumes, the end-to-end story is **unproven for that class and disproven for the volume leg generally**. The escrow/key half of this row is untouched by that and still stands. Evidence: `audits/DRILL-backup-truth-2026-08-21/evidence/` and `REPORT.md` (2026-08-21). |
+| **The customer's own UNAIDED recovery journey, end to end** | controller v0.206.0, hub v0.98.0, agent v0.127.0 | **PROVEN-LIVE (2026-08-07, the fifth walk) — an unaided customer journey on a real installation, SCOPED: see what it does not claim** | A throwaway appliance was built from the published ISO on demo-hp, claimed, given three sentinels, escrowed, backed up off-site, then destroyed — guest purged and both enrolled drives wiped. The rebuild and the customer's route were then walked with **no command line inside the guest**. **Data: PASS.** All three sentinels byte-identical (`beb9175d…`, `7c8cb0ad…`, `e012e76f…`), including a 12 MB binary and `C11-őrszem-ékezetes-árvíztűrő.txt` — the Hungarian filename survived disk → restic → SFTP → Storage Box → restore → disk intact. Restored in **16 s** out of the pre-wipe snapshot `f3d9cd67`, non-destructively. **Journey: FAIL.** Four interventions, three of them root on the appliance: R-216 (a correct code called wrong), R-218 (the store never opened; the box stopped asking), R-219 (the promised listing structurally could not render), R-220 (the app could not be redeployed — its drives were unenrollable). Evidence: `tests/campaign11-evidence-2026-08-05/journal.md` | **WHAT IT DOES NOT CLAIM, and what the v0.201.0/v0.97.1 fixes do and do not change.** Six of the nine findings are fixed and each is red-proofed (R-216, R-218, R-219, R-217, R-222, R-215) — but **fixes are not a journey.** This row goes green only when the walk is repeated end to end and completes with no operator intervention. **Three findings are deliberately still open and each is a live blocker for some flow:** **R-214** (the console never stops showing a stale pairing code), **R-220** (after a rebuild the customer's drives cannot be re-enrolled — the deploy refuses and the wizard's list is empty, so no app can be redeployed onto its own data drive), **R-221** (a rebuilt box cannot run the escrow ceremony at all, because the pbsdr convergence marker survives on the host while the seeded `escrow.pbs_storage_id` is rewritten out of `agent.json`). **And R-216's fix does not by itself make a NEW box work:** with the hub guard corrected but the Day-0 manifest still vouching agent 0.120.0, a new box is **HELD, not served** — it stops being lied to, which is better, but the feature does not work for it until agent 0.125.0 is vouched.  **⚠ CAMPAIGN-11 PHASES 2 + 4 RAN OVERNIGHT 2026-08-05/06 AND THIS ROW STAYS **FAIL**.** **What they add:** eleven injected faults against the recovery journey, each with a positive control, and a full unattended scheduled cycle. **The backup promise strengthened** — the off-site tier ran itself at 04:15 on a box rebuilt twice and set aside hours earlier (`snapshot_count` 1 → 2), all five daily jobs fired exactly once, and nothing on the must-not list fired. **R-217's and R-215's fixes were proven live under exactly their faults**, the set-aside proved it does not delete (12 535 KB byte-exact at the far end), and a wrong code was refused three times with nothing written and no lockout. **What they do NOT add: any progress on the JOURNEY.** These faults are **not a re-walk** — no customer route was walked end to end — and four new findings say the journey got no better where it matters: **R-224** (a hub outage and a stopped agent are BOTH reported to the customer as a bad recovery code, in 0.056 s and 0.030 s — no unseal attempted; the agent's own `err` distinguishes them and it is discarded at the HTTP boundary, and R-216's gate answers `source=version` so it cannot see reachability — **Phase 1's headline defect relocated from the version channel to the transport**), **R-226** (M1, the only message telling a customer to check their typing, is unreachable on any box that has re-escrowed), **R-225** (an unread store renders `0 pillanatkép · 0 GB` above a card saying it holds backups — 1 snapshot and 12 535 KB were really there), **R-228** (the set-aside history is recorded in `orphaned_renamed_to` and shown by nobody — `OrphanedRenamedTo` has zero references in any template or handler). **§4.1 is now MEASURED rather than deduced** — the floor IS served, from the box's own rendered `GetFloor()` and a cold-started controller's settle-gate line. **§4.2's positive half is still NOT measured** and needs a rebuild. Evidence: `audits/CAMPAIGN-11-recovery-journey-2026-08-05.md`, `tests/campaign11-evidence-2026-08-05/journal-phase24.md`  **2026-08-06 — THE FIVE PHASE-2 FINDINGS ARE FIXED AND THIS ROW STILL SAYS FAIL.** controller **v0.202.0** + agent **v0.126.0** close R-224, R-226, R-225, R-227, R-228. **What changed:** the unlock path now classifies WHY it failed, from the value and never the text, and the message that mentions typing is reachable from exactly one class — a real refusal — with **unknown defaulting to neutral**. Proven live on the venue with the same wrong code and only the hub's reachability changLine truncated
+| **Off-site app-data capture covers the paths an app declares MANDATORY — on BOTH drive layouts** | controller v0.197.0 | **PROVEN-LIVE (2026-08-04) — and this row was OPTIMISTIC before it** | On demo-hp, an app on the **system-data fallback** bound `/mnt/sys_drive/userdata/media/books` while the capture set looked in `/mnt/sys_drive/felhom-data/userdata/media/books`: the declared-mandatory directory was in **no** snapshot and the run reported `ok` (R-203). After v0.197.0 the capture log reads `1 mandatory path(s)` and the file is **listed inside the snapshot** — `restic ls -l latest --tag calibre-web` → `-rw-r--r-- 1000 1000 181 … /DRILL-SENTINEL.txt`. Evidence: `audits/DRILL-r201-offsite-recovery-2026-08-04.md` §2 and the v0.197.0 CHANGELOG | **WHAT IT DOES NOT CLAIM.** It covers CAPTURE, not RESTORE: **no file has ever been restored from an off-site backup after a wipe** (R-201, ready to resume). It also does not claim the enrolled-drive layout was ever wrong — it was not, which is precisely why this survived. And a run that still misses a mandatory directory now reports **`incomplete`** rather than `ok`, so this row's guarantee is one the status can express. **Widened 2026-08-06 (controller v0.205.0, R-234):** the same verdict now also covers an app skipped ENTIRELY — until then a missing declared FOLDER made the run incomplete while an app with no recovery unit at all still reported `ok`, so the smaller gap moved the verdict and the bigger one did not. **This row still claims CAPTURE, not that a newly-selected app is protected by the next run** — for a DEPLOYED app it is (the run's own pre-dump phase writes the unit, measured 2026-08-06), and for an undeployed one it is not and the card now says so || **Recurring offsite (PBS) whole-guest backups actually LAND, and RESTORE** — local daily + offsite weekly as scheduled work | agent v0.97–0.103, controller v0.174/0.175, hub v0.76.0, host-install 1.20.0 | **PROVEN-LIVE (2026-07-26)** | `audits/SPIKE-r82-phase0-2026-07-26.md`; per-repo CHANGELOGs/REPORTs. **Restore round-trip on demo-hp:** `--selftest=restore-test` against `felhom-pbs:backup/ct/9201/2026-07-26T15:42:42Z` → `pass:true`, `verified:"boot+running"`, **`mount_parity:"ok"`** (`mp0=/var/lib/docker 50G`, `mp1=/mnt/sys_drive 20G`, mp8/mp9 throwaway stand-ins for the archived binds), `source_tier:"pbs"`, 4m5s restore+boot+verify+teardown, scratch band clean afterwards and the live guest untouched. | **This row is distinct from the DR-tier row above, which proves ACTIVATION, not ARRIVAL.** That tier was PROVEN-LIVE as `applied` since 2026-07-21 while demo-felhom held ONE snapshot (a healing artifact) and demo-hp held **zero, ever** — "applied and empty", the R-39 shape one level quieter. **What earns PROVEN-LIVE here:** (a) demo-hp's FIRST EVER offsite backup landed (4.25 GB into a verifiably empty namespace); (b) it **restores into a bootable, mount-complete guest** — `mount_parity` is the non-hollow half, since a boot-only verify cannot see a missing data volume; (c) **the multi-tier quiesce ran through the real UI endpoint** (`POST /api/guest-backup/trigger`, authed+CSRF) and produced **exactly ONE stop/start pair with BOTH backups inside it** — `quiescing 1 stack(s)` 17:01:39 → local done 17:02:56 *"next tier may start (app still quiesced)"* → felhom-pbs snapshotted 17:03:06 → `unquiescing` 17:03:06. **App downtime 1m27s for both tiers**, and the app came back healthy. **Known gaps, recorded not hidden:** the SCHEDULED restore-test still only selects the PRIMARY tier, so the offsite tier is never AUTOMATICALLY restore-tested (the manual/selftest path is proven, the unattended one is not); the hub infers "PBS ⇒ weekly" from storage TYPE rather than a reported cadence; the installer-default fleet flip awaits a full weekly cycle. → **R-82** |
 | **Restore-proof is UNATTENDED — the scheduler covers EVERY tier, follows the BACKUP rather than the clock, and a failure is heard** | agent v0.104.0 → **v0.121.0**, hub v0.77.0 → **v0.91.0** | **PROVEN-LIVE (2026-08-03)** | per-repo CHANGELOGs; `backlog/SPEC-r85-phase4-5-2026-07-26.md`. Unit red-proofs for tier rotation, restart-survival, the one-heavy-op gate, failure-emits-an-event, and newborn silence. | **The row above is earned by a MANUAL `--selftest=restore-test`; this one is about the SCHEDULED path, and the distinction is the whole point.** Before R-85 the scheduler could only ever see `cfg.Backup.BackupTarget()`, so the offsite tier was never a candidate — and a failed restore-test was a `[WARN]` line with no event at all, which was true for the LOCAL tier that WAS being tested. Now: oldest-first rotation across every configured tier (operator ruling 2026-07-26), persisted so it survives a restart; a restore-test joins the host-wide one-heavy-operation gate so it never contends with a backup over the same tunnel; and the hub raises two DISTINCT operator-tier signals — `restore_test_failed` (broken now) and `restore_test_stale` (unverified, not known-broken), anchored on R-81 so a newborn box never alarms. **Why this was NOT PROVEN-LIVE until now:** rotation had not been observed selecting both tiers across consecutive UNATTENDED cadences — at a 24h cadence a multi-day window — and a single passing run proves the code path, not the schedule. → **R-85**. **R-86 (agent v0.121.0 + hub v0.91.0, 2026-08-03) replaced the schedule and the observation became possible in one afternoon**, because what has to be observed is no longer a multi-day rotation but a RULE: a tier is due when its newest archive that has settled ~24 h has not been proven. **UPGRADE EVIDENCE — a real unattended run on demo-felhom (2026-08-03), triggered by DUE-NESS, not by a timer.** The scheduler's own log: `15:14:38 restore-test tier is DUE … target=felhom-pbs archive=felhom-pbs:backup/ct/9201/2026-07-28T04:49:43Z … reason="newest settled archive … has not been proven"` → `proxmox-backup-client restore --crypt-mode=encrypt` under the agent's own token → `15:25:08 gate decision class=guest_destroy guest=990000 allowed=true` → `15:25:14 scratch guest torn down` → **`15:25:14 backup: scheduled restore-test passed archive=felhom-pbs:… duration_s=635.1`**. A **14.5 GB encrypted offsite archive pulled from ep0 over the WAN**, restored, booted, verified and destroyed in 635 s, unattended. **The three things a timer could not show**, all verified after it: the state names THAT archive (`{"felhom-pbs":{"archive":"…2026-07-28T04:49:43Z","proven_at":"2026-08-03T13:25:14Z"}}`); a second evaluation reports `due=false … is already proven` and runs nothing; and **an agent restart runs nothing**, which is the defect a person actually noticed — every deploy used to restart the timer. Teardown verified at all three layers: guest absent from `pct list`, **zero** `990000` volumes in `lvs`, and the hub-side `restore_tests[]` entry deliberately RETAINED (it IS the proof the staleness check reads). **R-189 (agent v0.122.0, 2026-08-03) closed the reporting half of this row, and it was a REAL gap in the evidence path:** the proof above reached the hub only because no restart intervened — `restore_tests[]` came solely from an in-memory store, so the 15:25:14 PASS was in fact LOST when the agent restarted 2 m 43 s later for a deploy (`0 restore-tests` on the next two host-reports). Under per-archive due-ness the box would not have repeated the work for a week. The persisted per-tier proof (with the archive, and now the tier) is merged into the report, so a proof survives a restart — one entry per tier, newest wins, and a record that cannot be described honestly is not emitted. **THE HOST TIER'S HALF OF THIS ROW WAS OPTIMISTIC UNTIL 2026-08-03, and it is worth saying plainly.** Every live restore-test cited here is on the OFFSITE tier. The HOST tier was not merely unproven on demo-felhom — it was **unprovable**, and on demo-hp equally: the agent's token had no ACL on `/storage/felhom-backup`, the storage both boxes configure as `local_backup_target`, so the content API answered `{"data":[]}` through the token while root listed three archives. The scheduler skipped it as *"no settled archive yet"* — which is exactly what a brand-new tier reports — so nothing ever said so (**R-185**). **CLOSED 2026-08-03 — agent v0.123.0 + installer 1.24.0.** The grant is applied on both demo boxes (the token now lists 3 and 4 archives), the installer's reuse arm grants on a pre-existing target, and the agent now **asks whether it may read each tier it depends on** instead of inferring it from an empty list: a critical degraded capability naming the storage and the missing role, which the hub alerted and emailed on **while the box was still blind**. **THE HOST TIER IS NOW PROVEN-LIVE, UNATTENDED, ON BOTH DEMO BOXES (2026-08-0Line truncated
 | Customer RESET (middle lifecycle tier: host delete < RESET < customer Delete): one operator action → pre-first-install; all operational state destroyed, identity + basic config survive | hub v0.61.0, felhom-tenantsync v1.1.0 | **PROVEN-LIVE (external teardown, incl. two real firings)** | **`tests/VALIDATION-n100-rehearsal-2026-07-18.md` — two live firings, both host-delete-first, on two different customers** (`demo-vm-felhom` 15:49:57, `demo-felhom` 16:08:51): every leg `ok` (`claim`, `db_purge`, `descriptor`, `hetzner`, `pbs`), escrow acked separately, each completing in 8–9 s (`hub-state.txt` `customer_resets`). The **Hetzner sub-account destruction is now verified against the live pool box** — and produced the run's sharpest lesson: **a sub-account is an access-control object, not a data object.** Deleting it left its `/home` intact, so re-enabling offsite recreated an account over the previous lifecycle's ciphertext under a key this same RESET had destroyed — which is why the orphan guard fired at 16:58:14 (**a finding by S7's own criterion**) and why RESET now needs a base-dir purge → **R-32**. Prior: hub v0.61.0 REPORT; **ep0 live drill 2026-07-17** (throwaway `drill-reset-01` with a real backup: deprovision `deleted:true` destroyed the namespace + backup group + token, idempotent re-run `deleted:false`, all 3 real tenants + shared user survived); red-proofs (ack-gate, partial-failure resumability) + orchestration/store/offsite/render tests | External teardown FIRST, DB purge LAST, every leg idempotent; refuses while any host row exists; separate escrow-custody ack; clears claim (fresh code next onboarding); keeps the offsite tier CHOICE, drops provisioned fields. **Live-clicked 2026-07-18** (twice, by Viktor) — this supersedes the earlier "not live-clicked / Hetzner delete unit-tested only" note. **R-25b CLOSED (hub v0.69.0, 2026-07-21):** the Danger-zone DELETE is now the guided full-teardown cascade that runs this very sequence as its middle leg — see the row below |
 | **Customer DELETE cascade** (top lifecycle tier): one guided operator action → `hosts → RESET → residue → purge`; host rows deleted (custody DEMOTED), full external teardown (Hetzner repo destroyed, PBS namespace/token revoked, tunnel + zone removed), then the customer record and ALL escrow ciphertext purged | hub v0.69.0 | **UNIT-PROVEN; live leg PENDING** | `hub/internal/web/customer_delete_test.go` — leg ORDER observed from inside leg 2 (hosts already gone, customer row still present, custody still retained); 9 fail-closed gate cases each asserting zero mutations + zero external calls + no journal row; resume-after-external-failure converges; `purgeEscrow` custody semantics; preview leaks no secret. **5 red-proofs** (ack gate, stale-preview gate, ONLINE-host gate, leg order inverted, `purgeEscrow=true`) | Three acknowledgements + typed customer-id + stale-preview check + ONLINE-host refusal, ALL before any write. Ruling-3 preserved BY CONSTRUCTION (leg 2 never sees a host row); custody purged EXACTLY ONCE, in leg 3. **Coupling:** hub-only — no agent/controller/catalog change; the cascade calls the same service paths as manual host-delete and standalone RESET, so their rules move together. **v0.70.0 (2026-07-21):** added the **residue** leg — `GetCustomers()` is REPORT-derived, so before it a fully deleted customer stayed on the Customers list and its report stream kept the staleness/offsite checkers alerting (live: `demo-vm-felhom` deleted 07-18, still emailing `offsite_stale` on 07-21). The leg also purges the credential-bearing `appliance_registrations` + `selfbind_tokens`. **Ghost customers (config row already gone) are now deletable** — 404 means "nothing here", not "no config row"; the Hetzner/descriptor legs record `skipped_no_config`. **Gap:** the end-to-end live leg on a scratch customer (external Hetzner teardown observed from outside) is not yet run |
@@ -52,7 +102,7 @@
 | App lifecycle: start/stop/restart/update/logs/remove/redeploy | controller | **PROVEN-LIVE** | `CAMPAIGN-2` T-LIFECYCLE (stop/start/restart/update/logs); remove live in `CAMPAIGN-3` | Redeploy-after-remove edge remains open (T-REMOVE-REDEPLOY never cleanly passed — stale dryrun journal); non-pilot-critical |
 | Protected infra stacks can't be stopped/removed from UI | controller | **PROVEN-LIVE** | `CAMPAIGN-nomercy` + `RERUN-p1p3` T-SEC-PROTECTED (refuse stop/remove, stay Up) | (Cited `CAMPAIGN-2` T-SEC-PROTECTED was a stale-dryrun FAIL — corrected to the runs with a real server-side refusal) |
 | Catalog sync (git, 15 min) + orphan lifecycle + validation choke point (bad `backup:` block degrades to legacy, loudly) | controller v0.132, catalog | **PROVEN-LIVE** | `CAMPAIGN-2` T-SYNC-IDEMPOTENT; v0.132 LoadMetadata red-proofs | |
-| Lemez-egészség felügyelet: per-disk SMART kártya („Lemezek állapota") + degradáció-riasztás (Rendben/Figyelmeztetés/Hiba/Nincs adat) | agent v0.94.0→**v0.95.0**, controller v0.169.0→**v0.171.0**, hub v0.73.1 | **PROVEN-LIVE (healthy path + delivery)** | **2026-07-25 (v0.95.0 + v0.171.0 — the SMART-coverage fix):** the card on guest 9201 now shows BOTH real disks with **real verdicts + human model labels** — **„AirDisk 512GB SSD" → Rendben (34°C)** (the system SSD, via LVM/dm resolution) and **„TOSHIBA MQ04ABF100" → Rendben (30°C)** (the USB, via union-path SMART). `/disks` carries `smart.health=PASSED` + `model_name` for both. This reverses the 2026-07-24 „Nincs adat on a raw UUID" state (`SPIKE-smart-coverage-2026-07-25.md` had proven both disks answer `smartctl -a -j` PASSED but the agent never asked). Prior: verdict table (+≥90 red-proof); check first-run/degradation/recovery/UNKNOWN tests; hub allowlist test. **Notification pipeline PROVEN-LIVE 2026-07-24** — a `disk_health_degraded` POST (the exact `notify.PushEvent` wire call) was **400-rejected by hub v0.73.0** and **200-accepted + „Operator email sent" by hub v0.73.1** | No new smartctl load; feature-detect by payload presence → **MinAgent floor unchanged**; no sudoers/`-d sat` change. **No global banner** (deliberate). Agent v0.95.0 fixes: union-path SMART (Fix B) + LVM/dm whole-disk resolution incl. the builtin `local` on the LVM root (Fix A, SMART-only — never touches backing/durable_id) + `model_name` capture. **A live FAILING/Figyelmeztetés verdict still needs a genuinely degrading disk** (the demo disks are healthy) — that arm stays unit+red-proof covered. **SMART history/trending (hub-side) PARKED** (ROADMAP R-73) |
+| Lemez-egészség felügyelet: per-disk SMART kártya („Lemezek állapota") + degradáció-riasztás (Rendben/Figyelmeztetés/Hiba/Nincs adat) | agent v0.94.0→**v0.95.0**, controller v0.169.0→v0.171.0→**v0.215.0**, hub v0.73.1 | **PROVEN-LIVE (healthy path + delivery + the severity wire).** **IMPLEMENTED, NOT proven-live: the Hiba-from-counters path** (v0.215.0) — it has never fired on real hardware, only against the committed fixture's values in unit tests (**R-332**) | **2026-07-25 (v0.95.0 + v0.171.0 — the SMART-coverage fix):** the card on guest 9201 now shows BOTH real disks with **real verdicts + human model labels** — **„AirDisk 512GB SSD" → Rendben (34°C)** (the system SSD, via LVM/dm resolution) and **„TOSHIBA MQ04ABF100" → Rendben (30°C)** (the USB, via union-path SMART). `/disks` carries `smart.health=PASSED` + `model_name` for both. This reverses the 2026-07-24 „Nincs adat on a raw UUID" state (`SPIKE-smart-coverage-2026-07-25.md` had proven both disks answer `smartctl -a -j` PASSED but the agent never asked). Prior: verdict table (+≥90 red-proof); check first-run/degradation/recovery/UNKNOWN tests; hub allowlist test. **Notification pipeline PROVEN-LIVE 2026-07-24** — a `disk_health_degraded` POST (the exact `notify.PushEvent` wire call) was **400-rejected by hub v0.73.0** and **200-accepted + „Operator email sent" by hub v0.73.1** | No new smartctl load; feature-detect by payload presence → **MinAgent floor unchanged**; no sudoers/`-d sat` change. **No global banner** (deliberate). Agent v0.95.0 fixes: union-path SMART (Fix B) + LVM/dm whole-disk resolution incl. the builtin `local` on the LVM root (Fix A, SMART-only — never touches backing/durable_id) + `model_name` capture. **2026-08-14 — a genuinely failing disk HAS now been seen, and it broke three assumptions** (`audits/DIAG-smart-passed-trap-2026-08-14.md` + two committed fixtures: raw `smartctl -a -j` and 406 `smartd` lines from ST3000VX010 S/N Z6A07P2G). **(1)** `smart_status.passed` is STRUCTURALLY incapable of failing on unreadable sectors — attrs 187/197/198 all carry `thresh: 0` and a normalized value floors at 1 — so the drive read PASSED at 352 pending sectors and 1001 uncorrectable reads. **(2)** The alert it did produce carried severity `"warn"`, which the hub coerces to `info` and never emails: **the counterfactual is ZERO emails about this drive** (R-328, fixed controller v0.215.0, and the `warning`-vs-`warn` pair proven side by side in `notification_log` on 2026-08-14 — `sent` vs no row at all). **(3)** The old check spoke once and forgot on restart, so between 8 and 352 sectors it emitted nothing. v0.215.0 adds the sustained/count/heat Hiba rules, persisted state and an hourly cadence. **The verdict half of that arm remains unit+red-proof covered only** — no live drive has reached Hiba from counters (R-332). **SMART history/trending (hub-side) PARKED** (ROADMAP R-73) |
 | App crashes → customer notified (one event per transition, no flapping spam) | controller v0.120, hub v0.48 | **IMPLEMENTED** | controller v0.120.0 (dead-app alerting, `app_start_failed`, one-event-per-transition red-proofs); `CAMPAIGN-3` F11 surfaced the gap | End-to-end crash→customer-email delivery never live-confirmed (6B deferred / 6C inconclusive: clean stop ≠ crash); anti-spam unit-proven |
 | Post-deploy optional config (API keys etc.) with restart | controller, catalog `.felhom.yml` | **IMPLEMENTED** | feature long-standing; config page renders (`CAMPAIGN-2` T-PAGE-ALL is GET-only) | The config-save+restart flow is exercised in no campaign (CAMPAIGN-3 explicitly skipped interactive app config). Demoted: T-PAGE-ALL is a page-render smoke test, not this flow |
 | Backup classification: 13 bind-bearing apps carry mandatory/optional/excluded classes | catalog, controller v0.132–133 | **PROVEN-LIVE** | `SPIKE-backup-classification-2026-07-14`, `CAMPAIGN-6D/6E` | Remaining ~39 apps are legacy-class by design (unit-only offsite) |
@@ -76,7 +126,7 @@
 | Whole-guest backup lands OFF the guest's own physical device; a single-drive box is recorded **DEGRADED** rather than silently normal (installer Case A/B) | agent v0.113, host-install v1.22.0 | **PROVEN-LIVE** | `E2D-fresh-vm-2026-07-29` C1 (real 1.22.0 install, rc=0, `Day-0 provision SUCCESS`) + C2 (both DEGRADED lines verbatim, `local_backup_target=local`, install did not abort) | Case A (a second drive already present at install) has never fired naturally — only Case B has |
 | Nightly DB dumps (postgres/mariadb autodiscovery), atomic writes | controller v0.118 | **PROVEN-LIVE** | `CAMPAIGN-2` T-BAK-FULL (pg+mariadb autodiscovered); atomicity `CAMPAIGN-6B` P4 + `CAMPAIGN-6E` B1/B2 (SIGKILL mid-write → only `.tar.tmp` touched, last-good byte-unchanged); DB restore `CAMPAIGN-6D` P-FAB | (Cited `CAMPAIGN-3` F7 is the *finding* of non-atomic writes, and T-RST-DB was auth-hollow — corrected to the 6B/6E fix-proofs.) T-6E-1 dir-fsync asymmetry (LOW) → R-10 **DB replay route → `07-backup-architecture.md` §8 row 3** |
 | Tier-2 secondary-drive copy: class-driven legs, v2 relpath layout, NAS-target exclusion, safe-remove boundary | controller v0.135 | **PROVEN-LIVE** | `CAMPAIGN-6E-2026-07-15` (P-TIER2 deep-4 PASS), `CAMPAIGN-6C` | **Route + RTO → `07-backup-architecture.md` §8 rows 1, 2, 4, 5.** The matrix records that the copy's `recovery-unit/` mirror is read by no path (→ R-102) |
-| Offsite (restic → Hetzner Storage Box): mandatory class only, raw-data quota, enlargement gate, retention regrouping | controller v0.134, agent, hub | **PROVEN-LIVE** | `CAMPAIGN-6D-2026-07-15` (mandatory-only P-IMMICH; enlargement gate fired at real 50GiB quota P3-DELIVERY); `VALIDATION-offbox-storagebox-2026-07-09` (byte-perfect round-trip) | Raw-data quota (SP-1) + retention regrouping (SP-2) are `SPIKE-restic-snapshot-shape` **dry-run** verdicts — mechanism validated, not fired in a live product run; only the enlargement gate is live-fired. **Reinstall-continuity (controller v0.142.0, 2026-07-17):** a recreated data volume that orphaned the repo (new passphrase can't open the old keys) is now CLASSIFIED (`wrong password or no key found`) → explicit ORPHANED card + event (not nightly-spam) + a move-aside (never-delete) reset (unclaimed auto / claimed confirm), instead of a raw nightly restic error. Fake-based scenarios + red-proofs. **The live leg FIRED on its own during the 2026-07-18 rehearsal** (`tests/VALIDATION-n100-rehearsal-2026-07-18.md`, S7): after a RESET + re-enable, the first offsite run hit the previous lifecycle's ciphertext and the guard **classified it, pushed `offbox_repo_orphaned`, skipped the run and showed the card (16:58:14)** rather than nightly-spamming a raw restic error; the operator-confirmed reset then **moved the repo aside (never deleted) to `.orphaned-20260718` and re-initialised (16:59:26→16:59:32)**, and the next run produced 2 snapshots / 48.717 MiB. The guard behaved exactly as designed — **the finding is that it had to fire at all** (R-32: RESET destroys custody, so the ciphertext it leaves behind is dead by design and should be purged, while the move-aside guard stays correct for reinstall-WITHOUT-RESET). `DIAGNOSE-offbox-repo-orphaned-2026-07-17` **Route + RTO → `07-backup-architecture.md` §8 rows 4, 10, 12, 15** (incl. the R-95 delete exposure and the R-104 stale-lock defect) |
+| Offsite (restic → Hetzner Storage Box): mandatory class only, raw-data quota, enlargement gate, retention regrouping | controller v0.134, agent, hub | **PROVEN-LIVE** | `CAMPAIGN-6D-2026-07-15` (mandatory-only P-IMMICH; enlargement gate fired at real 50GiB quota P3-DELIVERY); `VALIDATION-offbox-storagebox-2026-07-09` (byte-perfect round-trip) | Raw-data quota (SP-1) + retention regrouping (SP-2) are `SPIKE-restic-snapshot-shape` **dry-run** verdicts — mechanism validated, not fired in a live product run; only the enlargement gate is live-fired. **Reinstall-continuity (controller v0.142.0, 2026-07-17):** a recreated data volume that orphaned the repo (new passphrase can't open the old keys) is now CLASSIFIED (`wrong password or no key found`) → explicit ORPHANED card + event (not nightly-spam) + a move-aside (never-delete) reset (unclaimed auto / claimed confirm), instead of a raw nightly restic error. Fake-based scenarios + red-proofs. **The live leg FIRED on its own during the 2026-07-18 rehearsal** (`tests/VALIDATION-n100-rehearsal-2026-07-18.md`, S7): after a RESET + re-enable, the first offsite run hit the previous lifecycle's ciphertext and the guard **classified it, pushed `offbox_repo_orphaned`, skipped the run and showed the card (16:58:14)** rather than nightly-spamming a raw restic error; the operator-confirmed reset then **moved the repo aside (never deleted) to `.orphaned-20260718` and re-initialised (16:59:26→16:59:32)**, and the next run produced 2 snapshots / 48.717 MiB. The guard behaved exactly as designed — **the finding is that it had to fire at all** (R-32: RESET destroys custody, so the ciphertext it leaves behind is dead by design and should be purged, while the move-aside guard stays correct for reinstall-WITHOUT-RESET). `DIAGNOSE-offbox-repo-orphaned-2026-07-17` **Route + RTO → `07-backup-architecture.md` §8 rows 4, 10, 12, 15** (incl. the R-95 delete exposure and the R-104 stale-lock defect). **2026-08-04 (R-193/R-197, `audits/SPIKE-offsite-credential-recovery-2026-08-04.md`) — the row is NOT overclaiming and the guard is not the gap; the CADENCE is.** This row already recorded that a recreated data volume orphans the repo, and the spike confirms the mechanism at source: `WriteOffboxSecrets` (`offbox.go:392`) mints a fresh 256-bit repo password whenever `<DataDir>/offbox/repo_password` is absent, and **no automatic path ever consults the escrowed one** — `InjectOffboxPassword` has exactly one caller, a web form a human pastes into. What was NOT recorded is that this now fires on an **ordinary, planned, unattended guest rebuild**, on every box: measured on BOTH demo boxes 2026-08-03/04 by comparing `host_escrow.restic_pw_sha256` against `host_escrow_superseded.restic_pw_sha256` (demo-hp `8e03eddf…`→`8a9e33aa…`, demo-felhom `48741892…`→`c60c8bc7…`), orphaning **15 snapshots / 40.9 MB** and **36 snapshots / 1.14 GB** respectively. **demo-felhom is the important half:** it kept its DELIVERY (a stale staged secret restored the target in 76 s) and lost its REPOSITORY anyway, with **nothing marking the escrow stale for 13 h** — `escrow_stale` is wired to `ReissueCredentials`, the one path that does NOT change the repo password (**R-196**), and absent from the rebuild path that does. Status unchanged: the classify-and-move-aside guard remains PROVEN-LIVE and correct, and is predicted (not yet measured) to refuse the 2026-08-05 run on both boxes rather than start a silent fresh history |
 | Offsite restore: local-preferred scratch, unit-only default, full two-step, missing-only place-to-live | controller v0.134/134.1/135 | **PROVEN-LIVE** (2026-07-20) | `CAMPAIGN-6D` accept legs (immich end-to-end from offsite alone) | **2026-07-19:** `audits/DIAG-immich-restore-2026-07-19.md` finds **no offsite path loads a DB dump** — all three buttons are file-only (R-43). The mechanics in this row's title are each proven; the phrase "**immich end-to-end from offsite alone**" is what is contested, since a DB-indexed app cannot be reconstituted by any offsite action. **RULED 2026-07-19 (Viktor): 6D's destruction hit the FILE TREE ONLY — the database survived in its named volume** (`immich_postgres_data` is a named volume in both the v2 and v3 template eras), so "immich end-to-end from offsite alone" **overclaimed scope**: the file half was proven, the DB half was never destroyed and therefore never restored. Row downgraded PROVEN-LIVE → **PARTIAL**, scope-corrected. Evidence: `audits/DIAG-immich-restore-2026-07-19.md` (no offsite path could replay a DB at all) + the P-FAB destructive re-import (the proven-replay evidence, on the LOCAL path). **2026-07-19, controller v0.148.0:** the DB half now exists in code (R-43 + R-44) and its replay reached a live box — but **round 2 found it aborts against a running app** (`audits/DIAG-immich-restore-round2-2026-07-19.md`, H4: the replay races immich's own schema repair; `clip_index` recreated by the app 2 s before the dump's CREATE INDEX). **2026-07-20, controller v0.153.0: H4 IS CLOSED (R-47)** — both restore paths now replay into a DB-ONLY window (`StartStackServices` brings up the database service alone; the app starts only after the replay exits 0), with a fail-closed refusal when a dump has no identifiable DB service. *(The earlier note here said "closes in v0.149" — that was wrong: v0.149.0 was the F3 dashboard `BackupStatus` fix. R-47 shipped in v0.153.0.)* **2026-07-20: the clean run HAPPENED** — endpoint-level supervised reconstitute of immich from snapshot `49e7cb46` (the very snapshot that aborted in round 2): stop → DB-service-only start → replay rc-0 → full start, no `already exists`, operation reported SUCCESS, immich's own DatabaseService logged `No schema drift detected` twice, 11 assets `active`, 4/4 containers healthy, 231 `public` indexes. **Operator confirmed the immich timeline renders correctly after the reconstitute** (screenshot held, 2026-07-20). Evidence: `felhom-controller/REPORT.md` §4b. **2026-07-20, LATER THE SAME DAY — the destructive drill RAN and the row now earns PROVEN-LIVE.** The operator deleted the photos in immich own UI **and emptied the trash** (the step whose absence makes a drill prove nothing — the round-1 lesson), then restored through the customer-facing UI. **`40 file(s) placed`** against the 6 of the earlier non-destructive run — the files were really gone and really came back — plus 1 DB dump replayed rc-0, 11 assets `active`, `No schema drift detected`, timeline confirmed by the operator. This is the destroy-then-recover proof the 6D downgrade asked for, and it was taken through the customer own buttons, not endpoint shortcuts. Evidence: `felhom-controller/REPORT.md` 4e **Route + RTO → `07-backup-architecture.md` §8 rows 3, 4** — the matrix also records that no offsite action unpacks the named-volume tars it captures (→ R-107) |
 | Manual `.fab` export/import: class-scoped capture, browser up/download, tunnel-proof chunking | controller v0.125/128/130/136 | **PROVEN-LIVE** | `CAMPAIGN-6D` P-FAB / Accept #1 (1.7 GB full circle, byte-identical, app boots); chunking `CAMPAIGN-6B` P2 (100 MiB via real CF edge, 120 MiB→413) | Chunking proven at the real CF edge via `curl --resolve`; the **rendered browser file-picker** upload leg is still Viktor's open full-circle test (6C ran it NOT-RUN). C6B-F1 was the 6B *finding*; fix verified in 6D |
 | Guest-loss DR: PBS restore with full-fidelity layout from archive, restore-test verification | agent v0.75/0.76, PBS | **PROVEN-LIVE** | `CAMPAIGN-2` T-P9-DESTROY-RESTORE (whole-guest `pct restore` of 9201 → running+healthy) + T-PBS-VERIFY (`verify_state: ok`, 13 snapshots); `DRILL-GL6-2026-07-08` Phase 0d (restore-test `mount_parity: ok`) | (Cited `VALIDATION-newbox-restore` is offbox **restic** file-restore, wrong tier — corrected.) Real **offsite** guest-loss round-trip still R1-blocked → S5 DR drill **Route + RTO → `07-backup-architecture.md` §8 rows 6, 8, 9** — measured 84–112 s local / 1101 s PBS into a scratch guest; a restore to a DIFFERENT host is unmeasured |
@@ -86,7 +136,7 @@
 | An app can be **withdrawn from the catalog without orphaning the customers running it** (available / hidden / abandoned) | controller v0.158.1, catalog metadata | **PROVEN-LIVE** (2026-07-21) | TASK-F Part 1. Verified on 9201 through the real endpoints: `lifecycle: abandoned` arrived via the normal catalog sync; plant-it renders 0 times on the Alkalmazások page (control app renders 10); a direct `POST /api/stacks/plant-it/deploy` → **HTTP 409 "Ez az alkalmazás jelenleg nem telepíthető."**; the app page carries the permanent notice and offers no Telepítés button. `felhom-controller/REPORT.md` (2026-07-21) | Deployed instances keep FULL function in every state — lifecycle governs what is offered, never what runs. Orphan detection deliberately never sees the field (red-proofed): a withdrawn template stays in the catalog tree, or every deployed instance would read `Elavult` and be offered deletion. Unknown values fail OPEN; the deploy gate fails CLOSED. R-57 |
 | Box survives a **site/network change** (relocation, different subnet, DHCP re-lease) with the control plane intact | agent v0.96.0 (island NIC), host-install v1.19.0, controller (unchanged), bootstrap | **PROVEN-LIVE (2026-07-25)** | **R-50 SHIPPED and deployed to the whole fleet.** The control plane now rides a host-internal, portless island bridge (`vmbr9`, `169.254.253.1/30`↔`.2/30`) with a fixed private address that no LAN/DHCP/site move can invalidate. Proven end-to-end: the spike's F1 replay (renumber the LAN → agent stays bound on the island, control plane HTTP 200; the LAN-literal contrast reproduces the original `bind: cannot assign requested address` daemon-death) + cold-reboot survival (`SPIKE-island-bridge-2026-07-25.md`), the migration runbook run verbatim (`RUNBOOK-island-migration.md`), a fresh provision auto-attaching the island `net1` (A4), and the live migration of **both demo boxes** (demo-hp + demo-felhom, 2026-07-25) — island `/storage` HTTP 200, LAN DNS pinned to the LAN IP (Finding-1), **apps served throughout (0 container restarts)**, hub reporting 0.96.0. **Origin:** `audits/AUDIT-vacation-remote-ops-2026-07-20.md` — the real relocation where the agent's LAN-literal bind took storage/PBS/quiesce/restore-test/DR down silently; that is now structurally impossible on a migrated box | **Fleet: DONE.** Remaining: **R-74** — bring the island to Peti's 2-node cluster (SDN vnet / bridge parity), its own supervised runbook. Related historical: R-51 (dead-primary alerting), R-52 (boot desired-state reconciliation), both shipped |
 | **The customer is warned BEFORE a filesystem fills** — per filesystem, in Hungarian, naming the drive and the free space, edge-triggered | controller **v0.191.0/.1/.2**, hub **v0.89.0** (R-167, decision D-c) | **PROVEN-LIVE (2026-08-02)** | `audits/SPIKE-r165-mp1-merge-2026-08-02.md` (context) + `felhom-controller/REPORT.md`. Exercised on guest 9201 against a REAL filesystem (`/mnt/sys_drive` filled with `fallocate`): **`disk_warning` at 90% used / 4.7 GB free** → hub `notification_log` `customer | disk_warning | sent` with the dynamic Hungarian rendered; grown to 1.7 GB free → **`disk_critical`** → `customer | sent`; file removed → `critical → ok … cleared silently, re-armed` and the persisted state emptied. **Exactly two events across three boots** — the boot in between produced none, which is the edge trigger holding | **Nothing warned before this.** The only prior signal was the healthcheck's generic `health_degraded` at 90%, for REGISTERED STORAGE PATHS ONLY — it never looked at the docker area or the system-data area, never gave a free-byte figure and never named a drive. **The two event types already existed with NO PRODUCER** (`disk_warning`/`disk_critical`: allowlisted, copy'd, in `DefaultEnabledEvents`, checkbox'd) — the **sixth** *built-but-never-wired* instance here; this ships their producer rather than a seventh near-duplicate type. **Two threshold terms, whichever trips first, and the live proof vindicated the design:** the critical crossing fired on the FREE-BYTE term (1.7 GB) at only **91%** used — a percentage-only rule would have missed it. The hub's generic `customerMessages` entries were REMOVED, because `FormatCustomerEmail` prefers the entry over the message and would discard the label and figures. **Known gap → R-177:** there is no operator-triggerable run-now path; the check is daily 03:30 + once at startup, so confirming a cleared warning on a support call needs a controller restart or a wait |
-| **A failed per-app Tier-1 backup reaches the OPERATOR — EVERY failing app, in ONE mail per run, and every failure recorded whether or not it is mailed** | controller **v0.194.0**, hub **v0.90.1** (R-158 → R-167 → **R-182**) | **PROVEN-LIVE (2026-08-03)** | `felhom-controller/REPORT.md`. Two real capture failures on guest 9201 (`mkdir …/backups: permission denied`) → both accepted and stored by the hub, `operator | recovery_unit_capture_failed | sent`, and the positive observable **`customer | recovery_unit_capture_failed | skipped | operator_only`** read from the hub's `notification_log`. One event per app, loop continuing | **Before this the failure was a `[WARN]` line and nothing else** — the manager carried three notify seams and none for the unit capture, so `/backups/apps`, the page you open to ask whether ONE app is backed up, was the one page that never said. **Deliberately NOT `backup_failed`:** that type is customer-enabled by default and carries Hungarian copy, so reusing it — which R-158's own proposal said — would email the customer about a failure they cannot act on. **D-c routes it to the operator and overrides the proposal.** Operator-only is enforced by `notify.operatorOnlyEvents`, NOT by the absence of a `customerMessages` entry (the v0.78.0 defect); a red-proof removing the register entry shows the customer receiving it. **ROW REWRITTEN 2026-08-03 (R-182) — the 2026-08-02 claim was TRUE OF ONE APP AND FALSE OF THE REST, and it is worth saying which.** The signal existed and worked; what it did not do was scale past the first failing app. Measured: nine per-app events reached the hub in one day and **two** operator mails went out, because the cooldown key is `customerID:eventType(+tier)` and this type carries `app` but no `tier` — so the first refused app took the hour and the rest were dropped **before `LogNotification`**, leaving no row on any channel. The old row said "One event per app, loop continuing", which was true of what the CONTROLLER emitted and not of what the operator received. **Now:** the per-app event is the RECORD (hub `recordOnlyEvents`: stored + logged every time, never mailed) and `backup_run_failures` is the NOTIFICATION — one mail per run listing every failed app, its leg and its reason, with the counts and free space. A suppressed operator event of ANY type now leaves a `suppressed` row naming its key. **Proven live on demo-hp 2026-08-03** by a real 64.6 GiB fill (thin pool held 30.78 → 30.78): `notification_log` shows `recovery_unit_capture_failed | operator | recorded` ×2, `backup_run_failures | operator | sent` ×1 naming BOTH apps, and `backup_run_failures | customer | skipped | operator_only`. A second run in the same hour produced a second digest; after freeing space a run completed with 2 volume dumps and **no** digest. The suppression row proved itself on an unplanned event — `disk_critical | suppressed | key=demo-hp:disk_critical` — a collapse that yesterday would have left nothing at all. **The digest's silence is safe only because** the hub's deadline check raises `expected_backup_missed` from report freshness independently of any mail (`monitor/deadline.go:396,417`); that check is load-bearing for this row |
+| **A failed per-app Tier-1 backup reaches the OPERATOR — EVERY failing app, in ONE mail per run, and every failure recorded whether or not it is mailed** | controller **v0.194.0**, hub **v0.90.1** (R-158 → R-167 → **R-182**) | **PROVEN-LIVE (2026-08-03)** | `felhom-controller/REPORT.md`. Two real capture failures on guest 9201 (`mkdir …/backups: permission denied`) → both accepted and stored by the hub, `operator | recovery_unit_capture_failed | sent`, and the positive observable **`customer | recovery_unit_capture_failed | skipped | operator_only`** read from the hub's `notification_log`. One event per app, loop continuing | **Before this the failure was a `[WARN]` line and nothing else** — the manager carried three notify seams and none for the unit capture, so `/backups/apps`, the page you open to ask whether ONE app is backed up, was the one page that never said. **Deliberately NOT `backup_failed`:** that type is customer-enabled by default and carries Hungarian copy, so reusing it — which R-158's own proposal said — would email the customer about a failure they cannot act on. **D-c routes it to the operator and overrides the proposal.** Operator-only is enforced by `notify.operatorOnlyEvents`, NOT by the absence of a `customerMessages` entry (the v0.78.0 defect); a red-proof removing the register entry shows the customer receiving it. **ROW REWRITTEN 2026-08-03 (R-182) — the 2026-08-02 claim was TRUE OF ONE APP AND FALSE OF THE REST, and it is worth saying which.** The signal existed and worked; what it did not do was scale past the first failing app. Measured: nine per-app events reached the hub in one day and **two** operator mails went out, because the cooldown key is `customerID:eventType(+tier)` and this type carries `app` but no `tier` — so the first refused app took the hour and the rest were dropped **before `LogNotification`**, leaving no row on any channel. The old row said "One event per app, loop continuing", which was true of what the CONTROLLER emitted and not of what the operator received. **Now:** the per-app event is the RECORD (hub `recordOnlyEvents`: stored + logged every time, never mailed) and `backup_run_failures` is the NOTIFICATION — one mail per run listing every failed app, its leg and its reason, with the counts and free space. A suppressed operator event of ANY type now leaves a `suppressed` row naming its key. **Proven live on demo-hp 2026-08-03** by a real 64.6 GiB fill (thin pool held 30.78 → 30.78): `notification_log` shows `recovery_unit_capture_failed | operator | recorded` ×2, `backup_run_failures | operator | sent` ×1 naming BOTH apps, and `backup_run_failures | customer | skipped | operator_only`. A second run in the same hour produced a second digest; after freeing space a run completed with 2 volume dumps and **no** digest. The suppression row proved itself on an unplanned event — `disk_critical | suppressed | key=demo-hp:disk_critical` — a collapse that yesterday would have left nothing at all. **The digest's silence is safe only because** the hub's deadline check raises `expected_backup_missed` from report freshness independently of any mail (`monitor/deadline.go:396,417`); that check is load-bearing for this row  **⚠ CHECKED 2026-08-08 (R-258) AND THIS ROW WAS NOT CLAIMING SOMETHING UNTRUE — but the adjacent thing WAS false and the row's own narrative invites the wrong reading.** This row is about the OPERATOR notification path (`notification_log`, the per-run digest) and it claims nothing about what `/backups/apps` DRAWS. Independently of it, the page's per-app tier-1 tick was wrong until controller v0.210.0: it went green on the mere presence of a restore point and turned red only when the box's most recent DB dump — **whichever app it belonged to** — had failed. So an app whose own backup failed could show a tick while this row's operator mail correctly reported the failure; the two halves disagreed, and only the operator half was true. The tick now reads THIS app's own dump result and shows **no icon** when there is no result for it. Reading this row as evidence that the customer's page answers "is ONE app backed up" would have been wrong for five days. |
 | **A local backup is bounded by the box's FREE SPACE, not by a partition set at build time** — the appliance ships ONE data volume, and a capture that would exhaust it is refused per app rather than allowed to stop the container runtime | golden `build-golden.sh` **v3.0.0**, agent **v0.120.0**, controller **v0.193.1** (R-165 / D-a / B2, completed by R-181) | **PROVEN-LIVE (2026-08-03) — BOTH halves** | `REPORT.md` (R-178 reinstalls) + `audits/SPIKE-r165-phase0-2026-08-03.md` (P1/P2/P3) + the bake transcript. **The golden bake is real evidence and is cited as such:** `build-golden.sh v3.0.0` produced `including mount point mp0 ('/var/lib/felhom')` with **no `mp1` line at all**, and its own guards printed `/var/lib/docker is a real mount`, `/mnt/sys_drive is a real mount` and `both paths are ONE filesystem`. Archive published (registry HTTP 200, sha `54e2a4c4…`). The B2 floor is unit-proven with 3 red-proofs and live on 9201 | **The row's FIRST clause is now PROVEN-LIVE; its SECOND is not, and they are separated deliberately.** **Proven (R-178, 2026-08-03):** *"a local backup is bounded by the box's FREE SPACE, not by a partition set at build time"* — both demo boxes reinstalled from this golden, by two different supply paths (demo-hp `--golden <local volid>`; demo-felhom the normal manifest route with **`verified sha256 54e2a4c431daf580… matches the hub manifest`**), each showing `mp0` at `/var/lib/felhom` with **no `mp1`**, both consumer paths real mounts on ONE filesystem (`stat -c %d` = `64519` on all three), 3/3 reboots each, and claim → deploy → backup → **restore** with a planted marker returning byte-identical. Space available to a recovery unit measured at **65 GiB / 233 GiB**, against the **19 GiB / 45 GiB** those boxes' `mp1` slices offered. **NOT proven — and measured FALSE in part:** *"a capture that would exhaust it is refused per app rather than allowed to stop the container runtime"*. The floor fired live for the first time (demo-hp 06:40:03) and does refuse per app, delete nothing, and alert — **but it is checked only in `captureAllRecoveryUnits`, while `runVolumeDumps` writes the bulk with no floor check at all**, so the leg that exhausts the volume is the unguarded one; and the refusal's claim that the previous unit is untouched was measured false (a 182,272 B dump replaced by 2,147,666,432 B under a manifest still dated 06:34:26). → **R-181, CLOSED THE SAME DAY (controller v0.193.0 + v0.193.1) and the second half is now PROVEN-LIVE TOO.** The reserve became a **per-app, per-run ADMISSION decision** taken before the app's FIRST write and covering all three legs (DB dump, volume dump, capture) — they write under one per-app root, which is what lets one verdict cover them honestly — and it gained a **size term**, so an app is no longer admitted at 96% and then allowed to write 2 GB. **Re-proven by filling demo-hp deliberately, once for EACH term, using the method that found the defect.** *Headroom @ 08:59:46* (906 MB free / 99%): both apps refused, **the whole `backups/primary` tree byte-identical — `TREE_SHA` 111d1760c18d3440f700634ab325f8b8 before and after**, opengist's tar still at its original 182,272 B; **no `Stopping <app> for safe volume dump` line at all**, which is the positive-by-absence observable that matters because that line IS present in the 08:58 baseline run; 0 volume dumps; one alert per app, HTTP 200. Space freed, re-run @ 09:01:33 → both captured normally. *Size @ 09:03:00*, reproducing the original sequence with a real 2 GiB file in opengist's volume (previous tar **2,147,666,432 B**, the exact figure the defect was measured at) and the filesystem at **91% used / 2.9 GB free — both headroom terms deliberately clear**: opengist refused `(size)` while **privatebin was ADMITTED and dumped normally**, proving the term is per-app rather than a global halt. **The refusal's wording was NOT weakened to fit** — the behaviour moved so the wording became true, and it is verified by tree fingerprint rather than by reading the log line, which is what lied. The `fallocate` instrument was re-proven on the rebuilt box before use (5 GiB step moved guest `df` while thin-pool `data_percent` held **36.83 → 36.83**), and teardown returned the pool to **29.43%**, below its own baseline. The golden **is now VOUCHED** (2026-08-03, hub `Artifact manifest set: … golden=0.192.0`), so fresh installs pick up the merged layout. Every box in the field that has not been reinstalled is still on the SPLIT layout and is unaffected: nothing assumes the merged shape at runtime, the controller's system_data_path is a path rather than a volume, and agent v0.120.0 FOLDS the retired `-sysdata-grow` into the single grow so an older `felhom-host-install.sh` still provisions the same total capacity |
 | Soft-quota: usage bar, pre-push enlargement block, customer notification | controller v0.109/134, hub v0.41/55 | **PROVEN-LIVE** | 6D/6E; hub OffsiteChecker | |
 | **A customer (not the operator) performs a restore via UI alone** | all | **MISSING** (as evidence) | — | Alpha will produce this; script it into R-3. **2026-07-19:** the C6 evidence attempt ran and found a **product gap instead of evidence** — `audits/DIAG-immich-restore-2026-07-19.md`. A customer-driven UI restore of a DB-indexed app cannot currently succeed (R-43 file-only restore, R-44 stale dump), so this row cannot flip until those close. Row stays MISSING **by finding, not by absence of attempt** — the rehearsal system working, not failing. **2026-07-19: the blocking product gaps are CLOSED in controller v0.148.0** (R-43 + R-44 shipped), so this row is now blocked only on the evidence run itself, not on missing capability. It flips the moment the §9 acceptance produces screenshots + the outcome flash + a snapshot ID. **2026-07-19 round 2 — PARTIAL EVIDENCE ONLY, row NOT flipped** (`audits/DIAG-immich-restore-round2-2026-07-19.md`): a deliberate run from snapshot `49e7cb46` did recover all 11 assets (`status=active`, files resolve), but the operation **reported failure** and left immich reporting schema drift, because the replay aborted against the running app (H4). Photos back ≠ clean acceptance. **2026-07-20: H4 closed in controller v0.153.0 (R-47) on BOTH paths, AND THE EVIDENCE RUN HAPPENED.** *(The "closing in v0.149" wording above was wrong — v0.149.0 was the F3 dashboard fix; R-47 shipped in v0.153.0.)* The C6 drill ran end-to-end **through the UI**: photos deleted, **trash emptied**, the full files+database restore pressed on `/backups/restore`, 40 files placed + 1 DB dump replayed rc-0, 11 assets back, no drift, timeline visually confirmed. The method note below is now DEMONSTRATED, not merely written down. Evidence: `felhom-controller/REPORT.md` 4e. **Residual: the run was performed by the OPERATOR, not by a customer** — for this row literal wording the alpha still owes one genuinely customer-driven pass, but no product gap blocks it. Method note for R-3's script: deleting in an app's own UI usually means *trash*, not deletion, so a drill written that way merges 0 files, flashes success and proves nothing — a real drill must empty the trash **and** verify the app's *content*, not the file count **Lane split → `07-backup-architecture.md` §3**: this row is Lane 1 (customer, unassisted). §8 rows 1–5 are the routes it would exercise |
@@ -120,8 +170,9 @@
 | **Indítópult megosztás (vendég link)** — capability URL `/s/<token>` serves a standalone read-only guest launcher (no account, no admin session); optional per-share password; QR | controller v0.165.0 | **IMPLEMENTED** | 160-bit `crypto/rand` token, constant-time match (empty stored = disabled = byte-identical to the mux default 404); guest headers `noindex`/`no-referrer`/`no-store`; optional SEPARATE bcrypt share password + its own per-IP attempt map; signed cookie `HMAC(token`\|`passwordHash)` keyed with `session_secret` (rotate-token OR change-password invalidates all cookies); token redacted in logs (`/s/<redacted>`). Groups A–G (14 tests) + 3 red-proofs; **§13 endpoint-level live validation on 9201 all-pass** (`felhom-controller/REPORT.md` 2026-07-24). **Design ruling: member accounts SUPERSEDED by this capability-URL model; per-member tile visibility parked under the SSO arc (R-15).** | Full operator browser click-through + a validation doc pending → then PROVEN-LIVE. Accepted residuals: link-preview crawlers fetch once (noindex prevents indexing); reverse-proxy/CF access logs hold the path (ops-tier); the modal link carries the request Host (LAN-IP admin ⇒ LAN-IP link) |
 | Forgot dashboard password → instant reset code | controller v0.123, hub | **PROVEN-LIVE** | `DRILL-day0-take2-2026-07-12` F-15 (live re-run of the exact failure path: hash applied 1s after request, code accepted first try) | |
 | Multiple household users / per-person accounts | — | **MISSING** | — | Single dashboard password; acceptable for alpha → R-15 |
-| WireGuard base infra always-on; OOB operator access (felhom-sshd, /32 peer) | agent v0.72, hub v0.35 | **IMPLEMENTED** | `SPIKE-oob-wg-operator-peer-2026-07-05`, `SPIKE-felhom-sshd-2026-07-05` | Mutual-repair desired-state arc not built → R-13 |
+| WireGuard base infra always-on; OOB operator access (felhom-sshd, /32 peer) | agent v0.72, hub v0.35 | **IMPLEMENTED** | `SPIKE-oob-wg-operator-peer-2026-07-05`, `SPIKE-felhom-sshd-2026-07-05` | Mutual-repair desired-state arc not built → R-13. **CHECKED 2026-08-08 (R-260) and this row was NOT claiming something untrue** — it claims the capability is implemented, never that it is monitored, so no correction was owed. What WAS untrue is narrower and sat one layer down: **the hub's own OOB health check could not see whether the operator's key was installed.** `HostOOBRow` mirrored five of the agent's eight OOB fields, so `operator_key_configured` — emitted every heartbeat since agent v0.72.0, i.e. from this row's own vintage — was discarded by `encoding/json` on arrival, and `oobDegraded` returned `ok` for a box with felhom-sshd active, reachable, a valid config, a configured peer and **no operator key at all**. `operator_peer_configured`, which it did read, only says the peer IP is in desired-state — that OOB is MEANT to work, not that entry is possible. Fixed hub v0.99.0; the missing key now degrades and the alert NAMES it; a stanza too old to carry the field is reported distinctly and is never a silent ok. Pinned end-to-end from raw report JSON by `TestHostOOB_MissingOperatorKey_EndToEnd` and `TestHostOOB_NoKeyField_IsNotSilentlyOK_EndToEnd` |
 | The operator can see WHERE a managed host is — its LAN address and its WireGuard address, on the host page | agent **v0.119.0**, hub **v0.85.0** | **PROVEN-LIVE** (2026-07-31) | `audits/host-addresses-visible-2026-07-31.md` | Before this the LAN IP was **not reportable at all** — `HostMetrics` carried no address of any kind — and the WG IP existed only in `/offsite`'s peer table keyed by pubkey (peer→host, never host→peer). New wire field `addresses[]`, one row per (interface, address); `IsGlobalUnicast()` is the whole filter, chosen by MEASURING both demo boxes, and it needs no veth/fwbr denylist because that plumbing carries no IP. Rendered live on both 0.119.0 hosts matching their `ip addr` ground truth exactly. **Two honesty properties carry the risk and are both red-proofed:** WireGuard shows the hub ALLOCATION and whether the box CONFIRMS holding it (allocation alone cannot tell a live tunnel from a peer never applied), and an agent below 0.119.0 renders **UNKNOWN, never "no addresses"** — proven live on `drill-r50-0a4f9a` (0.113.0). **Not covered:** a two-LAN-bridge box and a real WG drift, neither of which exists to observe |
+| The operator can see whether a managed host's **guests still have working networking** — and **how often the watchdog had to repair them** | agent **v0.92.0** (emitter, 2026-07-21), hub **v0.104.0** (reader, 2026-08-13) | **IMPLEMENTED** | `backlog/OPEN-ITEMS.md` R-319; `hub/internal/web/hosts_guestnet_test.go` (7 tests, fixtures copied verbatim from `demo-felhom-8363b5`'s live `host_reports` row) | The agent emitted `guest_net` on every heartbeat for **twenty-three days** while the string occurred **nowhere** in `felhom.eu/hub/` — stored as raw text in `report_json`, read by nothing (R-260/R-264, the first of that census's readers to be built). **The fact that carries the risk is `heals_last_hour`, not `state`:** a guest the watchdog keeps repairing is healthy at every instant anyone looks, so rendering the state alone would give it a green tick — the failed-disk-drawn-as-a-healthy-empty-disk shape. `heal_succeeded` is decoded beside it, because six FAILED repairs is a guest that is down while six successful ones is a nuisance. **Unknown is never drawn as healthy:** three absences, three sentences (agent < 0.92.0; a capable agent that sent nothing; a guest whose own state the watchdog did not assert), and a malformed stanza degrades to unknown without a 500. **Three red-proofs, each mutation asserted applied by grep before its run**, including the one that matters — removing the unknown branches and watching a silent machine render as healthy. **Positive control that it is WIRED and not merely written: the wire-contract gate's checked-tag count rose 182 → 190** as the eight `guest_net` allowlist entries were deleted (an allowlisted tag is skipped, so leaving them would have meant these fields were never checked) | **IMPLEMENTED, not PROVEN-LIVE, and the distinction is the honest half.** Every scenario is proven against the real wire in tests, and the healthy case renders correctly for the live fleet — but **no machine has ever been observed with a climbing repair count on this card**, because neither demo box has needed a repair since the watchdog shipped. The signal this card exists for has therefore never been seen firing on hardware. It moves to PROVEN-LIVE the first time a real repair count is watched appearing. **No alarm was added, deliberately** (R-319): the incident behind this was about nobody being able to SEE the condition, and a new email on a fleet of two demo machines is untested noise — revisit when a third machine exists or when a count is seen climbing |
 | Break-glass management-plane recovery | agent v0.71, hub v0.84 | **IMPLEMENTED** | `runbooks/break-glass.md` | hub v0.84.0 adds an **operator-SESSION** retrieval path (host page → Console access → Reveal; `POST /hosts/{id}/reveal-recovery-credential`, CSRF-gated, writes a customer-visible `recovery_credential_revealed` event) beside the pre-existing **global-key** one (`GET /api/v1/admin/hosts/{id}/recovery-credential`), which is untouched and stays the route for when the hub UI itself is down. **The credential half is now PROVEN (2026-07-31):** the vaulted `demo-hp-bb76ea` password was verified against the box's own `/etc/shadow` hash AND minted a real PVE ticket — `POST /api2/json/access/ticket` → **HTTP 200, `root@pam`, 367-char ticket**, the exact API the login form submits to. Still IMPLEMENTED rather than PROVEN-LIVE overall, because the path has not been exercised on a REAL lockout (SSH was available throughout). Discovered during that check: the card's Copy button shipped `disabled` until a Reveal and silently no-opped, leaving ANOTHER host's password in the clipboard — fixed in hub v0.86.0. The vaulted secret is plaintext at rest → **R-133** |
 
 ## F. Notifications & monitoring
@@ -152,5 +203,6 @@
 | Per-customer offsite fill + staleness + freeze lever | hub v0.41 | **IMPLEMENTED** | `OffsiteChecker` (`hub/internal/monitor/offsite.go`): fill 90/95% vs soft quota, staleness >48h | No live-fired leg: `CAMPAIGN-offsite-overnight-2026-07-10` recorded no quota/fill/staleness emails, and the freeze write-block was **inconclusive** (only the Hetzner `readonly:true` API op succeeded). Demoted |
 | **Box-level Storage Box aggregate (total fill, Σ quotas, oversubscription alert)** | hub v0.64.0 (R-5) | **IMPLEMENTED** (data pipeline PROVEN-LIVE) | `monitor.OffsiteBoxChecker` — fetch-throttled Hetzner GET (1/15 min), fill (used/`storage_box_type.size`, 80/90%) + oversubscription (Σ shared+enabled ConfigJSON quotas / capacity, 2.0×), escalation-only operator alert on the customer-less `"pool-box"` scope; Offsite-tab panel + dashboard tile. **Phase-0-pinned** live shape (box 611714) + **live-computed in-cluster:** `0.2% full (2.6 GB of 1.00 TB), Σ shared quota 150 GB, oversub 0.15x`. Tests + 4 red-proofs; hub v0.64.0 REPORT | Two open legs: the **UI render** is unit-verified only (hub UI password-gated → no screenshot); the **alert emails** are unit + red-proof verified but NOT fired live (real pool nominal — a live-fire emails Viktor). Thresholds pending Viktor's ruling (named config keys). READ-ONLY (GET) |
 | **Operator sees PBS DR datastore fill at a glance (Offsite "PBS DR" tab + dashboard gauge)** | hub v0.65.0 + tenantsync v1.2.0 (R-5) | **IMPLEMENTED** (data pipeline PROVEN-LIVE) | The PBS DR datastore (`felhom-offsite` on ep0) fill — NOT a Hetzner box. **Option A:** a read-only `usage` op on the `felhom-tenantsync` ep0 forced command (twin of `fingerprint`; `df` on the datastore path — no customer_id, no admin token, NO mutation), polled by `monitor.PBSDRBoxChecker` (OffsiteBoxChecker clone; 15-min throttle; states ok/unavailable/degraded; fill 80/90% on the `"pbsdr-box"` operator scope). `/offsite` split into Restic + PBS DR tabs; two dashboard gauges. **Graceful: hub deploy ⟂ ep0 update** (ep0 ≤ v1.1.0 → gauge "n/a" until updated). **Phase-0-pinned** (`df` on ep0 PBS 4.2.3) + **live-computed in-cluster** (ep0 updated to v1.2.0 this session): `19.1% full (7.1 GB of 37.2 GB)`. 10 Go tests + a bash harness + 3 red-proofs; hub v0.65.0 REPORT | Open legs: **UI render** unit-verified only (hub UI password-gated); the **fill alert email** is unit + red-proof verified, NOT fired live (datastore nominal at 19%). Separate PBS threshold keys (default 80/90); no oversubscription (namespaces, not quotas). READ-ONLY |
+| **The hub reports LOSS OF VISIBILITY into either off-site store (not just how full it is)** | hub **v0.106.0** (R-339) | **IMPLEMENTED — deliberately NOT proven-live** | Both box checkers count consecutive failed fetch windows and emit `pbsdr_box_unreachable` / `offsite_box_unreachable` (severity `warning`) past a default 3 windows (≈30–45 min), each with a paired `*_recovered` all-clear routed via `recoveredPairedDownTypes` — required because the recoveries are severity `info`, which `severityNotifies` drops. Scopes stay customer-less (`pbsdr-box` / `pool-box`) → operator channel only. Fill logic untouched: a degraded read still drives no band transition. Evidence: `internal/monitor/box_reachability_test.go` + the cross-package wiring test in `internal/notify/`, which asserts an actual operator mail rather than a map entry. **Filed BECAUSE of a measured gap**, not a hypothesis: the 2026-08-18 ep0 outage ran 9 h 37 m with the hub silent | **The gap that remains is R-340**, and it is not small: the ep0 read is the `usage` op, which rides the LOCAL API daemon — the daemon that incident explicitly cleared — so this check would have shown GREEN for that entire outage. It closes "ep0 is unreachable as a host"; it does not close what actually happened. **No live or constructed outage has exercised the emit path**, and one cannot be manufactured against ep0 (Tier 2, protected) |
 | Secrets hygiene: bearer in k8s Secret, no secrets in git, single-quote credential store | hub v0.53, conventions | **IMPLEMENTED** | 07-13 closing bundle | |
 | Operator login password changeable from UI | hub v0.54 | **IMPLEMENTED** | 07-13 | |

documentation/architecture/01-topology-and-trust.md

@@ -1,5 +1,20 @@
 # Felhom Controller Architecture — Part 1: Topology & Trust
 
+> **How to read this document.** Two kinds of statement appear, and where this document marks them it
+> marks them like this — the same wording as `07-backup-architecture.md:11-17`, carried here on
+> 2026-08-22 (R-376) so a reader meets one convention and not eight:
+>
+> - **[DESIGN]** — a decision taken. Not derived from code; the code may not implement it yet.
+> - **[FACT]** — an observed property, carrying a `file:line`, a live command output or a citation.
+>
+> **Statements in this document are NOT yet all marked.** Marking them wholesale is a large judgement
+> exercise and a wrong mark is worse than none, so only what a session touches is marked (R-376).
+> **An unmarked statement therefore means "not yet classified", never "observed".** That ambiguity is
+> exactly what cost this project three sessions in August 2026: the hot/bulk placement decision sat
+> unmarked beside a marked `[FACT]`, and was read as an observation and reported as a defect.
+
+
+
 **Status:** draft (decisions from the topology/trust design sessions).
 **Platform facts** referenced here live in `docs/proxmox-platform.md`; this document
 records *Felhom's decisions*, not Proxmox behaviour.
@@ -147,9 +162,23 @@ credentials.
   at attach), role, encrypted credentials, schedule/retention. The agent creates the Proxmox
   storages, continuously checks presence/reachability, and reports per-target status (a
   disconnected target → actionable notification).
-- **App data placement is per-volume, not per-app:** `.felhom.yml` classifies each volume
+- **[DESIGN] App data placement is per-volume, not per-app:** `.felhom.yml` classifies each volume
   **hot** (DB/config/cache → fast storage, enforced) vs **bulk** (media/files → may be slow).
   A photo app's DB stays on SSD while its blobs go to the USB.
+
+  > **Marked [DESIGN] on 2026-08-22 (R-376), and the pointer is honest about what it can point at.**
+  > **This decision was never recorded as a decision anywhere** — it was established by reading, not
+  > by citation: it exists as this bullet and nowhere else, with no dated entry in the decision log
+  > and no `R-` row. A log entry was written on 2026-08-22 (`CONTEXT.md`, "App data placement is a
+  > DECISION") **to give it a home, not to claim it was decided then**; the choice is older than the
+  > entry and its original date is not on record.
+  >
+  > **What being unmarked cost.** The consequence of this bullet — that 40 of 53 catalogue templates
+  > declare no configurable path because they are all-hot — is stated as **[FACT]** at
+  > `07-backup-architecture.md:296-299`. A reader met a marked observation beside an unmarked choice
+  > and reasonably asked whether it *should* be so. **Between 19 and 22 August that reader called this
+  > decision a defect in four places** (R-370), and one session's work went into correcting the record
+  > rather than into the product.
 - **Backup scoping:** hot data (LXC rootfs) rides the guest `vzdump` → tiers + PBS. Bulk data
   on external mount points is **excluded** from the guest vzdump (per-mount `backup` flag) and
   gets its own per-volume policy (file-level to a tier, slower cadence — or explicitly *not*

documentation/architecture/02-controller-module-map.md

@@ -1,5 +1,20 @@
 # Felhom Controller Architecture — Part 2: Controller Module Map
 
+> **How to read this document.** Two kinds of statement appear, and where this document marks them it
+> marks them like this — the same wording as `07-backup-architecture.md:11-17`, carried here on
+> 2026-08-22 (R-376) so a reader meets one convention and not eight:
+>
+> - **[DESIGN]** — a decision taken. Not derived from code; the code may not implement it yet.
+> - **[FACT]** — an observed property, carrying a `file:line`, a live command output or a citation.
+>
+> **Statements in this document are NOT yet all marked.** Marking them wholesale is a large judgement
+> exercise and a wrong mark is worse than none, so only what a session touches is marked (R-376).
+> **An unmarked statement therefore means "not yet classified", never "observed".** That ambiguity is
+> exactly what cost this project three sessions in August 2026: the hot/bulk placement decision sat
+> unmarked beside a marked `[FACT]`, and was read as an observation and reported as a defect.
+
+
+
 > **EXECUTED (slice 8C, 2026-06-10 — controller v0.37.0).** This map's target state is now realized:
 > the disk-execution subsystem (`storage/*`, restic, cross-drive, drive-restore, `disk_layout`,
 > `local_infra`, `infra_backup`, `setup/scanner`, `monitor/watchdog`+`pinger`, the storage UI) is

documentation/architecture/03-host-agent.md

@@ -1,5 +1,20 @@
 # Architecture Part 3 — The Host Agent
 
+> **How to read this document.** Two kinds of statement appear, and where this document marks them it
+> marks them like this — the same wording as `07-backup-architecture.md:11-17`, carried here on
+> 2026-08-22 (R-376) so a reader meets one convention and not eight:
+>
+> - **[DESIGN]** — a decision taken. Not derived from code; the code may not implement it yet.
+> - **[FACT]** — an observed property, carrying a `file:line`, a live command output or a citation.
+>
+> **Statements in this document are NOT yet all marked.** Marking them wholesale is a large judgement
+> exercise and a wrong mark is worse than none, so only what a session touches is marked (R-376).
+> **An unmarked statement therefore means "not yet classified", never "observed".** That ambiguity is
+> exactly what cost this project three sessions in August 2026: the hot/bulk placement decision sat
+> unmarked beside a marked `[FACT]`, and was read as an observation and reported as a defect.
+
+
+
 > Status: design draft (decision content). To be grounded by Claude Code against
 > `docs/proxmox-platform.md` and `docs/architecture/02-controller-module-map.md`,
 > then placed at `docs/architecture/03-host-agent.md`.
@@ -378,6 +393,60 @@ nicety.
   **loses Felhom's backup guarantees** — no PBS verify / monitoring on storage we can't reach. An
   honest signup-time tradeoff, not a hidden one.
 
+#### Custody across generations — what the hub retains when a blob is superseded (hub v0.60.0; **contract corrected hub v0.93.0, R-198**)
+
+A ceremony that seals a *different* passphrase does not destroy the blob it replaces: the hub copies
+the current `host_escrow` row into `host_escrow_superseded` **before** overwriting it, so a previous
+generation stays openable with the recovery code that sealed it. The same routine
+(`demoteCurrentEscrowTx`) is used when a host is deleted, which **demotes** custody rather than
+destroying it. The hub never decrypts either table.
+
+**The contract as originally shipped was incomplete, and the gap is worth recording because it was
+invisible for two months.** An escrow generation is **two** sealed artifacts — the K-escrow `blob`
+(the PBS datastore key `K`) and `identity_blob` (the age-wrapped `IdentityBundle`, which carries the
+offsite **restic repository password** as well as the tunnel/PBS tokens and the WG key). Retention
+covered only the first. So a supersession preserved the whole-guest key and destroyed the off-site
+data key — and because the copy happens as the new blob lands, **the destroying act was the ceremony
+itself**, i.e. the step a rebuilt box asks its customer to perform. Corrected in hub v0.93.0: the
+retained row carries both.
+
+**Two consequences that belong in this doc rather than a changelog:**
+
+- **Generational custody is now the recovery precondition for the offsite tier.** The operator ruled
+  on 2026-08-04 that no repository password is retained on the Proxmox host (R-193 candidate (c),
+  refused). With no host-side copy, a rebuilt box's only route back to its previous off-site history
+  is *the customer's older recovery code opening the retained identity blob* — which exists only if
+  the supersession that replaced it happened on hub v0.93.0 or later.
+- **Retention is custody, not recovery, and this doc must not be read as claiming otherwise.** The
+  hub's restore-mode serving of these blobs (§ slice 10D) has **no client** in the agent, the
+  controller's recovered-password injection seam has **no user interface**, and no part of the chain
+  has ever been exercised outside a unit test — the one live identity round-trip (2026-06-10)
+  predates the `ResticRepoPassword` field. Tracked as R-199/R-200/R-201; evidence
+  `documentation/audits/RECON-offsite-dr-chain-2026-08-04.md`.
+
+#### Serving a blob back to its own box (hub v0.94.0 + agent v0.125.0, R-199)
+
+Retention without retrieval is custody, not recovery. Since 2026-08-04 a host reads its own sealed
+identity blob from `GET /api/v1/hosts/{host_id}/escrow` — self-scoped by the per-host key, the mirror
+of the PUT that stored it — and opens it locally with the customer's recovery code via the agent's
+`POST /escrow/recover-offsite-password`, which returns **only** the offsite repository password.
+
+**This is a deliberate widening of who can obtain the ciphertext**, recorded in `CONTEXT.md` S-29 and
+in the handler itself: it previously took an operator arming recovery mode, and now takes only that
+box's own credential. The blob remains unopenable without R, and every retrieval raises an
+operator-visible `escrow_blob_served` event. The operator-driven re-enroll/restore-directive path is
+unchanged and keeps its recovery-mode gate.
+
+**Proven end to end on demo-felhom, 2026-08-04:** the recovered repository password's sha256 was
+byte-identical to the one on the box, and to the hash the hub had independently recorded. **The chain
+stops there** — nothing installs a recovered password, reopens a repository with it, or restores a
+file.
+
+**The honesty property above is unchanged and now has a second edge:** losing `R` and the box makes
+the offsite backups unrecoverable by anyone — *and* an older generation's data is recoverable only
+with **that generation's** recovery code, which the customer must still hold. A current recovery code
+does not open a previous generation's blob.
+
 ## 9. Provisioning & DR flows
 
 **Provisioning (reconcile-driven, by restore).** Fresh creation of a Docker-capable LXC needs

documentation/architecture/04-control-plane-authorization.md

@@ -1,5 +1,20 @@
 # Architecture Part 4 — Control-plane authorization (operator signing)
 
+> **How to read this document.** Two kinds of statement appear, and where this document marks them it
+> marks them like this — the same wording as `07-backup-architecture.md:11-17`, carried here on
+> 2026-08-22 (R-376) so a reader meets one convention and not eight:
+>
+> - **[DESIGN]** — a decision taken. Not derived from code; the code may not implement it yet.
+> - **[FACT]** — an observed property, carrying a `file:line`, a live command output or a citation.
+>
+> **Statements in this document are NOT yet all marked.** Marking them wholesale is a large judgement
+> exercise and a wrong mark is worse than none, so only what a session touches is marked (R-376).
+> **An unmarked statement therefore means "not yet classified", never "observed".** That ambiguity is
+> exactly what cost this project three sessions in August 2026: the hot/bulk placement decision sat
+> unmarked beside a marked `[FACT]`, and was read as an observation and reported as a defect.
+
+
+
 > Status: design draft (decision content), grounded on `docs/tests/phase4-signing-findings.md`.
 > To be reviewed by Claude Code against that spike + `03` §4, then placed at
 > `docs/architecture/04-control-plane-authorization.md`.

documentation/architecture/05-hub-architecture.md

@@ -1,5 +1,20 @@
 # Architecture Part 5 — The Hub
 
+> **How to read this document.** Two kinds of statement appear, and where this document marks them it
+> marks them like this — the same wording as `07-backup-architecture.md:11-17`, carried here on
+> 2026-08-22 (R-376) so a reader meets one convention and not eight:
+>
+> - **[DESIGN]** — a decision taken. Not derived from code; the code may not implement it yet.
+> - **[FACT]** — an observed property, carrying a `file:line`, a live command output or a citation.
+>
+> **Statements in this document are NOT yet all marked.** Marking them wholesale is a large judgement
+> exercise and a wrong mark is worse than none, so only what a session touches is marked (R-376).
+> **An unmarked statement therefore means "not yet classified", never "observed".** That ambiguity is
+> exactly what cost this project three sessions in August 2026: the hot/bulk placement decision sat
+> unmarked beside a marked `[FACT]`, and was read as an observation and reported as a defect.
+
+
+
 > Status: design draft (decision content). To be validated by Claude Code against the **actual
 > felhom-hub source** (`felhom.eu` repo, `hub/`) + Parts 01–04, then placed at
 > `docs/architecture/05-hub-architecture.md`.

documentation/architecture/06-offsite-connectivity.md

@@ -1,5 +1,20 @@
 # Architecture Part 6 — Offsite Connectivity (the backup transport)
 
+> **How to read this document.** Two kinds of statement appear, and where this document marks them it
+> marks them like this — the same wording as `07-backup-architecture.md:11-17`, carried here on
+> 2026-08-22 (R-376) so a reader meets one convention and not eight:
+>
+> - **[DESIGN]** — a decision taken. Not derived from code; the code may not implement it yet.
+> - **[FACT]** — an observed property, carrying a `file:line`, a live command output or a citation.
+>
+> **Statements in this document are NOT yet all marked.** Marking them wholesale is a large judgement
+> exercise and a wrong mark is worse than none, so only what a session touches is marked (R-376).
+> **An unmarked statement therefore means "not yet classified", never "observed".** That ambiguity is
+> exactly what cost this project three sessions in August 2026: the hot/bulk placement decision sat
+> unmarked beside a marked `[FACT]`, and was read as an observation and reported as a defect.
+
+
+
 > Status: **design-of-record** (2026-07-03). Records the settled offsite-backup-transport
 > decisions; grounded against felhom.eu @ `bf099f6` and felhom-agent @ `4ba1b14` (v0.63.0).
 > Evidence base: `documentation/audits/SPIKE-connectivity-wireguard-2026-07-03.md` (all

documentation/architecture/07-backup-architecture.md

@@ -278,7 +278,10 @@ The tiers are **inputs to recovery**, not recovery routes. §7 and §8 say what
 | **Tier-2** cross-drive | `<target nsRoot>/backups/secondary/<app>/` | **always** a full mirror of the unit (`tier2.go:368-369`) **plus** `mandatory + optional` file legs, v2 layout `hdd/<rel>` + `userdata/<rel>` | nightly at W+60m | mirror (rsync) | no |
 | **Tier-3** restic offsite | Hetzner Storage Box over SFTP, one multi-path snapshot per app per run | the unit **plus** `mandatory` legs only; a separate `_shares` snapshot | nightly at W+105m | `--keep-daily 7 --keep-weekly 4 --keep-monthly 6` | **yes** (restic) |
 | **Plane-2** whole-guest, local | `local:` → `/var/lib/vz/dump` on the host | rootfs + `mp0 /var/lib/docker` + `mp1 /mnt/sys_drive` | **24 h** (`backup_cadence_seconds: 0`) | `local_backup_retention: 3` | **no** |
-| **Plane-2** whole-guest, offsite | `felhom-pbs:` → ep0 datastore `felhom-offsite`, per-customer namespace, over WireGuard | same contents | **7 days** (`604800`) | server-side prune on ep0, `keep-last 2` at `03:30` | **yes** (per-customer key) |
+| **Plane-2** whole-guest, offsite | `felhom-pbs:` → ep0 datastore `felhom-offsite`, per-customer namespace, over WireGuard | same contents | **7 days** (`604800`) | server-side prune on ep0, `keep-last 2` at `03:30` — **and the box asks for none** (R-191) | **yes** (per-customer key) |
+
+> **R-191 (2026-08-04) — this row was RIGHT and the configuration disagreed with it, weekly, for as long as R-89 has been in force.** The contract has not changed: offsite retention is ep0's, the box's token is write-only, and the box cannot delete its own history. What had not followed was the installer's `keep_last: 2` on the offsite tier, so every weekly run uploaded its snapshot successfully and then failed the whole JOB on a prune the token is refused — `whole_guest_backup_failed` in the operator's inbox about a backup that had already succeeded. Fixed in installer **1.25.0** (`keep_last: 0`) and on both live boxes; a gate now asserts it. **Verified before changing it:** ep0's two prune jobs have run every day since 2026-07-27, 18 tasks, all OK. A doc that states the contract does not enforce it — the gate does.
+
 
 **[FACT]** The three nightly legs derive from **one** customer-settable window start W at fixed
 offsets — db-dump at W, Tier-2 at W+60m, offsite at W+105m — so they can never be misordered
@@ -331,12 +334,96 @@ refuses **before** stopping the app and names the action that works.
 |---|---|---|---|
 | Tier-1 | unit incl. volume tars + DB dumps | all of it | none |
 | Tier-2 | unit mirror **+** file legs | `hdd/` and `userdata/` **only** (`tier2_restore.go:101-104`) | **the unit mirror is read by nothing** — `RecoveryUnitPath` resolves to `backups/primary/` (`appbackup/paths.go:46-48`) → **R-102** |
-| Tier-3 | unit (incl. volume tars) + mandatory legs | files + DB replay; the unit is **skipped** on the way to live (`offbox_reconstitute.go:284-289`; placed only if the live unit is absent, `offbox_restore.go:352-356`) | **no offsite action unpacks the named-volume tars it captures** → **R-107** |
+| Tier-3 | unit (incl. volume tars) + mandatory legs | files + DB replay **+ the named-volume tars, replayed from the scratch unit** (`offbox_reconstitute.go` `volReplay`, controller **v0.218.0**); the unit itself is still **skipped** on the way to live (`offbox_reconstitute.go:284-289`; placed only if the live unit is absent, `offbox_restore.go:352-356`) | **CLOSED — R-107** |
+
+**[FACT] 2026-08-22 — the Tier-3 row above was corrected; the Tier-2 row was NOT.** Until controller
+**v0.218.0** this table said *"no offsite action unpacks the named-volume tars it captures"*, and that
+was true from the day Tier-3 shipped until 2026-08-21. **R-107 closed in v0.218.0**: `volReplay`
+(`offbox_reconstitute.go`) replays the scratch unit's `volume-dumps/` into the live named volumes,
+proven live on `demo-hp`. The old sentence is kept here, in the past tense, because a correction that
+erases what was believed leaves the next reader no way to tell a fixed gap from one that was never
+noticed.
+
+**R-102 — the Tier-2 half — is NOT closed and nothing in this correction touches it.** The Tier-2 row
+above stands exactly as written: the secondary unit mirror is still read by nothing. Do not read
+"R-107 closed" as covering both; they were always two register rows, and only one of them moved.
 
 **[FACT]** Tier-2's gap is the sharper one because of *when* it bites: Tier-2 exists for the case
 where the primary drive is lost — and in exactly that case the primary unit is gone while this
 mirror survives on the second drive, unreachable by any customer action.
 
+**[FACT] 2026-08-23 — taking the undo copy used to DESTROY the app's own database backup (R-361).**
+`writeSafetyDump` called `DumpOne` into the app's own unit directory and renamed the result to
+`pre-restore-*` afterwards. `DumpOne` writes `<stack>-<dbtype>.sql` — the app's canonical dump, the
+name the replay loop matches exactly — so **every safety dump overwrote the app's real backup and then
+moved it away**, leaving the app with no database backup of its own until the next nightly run. A local
+restore-from-unit in that window finds no `.sql` and tells the customer the app never had a database.
+The comment beside it asserted the rename meant it *"can never overwrite the app's real dump"*; it was
+false as written and stood for four months. **Measured before the fix on `demo-hp` 2026-08-22:**
+`docmost` and `bookstack` each held only `pre-restore-*` files and no canonical dump.
+
+Fixed in controller **v0.221.0**: `DumpOneTo` takes an explicit final path and derives its own `.tmp`
+from it, so neither the destination nor the scratch file can collide with a nightly dump running
+beside it. **Proven the only way it can be** — the canonical dump's sha256, unchanged across a
+restore, on both engines.
+
+**[DESIGN] 2026-08-23 — `db_dumps` lists the app's OWN dumps, not the undo copies.** They are local
+material for a restore that went wrong, not part of the app's recovery set: nothing reads them from
+the manifest, and three per app were being pushed off-site permanently for no recovery value. The
+files are neither deleted nor hidden — their visibility is a separate recorded decision and it stands.
+**One consequence, recorded because it bit within minutes:** a stable `db_dumps` lets
+`CaptureRecoveryUnit`'s already-current early return fire, so anything that must happen on every
+capture — such as bounding the undo copies — has to sit ABOVE that check, not after it.
+
+**[DESIGN] 2026-08-22 — the failure ladder of a database restore: replay → rollback → hold.**
+Recorded here rather than only in a closed register row, because a decision that survives only inside
+a closed work item is a decision nobody will find.
+
+1. **Replay.** The snapshot's `.sql` is imported into the app's database, with only the DB service up
+   (R-47). A pre-restore copy of the LIVE database was taken first and is on disk (R-43); the restore
+   refuses outright if it could not be taken.
+2. **Rollback (controller v0.220.0, R-379).** If the replay fails, the product re-applies that undo
+   copy itself. **The whole set for this run** — an app with two databases gets two undo files, and
+   restoring only the first would leave the other half-written — matched on **the run's own stamp**,
+   never on the `pre-restore-` prefix, because several runs' copies coexist in the same directory. It
+   runs with the DB service still up and before any restart, so the app never observes the half
+   state, and into a **re-discovered** container: the DB-only start re-creates it, so the id captured
+   at dump time is dead by rollback time (v0.220.1, found by the first live run). The app then starts
+   and the customer is told **both** that the restore failed and that their data is as it was.
+3. **Hold (v0.220.0, operator ruling 2026-08-22).** If the rollback ALSO fails, the app is **held
+   stopped**, not started. A running app on a half-written database lets the customer type into it and
+   makes the damage permanent. The hold is persisted, every start path refuses it with a reason and a
+   route, the app-stop marker is ended so nothing auto-restarts it at the next boot, and the app reads
+   **red** rather than green. An operator clears it with `--clear-restore-hold`, which requires a
+   controller restart.
+
+**Why a rollback and not an engine flag.** Postgres gained `--single-transaction` in the same release
+and that does make its replay all-or-nothing — but **MariaDB's DDL is not transactional**, so a
+partial apply there is unavoidable at the engine. Measured 2026-08-22: the same truncated dump left
+Postgres emptied and crash-looping, and left MariaDB with its user data intact, its schema-version
+table wiped to zero rows, and the app reporting `health=healthy, running=true, restarts=0`. The flag
+is a belt; the rollback is the fix. **R-379, R-380.** Evidence:
+`audits/DRILL-r379-rollback-2026-08-22/`.
+
+**[DESIGN] 2026-08-22 — the restore destination is resolved by the same rule as the capture
+destination.** The drive if the app declares one (`HDD_PATH`), the system data path otherwise —
+`Manager.GetAppDrivePath`, one expression, used by `CaptureRecoveryUnit` and, since controller
+**v0.219.0**, by `ReconstituteFromOffsite` and `PlaceOffsiteRestore` too.
+
+The refusal that protects a drive app from being restored onto the wrong disk (R-253, R-351) applies
+to apps that **have a drive to get wrong**. It used to be reached by testing `HDD_PATH == ""`, which
+also answered "is this app installed?" — one predicate for two questions. Measured in the catalogue at
+`459766cb1639`: **53 templates, 13 declare `needs_hdd: true`, 40 declare `false`**, so for 40 apps that
+test was permanently true and the off-site restore refused them forever, while they were running,
+with a message telling the customer to reinstall them "in the same place" — a place those apps never
+offer. **An app with no drive is not misconfigured** (§8 of `01-topology-and-trust.md` carries the
+`[DESIGN]` marker); it is the majority case.
+
+Since v0.219.0 the two questions are asked separately: *installed?* of `ListDeployedStacks()`, failing
+CLOSED when there is no provider to ask; *where?* of `GetAppDrivePath`. A third refusal, with its own
+sentence, covers installed-but-no-resolvable-data-root. **R-356**; reasoning also recorded in
+`felhom-controller/CONTEXT.md`.
+
 ---
 
 ## 7. The recovery chain (D3) — the reason this document exists
@@ -348,6 +435,51 @@ about whether the bytes can be turned back into a working system, and a system c
 completely while having no executable recovery route for a given failure. That is not a hypothetical
 here — §8 has rows where it is the actual state.
 
+### 7.0 What a customer can and cannot do ALONE — the four steps the drill found
+
+> **[FACT] Added 2026-08-05.** The 2026-08-04 R-201 drill (`audits/DRILL-r201-night-run-2026-08-04.md`)
+> is the first end-to-end proof that a customer's file survives a machine rebuild and comes back
+> byte-identical. **It passed with an operator present, and four manual interventions stood between
+> "the key is recoverable" and "the file is back" — none of which was in any design document.** They
+> are recorded here because this is the section a future reader will use to answer *"can the customer
+> do this alone?"*, and until 2026-08-05 the answer was no for reasons nothing wrote down.
+
+| # | The step | Why it stopped a customer | Status |
+|---|---|---|---|
+| 1 | **The reset code was refused on the first try** | `--print-reset-code` runs as a SEPARATE process (`docker exec`); it persists a new code while the running controller keeps the old one in its cache, so the code the customer is told to type never matches. **The controller had to be restarted in between**, which nothing said. Two attempts failed during the drill before that was worked out. | **CLOSED — controller v0.198.0** (R-204 item 1). `effectiveClaimCode` reads through to the persisted state. Read-through, not a TTL: a TTL would leave a window in which a superseded code still works. Fails closed on an unreadable state. Proven live on demo-felhom 9201 with nothing restarted. |
+| 2 | **Re-issuing the off-site credential marked the recovery escrow "stale"** | A stale escrow withholds `restic_pw_sha256` from the report ACK → the controller's auto-confirm cannot flip `pending→escrowed` → `OffboxRunnable()` is false → **every off-site backup refused**. The customer is then told to re-run the recovery ceremony, **which is the one act that would have destroyed the key just recovered.** The repository password had not changed at all. | **CLOSED — hub v0.95.0** (R-204 item 2 / R-196). The precautionary mark is gone. The real case is measured by the controller's Scenario-F hash re-check each ACK — which the mark was BLINDING by emptying that very hash — and by R-197's `offsite_repo_key_changed` at a supersession. |
+| 3 | **The restore's default returned the wrong thing, silently** | `mode=unit` restores the recovery unit — the app's definition, configuration and database dumps — and **not the customer's files**; the userdata in the same snapshot is excluded by `--include`. The outcome message was one sentence for both modes and named neither scope. On the last step of a disaster recovery, the default quietly did not do what the person asked. | **CLOSED — controller v0.198.0** (R-204 item 3). The unit outcome names what came back, what did not, and the step that gets it; the wizard's intent card states its scope before the choice. **The size gate on `mode=full` is untouched**, and the default stays `unit`. |
+| 4 | **A rebuilt box cannot obtain an off-site credential unaided** | The one-time provider password was spent by its predecessor, so the rebuilt guest has nothing to authenticate with and an **operator Re-issue** was required. | **CLOSED — controller v0.199.0 + hub v0.96.0** (2026-08-05, operator ruling: automate it, and **the trigger is a state the BOX DECLARES**). The box now reports `offsite.state=needs_credential` when two local facts hold together — a fresh data area AND a hub-held recovery package — and the hub's `internal/offsiteheal` re-arms the stored one-time secret, minting only when there is nothing to re-arm. **Deliberately NOT automated: the escrow ceremony.** A credential is replaceable; the recovery code is not. |
+
+> **[FACT] The honest current answer, updated 2026-08-05 (controller v0.200.0): all four are gone AND
+> the customer is now offered the recovery.** A full-page screen meets the owner of a rebuilt box while
+> the hub holds a sealed package the box cannot open: it explains the situation, says plainly that
+> **nobody can replace a lost recovery code**, takes the code, opens the repository and **lists what is
+> in it** — apps, dates, sizes. No step requires an operator, and no step requires a command line.
+>
+> **WHERE THAT STOPS, and it is a real stop.** The screen **unlocks and only unlocks**. It restores
+> nothing. Putting files back is per-app, lives in the backups area, and the step after the listing —
+> a customer seeing what would change before anything is overwritten — is **not built** (→ R-213). A
+> screen that unlocks and then offers to overwrite is two decisions wearing one button, which is why
+> the operator ruled them separate.
+>
+> **What is still owed as evidence:** the final unlock has never been driven with a CORRECT code
+> through the page (no code was kept for demo-felhom's orphaned history; demo-hp's is operator-held),
+> so the live run exercised handler → agent → hub fetch → age KDF and stopped at the unseal. **And the
+> whole journey has not been re-walked end to end since these fixes** — the closures are proven
+> individually, not as one uninterrupted run. That re-walk is one more drill.
+>
+> **WHY THE TRIGGER FOR STEP 4 IS A DECLARATION, recorded here because it is the design and not an
+> implementation detail:** from the hub, an ABSENT off-site object means *never configured*,
+> *mid-restart*, *a transient config read failure* OR *rebuilt and stranded*, and the hub cannot
+> distinguish them. The BOX can, from two local facts it holds with certainty. So the box states its
+> condition and the hub acts on a stated request — never on a silence. Both facts are required:
+> freshness alone is a box that never had off-site backups, and an escrow alone is a healthy box.
+>
+> **The split that is deliberate and must not be widened: CREDENTIAL AUTOMATIC, KEY CUSTOMER-PRESENT.**
+> A credential is transport and is replaceable; the recovery code is not, because only the customer
+> holds it. Nothing in this chain runs, or asks for, an escrow ceremony.
+
 ### 7.1 The dependency graph
 
 > **[FACT] SUPERSEDED IN PART BY D5 — SHIPPED 2026-07-30 (controller v0.188.0).** Leg 1 below
@@ -477,10 +609,14 @@ anywhere under the backup namespace. Full record: `audits/D5-drive-alone-restore
   drive. In that failure the primary recovery unit is gone; the surviving mirror on the second drive
   is `backups/secondary/<app>/recovery-unit/`, which **no code path reads** (§6.3). For the 45-or-43
   class-B apps the restore is a guaranteed no-op in exactly its designed scenario. → **R-102**
-- **Tier-3 vs guest loss.** Tier-3 holds the volume tars and the DB dump. Reconstitution requires
-  the app to be deployed and skips the unit; the tars are unpacked only by the Tier-1 path, which
-  requires the guest's secrets. So offsite alone cannot rebuild an app onto a fresh guest.
-  → **R-107**
+- **Tier-3 vs guest loss — HALF of this closed.** Tier-3 holds the volume tars and the DB dump. It
+  was true until controller v0.218.0 that the tars were unpacked only by the Tier-1 path; since
+  v0.218.0 the reconstitution replays them itself (`volReplay`) → **R-107 CLOSED 2026-08-22**. What
+  is **still** true, and is the part that was never R-107: reconstitution requires the app to be
+  **deployed** and skips the unit, so offsite alone cannot rebuild an app onto a fresh guest. That
+  requirement is a deliberate decision (R-253) — the restore does not choose a customer's drive for
+  them — and since **v0.219.0** it means only what it says: an app that is not deployed. It no longer
+  catches the 40 driveless apps → **R-356**.
 
 ### 7.3 ~~What D5 would change — and why it was blocked~~ — **D5 SHIPPED 2026-07-30 (v0.188.0)**
 
@@ -689,7 +825,7 @@ crosses the line — **R-158**.
 | 3 | **An app's DB and named volumes are lost** | the guest, the unit | „Visszaállítás indítása" — Tier-1 unit restore (the **only** path that unpacks volume tars) | **customer** | **18.25 s** (path execution) · **27.6 s** (D5 drill, guest `app.yaml` absent) | 24 h | **PROVEN** (content recovery proven 2026-07-30) | CAMPAIGN-9 A2 proved the path executes; **D5 v0.188.0 closed the content gap** — after a restore with the guest's `app.yaml` moved aside, the app read the seeded row **over TCP with its own credential**, the pre-backup row returned and a post-backup row was gone (so the tar was really restored). No `.sql` dump in the unit ⇒ the DB came back from the volume tar |
 | 3c | *same, with the GUEST GONE (secrets unavailable)* | the drive | Tier-1 unit restore — **the unit carries the portable secrets** | **customer** | **27.6 s** | 24 h | **PROVEN** | D5, §7.4. Before v0.188.0 this row was **NONE**: the data-key gate refused and the customer's own copy of their own data was not a recovery |
 | 3b | *same, for a class-B app via Tier-2* | — | **no route** — Tier-2 never reads the unit mirror | — | | | **NONE** | §6.3; **R-102** |
-| 4 | **Primary drive dies** | Tier-2 copy on the second drive; Tier-3 offsite; the guest | Tier-2 for **file legs** (7 or 9 of 53 apps); Tier-3 reconstitute for files + DB; **the volume tars in either copy are unreachable** | **customer** (both) | | 24 h | **PARTIAL** | §7.2; **R-102**, **R-107** |
+| 4 | **Primary drive dies** | Tier-2 copy on the second drive; Tier-3 offsite; the guest | Tier-2 for **file legs** (7 or 9 of 53 apps); Tier-3 reconstitute for files + DB **+ the named-volume tars since controller v0.218.0** (`volReplay`); **the Tier-2 copy's volume tars remain unreachable** | **customer** (both) | | 24 h | **PARTIAL** | §7.2; **R-102** (open); **R-107 CLOSED 2026-08-22, v0.218.0** |
 | 5 | **Secondary drive dies** | everything the customer uses | none needed — Tier-2 is a derived copy, rebuilt on the next run (`07` §8 migration rule: *"Migration = rebuild, not preserve"*) | automatic | | 24 h | **PROVEN** (by construction) | tier2 v2 layout marker + rebuild, `internal/backup/tier2.go:359-393` |
 | 6 | **Guest lost or corrupted** | the host, both whole-guest tiers, the data drives (they are host binds) | `pct restore` from `local:` or `felhom-pbs:` | **operator** (SSH) | **84–112 s** local · **1101 s** PBS (both = restore-test into a scratch guest, boot + verify + teardown) | 24 h local · 7 d offsite | **PROVEN** | CAMPAIGN-2 T-P9; CAMPAIGN-8 Phase C (exact mount parity, `unprivileged: 1` preserved); LIVE restore-tests on both boxes this session |
 | 7 | **Guest stopped and does not come back** | everything | guest-power watchdog (60 s, `onboot` as the deliberate-stop discriminator) | automatic | **120 s** | | **PROVEN** | agent v0.107.0 replay — 120 s unattended vs the incident's 587 s with a human |
@@ -851,7 +987,8 @@ does **not** hold as written. → **R-108**
 | **R-104** | An interrupted offsite run leaves an exclusive restic lock the existing self-heal cannot reach, reported as *„ismeretlen okból"* | the offsite tier stays dead until a human unlocks. Was C9-F3 |
 | **R-105** | Three hub-held DR records are empty on the whole live fleet: `hosts.dr_record_json`, `host_escrow.directive_json`, `dr_recipe.host_half.drives` | the Recipe (§4) is incomplete in exactly the fields host-loss recovery reads. Causes may differ per field |
 | **R-106** | `dr_recipe.host_half.pbs.namespace` records `"root"` on every box | the recorded restore coordinate is wrong; real namespaces are per-customer |
-| **R-107** | No offsite action unpacks the named-volume tars Tier-3 captures on every run | offsite alone cannot rebuild a named-volume app (§7.2) |
+| **R-107** | ~~No offsite action unpacks the named-volume tars Tier-3 captures on every run~~ — **CLOSED, controller v0.218.0, 2026-08-22** (`volReplay`, proven live on `demo-hp`). True from the day Tier-3 shipped until 2026-08-21. | was: offsite alone cannot rebuild a named-volume app (§7.2). Now: the tars replay; what remains is that the app must be **deployed** (R-253), which is not R-107 |
+| **R-356** | The off-site restore resolved its destination with the raw `HDD_PATH` and read an empty answer as "not installed" — **CLOSED, controller v0.219.0, 2026-08-22** | 40 of 53 apps were refused permanently while running (§6.3 `[DESIGN]`) |
 | ~~**R-108**~~ | ~~Network storage can host an app's namespace~~ | **CLOSED 2026-07-30, controller v0.187.0 — D5 UNBLOCKED.** An app namespace may no longer be placed on network storage (5 surfaces guarded by one fail-closed predicate); the share-root bind is deliberately UNCHANGED because it is load-bearing and unscopable (§10.1). `audits/R108-network-app-namespace-2026-07-30.md` |
 | **R-126** | A `.fab` bundle — plaintext secrets, optional password — can be exported ONTO a NAS: `storageDriveList()` (`internal/web/handler_export.go`) does not filter network paths | split out of R-108, which closed without it. NOT a D5 precondition: an explicit customer-chosen export destination, not a browsing surface reaching a backup tree (§5, §7.3) |
 | R-95 (open) | The restic offsite credential **can delete** — the box can `forget --prune` its own repo | the tier holding the customer's documents and photos is the one whose credential can destroy it (matrix row 10) |
@@ -941,3 +1078,4 @@ to now *implement* D5 remains an open scheduling decision, not a blocked one.
 - It does not estimate a single RTO or RPO. Every blank in §8 is a real gap.
 - It does not answer §11. Those are the operator's.
 - It does not claim ratification.
+| 5 | **A customer had no way to BEGIN — the only route was a command line** | Everything above was self-service, and nothing told the owner of a rebuilt box that a sealed package was waiting or how to open it. | **CLOSED — controller v0.200.0** (R-193). A full-page recovery screen, shown while the hub holds a package this box cannot open; it unlocks and lists, and **restores nothing** (→ R-213 for the put-back). |

documentation/architecture/08-alarm-ladder.md

@@ -0,0 +1,268 @@
+# 08 — The app-down alarm ladder
+
+**Written 2026-08-23, with controller v0.222.0 (R-384).**
+
+**The absence is the finding.** Until this file existed, no document owned the question *"when does a
+customer's app being broken raise an alarm?"* The rules were spread across four packages as comments,
+each locally correct, and the ordering between them was legible only by reading
+`aggregateState` top to bottom. That is exactly how R-384 survived: every individual rule was right,
+and the composition was wrong. Three separate defects in this ladder (R-51, C9-F2, R-384) were each
+found on live hardware rather than by review, and each is a case where a reader could not see the
+whole ladder at once.
+
+Everything below is **[DESIGN]** — deliberate, with the reason recorded — unless marked otherwise.
+
+---
+
+## 1. The two questions, and their order
+
+Two different questions get asked about a multi-container app, and **the order between them is
+load-bearing**:
+
+1. **Is a SUPERVISED member of this app dead?** — a container Docker's restart policy says should be
+   running, that is not.
+2. **Is a RUNNING member failing its healthcheck?**
+
+**Question 1 is asked FIRST.** [DESIGN, R-384, v0.222.0]
+
+Until v0.222.0 it was asked second, and the consequence was not subtle: a two-container app whose
+database exits goes `unhealthy` seconds later *because it cannot reach that database*. So the symptom
+the dead database causes was the thing that suppressed the alarm for it. Measured on `demo-hp`
+2026-08-22 — `bookstack-db` stopped at 21:27:01 and the watcher reported `0 currently down`
+throughout.
+
+**"Some members are up" means any member NOT in the down bucket** — `running`, `unhealthy`,
+`starting` or `restarting`. [DESIGN, R-384] The earlier guard was `running > 0`, counting only
+`StateRunning`, which made the supervised test unreachable in precisely the case it was written for:
+an unhealthy survivor beside a dead database counted as nothing being up.
+
+---
+
+## 2. Where each decision is made
+
+| Decision | Where | Notes |
+|---|---|---|
+| container → stack aggregate state | `internal/stacks/manager.go` `aggregateState` | the ladder in §3 |
+| is a down member supervised? | `internal/stacks/manager.go` `supervisedPolicy` | `no`/`on-failure` benign; everything else, **including unknown**, supervised |
+| which states mean "down" | `internal/stacks/manager.go` `IsDownState` | `{stopped, exited, degraded}` |
+| stack state → "this app is down" | `cmd/controller/main.go` `classifyRunStates` | **the single derivation point**; all three suppressions live here |
+| sustained restarting → down | `internal/stacks/manager.go` `CrashLooping` | 5-minute threshold |
+| quiesce suppression | `internal/quiesce/suppress.go` | cycle-keyed, 180 s grace |
+| boot repair | `internal/bootrecon/bootrecon.go` | consumes `IsDownState` |
+
+---
+
+## 3. The aggregation ladder, in order
+
+`aggregateState(containers, policyOf)` — **priority: degraded > unhealthy/starting > restarting >
+all-running > stopped.**
+
+1. no containers → `not_deployed`
+2. **any DOWN member is supervised, and any member is up → `degraded`** ← R-384 put this first
+3. any `unhealthy` → `unhealthy`
+4. any `starting` → `starting`
+5. any `restarting` → `restarting`
+6. all running → `running`
+7. all down → `stopped`
+8. mix, every down member benign → `running`
+
+Step 2's `policyOf` is consulted **only** for the down members, and only when something is up. `nil`
+is allowed; every down member then reads as supervised.
+
+---
+
+## 4. Which states alarm, and which deliberately do not
+
+`IsDownState` = `{stopped, exited, degraded}`.
+
+| State | Down? | Why |
+|---|---|---|
+| `stopped`, `exited` | **yes** | not running, will not recover alone |
+| `degraded` | **yes** | [DESIGN, R-51] a dead supervised member is as unreachable as a single app that exited — immich-server sat Exited 18 h with the app 100 % dead and no alert |
+| `unhealthy` | **NO** | [DESIGN] a running container whose healthcheck is failing. Folding it in reintroduces the flapping fix-3 was written to stop. **R-384 did not change this** — it asks a prior question instead |
+| `restarting` | **NO**, until sustained | [DESIGN, C9-F2] `restarting` is on the normal deploy path, so folding it in would alarm fleet-wide on every update. Becomes down after **5 min** (`crashLoopAfter`) |
+| `starting`, `deploying` | no | mid-start |
+| `paused` | no | a deliberate user action |
+| `unknown` | no | [DESIGN] fail-OPEN — never manufacture a dead-app alert from an inconclusive read |
+
+**Note the two fail directions are deliberately opposite.** `IsDownState` fails OPEN on `unknown`
+(ambiguous *state* → do not alarm). `supervisedPolicy` fails CLOSED on unknown (we already KNOW a
+member is dead; only the excuse is missing). Both are recorded at their sites.
+
+---
+
+## 5. The three suppressions, all at `classifyRunStates`
+
+| Suppression | Rule | Expires? |
+|---|---|---|
+| **deliberate user stop** | `StateStopped` is not down **unless** the quiesce loop reports it failed to restart that stack | n/a — lifted by `failedRestart` |
+| **quiesce cycle** | a stack this backup cycle stopped is exempt | **yes**, 180 s after unquiescing |
+| **boot grace** | no evaluation for 90 s after controller start | **yes** |
+
+**None of them latch.** [DESIGN, R-97b + R-88 Scenario D] A permanent suppression trades a loud false
+alarm for a silent real one, which is the same error as an over-eager alarm, in the opposite
+direction. Every window expires; the cost is a bounded DELAY in reporting a real failure, never its
+loss.
+
+The quiesce suppression is **cycle-keyed, not state-keyed** — an app caught mid-restart is
+`starting`/`unhealthy`, not `stopped`, so no state test can see it. It is therefore **state-blind**,
+which is why R-384 moving a stack from `unhealthy` to `degraded` cannot weaken it.
+
+---
+
+## 6. The alarm itself
+
+Edge-triggered: `app_start_failed`, one event per transition into down, **not** per scan. Verified
+live 2026-08-23 — one event across 22 scans.
+
+- **Operator/hub event + dashboard banner.** `app_start_failed` is **not** in
+  `settings.DefaultEnabledEvents`, so by default it does **not** e-mail the customer.
+- **F-OBS heartbeat**, every 20 scans (~10 min), at `[INFO]`:
+  `[deadapp] check alive: N scans since boot, M deployed app(s) evaluated, K currently down`.
+  This line exists because an absent alarm and a stopped detector look identical in a log.
+
+### 6.1 The severity contract [DESIGN, R-329 — CLOSED controller v0.223.0 / hub v0.107.0]
+
+**The vocabulary is the HUB's and it is exact: `{info, warning, error, critical}`.** Anything else is
+**coerced to `info` at ingest**, and `info` is dropped by `severityNotifies` before *both* delivery
+legs. So a severity outside the set means the event is stored, answers `200`, shows on the dashboard —
+and is e-mailed to **nobody**.
+
+**This shipped twice.** `DiskAlertKind.Severity` emitted `"warn"` until controller v0.215.0;
+`app_start_failed` emitted it until v0.223.0. Measured on the live hub DB 2026-08-23: **91
+`app_start_failed` events stored all-time, ZERO `notification_log` rows before that day** — not one,
+on any channel.
+
+Three things now hold it:
+
+1. **The emitter is pinned by an AST walk** over the whole controller
+   (`TestR329_EveryEmittedSeverityIsInTheHubVocabulary`). Not grep — "warn" is a legitimate
+   *healthcheck status* in `internal/monitor` and `internal/selftest`. The six call sites that pass a
+   variable are registered by name with the values each can take, so a new dynamic path fails.
+2. **The hub SAYS SO** when it coerces (hub v0.107.0, R-387): a `WARN` naming the customer, the event
+   type and the rejected value. **The coercion stays** — a rejected event is a *lost* event, and
+   losing an alarm is worse than mis-routing one.
+3. **The dispatcher's `unrecognized severity` branch is kept**, because the hub's own monitor checkers
+   call `ProcessEvent` directly and never pass the ingest handler. For them it is the only guard.
+
+**Who gets it.** `processOperator` consults only `operatorOn`, the address and a 1-hour cooldown —
+**never customer preferences** — so a valid severity always reaches the operator. `processCustomer`
+consults `operatorOnlyEvents` and then the customer's `enabled_events`.
+
+**`app_start_failed` is customer-switchable but OFF by default** [DESIGN, operator ruling 2026-08-23]:
+it is deliberately absent from `DefaultEnabledEvents`, and deliberately **not** in `operatorOnlyEvents`
+— being in that register would make the toggle visible, flickable and structurally unable to deliver.
+
+---
+
+## 6.2 The delivery grain — how often, and per what [DESIGN, R-389 — hub v0.108.0]
+
+**"How loud" is a separate decision from "does it alarm", and it is made in one place**: the operator
+cooldown key at `processOperator`. Everything sharing a key is collapsed for **one hour**.
+
+| Family | Grain | Key carries | Why |
+|---|---|---|---|
+| app down (`app_start_failed`) | **per APP** | `…:<stack_name>` | no digest exists for it — see below |
+| backup run (`backup_run_failures`) | per RUN | `…:<run_id>` | a digest already lists every failing app; one per run |
+| tiered backup (`whole_guest_backup_failed`, …) | per TIER | `…:<tier>` | the tiers fail independently and mean different things |
+| everything else, incl. `crossdrive_failed` | per TYPE, per hour | — | coarse **on purpose** |
+
+**The default is COARSE and that is deliberate.** R-97a and R-182 exist so that one full disk produces
+**one** mail listing every affected app rather than one per app. Widening the grain is what makes an
+operator stop reading their alerts, which is the same failure as not sending them.
+
+**`app_start_failed` is the exception because it has no digest.** There is no `apps_down_run`
+summarising a scan the way `backup_run_failures` summarises a run, so per-app is the only grain
+available that does not lose alarms. Until hub v0.108.0 it was keyed per type, and **only the first
+broken app per hour reached the operator** — measured 2026-08-23: `bookstack` sent at 09:27:51,
+`privatebin` suppressed at 09:31:51 under `key=demo-hp:app_start_failed`.
+
+**The mechanism is a named ALLOW-LIST (`perAppCooldownEvents`), not a payload rule**, and the
+distinction is load-bearing rather than stylistic: **`crossdrive_failed` is severity `error`, reaches
+the operator leg, and carries `stack_name`** through `CrossDriveDetails`. A rule of the form "if the
+details carry a stack_name, split per app" would have split it, silently, and undone R-182.
+`cooldownStackSuffix` therefore takes the **event type** as well as the details — an asymmetry with
+its two siblings, and the reason for it is exactly this.
+
+**Fenced act:** adding an entry to `perAppCooldownEvents` for a type whose family has a digest, or
+whose coarse cooldown is deliberate. Reading the register anywhere is fine.
+
+**Measured burst, so the volume is a number and not an impression:** three apps stopped in one scan
+produced **three attempted, three sent, zero suppressed** (2026-08-23). The reference box has 8
+deployed apps, so a total outage is 8 mails. The boot grace (90 s), the quiesce grace (180 s) and the
+per-app edge trigger absorb reboots, backup cycles and persistently-dead apps. **This scales linearly
+with app count and has no ceiling** — the condition that would reopen the question is a box large
+enough that a total outage is unreadable, at which point the answer is a digest with a customer
+message, not a wider cooldown.
+
+---
+
+## 7. The intent test [DESIGN, R-386 — CLOSED controller v0.223.0]
+
+**"The customer stopped this" is asked of the FIELD THAT RECORDS IT, never inferred from the state.**
+
+Until v0.223.0 `classifyRunStates` read `st.State == StateStopped` and assumed every stopped stack was
+deliberate. It is not inferable: `aggregateState` folds `StateExited` into the stopped counter, so an
+all-down stack returns `StateStopped` whatever killed it. Measured on `demo-hp` 2026-08-23:
+`privatebin` stopped out of band, nine dead-app scans over four minutes, **zero events, zero banner
+lines** — while a comment beside the code claimed an out-of-band stop *"still alerts"*.
+
+`DesiredState` records the answer, has **exactly one writer** (the customer's own action), and is
+tri-state:
+
+| Intent | Verdict | Why |
+|---|---|---|
+| `Stopped` | **no alarm** | the customer asked |
+| `Running` | **ALARM** | nobody asked — the R-386 case |
+| absent (`""`) | **no alarm, and SAY SO** | UNKNOWN never means running |
+
+**The absent case keeps the old behaviour deliberately.** Reading it as "nobody asked" would, on the
+first cycle after upgrade, e-mail about every app any owner ever stopped — fleet-wide, from a field
+that predates the intent being asked of it. The backfill cannot help: it seeds `Running` only from an
+observed-**up** reading, so anything stopped at upgrade time stays unknown, which is precisely the
+ambiguous population.
+
+**The gap is BOUNDED, not silent.** Every such suppression sets `AppRunState.IntentUnknown`, and the
+scheduler logs the names at `INFO` on the heartbeat cadence:
+
+```
+[deadapp] N stopped app(s) have NO recorded customer intent, so their dead-app alarm is
+suppressed by the unknown-intent fallback (R-386): <names>. This closes itself as each app is
+started or stopped through the interface.
+```
+
+**A rule without a mechanism is a wish.** Measured on `demo-hp` 2026-08-23: **0 of 8 deployed apps had
+an absent intent** — the population is already empty on an exercised box; it will be larger on one
+upgraded and left alone.
+
+`failedRestart` still lifts a `Stopped` intent, and that ordering is load-bearing: the quiesce loop
+stops stacks by the same path a customer does, so one it stopped and could not restart must alarm
+whatever the intent says. Removing that term re-opens F-CRIT-1.
+
+**Fenced act:** adding a `DesiredState` **writer**. Reading it anywhere is fine. Twelve of
+`StopStack`'s fourteen callers are machines, so recording intent in the primitive would make a nightly
+backup indistinguishable from the customer pressing Stop.
+
+---
+
+## 8. Direction — who a customer should be notified about at all
+
+**[DESIGN — DIRECTION, NOT CURRENT BEHAVIOUR. Dated 2026-08-23, the operator's own framing.
+Nothing in controller v0.223.0 / hub v0.107.0 implements this.]**
+
+> **A customer should be notified only about things they can act on or are responsible for** — the
+> drive they unplugged, the storage they filled. **A failed backup is our incident, not theirs.** The
+> intended shape is that we detect it, we tell them we noticed and are dealing with it, and they are
+> not handed an error they cannot solve. The subscription should feel like being looked after, not
+> like being on call.
+
+Today's settings page is the opposite shape: it exposes one toggle per detector and **grew from 12 to
+15 in this session alone** (one new alarm, plus two compound toggles split into four). That growth is
+the argument, not an aside — a page that grows by one per detector is a page that will keep asking a
+household to make engineering decisions.
+
+`app_start_failed` defaulting **off** is consistent with this direction and reversible either way; it
+was ruled that way on its own merits and does not pre-judge the redesign.
+
+**Filed as a PRODUCT DECISION, not a defect** — see the register. It is the operator's call to take
+separately, and no part of it was implemented here.

documentation/architecture/where-felhom-stands-2026-08-09-snapshot.html

@@ -0,0 +1,396 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Bundled Page</title>
+  <style>
+    * { margin: 0; padding: 0; box-sizing: border-box; }
+    body { background: #0b1220; display: flex; align-items: center; justify-content: center; min-height: 100vh; font-family: -apple-system, BlinkMacSystemFont, sans-serif; }
+    #__bundler_loading { position: fixed; bottom: 20px; right: 20px; font: 13px/1.4 -apple-system, BlinkMacSystemFont, sans-serif; color: #666; background: #fff; padding: 8px 14px; border-radius: 8px; box-shadow: 0 1px 4px rgba(0,0,0,0.12); z-index: 10000; }
+    #__bundler_thumbnail { position: fixed; inset: 0; width: 100%; height: 100%; display: flex; align-items: center; justify-content: center; background: #0b1220; z-index: 9999; }
+    #__bundler_thumbnail svg { width: 100%; height: 100%; object-fit: contain; }
+    #__bundler_placeholder { color: #999; font-size: 14px; }
+  </style>
+  <noscript>
+    <style>#__bundler_loading { display: none; }</style>
+    <div style="position:fixed;bottom:12px;left:12px;font:13px/1.4 -apple-system,BlinkMacSystemFont,sans-serif;color:#999;background:rgba(255,255,255,0.9);padding:6px 12px;border-radius:6px;box-shadow:0 1px 4px rgba(0,0,0,0.08);z-index:10000;">
+      This page requires JavaScript to display.
+    </div>
+  </noscript>
+</head>
+<body>
+  <div id="__bundler_thumbnail">
+<svg sc-camel-view-box="0 0 1200 800" xmlns="http://www.w3.org/2000/svg">
+<rect width="1200" height="800" fill="#0b1220"></rect>
+<rect x="120" y="150" width="960" height="90" rx="12" fill="#121b2c"></rect>
+<rect x="120" y="280" width="300" height="370" rx="12" fill="#121b2c"></rect>
+<rect x="450" y="280" width="300" height="370" rx="12" fill="#121b2c"></rect>
+<rect x="780" y="280" width="300" height="370" rx="12" fill="#121b2c"></rect>
+<circle cx="175" cy="335" r="18" fill="#34d399"></circle>
+<circle cx="505" cy="335" r="18" fill="#fbbf24"></circle>
+<circle cx="835" cy="335" r="18" fill="#60a5fa"></circle>
+</svg>
+</div>
+  <div id="__bundler_loading">Unpacking...</div>
+
+  <script>
+    
+document.addEventListener('DOMContentLoaded', async function() {
+  const loading = document.getElementById('__bundler_loading');
+  function setStatus(msg) { if (loading) loading.textContent = msg; }
+
+  const FONT_MIME = /^(font[/]|application[/](x-)?font-|application[/]vnd\.ms-fontobject)/i;
+  const MIME_TOKEN = /^[\w.+-]+[/][\w.+-]+$/;
+  function toBase64(bytes) {
+    let bin = '';
+    for (let i = 0; i < bytes.length; i += 0x8000) {
+      bin += String.fromCharCode.apply(null, bytes.subarray(i, i + 0x8000));
+    }
+    return btoa(bin);
+  }
+
+  // Error sink persists across replaceWith since it's on window, not the DOM.
+  window.addEventListener('error', function(e) {
+    // Failed resource loads (CSP-blocked links, scripts, images) fire plain
+    // events at the element — warn only; real JS errors carry message/error.
+    if (!e.message && !e.error && e.target && e.target !== window) {
+      console.warn('[bundle] resource failed to load:',
+        e.target.tagName, String(e.target.src || e.target.href || ''));
+      return;
+    }
+    var p = document.body || document.documentElement;
+    var d = document.getElementById('__bundler_err') || p.appendChild(document.createElement('div'));
+    d.id = '__bundler_err';
+    d.style.cssText = 'position:fixed;bottom:12px;left:12px;right:12px;font:12px/1.4 ui-monospace,monospace;background:#2a1215;color:#ff8a80;padding:10px 14px;border-radius:8px;border:1px solid #5c2b2e;z-index:99999;white-space:pre-wrap;max-height:40vh;overflow:auto';
+    d.textContent = (d.textContent ? d.textContent + String.fromCharCode(10) : '') +
+      '[bundle] ' + (e.message || e.type) +
+      (e.filename ? ' (' + e.filename.slice(0, 60) + ':' + e.lineno + ')' : '');
+  }, true);
+
+  try {
+    const manifestEl = document.querySelector('script[type="__bundler/manifest"]');
+    const templateEl = document.querySelector('script[type="__bundler/template"]');
+    if (!manifestEl || !templateEl) {
+      setStatus('Error: missing bundle data');
+      console.error('[bundler] Missing script tags — manifestEl:', !!manifestEl, 'templateEl:', !!templateEl);
+      return;
+    }
+
+    const manifest = JSON.parse(manifestEl.textContent);
+    let template = JSON.parse(templateEl.textContent);
+
+    // Nested page bundles (iframe targets). Each ships ONCE, in the ROOT
+    // document's manifest; frame srcs carry an about:blank#<uuid> marker
+    // instead of a substitutable uuid. Every document mints the blobs for
+    // its OWN frames — from local text at the root, or text obtained from
+    // its DIRECT parent over the relay protocol below — so each frame
+    // navigation stays same-origin with its initiator and a deduped page
+    // loads at any depth on any host, including a file:// download's
+    // opaque origins (where a blob minted by one document cannot be
+    // navigated to by another).
+    const pageOrderEl = document.querySelector('script[type="__bundler/page_order"]');
+    const pageOrder = pageOrderEl ? JSON.parse(pageOrderEl.textContent) : [];
+    const pageSet = new Set(pageOrder);
+    const pageTexts = {};
+
+    // ── Nested-page text protocol (parent-chain relay) ──
+    // Page bundles ship once, in the ROOT document's manifest. Every
+    // document mints the blobs for its OWN frames, obtaining page text
+    // through a strict parent-chain relay: a document only ever SENDS to
+    // its direct parent (which, for every document the publisher's own
+    // runtime minted, is another publisher document) and only ACCEPTS
+    // text from that direct parent; requests from below are honored only
+    // for the document's own child frames, and the ROOT never sends
+    // upward at all. That last rule is load-bearing: the artifact host's
+    // frame-ancestors allows claude.ai (and friends) to frame an
+    // artifact, so window.top can be a FOREIGN document — a top-addressed
+    // protocol would hand page uuids to that ancestor and accept forged
+    // "page text" from it, minting attacker HTML as an artifact-origin
+    // blob document. The chain never touches the ancestor: requests stop
+    // at the root, replies are origin-addressed per hop (never '*' when
+    // an origin exists), and both directions are origin-gated (on https
+    // a foreign sender's origin can never equal this document's; in
+    // opaque contexts — file:// — everything serializes as 'null', where
+    // an embedded EXTERNAL frame still fails the gate by carrying its
+    // own real origin, and a sandboxed child of such a frame is excluded
+    // by the own-child-frames check plus uuid unguessability). Shape is
+    // deny-by-default: one request form, one reply form, no error
+    // replies.
+    // window.origin is the SERIALIZED SECURITY origin ('null' in opaque
+    // contexts such as a sandboxed preview iframe) — location.origin is
+    // computed from the URL and stays 'https://…' even when the document
+    // is sandboxed, which would misgate every opaque chain.
+    const OWN_TARGET = /^https?:[/][/]/.test(window.origin || '')
+      ? window.origin
+      : '*';
+    function trustedOrigin(e) {
+      if (e.origin === window.origin) return true; // https chains; opaque==opaque
+      // file:// trees: Chrome serializes the file document's origin as
+      // 'file://' while the blob: documents it mints serialize as 'null',
+      // so the two legitimate shapes can never string-match — accept the
+      // pair in both directions. https origins never serialize as either,
+      // and sender identity (own child frame / direct parent) is checked
+      // separately.
+      return (
+        (e.origin === 'null' &&
+          (window.origin === 'file://' ||
+            window.location.protocol === 'file:')) ||
+        (/^file:/.test(e.origin) && window.origin === 'null')
+      );
+    }
+    // Non-empty only in the root document (nested bundles ship an empty
+    // island), so it doubles as the root marker: the root answers from
+    // local text and treats a miss as authoritative — never relaying to
+    // its (possibly foreign) parent.
+    const isPageRoot = pageOrder.length > 0;
+    const blobUrls = {};
+    const resourceBlobs = {};
+    const UUID_SHAPE = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/;
+    const pendingFrames = {}; // uuid -> [{el, frag}] awaiting text for own frames
+    const pendingRelays = {}; // uuid -> [childWindow] awaiting text to pass down
+    function mountPage(el, frag, text) {
+      const pageBlob = new Blob([text], { type: 'text/html' });
+      const u = URL.createObjectURL(pageBlob);
+      resourceBlobs[u] = pageBlob;
+      el.src = u + frag;
+    }
+    function deliverPage(uuid, text) {
+      const frames = pendingFrames[uuid];
+      delete pendingFrames[uuid];
+      if (frames) for (const f of frames) mountPage(f.el, f.frag, text);
+      const relays = pendingRelays[uuid];
+      delete pendingRelays[uuid];
+      if (relays) {
+        for (const cw of relays) {
+          try { cw.postMessage({ __bundler_page: uuid, __bundler_text: text }, OWN_TARGET); } catch (err) { /* gone */ }
+        }
+      }
+    }
+    function ownFrameWindows() {
+      const out = [];
+      for (const f of Array.from(document.querySelectorAll('iframe'))) {
+        try { if (f.contentWindow) out.push(f.contentWindow); } catch (err) { /* detached */ }
+      }
+      return out;
+    }
+    window.addEventListener('message', function (e) {
+      const d = e.data;
+      if (!d || typeof d !== 'object' || !e.source) return;
+      // Origin gate first; the structural checks below (own-child-frames
+      // for requests, direct-parent + solicited-uuid for replies, the
+      // root's never-relay rule) are what hold in fully opaque chains
+      // where origin strings can't discriminate — a sandboxed root's
+      // FOREIGN wrapper still fails all three even though both serialize
+      // as real-vs-'null' rather than matching.
+      if (!trustedOrigin(e)) return;
+      if (typeof d.__bundler_need === 'string' && UUID_SHAPE.test(d.__bundler_need)) {
+        // Requests are honored only for this document's own child frames.
+        if (ownFrameWindows().indexOf(e.source) < 0) return;
+        const uuid = d.__bundler_need;
+        const text = pageTexts[uuid];
+        if (typeof text === 'string') {
+          try { e.source.postMessage({ __bundler_page: uuid, __bundler_text: text }, OWN_TARGET); } catch (err) { /* gone */ }
+          return;
+        }
+        if (isPageRoot || window.parent === window) return; // authoritative miss
+        const waiting = pendingRelays[uuid];
+        if (waiting) {
+          if (waiting.indexOf(e.source) < 0) waiting.push(e.source);
+          return;
+        }
+        // Never-answered uuids would otherwise accumulate forever under a
+        // request spray; past the cap (far above any real page count) new
+        // relays are dropped rather than remembered.
+        if (Object.keys(pendingRelays).length >= 128) return;
+        pendingRelays[uuid] = [e.source];
+        window.parent.postMessage({ __bundler_need: uuid }, OWN_TARGET);
+      } else if (
+        typeof d.__bundler_page === 'string' &&
+        UUID_SHAPE.test(d.__bundler_page) &&
+        typeof d.__bundler_text === 'string'
+      ) {
+        // The shape test is load-bearing beyond tidiness: the solicited
+        // check below uses the in operator, which matches prototype keys
+        // ('__proto__', 'constructor') — an unshaped key would reach
+        // deliverPage and throw, painting the error banner.
+        // Text is accepted only from the direct parent — the document
+        // that minted this one.
+        if (e.source !== window.parent || window.parent === window) return;
+        if (!(d.__bundler_page in pendingFrames) && !(d.__bundler_page in pendingRelays)) return;
+        deliverPage(d.__bundler_page, d.__bundler_text);
+      }
+    });
+
+    const uuids = Object.keys(manifest);
+    setStatus('Unpacking ' + uuids.length + ' assets...');
+
+    await Promise.all(uuids.map(async (uuid) => {
+      const entry = manifest[uuid];
+      try {
+        const binaryStr = atob(entry.data);
+        const bytes = new Uint8Array(binaryStr.length);
+        for (let i = 0; i < binaryStr.length; i++) bytes[i] = binaryStr.charCodeAt(i);
+
+        let finalBytes = bytes;
+        if (entry.compressed) {
+          if (typeof DecompressionStream !== 'undefined') {
+            const ds = new DecompressionStream('gzip');
+            const writer = ds.writable.getWriter();
+            const reader = ds.readable.getReader();
+            writer.write(bytes);
+            writer.close();
+            const chunks = [];
+            let totalLen = 0;
+            while (true) {
+              const { done, value } = await reader.read();
+              if (done) break;
+              chunks.push(value);
+              totalLen += value.length;
+            }
+            finalBytes = new Uint8Array(totalLen);
+            let offset = 0;
+            for (const chunk of chunks) { finalBytes.set(chunk, offset); offset += chunk.length; }
+          } else {
+            console.warn('DecompressionStream not available, asset ' + uuid + ' may not render');
+          }
+        }
+
+        if (pageSet.has(uuid)) {
+          pageTexts[uuid] = new TextDecoder().decode(finalBytes);
+          return;
+        }
+        if (FONT_MIME.test(entry.mime) && MIME_TOKEN.test(entry.mime)) {
+          // Strict artifact hosts allow font-src data: but not blob:.
+          blobUrls[uuid] = 'data:' + entry.mime + ';base64,' +
+            (entry.compressed ? toBase64(finalBytes) : entry.data);
+        } else {
+          const blob = new Blob([finalBytes], { type: entry.mime });
+          blobUrls[uuid] = URL.createObjectURL(blob);
+          resourceBlobs[blobUrls[uuid]] = blob;
+        }
+      } catch (err) {
+        console.error('Failed to decode asset ' + uuid + ':', err);
+        const blob = new Blob([], { type: entry.mime });
+        blobUrls[uuid] = URL.createObjectURL(blob);
+        resourceBlobs[blobUrls[uuid]] = blob;
+      }
+    }));
+
+    const extResEl = document.querySelector('script[type="__bundler/ext_resources"]');
+    const extResources = extResEl ? JSON.parse(extResEl.textContent) : [];
+    const resourceMap = {};
+    for (const entry of extResources) {
+      if (blobUrls[entry.uuid]) resourceMap[entry.id] = blobUrls[entry.uuid];
+    }
+
+    // Artifact-host CSP (connect-src 'self') refuses fetch() of blob: URLs —
+    // consumers read these Blobs directly. Survives the swap like the error sink.
+    window.__resourceBlobs = resourceBlobs;
+
+    setStatus('Rendering...');
+    // Page uuids have no blob here — they ride inside about:blank#<uuid>
+    // frame markers the pass below resolves after the swap.
+    for (const uuid of uuids) {
+      if (pageSet.has(uuid)) continue;
+      template = template.split(uuid).join(blobUrls[uuid]);
+    }
+
+    // Strip integrity + crossorigin — blob URLs from a file:// document inherit
+    // a null origin, so crossorigin forces a CORS fetch that SRI then rejects.
+    // The manifest bytes are ours; SRI protects against CDN compromise, not this.
+    template = template.replace(/\s+integrity="[^"]*"/gi, '').replace(/\s+crossorigin="[^"]*"/gi, '');
+
+    const resourceScript = '<script>window.__resources = ' +
+      JSON.stringify(resourceMap).replace(/<\//g, '<\\/') +
+      ';</' + 'script>';
+    // Inject after <head> so the DOCTYPE stays first; prepending the script
+    // would push the parser into quirks mode. DOMParser always emits a <head>
+    // (synthesizing one if the source HTML omitted it) but may carry
+    // attributes through, so match the full opening tag. slice() rather than
+    // replace() keeps us clear of $-pattern substitution in resourceScript.
+    const headOpen = template.match(/<head[^>]*>/i);
+    if (headOpen) {
+      const i = headOpen.index + headOpen[0].length;
+      template = template.slice(0, i) + resourceScript + template.slice(i);
+    }
+
+    // Parse the template and swap the root element. Scripts inserted via
+    // DOMParser/replaceWith are inert per spec — re-create each with
+    // createElement so they execute, awaiting onload for src scripts to
+    // preserve ordering (React before ReactDOM before Babel before text/babel).
+    const doc = new DOMParser().parseFromString(template, 'text/html');
+    document.documentElement.replaceWith(doc.documentElement);
+
+    // Resolve page-frame markers: mint this document's own blob for each
+    // framed page — from local text when this is the root, otherwise by
+    // asking the direct parent over the relay protocol above. An
+    // unanswered request leaves the frame on about:blank, the same
+    // degraded state as a refused embed.
+    {
+      const MARKER = /^about:blank#([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})(#.*)?$/;
+      const needed = [];
+      for (const el of Array.from(document.querySelectorAll('iframe'))) {
+        const m = MARKER.exec(el.getAttribute('src') || '');
+        if (!m) continue;
+        const text = pageTexts[m[1]];
+        if (typeof text === 'string') {
+          mountPage(el, m[2] || '', text);
+        } else if (window.parent !== window && !isPageRoot) {
+          const had = pendingFrames[m[1]];
+          (pendingFrames[m[1]] = had || []).push({ el: el, frag: m[2] || '' });
+          if (!had) needed.push(m[1]);
+        }
+      }
+      for (const uuid of needed) {
+        window.parent.postMessage({ __bundler_need: uuid }, OWN_TARGET);
+      }
+    }
+
+    const dead = Array.from(document.scripts);
+    for (const old of dead) {
+      const s = document.createElement('script');
+      for (const a of old.attributes) s.setAttribute(a.name, a.value);
+      s.textContent = old.textContent;
+      // text/babel scripts with a src: read and inline. transformScriptTags
+      // does XHR against the src, but blob:null/ from a file:// origin is
+      // silently dropped. Inlining makes it a plain inline babel script,
+      // which transformScriptTags handles unconditionally.
+      if ((s.type === 'text/babel' || s.type === 'text/jsx') && s.src) {
+        const pre = resourceBlobs[s.src.split('#')[0]];
+        s.textContent = pre ? await pre.text() : await (await fetch(s.src)).text();
+        s.removeAttribute('src');
+      }
+      const p = s.src ? new Promise(function(r) { s.onload = s.onerror = r; }) : null;
+      old.replaceWith(s);
+      if (p) await p;
+    }
+    // Babel standalone auto-transforms type=text/babel on DOMContentLoaded,
+    // which fired before we swapped the document. Trigger manually if present.
+    if (window.Babel && typeof window.Babel.transformScriptTags === 'function') {
+      window.Babel.transformScriptTags();
+    }
+  } catch (err) {
+    setStatus('Error unpacking: ' + err.message);
+    console.error('Bundle unpack error:', err);
+  }
+});
+
+  </script>
+
+  <script type="__bundler/manifest">
+{"b04ad76c-d925-4bfb-8239-f9fbb800ffcc":{"mime":"text/javascript","compressed":true,"data":"H4sIAAAAAAAAA91963rcNpLo/zwFxPHYpNRNXWI7ScttjS3JjhPJ8khyMrOSRmKT6G5KbJIm2LpE7u/bh9gn3Cc5XxXuIFuXJLPn7Jn91lGDQKFQKBQKVYXC8jJ5v/1xe//N4fYWGVbFhCRxt5rmdTqhy6yKlxfDmpH//s//IklB8qImNEnrkOzTwTTNEnKV1mNyFidGK/L0KRlMc1JNc4KVzsJvvCmjhNVVGtfe+je+H5D+a3L7DSGXUUVOTxM6/FQVJemTvcE5jeswocM0p1BGq/pm3az4sagmUSaq+8XgvEMu6E2HXEbZlCLcC3pD0pwUg3OyoYEbVW8JzacTWkWDjPZIXU1ph8RFPkxHU6vsqkpr8zd2QWYB6QHwowt6c0L6vFSjWE4HWRq/S2mWzEPQGQevU9+UtBgi8gv9PvHYzWRQZB7ZwKIl4nmkZwJa/+YbQpaXCcxRRaO4Dmv2DSHDaR7XaZGTEa33odgPkNAERshqsk/65CrNk+IqxM/r+C0dEn9hPyD1uCquSE6vyHZVFZXv6WntWc1IypAbossozYBG5IbWXsChVbSeVjnZh1+zNpy29nZdtLYcvLb2dk3Uth6B29be7oPQ25L4wcSNYbL8MAyjasRwljQBw7iiUU23Mzqhee0jEFHzG0ICayrKqGLUmQos24q3iniKAJIitkefxKRPkiIOv0xpdXNAMxrXMMLrbhJLrJEOSRxI9PNplq0bMFhcpWW9nbVD4l+PkqiOuknc5T9PJGwO4ZaUVVGyDikrepnSKzIjfYF7VEfAqYyPnajONsIRrd/UdZUOpjX1PYSPULyAbGwgktjEJv2tAFPTSZlFNe2RJA7TPKfVj4e7Ox3x9Zz19Kg21J9hTa/rzSKvaV6Tr1/5wvA82YqPQf3AkeCvWYMdxbwc0uvaZ5UzJ0VJ892ojoExll/BTPgbvWN29K/XJ4vBxuvlkF7TGJsZ86MazZ2mOCsYJX3glTCLWP0hT+j13tD3Xi1DH6/N6RZ1+33SXYWR8t+vNGphCq3n9iXJK7pjWRpT32lMljS4o5WTMKP5qB53eF8WeyQFcCmsv6293U9AusoPQqThu6qYHNRVmo+AIB3iwRQtj+tJZnPY/2Ye/R/mSjWaKrqSjIkshr8ljhxuD8egaMJ/csiEZLTmIBP+u65u1Nh4OemTnw72PvKpxP54zRmJkf9l7Ud0OtP4ij6+fpU7nCjATa7A7d6Dr2+qKroJU4b/9XmlIPj9nYtVPDiXDJKYfCTZpw81wify59OnEkuruG/iumF/6zWWXUVZTfrkVqAzLCri8y8XpBhKFeeC3jDY+Y0xAr0ujlZOOG2eeAGCOro44WgeXZyYA3QpYsKFdoFYy2SDY+TQrIXzkvhjNMHF/Cmqx34Z1eM8mlCJIHISUpOXczZv4SpY3jQuEvp5/8NmMSmLHHa9spWtzMkaRCgay5CVWVr73rIXhGVR+gH2tF8UtWctUagfVrTMopj6y8dhEh+HIHSeLHeI5wXmJyjeEOU2tJmxeQ+KQqhRoBK8fXOwfbp5cED65Izv+SzuIsRxkSW0uh1E8cWoKqZ50ouLrKi6k/TaT3PCqtGgE0+riub1Jnwg3/+1U1dRzsoIygQhCBkUVUKr3mp5TViRpQm5B8yLlbvgdKsoSaest1Zerw+K6y5Lf0vzUU98HBTX68UlrYZZcdUbp0lCc077v13Qm2EVTSgjLO6ycZrT25W/GoPrlgVLgUF6qysrfwUkZvBHaw3xnUMGogPNQJjXFY0maT5yidi5u2aa17Qq4a9Jyliaj25VVxXNojq9pIoID56NF3dSERv3jAoPH0yvN6DDoqKPHZRsdxvzDaT37JlESg03GrAim9Z0Pc0ZrXsr62WBcLr0kuY16+VF3kaKLM1pVHVHwBuwCn9YSeioU40Gkb+2+l1ndfWHzvffdVYCsvbir6L4+XedtbUXnbXV1U74w4uAfPvdX9savPz2r0GzQ+A62nsOjAJMsh7l6STCAUjmIqvhc0YorPU0H6Z5WtNHUDivx914nGaJny/9AOLUqRD87jlohdyopuDf6pHNIf3jZMKsTcR0KRx1bssoSQDF5+U1+b68Xh8Wed1bXS2vl1fD52SadidFXrAyimlH/SUR4ux8Dy7fuYLlqqiS7qCi0UUP/+1CgUaxuSyTlJVZdNNLc+C47iAr4ov1qzSpx701Olkf03Q0rnurdOIKIYnnJa3qNI6ybpSlo7wH6lR3UNR1MVk3aMr58MWLjvz/8NtgvSFGsdZKB/4vfPFoKdkQABLAlNGqy1BfxTlvo8c0rygrskua3MIsdYfRJM1uenPmCKvgigm/f0Enj5qzuZvBgzlw1YVgU+jb8lpJIcGAK+Tb8loPe1ywGv8bMcmprnTWlbNilMZuNSXV6qLsAWtndFjjH7918XzSW1t9/t3z7799+fy79Ul03eUs9XIlHru4vSyvyeoKzKomwF8GKysraytiSv8yHA7F2ll70Nqx6fG8vF6/Gqc17WKlXlnR7lUVlW2SmA97eZHspjBgRj7tf/h4eAoqxc6Hj1ytSHMSlSVbvqID0JcuuqyORrRLr8uiAjWEHE/XVlafkwtKSzIo6rHAChqymzwmYPzITMtbRUdRmjMSccMbYTUtQ7K4zPf5CU3SiJRVmtdKV/tbGY0ouSWTqBqleY+shC/iybrQyghBkxjtEDSDkVvCZUGaszShPRJdFmmiK/8FMCmKuqP+Iq8Vm5BbImQAiaZ1oVstdsiiktnwZzSsaaUQJBxhvit3o+R8yuoeoddguiLdKzq4SOvu/CoKCjBFUhVld5hmNa16BGaJLKQTIHaUG8Duralgqh2gm1CQfaT7ww/MgmnUmFZ8syDhysoquwdeWlNevRsX07zukdU5YIdplnUnBcwGcMg9YEFCA5eBxaWa5jlshiZcFAapg+9KG7IzpbyfSdPnu887O6ef3ryXOrMHe29nUCQ3t1L6g0IgOG1lpthF/vFa8opZf4ZKujqiQD08pBSVaU7rkEzb1OCcApo8HGJIH76EbUcWPJ0ap4aNJ8tpWFNW+ywa0i08wPgSTmAc08yzDjF7AtvI5/0dQCiEs8nn/Q/YIZ5jBAaKgM7hWhNUHW+c45hCpXFuM/BlEk0TSQmveSZjdx/1mT5vWh0CKr4QOh1hGErEdNhWNGVhaLOBGvMgzvvzLFnc5tw3bLLWgVswBenfyR/Iz9LIw5EPJ1F18Y7W8ZgmvmzrVGG03hdf5lWJkqKs0SSmoXTE2M1RCiv16SnoCNMqpkxz1RCw8CWa4biiwyCsxzT34TSPFumKsrC44Od5tDf5ARqZZL1auVWkGoHUicDMUZMNy95ZB5blQqJYRVcboTR5BWqA0zKJavpjPcmM8VXRla6q+DoIkZUMHw8vbtpmHmL15jVBKCiroW2M95L0Ulbm1cIU+M0TQkUs9iSW1oBf03rs85pNBgyFcURPizBctvfN6puMemrszDIC9m2JKCsBmDGNkjAqS5onm3jiYC3kAaYDjhZTMKL11qbLgLwmzWG166oVHaWsrm6gjdtCreGDOsqTKCtyCh357oiPOoTR+jCN0fqEiy6cMnoAm4e/ooasPmwPhzSunVlX5JsOwL2C3wRU38/xZ06WyGqgmRDHErLpgIVRkvhsOjA+CungdmK1SmhGa+o0nCn27JCjE/VB8CEdRtOsZuY4d+mkmDOYxLDtEde+l+YCFzTK7dI6gh3gdhZY6PLal6TvVt4Ijy5ONkKB0brRBJj0Eg2DoHSRlYAk3DB4aYzSJVRiDtvpSlNBVB77+6i83YJvS9KkAz90y71LWlVpQhkfVeuyVj64vu3v04tNlonlBN0GJj/Zn+RiDSuaJ7Tyx77NuoGATDNGdft5lTvEWvti7HKRuAZBel1W2iD4YWv74+Hp/jZ4hP519Kb7H1H3t9MnJ+Kvle4Pp09OFpelPvTx8+7b7X1ZvbtxnCz5x+FxshRsPFm2lRp+YvQvo4x1SMMTBUiQPtEOliCsq3RiUnQB6qjdk3OI/gofwayMZmzfAys3FuHohJG4S1ZFhQAr4JGQ/VpF5a/jIqMIo2mOtzFHeNzLtNoh3dWghTvoF9InwzRPDotyh17SbPvLNMrS+ob3YCD9xRVJGSyYuT2udAj9IhxizgKv7mwoW5ElAFCUgiIaCLtKQTfy8au5kGOwYXn9ft/rGStVkAaw7fdJZaxPXn9hbv2F1vp3gLdqiyU7D7RR19Q1G/yx4Ck+Wpg/vUFgsxdvC2ESujn8aqs1jDJmVMOfbfVAO/FaVEK71jTnwSKJN5f/1Urk6r1gZVH543QyoFWD+4yl8bpP1mBJWHR65j0DGWiR7pkX3L22RO3GMmosnBY/j5gLPAro+WgeBloXrnEySmiJh5UVwzsF5SmWkZS8Ig7u6yRdWrK9VDiQVEmUgENdWpIchrK4UTHwzNWDTbpdW/8U2PX7sMM1GaT1nCT5zCLDfBHzu2nh0EH484mY1vRk3SBQzEd8hK7N+H46iSonZv1A1tdEUvUNOiFriiZ9s/2CwY4pqFknspI5DQAtJa8FHFG5a1RWbG4WL3hBABSo03xK7SlcsIVyKnertvoy1EIRkSyRNd3zBokh8qnfB2c6/9NraIO3hBsKSdoBSLM7OEXKkFnL7usuLGsLBoVd4BhO8HgjdQFzE4ZarUIIeCqeVjxYjIHgRn/1hqhEelh+BO2PVk5OdCNgRFEqmRC/XY3TjMK8WQx6xxoNrTnng5rIEfG5QhYJ3OHJ2W+rtPyv42RpOXCmf9JKAuwWSYD/NikQT6ujiR49giNLfbJKlsjEHT9YLNplzJE1UHORr65bxRAXgKPRxYKq544IfPpUwHgNQsnU41Xv50bvzhJvikNZ+cSzobWIxFaxiEZYs87M+Pvc7Hn2TRPLine truncated
+  </script>
+
+  <script type="__bundler/ext_resources">
+[{"id":"https://unpkg.com/react@18.3.1/umd/react.production.min.js","uuid":"d48860b1-c58f-4a75-b146-62b4161ed769"},{"id":"https://unpkg.com/react-dom@18.3.1/umd/react-dom.production.min.js","uuid":"a6ec313f-b019-4ed4-afce-55bc02fb363d"}]
+  </script>
+
+  <script type="__bundler/page_order">
+[]
+  </script>
+
+  <script type="__bundler/template">
+"<!DOCTYPE html>\n<html><head>\n<meta charset=\"utf-8\">\n<meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">\n<script src=\"b04ad76c-d925-4bfb-8239-f9fbb800ffcc\"><\u002Fscript>\n<\u002Fhead>\n<body>\n<x-dc>\n<helmet>\n<style>\n@page { size: A3 landscape; margin: 8mm; }\nbody { margin: 0; background: #0b1220; -webkit-font-smoothing: antialiased; }\na { color: #60a5fa; text-decoration: none; }\na:hover { color: #93c5fd; }\n@media print { body { background: #0b1220; -webkit-print-color-adjust: exact; print-color-adjust: exact; } }\n<\u002Fstyle>\n<\u002Fhelmet>\n\n<div style=\"background:#0b1220;font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif;color:#e8eef8;padding:40px 0 56px;min-width:1600px\">\n<div style=\"width:1600px;margin:0 auto\">\n\n  <div style=\"display:flex;align-items:flex-end;justify-content:space-between;gap:40px;padding-bottom:18px;border-bottom:1px solid #1f2c44\">\n    <div>\n      <div style=\"font-size:28px;font-weight:600;letter-spacing:-0.01em\">Where Felhom stands<\u002Fdiv>\n      <div style=\"font-size:12px;color:#8ea0ba;margin-top:6px;max-width:820px;line-height:1.5\">What we built, what happens when things go wrong, and what is still missing. Built from the project's own capability map, register and audit records — not re-verified against source for this drawing.<\u002Fdiv>\n    <\u002Fdiv>\n    <div style=\"display:flex;gap:26px;align-items:flex-start;flex:0 0 auto\">\n      <div style=\"display:flex;gap:8px;align-items:flex-start\"><span style=\"width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px\"><\u002Fspan><span style=\"font-size:12px;color:#8ea0ba;line-height:1.4\"><span style=\"color:#e8eef8;font-weight:500\">Walked<\u002Fspan><br>done end to end on real<br>hardware, evidence on file<\u002Fspan><\u002Fdiv>\n      <div style=\"display:flex;gap:8px;align-items:flex-start\"><span style=\"width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px\"><\u002Fspan><span style=\"font-size:12px;color:#8ea0ba;line-height:1.4\"><span style=\"color:#e8eef8;font-weight:500\">Built<\u002Fspan><br>shipped and tested, the real<br>path never walked<\u002Fspan><\u002Fdiv>\n      <div style=\"display:flex;gap:8px;align-items:flex-start\"><span style=\"width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px\"><\u002Fspan><span style=\"font-size:12px;color:#8ea0ba;line-height:1.4\"><span style=\"color:#e8eef8;font-weight:500\">Partial<\u002Fspan><br>some walked, some not —<br>the note says which<\u002Fspan><\u002Fdiv>\n      <div style=\"display:flex;gap:8px;align-items:flex-start\"><span style=\"width:8px;height:8px;border-radius:50%;background:#64748b;flex:0 0 8px;margin-top:5px\"><\u002Fspan><span style=\"font-size:12px;color:#8ea0ba;line-height:1.4\"><span style=\"color:#e8eef8;font-weight:500\">Missing<\u002Fspan><br>does not exist<\u002Fspan><\u002Fdiv>\n      <div style=\"display:flex;gap:8px;align-items:flex-start\"><span style=\"color:#fbbf24;font-size:12px;margin-top:2px\">⚠<\u002Fspan><span style=\"font-size:12px;color:#8ea0ba;line-height:1.4\"><span style=\"color:#e8eef8;font-weight:500\">Contested<\u002Fspan><br>two records disagree —<br>see the note<\u002Fspan><\u002Fdiv>\n    <\u002Fdiv>\n  <\u002Fdiv>\n\n  <sc-if value=\"{{ showBand0 }}\" hint-placeholder-val=\"{{ true }}\">\n  <div style=\"padding-top:26px\">\n    <div style=\"font-size:22px;font-weight:600;margin-bottom:4px\">The four parts, and who talks to whom<\u002Fdiv>\n    <div style=\"font-size:12px;color:#8ea0ba;margin-bottom:16px\">Orientation only — no status here.<\u002Fdiv>\n    <div style=\"display:grid;grid-template-columns:1fr 1fr 1fr 1fr 1fr;gap:14px;align-items:stretch\">\n      <div style=\"background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 16px\">\n        <div style=\"font-size:14px;font-weight:500;margin-bottom:2px\">The customer's machine — host side<\u002Fdiv>\n        <div style=\"font-size:12px;color:#60a5fa;font-family:ui-monospace,SFMono-Regular,Menlo,monospace;margin-bottom:8px\">felhom-agent<\u002Fdiv>\n        <div style=\"font-size:12px;color:#8ea0ba;line-height:1.5\">Runs on their Proxmox. Owns the disks, the guest, the whole-machine backups and the tunnel. The only part that talks to Proxmox.<\u002Fdiv>\n      <\u002Fdiv>\n      <div style=\"background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 16px\">\n        <div style=\"font-size:14px;font-weight:500;margin-bottom:2px\">The customer's machine — inside the box<\u002Fdiv>\n        <div style=\"font-size:12px;color:#60a5fa;font-family:ui-monospace,SFMono-Regular,Menlo,monospace;margin-bottom:8px\">felhom-controller<\u002Fdiv>\n        <div style=\"font-size:12px;color:#8ea0ba;line-height:1.5\">Runs their apps, owns their files and their app backups, serves the Hungarian dashboard. Never sees Proxmox credentials.<\u002Fdiv>\n      <\u002Fdiv>Line truncated
+  </script>
+</body>
+</html>

documentation/architecture/where-felhom-stands.html

@@ -0,0 +1,46 @@
+<!DOCTYPE html>
+<html lang="en"><head><meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Where Felhom stands</title><style>
+@page{size:A3 landscape;margin:8mm}*{margin:0;padding:0;box-sizing:border-box}body{background:#0b1220;color:#e6edf7;font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,sans-serif;-webkit-font-smoothing:antialiased;padding:26px 20px}.wrap{max-width:1600px;margin:0 auto}.grid7{display:grid;grid-template-columns:repeat(7,1fr);gap:12px;align-items:start}.grid4{display:grid;grid-template-columns:repeat(4,1fr);gap:12px;align-items:start}.grid3{display:grid;grid-template-columns:repeat(3,1fr);gap:12px;align-items:start}h1{font-size:22px;font-weight:600;letter-spacing:-.2px}a{color:#60a5fa}@media print{body{padding:0}.grid7{grid-template-columns:repeat(7,1fr)}}
+</style></head><body><div class="wrap">
+<h1>Where Felhom stands</h1>
+<div style="color:#8fa0b8;font-size:12.5px;margin:7px 0 4px;max-width:1100px;line-height:1.5">What we built, what happens when things go wrong, and what is still missing. <b style="color:#cbd7e8">Generated from <code>where-felhom-stands.yaml</code></b>, which cites the capability map, register row or evidence document behind every claim — and which is checked by <code>scripts/check_stands.py</code>.</div>
+<div style="color:#6b7a91;font-size:11.5px;margin-bottom:16px">Verified 2026-08-22 against felhom-agent <code>40d857b527</code>, felhom-controller <code>2da259af38</code>, hub <code>877fcd2a38</code>. <b style="color:#fbbf24">15 claim(s) carry a recorded status move</b> (8 re-checked in this pass) — each is marked on the page.</div>
+<div style="display:flex;gap:22px;flex-wrap:wrap;background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:11px 14px;margin-bottom:18px"><div style="display:flex;gap:8px;align-items:flex-start"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:11.5px"><b>Walked</b> <span style="color:#7c8aa3">(20)</span><span style="display:block;color:#6b7a91;font-size:10.5px">done end to end on real hardware, evidence on file</span></span></div><div style="display:flex;gap:8px;align-items:flex-start"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:11.5px"><b>Built</b> <span style="color:#7c8aa3">(14)</span><span style="display:block;color:#6b7a91;font-size:10.5px">shipped and tested, the real path never walked</span></span></div><div style="display:flex;gap:8px;align-items:flex-start"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:11.5px"><b>Partial</b> <span style="color:#7c8aa3">(17)</span><span style="display:block;color:#6b7a91;font-size:10.5px">some walked, some not — the note says which</span></span></div><div style="display:flex;gap:8px;align-items:flex-start"><span style="width:8px;height:8px;border-radius:50%;background:#64748b;flex:0 0 8px;margin-top:5px"></span><span style="font-size:11.5px"><b>Missing</b> <span style="color:#7c8aa3">(4)</span><span style="display:block;color:#6b7a91;font-size:10.5px">does not exist</span></span></div><div style="display:flex;gap:8px;align-items:flex-start"><span style="font-size:11.5px"><b style="color:#7dd3fc">needs-hardware</b><span style="display:block;color:#6b7a91;font-size:10.5px">only a running box could settle it</span></span></div></div>
+<div style="font-size:15px;font-weight:600;margin:0 0 9px">The journey</div>
+<div style="color:#6b7a91;font-size:11.5px;margin-bottom:10px">Seven stages, left to right, as they happen to a person.</div>
+<div class="grid7">
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44"><span style="color:#4b5b76;font-family:ui-monospace,monospace">1</span> &nbsp;Getting a box</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A blank machine installs itself from our own boot image and registers itself as unclaimed — proven on two different boards<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Two boards: N100 2026-07-18, HP t740 2026-07-21.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Bare-metal Felhom ISO (blank hardware → zero-touch auto-ins… · evidence tests/VALIDATION-n100-rehearsal-2026-07-18.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The installer is published rather than pushed: rolling it back is one act<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Gate 6 of hostinstall_gates asserts the manifest names an installer-v tag; ran green tonight.</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: gate 6 asserts the manifest names an installer tag, but no walk of a rollback is on file</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map The installer is PUBLISHED, not pushed · register R-110</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Installing onto hardware the customer already owns — the path exists, the first real one has not happened<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">UPGRADED: a real --mode byo install completed on demo-hp 2026-08-09 (Day-0 provision SUCCESS, 3m49s). Still not a customer's own hardware, so not 'walked' — but 'has not happened' is now false.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A machine that ends up on the wrong network port explains itself on screen and finds its way back — proven in a virtual drill, never on metal<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Map says the same: PROVEN-LIVE (nested drill — nested != metal).</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Box survives a wrong-NIC install · evidence audits/SPIKE-firstboot-nic-sweep-2026-07-22.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Reinstalling a machine we previously installed refuses, because our own removal leaves a name service holding the port our own installer checks<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Warning card. Confirmed live 2026-08-09; dnsmasq restarted by --uninstall seizes :53.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-272 · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44"><span style="color:#4b5b76;font-family:ui-monospace,monospace">2</span> &nbsp;Making it theirs</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">An emailed one-time code; the customer sets their own password and the operator never sees it<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Exercised live 2026-08-09: reset code accepted at /claim, 302 + session.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Customer claim: one-time emailed code → customer sets own p… · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The customer can bind their own machine from a link, with no operator present — done once, for real<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">attempts=0, locked=0, source customer_selfbind, 2026-07-18.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Customer binds their own appliance (self-service) · evidence tests/VALIDATION-n100-rehearsal-2026-07-18.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">It has never been done by a person who is not the operator<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Map records MISSING (as evidence). Still true after 2026-08-09.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map A customer (not the operator) performs a restore via UI alone</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The same word is used for two different secrets across three surfaces; the email points at a page a rebuilt machine does not show<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Warning card. Cost a real code on 2026-08-09.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-282 · register R-283</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44"><span style="color:#4b5b76;font-family:ui-monospace,monospace">3</span> &nbsp;Using it</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Apps installed from a catalog of about 52, with a memory guard and health-aware progress<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">53 templates listed on the rebuilt box 2026-08-09; deploy driven live.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Deploy an app from the catalog (env config, memory guard, h… · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Start, stop, restart, update, logs, remove — and the parts that must not be stopped cannot be<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: no walk document cited by the map row or anywhere else</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map App lifecycle: start/stop/restart/update/logs/remove/redeploy · register R-108</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Reachable from anywhere through a tunnel, per-app addresses<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Verified tonight: the rebuilt box answered on its public URL from outside.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Remote access via Cloudflare Tunnel + Traefik (per-app subd… · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Reachable on the home network when the internet is down<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#1b2740;color:#7dd3fc;font-size:10px;white-space:nowrap">needs-hardware</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Only an observation on a running box with WAN pulled could settle it. Boxes are off.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map LAN access when internet is down (lan_resolver)</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Phone photos, documents with text recognition, files from Windows Explorer or a Mac<span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Files from Windows Explorer / Mac Finder (SMB server) · evidence audits/SPIKE-lan-discovery-2026-07-18.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A one-tap launcher, and a read-only guest link for visitors<span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Indítópult (app launcher) — one-tap grid of the household's…</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#64748b;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-heigLine truncated
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44"><span style="color:#4b5b76;font-family:ui-monospace,monospace">4</span> &nbsp;Drives</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A new drive is found, offered, formatted, mounted and enrolled — including on awkward older boot layouts<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">moved twice: 2026-08-09 walked -&gt; built, then 2026-08-10 back to walked</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Applies to a NEW drive. Re-attaching an existing one after a reinstall is R-280 and fails.</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: receipt found 2026-08-10: a live throwaway drive on felhom-pve walked scan -&gt; format -&gt; mount -&gt; PVE dir storage -&gt; one-click Regisztralas, with the resulting storage.cfg entry and systemd mount unit recorded. The map already read PROVEN-LIVE; the dataset was behind it. Scope unchanged: this is a NEW drive. Re-attaching an existing one after a reinstall is R-280 and still fails.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Drive wizard: scan/format/mount/enroll, incl. legacy-boot L… · register R-220 · evidence audits/SPIKE-raw-drive-enroll-2026-06-15.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Moving data between drives, crash-safe; removing a drive safely; unplug detected<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: no walk document cited</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Data migration between drives (all / per-app), crash-safe</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A network drive can be browsed and hold bulk media, but may not hold an app's data — enforced<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">RefuseAsAppNamespace is the fail-closed predicate.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Network storage (NAS) is browse + bulk-media only · register R-108 · evidence audits/R108-network-app-namespace-2026-07-30.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">After a reinstall the data drive cannot be re-attached through any dashboard route<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Warning card. /api/disks/candidates returns empty; the restore page promises two clicks.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-280 · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44"><span style="color:#4b5b76;font-family:ui-monospace,monospace">5</span> &nbsp;Backing up</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">App data on the machine, nightly database dumps, a copy on a second drive<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">moved twice: 2026-08-09 walked -&gt; built, then 2026-08-10 back to walked</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">True for every app but one, and that one was found on 2026-08-21: paperless-ngx's 72-table PostgreSQL was dumped nightly and written into a folder named after an app that does not exist, so it never entered the recovery unit, the second-drive copy or the off-site copy. Fixed and proven live 2026-08-22 (R-355) — the dump is now in the app's own unit and in the off-site snapshot for the first time. A catalogue-wide sweep, itself proven able to convict a planted case, says 1 of 53 was affected.</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: receipt found 2026-08-10: an adversarial, destructive, unattended overnight campaign across both boxes and ep0, with A2 (one quiesce, two tiers) proven end to end. Map already read PROVEN-LIVE.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Tier-2 secondary-drive copy: class-driven legs · register R-355 · evidence audits/CAMPAIGN-8-backup-restore-2026-07-27.md · evidence audits/DRILL-backup-truth-2026-08-21/evidence/phase4-paperl…</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A whole-machine archive that lands off the guest's own disk — a single-drive machine is recorded as degraded rather than pretending<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: no walk document cited</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Whole-guest backup lands OFF the guest's own physical device · register R-165</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">An encrypted off-site copy, sealed with a key the operator cannot read<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">The COPY is real and the key is still unreadable to us — what failed is DAILY and UNBROKEN. The 2026-08-09 note said '18 snapshots, daily, unbroken'; the next snapshot after 2026-08-09 08:30 was 2026-08-21 22:17, put there by hand during the drill. Twelve days, no alarm. Two causes in series: the 2026-08-21 rebuild lost the off-box target (R-193's shape), and after the self-heal restored it EVERY per-app switch was still off, so the first run logged 'backup OK: 0 app(s) backed up, 14s'.</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: the claim is about a CONTINUING daily copy; a 12-day silent gap was found on 2026-08-21 and nothing reported it</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Offsite (restic → Hetzner Storage Box) · register R-199 · register R-193 · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md · evidence audits/REPORT-DRILL-backup-truth-2026-08-21.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The backups prove themselves: a restore is actually performed, uLine truncated
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44"><span style="color:#4b5b76;font-family:ui-monospace,monospace">6</span> &nbsp;When something goes wrong</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The machine watches itself and repairs some faults without telling anyone it had to<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">R-264 records that the self-heal counters reach the hub and are decoded nowhere.</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: no walk document cited</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Box survives an unattended app or guest-network failure · register R-264</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Failures reach the operator by email, one mail per run, every failing app named<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">CONFIRMED against source: backup_run_failures digest is allowlisted (api/handler.go:1837), operator-only (dispatcher.go:423), templated (templates.go:48); recovery_unit_capture_failed is record-only (dispatcher.go:376). NOTE: R-182's register row still describes the PRE-FIX behaviour — see R-289.</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: the digest is wired and source-verified, but no run of it has been observed delivering</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map A failed per-app Tier-1 backup reaches the OPERATOR — EVERY… · register R-182</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Failures reach the customer<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">The customer leg is built; today's log shows customer-channel rows skipped as operator_only.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map App crashes → customer notified (one event per transition, …</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">An already-paired box is still told to pair itself<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Warning card.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-214 · register R-235</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44"><span style="color:#4b5b76;font-family:ui-monospace,monospace">7</span> &nbsp;Getting everything back</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A rebuilt machine shows a full-page recovery screen without anyone looking for it, and says plainly that nobody can replace a lost recovery code<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Seen unsought on the rebuilt demo-hp 2026-08-09, seal date matching host_escrow.created_at.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-193 · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The customer's code opens the sealed package and the data returns byte for byte — including accented Hungarian filenames, verified as raw bytes<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Still true, and re-proven 2026-08-22 (5/5 byte-identical, both accented names as raw bytes) — but the SCOPE is narrower than the sentence sounds and was silently narrower still until v0.218.0. The drill found the off-site restore had NO named-volume leg at all: the archive sat in the unit, the snapshot and the checking folder and was never replayed, under a success message (R-354, fixed and proven 2026-08-22). AND 40 of the 53 catalogue apps STILL cannot run this route at all — it refuses first, saying a running app is not installed (R-356, open). So: proven for an app that declares a data drive; unproven and currently unreachable for the class whose entire dataset is a named volume.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-201 · register R-354 · register R-356 · evidence tests/walk5-r201-2026-08-07/journal.md · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md · evidence audits/REPORT-DRILL-backup-truth-2026-08-21.md</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Walked end to end with no command line inside the machine (2026-08-07)<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#1b2740;color:#a78bfa;font-size:10px;white-space:nowrap">contested</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">CONTESTED-RESOLVED: not a contradiction. The walk proves the ROUTE needs no guest shell; the map's MISSING row is about a NON-OPERATOR doing it, which has still never happened. Two questions, one word 'customer'.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-201 · evidence tests/walk5-r201-2026-08-07/journal.md · capability-map A customer (not the operator) performs a restore via UI alone</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Putting restored files back where they belong is still manual<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Warning card. Confirmed 2026-08-09: the restore lands in a verification folder and says so.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-213</span></span></div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The tripwire that says someone is opening this customer's backups does fire<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">CONFIRMED tonight from the hub store: escrow_blob_served 2026-08-09 10:19:41Z = 12:19 CEST in the operator's mailbox. R-281's original claim of silence is WITHDRAWN.</span><span style="display:block;color:#4b5bLine truncated
+</div>
+<div style="font-size:15px;font-weight:600;margin:22px 0 9px">When things go wrong</div>
+<div style="color:#6b7a91;font-size:11.5px;margin-bottom:10px">19 situations, and what actually happens in each.</div>
+<div class="grid3">
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">A disk starts failing</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A disk starts failing — healthy path only; a genuinely failing disk has never been seen<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#1b2740;color:#7dd3fc;font-size:10px;white-space:nowrap">needs-hardware</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Only a failing disk on a running box could settle it.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Lemez-egészség felügyelet: per-disk SMART kártya · evidence audits/SPIKE-smart-coverage-2026-07-25.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The backup drive is unplugged</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The backup drive is unplugged<span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map An ABSENT backup-target drive raises its OWN alarm · evidence audits/R116-v0116-2026-07-30.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">A drive is filling up</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A drive is filling up<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: no walk document cited</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-167</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">An app crashes</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">An app crashes — the email leg has never been confirmed end to end<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Consistent with fault.operator-email: the digest is wired but its delivery is unobserved.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map App crashes → customer notified (one event per transition, …</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">Power cut mid-backup</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">Power cut mid-backup<span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">evidence audits/AUDIT-power-outage-recovery-2026-07-22.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The guest is destroyed</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The guest is destroyed<span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-201 · evidence audits/DRILL-r201-night-run-2026-08-04.md · evidence audits/DRILL-r201-night-run-2026-08-04.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The whole machine is wiped and reinstalled</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The whole machine is wiped and reinstalled — the data comes back<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">The 2026-08-09 rehearsal really did return 4/4 byte-identical, and that stands. What the next real reinstall showed (2026-08-21, demo-hp) is that the rebuild ORPHANS BOTH OFF-PREMISES TIERS at once, quietly: the restic target was lost and needed a self-heal plus a per-app re-enable before any copy resumed (R-193), and the PBS archives from before the reinstall cannot be opened by the rebuilt box at all, because it now presents a different key (R-366). The data came back in the rehearsal because the rehearsal restored it immediately; a machine left alone after a reinstall is not protected in the meantime and nothing says so.</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: a real reinstall on 2026-08-21 left both off-premises tiers broken - one silently for 12 days, the other unreadable - so 'the data comes back' holds only if someone restores it at once</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-193 · register R-366 · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md · evidence audits/REPORT-DRILL-backup-truth-2026-08-21.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The whole machine is wiped and reinstalled</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The whole machine is wiped and reinstalled — the journey needs a terminal twice<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">CONTESTED-RESOLVED against the map: the map's PROVEN-LIVE row is scoped to a controller-data-volume REBUILD (2026-08-04), not a whole-host reinstall. The map has no row for the host case, so there was no contradiction — only a gap.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-273 · register R-280 · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The machine is stolen, and someone opens the backups</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The machine is stolen, and someone opens the backups — the operator is told<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Confirmed 2026-08-09 from the store and the mailbox.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-281 · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The customer forgets their dashboard password</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The customer forgets their dashboard password<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Exercised 2026-08-09 via the reset code.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The customer loses their recovery code</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The customer loses their recovery code — by design, the data is unrecoverable<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">moved twice: 2026-08-09 walked -&gt; built, then 2026-08-10 back to walked</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">The recovery screen states it in Hungarian.</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: receipt found 2026-08-10, and then proven the hard way: the recovery screen states in Hungarian that nobody can replace a lost code, and on 2026-08-10 demo-felhom's pre-fix key was confirmed unrecoverable by construction (identity_blob NULL; the restic password lives only in that bundle). The by-design refusal is real.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Escrow ceremony: customer-facing wizard, one-shot R claim, … · register R-198 · evidence audits/REHEARSAL-byo-reinstall-2026-08-09.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The machine moves house / new network</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#34d399;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The machine moves house / new network<span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Box survives a site/network change (relocation, different s… · evidence audits/AUDIT-vacation-remote-ops-2026-07-20.md</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The internet goes down</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The internet goes down — built, never walked<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#1b2740;color:#7dd3fc;font-size:10px;white-space:nowrap">needs-hardware</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Needs a running box with WAN pulled.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map LAN access when internet is down (lan_resolver)</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The hub is down</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#60a5fa;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The hub is down<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#3a2a12;color:#fbbf24;font-size:10px;white-space:nowrap">changed 2026-08-09, was walked</span><span style="display:block;color:#9a7b3a;font-size:11px;margin-top:2px">why it moved: no walk document cited</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map Config/state change round-trips in seconds (hub↔box immediacy</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">We ship a broken release</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#64748b;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">We ship a broken release — the guard is missing<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Proven the hard way on 2026-08-09: a vouched agent version had no git tag and every install died at 5/8. Both guards still owed.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-273 · register R-287</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">A fresh install picks up an old image</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A fresh install picks up an old image<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Narrowed 2026-08-09: the resume path fetched the vouched golden; a fresh install still takes the newest LOCAL archive with no manifest comparison.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-274</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The off-site provider account is deleted</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The off-site provider account is deleted<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">The credential that holds the customer's documents can still delete.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-95</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">The machine is switched off for an afternoon</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#64748b;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">The machine is switched off for an afternoon — no notion of expected downtime<span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">Confirmed 2026-08-09: eight operator mails for deliberate, attended work.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">register R-285</span></span></div></div>
+<div style="background:#121b2c;border:1px solid #1f2c44;border-radius:6px;padding:14px 13px"><div style="font-size:14px;font-weight:500;padding-bottom:9px;margin-bottom:10px;border-bottom:1px solid #1f2c44">A customer restores their own data with no help</div><div style="display:flex;gap:8px;align-items:flex-start;margin-bottom:9px"><span style="width:8px;height:8px;border-radius:50%;background:#fbbf24;flex:0 0 8px;margin-top:5px"></span><span style="font-size:12px;line-height:1.45;color:#b8c4d6;text-wrap:pretty">A customer restores their own data with no help<span style="display:inline-block;margin-left:6px;padding:1px 5px;border-radius:3px;background:#1b2740;color:#a78bfa;font-size:10px;white-space:nowrap">contested</span><span style="display:block;color:#7c8aa3;font-size:11px;margin-top:3px">CONTESTED-RESOLVED: the map's MISSING is about a NON-OPERATOR performing it; the walks prove the route, not the person. Neither record was wrong. SINCE 2026-08-21 there is a second, harder blocker and it is not about the person at all: for the 40 of 53 apps that declare no data drive the off-site restore REFUSES before it starts, telling the customer a running app 'nincs telepítve' and to reinstall it to the same place — which those apps give them no way to choose (R-356). Those are exactly the apps whose whole dataset is a named volume. Until that is fixed, most customers cannot self-restore off-site even in principle.</span><span style="display:block;color:#4b5b76;font-size:10px;margin-top:3px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace">capability-map A customer (not the operator) performs a restore via UI alone · register R-201 · register R-356 · evidence audits/REPORT-DRILL-backup-truth-2026-08-21.md</span></span></div></div>
+</div>
+<div style="margin-top:26px;padding-top:12px;border-top:1px solid #1f2c44;color:#4b5b76;font-size:10.5px;line-height:1.6">Generated by <code>scripts/render_stands.py</code> from <code>where-felhom-stands.yaml</code>. Do not hand-edit this file — edit the data and regenerate. The 2026-08-09 React bundle is kept as <code>where-felhom-stands-2026-08-09-snapshot.html</code> and is not maintained.</div>
+</div></body></html>

documentation/architecture/where-felhom-stands.yaml

@@ -0,0 +1,767 @@
+# where-felhom-stands.yaml — the data behind documentation/architecture/where-felhom-stands.html
+#
+# THIS IS A VIEW, NEVER A SOURCE. Every entry cites the capability-map row, register row or
+# evidence document it derives from; an entry with no source is a defect, not a claim.
+# A status may not be RAISED here — if the evidence supports a stronger status than the
+# capability map records, the MAP changes first and this file follows it.
+# Regenerate the page after any status move:  python3 scripts/render_stands.py
+#
+# YAML rather than JSON, deliberately: statuses move one line at a time and a YAML diff shows
+# which claim moved. A JSON re-dump reflows and shows the whole file.
+#
+# verdict vocabulary: confirmed | downgraded | upgraded | contested | needs-hardware
+# depth: source-read (opened live source or evidence) | register+map (checked against the
+#        register and capability map only) | needs-hardware (cannot be settled off-box)
+verified_on: 2026-08-22
+verified_against:
+  felhom-agent: 40d857b527
+  felhom-controller: 2da259af38
+  hub: 877fcd2a38
+claims:
+  - id: install.iso-selfregister
+    band: journey
+    stage: 1
+    title: "A blank machine installs itself from our own boot image and registers itself as unclaimed — proven on two different boards"
+    status: walked
+    note: "Two boards: N100 2026-07-18, HP t740 2026-07-21."
+    sources:
+      - capability-map: "Bare-metal Felhom ISO (blank hardware → zero-touch auto-install → first-boot host-install)"
+      - evidence: "tests/VALIDATION-n100-rehearsal-2026-07-18.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: install.installer-by-tag
+    band: journey
+    stage: 1
+    title: "The installer is published rather than pushed: rolling it back is one act"
+    status: built
+    note: "Gate 6 of hostinstall_gates asserts the manifest names an installer-v tag; ran green tonight."
+    sources:
+      - capability-map: "The installer is PUBLISHED, not pushed"
+      - register: "R-110"
+    changed:
+      from: walked
+      reason: "gate 6 asserts the manifest names an installer tag, but no walk of a rollback is on file"
+    verified:
+      date: 2026-08-09
+      verdict: downgraded
+      depth: source-read
+  - id: install.byo
+    band: journey
+    stage: 1
+    title: "Installing onto hardware the customer already owns — the path exists, the first real one has not happened"
+    status: partial
+    note: "UPGRADED: a real --mode byo install completed on demo-hp 2026-08-09 (Day-0 provision SUCCESS, 3m49s). Still not a customer's own hardware, so not 'walked' — but 'has not happened' is now false."
+    sources:
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: upgraded
+      depth: source-read
+  - id: install.nic-selfheal
+    band: journey
+    stage: 1
+    title: "A machine that ends up on the wrong network port explains itself on screen and finds its way back — proven in a virtual drill, never on metal"
+    status: partial
+    note: "Map says the same: PROVEN-LIVE (nested drill — nested != metal)."
+    sources:
+      - capability-map: "Box survives a wrong-NIC install"
+      - evidence: "audits/SPIKE-firstboot-nic-sweep-2026-07-22.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: install.reinstall-refuses
+    band: journey
+    stage: 1
+    title: "Reinstalling a machine we previously installed refuses, because our own removal leaves a name service holding the port our own installer checks"
+    status: partial
+    note: "Warning card. Confirmed live 2026-08-09; dnsmasq restarted by --uninstall seizes :53."
+    sources:
+      - register: "R-272"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: claim.one-time-code
+    band: journey
+    stage: 2
+    title: "An emailed one-time code; the customer sets their own password and the operator never sees it"
+    status: walked
+    note: "Exercised live 2026-08-09: reset code accepted at /claim, 302 + session."
+    sources:
+      - capability-map: "Customer claim: one-time emailed code → customer sets own password"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: claim.selfbind
+    band: journey
+    stage: 2
+    title: "The customer can bind their own machine from a link, with no operator present — done once, for real"
+    status: walked
+    note: "attempts=0, locked=0, source customer_selfbind, 2026-07-18."
+    sources:
+      - capability-map: "Customer binds their own appliance (self-service)"
+      - evidence: "tests/VALIDATION-n100-rehearsal-2026-07-18.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: claim.never-by-non-operator
+    band: journey
+    stage: 2
+    title: "It has never been done by a person who is not the operator"
+    status: partial
+    note: "Map records MISSING (as evidence). Still true after 2026-08-09."
+    sources:
+      - capability-map: "A customer (not the operator) performs a restore via UI alone"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: claim.code-naming
+    band: journey
+    stage: 2
+    title: "The same word is used for two different secrets across three surfaces; the email points at a page a rebuilt machine does not show"
+    status: partial
+    note: "Warning card. Cost a real code on 2026-08-09."
+    sources:
+      - register: "R-282"
+      - register: "R-283"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: use.catalog
+    band: journey
+    stage: 3
+    title: "Apps installed from a catalog of about 52, with a memory guard and health-aware progress"
+    status: walked
+    note: "53 templates listed on the rebuilt box 2026-08-09; deploy driven live."
+    sources:
+      - capability-map: "Deploy an app from the catalog (env config, memory guard, health-aware progress)"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: use.lifecycle
+    band: journey
+    stage: 3
+    title: "Start, stop, restart, update, logs, remove — and the parts that must not be stopped cannot be"
+    status: built
+    sources:
+      - capability-map: "App lifecycle: start/stop/restart/update/logs/remove/redeploy"
+      - register: "R-108"
+    changed:
+      from: walked
+      reason: "no walk document cited by the map row or anywhere else"
+    verified:
+      date: 2026-08-09
+      verdict: downgraded
+      depth: register+map
+  - id: use.tunnel
+    band: journey
+    stage: 3
+    title: "Reachable from anywhere through a tunnel, per-app addresses"
+    status: walked
+    note: "Verified tonight: the rebuilt box answered on its public URL from outside."
+    sources:
+      - capability-map: "Remote access via Cloudflare Tunnel + Traefik (per-app subdomains)"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: use.lan-fallback
+    band: journey
+    stage: 3
+    title: "Reachable on the home network when the internet is down"
+    status: built
+    note: "Only an observation on a running box with WAN pulled could settle it. Boxes are off."
+    sources:
+      - capability-map: "LAN access when internet is down (lan_resolver)"
+    verified:
+      date: 2026-08-09
+      verdict: needs-hardware
+      depth: needs-hardware
+  - id: use.files
+    band: journey
+    stage: 3
+    title: "Phone photos, documents with text recognition, files from Windows Explorer or a Mac"
+    status: walked
+    sources:
+      - capability-map: "Files from Windows Explorer / Mac Finder (SMB server)"
+      - evidence: "audits/SPIKE-lan-discovery-2026-07-18.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: use.launcher
+    band: journey
+    stage: 3
+    title: "A one-tap launcher, and a read-only guest link for visitors"
+    status: built
+    sources:
+      - capability-map: "Indítópult (app launcher) — one-tap grid of the household's openable apps"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: use.dlna
+    band: journey
+    stage: 3
+    title: "Media to a TV"
+    status: missing
+    note: "Map: MISSING."
+    sources:
+      - capability-map: "Media to TV via DLNA"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: use.multiuser
+    band: journey
+    stage: 3
+    title: "Separate accounts per household member"
+    status: missing
+    note: "Map: MISSING."
+    sources:
+      - capability-map: "Multiple household users / per-person accounts"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: drives.enrol
+    band: journey
+    stage: 4
+    title: "A new drive is found, offered, formatted, mounted and enrolled — including on awkward older boot layouts"
+    status: walked
+    note: "Applies to a NEW drive. Re-attaching an existing one after a reinstall is R-280 and fails."
+    sources:
+      - capability-map: "Drive wizard: scan/format/mount/enroll, incl. legacy-boot LVM-root hosts"
+      - register: "R-220"
+      - evidence: "audits/SPIKE-raw-drive-enroll-2026-06-15.md"
+    changed:
+      from: built
+      also_moved: 2026-08-09 walked -> built
+      reason_superseded: "the 2026-08-09 walk exercised RE-attach (which failed, R-280); first-enrolment of a NEW drive has no walk on file"
+      reason: "receipt found 2026-08-10: a live throwaway drive on felhom-pve walked scan -> format -> mount -> PVE dir storage -> one-click Regisztralas, with the resulting storage.cfg entry and systemd mount unit recorded. The map already read PROVEN-LIVE; the dataset was behind it. Scope unchanged: this is a NEW drive. Re-attaching an existing one after a reinstall is R-280 and still fails."
+    verified:
+      date: 2026-08-09
+      verdict: upgraded
+      depth: source-read
+  - id: drives.migrate
+    band: journey
+    stage: 4
+    title: "Moving data between drives, crash-safe; removing a drive safely; unplug detected"
+    status: built
+    sources:
+      - capability-map: "Data migration between drives (all / per-app), crash-safe"
+    changed:
+      from: walked
+      reason: "no walk document cited"
+    verified:
+      date: 2026-08-09
+      verdict: downgraded
+      depth: register+map
+  - id: drives.nas
+    band: journey
+    stage: 4
+    title: "A network drive can be browsed and hold bulk media, but may not hold an app's data — enforced"
+    status: walked
+    note: "RefuseAsAppNamespace is the fail-closed predicate."
+    sources:
+      - capability-map: "Network storage (NAS) is browse + bulk-media only"
+      - register: "R-108"
+      - evidence: "audits/R108-network-app-namespace-2026-07-30.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: drives.reattach-wall
+    band: journey
+    stage: 4
+    title: "After a reinstall the data drive cannot be re-attached through any dashboard route"
+    status: partial
+    note: "Warning card. /api/disks/candidates returns empty; the restore page promises two clicks."
+    sources:
+      - register: "R-280"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: backup.tier1
+    band: journey
+    stage: 5
+    title: "App data on the machine, nightly database dumps, a copy on a second drive"
+    status: walked
+    note: "True for every app but one, and that one was found on 2026-08-21: paperless-ngx's 72-table PostgreSQL was dumped nightly and written into a folder named after an app that does not exist, so it never entered the recovery unit, the second-drive copy or the off-site copy. Fixed and proven live 2026-08-22 (R-355) — the dump is now in the app's own unit and in the off-site snapshot for the first time. A catalogue-wide sweep, itself proven able to convict a planted case, says 1 of 53 was affected."
+    sources:
+      - capability-map: "Tier-2 secondary-drive copy: class-driven legs"
+      - register: "R-355"
+      - evidence: "audits/CAMPAIGN-8-backup-restore-2026-07-27.md"
+      - evidence: "audits/DRILL-backup-truth-2026-08-21/evidence/phase4-paperless/FINDING.txt"
+    changed:
+      from: built
+      also_moved: 2026-08-09 walked -> built
+      reason_superseded: "no walk document cited"
+      reason: "receipt found 2026-08-10: an adversarial, destructive, unattended overnight campaign across both boxes and ep0, with A2 (one quiesce, two tiers) proven end to end. Map already read PROVEN-LIVE."
+    verified:
+      date: 2026-08-22
+      verdict: confirmed
+      depth: source-read
+  - id: backup.whole-machine
+    band: journey
+    stage: 5
+    title: "A whole-machine archive that lands off the guest's own disk — a single-drive machine is recorded as degraded rather than pretending"
+    status: built
+    sources:
+      - capability-map: "Whole-guest backup lands OFF the guest's own physical device"
+      - register: "R-165"
+    changed:
+      from: walked
+      reason: "no walk document cited"
+    verified:
+      date: 2026-08-09
+      verdict: downgraded
+      depth: register+map
+  - id: backup.offsite
+    band: journey
+    stage: 5
+    title: "An encrypted off-site copy, sealed with a key the operator cannot read"
+    status: partial
+    note: "The COPY is real and the key is still unreadable to us — what failed is DAILY and UNBROKEN. The 2026-08-09 note said '18 snapshots, daily, unbroken'; the next snapshot after 2026-08-09 08:30 was 2026-08-21 22:17, put there by hand during the drill. Twelve days, no alarm. Two causes in series: the 2026-08-21 rebuild lost the off-box target (R-193's shape), and after the self-heal restored it EVERY per-app switch was still off, so the first run logged 'backup OK: 0 app(s) backed up, 14s'."
+    sources:
+      - capability-map: "Offsite (restic → Hetzner Storage Box)"
+      - register: "R-199"
+      - register: "R-193"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+      - evidence: "audits/REPORT-DRILL-backup-truth-2026-08-21.md"
+    changed:
+      from: walked
+      reason: "the claim is about a CONTINUING daily copy; a 12-day silent gap was found on 2026-08-21 and nothing reported it"
+    verified:
+      date: 2026-08-22
+      verdict: downgraded
+      depth: source-read
+  - id: backup.restore-proof
+    band: journey
+    stage: 5
+    title: "The backups prove themselves: a restore is actually performed, unattended, on every tier, on both machines"
+    status: built
+    note: "STILL GREY, and for a sharper reason than in August. The scheduler runs and the check works — it failed again on 2026-08-21, unprompted, and named the cause exactly: after the reinstall the box presents a different PBS key than its own older archives were sealed with, so those archives cannot be opened at all (R-366). A tier whose archives are orphaned is a different alarm from a tier whose test failed, and only the second is being said."
+    sources:
+      - capability-map: "Restore-proof is UNATTENDED — the scheduler covers EVERY tier"
+      - register: "R-86"
+      - register: "R-366"
+      - evidence: "audits/REPORT-DRILL-backup-truth-2026-08-21.md"
+    changed:
+      from: walked
+      reason: "no walk document cited, and the last recorded restore-test on demo-hp FAILED (2026-08-05)"
+      decay: "PROOF-DECAY RULE FIRED (first time it has). A receipt EXISTS - architecture/_recovery-inventory-2026-07-28.md carries live journal lines for scheduled restore-tests on both boxes and both tiers - but it is superseded by later observation: demo-hp logged restore_test_failed on 2026-08-05, and the box has since been wiped and reinstalled (2026-08-09). The claim is about a CONTINUING scheduled behaviour, so a 2026-07-28 observation cannot carry it. Stays grey until a scheduled restore-test is seen passing on the rebuilt box. THE CAPABILITY MAP STILL READS PROVEN-LIVE (2026-08-03) AND IS NOW THE THING OUT OF STEP."
+      worse_2026_08_22: "It failed AGAIN, unprompted, on 2026-08-21 21:59 - and the cause is worse than 'untested'. Hub event 3016: the PBS archive of 2026-08-18 could not be restored because the manifest's key does not match the key the rebuilt box now presents. The archives that predate the 2026-08-21 reinstall are UNREADABLE to the machine that made them (R-366). Credit where due: the mechanism caught it and named the key mismatch precisely. The gap is that it is reported as 'a restore test failed' rather than 'your older whole-machine backups cannot be opened on this box'."
+    verified:
+      date: 2026-08-22
+      verdict: downgraded
+      depth: needs-hardware
+  - id: backup.fill-warning
+    band: journey
+    stage: 5
+    title: "The customer is warned before a drive fills, per drive, in their own language"
+    status: partial
+    note: "The warning is real and was SEEN firing on 2026-08-21 with the right Hungarian copy, naming the drive and the free space. What 'BEFORE' cannot survive is the cadence: the watcher runs once a day at 03:30 plus once at startup (R-363), so a filesystem that fills at 03:31 goes unannounced for ~24 h. Watched live: the 69 GB volume carrying all 40-class app data was filled to 99% and the watcher said nothing, while the backup reserve was already refusing an app per run and telling the hub about it."
+    sources:
+      - capability-map: "The customer is warned BEFORE a filesystem fills"
+      - register: "R-167"
+      - register: "R-363"
+      - evidence: "audits/SPIKE-r165-mp1-merge-2026-08-02.md"
+      - evidence: "audits/REPORT-DRILL-backup-truth-2026-08-21.md"
+    changed:
+      from: walked
+      reason: "a daily check cannot carry the word BEFORE; observed silent for the whole window a filesystem sat at 99%"
+    verified:
+      date: 2026-08-22
+      verdict: downgraded
+      depth: source-read
+  - id: backup.sikeres
+    band: journey
+    stage: 5
+    title: "A backup that covered nothing still calls itself successful"
+    status: partial
+    note: "Warning card — and the drill found two more of it, both live. (1) An off-site run with no app selected logs 'backup OK: 0 app(s) backed up'; the card does say 'nincs kijelölt alkalmazás' beside the green tick, so this one is honest if you read past the tick. (2) A restore that placed nothing reported success: '0 fájl visszaállítva', ok=true. The second is the one that matters and it is R-353, still open. The volume half of it is fixed (R-354): the message now names what came back."
+    sources:
+      - register: "R-240"
+      - register: "R-353"
+      - register: "R-354"
+      - evidence: "audits/DRILL-backup-truth-2026-08-21/evidence/phase3-experiment/messages-verbatim.txt"
+    verified:
+      date: 2026-08-22
+      verdict: confirmed
+      depth: source-read
+  - id: fault.selfheal
+    band: journey
+    stage: 6
+    title: "The machine watches itself and repairs some faults without telling anyone it had to"
+    status: built
+    note: "R-264 records that the self-heal counters reach the hub and are decoded nowhere."
+    sources:
+      - capability-map: "Box survives an unattended app or guest-network failure"
+      - register: "R-264"
+    changed:
+      from: walked
+      reason: "no walk document cited"
+    verified:
+      date: 2026-08-09
+      verdict: downgraded
+      depth: source-read
+  - id: fault.operator-email
+    band: journey
+    stage: 6
+    title: "Failures reach the operator by email, one mail per run, every failing app named"
+    status: built
+    note: "CONFIRMED against source: backup_run_failures digest is allowlisted (api/handler.go:1837), operator-only (dispatcher.go:423), templated (templates.go:48); recovery_unit_capture_failed is record-only (dispatcher.go:376). NOTE: R-182's register row still describes the PRE-FIX behaviour — see R-289."
+    sources:
+      - capability-map: "A failed per-app Tier-1 backup reaches the OPERATOR — EVERY failing app, in ONE mail per run"
+      - register: "R-182"
+    changed:
+      from: walked
+      reason: "the digest is wired and source-verified, but no run of it has been observed delivering"
+    verified:
+      date: 2026-08-09
+      verdict: downgraded
+      depth: source-read
+  - id: fault.customer-email
+    band: journey
+    stage: 6
+    title: "Failures reach the customer"
+    status: built
+    note: "The customer leg is built; today's log shows customer-channel rows skipped as operator_only."
+    sources:
+      - capability-map: "App crashes → customer notified (one event per transition, no flapping spam)"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: fault.already-paired
+    band: journey
+    stage: 6
+    title: "An already-paired box is still told to pair itself"
+    status: partial
+    note: "Warning card."
+    sources:
+      - register: "R-214"
+      - register: "R-235"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: recover.screen
+    band: journey
+    stage: 7
+    title: "A rebuilt machine shows a full-page recovery screen without anyone looking for it, and says plainly that nobody can replace a lost recovery code"
+    status: walked
+    note: "Seen unsought on the rebuilt demo-hp 2026-08-09, seal date matching host_escrow.created_at."
+    sources:
+      - register: "R-193"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: recover.byte-identical
+    band: journey
+    stage: 7
+    title: "The customer's code opens the sealed package and the data returns byte for byte — including accented Hungarian filenames, verified as raw bytes"
+    status: walked
+    note: "Still true, and re-proven 2026-08-22 (5/5 byte-identical, both accented names as raw bytes) — but the SCOPE is narrower than the sentence sounds and was silently narrower still until v0.218.0. The drill found the off-site restore had NO named-volume leg at all: the archive sat in the unit, the snapshot and the checking folder and was never replayed, under a success message (R-354, fixed and proven 2026-08-22). AND 40 of the 53 catalogue apps STILL cannot run this route at all — it refuses first, saying a running app is not installed (R-356, open). So: proven for an app that declares a data drive; unproven and currently unreachable for the class whose entire dataset is a named volume."
+    sources:
+      - register: "R-201"
+      - register: "R-354"
+      - register: "R-356"
+      - evidence: "tests/walk5-r201-2026-08-07/journal.md"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+      - evidence: "audits/REPORT-DRILL-backup-truth-2026-08-21.md"
+    verified:
+      date: 2026-08-22
+      verdict: confirmed
+      depth: source-read
+  - id: recover.no-shell
+    band: journey
+    stage: 7
+    title: "Walked end to end with no command line inside the machine (2026-08-07)"
+    status: walked
+    note: "CONTESTED-RESOLVED: not a contradiction. The walk proves the ROUTE needs no guest shell; the map's MISSING row is about a NON-OPERATOR doing it, which has still never happened. Two questions, one word 'customer'."
+    sources:
+      - register: "R-201"
+      - evidence: "tests/walk5-r201-2026-08-07/journal.md"
+      - capability-map: "A customer (not the operator) performs a restore via UI alone"
+    verified:
+      date: 2026-08-09
+      verdict: contested
+      depth: source-read
+  - id: recover.putback
+    band: journey
+    stage: 7
+    title: "Putting restored files back where they belong is still manual"
+    status: partial
+    note: "Warning card. Confirmed 2026-08-09: the restore lands in a verification folder and says so."
+    sources:
+      - register: "R-213"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: recover.tripwire
+    band: journey
+    stage: 7
+    title: "The tripwire that says someone is opening this customer's backups does fire"
+    status: walked
+    note: "CONFIRMED tonight from the hub store: escrow_blob_served 2026-08-09 10:19:41Z = 12:19 CEST in the operator's mailbox. R-281's original claim of silence is WITHDRAWN."
+    sources:
+      - register: "R-281"
+      - register: "R-285"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: fail.disk-failing
+    band: failures
+    title: "A disk starts failing — healthy path only; a genuinely failing disk has never been seen"
+    status: partial
+    note: "Only a failing disk on a running box could settle it."
+    sources:
+      - capability-map: "Lemez-egészség felügyelet: per-disk SMART kártya"
+      - evidence: "audits/SPIKE-smart-coverage-2026-07-25.md"
+    verified:
+      date: 2026-08-09
+      verdict: needs-hardware
+      depth: needs-hardware
+  - id: fail.backup-drive-unplugged
+    band: failures
+    title: "The backup drive is unplugged"
+    status: walked
+    sources:
+      - capability-map: "An ABSENT backup-target drive raises its OWN alarm"
+      - evidence: "audits/R116-v0116-2026-07-30.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: fail.drive-filling
+    band: failures
+    title: "A drive is filling up"
+    status: built
+    sources:
+      - register: "R-167"
+    changed:
+      from: walked
+      reason: "no walk document cited"
+    verified:
+      date: 2026-08-09
+      verdict: downgraded
+      depth: register+map
+  - id: fail.app-crash
+    band: failures
+    title: "An app crashes — the email leg has never been confirmed end to end"
+    status: built
+    note: "Consistent with fault.operator-email: the digest is wired but its delivery is unobserved."
+    sources:
+      - capability-map: "App crashes → customer notified (one event per transition, no flapping spam)"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: fail.power-cut
+    band: failures
+    title: "Power cut mid-backup"
+    status: walked
+    sources:
+      - evidence: "audits/AUDIT-power-outage-recovery-2026-07-22.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: fail.guest-destroyed
+    band: failures
+    title: "The guest is destroyed"
+    status: walked
+    sources:
+      - register: "R-201"
+      - evidence: "audits/DRILL-r201-night-run-2026-08-04.md"
+      - evidence: "audits/DRILL-r201-night-run-2026-08-04.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: fail.wiped-reinstalled.data
+    band: failures
+    title: "The whole machine is wiped and reinstalled — the data comes back"
+    status: partial
+    note: "The 2026-08-09 rehearsal really did return 4/4 byte-identical, and that stands. What the next real reinstall showed (2026-08-21, demo-hp) is that the rebuild ORPHANS BOTH OFF-PREMISES TIERS at once, quietly: the restic target was lost and needed a self-heal plus a per-app re-enable before any copy resumed (R-193), and the PBS archives from before the reinstall cannot be opened by the rebuilt box at all, because it now presents a different key (R-366). The data came back in the rehearsal because the rehearsal restored it immediately; a machine left alone after a reinstall is not protected in the meantime and nothing says so."
+    sources:
+      - register: "R-193"
+      - register: "R-366"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+      - evidence: "audits/REPORT-DRILL-backup-truth-2026-08-21.md"
+    changed:
+      from: walked
+      reason: "a real reinstall on 2026-08-21 left both off-premises tiers broken - one silently for 12 days, the other unreadable - so 'the data comes back' holds only if someone restores it at once"
+    verified:
+      date: 2026-08-22
+      verdict: downgraded
+      depth: source-read
+  - id: fail.wiped-reinstalled.journey
+    band: failures
+    title: "The whole machine is wiped and reinstalled — the journey needs a terminal twice"
+    status: partial
+    note: "CONTESTED-RESOLVED against the map: the map's PROVEN-LIVE row is scoped to a controller-data-volume REBUILD (2026-08-04), not a whole-host reinstall. The map has no row for the host case, so there was no contradiction — only a gap."
+    sources:
+      - register: "R-273"
+      - register: "R-280"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: fail.stolen-machine
+    band: failures
+    title: "The machine is stolen, and someone opens the backups — the operator is told"
+    status: walked
+    note: "Confirmed 2026-08-09 from the store and the mailbox."
+    sources:
+      - register: "R-281"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: fail.forgot-password
+    band: failures
+    title: "The customer forgets their dashboard password"
+    status: walked
+    note: "Exercised 2026-08-09 via the reset code."
+    sources:
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: fail.lost-recovery-code
+    band: failures
+    title: "The customer loses their recovery code — by design, the data is unrecoverable"
+    status: walked
+    note: "The recovery screen states it in Hungarian."
+    sources:
+      - capability-map: "Escrow ceremony: customer-facing wizard, one-shot R claim, operator zero-knowledge"
+      - register: "R-198"
+      - evidence: "audits/REHEARSAL-byo-reinstall-2026-08-09.md"
+    changed:
+      from: built
+      also_moved: 2026-08-09 walked -> built
+      reason_superseded: "a by-design refusal; no walk document cited"
+      reason: "receipt found 2026-08-10, and then proven the hard way: the recovery screen states in Hungarian that nobody can replace a lost code, and on 2026-08-10 demo-felhom's pre-fix key was confirmed unrecoverable by construction (identity_blob NULL; the restic password lives only in that bundle). The by-design refusal is real."
+    verified:
+      date: 2026-08-09
+      verdict: upgraded
+      depth: source-read
+  - id: fail.moves-house
+    band: failures
+    title: "The machine moves house / new network"
+    status: walked
+    sources:
+      - capability-map: "Box survives a site/network change (relocation, different subnet, DHCP re-lease)"
+      - evidence: "audits/AUDIT-vacation-remote-ops-2026-07-20.md"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: fail.internet-down
+    band: failures
+    title: "The internet goes down — built, never walked"
+    status: built
+    note: "Needs a running box with WAN pulled."
+    sources:
+      - capability-map: "LAN access when internet is down (lan_resolver)"
+    verified:
+      date: 2026-08-09
+      verdict: needs-hardware
+      depth: needs-hardware
+  - id: fail.hub-down
+    band: failures
+    title: "The hub is down"
+    status: built
+    sources:
+      - capability-map: "Config/state change round-trips in seconds (hub↔box immediacy"
+    changed:
+      from: walked
+      reason: "no walk document cited"
+    verified:
+      date: 2026-08-09
+      verdict: downgraded
+      depth: register+map
+  - id: fail.broken-release
+    band: failures
+    title: "We ship a broken release — the guard is missing"
+    status: missing
+    note: "Proven the hard way on 2026-08-09: a vouched agent version had no git tag and every install died at 5/8. Both guards still owed."
+    sources:
+      - register: "R-273"
+      - register: "R-287"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: fail.stale-image
+    band: failures
+    title: "A fresh install picks up an old image"
+    status: partial
+    note: "Narrowed 2026-08-09: the resume path fetched the vouched golden; a fresh install still takes the newest LOCAL archive with no manifest comparison."
+    sources:
+      - register: "R-274"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: fail.offsite-account-deleted
+    band: failures
+    title: "The off-site provider account is deleted"
+    status: partial
+    note: "The credential that holds the customer's documents can still delete."
+    sources:
+      - register: "R-95"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: register+map
+  - id: fail.expected-downtime
+    band: failures
+    title: "The machine is switched off for an afternoon — no notion of expected downtime"
+    status: missing
+    note: "Confirmed 2026-08-09: eight operator mails for deliberate, attended work."
+    sources:
+      - register: "R-285"
+    verified:
+      date: 2026-08-09
+      verdict: confirmed
+      depth: source-read
+  - id: fail.customer-self-restore
+    band: failures
+    title: "A customer restores their own data with no help"
+    status: partial
+    note: "CONTESTED-RESOLVED: the map's MISSING is about a NON-OPERATOR performing it; the walks prove the route, not the person. Neither record was wrong. SINCE 2026-08-21 there is a second, harder blocker and it is not about the person at all: for the 40 of 53 apps that declare no data drive the off-site restore REFUSES before it starts, telling the customer a running app 'nincs telepítve' and to reinstall it to the same place — which those apps give them no way to choose (R-356). Those are exactly the apps whose whole dataset is a named volume. Until that is fixed, most customers cannot self-restore off-site even in principle."
+    sources:
+      - capability-map: "A customer (not the operator) performs a restore via UI alone"
+      - register: "R-201"
+      - register: "R-356"
+      - evidence: "audits/REPORT-DRILL-backup-truth-2026-08-21.md"
+    verified:
+      date: 2026-08-22
+      verdict: contested
+      depth: source-read

documentation/audits/CAMPAIGN-11-recovery-journey-2026-08-05.md

@@ -0,0 +1,640 @@
+# CAMPAIGN 11 — the recovery journey (2026-08-05 → 08-06)
+
+**Four phases. Phase 1 (the clean journey) FAILED on the journey and PASSED on the data. Phase 3 (key
+supersession) PASSED on its central question. Phase 2 (eleven injected faults) and Phase 4 (an
+unattended soak) ran overnight on 2026-08-05/06 and are reported here for the first time.**
+
+**Findings: R-214 … R-223 from Phases 1 and 3** (seven since fixed and shipped), **plus R-224 … R-228
+from Phase 2.** **Three suspicions investigated — two confirmed, one DISPROVED.** **Five harness
+faults, separated from the product's.**
+
+Evidence: `../tests/campaign11-evidence-2026-08-05/` — `journal.md` (Phases 0, 1, 3) and
+`journal-phase24.md` (Phases 2 and 4, every observable in the order taken).
+
+> **The one-line answer to the question this campaign was built to ask.** A Hungarian household whose
+> machine is rebuilt **gets their data back only if an operator is standing next to them.** The
+> cryptography, the retention and the transport all work and are now proven live. **What fails is
+> being told the truth**: on this box, four different situations — a mistyped code, a hub outage, a
+> stopped agent, and a correct code for a retained earlier package — produce **one** message, and
+> three of the four are wrong.
+
+---
+
+> **ANNOTATION 2026-08-06 — what has since been fixed. The body below is NOT rewritten.** This
+> document records what was true when the campaign ran, and that is its value; the fixes are recorded
+> here and in `felhom-controller/REPORT.md`.
+>
+> **R-224, R-226, R-225, R-227, R-228 are CLOSED** in controller **v0.202.0** + agent **v0.126.0**.
+> The unlock path now classifies why it failed — from the value, never the text — and the message
+> that mentions typing is reachable only after a real refusal; anything unclassifiable renders a
+> neutral message rather than an accusation. Proven live on this venue: same wrong code, hub up →
+> `400`, hub REJECTed → `502` naming the connection and stating the code was **not used**, hub
+> restored → `400`.
+>
+> **Unchanged by that work:** the campaign's verdict, the RTO, and the capability map's recovery row,
+> which stays **FAIL** until a re-walk passes. **R-214, R-220, R-221 remain open**, and R-220 is still
+> worked around by hand on this venue.
+
+> **ADDENDUM 2026-08-06 — THE RE-WALK (R-201). The body below is NOT rewritten.**
+>
+> Phase 1's question was asked again on the fixed build, on a **new** appliance (VM 322, customer
+> `rewalk`) — this campaign's venue was left untouched. **The data half PASSED again**: all three
+> sentinels byte-identical, including an accented Hungarian filename whose **name bytes** are also
+> identical, restored in **23 s**. **The journey half still FAILS, with TWO dead ends instead of
+> four**: R-218's *consume* half (the hub re-stages, the box never collects — only a guest command
+> line moves it) and R-220 (drives unenrollable after a rebuild). **The unaided RTO remains
+> undefined.**
+>
+> Two of this campaign's findings were reproduced live: **R-216 part 4** (the reinstall downgraded the
+> hand-installed agent back to the vouched version) and **R-220**. One of last night's fixes was seen
+> working in the wild: **R-225** (an unread store said "unknown", not a false zero).
+>
+> Evidence: `../tests/rewalk-r201-2026-08-06/journal.md`.
+
+## 1. Venue and baselines
+
+| | |
+|---|---|
+| Host | `demo-hp` (HP t740), **Tier 0**, the designated drill host. Reached **by SSH key, first try** — R-129 stands |
+| VM | **321 `c11-appliance`** — q35/OVMF, 4 cores, 8 GB, `cpu=host` |
+| Disks | `scsi0` 200 G system · `scsi1` 50 G · `scsi2` 50 G, qcow2 on `c11-scratch` |
+| Storage | **`c11-scratch`**, `dir` at **`/mnt/nvme-1tb` — the mount ROOT** (a subdirectory fails the agent's `exactMount` check; Campaign 10 §1) |
+| Appliance | `192.168.0.105`, hostname `c11`, `felhom-agent 0.125.0` |
+| Guest | LXC **9201**, **`192.168.0.106`** — DHCP, and it MOVED between phases (`.207` → `.227` → `.106`) |
+| Hub customer | **`c11`** "Campaign 11", domain `c11.felhom.eu`, DR tier ON, off-site ON |
+| Host id | **`c11-36d660`** |
+| Untouched | `drill-r50` (VM 300, stopped), guest 9201 on both demo boxes, `local-lvm`, `felhom-backup`, every other hub customer |
+
+### Baselines — every value re-read fresh at the start of Phase 2
+
+| What | Value | How |
+|---|---|---|
+| `felhom-controller` `main` | **v0.201.0** @ `05cf352a2f17` | `HEAD` == `origin/main`, tree clean |
+| `felhom-agent` `main` | **v0.125.0** @ `0404f60e6a7b` | same |
+| `felhom.eu` `main` | @ `3a539ea5306a` | same |
+| hub, LIVE | **`felhom-hub:0.97.1`** | `kubectl … get deploy hub -o jsonpath` |
+| Day-0 manifest | agent **0.125.0** · golden **0.201.0** · `min_agent` **0.125.0** | hub `/configuration`, `selected` options |
+| c11 floor | **`v0.200.0 (override)`**; every other customer `v0.156.0` | hub `/configs` |
+| Highest register ID | **R-223** | fresh `grep -rhoE 'R-[0-9]{1,3}'` over all four repos |
+
+**All four cited commits match the brief exactly**, and the manifest matches the golden rebake the
+Phase-1/3 journal records. **Blast radius of the per-customer floor is still zero, measured** — the
+other five customers all read `v0.156.0`.
+
+### The hub CHANGELOG/deployed mismatch — diagnosed more precisely than filed
+
+The brief records *"`0.97.1` shipped without an entry"*. **The content was not missing; its heading
+was.** Commit `a7f1d27` wrote the change into the **v0.97.0** entry and `79e31ac` bumped the manifest
+to `0.97.1`, so a reader matching the running tag against `hub/CHANGELOG.md` found no `v0.97.1`
+heading at all. **Fixed in this session** — the paragraph now has its own entry, marked as added
+retroactively. Second occurrence of the class (the first was agent `0.90.1`).
+
+---
+
+## 2. Scope, and what was deliberately not isolated
+
+Campaign 10 could run with Tier 3 OFF; **a campaign about off-site recovery cannot.** Off-site
+hard-requires the DR tier, which provisions on **ep0** (Tier 2). The Phase-0 operator ruling stands
+and is restated here rather than quietly inherited: **ep0 and the Hetzner Storage Box are written to,
+additively** — a PBS namespace and token, a WireGuard peer, and a Storage Box sub-account, all created
+on the ordinary customer path. **Nothing existing is modified or deleted.** The brief's I7 wording
+("ep0 read-only") was relaxed by that ruling, not widened by this session.
+
+**Phase 2 added no new external writes.** Its faults are network blocks, a service stop, a container
+restart and a VM shutdown — all on the campaign's own appliance, all reverted, each with a positive
+control proving the fault was real.
+
+---
+
+## 3. The two positives that were owed (brief §4)
+
+### §4.1 — is the floor actually SERVED? **MEASURED. YES. Twice, independently.**
+
+The previous session recorded *"no HELD line and no held reason"* — **two absences** — and correctly
+refused to call that a measurement. Both positives were taken here.
+
+**(a) The box's own rendered state.** `/settings` → „Automatikus frissítés – **Minimális verzió
+(üzemeltető) `0.200.0`**". That value is `s.updater.GetFloor()`, and `u.floor` has exactly one writer
+— `SetFloor`, whose only non-test caller is the report-ACK handler. **Both hold branches of
+`ResolveManagedFloor` set `Floor = ""`** (`store.go:2086`, `:2095`), pinned by
+`managed_floor_test.go:94`. A non-empty floor on the box therefore proves an ACK carried one.
+
+**(b) A cold-started process saying it out loud.** F8's restart produced the decisive A/B — the same
+log line, same box, same code, before and after the golden rebake:
+
+```
+15:58:35  settle-gate: GO — floor still unknown after 1m30s               ← hold IN FORCE
+21:06:16  settle-gate: GO — at/above floor 0.200.0 (we are 0.201.0)       ← hold RELEASED
+```
+
+**The hub half, as a positive rather than an absence:** `managed floor HELD for c11 …` fired every
+15 minutes from 17:57:11 to **22:12:06** and then stopped — and the silence is backed by a liveness
+control (the hub logged `host-report from demo-hp-bb76ea` at 22:44:41 and `wgsync: pushed 5 peers` at
+22:44:57, so it was demonstrably still logging).
+
+> **A correction to the brief's own plan.** It says to take this at DEBUG during F8's restart.
+> **A restart alone would not have produced it**: `SetFloor`'s line is `u.dbg(...)`, gated on a private
+> flag set from `cfg.Logging.Level == "debug"`, and it writes to the logger — **never to the logx debug
+> ring**, so it cannot appear in `/api/debug/logs` at any level. Confirmed live: 4 000 ring entries
+> spanning the release window contain no `SetFloor` line, **with a level census run first** (1196
+> DEBUG / 2802 INFO / 2 WARN) so the absence was known to be structural rather than evidential.
+
+### §4.2 — R-218's live half: **still NOT measured, deliberately, with the reason**
+
+The fix is present and readable — `needsOffsiteCredential` now retires the declaration on the
+**target**, not on the key:
+
+```go
+if t != nil { return false }   // a TARGET exists — not a rebuild
+```
+
+**The venue cannot exercise it.** c11 has a target (`applied_marker` present since 14:57), so
+`t != nil` and the box correctly does **not** declare; declaring here would be the bug. The state that
+exercises the fix — hub identity blob present, key placed, **no target** — is shape (a), which the
+venue held during Phase 1 and does not hold now. F7's set-aside was examined as a route to it and
+**does not produce it either** (§5, F7).
+
+**Recorded as still not measured rather than inferred from the unit test.** It needs one rebuild,
+which the brief forbids before Phase 4.
+
+---
+
+## 4. Phase 2 — the eleven faults
+
+**Judged on the message, not the outcome.** Every fault carries a positive control proving the fault
+was real; **every control that failed is reported as a failed control, not as a result.**
+
+### The four messages (`internal/web/recovery_handlers.go`, v0.201.0)
+
+| | fires when | first words |
+|---|---|---|
+| **M1** | unseal failed **and** no superseded package | „A megadott helyreállítási kódot **nem fogadtuk el**. Ellenőrizd, hogy mind a tíz szót…" |
+| **M2** | the capability gate says the agent cannot do it (R-216) | „Ez a gép **még nem tudja megnyitni** a mentéseidet… **A kódoddal semmi baj**…" |
+| **M3** | unlocked, inventory unreadable (R-217) | „**A kulcs visszakerült**, de a mentések listáját most nem sikerült beolvasni…" |
+| **M4** | unseal failed **and** a superseded package is retained (R-222) | „**Ez a kód nem nyitja meg azt a csomagot, amit most őrzünk** ehhez a géphez…" |
+
+**The venue retains a superseded package**, so M4's branch — tested **before** M1 on the failure path
+— is live for every failed unlock. That single ordering fact produces two of the four new findings.
+
+### Results
+
+| | Fault | Right answer | Result |
+|---|---|---|---|
+| **F1** | wrong code ×3 | refused, **M1 only**, no lockout, nothing written | **PARTIAL** — refused ✅, no lockout ✅, nothing written ✅, but **M4, not M1** → **R-226** |
+| **F2** | no code at all | states nobody can recover it; offers set-aside | **PASS** |
+| **F3** | hub unreachable | names **the hub**, never the code | **FAIL** — M4. → **R-224** |
+| **F4** | agent stopped | **M2**, the R-216 fix under pressure | **FAIL** — M4. → **R-224** |
+| **F5** | store unreachable after a successful unlock | unlock counts; „could not be read", not „opened with content" | **PASS** — R-217's fix holds |
+| **F6** | „Most nem", return later | entry point survives; unlock still works | **PASS** |
+| **F7** | set aside, then a change of mind | set aside, never deleted; honest afterwards | **SPLIT** — set-aside **PASS**, verified byte-for-byte; the afterwards **FAIL** → **R-228** |
+| **F8** | controller restarted mid-unlock | no half-state; the screen says which | **PARTIAL** — no half-state ✅, but a raw English `Bad Gateway` → **R-227** |
+| **F9** | a box that never had off-site | nothing, incl. a direct `GET /recovery` | **PARTIAL PASS** — R-215's gate proven live on a narrower shape; the literal precondition was not staged |
+| **F10** | app with a mandatory data path missing | run reports `incomplete`, names the app, digest carries it | **NOT INJECTED** — harness. Three attempts, each self-healed |
+| **F11** | box offline a whole reporting window | hub and box agree once it returns | **PASS** — both directions fired, each with an operator mail |
+
+### F7 — the set-aside, and the afterwards
+
+**The move-aside is exactly what it claims.** Both confirmations state the consequences first
+(*„félretesszük — nem töröljük"*, *„a gép új, üres mentési tárolót kezd"*, *„ez az oldal többé nem
+jelenik meg"*), and the result measured against the Storage Box:
+
+```
+BEFORE  /home/felhom-repo                    mtime 13:13   snapshot f3d9cd67   du -s 12535
+AFTER   /home/felhom-repo.orphaned-20260805  mtime 13:13   snapshot f3d9cd67   du -s 12535   ← untouched
+        /home/felhom-repo                    mtime 21:32   (empty)                           ← fresh
+```
+
+**Nothing deleted.** Then the customer changes their mind — and finds nothing: `GET /recovery` 302s,
+`POST /recovery/unlock` 302s in 0.028 s with no message, and `/backups/remote` never mentions the
+set-aside history at all, though the box records its exact path. → **R-228**
+
+### F9 — what was and was not proven
+
+The literal precondition (a box that never had off-site backups) needs a rebuild, which the brief
+forbids before Phase 4, so it was **not staged**. But **the assertion that failed in Phase 1 was
+tested and passes**: Phase 1's defect was that `GET /recovery` never asked the predicate. After F7
+drives `recoveryOffer()` false, `GET /recovery` → **302 `/backups/remote`**. **R-215's fix is proven
+live.** The `GetHubEscrowIdentityPresent()==false` arm remains covered by tests only.
+
+### F10 — not injected, and why that is a harness result
+
+Three attempts, each with a control confirming the directory was genuinely absent — and each
+self-healed before capture: (1) the app recreated it; (2) `docker stop` was undone by **the
+controller's own monitor restarting the stack**; (3) with the stack stopped through the controller
+API, the directory reappeared at **21:51:38.65**, coincident with the run's own start. All three runs
+reported `ok` with `1 mandatory path(s)`, and R-203's stat-gap correctly never fired, because by the
+time `os.Stat` ran the path existed.
+
+**The state F10 describes is not reachable on a deployed app of this kind.** Recorded as **harness,
+not product**.
+
+**One observation kept, with its evidence:** at capture the directory held only a recreated
+`metadata.db` and **not** the customer's `F10-SENTINEL.txt`, and the run still said `ok`. The verdict
+is about a path's *presence*, not its *content* — correct as designed, and it means an `ok` off-site
+run can immediately follow the loss of everything that path contained.
+
+### F11 — the dead-man's switch, both ways
+
+```
+23:28:11  ok → stale (host_stale)        + Operator email SENT
+23:29:59  Received report from c11        ← the box returns unaided
+23:30:11  stale → ok (host_recovered)     + Operator email SENT
+23:30:11  customer mail skipped — no unanswered customer down mail (pairing miss)
+```
+
+The customer mail was correctly **withheld** by the pairing gate under a real outage. **I5 holds** —
+box and hub agree after the return, judged after a full report cycle rather than from one read.
+**Not reached:** `STALE → DOWN` (>1 h); the outage was ended once both transitions had fired because
+Phase 4 needed the venue back.
+
+### The timing discriminator used throughout
+
+`age`'s scrypt makes a real unseal cost ~1 s. **Phase 1's headline was diagnosed by a 0.134 s
+response**, and the same instrument separates every fault below:
+
+| | elapsed | what it means |
+|---|---|---|
+| F1 wrong code | **1.194 / 1.004 / 1.014 s** | a real unseal was attempted and failed |
+| F3 hub down | **0.0556 s** | **no unseal attempted** — it failed before the KDF |
+| F4 agent down | **0.0299 s** | **no unseal attempted** |
+| F5 store down | **1.198 s** | a real unseal, which SUCCEEDED |
+
+**The customer sees the same sentence for the 1.0 s case and the 0.03 s case.**
+
+---
+
+## 5. Findings
+
+### R-224 — every non-code failure on the unlock path is reported as a statement about the code
+
+**F3 and F4 are one defect with two faces**, and it is Phase 1's headline finding relocated from the
+version channel to the transport.
+
+| | injected (control) | customer sees | machine's own log |
+|---|---|---|---|
+| **F3** | hub REJECTed (`302` → `exit 7`) | **M4** | `fetching the sealed bundle: hub: transport error: … no route to host` |
+| **F4** | `systemctl stop felhom-agent` (`:8443` gone) | **M4** | `dial tcp 169.254.253.1:8443: connect: connection refused` |
+
+In both the **correct, current** recovery code was entered, so the only possible cause of failure was
+the injected fault.
+
+**The discriminator exists and is discarded at the HTTP boundary.** The agent's own `err` separates
+the cases exactly —
+
+```
+wrong code : "escrow: the recovery code did not unwrap the identity escrow …"
+hub down   : "escrow: fetching the sealed bundle: hub: transport error: … no route to host"
+```
+
+— but both return **HTTP 400** under one merged sentence (*"the recovery code did not open the sealed
+bundle, **or the bundle could not be fetched**"*), the agent's own `msg=` collapses them too, and the
+controller's failure path has **no branch for "could not ask / could not reach"** at all. `rerr != nil`
+falls straight into the code/package messages.
+
+**Why R-216's gate did not catch F4**, measured rather than reasoned — from the box's debug ring:
+
+```
+[web] recovery capability gate: offsite_key_recovery=yes (source=version)
+```
+
+**`source=version`.** The gate answers from the *known agent version* without probe traffic, which is
+correct for the question it was built for (*is this agent too old?*) and cannot answer the question it
+is being used for (*can this machine ask right now?*). **A dead agent of the right version sails
+through it** — and the failure that follows is attributed to the code, which R-216's own comment says
+must never happen: *"An attempt that cannot succeed must never be made, because its failure is
+attributed to the code."*
+
+**Consequence.** During any hub outage or agent restart, a customer holding a perfect recovery code is
+told it does not open their package and is routed to customer support about *older* backups. **I6** —
+an unreachable service reported as a fact about the code.
+
+### R-225 — the store reports `0 snapshots · 0 GB` when it cannot read it, beside a card saying it holds backups
+
+Found while checking F6's *"the listing is coherent"* clause. `/backups/remote` renders, **on one
+screen**:
+
+```
+Tároló méret · 0 pillanatkép            Tárhelykeret: 0 / 50 GB (0%)
+```
+
+immediately above:
+
+> „**A távoli tároló másik kulccsal készült mentéseket tartalmaz.** … **A meglévő mentések nem
+> sérültek**…"
+
+**Ground truth, measured directly against the Storage Box over SFTP** — a read-only listing, no
+decryption, using the box's own transport credential:
+
+```
+/home/felhom-repo/snapshots:
+  f3d9cd67d539c00359f0454ea7a782f45beac8406c55275bee5a6886afa8d791   (Aug 5 13:14)
+/home/felhom-repo:   du -s → 12535 KB          /home/felhom-repo/keys:   exactly ONE key
+```
+
+That is the Phase 0 snapshot holding **all three sentinels** — the customer's only surviving copy —
+matching the journal's `repo_size_bytes 12 611 522`.
+
+**Mechanism, from the box's own state:** after the Phase 3 rebuild the `offbox` block in
+`settings.json` carries **no `snapshot_count` and no `repo_size_bytes` key at all**. The values are
+*unknown*, and unknown renders as the zero value.
+
+**This is R-217's defect class in a second location** — a field whose zero is indistinguishable from a
+real measurement, defaulted past on an unknown path. `OffsiteInventory.Empty` exists precisely because
+*"len(Apps)==0 is also what a failed read looks like"*. **I6.**
+
+**I5 checked and NOT breached:** the hub's `/offsite` shows `Campaign 11 · 0.0 GB`, but that is 12.5 MB
+rounded to one decimal of a GB and the pool total (`Used 3.8 GB`) is consistent. The two views do not
+disagree; **both understate, for different reasons**, and only the box's snapshot **count** — an
+integer — is false.
+
+### R-226 — M1, the only message that tells a customer to check their typing, is unreachable on any box that has re-escrowed
+
+The failure path tests M4's condition **before** M1's:
+
+```go
+if present, at := s.recoverySuperseded(); present { …M4…; return }
+…M1…
+```
+
+So on every box the hub keeps an earlier package for, a **genuinely mistyped code** produces M4 —
+which is hedged (*„**Ha** egy korábbi kódot adtál meg"*) and states two true facts, but offers no hint
+to re-check the ten words and routes the customer to support about older backups.
+
+**Measured:** F1's three wrong-code attempts each returned M4, each after a real ~1 s unseal.
+
+**Why it matters rather than being a nicety:** the population that has re-escrowed is exactly the
+population that has just been handed a new recovery code and is most likely to be typing one. R-222's
+fix removed one conflation (correct-earlier-code read as a mistype) and introduced another
+(mistype read as a correct-earlier-code) **on the same branch**.
+
+### R-227 — a restart mid-unlock returns a raw English `Bad Gateway`
+
+F8 restarted the controller at T+0.7 s, inside the unseal window (control: the container's `StartedAt`
+moved). The customer got:
+
+```
+HTTP 502 · "Bad Gateway"
+```
+
+A raw upstream error, in **English**, from traefik. It names no reason, offers no action, and says
+nothing about whether the key was installed. **I3** — *"every refusal names a reason a person can act
+on, in Hungarian, with no raw error."* Low severity (the window is ~1 s wide) and recorded rather than
+inflated.
+
+### R-228 — the set-aside history becomes invisible the moment it is set aside
+
+The move-aside is correct and was verified byte-for-byte (§F7). What follows it is not.
+
+```json
+"orphaned_renamed_to": "/home/felhom-repo.orphaned-20260805"
+```
+
+The box records the exact path. And:
+
+```
+grep -rn "OrphanedRenamedTo" internal/web/templates/ internal/web/*.go   →   (no hits)
+```
+
+The field is **written and read by nobody**. `/backups/remote` after the set-aside contains no
+occurrence of the path, „félretéve", „régi előzmény" or any equivalent — with instrument controls
+passing (`felhom-repo` → 2, „letétbe helyezve" → 1), so the page and the matcher both work.
+
+> **12.5 MB of the customer's deliberately retained data sits at a path the box knows and never
+> shows.** Its only mention is a flash message on the redirect, gone on the next click.
+
+**The project's own "seam built but never wired" pattern** — the fifth recorded instance — landing on
+the one promise the set-aside screen makes. The fix is a plain statement that an earlier history is
+set aside and not deleted; **it must not promise the history can be reopened**, because R-222 means it
+cannot be, and that is exactly the conditional promise R-202's gate exists to prevent.
+
+---
+
+## 6. What behaved correctly
+
+**A campaign that reports only what broke is half a campaign.** These were tested and held.
+
+| | |
+|---|---|
+| **R-217's fix** | F5: with the store blocked after a successful unlock, the page rendered M3 and **no listing block at all**. The four false-claim strings („A tároló megnyílt", „van benne tartalom", „nem tudtuk alkalmazásokhoz rendelni") are absent — verified in UTF-8 with two accented positive controls present, after the documented accented-substring false-zero trap was accounted for |
+| **No lockout** | F1: three wrong codes, three identical responses, no rate limit, no refusal to try again — as `§8.4 NO LOCKOUT` documents |
+| **Nothing written on failure** | F1: all four `/data/offbox` files byte-identical, **mtimes frozen at 14:57:35** |
+| **I4** | the entered code appears in **no** log, file or page. Sweep run with a planted-canary control first; the only hits were the harness's own script |
+| **The „Most nem" asymmetry** | F6: the full page stops interrupting `/launcher` and `/dashboard`, while `/recovery` stays 200 and the backups-area entry point survives — bound to the offer, never to the postpone flag |
+| **No half-state** | F8: a restart mid-unlock left the key files and `settings.json` coherent; the controller returned healthy in 40 s |
+| **R-215's fix** | the `GET /recovery` gate is present in v0.201.0 and consults the same predicate as the POST sibling |
+| **R-198's retention, in the UI** | the hub host page reads „Key Escrow: present · **1 superseded escrow blob(s) retained**" |
+| **The empty submission** | F2: „Add meg a helyreállítási kódot." in 0.027 s — no unseal, and no blame attached to a code never given |
+
+---
+
+## 7. Harness faults, separated from the product's
+
+**Four, all mine, none a product defect** — recorded because Campaign 10's §4d is the format and
+because two of them nearly produced false findings.
+
+1. **`source ~/.config/credentials` echoes secrets.** The file holds keys with hyphens
+   (`R_DEMO-HP=…`) that bash cannot assign, and the `command not found` error **prints the value**.
+   Two demo-box recovery codes were printed this way before the helper was rewritten to `grep` the one
+   key it needs. **A live I4 hazard for any session that sources that file** — worth a memory, not a
+   register row.
+2. **Quoted values in that file** — a bare `cut -d=` keeps the quotes and yields the wrong secret; the
+   hub returned `302` until they were stripped. Already in project memory; re-confirmed.
+3. **The recovery page carries no `<meta name="csrf-token">`** — it renders a hidden `_csrf` input
+   (`data["CSRFField"]`). The first F1 run produced three `403`s and `CSRF-LEN-0`; **the harness's own
+   length check caught it**, and the controller's log named the reason word (`token mismatch`).
+   Harness, not product.
+4. **Two failed reachability controls, reported as failures.** The F5 probe first used `nc`, which the
+   controller container does not have, so blocked and unblocked printed the same fallback; the second
+   attempt used the IPv6 address `getent hosts` prefers, and **the container has no IPv6 route at
+   all**. Only a `/dev/tcp` probe against the IPv4 address (`91.98.242.176`) discriminated
+   `TCP-OPEN` → `TCP-CLOSED`. **Two readings that looked like results and were instrument failures.**
+
+---
+
+## 8. Suspicions investigated
+
+| | verdict |
+|---|---|
+| *"The floor is still held — there is no HELD line and no held reason"* | **DISPROVED.** Both absences were real, and both are explained: the hub stops logging when it stops holding, and `SetFloor`'s DEBUG line cannot reach the debug ring at all. The floor is served, measured two ways (§3) |
+| *"The hub and the box disagree about the store's contents (I5)"* | **DISPROVED.** Both understate; the hub's `0.0 GB` is rounding of 12.5 MB. Only the box's snapshot **count** is false → R-225, which is an I6 finding, not an I5 one |
+| *"`GET /recovery` still renders on a box it should not"* | **CONFIRMED FIXED** — the gate is present in v0.201.0 (§9, F9) |
+
+---
+
+*(Sections 9–12 — F7, F9, F10, F11, Phase 4, invariants, teardown and hygiene — follow below.)*
+
+---
+
+## 8b. Phase 4 — the unattended soak
+
+**23:56 → 04:35, venue untouched.** 30 five-minute samples plus a full log census. **Expectations were
+pre-registered in the journal BEFORE the window**, in both directions, so nothing here is fitted
+afterwards.
+
+### Everything scheduled fired, exactly once, on time
+
+| job | due | result |
+|---|---|---|
+| `db-dump` | 02:30 | ✅ 5.237 s |
+| `tier2-backup` | 03:30 | ✅ 118 ms — **and the copy is real** (below) |
+| `fill-watch` | 03:30 | ✅ |
+| `metrics-prune` | 04:00 | ✅ |
+| **`offbox-backup`** | **04:15** | ✅ **24.884 s — `snapshot_count` 1 → 2, `last_status: ok`** |
+
+**The off-site tier runs itself, unprompted, on a box that was rebuilt twice and had its repository set
+aside four hours earlier.** That is the strongest positive of the whole campaign for the backup
+promise, as distinct from the recovery journey.
+
+### Nothing fired that should not have
+
+`needs_credential` 0 · `offsiteheal` 0 · `offbox_repo_orphaned` 0 in-window · `offsite_repo_key_changed`
+0 · `escrow blob SERVED` 0 · `host_stale`/`host_recovered` 0 · self-update 0 · operator emails 0.
+
+> **§4.2's negative control passes.** A box that HAS a target did not declare `needs_credential` once
+> in five hours. R-218's fix is not over-firing in the other direction — which does **not** substitute
+> for its positive half, still owed.
+
+### Investigated and DISPROVED — `tier2-backup` in 118 ms
+
+It looked like a scheduled backup that silently no-ops. It is not: `Tier 2 copied calibre-web →
+/mnt/felhom-drives/mentes/backups/secondary/calibre-web (818.5 KB, 1 leg(s), 0s)`, and the copy is on
+the backup drive. 388 KB on local NVMe in 118 ms is honest. **No finding.**
+
+### A correction to my own pre-registration
+
+I pre-registered a `backup_run_digest` event. **No such event type exists** — that is a *test
+filename*, and the real one is **`backup_run_failures`**, a failures digest whose silence on a clean
+night is correct. Reporting it as a miss would have been a finding invented by a bad reading.
+
+**What survives the correction:** the off-site run emitted **no hub event at all**, while both lesser
+tiers announced success (`db_dump_completed`, `crossdrive_completed`). Failures are covered by
+`backup_run_failures` and staleness by the hub's tier deadline monitor
+(`offsiteBackupStaleAfter = 8 days`), so this is **a consistency wrinkle, not a blind spot** —
+recorded, not filed.
+
+### What should have fired and did not — answered in both directions
+
+- **The restore-test did not run, and that is CORRECT** — `eval_interval=6h` (armed 23:29:43, first
+  evaluation ~05:29) with a **24 h settle** on archives hours old. **Pre-registered as "expected not to
+  run"**; without that, its silence would have read as a gap.
+- **The agent's whole-guest tier did not run, and whether it should have is NOT RESOLVABLE.** The box
+  reports `0 backups` all night; the agent is emphatically alive (**2 091 of its own lines** since
+  00:00, polling the guest at 04:17:57); **but routine local-api requests are not logged at INFO** — a
+  five-hour search for `local-api` returns **0** on a box that demonstrably served such calls earlier —
+  so "no `/backup/due` poll" is **not evidence**. The hub's deadline monitor is equally invisible at
+  INFO. **Recorded as an open question, not scored as a pass.**
+
+---
+
+## 9. Invariants at every phase boundary
+
+| | | verdict |
+|---|---|---|
+| **I1** | no customer data destroyed without an explicit confirmation naming what is lost | **HELD.** The only destructive act was F7's set-aside, behind **two** confirmations that name the consequences first; and it does not destroy — `du -s 12535` before and after |
+| **I2** | a green status never coexists with missing mandatory data | **HELD as tested, with a caveat.** F10 could not be injected, so the intended test never ran. The caveat is recorded rather than scored: an `ok` run captured a recreated directory that no longer held the customer's file |
+| **I3** | every refusal names a reason a person can act on, in Hungarian, with no raw error | **BREACHED twice.** F8's `Bad Gateway` (raw, English) → R-227. And R-220's refusal still names an action the customer cannot perform (the list it points at is empty) — reproduced live a third time |
+| **I4** | no secret anywhere — code, repository password, blob, credential | **HELD on the product.** The F1 sweep found the entered code in no log, file or page, with a planted-canary control passing first. **Breached by the HARNESS**, not the product: `source ~/.config/credentials` echoed two demo-box recovery codes into the session transcript (§7) |
+| **I5** | the hub's view and the box's never disagree about protection | **HELD.** Checked at the F11 boundary after a full report cycle. The apparent `0.0 GB` disagreement was investigated and DISPROVED (rounding) |
+| **I6** | an absence is never reported as a fact | **BREACHED twice.** R-224 (an unreachable hub/agent reported as a fact about the code) and R-225 (an unread store reported as `0 pillanatkép · 0 GB`) |
+| **I7** | nothing reaches a machine outside the venue | **HELD.** Every fault was applied to VM 321 or its guest. Both demo boxes were read, never written. Nothing was deleted on ep0 or the Storage Box — F7's move-aside is a rename **inside the campaign's own sub-account home** |
+
+---
+
+## 10. RTO — unchanged, and why this campaign does not move it
+
+**Phase 1's number stands: undefined for an unaided customer**, because the unaided journey does not
+complete. The attended figure — **61 minutes, three of whose four blockers needed root on the
+appliance** — is Phase 1's and is not re-measured here. **Phase 2's faults are not a re-walk**, and
+nothing in them shortens or lengthens that path.
+
+**The only segment that reflects the product working remains Phase 1's last one: 16 seconds to pull
+12.8 MB back out of the off-site repository once everything was in place.**
+
+Phase 2 does add one measurement to the picture: **the off-site tier, once healthy, works
+unremarkably.** Three manual runs completed in 18 s, 59 s and 1 m 4 s, and the scheduled run is
+reported in §11.
+
+---
+
+## 11. Teardown — OWED, nothing removed
+
+**Deliberately not torn down.** Phase 4 needed the venue, this document had to be written first, and
+**deleting evidence unattended is worse than leaving a VM running.** All three layers are owed, plus
+the off-site side.
+
+| layer | what it will need |
+|---|---|
+| **1. The machine** | VM **321 `c11-appliance`** on `demo-hp` and its three disks (`scsi0` 200 G, `scsi1` 50 G, `scsi2` 50 G) on `c11-scratch`. `qm stop 321 && qm destroy 321 --purge` |
+| **2. The host** | `pvesm status` on `demo-hp` **before and after**, and the space returned recorded. The `c11-scratch` storage definition itself, once empty |
+| **3. The hub** | customer **`c11`** and host **`c11-36d660`**: the customer Danger-zone Delete is the one true purge point (it cascades both escrow tables). **⚠ It destroys the retained escrow custody** — which is the point, but say so before pressing it |
+
+**The off-site side — and this one needs the most care:**
+
+- The campaign's **Storage Box sub-account 284166 / `u629488-sub4`**, holding **two** repositories:
+  `/home/felhom-repo` (the fresh one, ~26 KB) and **`/home/felhom-repo.orphaned-20260805`
+  (12 535 KB — the Phase 0 history with all three sentinels)**.
+- On **ep0**: namespace `c11`, token `felhom@pbs!c11`, and the two ACL lines on
+  `/datastore/felhom-offsite/c11`. **`demo-felhom` and `demo-hp` namespaces and tokens must not be
+  touched** — the Phase 0 capture recorded all three so teardown can tell them apart.
+- The WireGuard peer for `c11-36d660` (`10.77.0.5/32`).
+
+**Delete nothing that is not the campaign's own.** The brief's §8 warns that scratch customers have
+accumulated before; the Phase 0 census found **none** outstanding, and c11 must not become the next.
+
+---
+
+## 12. Hygiene
+
+- **The recovery codes are SHREDDED**, with the plant→find→shred→fail-to-find control the brief asks
+  for. **The control paid for itself on its first run**: it found the Phase 0 code in
+  `~/.config/credentials` as **`R_CAMPAIGN_11`** — a copy this session did not create and would never
+  have looked for, which would have made a "codes shredded" claim **false**. That key was removed from
+  the shared file carefully (backup → exact-match removal → `diff` proving every other line identical →
+  `HUB_PW` re-verified at `hub:200` → backup shredded). Everything else was `shred -u`'d on both hosts
+  and the absence re-swept; only the planted controls remained, and they were shredded too.
+  **⚠ Consequence, stated plainly: `/home/felhom-repo.orphaned-20260805` (12 535 KB, the three Phase 0
+  sentinels) is now permanently unopenable.** That is what the set-aside screen promises will happen,
+  teardown removes the repository anyway, and R-222 means no read path existed for it regardless — but
+  the door is now shut for good.
+- **No secret is written into any committed file.** Every hash quoted here is a sha256 prefix; the
+  codes' contents appear nowhere.
+- **`git add -A` was never used** — every commit staged explicit paths, and `git status --porcelain`
+  was checked before each one to confirm no foreign file was swept (a parallel session shares this
+  clone).
+- **The pre-push hook is armed on this clone** (`core.hooksPath=.githooks`) and ran
+  `repo_gates.py --fast` green before every push. **No `--no-verify` was used.**
+- **No product code was changed.** Every finding was filed and the run continued, per the brief's
+  rule 1.
+- **No version was bumped** in any repo.
+
+
+---
+
+## 13. What did not run, and why
+
+| | why |
+|---|---|
+| **F10 as specified** | **Not injectable.** Three attempts, each with a control: the app, then the controller's monitor, then the run itself recreate the mandatory directory within ~1 s. The state does not exist on a deployed app of this kind. **Harness, not product** |
+| **F9's literal precondition** | A box that never had off-site backups needs a **rebuild**, which the brief forbids before Phase 4. The assertion that failed in Phase 1 (the page not consulting its predicate) was tested instead, and passes |
+| **§4.2's positive half** | Needs shape (a) — hub blob present, key placed, **no target**. The venue has a target, so the box correctly does not declare. Also needs a rebuild |
+| **`STALE → DOWN` escalation** | F11 was ended once `stale` and `recovered` had both fired, because Phase 4 needed the venue back. The >1 h arm is untested |
+| **The whole-guest tier's due-ness** | **Not resolvable with existing instruments** — routine local-api calls and the hub's deadline monitor are both invisible at INFO. Recorded as an open question, not scored |
+| **The retained package's read path** | Does not exist (R-199's inventory is unbuilt). R-222 was re-confirmed live rather than re-tested |
+| **A re-walk of the journey** | **Deliberately out of scope.** These faults are not a re-walk, and the capability map's recovery row stays **FAIL** until one passes |
+| **Any fix** | Brief rule 1 — file and continue. **No product code was changed and no version bumped** |
+
+---
+
+## 14. Venue state at the end — **WORKING**
+
+| | |
+|---|---|
+| Hub | `c11-36d660` **ONLINE**, agent `0.125.0`, 1/1 guests, reporting on schedule (last seen 04:29:54) |
+| Containers | `calibre-web` · `filebrowser` · `felhom-controller:0.201.0` · `traefik` — all healthy |
+| Drives | both enrolled; backup target `{"degraded":false,"label":"mentes","target":"felhom-backup"}` |
+| Off-site | **2 snapshots**, `last_status: ok`, `last_success 2026-08-06T02:15:24Z`, 51 206 B, `escrow_state: escrowed` |
+| Set aside | `/home/felhom-repo.orphaned-20260805` — 12 535 KB, intact, and now **permanently unopenable** (§12) |
+| Left in place | the raw `/mnt/adatok` and `/mnt/mentes` mounts remain **unmounted** — R-220's workaround, without which no app can be deployed on a rebuilt box. The stable `/mnt/felhom-drives/*` mounts are what everything uses |
+| Access | the appliance's vaulted root credential was **shredded with the codes**, so a future session must re-fetch it from the hub (`POST /hosts/c11-36d660/reveal-recovery-credential`) — the designed path |
+
+**Nothing is left broken, and nothing is left running that should not be.**

documentation/audits/CAMPAIGN-12-class-sweep-2026-08-08.md

@@ -0,0 +1,429 @@
+# CAMPAIGN 12 — the class sweep (2026-08-08, unattended)
+
+**Look for the siblings of everything this arc found, by class rather than by feature.** Nothing was
+fixed, nothing was deployed beyond Part 1's golden, and no machine was touched beyond the bake VM,
+which was torn down.
+
+Baselines re-read on arrival, all three clean and equal to `origin/main`:
+
+| Component | Version | commit |
+|---|---|---|
+| `felhom-controller` | released **v0.208.0** | `37b5ba08a704` |
+| `felhom-agent` | v0.127.0 | `703db166e762` |
+| hub | v0.98.0 deployed | `59527d00f9c4` |
+| `app-catalog-felhom.eu` | — | `459766c` |
+
+Highest register ID on arrival **R-255**; re-checked before minting, unmoved. This session opens
+**R-256 … R-263**.
+
+---
+
+## 1. The bake — and the one approval awaiting the operator
+
+**Golden 0.208.0 is baked, published and round-trip verified. It is NOT vouched.** Full evidence:
+`documentation/tests/golden-0.208.0-2026-08-08/` (README + the 324-line `bake.log`).
+
+| | |
+|---|---|
+| version | **0.208.0** (derived from the controller image, which is a required argument) |
+| size | **656 150 362 B** |
+| sha256 | **`ba668f59f063511dda122a5b05900f1350573cdc9619980872f87a58755ffb82`** |
+| round trip | downloaded back from Gitea, hashed independently on DooPlex — **size and sha identical** |
+| **the delivered artifact's own claim** | `./etc/felhom-controller-image` read **out of the downloaded archive** → `gitea.dooplex.hu/admin/felhom-controller:0.208.0` |
+| fourth confirmation | the sha the hub's `/configuration` dropdown offers for 0.208.0 matches the bake exactly |
+
+**Acceptance markers, each grepped verbatim against the real log:** `docker OK (overlay2; data-root
+/var/lib/docker)` ×1 · `including mount point` ×2 (rootfs **and mp0**, no mp1) · `upload OK (HTTP 201)`
+×1 · `excluding` ×0 · `FATAL` ×0 · `mp1` ×0. `Result=success`, `ExecMainStatus=0`.
+
+**Hygiene.** The token was copied **file → file** and read from a `0600` file **inside** the VM by a
+runner script; `systemctl show golden-bake -p Environment -p ExecStart | grep -c -F <token>` → **0**.
+The committed log greps **0** for the literal token, **and the grep was shown to work first** — the
+same grep on a copy with the token appended returned **1**, then the copy was shredded.
+
+**404 pre-gate with a control:** `…/0.207.0/golden.tar.zst` → **200** (the URL shape is right),
+`…/0.208.0/golden.tar.zst` → **404** (nothing to overwrite).
+
+**Teardown:** `pct destroy 9100 --purge`, `pct list` empty; token/runner/script/log `shred -u`'d and
+`/root` residue clean; `poweroff`; qemu confirmed gone via `ps -eo comm | grep -c qemu-system-x86` → 0
+(never `pgrep -f`, which self-matches); **`qemu-img snapshot -a virgin` restored** and the snapshot
+list re-read.
+
+### ⚠ THE ONE THING ASKED OF THE OPERATOR
+
+**Vouch golden 0.208.0** — hub → Configuration → Day-0 artifacts → Golden `0.208.0` → Save.
+
+| field | now | after | why |
+|---|---|---|---|
+| `golden_version` | 0.207.0 | **0.208.0** | **the only field that moves** |
+| `agent_version` | 0.127.0 | 0.127.0 | already ≥ `MinAgent 0.127.0` — read from the controller CHANGELOG header, checked not skipped |
+| `min_agent` | 0.127.0 | 0.127.0 | equals the declared `MinAgent`; **not above `agent_version`** (the R-216 shape hub v0.97.0 holds) |
+
+**Vouching is reversible** — re-select 0.207.0 and Save. The 0.207.0 package was not deleted (the
+publish step's pre-delete targets only its own version), so a rollback is a form submission.
+
+**Until that Save, a machine installed tonight still receives controller 0.207.0.**
+
+---
+
+## 2. What golden is vouched, and the currency gate's state
+
+- **Vouched at the time of writing: golden 0.207.0**, agent 0.127.0, `min_agent` 0.127.0,
+  `min_controller_version` 0.156.0 — read live from the hub, not from a document.
+- `golden_currency_gate.py` was **RED on arrival** (`controller v0.208.0 is released and NO golden
+  carries it`) exactly as §1 of the task predicted, and is **GREEN after the bake**.
+- **No `--no-verify` was needed anywhere in this session.**
+
+---
+
+## 3. Per class — new instances, the control, the method, and its blind spots
+
+### C1 — a secret in a response body
+
+**New instances: 0** on the surface the class names (a response body a customer can fetch).
+
+**Control — the shipped gate re-finds 2 of the 3 known instances, measured not assumed.** The three
+pre-fix templates were restored from history (`8dbbc98^`) into a scratch copy of the controller and
+`scripts/secret_in_markup_gate.py` was run against them. It convicted
+`settings_security.html:408`, `:430` and `app_info.html:185`, and **did not convict**
+`deploy.html:482` (`value="{{$val}}"`) — R-255's stated blind spot, now verified by replay rather
+than by reading its docstring. The gate passes clean over today's 36 templates.
+
+**Method (the new half).** The shipped gate is name-based on the TEMPLATE side. This sweep is its
+mirror on the GO side: every assignment into template data, a JSON response map or a render struct
+whose **right-hand side** names a secret, regardless of what the **key** is called — the shape the
+gate cannot see. 27 sites matched; 5 under a key that does not itself announce a secret.
+
+All 5 resolve to non-findings, and the reasoning is recorded in §6.
+
+**Blind spots.** One hop only — a secret laundered through a neutrally-named local two or more hops
+from its source is invisible. Struct-literal page data is covered only in the field-assignment form.
+A secret fetched inside a helper the handler calls is invisible. And the whole sweep reasons about
+**source**, never about rendered bytes — the runtime body assertion remains the only check that
+catches all three known shapes, and it still covers 4 of 27 pages.
+
+### C2 — a refusal that names no route
+
+**New instances: 2 (R-256, R-257).**
+
+**Control.** The known instances (R-252, R-253) were re-read in their pre-fix form at `8dbbc98^` and
+in today's tree. The method distinguishes them correctly: the pre-fix strings state a reason and stop
+(*"nincs mentés felhasználói adattal"*), and today's `backups_restore.html:79` names the route —
+*„Meghajtók", „Meglévő meghajtó csatolása". Utána gyere vissza ide.* **2 of 2 re-found, as fixed.**
+
+**Method + what was SAMPLED.** 221 distinct customer-visible refusal strings exist across the
+controller's production code. **This was NOT swept exhaustively.** The sample is the three files on
+the surface where both known instances lived — `recovery_handlers.go`, `offbox_handlers.go`,
+`restore_wizard.go` — yielding 19 distinct refusals, all read by hand. **The other ~202 strings were
+not examined.**
+
+**Blind spots.** Refusals composed at render time from template fragments are invisible to a
+string-literal grep; so are refusals whose text lives in the HTML rather than in Go. "Names a route"
+is a judgement, not a predicate — two readers could disagree on the borderline cases, and three of
+the 19 were called borderline and left unfiled.
+
+### C3 — a success verdict over an incomplete state
+
+**New instances: 1 (R-258). This class was swept COMPLETELY, not sampled.**
+
+**Method.** Every assignment of a success-valued status in the controller's production code:
+**9 sites**, all read. That is the whole population, which is why this is the one class where
+"no others exist" is a claim the method can support.
+
+**Control — 2 of 3 known instances re-found, and the third re-found as fixed.** `offbox.go:1040`
+still carries R-240 verbatim: a configured box with nothing selected reports `LastStatus = "ok"` with
+the warning *„Sikeres — nincs mentésre jelölt alkalmazás"*. R-234's fix is visible in the same block
+(`missingUnprotected` → `incomplete`). R-203's mandatory-gap fix likewise.
+
+**Blind spots.** It sees only *literal* success values assigned to a name matching
+`Status|State|Verdict|Result`. A verdict expressed as a boolean, an enum constant, or the absence of
+an error is invisible — and the controller does use booleans for verdicts elsewhere. It covers the
+controller only; the hub and agent were not swept for this class.
+
+### C4 — an absence reported as a fact
+
+**New instances: 1 (R-259).**
+
+**Control — the fix pattern re-found.** R-225's `StatsKnown` is exemplary and the sweep re-finds it
+intact: on `backups_remote.html` every derived figure — size, snapshot count, quota text and the
+**bar itself** — is behind `{{if .Offbox.StatsKnown}}`, with the honest alternative text
+*„a pillanatképek száma még ismeretlen"*. Its own comment states the principle this class is about:
+*"a 0%-wide bar over an unread store is a picture of emptiness, and a picture is a claim."*
+
+**Method.** Enumerate the rendered counts/sizes/percentages in the 36 templates, then ask of each
+whether a `*Known`-style companion exists and whether the producing Go call can fail into a zero.
+
+**Blind spots.** Name-based on the companion flag — a three-state encoding done some other way (a
+pointer, a sentinel, a separate error field) reads as "unguarded" and needs a human look; two
+candidates were dismissed that way. Only the controller's templates were covered; the hub's operator
+UI was not.
+
+### C5 — a field one side sends and the other drops
+
+**New instances: 1 register row (R-260) carrying a measured census of 8+ dropped fields.**
+**This class was the highest-yield, as predicted.**
+
+**Control — re-found.** The known instance is live: the hub's `store.EscrowStatus` carries
+`Stale bool json:"escrow_stale,omitempty"` and the controller's `report.EscrowStatus` has no matching
+field. **Correction to the task's framing, recorded rather than dropped: this is R-247 and it is
+`READY`, not closed.** The live repo is the source (rule 7).
+
+**Method — and the first one was wrong.** Attempt 1 paired structs across repos by json-tag-set
+overlap. It false-positived badly, because the hub decodes the same controller report through
+**several ad-hoc anonymous structs** — `offsite.state` and `offsite.abandon_purge_requested` looked
+dropped and are in fact consumed at `api/handler.go:530` and `store/store.go:1490`. Attempt 2 is the
+**tag-reachability test**: for every json tag emitted on a real wire, does that literal string occur
+**anywhere** in the receiving repo? A tag that occurs nowhere cannot be decoded by any struct, named
+or anonymous. That is definitive, and it is the version that generalises into a gate.
+
+**Blind spots, several of them earned during the sweep.** (a) The emit sets initially included
+*decode* structs — `hostReportPayload`, `applianceRegisterReq`, `WireDesiredState` — producing
+nonsense in the reverse direction; those rows were struck. (b) The struct extractor **flattens
+anonymous nested structs**, which produced a phantom asymmetry on `hostStorageTarget` (§6). (c) 29
+generic tag names (`name`, `type`, `state`, `status`, …) were excluded by name because a repo-wide
+string test is meaningless for them — **a genuine drop of a generically-named field would be missed.**
+(d) It cannot tell a deliberate ignore from an accidental one; the hub's `hostReportPayload` documents
+that it ignores several collections on purpose, and those were not counted.
+
+### C6 — built and never wired
+
+**New instances: 1 (R-261). The more valuable output is the method result, not the list.**
+
+**Control — and the standard tool FAILS it.** `golang.org/x/tools/cmd/deadcode` was run against all
+three binaries and **re-found neither** known instance. A **planted probe** measured why: an
+unreachable exported *function* added to the hub's store package is reported; an unreachable exported
+*method* on `*Store`, in the same file, is **not**. RTA treats the method set of a dynamically-used
+type as potentially reachable. **Both known instances are methods** — `(*Store).MarkEscrowStale` and
+`(*RestoreTestState).Snapshot`, both confirmed still callerless today — which is exactly the shape it
+cannot see.
+
+A method-aware textual sweep was then written. It re-finds **1 of 2** (`MarkEscrowStale`); it misses
+`RestoreTestState.Snapshot` because a `.Snapshot()` call on a *different* type in
+`guestnet/report.go` satisfies its name-based test. **So: 1 of 2, and stated as 1 of 2.**
+
+**Findings after triage: small, and mostly inert — which is itself the result.** 137 raw candidates →
+31 whose doc comment claims a consumer → after removing method-values-as-callbacks
+(`PBSDRAutoProvision`), cross-repo name reuse (`DebugLogs`, `AppStopGuard`) and template dispatch,
+five genuinely have only their own declaration. Four of those five are **inert**: the data reaches its
+stated consumer by another route. `OffboxOrphanedRenamedTo` says *"for the card copy"* and has no
+caller — **but R-228 is genuinely closed**, because the card reads the settings field
+`.Offbox.OrphanedRenamedTo` directly in `backups_remote.html:80`. Same for `OffboxEscrowState`.
+**An unwired accessor whose data reaches its consumer another way is dead code, not a defect**, and
+ranking it as one would inflate this class.
+
+The one that is not inert is R-261.
+
+**Blind spots.** Go **templates** call methods with no `.Name(` syntax; method **values** passed as
+callbacks likewise; reflection and struct-literal function fields likewise. Same-name methods on
+different types are conflated, which makes the sweep conservative — it under-reports and never
+over-reports. A method used only inside its own file counts as used, so whole-subsystem orphans are
+invisible.
+
+### C7 — a comment asserting an invariant the code does not hold
+
+**New instances: 2 (R-262, R-263), both found while sweeping other classes.**
+
+**Method + what was SAMPLED — this is the class where the honesty matters most.** There are **4092**
+comments across the three repos matching the invariant vocabulary (`never` / `always` / `must not` /
+`cannot` / `is the only` / `guarantees` / `impossible`) — 2652 in production code and 1440 in tests.
+**Exhaustive is not possible in one session and was not attempted.** The sample is the **60 production
+comments containing "is the only"**, chosen because a uniqueness claim is the one form that is
+*mechanically falsifiable* by a grep. Of those 60, the safety-bearing ones were tested by hand.
+**The other ~2592 production comments and all 1440 test comments were not examined** — and the task's
+own instruction to check the tests' claims is therefore **only partly discharged**: the two instances
+below are production comments.
+
+**Control.** The nine known instances are the repo's own table (in the `felhom-testing` skill) and are
+closed; the sample re-finds the *pattern* rather than the instances, so **C7 has the weakest control
+of the seven and should be read that way.**
+
+Both new instances are stated in the register. The sharper one, R-262, is the campaign in miniature:
+a comment claiming a contract is mirrored *field-for-field* and *guarded by a key-set test*, where the
+contract is two fields short **and the fixture the test reads omits the same two fields** — the
+instrument is blind in exactly the place the defect is.
+
+---
+
+## 4. Which classes can be gated — the ranking
+
+Ranked by what a gate would be worth, using this campaign's own instance counts as the evidence.
+
+| rank | class | gateable? | cost | what it would MISS |
+|---|---|---|---|---|
+| **1** | **C5** | **Yes — cheaply and definitively** | ~150 lines of Python, no network, `--fast`-eligible | generically-named tags; a deliberate ignore looks like an accident, so it needs an allowlist-with-reasons like the C1 gate has |
+| **2** | **C3** | **Yes** | small — the whole population is 9 sites | verdicts expressed as booleans or as the absence of an error |
+| **3** | **C4** | **Partly** | medium | the companion-flag convention must be adopted deliberately; a gate can enforce "every rendered figure has a `*Known`" only once that is the house style |
+| **4** | **C1** | **Already gated, partly** | completing it is the expensive one | see below |
+| **5** | **C7** | **Narrowly** | small for the narrow form | only uniqueness claims are mechanical; the other ~97% of the vocabulary is not |
+| **6** | **C2** | **No, not mechanically** | — | "names a route" is a judgement; a gate could only enforce a *convention* |
+| **7** | **C6** | **No — and this is the finding** | — | the off-the-shelf tool is blind to the project's own shape, measured |
+
+**C5 is the clear first.** The tag-reachability test is a string comparison over two repos' source: it
+convicts definitively (a tag occurring nowhere in the receiver cannot be decoded), needs no network,
+and would have caught the escrow_stale instance, the `operator_key_configured` instance and every
+other row in R-260's census on the commit that introduced them. **It is the cheapest high-value gate
+available to this project.** Its one design requirement is an allowlist with stated reasons, because
+the hub deliberately ignores some collections.
+
+**C6 does not hold, and saying so is the point.** The class *looks* the most mechanical of the seven
+and it is the one where the standard tool measurably fails. Any gate here would have to be written
+from scratch, would be conservative by construction, and — on this campaign's evidence — would spend
+most of its output on inert dead accessors. **Recommendation: do not gate C6. Gate C5 instead, which
+catches a strict subset of the same "the answer was available and discarded" family with none of the
+ambiguity.**
+
+**C1's existing gate, stated honestly.** `secret_in_markup_gate.py` covers all 36 templates on the
+name-based check and is **blind to the neutral-page-data-key shape** — measured this session by replay,
+not merely quoted: it convicts 2 of the 3 known instances and not the third. The runtime body
+assertion, which catches all three, covers **4 of 27 pages**. Completing it means constructing each
+remaining page's data in a test — the cost is per-page and real, and it is the honest reason it has
+not been done. The Go-side mirror written for this campaign is a cheap partial third net and is **not
+recommended as a gate on its own**: it produced 27 candidates and 0 findings, which is a bad
+signal-to-noise ratio to put in front of every push.
+
+**Nothing was built.** These are candidates recorded in `backlog/ROADMAP.md`.
+
+---
+
+## 5. Harness faults, separated from product faults
+
+**Harness, not product:**
+
+1. **My first C5 method was wrong** and would have produced ~10 false findings had it been believed —
+   struct-pair diffing cannot see a receiver that decodes through ad-hoc anonymous structs. Replaced,
+   not patched over.
+2. **My struct extractor flattens anonymous nested structs**, which manufactured a phantom
+   `hostStorageTarget` asymmetry (§6).
+3. **A `grep -v host_oob.go` excluded `monitor/host_oob.go` too**, and I briefly believed
+   `GetHostOOBStates` had no caller. Caught by checking before writing it down. Excluding by basename
+   is a trap worth naming.
+4. **`deadcode` failing its control** is a harness fault in the sense that matters here — but it is
+   reported as a *result* in §3/C6, because "the standard tool cannot see this project's shape" is
+   exactly what Part 4 was asked to establish.
+
+**Session hygiene, recorded:** this session did **not** run inside `tmux`, contrary to the workspace
+`CLAUDE.md`. Nothing was lost, but the whole unattended run was one dropped connection from dying.
+
+---
+
+## 6. Suspicions investigated and DISPROVED
+
+A campaign reporting only what it found is half a campaign.
+
+1. **`offsite.state` / `offsite.abandon_purge_requested` are dropped by the hub.** **DISPROVED.**
+   The hub's `monitor.offsiteReport` has neither, but both are consumed through separate ad-hoc
+   structs — `api/handler.go:530` and `store/store.go:1490`. This is what killed method 1.
+2. **A restore-test mount-parity mismatch is invisible to the hub.** **DISPROVED, and it mattered.**
+   `mount_parity` and `mount_inventory` genuinely are dropped, but a mismatch sets `res.Err` and
+   returns **before** `res.Pass = true` (`reconcile/restoretest.go:277-283`), so the *verdict* travels
+   as `pass:false` with the delta in the error string. What is lost is the *depth* of a pass, not the
+   failure. R-260 states it that way rather than the way it first looked.
+3. **`hostStorageTarget` does not mirror the agent field-for-field.** **DISPROVED.** The 11 "missing"
+   SMART fields are nested under `smart` on both sides; my extractor flattened the hub's anonymous
+   inner struct. That half of the comment is TRUE — which is what makes the `hostRestoreTest` half
+   (R-262) a real finding rather than a sweeping accusation.
+4. **`GetHostOOBStates` has no caller (a C6 instance).** **DISPROVED** — `monitor/host_oob.go:40,77`.
+   My own grep excluded it.
+5. **`Validation.TableCount` reports 0 tables over a validation that could not run (a C4 instance).**
+   **DISPROVED.** `backups_apps.html:74-82` is correctly three-stated: `Valid` → the count,
+   `Error` → *„Hiba"*, neither → *„Az érvényesítés nem futott le"*. A good example of the class handled
+   well.
+6. **The controller leaks a NAS password into a response body (a C1 instance).** **DISPROVED.**
+   `netstorage_handlers.go:163` puts it in a **request to the agent**, documented in place as never
+   persisted and never in the job status.
+7. **`OffboxOrphanedRenamedTo` being callerless means R-228 regressed.** **DISPROVED** — the card reads
+   the settings field directly (`backups_remote.html:80`). R-228 is genuinely closed.
+
+---
+
+## 7. What was SAMPLED rather than swept, exactly
+
+| class | swept completely | sampled | NOT examined |
+|---|---|---|---|
+| C1 | all 36 templates (shipped gate); 27 Go-side candidate sites | — | the 23 pages with no runtime body assertion |
+| C2 | — | 3 files / 19 refusals on the recovery-restore-offbox surface | **~202 of 221 refusal strings**; all refusals composed in HTML |
+| C3 | **yes — all 9 success-status sites in the controller** | — | the hub and the agent entirely; boolean/enum verdicts |
+| C4 | the 36 controller templates' rendered figures | — | the hub operator UI |
+| C5 | **yes — all 4 wire directions, 465 emitted tags** | — | 29 generically-named tags, excluded by name |
+| C6 | all 3 binaries via `deadcode`; 1323 exported methods textually | 31 of 137 candidates triaged by hand | the 106 candidates whose doc comment claims no consumer |
+| C7 | — | **60 of 2652** production invariant comments ("is the only" only) | **~2592 production + all 1440 test comments** |
+
+---
+
+## 8. R-242's untouched half — what would catch a skipped vouch earliest
+
+**Recorded, not built.** This bake demonstrated the gap rather than arguing it:
+`golden_currency_gate.py` **flipped from red to green the moment the evidence DIRECTORY existed** —
+before the round-trip download had finished, and with no vouch anywhere near it. Its positive signal
+is "a directory named after the version is present in the repo".
+
+**Earliest catch, in order of how early it fires:**
+
+1. **Earliest and cheapest — make the vouch the thing that writes the evidence.** The gate cannot read
+   the hub (its docstring records why: a network-reading gate is not `--fast`, so it would run in
+   neither the pre-push hook nor CI). But the *bake session* can: after the operator saves, re-read
+   `/configuration` and write the observed `golden_version` into the evidence README as a machine-
+   readable line. The gate then requires that line, not merely the directory. It still cannot detect a
+   lie, but it detects the **forgetting**, which is the actual failure mode the gate was built for.
+2. **Loudest — a hub-side check, not a repo-side one.** The hub already knows both numbers: the
+   vouched `golden_version` and the newest controller the fleet reports. A daily monitor raising
+   `golden_behind_release` would catch a skipped vouch **and** a vouch that silently rolled back, which
+   nothing in git can ever see. It fires within a day rather than at the next push.
+3. **Weakest — a checklist item.** R-242 already was a rule without a mechanism, and it recurred the
+   next day. Recording it again is not a fix.
+
+**Recommendation: (1) now, (2) when the hub is next touched.** (1) closes the recurrence that has cost
+two releases in two days; (2) closes the class.
+
+---
+
+## 9. Register rows opened, grouped by class
+
+Highest ID **moved: R-255 → R-263.**
+
+| class | rows |
+|---|---|
+| C1 | *none — no new instance* |
+| C2 | **R-256**, **R-257** |
+| C3 | **R-258** |
+| C4 | **R-259** |
+| C5 | **R-260** |
+| C6 | **R-261** |
+| C7 | **R-262**, **R-263** |
+
+Gating candidates from Part 4 are items in `backlog/ROADMAP.md`, not register rows.
+
+---
+
+## 10. What did not run, and why
+
+- **The vouch.** Deliberate — §3 of the task halts for it, and the campaign does not depend on it.
+- **Any fix.** Deliberate — §0 forbids it; a campaign that fixes as it goes measures a moving target.
+- **C7 exhaustively.** Not possible in one session: 4092 comments. Sampled and declared.
+- **C2 exhaustively.** 221 refusals; 19 read. Sampled and declared.
+- **C3/C4 on the hub and agent.** Only the controller was swept. Not attempted, not a claim.
+- **The tests' invariant claims (C7's second half).** 1440 test comments; none examined. The task asked
+  for this explicitly and it is **owed**, not done.
+- **Live validation of any finding.** Every finding in this report is from source reading. **None was
+  reproduced on a live box** — deliberately, since §6 rule 2 permits no machine beyond the bake VM.
+  R-258 and R-259 are the two most worth confirming live before they are fixed.
+
+---
+
+## 11. Observations — noticed and NOT acted on
+
+1. **The `felhom-golden` package list holds 14 goldens** back to 0.136.0, none ever pruned. Not a
+   problem today (a rollback needs the old package to exist), but nothing decides when one may go.
+2. **The hub's `host-report.golden.json` fixture contains `cpu_temp_c` and `loadavg`**, which no hub
+   struct decodes. A fixture carrying keys the receiver cannot read is a quiet way for a "contract
+   test" to look broader than it is — the same shape as R-262, one level down.
+3. **`readDiskUsage` (R-259's site) is one of several collectors that return silently on error**,
+   leaving the caller's zero value. The class may be wider than the one rendered figure this campaign
+   measured; only the dashboard's system-disk meter was traced to a customer-visible surface.
+4. **The re-enroll response echoes `new_api_key` back to the caller that sent it**
+   (`api/dr.go:148`). Not a leak — the box already holds it — but it puts a live credential in any
+   transcript of that response, and the endpoint is one an operator drives by hand.
+5. **The hub operator UI renders `RetrievalPassword` into page data** (`web/configs.go:672`, `:1262`).
+   Outside C1 as defined (operator-only, not a customer-fetchable page), so not filed — but it is the
+   R-249 shape on the other surface, and the operator UI has no equivalent of the controller's gate.
+6. **This session did not run inside `tmux`**, contrary to the workspace `CLAUDE.md`.

documentation/audits/DIAG-smart-passed-trap-2026-08-14.md

@@ -0,0 +1,196 @@
+# DIAG — the SMART `PASSED` trap, and the disk alert that reached nobody
+
+**Date:** 2026-08-14
+**Drive:** Seagate `ST3000VX010-2E3166`, S/N `Z6A07P2G`, 3.0 TB, `/dev/sdg` on **DooPlex**
+**Fixtures:** `fixtures/smart-ST3000VX010-failing-2026-08-14.json` (raw `smartctl -a -j /dev/sdg`),
+`fixtures/smartd-history-sdg-2026-08-14.txt` (406 `smartd` journal lines for this device, 11–14 Aug)
+**Status:** the three controller defects named here are FIXED in controller **v0.215.0**; the
+counterfactual in §5 is derived from source, **not** reproduced live.
+
+This is the project's first genuinely failing disk. Before it, the capability map recorded the
+disk-failure scenario as *"Healthy path only — a genuinely failing disk has never been seen."*
+
+---
+
+## 1. What happened
+
+On **11 August 12:28** a 3 TB drive in DooPlex reported its first unreadable sectors. By **13 August
+21:58** it was at 360, and it was taking down a running service. Throughout the entire episode the
+drive's own overall self-assessment read **`PASSED`**, and it still does.
+
+`smartd` was running the whole time and mailed **local root** — a mailbox nobody reads. The failure
+was actually found by a crashlooping pod, not by any alert.
+
+---
+
+## 2. The mechanism — `smart_status.passed` cannot fail on unreadable sectors
+
+Measured, from the committed fixture:
+
+| ID  | Attribute                | value | worst | thresh | raw    |
+|-----|--------------------------|-------|-------|--------|--------|
+| 5   | `Reallocated_Sector_Ct`  | 100   | 100   | **10** | 0      |
+| 187 | `Reported_Uncorrect`     | **1** | **1** | **0**  | **1001** |
+| 188 | `Command_Timeout`        | 100   | 100   | **0**  | 0      |
+| 197 | `Current_Pending_Sector` | 98    | 98    | **0**  | **352** |
+| 198 | `Offline_Uncorrectable`  | 98    | 98    | **0**  | **352** |
+| 199 | `UDMA_CRC_Error_Count`   | 200   | 200   | **0**  | 0      |
+
+`smart_status.passed` is false only when some attribute's **normalized value** falls **at or below**
+its **threshold**. Attributes 187, 197 and 198 — the three that record unreadable sectors — all carry
+`thresh: 0`. A normalized SMART value floors at 1 and cannot reach 0.
+
+> **Therefore `smart_status.passed` is structurally incapable of failing on unreadable sectors.**
+> This is not a quirk of this drive or this vendor. It is how a zero threshold behaves.
+
+Attribute **187 `Reported_Uncorrect` sits at normalized `1` against threshold `0`** with a raw count
+of **1001**. It is one point from failing and has no remaining point to give.
+
+Corroborating, from the same fixture: `ata_smart_error_log.summary.count = 1001`, power-on hours
+**60505** (~6.9 years), `smartctl` exit status **64** (bit 6 — *the device error log contains
+records of errors*) while `smart_status.passed` is still `true`.
+
+**Any monitor built on the drive's overall verdict is blind to this entire class of failure.**
+Felhom already knows better — `agentapi.DiskVerdictFor` reads the raw counters — which is why it
+would have noticed on 11 August, two days early.
+
+---
+
+## 3. Unreadable sectors are not monotonic
+
+From `smartd-history-sdg-2026-08-14.txt`, `Current_Pending_Sector` over the episode (30-minute
+sampling, host clock = CEST):
+
+```
+Aug 11 12:28   8      first sighting
+Aug 11 12:58  16      (+8)
+Aug 11 13:28   0      FULL CLEAR — "No more Currently unreadable (pending) sectors,
+                       warning condition reset after 1 email"
+Aug 11 20:28   8      returns
+Aug 12 01:28  16  →  01:58   8  (-8)
+Aug 12 02:28  32  →  02:58  24  (-8)
+Aug 12 03:28  24      187 Reported_Uncorrect 100→97; ATA error count 0→3
+Aug 12 03:58  16  (-8)  →  04:28  24  (+8)
+Aug 12 10:58  32      … steady 32 for ~11h …
+Aug 12 21:58  24  (-8)
+Aug 13 03:28  40  (+16)  →  04:28  24  (-16)
+Aug 13 11:28  64      terminal run begins — never returns below 64
+Aug 13 11:58  72   12:58  80   13:28 112   15:58 120
+Aug 13 21:58 360      (+240)
+Aug 13 22:28 352  (-8)   … steady 352 through 14 Aug …
+```
+
+Two measured facts carry design weight:
+
+1. **The 11 August excursion cleared completely within one hour** (12:28 → 13:28). A bare `> 0`
+   alarm would have fired on a drive that then looked fine for seven hours. This is why the ladder
+   uses a *sustain* rule rather than a bare non-zero test.
+2. **The benign excursion peaked at 16; the terminal run crossed 64 at 13 Aug 11:28 and never came
+   back.** That is the entire empirical basis for the static count threshold of 64 — see §6.
+
+---
+
+## 4. The three controller defects
+
+All three are in `felhom-controller` at `3e3ee94` (v0.214.0), the tree audited here.
+
+### D1 — the alert carries a severity the hub does not recognise *(highest value)*
+
+`internal/notify/notifier.go:565` — `NotifyDiskHealthDegraded` sets:
+
+```go
+severity := "warn"
+```
+
+The hub accepts an exact-match lowercase vocabulary and **coerces anything else to `info`**:
+
+- `felhom.eu/hub/internal/api/handler.go:2121-2126` — `case "info", "warning", "error", "critical":`
+  … `default: payload.Severity = "info"`
+- `felhom.eu/hub/internal/notify/dispatcher.go:89-96` — `severityNotifies` returns true only for
+  `warning` / `error` / `critical`.
+
+`"warn"` is not in the accepted set. So the Figyelmeztetés-level disk alert is **stored as an
+informational notice and emailed to nobody**, on the customer leg and the operator leg alike.
+
+The function's own doc comment reads *"The hub applies its own per-event-type cooldown"* — which
+presumes it routes. An invariant asserted in a comment with no test pinning it; this project's
+recurring shape.
+
+### D2 — no level above "worth keeping an eye on it"
+
+`internal/agentapi/diskverdict.go:28-41` returns `Warn` for *any* non-zero counter, and can only
+reach `Fail` when `Health == "FAILING"` — which, by §2, this fault class cannot produce. A drive with
+one aging sector and a drive at 352 unreadable sectors rendered the identical chip and the identical
+mild sentence.
+
+### D3 — it speaks once, and forgets on restart
+
+`internal/web/disk_health.go:182` emits only on `v > prev`, against a **in-memory** baseline
+(`disk_health.go:26-29`, *"Lost on restart → the next check re-baselines silently"*). Consequences:
+
+- Between 8 and 352 pending sectors the verdict never changes level, so **nothing further is emitted**.
+- A controller restart while a disk is already bad re-baselines it silently — that disk never alerts
+  again.
+
+---
+
+## 5. Counterfactual — what a customer would have received
+
+**Derived from the source above plus the §3 timeline. NOT reproduced live.**
+
+| Date/time | Drive state | Felhom verdict at v0.214.0 | Emitted | Delivered |
+|-----------|-------------|-----------------------------|---------|-----------|
+| 11 Aug 12:28 | pending 8 | OK → Figyelmeztetés | `disk_health_degraded`, severity `warn` | **nothing** — coerced to `info`, dropped by `severityNotifies` |
+| 11 Aug 13:28 | pending 0 | Figyelmeztetés → Rendben | none (recovery is silent) | nothing |
+| 11 Aug 20:28 → 13 Aug | 8 → 352 | Figyelmeztetés throughout | none (no level change) | nothing |
+| 13 Aug 21:58 | pending 360 | Figyelmeztetés | none | nothing |
+
+> **Felhom would have emitted zero emails about this drive.** The one event it did produce was filed
+> at `info` and delivered to no one.
+
+Note the two defects compound: even had D1 been fixed alone, the customer would have received a
+single mild "Javasolt figyelemmel kísérni" at 8 sectors on 11 August and then silence through 352.
+
+---
+
+## 6. Provenance of the thresholds chosen in v0.215.0
+
+- **64 unreadable sectors → Hiba.** The observed benign excursion peaked at **16** and cleared inside
+  an hour; the terminal run passed **64** at 13 Aug 11:28 and never returned below it. 64 sits above
+  the one observed transient and below the observed terminal run. **This is a judgement from ONE
+  drive.** It is a static backstop and is expected to be replaced in Phase 3 by growth-rate detection
+  over real history.
+- **Sustain before count.** The primary rule is "unreadable sectors still present at the next check";
+  the count is the backstop. On this drive sustain fires **12 Aug**, the count not until **13 Aug** —
+  a full day earlier. The backstop exists for a box that was powered off or restarted across the
+  sustain window.
+- **55 / 60 °C.** Adopted unchanged from the operator's existing Prometheus bands on DooPlex, so the
+  two systems cannot disagree about the same drive.
+
+---
+
+## 7. Measured vs inferred
+
+**Measured** (reproducible from the committed fixtures):
+- The attribute table, thresholds and raw values in §2; `passed: true` at 352 pending sectors.
+- The full non-monotonic timeline in §3, including the one-hour full clear.
+- The three defect locators in §4 — read from live source on both the controller and the hub side.
+
+**Inferred** (source-derived, not executed):
+- The §5 counterfactual. It follows from the §4 locators and the §3 timeline; **no email path was
+  exercised against this drive**, and no `disk_health_degraded` event for it exists in the hub.
+
+**Not covered here:**
+- Attributes **187**, **199** and **188** are not on the agent→controller wire today. Adding them is
+  Phase 2 (a declared wire change, so the hub models them in the same session under G-1). Everything
+  the v0.215.0 fix needs was already on the wire.
+- The new Fail-from-counters path has **not** fired on real hardware — only against this fixture's
+  values in unit tests.
+
+---
+
+## 8. One layer out
+
+`smartd` on DooPlex did its job and mailed local root, where nothing reads. That is the same shape
+as D1 — a correct detection with a delivery path to nowhere — one layer outside the product. Tracked
+separately as DooPlex hygiene.

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase0-preexisting-scratch/offsite-restore-scratch.listing.txt

@@ -0,0 +1,42 @@
+drwxr-xr-x root/root         0 2026-08-21 18:33 offsite-restore/
+drwxr-xr-x root/root         0 2026-08-21 18:33 offsite-restore/opengist/
+drwxr-xr-x root/root         0 2026-08-03 08:11 offsite-restore/opengist/mnt/
+drwxr-xr-x root/root         0 2026-08-04 14:51 offsite-restore/opengist/mnt/sys_drive/
+drwxr-xr-x root/root         0 2026-08-03 08:29 offsite-restore/opengist/mnt/sys_drive/felhom-data/
+drwxr-xr-x root/root         0 2026-08-04 23:13 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/
+drwxr-xr-x root/root         0 2026-08-06 22:02 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/
+drwxr-xr-x root/root         0 2026-08-09 10:30 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/
+drwxr-xr-x root/root         0 2026-08-09 10:30 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/compose/
+-rw-r--r-- root/root      1750 2026-08-09 10:30 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/compose/.felhom.yml
+-rw-r--r-- root/root      1260 2026-08-09 10:30 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/compose/docker-compose.yml
+-rw------- root/root       287 2026-08-09 10:30 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/compose/app.yaml
+drwxr-xr-x root/root         0 2026-08-09 10:30 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/volume-dumps/
+-rw-r--r-- root/root    182272 2026-08-09 10:30 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/volume-dumps/opengist_opengist_data.tar
+-rw-r--r-- root/root      1121 2026-08-09 10:30 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/manifest.json
+drwxr-xr-x root/root         0 2026-08-21 18:30 offsite-restore/calibre-web/
+drwxr-xr-x root/root         0 2026-08-03 08:11 offsite-restore/calibre-web/mnt/
+drwxr-xr-x root/root         0 2026-08-04 14:51 offsite-restore/calibre-web/mnt/sys_drive/
+drwxr-xr-x root/root         0 2026-08-03 08:29 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/
+drwxrwsr-x root/1000         0 2026-08-04 18:45 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/
+drwxr-sr-x root/1000         0 2026-08-04 18:50 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/
+drwxrwsr-x 1000/1000         0 2026-08-09 10:15 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/
+-rw-r--r-- 1000/1000       181 2026-08-04 14:53 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/DRILL-SENTINEL.txt
+drwxrwxr-x 1000/1000         0 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/
+-rw-rw-r-- 1000/1000        21 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/plain.txt
+-rw-rw-r-- 1000/1000   3145728 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/binary-3mb.bin
+drwxrwxr-x 1000/1000         0 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/nested/
+-rw-rw-r-- 1000/1000        25 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/nested/\305\221szibarack.md
+-rw-rw-r-- 1000/1000        59 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/\303\241rv\303\255zt\305\261r\305\221-t\303\274k\303\266rf\303\272r\303\263g\303\251p.txt
+-rw-r--r-- 1000/1000     32768 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/metadata.db-shm
+-rw-r--r-- 1000/1000         0 2026-08-09 04:15 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/metadata.db-wal
+-rw-r--r-- 1000/1000    413696 2026-08-04 14:52 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/metadata.db
+drwxr-xr-x root/root         0 2026-08-04 23:13 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/
+drwxr-xr-x root/root         0 2026-08-06 22:02 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/
+drwxr-xr-x root/root         0 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/
+drwxr-xr-x root/root         0 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/compose/
+-rw-r--r-- root/root      3035 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/compose/.felhom.yml
+-rw-r--r-- root/root      2122 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/compose/docker-compose.yml
+-rw------- root/root       317 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/compose/app.yaml
+drwxr-xr-x root/root         0 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/volume-dumps/
+-rw-r--r-- root/root    368640 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/volume-dumps/calibre-web_calibre_web_config.tar
+-rw-r--r-- root/root      1157 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/manifest.json

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase0-preexisting-scratch/offsite-restore-scratch.sha256

@@ -0,0 +1 @@
+c9498bfba3dab7b8c59196be8a6c792f0044356d969b2d81ce4b00b61950aa96  documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase0-preexisting-scratch/offsite-restore-scratch.tar

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase3-experiment/RESULT-MATRIX.txt

@@ -0,0 +1,22 @@
+DRILL 2026-08-21 — FULL/EMPTY contrast on demo-hp. All hashes sha256, byte-for-byte.
+Comparator positive control: one byte flipped at offset 500000 of binary-1mb.bin
+(af -> 00) => sha256sum -c FAILED rc=1; original PASSED rc=0. Mutant discarded.
+
+Planted fixture (5 files, incl. two UTF-8 Hungarian accented names):
+  SENTINEL.txt                    0c23c8531214fe20cbc1ed177da22f51d65570c5aaedb39e380aa8d4d3e62991
+  binary-1mb.bin                  725763bbe679b22d5c231a14083ff13155f475c028c22ade4623955b50a2a84a
+  nested/őszibarack.md            a39ad6f623da67ac72f2e62a24245eef46c722c279ae89cd6b0c7c45afa6a4c4
+  plain.txt                       07e91a985809fc96752f97cddcf6523b211bc607c81a5808befabe35573926f1
+  árvíztűrő-tükörfúrógép.txt      0d6a22ec56acf61b8a80e73eb12cb223d607acaa3684acfcfa7c3e34ecdfabea
+Name bytes (UTF-8 NFC):
+  árvíztűrő-tükörfúrógép.txt = c3a1 72 76 c3ad 7a 74 c5b1 72 c591 2d 74 c3bc 6b c3b6 72 66 c3ba 72 c3b3 67 c3a9 70 2e747874
+  őszibarack.md              = c591 73 7a 69 62 61 72 61 63 6b 2e 6d 64
+
+                     | class      | data leg          | in unit | in offsite snap | checking folder | OFF-SITE restore | LOCAL restore
+ calibre-web  FULL   | drive      | userdata files    |   n/a   | YES 5/5 ident.  | YES 5/5 ident.  | YES 5/5 ident.   | -
+ calibre-web  FULL   | drive      | named volume      | YES 1.42MB | YES          | YES             | NO  (silent)     | -
+ privatebin   FULL   | no-drive   | named volume      | YES 1.06MB | YES 5/5 ident.| YES 5/5 ident.  | REFUSED (false)  | YES 5/5 ident.
+ opengist     EMPTY  | no-drive   | named volume      | YES 181KB skeleton | YES  | YES             | REFUSED (false)  | -
+
+CONCLUSION: the unit and the off-site snapshot HOLD the data, verified by identity.
+The off-site full restore has no named-volume leg at all; the local restore has one.

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase3-experiment/checking-folders-after-full-restore.listing.txt

@@ -0,0 +1,88 @@
+drwxr-xr-x root/root         0 2026-08-21 22:19 offsite-restore/
+drwxr-xr-x root/root         0 2026-08-21 18:33 offsite-restore/opengist/
+drwxr-xr-x root/root         0 2026-08-21 18:00 offsite-restore/opengist/mnt/
+drwxr-xr-x root/root         0 2026-08-21 18:01 offsite-restore/opengist/mnt/sys_drive/
+drwxr-xr-x root/root         0 2026-08-21 18:31 offsite-restore/opengist/mnt/sys_drive/felhom-data/
+drwxr-xr-x root/root         0 2026-08-21 18:31 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/
+drwxr-xr-x root/root         0 2026-08-21 18:31 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/
+drwxr-xr-x root/root         0 2026-08-21 22:17 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/
+drwxr-xr-x root/root         0 2026-08-21 22:17 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/compose/
+-rw-r--r-- root/root      1750 2026-08-21 22:17 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/compose/.felhom.yml
+-rw-r--r-- root/root      1260 2026-08-21 22:17 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/compose/docker-compose.yml
+-rw------- root/root       287 2026-08-21 22:17 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/compose/app.yaml
+drwxr-xr-x root/root         0 2026-08-21 22:16 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/volume-dumps/
+-rw-r--r-- root/root    181248 2026-08-21 22:16 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/volume-dumps/opengist_opengist_data.tar
+-rw-r--r-- root/root      1121 2026-08-21 22:17 offsite-restore/opengist/mnt/sys_drive/felhom-data/backups/primary/opengist/manifest.json
+drwxr-xr-x root/root         0 2026-08-21 22:19 offsite-restore/privatebin/
+drwxr-xr-x root/root         0 2026-08-21 18:00 offsite-restore/privatebin/mnt/
+drwxr-xr-x root/root         0 2026-08-21 18:01 offsite-restore/privatebin/mnt/sys_drive/
+drwxr-xr-x root/root         0 2026-08-21 18:31 offsite-restore/privatebin/mnt/sys_drive/felhom-data/
+drwxr-xr-x root/root         0 2026-08-21 18:31 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/
+drwxr-xr-x root/root         0 2026-08-21 18:31 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/primary/
+drwxr-xr-x root/root         0 2026-08-21 22:17 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/primary/privatebin/
+drwxr-xr-x root/root         0 2026-08-21 22:17 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/primary/privatebin/compose/
+-rw-r--r-- root/root      1723 2026-08-21 22:17 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/primary/privatebin/compose/.felhom.yml
+-rw-r--r-- root/root      1223 2026-08-21 22:17 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/primary/privatebin/compose/docker-compose.yml
+-rw------- root/root       288 2026-08-21 22:17 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/primary/privatebin/compose/app.yaml
+drwxr-xr-x root/root         0 2026-08-21 22:16 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/primary/privatebin/volume-dumps/
+-rw-r--r-- root/root   1055744 2026-08-21 22:16 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/primary/privatebin/volume-dumps/privatebin_privatebin_data.tar
+-rw-r--r-- root/root      1118 2026-08-21 22:17 offsite-restore/privatebin/mnt/sys_drive/felhom-data/backups/primary/privatebin/manifest.json
+drwxr-xr-x root/root         0 2026-08-21 18:30 offsite-restore/calibre-web/
+drwxr-xr-x root/root         0 2026-08-21 18:00 offsite-restore/calibre-web/mnt/
+drwxr-xr-x nobody/nogroup    0 2026-08-21 18:26 offsite-restore/calibre-web/mnt/felhom-drives/
+drwxr-xr-x root/root         0 2026-07-22 03:30 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/
+drwxrwsr-x root/1000         0 2026-07-21 19:08 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/
+drwxrwsr-x root/1000         0 2026-07-26 08:17 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/
+drwxrwsr-x 1000/1000         0 2026-08-21 22:10 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/
+-rw-r--r-- 1000/1000       181 2026-08-04 14:53 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/DRILL-SENTINEL.txt
+drwxrwxr-x 1000/1000         0 2026-08-21 22:09 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/DRILL-2026-08-21/
+-rw-rw-r-- 1000/1000        35 2026-08-21 22:09 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/DRILL-2026-08-21/plain.txt
+-rw-rw-r-- 1000/1000   1048576 2026-08-21 22:09 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/DRILL-2026-08-21/binary-1mb.bin
+drwxrwxr-x 1000/1000         0 2026-08-21 22:09 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/DRILL-2026-08-21/nested/
+-rw-rw-r-- 1000/1000        21 2026-08-21 22:09 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/DRILL-2026-08-21/nested/\305\221szibarack.md
+-rw-rw-r-- 1000/1000        46 2026-08-21 22:09 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/DRILL-2026-08-21/SENTINEL.txt
+-rw-rw-r-- 1000/1000        52 2026-08-21 22:09 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/DRILL-2026-08-21/\303\241rv\303\255zt\305\261r\305\221-t\303\274k\303\266rf\303\272r\303\263g\303\251p.txt
+drwxrwxr-x 1000/1000         0 2026-08-09 09:59 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/rehearsal-2026-08-09/
+-rw-rw-r-- 1000/1000        21 2026-08-09 09:59 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/rehearsal-2026-08-09/plain.txt
+-rw-rw-r-- 1000/1000   3145728 2026-08-09 09:59 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/rehearsal-2026-08-09/binary-3mb.bin
+drwxrwxr-x 1000/1000         0 2026-08-09 09:59 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/rehearsal-2026-08-09/nested/
+-rw-rw-r-- 1000/1000        25 2026-08-09 09:59 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/rehearsal-2026-08-09/nested/\305\221szibarack.md
+-rw-rw-r-- 1000/1000        59 2026-08-09 09:59 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/rehearsal-2026-08-09/\303\241rv\303\255zt\305\261r\305\221-t\303\274k\303\266rf\303\272r\303\263g\303\251p.txt
+-rw-r--r-- 1000/1000     32768 2026-08-21 22:17 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/metadata.db-shm
+-rw-r--r-- 1000/1000         0 2026-08-09 04:15 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/metadata.db-wal
+-rw-r--r-- 1000/1000    413696 2026-08-04 14:52 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/userdata/media/books/metadata.db
+drwxr-xr-x root/root         0 2026-07-23 12:10 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/
+drwxr-xr-x root/root         0 2026-08-21 18:31 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/primary/
+drwxr-xr-x root/root         0 2026-08-21 22:17 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/primary/calibre-web/
+drwxr-xr-x root/root         0 2026-08-21 22:17 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/primary/calibre-web/compose/
+-rw-r--r-- root/root      3035 2026-08-21 22:17 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/primary/calibre-web/compose/.felhom.yml
+-rw-r--r-- root/root      2122 2026-08-21 22:17 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/primary/calibre-web/compose/docker-compose.yml
+-rw------- root/root       327 2026-08-21 22:17 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/primary/calibre-web/compose/app.yaml
+drwxr-xr-x root/root         0 2026-08-21 22:16 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/primary/calibre-web/volume-dumps/
+-rw-r--r-- root/root   1422848 2026-08-21 22:16 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/primary/calibre-web/volume-dumps/calibre-web_calibre_web_config.tar
+-rw-r--r-- root/root      1165 2026-08-21 22:17 offsite-restore/calibre-web/mnt/felhom-drives/hdd_1/backups/primary/calibre-web/manifest.json
+drwxr-xr-x root/root         0 2026-08-04 14:51 offsite-restore/calibre-web/mnt/sys_drive/
+drwxr-xr-x root/root         0 2026-08-03 08:29 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/
+drwxrwsr-x root/1000         0 2026-08-04 18:45 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/
+drwxr-sr-x root/1000         0 2026-08-04 18:50 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/
+drwxrwsr-x 1000/1000         0 2026-08-09 10:15 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/
+-rw-r--r-- 1000/1000       181 2026-08-04 14:53 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/DRILL-SENTINEL.txt
+drwxrwxr-x 1000/1000         0 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/
+-rw-rw-r-- 1000/1000        21 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/plain.txt
+-rw-rw-r-- 1000/1000   3145728 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/binary-3mb.bin
+drwxrwxr-x 1000/1000         0 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/nested/
+-rw-rw-r-- 1000/1000        25 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/nested/\305\221szibarack.md
+-rw-rw-r-- 1000/1000        59 2026-08-09 09:59 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/rehearsal-2026-08-09/\303\241rv\303\255zt\305\261r\305\221-t\303\274k\303\266rf\303\272r\303\263g\303\251p.txt
+-rw-r--r-- 1000/1000     32768 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/metadata.db-shm
+-rw-r--r-- 1000/1000         0 2026-08-09 04:15 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/metadata.db-wal
+-rw-r--r-- 1000/1000    413696 2026-08-04 14:52 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/userdata/media/books/metadata.db
+drwxr-xr-x root/root         0 2026-08-04 23:13 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/
+drwxr-xr-x root/root         0 2026-08-06 22:02 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/
+drwxr-xr-x root/root         0 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/
+drwxr-xr-x root/root         0 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/compose/
+-rw-r--r-- root/root      3035 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/compose/.felhom.yml
+-rw-r--r-- root/root      2122 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/compose/docker-compose.yml
+-rw------- root/root       317 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/compose/app.yaml
+drwxr-xr-x root/root         0 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/volume-dumps/
+-rw-r--r-- root/root    368640 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/volume-dumps/calibre-web_calibre_web_config.tar
+-rw-r--r-- root/root      1157 2026-08-09 10:30 offsite-restore/calibre-web/mnt/sys_drive/felhom-data/backups/primary/calibre-web/manifest.json

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase3-experiment/checking-folders-after-full-restore.sha256

@@ -0,0 +1 @@
+7e59e57d6458d28f530dbaddbee0f2314ea1ef885052701531f57bad2529849d  documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase3-experiment/checking-folders-after-full-restore.tar

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase3-experiment/messages-verbatim.txt

@@ -0,0 +1,32 @@
+VERBATIM customer-facing outcome strings, read from /api/backup/restore-status
+(the same value the wizard banner renders). Times CEST.
+
+1) 22:21:51  off-site FULL RESTORE (reconstitute), app = privatebin  [40-class, no HDD_PATH]
+   ok = FALSE
+   "A teljes visszaállítás sikertelen: a(z) privatebin nincs telepítve, ezért nincs hová
+    visszaállítani az adatait. A mentése szerint az adatai itt voltak: /mnt/sys_drive.
+    Telepítsd újra az alkalmazást (Alkalmazások) ugyanerre a helyre, utána ez a
+    visszaállítás működni fog"
+   FACT AT THAT MOMENT: privatebin deployed=true, state=running, container healthy.
+
+2) 22:23:36  off-site FULL RESTORE (reconstitute), app = calibre-web  [drive class]
+   ok = TRUE
+   "A(z) calibre-web: 5 fájl visszaállítva (mentés: 2026-08-21 22:16) — az alkalmazás
+    újraindult. Ennek az alkalmazásnak nincs adatbázisa."
+   FACT: the 5 declared-userdata files came back byte-identical.
+         The named volume calibre-web_calibre_web_config was NOT restored, though its
+         1,422,848-byte tar was in the snapshot, in the checking folder, and named in
+         manifest.json volume_dumps. The message does not mention it.
+
+3) 22:25:31  LOCAL restore from recovery unit, app = privatebin
+   ok = TRUE
+   "privatebin visszaállítva (helyi)."
+   FACT: the named volume WAS restored, all 5 planted files byte-identical.
+         The message carries no counts at all - it reads the same whatever happened.
+
+4) 22:13:15  off-site backup run with ZERO apps selected
+   log:  "[offbox] backup run started (0 app(s) toggled)"
+         "[offbox] backup OK: 0 app(s) backed up, 18 snapshot(s), 14s"
+   card: badge "Aktív — nincs kijelölt alkalmazás" / "✓ Rendben" /
+         "Sikeres — nincs mentésre jelölt alkalmazás" /
+         "Nincs távoli mentésre jelölt alkalmazás — jelölj ki legalább egyet."

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase3-experiment/plant-manifest.txt

@@ -0,0 +1,5 @@
+0c23c8531214fe20cbc1ed177da22f51d65570c5aaedb39e380aa8d4d3e62991  DRILL-2026-08-21/SENTINEL.txt
+725763bbe679b22d5c231a14083ff13155f475c028c22ade4623955b50a2a84a  DRILL-2026-08-21/binary-1mb.bin
+a39ad6f623da67ac72f2e62a24245eef46c722c279ae89cd6b0c7c45afa6a4c4  DRILL-2026-08-21/nested/őszibarack.md
+07e91a985809fc96752f97cddcf6523b211bc607c81a5808befabe35573926f1  DRILL-2026-08-21/plain.txt
+0d6a22ec56acf61b8a80e73eb12cb223d607acaa3684acfcfa7c3e34ecdfabea  DRILL-2026-08-21/árvíztűrő-tükörfúrógép.txt

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase4-abandon/repo-inventory-before.txt

@@ -0,0 +1,59 @@
+ID        Time                 Host        Tags                         Paths
+------------------------------------------------------------------------------------------------------------------------------
+e6132ae5  2026-08-04 19:36:26  demo-hp     felhom-offbox,calibre-web    /mnt/sys_drive/felhom-data/backups/primary/calibre-web
+                                                                        /mnt/sys_drive/felhom-data/userdata/media/books
+
+9ac78c98  2026-08-04 19:36:31  demo-hp     felhom-offbox,opengist       /mnt/sys_drive/felhom-data/backups/primary/opengist
+
+92212ff8  2026-08-04 19:36:36  demo-hp     felhom-offbox,privatebin     /mnt/sys_drive/felhom-data/backups/primary/privatebin
+
+9d6d233f  2026-08-05 09:12:42  demo-hp     felhom-offbox,calibre-web    /mnt/sys_drive/felhom-data/backups/primary/calibre-web
+                                                                        /mnt/sys_drive/felhom-data/userdata/media/books
+
+29e7b245  2026-08-05 09:12:48  demo-hp     felhom-offbox,opengist       /mnt/sys_drive/felhom-data/backups/primary/opengist
+
+cd1db049  2026-08-05 09:12:53  demo-hp     felhom-offbox,privatebin     /mnt/sys_drive/felhom-data/backups/primary/privatebin
+
+0ef7a006  2026-08-06 20:00:44  demo-hp     felhom-offbox,calibre-web    /mnt/sys_drive/felhom-data/backups/primary/calibre-web
+                                                                        /mnt/sys_drive/felhom-data/userdata/media/books
+
+8662a8c1  2026-08-06 20:00:50  demo-hp     felhom-offbox,opengist       /mnt/sys_drive/felhom-data/backups/primary/opengist
+
+6dfa6602  2026-08-06 20:00:54  demo-hp     felhom-offbox,privatebin     /mnt/sys_drive/felhom-data/backups/primary/privatebin
+
+3635f945  2026-08-07 02:15:13  demo-hp     felhom-offbox,calibre-web    /mnt/sys_drive/felhom-data/backups/primary/calibre-web
+                                                                        /mnt/sys_drive/felhom-data/userdata/media/books
+
+7b1fa8b0  2026-08-07 02:15:17  demo-hp     felhom-offbox,opengist       /mnt/sys_drive/felhom-data/backups/primary/opengist
+
+38edf5b8  2026-08-07 02:15:21  demo-hp     felhom-offbox,privatebin     /mnt/sys_drive/felhom-data/backups/primary/privatebin
+
+a4d03ee3  2026-08-08 02:15:12  demo-hp     felhom-offbox,calibre-web    /mnt/sys_drive/felhom-data/backups/primary/calibre-web
+                                                                        /mnt/sys_drive/felhom-data/userdata/media/books
+
+f534bffe  2026-08-08 02:15:17  demo-hp     felhom-offbox,opengist       /mnt/sys_drive/felhom-data/backups/primary/opengist
+
+a685d30e  2026-08-08 02:15:22  demo-hp     felhom-offbox,privatebin     /mnt/sys_drive/felhom-data/backups/primary/privatebin
+
+41c830db  2026-08-09 08:30:38  demo-hp     felhom-offbox,calibre-web    /mnt/sys_drive/felhom-data/backups/primary/calibre-web
+                                                                        /mnt/sys_drive/felhom-data/userdata/media/books
+
+9e38b84c  2026-08-09 08:30:49  demo-hp     felhom-offbox,opengist       /mnt/sys_drive/felhom-data/backups/primary/opengist
+
+78b93f04  2026-08-09 08:30:53  demo-hp     felhom-offbox,privatebin     /mnt/sys_drive/felhom-data/backups/primary/privatebin
+
+8c44bd4c  2026-08-21 21:00:52  demo-hp     felhom-offbox,calibre-web    /mnt/felhom-drives/hdd_1/backups/primary/calibre-web
+                                                                        /mnt/felhom-drives/hdd_1/userdata/media/books
+
+07bac5ad  2026-08-21 21:00:55  demo-hp     felhom-offbox,privatebin     /mnt/sys_drive/felhom-data/backups/primary/privatebin
+
+7e4b703b  2026-08-21 21:00:58  demo-hp     felhom-offbox,kimai          /mnt/sys_drive/felhom-data/backups/primary/kimai
+
+16cb8ce7  2026-08-21 21:01:08  demo-hp     felhom-offbox,paperless-ngx  /mnt/felhom-drives/hdd_1/appdata/paperless/media
+                                                                        /mnt/felhom-drives/hdd_1/backups/primary/paperless-ngx
+
+2a891149  2026-08-21 21:01:13  demo-hp     felhom-offbox,romm           /mnt/felhom-drives/hdd_1/backups/primary/romm
+
+49b9f317  2026-08-21 21:01:22  demo-hp     felhom-offbox,opengist       /mnt/sys_drive/felhom-data/backups/primary/opengist
+------------------------------------------------------------------------------------------------------------------------------
+24 snapshots

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase4-abandon/sweep-result.txt

@@ -0,0 +1,23 @@
+PART 4.2 — the abandonment sweep, watched firing. 2026-08-22.
+
+State created 2026-08-21 23:08-23:09 CEST:
+  set-aside store  u629488-sub3:/home/felhom-repo-superseded-drill-20260821  (config/data/index/snapshots)
+  countdown        started 2026-08-07, due 2026-08-20  (written into settings.json, controller restarted)
+  product CLI      "abandonment countdown RUNNING … deleted on: 2026-08-20 … days left: 0"
+
+05:10 CEST — the daily `offsite-abandon-sweep` job fired.
+  /home on the storage box now stamped 03:10Z
+  /home/felhom-repo-superseded-drill-20260821   -> GONE
+  /home/felhom-repo  (the LIVE repository)      -> present, mtime still Aug 4  ** survived **
+
+05:13 CEST — the hub half. Event 3025 `offsite_abandon_purged`:
+  "Az ügyfél korábbi távoli mentései és a hozzájuk tartozó megőrzött helyreállítási csomag is
+   törölve (1 csomag). Az ügyfél döntése alapján, a 14 napos türelmi idő lejárta után."
+  demo-hp's row in host_escrow_superseded: REMOVED (there was exactly one).
+  demo-felhom's rows 4, 11, 12: ALL PRESENT — the protected fixtures were not touched.
+
+Controller closed itself out: every abandon_* field removed from settings.json;
+`--abandon-status` reports "no abandonment countdown is running on this box".
+
+VERDICT: the two-phase commit's promise — "it removes BOTH halves or neither" — is confirmed
+live for the first time. It removed exactly the recorded set-aside path and nothing else.

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase4-paperless/FINDING.txt

@@ -0,0 +1,34 @@
+paperless-ngx: the database is dumped into a directory for a stack that does not exist,
+so the recovery unit never contains it, and the restore then tells the customer the app
+has no database. Proven live 2026-08-21 22:39-22:45 CEST on demo-hp.
+
+MECHANISM (source):
+  internal/appbackup/dbdump.go:770 deriveStackName("paperless-postgres", known)
+    1. candidate = suffixStripStackName("paperless-postgres") = "paperless"   (line 801)
+    2. known is non-empty, known["paperless"] is FALSE   (the stack is "paperless-ngx")
+    3. known["paperless-postgres"] is FALSE
+    4. no known stack name is a prefix of "paperless-postgres"  ("paperless-ngx" is not)
+    5. FALLS THROUGH to `return candidate`  (line 797) -> "paperless"
+  An unresolved mapping is returned as if resolved. There is no warning and no refusal.
+
+OBSERVED CONSEQUENCES (all live):
+  a) the dump is written to
+       /mnt/sys_drive/felhom-data/backups/primary/paperless/db-dumps/paperless-postgres.sql
+     284,617 bytes, 72 tables, valid=true  -- an orphan directory for a non-existent stack,
+     on the SYSTEM drive, while the app's real unit is on /mnt/felhom-drives/hdd_1.
+  b) the real unit /mnt/felhom-drives/hdd_1/backups/primary/paperless-ngx/manifest.json
+     records  "db_dumps": null
+  c) the off-site snapshot therefore carries no .sql at all
+     (checking folder: `find ... -name "*.sql" | wc -l` = 0)
+  d) writeSafetyDump (offbox_reconstitute.go:115) filters discovered DBs on
+     db.StackName == stackName, so `mine` is empty -> returns ("", nil) -> hasDB = false.
+     NO pre-restore safety dump is taken.  Verified: `find /mnt -name "pre-restore-*"`
+     returned nothing before AND after the destructive restore.
+  e) the destructive restore ran to completion and reported SUCCESS:
+       "A(z) paperless-ngx: 0 fájl visszaállítva (mentés: 2026-08-21 22:41)
+        — az alkalmazás újraindult. Ennek az alkalmazásnak nincs adatbázisa."
+     The controller had dumped that same database 5 minutes earlier.
+
+The orphan directory is also invisible to the app's off-site push, because the push
+resolves paths from the app's own unit path -- so the only copy of that database dump
+is on the system drive of the machine it protects.

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase4-paperless/discovery-log.txt

@@ -0,0 +1,9 @@
+{"timestamp":"2026-08-21T20:38:46Z","level":"DEBUG","message":"DiscoverDatabases: paperless-postgres → stack=paperless, dbUser=paperless, dbName=paperless","source":"dbdump.go:150"}
+{"timestamp":"2026-08-21T20:39:37Z","level":"DEBUG","message":"DiscoverDatabases: paperless-postgres → stack=paperless, dbUser=paperless, dbName=paperless","source":"dbdump.go:150"}
+{"timestamp":"2026-08-21T20:39:37Z","level":"DEBUG","message":"DumpOne: starting dump for container=paperless-postgres, stack=paperless, dbType=postgres, dumpDir=/mnt/sys_drive/felhom-data/backups/primary/paperless/db-dumps","source":"dbdump.go:189"}
+{"timestamp":"2026-08-21T20:39:37Z","level":"DEBUG","message":"DumpOne: completed paperless-postgres → paperless-postgres.sql (size=277.9 KB, valid=true, tables=72, duration=313ms)","source":"dbdump.go:330"}
+{"timestamp":"2026-08-21T20:41:23Z","level":"DEBUG","message":"DiscoverDatabases: paperless-postgres → stack=paperless, dbUser=paperless, dbName=paperless","source":"dbdump.go:150"}
+{"timestamp":"2026-08-21T20:41:23Z","level":"DEBUG","message":"DumpOne: starting dump for container=paperless-postgres, stack=paperless, dbType=postgres, dumpDir=/mnt/sys_drive/felhom-data/backups/primary/paperless/db-dumps","source":"dbdump.go:189"}
+{"timestamp":"2026-08-21T20:41:23Z","level":"DEBUG","message":"DumpOne: completed paperless-postgres → paperless-postgres.sql (size=278.2 KB, valid=true, tables=72, duration=314ms)","source":"dbdump.go:330"}
+{"timestamp":"2026-08-21T20:43:46Z","level":"DEBUG","message":"DiscoverDatabases: paperless-postgres → stack=paperless, dbUser=paperless, dbName=paperless","source":"dbdump.go:150"}
+{"timestamp":"2026-08-21T20:44:33Z","level":"DEBUG","message":"DiscoverDatabases: paperless-postgres → stack=paperless, dbUser=paperless, dbName=paperless","source":"dbdump.go:150"}

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase4-paperless/orphan-dump-and-manifest.txt

@@ -0,0 +1,48 @@
+total 288
+drwxr-xr-x 2 root root   4096 Aug 21 20:41 .
+drwxr-xr-x 3 root root   4096 Aug 21 20:39 ..
+-rw-r--r-- 1 root root 284902 Aug 21 20:41 paperless-postgres.sql
+--- real unit:
+{
+  "schema_version": 2,
+  "app_name": "paperless-ngx",
+  "display_name": "Paperless-ngx",
+  "controller_version": "0.217.0",
+  "created_at": "2026-08-21T20:42:01Z",
+  "drive": "/mnt/felhom-drives/hdd_1",
+  "namespace_root": "/mnt/felhom-drives/hdd_1",
+  "image_pins": [
+    "ghcr.io/paperless-ngx/paperless-ngx:2.20.15",
+    "postgres:16-alpine",
+    "redis:7-alpine"
+  ],
+  "secret_env_vars": [
+    "DB_PASSWORD",
+    "PAPERLESS_SECRET_KEY",
+    "PAPERLESS_ADMIN_PASSWORD"
+  ],
+  "data_key_env_vars": null,
+  "secret_source": "portable secrets (data keys, DB passwords, internal signing secrets) are IN this unit's compose/app.yaml (0600); internet-reachable admin logins are NOT, and come from the guest's app.yaml or are regenerated on restore",
+  "config_files": [
+    "docker-compose.yml",
+    ".felhom.yml",
+    "app.yaml"
+  ],
+  "db_dumps": null,
+  "volume_dumps": [
+    "paperless-ngx_paperless_data.tar",
+    "paperless-ngx_paperless_postgres_data.tar",
+    "paperless-ngx_paperless_redis_data.tar"
+  ],
+  "checksums": {
+    ".felhom.yml": "a7cce0a557fd151e6385a137f4721366dd2cd0aa3876783f0f9f0acc9a78dd23",
+    "app.yaml": "8dfec452dfc00c7e3dce26864bf97165acac44f32470d2425c96e2bd86649cf0",
+    "docker-compose.yml": "b112952565ef3928f192358ea58fdf4a5a26d788593bf2614e36050c77539b3d"
+  },
+  "portable_secret_env_vars": [
+    "DB_PASSWORD",
+    "PAPERLESS_SECRET_KEY"
+  ],
+  "offsite_run_id": "20260821T204123Z",
+  "dumps_at": "2026-08-21T20:41:23Z"
+}

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase4-part4/results.txt

@@ -0,0 +1,64 @@
+PART 4 — things we claim and have never watched. demo-hp, 2026-08-21, times CEST.
+
+4.1 THE DESTRUCTIVE RESTORE
+  (a) "nothing is ever deleted"  -- PASS, both directions, calibre-web 22:26:59.
+      POST-SNAPSHOT.txt, created after the snapshot, SURVIVED the restore.
+      plain.txt, mutated after the snapshot, was OVERWRITTEN back to the snapshot's
+      content (sha 07e91a98…). Copier is rsync -a, no --delete, no --ignore-existing
+      (offbox_reconstitute.go:94).
+      NOTE ON THE COUNT: the message says "2 fájl visszaállítva" because rsync counts
+      TRANSFERS, not files restored. An identical restore reports "0 fájl visszaállítva",
+      which is indistinguishable from a restore that did nothing.
+
+  (b) "a safety dump is taken and VERIFIED before anything is stopped, and the whole
+      operation refuses if it cannot be"
+      HAPPY PATH -- PASS, romm 23:02:44.
+        21:02:47Z  "[offbox] romm: pre-restore safety dump written →
+                    pre-restore-20260821T210246Z-romm-mariadb.sql (60.8 KB)"
+        21:02:47Z  "[stacks] StopStack romm: current state=running"
+        The dump precedes the stop. Message correctly said
+        "0 fájl és az adatbázis visszaállítva".
+      THE REFUSAL -- PASS, romm 23:04:15.
+        Safety dump made impossible by putting a regular FILE at the db-dumps path.
+        Result: ok=FALSE,
+          "A teljes visszaállítás sikertelen: a biztonsági mentés könyvtára nem hozható
+           létre: mkdir /mnt/felhom-drives/hdd_1/backups/primary/romm/db-dumps:
+           not a directory"
+        Nothing changed: plain.txt kept my post-snapshot mutation (sha 3754dfc6…), and
+        romm's container StartedAt was unchanged (21:03:08) -- the app was never stopped.
+        JUDGEMENT: honest and it names the path, but it leaks a raw Go mkdir error into
+        a customer surface.
+      THE HOLE -- the guard only protects apps whose database the discovery resolves to
+        the right stack. For paperless-ngx it concludes "no database", so hasDB is false
+        and the refusal CANNOT fire: the undo is absent rather than refused. See
+        ../phase4-paperless/FINDING.txt.
+      SIDE EFFECT, NOT PREVIOUSLY FILED -- the safety dump DESTROYS the unit's own DB dump.
+        DumpOne writes the canonical `<stack>-<dbtype>.sql` (appbackup/dbdump.go:200-202),
+        i.e. the app's real dump, and only THEN is it renamed to pre-restore-*.
+        The comment at offbox_reconstitute.go:147-148 states it "can never overwrite the
+        app's real dump". It does.
+        PROVEN: romm's db-dumps held romm-mariadb.sql (62,270 B) at 22:59; after one
+        reconstitute it held ONLY pre-restore-20260821T210246Z-romm-mariadb.sql.
+        Consequence: until the next backup run the LOCAL restore-from-unit finds no .sql
+        and tells the customer the app has no database.
+
+4.3 A DAMAGED STORE  -- MIXED
+  Method: one byte flipped inside pack 967853d2… (offset 5,000,000) via the repo's own
+  SFTP transport; the pack's name is its content hash, so this is genuine corruption.
+  * `restic check` DOES detect it ("ciphertext verification failed",
+    "Fatal: repository contains errors").  BUT the controller NEVER RUNS `restic check`:
+    the only restic verbs in the whole controller are restore, snapshots, backup, unlock,
+    stats, init, forget, prune, cat. The agent's restore-test is PBS-tier only.
+    So the off-site store is never verified by any layer, at any time.
+  * A restore that TOUCHES the damage fails honestly:
+    ok=FALSE, "A visszaállítás sikertelen: offbox restore paperless-ngx: exit status 1:
+    … ignoring error for …/documents/originals/0000011.pdf: ciphertext verification failed"
+  * BUT the failure is not remembered. It left a PARTIAL scratch (78 MB, 54 files,
+    15 of 16 originals). OffboxFullScratchReady (offbox_restore.go:305) only asks
+    "does the directory exist and is it non-empty", so the wizard then offered all three
+    actions including "Teljes visszaállítás indítása".
+  * Pressing it ran the DESTRUCTIVE restore from that known-incomplete copy and reported
+    SUCCESS: ok=TRUE, "A(z) paperless-ngx: 0 fájl visszaállítva … Ennek az alkalmazásnak
+    nincs adatbázisa."
+  REPO REPAIRED afterwards from the byte-identical originals; `restic check` now says
+  "no errors were found".

documentation/audits/DRILL-backup-truth-2026-08-21/evidence/phase5-scheduled/scheduled-cycle-and-sweep.log

@@ -0,0 +1,71 @@
+[2026-08-21 23:34:08 CEST] collector v2 started (epoch waits)
+[2026-08-22 02:38:09 CEST] === after the 02:30 SCHEDULED local cycle
+[2026-08-22 02:38:09 CEST] --- units:
+## /mnt/sys_drive/felhom-data/backups/primary/kimai
+        2235  2026-08-21 21:00  compose/.felhom.yml
+         488  2026-08-21 21:00  compose/app.yaml
+        2195  2026-08-21 21:00  compose/docker-compose.yml
+       48217  2026-08-22 00:30  db-dumps/kimai-mariadb.sql
+        1275  2026-08-21 21:00  manifest.json
+   160331776  2026-08-22 00:30  volume-dumps/kimai_kimai_db_data.tar
+    52845056  2026-08-22 00:30  volume-dumps/kimai_kimai_var.tar
+## /mnt/sys_drive/felhom-data/backups/primary/opengist
+        1750  2026-08-21 21:00  compose/.felhom.yml
+         287  2026-08-21 21:00  compose/app.yaml
+        1260  2026-08-21 21:00  compose/docker-compose.yml
+        1121  2026-08-21 21:00  manifest.json
+      181248  2026-08-22 00:30  volume-dumps/opengist_opengist_data.tar
+## /mnt/sys_drive/felhom-data/backups/primary/paperless
+      294936  2026-08-22 00:30  db-dumps/paperless-postgres.sql
+## /mnt/sys_drive/felhom-data/backups/primary/privatebin
+        1723  2026-08-21 21:00  compose/.felhom.yml
+         288  2026-08-21 21:00  compose/app.yaml
+        1223  2026-08-21 21:00  compose/docker-compose.yml
+        1118  2026-08-21 21:00  manifest.json
+     1055744  2026-08-22 00:30  volume-dumps/privatebin_privatebin_data.tar
+## /mnt/felhom-drives/hdd_1/backups/primary/calibre-web
+        3035  2026-08-21 21:00  compose/.felhom.yml
+         327  2026-08-21 21:00  compose/app.yaml
+        2122  2026-08-21 21:00  compose/docker-compose.yml
+        1165  2026-08-21 21:00  manifest.json
+      368640  2026-08-22 00:30  volume-dumps/calibre-web_calibre_web_config.tar
+## /mnt/felhom-drives/hdd_1/backups/primary/paperless-ngx
+        5971  2026-08-21 21:00  compose/.felhom.yml
+         664  2026-08-21 21:00  compose/app.yaml
+        5802  2026-08-21 21:00  compose/docker-compose.yml
+        1462  2026-08-21 21:00  manifest.json
+      231424  2026-08-22 00:30  volume-dumps/paperless-ngx_paperless_data.tar
+    71417344  2026-08-22 00:30  volume-dumps/paperless-ngx_paperless_postgres_data.tar
+      116736  2026-08-22 00:30  volume-dumps/paperless-ngx_paperless_redis_data.tar
+## /mnt/felhom-drives/hdd_1/backups/primary/romm
+        5520  2026-08-21 21:20  compose/.felhom.yml
+         576  2026-08-21 21:20  compose/app.yaml
+        4399  2026-08-21 21:20  compose/docker-compose.yml
+       62270  2026-08-21 21:02  db-dumps/pre-restore-20260821T210246Z-romm-mariadb.sql
+       62270  2026-08-22 00:30  db-dumps/romm-mariadb.sql
+        1466  2026-08-21 21:20  manifest.json
+        2560  2026-08-22 00:30  volume-dumps/romm_romm_config.tar
+   160247296  2026-08-22 00:30  volume-dumps/romm_romm_db_data.tar
+    14677504  2026-08-22 00:30  volume-dumps/romm_romm_redis_data.tar
+[2026-08-22 02:38:10 CEST] --- planted files still byte-identical (calibre-web books):
+eee5880e304b27c13d205aac9989e901a5f2393be7ecf076ee2c3a0195a2358c  DRILL-2026-08-21/POST-SNAPSHOT.txt
+0c23c8531214fe20cbc1ed177da22f51d65570c5aaedb39e380aa8d4d3e62991  DRILL-2026-08-21/SENTINEL.txt
+725763bbe679b22d5c231a14083ff13155f475c028c22ade4623955b50a2a84a  DRILL-2026-08-21/binary-1mb.bin
+a39ad6f623da67ac72f2e62a24245eef46c722c279ae89cd6b0c7c45afa6a4c4  DRILL-2026-08-21/nested/őszibarack.md
+07e91a985809fc96752f97cddcf6523b211bc607c81a5808befabe35573926f1  DRILL-2026-08-21/plain.txt
+0d6a22ec56acf61b8a80e73eb12cb223d607acaa3684acfcfa7c3e34ecdfabea  DRILL-2026-08-21/árvíztűrő-tükörfúrógép.txt
+[2026-08-22 02:38:12 CEST] --- scheduled db-dump log:
+grep: /opt/docker/felhom-controller/data/debug-ring.log: No such file or directory
+[2026-08-22 04:30:13 CEST] === after the 04:15 SCHEDULED off-site run
+{"last_duration":"2m8s","last_error":"","last_run":"2026-08-22T02:17:12Z","orphaned":false,"progress":{"active":false,"current_app":"","percent":0,"bytes_done":0,"total_bytes":0,"done_human":"","total_human":"","files_done":0,"total_files":0,"current_file":"","elapsed_sec":0,"phase":""},"repo_size_human":"42.8 MB","snapshots":27,"status":"ok"}
+
+[2026-08-22 04:30:13 CEST] --- offsite log:
+grep: /opt/docker/felhom-controller/data/debug-ring.log: No such file or directory
+[2026-08-22 05:20:15 CEST] === after the 05:10 abandonment sweep
+[2026-08-22 05:20:15 CEST] --- sweep log:
+grep: /opt/docker/felhom-controller/data/debug-ring.log: No such file or directory
+[2026-08-22 05:20:16 CEST] --- product CLI:
+[INFO] [settings] Loaded settings from /opt/docker/felhom-controller/data/settings.json
+no abandonment countdown is running on this box
+[2026-08-22 05:20:17 CEST] --- settings abandon fields:
+[2026-08-22 05:20:18 CEST] collector finished

documentation/audits/DRILL-cooldown-grain-2026-08-23/README.md

@@ -0,0 +1,118 @@
+# DRILL — R-389: only the first broken app per hour reached the operator (2026-08-23)
+
+**Hub v0.107.0 → v0.108.0. No controller release, so no golden and no floor.** Live leg on `demo-hp`
+(Tier 0) plus the hub. UNATTENDED. Method: the hub's own SQLite records plus the controller log.
+Guest and hub DB are UTC; the hub pod logs CEST.
+
+**No halt condition fired.**
+
+## The pair that says it
+
+Same box, same shape — two apps down four minutes apart, inside one hour:
+
+```
+2026-08-23 09:27:51  sent        BookStack     <- v0.107.0
+2026-08-23 09:31:51  suppressed  PrivateBin        operator cooldown 1h, key=demo-hp:app_start_failed
+
+2026-08-23 11:56:57  sent        OpenGist      <- v0.108.0
+2026-08-23 12:00:57  sent        Calibre-Web
+```
+
+**2 sent / 0 suppressed**, where the day before the identical shape gave one of each.
+
+And the keys, from the hub's own suppression rows — it records the key only when it declines:
+
+```
+operator cooldown 1h, key=demo-hp:app_start_failed:opengist
+operator cooldown 1h, key=demo-hp:app_start_failed:calibre-web
+```
+
+against v0.107.0's shared `key=demo-hp:app_start_failed`.
+
+## The fence, and why it is not decoration
+
+`crossdrive_failed` is severity `error`, reaches the operator leg, and carries `stack_name` — through
+`CrossDriveDetails`, **a different struct from `AppDetails`**. A rule of the form *"if the details
+carry a stack_name, split per app"* would have split it and silently undone R-182.
+
+Proven live: two different apps' `crossdrive_failed`, one minute apart →
+
+```
+sent        opengist
+suppressed  calibre-web    operator cooldown 1h, key=demo-hp:crossdrive_failed
+```
+
+**Byte-identical to the derived v0.107.0 key. No app suffix.** That is why `cooldownStackSuffix`
+takes the event type as well as the details, unlike its two siblings.
+
+## Part 2 — the burst, measured
+
+Three apps stopped in one scan (`kimai`, `romm`, `paperless-ngx`, none with a live cooldown — checked
+first, because a stale one would have halved the count and made the answer look better than it is):
+
+| | |
+|---|---|
+| attempted | **3** |
+| sent | **3** |
+| suppressed | **0** |
+
+**Judgement: per-app is the right grain, and this volume is acceptable.** The reference box has 8
+deployed apps, so a total outage is 8 mails; the boot grace (90 s), the quiesce grace (180 s) and the
+per-app edge trigger absorb reboots, backup cycles and persistently-dead apps. **No digest row was
+filed.** The reopening condition is stated rather than left implicit: it scales linearly with app
+count and has no ceiling, so a box large enough that a total outage is unreadable is the point at
+which the answer becomes a digest with a customer message — not a wider cooldown.
+
+## Part 3 — gate 11, and the spec discrepancy it forced
+
+The gate refuses a push whose `REPORT.md` carries an observation with neither `FILED: R-NNN` nor
+`NOT-A-FINDING: <reason>`.
+
+**The specification said an item may "cite an R-NNN that resolves". That rule would have passed the
+very item the gate was built to catch.** Yesterday's lost observation reads *"This is R-182's known
+cooldown-key shape…"* — `R-182` resolves, and it is cited as an **analogy**, not as the row that files
+it. No parser can tell citation-as-precedent from citation-as-filing by reading prose. The marker is
+therefore explicit, and the discrepancy is recorded in the gate's docstring rather than quietly
+resolved. `EDGE 7` in the evidence is that exact case, convicted.
+
+| Control | Expected | Observed |
+|---|---|---|
+| historical: yesterday's real section, verbatim | refuse | **exit 1**, naming both items |
+| plant an observation with no row | refuse | **exit 1** |
+| add the row | pass | **exit 0** |
+| remove the observation | pass quietly | **exit 0** |
+| `FILED:` a row that does not resolve | refuse | **exit 1** |
+| `NOT-A-FINDING:` with no reason | refuse | **exit 1** |
+| both markers on one item | refuse | **exit 1** |
+| section present, no numbered items | inconclusive | **exit 2**, saying what it could not read |
+| no `REPORT.md` at all | inconclusive | **exit 2** |
+| a bare `R-182` mention (the trap) | refuse | **exit 1** |
+
+## Evidence index (`evidence/`)
+
+| File | What it shows |
+|---|---|
+| `redproof-1-key.txt` | suffix dropped from the key → `1 operator mail(s), want 2`, and the live key shape reproduced |
+| `redproof-2-allowlist.txt` | allow-list removed → `crossdrive_failed`, `app_deployed`, `app_removed`, `backup_failed` all split per app |
+| `gate11-01-historical-redproof.txt` | yesterday's actual observations section, refused |
+| `gate11-02-three-controls.txt` | plant → refuse, file → pass, remove → pass |
+| `gate11-03-edges.txt` | seven boundaries incl. the R-182 trap |
+| `live-01`…`live-05` | Scenarios A and B: both sent, then each suppressed under its own key |
+| `live-06`, `live-07` | Scenario C: crossdrive stays coarse |
+| `live-08`, `live-09` | the burst, with its pre-check |
+| `live-10-full-controller-log.txt` | 1803 lines, pulled before the restore |
+
+## Teardown
+
+Nothing provisioned. Five apps were stopped across the walk (`opengist`, `calibre-web`, `kimai`,
+`romm`, `paperless-ngx`) and **all were restarted and confirmed healthy** — 17 containers up. No app
+was rebuilt, redeployed or restored; the three retained subjects (`docmost`, `bookstack`,
+`privatebin`) were not touched at all.
+
+**Hub-side, stated explicitly.** The hub was written this session: deployment to v0.108.0 via the
+manifest, and **six probe events were POSTed to the live hub** for Scenarios B and C (two
+`app_start_failed`, two `crossdrive_failed`, plus the two from yesterday's Scenario H that were
+deliberately left in place). They are inert event rows for `demo-hp` and are named here rather than
+left to be found. **Every count in this drill is filtered by `created_at >= T0`** precisely so those
+rows cannot contaminate it. Nothing else: no appliance registered, no customer created, no artifact
+manifest changed, floor untouched.

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/gate11-01-historical-redproof.txt

@@ -0,0 +1,16 @@
+### HISTORICAL RED-PROOF — yesterday's ACTUAL observations section, verbatim from 2f7c9a6 ###
+  report            : ../../../../../tmp/claude-1000/-mnt-5-hdd-felhom-eu-git/3b17bdbd-9113-4908-9b30-15678f2978bc/scratchpad/gate11/REPORT.md
+  section           : ## 10. Observations — recorded, not acted on
+  observation items : 2
+
+OBSERVATIONS GATE FAILED: 2 observation(s) with nothing behind them.
+
+  item 1: **The operator cooldown key carries no app identifier.** PrivateBin's alarm fo…
+     neither `FILED: R-NNN` nor `NOT-A-FINDING: <reason>`
+
+  item 2: Two probe events remain as rows for `demo-hp` from Scenario H — inert, and nam…
+     neither `FILED: R-NNN` nor `NOT-A-FINDING: <reason>`
+
+An observation that lives only in REPORT.md has a lifetime of ONE SESSION — this file is overwritten every time. That is how the cooldown-grain finding was lost on 2026-08-23 and had to be re-derived the next day.
+Fix: add `FILED: R-NNN` naming the row you opened for it, or `NOT-A-FINDING: <why this is not worth a row>`. Opening the row is the default; declaring is the exception and needs its reason stated.
+EXIT=1 (want 1)

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/gate11-02-three-controls.txt

@@ -0,0 +1,25 @@
+### CONTROL 1 — an observation with NO row: must REFUSE (1) ###
+  report            : ../../../../../tmp/claude-1000/-mnt-5-hdd-felhom-eu-git/3b17bdbd-9113-4908-9b30-15678f2978bc/scratchpad/gate11/c1.md
+  section           : ## 9. Observations
+  observation items : 1
+
+OBSERVATIONS GATE FAILED: 1 observation(s) with nothing behind them.
+
+  item 1: The operator cooldown key carries no app identifier, so only the first app per…
+     neither `FILED: R-NNN` nor `NOT-A-FINDING: <reason>`
+
+An observation that lives only in REPORT.md has a lifetime of ONE SESSION — this file is overwritten every time. That is how the cooldown-grain finding was lost on 2026-08-23 and had to be re-derived the next day.
+Fix: add `FILED: R-NNN` naming the row you opened for it, or `NOT-A-FINDING: <why this is not worth a row>`. Opening the row is the default; declaring is the exception and needs its reason stated.
+EXIT=1
+
+### CONTROL 2 — add the row: must PASS (0) ###
+  report            : ../../../../../tmp/claude-1000/-mnt-5-hdd-felhom-eu-git/3b17bdbd-9113-4908-9b30-15678f2978bc/scratchpad/gate11/c2.md
+  section           : ## 9. Observations
+  observation items : 1
+      OK  1. FILED R-389
+observations gate OK — every observation is either filed or explicitly declared
+EXIT=0
+
+### CONTROL 3 — remove the observation entirely: must PASS quietly (0) — Scenario F ###
+observations gate OK — c3.md has no observations section (nothing to check)
+EXIT=0

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/gate11-03-edges.txt

@@ -0,0 +1,44 @@
+### EDGE 1 — NOT-A-FINDING with a reason: PASS (0) ###
+  section           : ## Observations
+  observation items : 1
+      OK  1. NOT-A-FINDING
+observations gate OK — every observation is either filed or explicitly declared
+EXIT=0
+
+### EDGE 2 — FILED with a row that does NOT resolve: REFUSE (1) ###
+     `FILED: R-99999` does not resolve — no row for R-99999 in OPEN-ITEMS.md or CLOSED-ITEMS.md
+
+An observation that lives only in REPORT.md has a lifetime of ONE SESSION — this file is overwritten every time. That is how the cooldown-grain finding was lost on 2026-08-23 and had to be re-derived the next day.
+Fix: add `FILED: R-NNN` naming the row you opened for it, or `NOT-A-FINDING: <why this is not worth a row>`. Opening the row is the default; declaring is the exception and needs its reason stated.
+EXIT=1
+
+### EDGE 3 — NOT-A-FINDING with no reason: REFUSE (1) ###
+     `NOT-A-FINDING:` carries no reason — the reason is the whole point of the marker
+
+An observation that lives only in REPORT.md has a lifetime of ONE SESSION — this file is overwritten every time. That is how the cooldown-grain finding was lost on 2026-08-23 and had to be re-derived the next day.
+Fix: add `FILED: R-NNN` naming the row you opened for it, or `NOT-A-FINDING: <why this is not worth a row>`. Opening the row is the default; declaring is the exception and needs its reason stated.
+EXIT=1
+
+### EDGE 4 — BOTH markers on one item: REFUSE (1) ###
+     carries BOTH `FILED:` and `NOT-A-FINDING:` — decide which it is
+
+An observation that lives only in REPORT.md has a lifetime of ONE SESSION — this file is overwritten every time. That is how the cooldown-grain finding was lost on 2026-08-23 and had to be re-derived the next day.
+Fix: add `FILED: R-NNN` naming the row you opened for it, or `NOT-A-FINDING: <why this is not worth a row>`. Opening the row is the default; declaring is the exception and needs its reason stated.
+EXIT=1
+
+### EDGE 5 — section present, NO numbered items: INCONCLUSIVE (2) ###
+OBSERVATIONS GATE INCONCLUSIVE: found the section '## Observations' but no numbered items under it.
+  Items must be a numbered list (`1.`, `2.` …). If the section is deliberately empty, remove the heading — an empty section reads as coverage while providing none.
+EXIT=2
+
+### EDGE 6 — REPORT.md absent: INCONCLUSIVE (2) ###
+OBSERVATIONS GATE INCONCLUSIVE: no REPORT.md at /tmp/claude-1000/-mnt-5-hdd-felhom-eu-git/3b17bdbd-9113-4908-9b30-15678f2978bc/scratchpad/gate11/does-not-exist.md
+  This gate is registered here because this repo keeps one. If it was removed deliberately, unregister the gate in the runner rather than leaving it unreadable.
+EXIT=2
+
+### EDGE 7 — the R-182 TRAP: a bare mention must NOT satisfy the gate (1) ###
+     neither `FILED: R-NNN` nor `NOT-A-FINDING: <reason>`
+
+An observation that lives only in REPORT.md has a lifetime of ONE SESSION — this file is overwritten every time. That is how the cooldown-grain finding was lost on 2026-08-23 and had to be re-derived the next day.
+Fix: add `FILED: R-NNN` naming the row you opened for it, or `NOT-A-FINDING: <why this is not worth a row>`. Opening the row is the default; declaring is the exception and needs its reason stated.
+EXIT=1

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-00-prestate.txt

@@ -0,0 +1,16 @@
+=== LIVE WALK — pre-state ===
+hub image: gitea.dooplex.hu/admin/felhom-hub:0.108.0
+2026-08-23T11:56:06Z
+controller: gitea.dooplex.hu/admin/felhom-controller:0.223.0 Up 2 hours (healthy)
+
+bookstack	Up 9 hours (healthy)
+bookstack-db	Up 2 hours (healthy)
+calibre-web	Up 9 hours (healthy)
+docmost	Up 6 hours (healthy)
+docmost-postgres	Up 6 hours (healthy)
+docmost-redis	Up 6 hours (healthy)
+opengist	Up 9 hours (healthy)
+privatebin	Up 2 hours (healthy)
+
+-- T0 for every count below: any notification_log row created at or after this instant --
+T0=2026-08-23T11:56:06Z

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-01-scenarioA-app1.txt

@@ -0,0 +1,8 @@
+=== SCENARIO A — two DIFFERENT apps down inside the hour ===
+subjects: opengist and calibre-web (single-container, intent running, neither on the
+do-not-rebuild list). Stopped OUT OF BAND so the controller's own Deploying skip cannot mask it.
+  opengist     desired_state: running
+  calibre-web  desired_state: running
+
+APP 1 (opengist) down at: 2026-08-23T11:56:26Z
+opengist	Exited (0) 5 seconds ago

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-02-scenarioA-app2.txt

@@ -0,0 +1,8 @@
+-- waiting 4 minutes, then APP 2 — the same gap that produced one mail yesterday --
+APP 2 (calibre-web) down at: 2026-08-23T12:00:48Z
+opengist	Exited (0) 4 minutes ago
+calibre-web	Exited (0) 5 seconds ago
+
+-- letting the second alarm land --
+2026/08/23 11:56:56 notifier.go:234: [INFO] Event pushed: app_start_failed (warning) — Telepített alkalmazás nem fut: OpenGist
+2026/08/23 12:00:57 notifier.go:234: [INFO] Event pushed: app_start_failed (warning) — Telepített alkalmazás nem fut: Calibre-Web Automated

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-03-scenarioA-hub-rows.txt

@@ -0,0 +1,11 @@
+=== SCENARIO A — the hub's notification log, filtered to created_at >= T0 (11:56:06Z) ===
+(the T0 filter is what keeps yesterday's two inert Scenario H probe rows out of every count)
+
+status  channel   message                                       key_or_reason  created_at         
+------  --------  --------------------------------------------  -------------  -------------------
+sent    operator  Telepített alkalmazás nem fut: OpenGist                      2026-08-23 11:56:57
+sent    operator  Telepített alkalmazás nem fut: Calibre-Web A                 2026-08-23 12:00:57
+
+-- counts --
+sent      : 2
+suppressed: 0

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-04-scenarioB-repeat.txt

@@ -0,0 +1,8 @@
+=== SCENARIO B — the SAME app again inside the hour: one sent, one suppressed ===
+Posted through the exact endpoint the controller invokes (/api/v1/event), with the controller's
+own AppDetails payload. The controller's own event is edge-triggered per app, so a down->down
+cycle is silent by design and cannot re-fire it from the box.
+
+  T_B=2026-08-23T12:02:48Z
+  repeat OpenGist   http=200
+  repeat Calibre-Web http=200

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-05-scenarioAB-keys.txt

@@ -0,0 +1,15 @@
+=== SCENARIOS A + B — every operator row since T0, with the KEY where the hub records it ===
+status      app                     key_or_reason                                                   created_at         
+----------  ----------------------  --------------------------------------------------------------  -------------------
+sent        ut: OpenGist                                                                            2026-08-23 11:56:57
+sent        ut: Calibre-Web Automa                                                                  2026-08-23 12:00:57
+suppressed  ut: OpenGist            operator cooldown 1h, key=demo-hp:app_start_failed:opengist     2026-08-23 12:02:48
+suppressed  ut: Calibre-Web         operator cooldown 1h, key=demo-hp:app_start_failed:calibre-web  2026-08-23 12:02:48
+
+-- THE KEYS, side by side. Yesterday BOTH apps shared key=demo-hp:app_start_failed. --
+  operator cooldown 1h, key=demo-hp:app_start_failed:opengist
+  operator cooldown 1h, key=demo-hp:app_start_failed:calibre-web
+
+-- counts since T0 --
+  sent      : 2
+  suppressed: 2

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-06-scenarioC-crossdrive.txt

@@ -0,0 +1,15 @@
+=== SCENARIO C — a backup-family event carrying stack_name must NOT split per app ===
+subject: crossdrive_failed — severity error, reaches the operator leg, carries stack_name
+through CrossDriveDetails. Two DIFFERENT apps: if the key had split, both would send.
+
+HOW THE 'BEFORE' VALUE WAS OBTAINED, two independent ways:
+  (a) derivation from v0.107.0's expression, which is customerID:eventType + tier + run and
+      carries no app term, so for this payload it is exactly 'demo-hp:crossdrive_failed';
+  (b) TestR389_NoOtherEventTypeKeyChanges models that v0.107.0 expression INLINE and compares
+      it against the live one for 12 event types — with a positive control proving the test
+      can see a key change before it reports that none occurred.
+The live key printed below must equal that.
+
+  T_C=2026-08-23T12:03:44Z
+  crossdrive_failed opengist http=200
+  crossdrive_failed calibre-web http=200

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-07-scenarioC-result.txt

@@ -0,0 +1,8 @@
+-- SCENARIO C result: the operator rows for crossdrive_failed since T_C --
+status      app         key_or_reason                                        created_at         
+----------  ----------  ---------------------------------------------------  -------------------
+suppressed  alibre-web  operator cooldown 1h, key=demo-hp:crossdrive_failed  2026-08-23 12:03:44
+sent        pengist                                                          2026-08-23 12:03:45
+
+-- the live key, to compare against the derived v0.107.0 value 'demo-hp:crossdrive_failed' --
+  operator cooldown 1h, key=demo-hp:crossdrive_failed

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-08-burst-setup.txt

@@ -0,0 +1,21 @@
+-- restoring the two Scenario A/B subjects before the burst --
+opengist	Up 20 seconds (healthy)
+calibre-web	Up 20 seconds (healthy)
+
+=== PART 2 — THE BURST: three apps down in ONE scan ===
+subjects: kimai, romm, paperless-ngx — none has alarmed inside the last hour, so no
+pre-existing cooldown can mask the count. Verified below before stopping them.
+-- CONTROL: no app_start_failed row for these three in the last hour (a stale cooldown would
+   silently halve the count and the burst would look better than it is) --
+  rows for kimai/romm/paperless since 11:04: 0
+
+  T_BURST=2026-08-23T12:05:03Z
+2026-08-23T12:05:13Z
+kimai	Exited (0) 9 seconds ago
+kimai-db	Exited (0) 8 seconds ago
+paperless-postgres	Exited (0) 4 seconds ago
+paperless-redis	Exited (0) 4 seconds ago
+paperless-webserver	Exited (0) 4 seconds ago
+romm	Exited (0) 9 seconds ago
+romm-db	Exited (0) 9 seconds ago
+romm-redis	Exited (0) 9 seconds ago

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-09-burst-result.txt

@@ -0,0 +1,18 @@
+-- PART 2 — THE BURST RESULT (T_BURST = 12:05:03Z) --
+
+controller side, what it SENT:
+2026/08/23 12:05:26 notifier.go:234: [INFO] Event pushed: app_start_failed (warning) — Telepített alkalmazás nem fut: Kimai
+2026/08/23 12:05:26 notifier.go:234: [INFO] Event pushed: app_start_failed (warning) — Telepített alkalmazás nem fut: RomM
+2026/08/23 12:05:26 notifier.go:234: [INFO] Event pushed: app_start_failed (warning) — Telepített alkalmazás nem fut: Paperless-ngx
+
+hub side, the operator rows:
+status  app                key_or_reason  created_at         
+------  -----------------  -------------  -------------------
+sent    ut: RomM                          2026-08-23 12:05:27
+sent    ut: Kimai                         2026-08-23 12:05:27
+sent    ut: Paperless-ngx                 2026-08-23 12:05:27
+
+THE THREE COUNTS:
+  attempted (rows written): 3
+  sent                    : 3
+  suppressed              : 0

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/live-11-restore.txt

@@ -0,0 +1,19 @@
+-- restoring the three burst subjects --
+2026-08-23T12:08:39Z
+bookstack	Up 10 hours (healthy)
+bookstack-db	Up 3 hours (healthy)
+calibre-web	Up 4 minutes (healthy)
+docmost	Up 6 hours (healthy)
+docmost-postgres	Up 6 hours (healthy)
+docmost-redis	Up 6 hours (healthy)
+filebrowser	Up 44 hours (healthy)
+kimai	Up 52 seconds (healthy)
+kimai-db	Up About a minute (healthy)
+opengist	Up 4 minutes (healthy)
+paperless-postgres	Up 40 seconds (healthy)
+paperless-redis	Up 40 seconds (healthy)
+paperless-webserver	Up 30 seconds (health: starting)
+privatebin	Up 2 hours (healthy)
+romm	Up 41 seconds (healthy)
+romm-db	Up 51 seconds (healthy)
+romm-redis	Up 51 seconds (healthy)

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/redproof-1-key.txt

@@ -0,0 +1,9 @@
+### RED-PROOF 1 (R-389) — mutation: cooldownStackSuffix removed from the key ###
+### layer: processOperator's KEY — where the collapse happens ###
+--- FAIL: TestR389_TwoAppsInsideTheHourBothReachTheOperator (0.02s)
+    r389_cooldown_grain_test.go:180: 2 apps down inside the hour produced 1 operator mail(s), want 2 (suppressed=1). This is R-389: the second app's alarm took the first app's cooldown slot.
+--- FAIL: TestR389_SameAppTwiceInsideTheHourIsStillSuppressed (0.02s)
+    r389_cooldown_grain_test.go:220: the suppression row does not name the app in its key — that visibility is R-182's contribution and is how this defect was found: [sent | Telepített alkalmazás nem fut: BookStack |  suppressed | Telepített alkalmazás nem fut: BookStack | operator cooldown 1h, key=c1:app_start_failed]
+FAIL
+FAIL	gitea.dooplex.hu/admin/felhom-hub/internal/notify	0.166s
+FAIL

documentation/audits/DRILL-cooldown-grain-2026-08-23/evidence/redproof-2-allowlist.txt

@@ -0,0 +1,12 @@
+### RED-PROOF 2 (R-389) — mutation: allow-list removed, suffix applied globally ###
+### layer: cooldownStackSuffix's REGISTER — the fence that keeps the backup family coarse ###
+--- FAIL: TestR389_StackSuffixIsAllowListedAndFailSoft (0.00s)
+    --- FAIL: TestR389_StackSuffixIsAllowListedAndFailSoft/crossdrive_failed_is_NOT_split_per_app (0.00s)
+        r389_cooldown_grain_test.go:58: cooldownStackSuffix("crossdrive_failed", "{\"stack_name\":\"bookstack\",\"method\":\"rsync\"}") = ":bookstack", want ""
+    --- FAIL: TestR389_StackSuffixIsAllowListedAndFailSoft/app_deployed_is_not_in_the_register (0.00s)
+        r389_cooldown_grain_test.go:58: cooldownStackSuffix("app_deployed", "{\"stack_name\":\"bookstack\",\"display_name\":\"BookStack\"}") = ":bookstack", want ""
+    --- FAIL: TestR389_StackSuffixIsAllowListedAndFailSoft/app_removed_is_not_in_the_register (0.00s)
+        r389_cooldown_grain_test.go:58: cooldownStackSuffix("app_removed", "{\"stack_name\":\"bookstack\",\"display_name\":\"BookStack\"}") = ":bookstack", want ""
+    --- FAIL: TestR389_StackSuffixIsAllowListedAndFailSoft/backup_failed_is_not_in_the_register (0.00s)
+        r389_cooldown_grain_test.go:58: cooldownStackSuffix("backup_failed", "{\"stack_name\":\"bookstack\",\"display_name\":\"BookStack\"}") = ":bookstack", want ""
+--- FAIL: TestR389_NoOtherEventTypeKeyChanges (0.00s)

documentation/audits/DRILL-r201-night-run-2026-08-04.md

@@ -0,0 +1,265 @@
+# DRILL — R-201, the night run: **PASS. The customer's file came back, byte-identical.**
+
+**Date:** 2026-08-04, 21:30–23:15 · **Box:** `demo-hp` (Tier 0) · unattended, then **finished with the
+operator present**. The box is up, healthy, and fully re-armed.
+
+> **THE VERDICT: PASS.**
+>
+> ```
+> pre-wipe   sha256: 643166269103a25cf41d34a26b75fd6ebba0a837bbcd7e0d2b5aba7106bcbe7c
+> restored   sha256: 643166269103a25cf41d34a26b75fd6ebba0a837bbcd7e0d2b5aba7106bcbe7c
+> ```
+>
+> A machine was destroyed on purpose — controller data volume gone, the customer's file deleted from
+> disk — and **the file came back byte-identical**, through the customer's own recovery code and the
+> customer's own restore flow. **This is the first time the Felhom backup story has been proved end to
+> end.**
+>
+> The key recovered byte-identical (`8a9e33aa4da6…`), the existing repository **opened rather than
+> being re-initialised** (`repo_state: null`, 3 snapshots, 42 026 B — the pre-wipe size exactly), and
+> the pre-wipe snapshot `e6132ae5` was still there with the file inside it.
+>
+> **It took four undocumented steps to get there**, each measured, and they are the other half of the
+> result — see §3. A customer hitting this alone today would not get their data back.
+
+---
+
+## 1. The verdict — **PASS**
+
+| | |
+|---|---|
+| sentinel sha256, pre-wipe (step 3) | `643166269103a25cf41d34a26b75fd6ebba0a837bbcd7e0d2b5aba7106bcbe7c` |
+| sentinel sha256, restored (step 10) | **`643166269103a25cf41d34a26b75fd6ebba0a837bbcd7e0d2b5aba7106bcbe7c`** |
+| **match** | **YES — byte-identical** |
+| snapshot count at step 9 | **3** — the pre-wipe count. **NOT 1.** No fresh history was started |
+| repo size at step 9 | **42 026 B** — the pre-wipe size exactly |
+| `repo_state` | **`null`** — the repository OPENED. Not orphaned |
+
+The restore ran through the customer flow (`POST /backup/offbox/restore`, `mode=full`, two-step
+confirm), out of snapshot `e6132ae5` — the one taken **before** the wipe.
+
+**A detail worth keeping:** the first restore attempt used the default `mode=unit`, which recovers the
+recovery unit only and **not** the userdata leg. `mode=full` is what returns the customer's files. A
+customer told to "restore from off-site" would, on the default, get their app definition back and not
+their documents — and nothing in that outcome says so.
+
+## 2. What was proven, in order, on hardware
+
+### Step 6 — the wipe
+
+The controller's data volume was destroyed and the bootstrap re-ran. Fresh data directory, everything
+stamped `2026-08-04 20:00:2x`:
+
+```
+encryption.key   32 B   2026-08-04 20:00:21     ← brand new: every pre-wipe app secret is undecryptable
+claimed = None                                   ← the fresh-install signal
+offbox  = null                                   ← no off-site target
+```
+
+**Faithful to the incident, and deliberately so.** The 2026-08-03 rebuild that R-193 is filed against
+was **not** a guest reprovision — the journal shows guest 9201 running continuously through that
+window, with no `pct destroy`, no `pct restore` and no `--selftest=provision`. What changed was the
+controller and its data volume. Reproducing *that* is what the drill needs; a guest destroy plus an
+unrehearsed provisioning chain, improvised unattended, is what §8.10 exists to prevent.
+
+### Step 7 — the assertion that keeps recovery possible: **PASSED**
+
+```
+host_escrow (demo-hp-bb76ea), AFTER the wipe:
+  identity_blob    = 572 bytes          ← unchanged
+  restic_pw_sha256 = 8a9e33aa4da6…      ← unchanged
+  updated_at       = 2026-08-04 11:11:37 ← unchanged; nothing re-escrowed
+  stale_at         = NULL
+```
+
+**No ceremony was run and nothing re-escrowed itself.** The sealed key survived the rebuild untouched.
+
+### Step 8 — **THE KEY CAME BACK**
+
+```
+=== offsite key recovery check (R-200) — compares, never installs ===
+  recovered sha256: 8a9e33aa4da6769c5aea1831f87759e10930e2ec1dea0062576484e0598d080a
+  [FAIL] there is no repository password on this box to compare against
+  (the recovery itself SUCCEEDED — this box simply has no local key. That is the
+   rebuilt-box shape, where the next step is to INSTALL rather than compare.)
+```
+
+Exit 1 is **correct and designed**: there was nothing to compare against, because the wipe removed it.
+The recovered hash matches the pre-wipe on-disk key and the hub's own record — three independent
+sources agreeing, one of them recovered through the full chain (hub → agent → unseal → extract) on a
+box that had just lost everything it knew.
+
+### Step 9a — installed cleanly
+
+```
+=== offsite key recovery INSTALL (R-200) ===
+  on-disk   sha256: (none — this box has no repository password)
+  recovered sha256: 8a9e33aa4da6…
+  [INSTALLED] the recovered repository password is in place and reads back identical.
+```
+
+The "installed" branch — the rebuilt-box shape v0.196.0 was written for — took its first real run.
+
+### Step 9b — the apply kept it
+
+After the target was reconfigured, the on-disk key was still `8a9e33aa4da6…`. `WriteOffboxSecrets`
+found the file present and kept it, exactly as documented.
+
+---
+
+## 3. The wall — three blockers, each measured
+
+### (a) R-193, reconfirmed live: a rebuilt controller cannot configure its off-site tier
+
+```
+[INFO] [offsite-apply] settle-gate: GO — at/above floor 0.156.0 (we are 0.197.0)
+[WARN] [offsite-apply] reconcile: offsite-apply: consume one-time password:
+       no unconsumed offsite password (already consumed or none provisioned)
+       (retries on next config refresh/restart)
+```
+
+The ledger, measured: `demo-hp` one-time secret created `07:11:51`, consumed `07:12:06` — **by the
+previous controller**. The rebuilt one has nothing to consume and retries forever. Exactly the state
+demo-hp sat in for 25 hours on 2026-08-03.
+
+**Remedy:** an operator Re-issue. Performed here through the designed endpoint
+(`POST /configs/demo-hp/offsite-reissue`, HTTP 303), after which the target configured normally.
+
+### (b) R-196, measured live — and it lands squarely on the recovery path
+
+```
+host_escrow (demo-hp-bb76ea), after the Re-issue:
+  stale_at         = 2026-08-04 20:15:49   ← set
+  restic_pw_sha256 = 8a9e33aa4da6…         ← UNCHANGED. The key did not move.
+```
+
+**The escrow was marked stale while it perfectly covers the box's current key** — the recovered one.
+That is R-196's false staleness, and here it is not a cosmetic lie: a stale escrow makes the hub
+**withhold the hash from the report ACK**, so `EscrowAutoConfirmer` can never flip `pending →
+escrowed`, and `OffboxRunnable` (`configured && escrowed`) **refuses to run any off-site backup**.
+
+> **The remedy for (a) disables the recovery it was needed for.** The only documented way to clear a
+> stale escrow is a fresh ceremony — which supersedes the identity blob, i.e. **destroys the very key
+> being recovered**. Under hub v0.93.0 the old blob is now *retained*, but nothing can serve a
+> superseded blob back (R-199's inventory: the endpoint serves the CURRENT row only).
+
+**Superseded rows still number 2** — no ceremony was run tonight. The key is intact.
+
+### (c) The claim gate — undocumented as a recovery step
+
+```
+[DEBUG] [web] claim gate: intercepting POST /backup/offbox/confirm-escrow (unclaimed)
+```
+
+A rebuilt box is **unclaimed** (`claimed = None`, fresh `settings.json`), and the claim gate correctly
+intercepts every non-claim route. **So no controller endpoint can be driven at all** — not the manual
+escrow confirm, not the backup trigger — until the customer re-claims the box. Both POSTs returned 302
+to the claim page and neither reached its handler; `last_run` stayed null, which is why the earlier
+reading of "the run was refused" needed this second look to be accurate.
+
+This is correct behaviour and it is **not wrong** — but it is a step in the customer's recovery journey
+that appears in no design document, and it comes *before* anything else can happen.
+
+---
+
+## 4. How it was finished, and the fourth undocumented step
+
+The unattended run stopped at the wall in §3 rather than improvising further at 22:35 (§8.10). With the
+operator present the remaining path was walked, and it took **four steps a customer would have to
+discover**:
+
+1. **Re-issue** the offsite credential (hub, operator-only) — otherwise the box can never configure its
+   tier. §3(a).
+2. **Re-claim the box.** The local escape hatch (`--print-reset-code`) mints a code — **and does not
+   work on its own**: it writes the new hash to `settings.json` while the RUNNING controller keeps its
+   old copy in memory, so `effectiveClaimCode()` never sees it and every attempt returns
+   *"Hibás vagy lejárt kód"*. **The controller must be restarted between minting and claiming.** Two
+   claim attempts failed on this before it was diagnosed; the generation counter reached 6.
+3. **Confirm the escrow** manually (`/backup/offbox/confirm-escrow`) → `escrowed`, so `OffboxRunnable`
+   permits a run. **Not a ceremony** — the identity blob was never superseded (still 2 retained rows).
+4. **Restore with `mode=full`.** The default `mode=unit` returns the recovery unit and **not** the
+   customer's files.
+
+**None of these four is in any design document, and the drill needed all four.**
+
+## 5. §5's five conditions, as recorded before the wipe
+
+| # | Condition | Evidence |
+|---|---|---|
+| 1 | §4 confirmed, sentinel **listed by name** | snapshot `e6132ae5` (19:36:26) — `-rw-r--r-- 1000 1000 181 … /DRILL-SENTINEL.txt` |
+| 2 | deliberate rollback archive, **verified** | `vzdump-lxc-9201-2026_08_04-21_44_24.tar.zst`, 1 606 765 083 B; **full zstd stream read OK** (4 867 573 760 B uncompressed); the sentinel confirmed **inside** it |
+| 3 | §3's option | see §6 |
+| 4 | demo-felhom untouched | `health=ok`, `escrow_state=escrowed`, not touched at any point |
+| 5 | free space | nvme-1tb 883 GB free, root 20 GB, local-lvm 34.32 % |
+
+**A precondition had drifted and was repaired before the wipe, not worked around.** The staged
+snapshot no longer contained the sentinel: the afternoon's `[WARN] mandatory data path missing`
+experiment produced a *later* same-day calibre-web snapshot, and restic's `forget --keep-daily 7
+--group-by host,tags` had pruned the good one in its favour. The fixture on disk was correct, so one
+backup re-established it and it was re-verified by listing. **Lesson worth carrying: a good snapshot is
+not durable against a later bad run on the same day.**
+
+## 6. §3 — the recovery code
+
+**Option B as already in place, with a strict improvement: no new copy was created, so nothing needed
+shredding.**
+
+The operator placed `R_DEMO-HP` in their own `~/.config/credentials` on DooPlex (mode `0600`) two
+sessions ago, deliberately, for this purpose. This session read it from there and **piped it to stdin**
+for each of the two invocations that needed it. It was never an argument, never exported, never written
+to a second file, and never logged.
+
+**Nothing was shredded, and that is the point:** the operator's own permanent store is theirs, not a
+drill artefact, and destroying it would have destroyed their record. Because no additional copy was
+made, there is nothing left behind to prove gone — a stronger position than option B's
+create-then-shred.
+
+**Verified afterwards** with the planted-copy positive control, exactly as on 2026-08-04 afternoon —
+see §8.
+
+---
+
+## 7. The state the box is left in — healthy and re-armed
+
+```
+controller   felhom-controller:0.197.0, healthy, CLAIMED
+apps         privatebin opengist calibre-web filebrowser cloudflared traefik  — all serving
+escrow_state escrowed          (no ceremony was run; identity_blob untouched)
+repo key     8a9e33aa4da6…     THE RECOVERED KEY — and the repository opens with it
+off-site     3 snapshots, 42 026 B, repo_state null; all three apps re-toggled for off-site
+sentinel     restored to its live location, sha256 643166269103a25c… — verified
+```
+
+The verification copy under `backups/offsite-restore/calibre-web/` is **left in place as evidence**.
+
+## 8. R persisted nowhere — searched, with a positive control
+
+Swept the agent journal, the controller container log, and `/tmp`, `/var/tmp`, `/var/lib/felhom-agent`,
+`/root` on demo-hp for the recovery code: **0 hits**, and **0** leftover `felhom-idesc-*` unseal
+staging directories. A planted copy was found by the same sweep (**1**) and not found after shredding
+(**0**), so the instrument is shown sensitive rather than assumed to be.
+
+---
+
+## 9. Teardown — three layers
+
+| layer | state |
+|---|---|
+| the guest | **Nothing torn down.** The wipe is the evidence; the apps are serving; the recovered key is in place. The scratch band is empty — no restore-test guest was created tonight. |
+| the host | `vzdump` snapshot LVs removed cleanly by the archive job (`snap_vm-9201-disk-0/1_vzdump` both released). One new archive, 1.6 GB, on `nvme-1tb` (883 GB free). Nothing deleted. |
+| the hub | **No new customer records.** `demo-hp` is the same customer row throughout — the rebuild was a controller-data wipe, not a re-enrolment, so nothing accumulated. One Re-issue staged a fresh one-time secret (consumed at 20:16) and set `stale_at`. The two superseded escrow rows are **unchanged** — no ceremony ran. |
+
+**Nothing was deleted on the storage endpoint**, including the ~1.2 GB of previously-orphaned
+ciphertext. Ruled, still owed, and deliberately not ridden along with a drill.
+
+## 10. Part 2 — not run
+
+Its gate is *"the drill PASSED; its evidence is written down; and there is time."* The first two are
+now met. **The third was not** — it was 23:15 after a full destructive cycle, and Part 2 is a second
+wipe. It is deliberately left for a session that starts fresh, with drill 1's result already recorded
+so a second wipe cannot overwrite it.
+
+**R-198's retention therefore remains unit-proven only.** Nothing has yet superseded a key in
+production, so the retention's live behaviour is still unobserved — and it is now the last unproven
+link in the chain this drill exercised. The check is cheap: wipe again, do NOT recover, let a ceremony
+seal a different password, then read the superseded row's `identity_blob`.

documentation/audits/DRILL-r201-offsite-recovery-2026-08-04.md

@@ -0,0 +1,311 @@
+# DRILL RECORD — R-201, the wipe-and-recover proof: **PREPARED, HALTED BEFORE THE WIPE**
+
+**Date:** 2026-08-04 · **Box:** `demo-hp` (Tier 0, the designated drill host) · **Nothing was wiped.**
+**Outcome:** the drill did not reach its verdict. It was halted at step 4 by a defect that makes the
+verdict unobtainable — and that defect is worth more than the drill.
+
+> **THE HEADLINE.** A customer-declared **mandatory** data directory was **silently absent from the
+> off-site snapshot**, while the backup reported `ok` with three snapshots. The only trace is one
+> `[WARN]` line inside the controller container. The hub, the card and the counters all say the backup
+> succeeded. → **R-203**
+>
+> **Nothing irreversible happened.** The wipe never ran. `demo-hp` is left in a BETTER state than it
+> started: it now has a working off-site repository (it had an orphaned one), three snapshots, and a
+> sentinel file on disk.
+
+---
+
+## 1. The verdict — not reached, and why that is the correct outcome
+
+The drill's pass condition is a byte-identical sentinel sha256 after a wipe. **Step 4 established that
+the sentinel is not in the off-site snapshot at all.** Wiping the box would therefore have:
+
+- destroyed the sentinel, which exists only on that box;
+- proven nothing about recovery, because there would be nothing to recover;
+- and done so *after* the point of no return.
+
+The runbook's own rule applies: *"If this session finds itself writing code beyond Part 0, stop. That
+means a precondition was wrong, and the finding outranks the drill."* A precondition was wrong. It was
+one the runbook's P1–P6 table did not contain, because nobody knew to look for it.
+
+**Sentinel sha256 (step 3), recorded and still on the box:**
+`643166269103a25cf41d34a26b75fd6ebba0a837bbcd7e0d2b5aba7106bcbe7c`
+at `/mnt/sys_drive/userdata/media/books/DRILL-SENTINEL.txt` (181 B).
+
+---
+
+## 2. R-203 — the defect that halted the drill
+
+**Measured, twice, on the live box.**
+
+| what | path | exists? |
+|---|---|---|
+| the app's live bind, where the customer's files actually land | `/mnt/sys_drive/userdata/media/books` | **YES** (the sentinel is here) |
+| the path the off-site capture set treats as the mandatory directory | `/mnt/sys_drive/felhom-data/userdata/media/books` | **NO** |
+
+The controller's own log, verbatim:
+
+```
+[WARN] [offbox] calibre-web: mandatory data path missing on disk, skipped from offsite:
+       /mnt/sys_drive/felhom-data/userdata/media/books
+[INFO] [offbox] backed up calibre-web (…/backups/primary/calibre-web, 0 mandatory path(s))
+[INFO] [offbox] backup OK: 3 app(s) backed up, 3 snapshot(s), 37s
+```
+
+**The run reported `ok`.** `last_status: ok`, `last_success` stamped, `snapshot_count: 3`. Nothing
+customer-visible, nothing hub-visible and nothing in any counter says the mandatory directory was
+dropped. This is `CLAUDE.md`'s recurring shape — *a path the customer thinks is protected is not in the
+snapshot* — and the code even has the right words for it in a WARN nobody reads.
+
+**The mechanism, from source.** `NamespaceRoot(drivePath, inGuestDrive)`
+(`appbackup/paths.go:28-33`) appends `felhom-data` **when the drive IS the system data path**
+(`m.namespaceRoot` = `NamespaceRoot(drivePath, drivePath != m.systemDataPath)`,
+`backup/backup.go:331`). The deploy-time bind does not: `${USERDATA_PATH}` is documented and computed
+as **`<HDD_PATH>/userdata`** (`stacks/classify_binds.go:14`). With `system_data_path: /mnt/sys_drive`
+and an app deployed at `HDD_PATH=/mnt/sys_drive`, those two produce different directories.
+
+**And the same compose file used BOTH roots.** From `docker inspect calibre-web`:
+
+```
+bind /mnt/sys_drive/felhom-data/userdata/import/calibre -> /cwa-book-ingest     ← felhom-data root
+bind /mnt/sys_drive/userdata/media/books               -> /calibre-library      ← NO felhom-data root
+```
+
+`${IMPORT_PATH}` resolved *with* the segment; `${USERDATA_PATH}` resolved *without* it. One deploy, one
+template, two roots.
+
+### What is measured and what is not — stated because the scope changes the fix
+
+- **MEASURED:** the two paths disagree; the mandatory directory is absent from the snapshot; the run
+  reports `ok`; the only signal is a container-log WARN.
+- **NOT ESTABLISHED:** whether `HDD_PATH=/mnt/sys_drive` is a *supported* choice. It was chosen because
+  demo-hp's only registered drive, `Felhom-Share`, is a NAS and was **correctly refused** as an app
+  namespace (R-108's `RefuseAsAppNamespace`, working as designed). `/mnt/sys_drive` was **accepted**
+  (HTTP 202) rather than refused.
+
+**Either branch is a defect, which is why this is filed regardless:**
+
+- if the system drive **is** a supported app namespace → the userdata path resolution is wrong for
+  every app deployed on it, and their mandatory directories are silently unprotected;
+- if it is **not** supported → the deploy accepted a namespace it should have refused, exactly as it
+  refused the NAS one call earlier, and the refusal that exists is not reaching this case.
+
+**What must NOT be concluded from this drill:** that off-site backups are broken generally. The two
+pre-existing apps (`opengist`, `privatebin`) declare **no** mandatory userdata paths — everything they
+own is in named volumes — so they are unaffected, and their snapshots are real.
+
+---
+
+## 3. Preconditions, each measured
+
+| # | Precondition | Result |
+|---|---|---|
+| **P1** | operator holds the recovery code | **PASS** — `R_DEMO-HP`, recorded by the operator in the DooPlex credentials file (`~/.config/credentials`). *The code itself appears nowhere in this record.* |
+| **P2** | demo-hp on agent v0.125.0 + controller v0.196.0 | **FAILED ON ARRIVAL, FIXED** — the box was on agent **v0.124.1**. Deployed the published v0.125.0 (sha `f7d8339b53d9…`, verified against the release) and controller v0.196.0. `age` present at `/usr/bin/age`. |
+| **P3** | the current `identity_blob` seals the repository under test | **PASS with a caveat that reshaped the drill** — `identity_blob` = 572 B, `restic_pw_sha256` = `8a9e33aa4da6…`. But **no repository existed under that key** (see §4). |
+| **P4** | a deliberate, verified whole-guest archive as rollback | **NOT TAKEN** — deliberately. It is only needed for the wipe, and the wipe did not happen. |
+| **P5** | demo-felhom untouched and healthy | **PASS** — not touched at any point. |
+| **P6** | space | **PASS** — `felhom-backup` 927 GB free, `local-lvm` 30.9 % used, guest 64 GB free. |
+
+---
+
+## 4. Step-by-step, with every observable
+
+### Step 1 — starting state (hub, read-only)
+
+`demo-hp-bb76ea`: `identity_blob` 572 B, `restic_pw_sha256` `8a9e33aa4da6769c5aea1831f87759e10930e2ec1dea0062576484e0598d080a`, created `2026-08-04T11:11:37Z`, `escrow_state: escrowed`.
+Report: `snapshot_count: 0`, `repo_size_bytes: 0`, **no `last_run`/`last_status` at all** — the shape of
+a controller that has never run an off-site backup in this lifetime.
+
+### Step 1b — the repository was ORPHANED, and this is the first live proof of a prediction
+
+The 2026-08-04 spike predicted from source — and could not measure — that a rebuilt box's next
+off-site run would hit a **third** outcome: neither reattaching the old snapshots nor silently starting
+a fresh history, but **refusing**. Measured here, twice over.
+
+**Read-only probe first** (`restic cat config` with the current key, writes nothing):
+
+```
+Fatal: wrong password or no key found
+```
+
+— the exact string `classifyResticProbe` maps to `"orphaned"`.
+
+**Then the real run, through the customer UI endpoint** (`POST /backup/offbox/run`):
+
+```
+[WARN] [offbox] offsite repo ORPHANED — remote holds backups written under a previous,
+       no-longer-available key; runs will skip until reset
+[WARN] [offbox] run skipped — offsite repo orphaned (card shown; awaiting reset)
+[INFO] Event pushed: offbox_repo_orphaned (warning) — A távoli mentési tároló elárvult …
+```
+
+`repo_state: "orphaned"`, `orphaned_at: 2026-08-04T12:37:30Z`, `last_status: "error"`, the orphan card
+rendered on `/backups/remote`, and the event reached the hub (HTTP 200).
+
+> **The system stopped and said so. It did not quietly start a new history over the old one.**
+> That closes R-193's open Q3 — and it is the good half of this month's story.
+
+**Why the repository was orphaned:** the 15 snapshots / 40.9 MB at `/home/felhom-repo` were written
+under key `8e03eddf9ff7…` before the 2026-08-03 rebuild. That key survives only in superseded escrow
+row **id 3**, which carries **`identity_blob` = NULL** — it was superseded at `2026-08-04 07:15:36`,
+**four hours before** hub v0.93.0 fixed the retention. Unrecoverable, permanently, with or without a
+recovery code.
+
+### Step 1c — the reset (operator-authorised)
+
+The orphan card's own reset, confirmed by the operator during the session:
+
+```
+[WARN] [offbox] resetting orphaned repo (operator-confirmed (claimed)):
+       move-aside /home/felhom-repo -> /home/felhom-repo.orphaned-20260804, then re-init
+[INFO] [offbox] orphaned repo reset complete — old history set aside at
+       /home/felhom-repo.orphaned-20260804 (move-aside, not deleted); fresh repo initialized
+[INFO] Event pushed: offbox_repo_reset (info)
+```
+
+**Nothing was deleted.** The reset path had never run in anger before; it works.
+
+### Steps 2–3 — the recovery code and the sentinel
+
+The operator ran the ceremonies for **both** boxes earlier the same day and saved the codes. Measured
+hub-side: the new escrow rows are stamped `2026-08-04T11:11:37Z` (demo-hp) and `11:13:06Z`
+(demo-felhom), and `restic_pw_sha256` is **unchanged** on both — so `SaveHostEscrow` correctly treated
+them as same-password re-ceremonies: **no superseded row, no `offsite_repo_key_changed`**. That is
+v0.93.0's Scenario E, live.
+
+**A file-leg app had to be deployed**, and this is a precondition the runbook did not anticipate:
+neither off-site-toggled app on the box (`opengist`, `privatebin`) has a restorable file leg — both
+keep everything in **named volumes**, which the off-site tier backs up as tars but the customer restore
+flow **never unpacks** (`offbox_reconstitute.go`). A sentinel in either would have been unrecoverable
+by design.
+
+`calibre-web` was chosen: it declares `userdata: media/books class: mandatory`, and it is a
+single-container app. Deployed through the real API (`POST /api/stacks/calibre-web/deploy`, HTTP 202),
+toggled for off-site, and a Tier-1 recovery unit captured
+(`Recovery unit captured for calibre-web → …/backups/primary/calibre-web`).
+
+Sentinel written, `sync`ed, hashed: **`643166269103a25c…`**, 181 B.
+
+### Step 4 — the pre-wipe off-site backup: **`ok`, and wrong**
+
+```
+last_run 2026-08-04T12:54:50Z · last_status ok · last_success stamped
+snapshot_count 3 · repo_size_bytes 30 636 · repo_state null
+```
+
+Three snapshots, three apps, 37 s — and **the sentinel is in none of them**, per §2.
+
+### Steps 5–11 — NOT RUN
+
+Step 5 (verify the pre-wipe snapshot contents) would have confirmed the absence a second way; it is
+moot given §2. Steps 6–11 (archive, wipe, reinstall, recover, install, restore, compare) were **not
+started**. The §7 STOP was never reached, because the drill failed its own precondition first.
+
+---
+
+## 5. Part 0 — shipped, tested, deployed (R-200's plumbing half)
+
+`--recover-offsite-install` (controller **v0.196.0**, commit `1b1366b`): same fetch → unseal → extract
+path as `--recover-offsite-check`, same STDIN discipline for R, but it **places** the recovered
+password via `InjectOffboxPassword`.
+
+- **Confirmation is a second invocation.** Without `--confirm-install` it prints both hashes and writes
+  nothing. A single interactive prompt would have had to share stdin with R.
+- **Three outcomes, named distinctly:** *installed* (no local password — the rebuilt-box shape),
+  *unchanged* (identical key already present, nothing written), *refused* (a DIFFERENT key present;
+  installing would clobber the key the current repository is encrypted under — exit 2, no force offered).
+- It re-reads the file after writing rather than trusting the call's return.
+
+**Tests + red-proof.** `go build && go vet && go test ./...` rc=0; `controller_gates.py --fast` OK.
+Removing the confirmation gate makes the dry run write the password and fails
+`TestRecoverAndInstall_InstallsOnABareBox` with *"the DRY RUN wrote the password"*. The R-persistence
+test carries a **positive control** — a planted copy of the code is found by the sweep, then removed
+and not found — because an absence check is worth only what its sensitivity is.
+
+**It was deployed to demo-hp and never exercised against a live recovery**, because the drill halted
+before step 9. Its unit proof stands; its live proof does not exist.
+
+---
+
+## 6. What this drill did and did not establish
+
+**Established, live, for the first time:**
+
+1. A rebuilt box's off-site repository is **orphaned and the run refuses** — the spike's predicted
+   third outcome, measured. It does not silently start a fresh history.
+2. The **orphan reset works**: move-aside, never delete, fresh repo initialised, event pushed.
+3. **A customer-declared mandatory data directory can be silently absent from the off-site snapshot
+   while the run reports `ok`** (R-203).
+4. demo-hp's pre-rebuild off-site history is **permanently unrecoverable** — its key was destroyed four
+   hours before the fix that would have kept it.
+
+**NOT established — and unchanged from before this session:**
+
+- **No file has ever been restored from an off-site backup after a wipe.** R-201's question is still
+  open, and its pass condition is unchanged.
+- Part 0's install path has never run against a live recovery.
+- The v0.93.0 `identity_blob` retention is **still unit-proven only** — nothing in this session
+  superseded a key, so nothing exercised it.
+
+---
+
+## 7. State left behind, and teardown
+
+**Deliberately not torn down** — this is evidence, and the box is better off than it was:
+
+| layer | state |
+|---|---|
+| the guest | `calibre-web` deployed and running, off-site-toggled, sentinel file in place. **Kept** as the drill fixture for the resumed run — it is the only app on either demo box with a restorable file leg. |
+| the off-site repository | fresh, working, 3 snapshots, 30 636 B. The old 15-snapshot history is **set aside**, not deleted, at `/home/felhom-repo.orphaned-20260804`. |
+| the host | agent v0.125.0, controller v0.196.0, `pvesm` unchanged apart from normal usage. |
+| the hub | `offbox_repo_orphaned` + `offbox_repo_reset` events recorded for `demo-hp`. No scratch customer records were created — **nothing was reinstalled**. |
+
+**The ~1.2 GB of previously-orphaned ciphertext was NOT deleted** — that act is ruled and still owed,
+and §8.3 of the runbook forbids riding it along with a drill. The reset added
+`/home/felhom-repo.orphaned-20260804` (≈41 MB) to what is set aside.
+
+**No `R` persisted anywhere** — the recovery code was never used in this session. It was read only to
+confirm the key exists in the credentials file; no unseal was performed on demo-hp.
+
+---
+
+## 7b. UPDATE, same day — the blocker is FIXED and the drill is ready to resume
+
+Controller **v0.197.0** shipped both halves of R-203:
+
+- **the paths agree.** On demo-hp the live bind moved from `/mnt/sys_drive/userdata/media/books` to
+  `/mnt/sys_drive/felhom-data/userdata/media/books` — the directory the capture set looks in. The
+  capture log went from `0 mandatory path(s)` to **`1 mandatory path(s)`**.
+- **`ok` means it.** A run that cannot capture a MANDATORY directory now reports **`incomplete`**,
+  names the app and the folders, and raises the operator digest — instead of `ok` with a warning
+  beside it.
+
+**And the sentinel is in the snapshot, listed by name:**
+
+```
+$ restic ls -l latest --tag calibre-web
+-rw-r--r--  1000  1000  181  2026-08-04 12:53:06  /mnt/sys_drive/felhom-data/userdata/media/books/DRILL-SENTINEL.txt
+```
+
+sha256 **`643166269103a25cf41d34a26b75fd6ebba0a837bbcd7e0d2b5aba7106bcbe7c`** — byte-identical to §1,
+verified after the fix's migration moved the file to the corrected directory.
+
+**One live check could NOT be reproduced, and is recorded rather than claimed.** Hiding the books
+directory to watch the `incomplete` verdict fire on hardware did not work: the running container's
+bind mount **recreated** the directory, so `os.Stat` succeeded and there was no gap. That is itself
+worth knowing — a bind-mounted directory cannot easily be "missing" while its app runs, so the
+mandatory-gap condition arises in practice when the path resolves somewhere the app never binds (the
+R-203 case), not when a live app's own directory vanishes. The verdict is proven by the run-level
+test, which drives the real `RunOffboxBackup` and asserts both `incomplete` and the operator signal.
+The fixture was restored and the sentinel re-verified at the same hash.
+
+## 8. To resume the drill
+
+1. **Fix or scope R-203.** Until the mandatory userdata path lands in the snapshot, no sentinel can
+   survive a wipe and the drill cannot reach its verdict.
+2. Re-run steps 4–5 and confirm the sentinel IS in the snapshot — by listing it, not by a green status.
+3. Then P4 (the deliberate archive), the §7 STOP, and steps 6–11 as written.
+
+Everything else is already in place: the code, the versions, the recovery code, the working repository,
+the file-leg app and the sentinel.

documentation/audits/DRILL-r329-r386-2026-08-23/README.md

@@ -0,0 +1,110 @@
+# DRILL — R-329 + R-386: the alarm that fired but reached nobody, and the stop nobody heard (2026-08-23)
+
+**Controller v0.222.0 → v0.223.0. Hub v0.106.0 → v0.107.0. Live leg on `demo-hp` (Tier 0), guest
+9201. UNATTENDED.** Method: endpoint-level plus the hub's own SQLite records — no browser exists on
+DooPlex. Guest and hub clocks are UTC; the hub pod logs CEST.
+
+## Verdict
+
+| Part | Outcome |
+|---|---|
+| 1.1 the severity word + sweep | ✅ **exactly one** bad severity in the whole controller |
+| 1.2 the AST contract guard | ✅ and it found two dynamic sites the hand sweep missed |
+| 1.3 customer toggle, default OFF | ✅ |
+| 2 the hub says what it rewrote | ✅ hub v0.107.0, proven live |
+| 3 ask the field that knows | ✅ proven live, both directions |
+| 4 split the compound toggles | ✅ round trip byte-identical |
+| 5 record the notification philosophy | ✅ recorded, **not implemented** |
+
+**No halt condition fired.**
+
+## The one number that says it all
+
+Read from the live hub DB:
+
+```
+91 app_start_failed events stored, all-time
+ 0 notification_log rows before 2026-08-23 09:00   <- not one, ever, on any channel
+```
+
+After the fix, at 09:27:51: **one row — `warning` / `sent` / `operator`.**
+
+## The two live pairs
+
+**Scenario A** — a database dies, customer has not opted in:
+
+```
+events         : demo-hp  app_start_failed  warning  2026-08-23 09:27:51   <- v0.223.0
+                 demo-hp  app_start_failed  info     2026-08-23 05:30:14   <- v0.222.0, coerced
+notification_log: demo-hp  app_start_failed  warning  sent  operator  09:27:51
+                 (no customer row)
+```
+
+**Scenario D** — an app stopped out of band, intent `running`:
+
+```
+2026/08/23 05:47:44  [deadapp] check alive: 40 scans since boot, 8 deployed app(s) evaluated, 0 currently down   <- v0.222.0
+2026/08/23 09:34:51  [deadapp] check alive: 20 scans since boot, 8 deployed app(s) evaluated, 1 currently down   <- v0.223.0
+```
+
+Alarm fired **24 seconds** after the `docker compose stop`.
+
+## Three things that had to be re-run, and why that matters
+
+1. **Red-proof 5 passed first time — the mutation was INERT.** Changing `if next <= prev` to
+   `if next < prev` in fillwatch does nothing, because an earlier `if next == prev { continue }` had
+   already removed the equal case. The test was right to pass. Removing the guard outright convicts
+   it. **Check the mutation applied before believing either verdict.**
+2. **Scenario G was silently refused TWICE behind an HTTP 200.** The empty-email wipe guard declines
+   the save and renders an error page — still `200`. The first run had no prefs at all; the second
+   read the email with a single-line grep from a `<input>` that spans **three lines**, got `""`, and
+   was refused again. Both times the before/after hashes matched — *because nothing was saved*, not
+   because nothing changed. Fixed by asserting the refusal banner is **absent**. **A warning beside a
+   success is read as a success.**
+3. **The live Scenario A does NOT prove the customer gate**, and is not claimed to. `demo-hp` has no
+   `customer_notifications` row at all, so the customer leg could not have delivered regardless. The
+   toggle gate is proven by the unit tests, which configure prefs both ways. Stated rather than
+   implied.
+
+## Evidence index (`evidence/`)
+
+| File | What it shows |
+|---|---|
+| `redproof-1-R329-emitter.txt` | severity back to `"warn"` → AST guard names file, line and value |
+| `redproof-2-R386-intent.txt` | intent test reverted → `dead-app banner = []`, the live symptom |
+| `redproof-3-part4-migration.txt` | no-op-save guard removed → the `defaults` case reorders |
+| `redproof-4-R387-ingest.txt` | hub WARN removed → "the hub rewrote a severity and said nothing" |
+| `redproof-5-fillwatch-consequence.txt` | the inert first attempt, and the effective one |
+| `live-01`…`live-04` | Scenario A: stop, controller send, **hub records**, customer-leg control |
+| `live-05-step4-absent-intent-count.txt` | **0 of 8** deployed apps carry an absent intent |
+| `live-07`…`live-09` | Scenario D: out-of-band stop, alarm in 24 s, the heartbeat pair |
+| `live-10`, `live-11` | Scenario C: UI Stop → intent `running`→`stopped`, 0 alarms / 9 scans |
+| `live-12`, `live-13` | Scenario E: intent removed → suppressed **and** the log line names the app |
+| `live-16-scenarioG-roundtrip.txt` | all three attempts, ending byte-identical (`10840f3a…`) |
+| `live-18-golden-bake.txt` | golden 0.223.0 markers, each counted |
+| `live-19-scenarioH-after.txt` | the new hub WARN line, live, with a silent `error` control |
+| `live-06`, `live-14` | full controller-log windows (1041 and 4044 lines), pulled before each revert |
+
+## Observations — noticed, recorded, NOT acted on
+
+1. **The operator cooldown has no app identifier, and it now bites.** PrivateBin's event 4 minutes
+   after BookStack's was logged `suppressed — operator cooldown 1h, key=demo-hp:app_start_failed`. So
+   **only the first app-down per hour e-mails the operator.** This is R-182's known cooldown-key
+   shape; it was harmless while the event was undeliverable and is not any more. Recorded, not fixed.
+2. **The prompt's §6 premise was wrong and is corrected:** the hub's manifest **is** in version
+   control, at `felhom.eu/manifests/hub.yaml:128`, and ArgoCD app `felhom` tracks
+   `admin/felhom.eu.git` path `manifests`. No out-of-git deployment path exists.
+3. **The golden-bake runbook still lacks `pveam update`** — second bake in a row to hit the stale
+   index on the `virgin` snapshot, presenting as `400 … no such template`.
+4. `internal/notify/notifier.go` carries **pre-existing** gofmt drift in a const block, confirmed by
+   stashing this session's work. Not touched (§12).
+
+## Teardown
+
+Nothing provisioned. Every app restarted and confirmed healthy (17 containers). `privatebin`'s
+`app.yaml` restored from its backup and the backup removed; its intent reads `running` again.
+`demo-hp`'s notification settings restored to `enabled_events: null`, no e-mail — the state they were
+in before the drill. The drill VM is powered off, its Gitea token shredded, and `drill.qcow2` reverted
+to `virgin`. **Hub-side: two probe events (`backup_failed`, "R-387 scenario H probe"/"control") were
+POSTed to the live hub for Scenario H and remain as event rows for customer `demo-hp`.** They are
+inert records; named here rather than left for someone to find.

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-00-prestate.txt

@@ -0,0 +1,10 @@
+=== LIVE WALK PRE-STATE (controller v0.223.0) ===
+2026-08-23T09:25:42Z
+gitea.dooplex.hu/admin/felhom-controller:0.223.0 Up About a minute (healthy)
+
+docmost	Up 4 hours (healthy)
+docmost-postgres	Up 4 hours (healthy)
+docmost-redis	Up 4 hours (healthy)
+privatebin	Up 4 hours (healthy)
+bookstack	Up 7 hours (healthy)
+bookstack-db	Up 4 hours (healthy)

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-01-scenarioA-stop.txt

@@ -0,0 +1,6 @@
+=== SCENARIO A — an app's database dies; customer has NOT opted in ===
+waiting out the 90s dead-app boot grace first...
+T0=2026-08-23T09:27:27Z
+2026-08-23T09:27:32Z
+bookstack	Up 7 hours (healthy)
+bookstack-db	Exited (0) 5 seconds ago

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-02-scenarioA-controller-sent.txt

@@ -0,0 +1,4 @@
+-- the CONTROLLER only proves it SENT (quoted for the severity word) --
+2026/08/23 09:27:51 notifier.go:206: [DEBUG] PushEvent: type=app_start_failed severity=warning url=https://hub.felhom.eu/api/v1/event
+2026/08/23 09:27:51 notifier.go:232: [DEBUG] PushEvent: app_start_failed pushed OK (HTTP 200)
+2026/08/23 09:27:51 notifier.go:234: [INFO] Event pushed: app_start_failed (warning) — Telepített alkalmazás nem fut: BookStack

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-03-scenarioA-hub-records.txt

@@ -0,0 +1,14 @@
+=== SCENARIO A — THE HUB'S OWN RECORDS (not the controller's) ===
+
+-- 1. the STORED event: severity as the hub filed it --
+customer_id  event_type        severity  message                                   created_at         
+-----------  ----------------  --------  ----------------------------------------  -------------------
+demo-hp      app_start_failed  warning   Telepített alkalmazás nem fut: BookStack  2026-08-23 09:27:51
+demo-hp      app_start_failed  info      Telepített alkalmazás nem fut: BookStack  2026-08-23 05:30:14
+demo-hp      app_start_failed  info      Telepített alkalmazás nem fut: BookStack  2026-08-22 21:27:18
+demo-hp      app_start_failed  info      Telepített alkalmazás nem fut: Kimai      2026-08-22 14:19:12
+
+-- 2. the NOTIFICATION LOG: which channel actually delivered --
+customer_id  event_type        severity  status  channel   created_at         
+-----------  ----------------  --------  ------  --------  -------------------
+demo-hp      app_start_failed  warning   sent    operator  2026-08-23 09:27:51

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-04-scenarioA-customer-leg-control.txt

@@ -0,0 +1,26 @@
+-- 3. IS THE CUSTOMER LEG EVEN CAPABLE? (or is 'no customer row' true for the wrong reason) --
+Error: in prepare, no such table: notification_prefs
+
+-- the customer leg DOES deliver other event types for this same customer: --
+event_type           severity  status   channel   created_at         
+-------------------  --------  -------  --------  -------------------
+backup_run_failures  error     skipped  customer  2026-08-22 22:20:32
+backup_run_failures  error     skipped  customer  2026-08-22 22:17:44
+backup_run_failures  error     skipped  customer  2026-08-22 21:11:19
+backup_run_failures  error     skipped  customer  2026-08-22 16:06:21
+backup_run_failures  error     skipped  customer  2026-08-21 21:20:36
+
+-- 4. HOW MANY notification rows did app_start_failed EVER produce before today? --
+0 rows before 2026-08-23 09:00
+91 app_start_failed EVENTS stored, all-time
+-- 3b. the customer's own preferences (does app_start_failed appear?) --
+-- 3b. the customer's own preferences (does app_start_failed appear?) --
+-- HONESTY CHECK: demo-hp has NO customer_notifications row at all --
+0 prefs rows for demo-hp
+
+-- why the customer channel logs 'skipped' for other types: --
+event_type           status   reason       
+-------------------  -------  -------------
+backup_run_failures  skipped  operator_only
+backup_run_failures  skipped  operator_only
+backup_run_failures  skipped  operator_only

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-05-step4-absent-intent-count.txt

@@ -0,0 +1,11 @@
+=== STEP 4 — THE ABSENT-INTENT COUNT ON demo-hp (deployed apps only) ===
+  bookstack          running
+  calibre-web        running
+  docmost            running
+  kimai              running
+  opengist           running
+  paperless-ngx      running
+  privatebin         running
+  romm               running
+
+DEPLOYED=8  running=8  stopped=0  ABSENT=0

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-07-scenarioD-stop.txt

@@ -0,0 +1,8 @@
+=== SCENARIO D — an app stopped OUT OF BAND, intent recorded as Running ===
+subject: privatebin (single container, desired_state: running) — R-386's measured-silent case
+desired_state: running
+T0=2026-08-23T09:31:27Z
+2026-08-23T09:31:33Z
+privatebin	Exited (0) 5 seconds ago
+bookstack	Up 7 hours (healthy)
+bookstack-db	Up 10 seconds (healthy)

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-08-scenarioD-verdict.txt

@@ -0,0 +1,6 @@
+-- SCENARIO D verdict (T0=09:31:27Z) --
+2026-08-23T09:32:41Z
+privatebin	Exited (0) About a minute ago
+
+app_start_failed events since T0: 1
+2026/08/23 09:31:51 notifier.go:234: [INFO] Event pushed: app_start_failed (warning) — Telepített alkalmazás nem fut: PrivateBin

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-09-scenarioD-heartbeat.txt

@@ -0,0 +1,17 @@
+-- SCENARIO D: the heartbeat, new beside last session's --
+LAST SESSION (v0.222.0, R-386 open, privatebin stopped out of band):
+  2026/08/23 05:5x  [deadapp] check alive: ... 8 deployed app(s) evaluated, 0 currently down
+  (9 scans, 0 events, 0 banner lines — evidence: DRILL-r384-.../live-18-sec4-verdict.txt)
+
+NOW (v0.223.0):
+2026/08/23 09:34:51 main.go:1731: [INFO] [deadapp] check alive: 20 scans since boot, 8 deployed app(s) evaluated, 1 currently down
+
+THE PAIR, exactly as logged — same box, same fixture (privatebin stopped out of band), same 8 apps:
+  2026/08/23 05:47:44  [deadapp] check alive: 40 scans since boot, 8 deployed app(s) evaluated, 0 currently down   <- v0.222.0
+  2026/08/23 09:34:51  [deadapp] check alive: 20 scans since boot, 8 deployed app(s) evaluated, 1 currently down   <- v0.223.0
+
+-- and the hub's own record for it --
+event_type        severity  status      channel   message                                    created_at         
+----------------  --------  ----------  --------  -----------------------------------------  -------------------
+app_start_failed  warning   suppressed  operator  Telepített alkalmazás nem fut: PrivateBin  2026-08-23 09:31:51
+app_start_failed  warning   sent        operator  Telepített alkalmazás nem fut: BookStack   2026-08-23 09:27:51

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-10-scenarioC-ui-stop.txt

@@ -0,0 +1,11 @@
+=== SCENARIO C — the customer presses Stop in the interface ===
+-- intent BEFORE --
+desired_state: running
+-- restart it first, so the Stop is a real transition --
+{"ok":true,"message":"Stack privatebin start completed"}
+ start=200
+T_STOP=2026-08-23T09:36:13Z
+{"ok":true,"message":"Stack privatebin stop completed"}
+ stop=200
+-- intent AFTER --
+desired_state: stopped

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-11-scenarioC-verdict.txt

@@ -0,0 +1,7 @@
+-- SCENARIO C verdict: 4 minutes past the Stop (T=09:36:13Z), every grace elapsed --
+2026-08-23T09:40:37Z
+
+app_start_failed since the Stop : 0
+deadapp scans since the Stop    : 9
+unknown-intent log lines        : 0
+

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-12-scenarioE-setup.txt

@@ -0,0 +1,7 @@
+=== SCENARIO E — an app with NO recorded intent (the legacy/upgrade population) ===
+demo-hp has ZERO such apps (all 8 read 'running'), so one is CREATED for the measurement:
+the desired_state key is removed from privatebin's app.yaml, exactly as a box upgraded from
+before R-166 would look. Backed up and restored afterwards. No code writer was added.
+desired_state line now: [0 found]
+T0=2026-08-23T09:40:55Z
+Up 30 seconds (healthy)

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-13-scenarioE-verdict.txt

@@ -0,0 +1,11 @@
+-- SCENARIO E verdict --
+2026-08-23T09:51:48Z
+app_start_failed events : 0
+deadapp scans           : 21
+
+-- is privatebin actually being EVALUATED? (a suppression nobody reaches proves nothing) --
+privatebin deployed=True state=stopped
+
+-- waiting for the heartbeat scan (deadAppScans lags the log count by the boot grace) --
+2026/08/23 09:51:56 main.go:1731: [INFO] [deadapp] check alive: 20 scans since boot, 8 deployed app(s) evaluated, 0 currently down
+2026/08/23 09:51:56 main.go:1760: [INFO] [deadapp] 1 stopped app(s) have NO recorded customer intent, so their dead-app alarm is suppressed by the unknown-intent fallback (R-386): privatebin. This closes itself as each app is started or stopped through the interface.

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-15-scenarioG-before.txt

@@ -0,0 +1,4 @@
+=== SCENARIO G — open the settings page and Save, changing NOTHING ===
+-- stored BEFORE --
+/var/lib/felhom/docker/volumes/felhom-controller-data/_data/data/settings.json
+/var/lib/docker/volumes/felhom-controller-data/_data/data/settings.json

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-16-scenarioG-roundtrip.txt

@@ -0,0 +1,46 @@
+=== SCENARIO G — open the settings page and Save, changing NOTHING ===
+-- stored BEFORE (sha256 + value) --
+  enabled_events: null
+  sha256        : 74234e98afe7498fb5daf1f36ac2d78a
+  email set     : False
+
+-- RENDER the page, take exactly what it ticked, POST it back unchanged --
+  render=200
+  ticked boxes  : 10
+  save=200
+
+-- stored AFTER --
+  enabled_events: null
+  sha256        : 74234e98afe7498fb5daf1f36ac2d78a
+=== SCENARIO G — REDONE ===
+First attempt was INCONCLUSIVE and is reported: demo-hp has NO notification prefs, so the
+page rendered the DEFAULTS ticked and the save was refused by the empty-email wipe guard.
+Stored bytes were unchanged — but for the wrong reason. Seeding prefs makes it a real round trip.
+
+  seed=200
+  BEFORE: ["backup_failed", "db_dump_failed", "node_down", "disk_warning", "disk_critical", "expected_backup_missed", "expected_dbdump_missed"]
+  sha   : 10840f3a95bac168f0d7c79760998138
+
+  -- now RENDER and SAVE, changing nothing --
+  render=200
+  ticked: 7  email=
+  save=200
+  AFTER : ["backup_failed", "db_dump_failed", "node_down", "disk_warning", "disk_critical", "expected_backup_missed", "expected_dbdump_missed"]
+  sha   : 10840f3a95bac168f0d7c79760998138
+=== SCENARIO G — THIRD attempt, and the first CONCLUSIVE one ===
+Attempt 2 also refused: the email <input> spans THREE LINES, so a single-line grep read it as
+empty and the wipe guard declined the save — while still answering 200. A warning beside a
+success reads as a success; the sha matching meant NOTHING was saved, not that nothing changed.
+
+  BEFORE: ["backup_failed", "db_dump_failed", "node_down", "disk_warning", "disk_critical", "expected_backup_missed", "expected_dbdump_missed"]
+  sha   : 10840f3a95bac168f0d7c79760998138
+  render=200
+  email read : [drill@felhom.eu]   ticked: 7
+  HTTP=200
+  refusal banner present? : 0  (0 = a REAL save)
+  AFTER : ["backup_failed", "db_dump_failed", "node_down", "disk_warning", "disk_critical", "expected_backup_missed", "expected_dbdump_missed"]
+  sha   : 10840f3a95bac168f0d7c79760998138
+-- restoring demo-hp's notification settings to their pre-drill state (no email, no events) --
+  restore=200
+  enabled_events: null
+  email set     : False

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-17-scenarioH-before.txt

@@ -0,0 +1,6 @@
+=== SCENARIO H — the hub receives an unknown severity ===
+NOTE: the LIVE hub is still v0.106.0 (the manifest bump is not synced yet), so this run is the
+BEFORE picture. It is repeated after the hub deploy.
+
+-- hub version now --
+gitea.dooplex.hu/admin/felhom-hub:0.106.0

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-18-golden-bake.txt

@@ -0,0 +1,11 @@
+=== GOLDEN 0.223.0 — acceptance markers, each counted ===
+docker OK (overlay2   : 1
+including mount point : 2
+upload OK (HTTP 201)  : 1
+excluding (must be 0) : 0
+FATAL     (must be 0) : 0
+  docker OK (overlay2; data-root /var/lib/docker)
+GOLDEN_VERSION=0.223.0
+GOLDEN_SHA256=9eaf39ac39219b42ec9e6cbf890275febcdcc6f53325fe0c0f591d3431044f17
+-- round trip from the published URL --
+  ranged GET http=206

documentation/audits/DRILL-r329-r386-2026-08-23/evidence/live-19-scenarioH-after.txt

@@ -0,0 +1,9 @@
+=== SCENARIO H — LIVE hub v0.107.0, bad severity ===
+  api key length: 64
+  POST /event (severity=warn) http=200
+  POST /event (severity=error, control) http=200
+
+-- THE NEW LINE in the hub's own log --
+2026/08/23 11:59:07 [WARN] [api] Event from demo-hp: severity "warn" is not in {info,warning,error,critical} — coercing to "info", which severityNotifies DROPS, so this backup_failed alert will reach NOBODY. Fix the emitting controller; this event is stored but not routed.
+2026/08/23 11:59:07 [INFO] Event from demo-hp: backup_failed (info) — R-387 scenario H probe
+2026/08/23 11:59:07 [INFO] Event from demo-hp: backup_failed (error) — R-387 scenario H control