12 KiB
CAMPAIGN-6D — supervised acceptance of the backup-classification redesign (2026-07-15)
Operator: Viktor (present, async rulings). Driver: Claude Code (live box). Validator: project Claude.
Redesign under test: 3-core ComputeCaptureSet/ComputeFabBuckets (v0.133.0), 3a offsite engine +
restore + placement (v0.134.x, hub v0.55.0), 3b tier-2 v2 + NAS exclusion (v0.135.0), Task 4 .fab
exclusion scoping (v0.136.0). Baselines: ctrl 0.136.0, agent 0.88.0 (published), hub 0.55.0,
golden 0.136.0 (baked+published this day). Evidence sink: 180:~/campaign6/6D/evidence/.
Headline verdict
The redesign's core promise is GREEN. Both gating legs PASS on real data:
- Accept #1 (
.fab≥1 GiB full circle) — PASS. A 1.7 GB immich.fab(1.06 GiB mandatory tar) round-trips byte-identically through a destructive compose-down-volumes re-import; the DB restores, the app boots clean, assets resolve, and zero sibling contamination (the SQ6 fix) is proven on a genuinely shared userdata root. - SQ3 immich offsite (broken-not-empty) — PASS. immich's offsite snapshot carries unit + mandatory
appdata/immich(not the:rooptional library); a destructive restore-to-live from offsite alone makes immich functional (thumbnail and full-res original resolve), mandatory tree byte-identical.
⇒ The friend-alpha core-promise gate is GREEN. (Remaining friend-alpha prerequisites: the deferred phases below — none block the core promise.)
1. Pre-flight gate (G0–G7)
| Gate | Result | Note |
|---|---|---|
| G0 baselines | 🟢 | ctrl 0.136.0 live, hub 0.55.0, agent 0.88.0 published |
| G1 images settled | 🟢 | ctrl image + golden 0.136.0 + agent 0.88.0 all pushed to gitea today |
| G2 guest health | 🟢 | felhom-controller:0.136.0 Up (healthy), "Controller elindult (0.136.0)" |
| G3 credential | 🟢 | proven: login POST 302 → GET /backups 200 (authed) |
| G4 customer email | 🟢 | restored to nagyfenyvesi.viktor@gmail.com via the real notifications form (P3-DELIVERY) — regression-proofs the empty-form wipe bug |
| G5 storage headroom | 🟢 | 176 G local + 868/108 G on drives |
| G6 evidence sink | 🟢 | 180:~/campaign6/6D/evidence/ |
| G7 clean box | 🟠 | campaign6 = orphaned host autofs (no systemd unit; needs a host reboot to clear; NOT a registered target → empirically inert in P-REG). teszt_enroll kept (ruling). |
2. Per-phase results
| Phase | Result | One-line evidence |
|---|---|---|
| P-REG F-6C-1 nightly | PASS | Fresh tier-2: calibre-web (NAS data) → local teszt_enroll, NAS skipped, exit 0, v2 tree; crossdrive_failed=0 in the persistent ring. |
| P-FAB Accept #1 (⚠) | PASS | 1.7 GB .fab (1.06 GiB mandatory); userdata.tar=2 KB (no siblings); DB captured; destructive re-import → immich boots, 90 photos + thumbnail resolve; mandatory byte-identical (only immich boot-markers differ). |
| P-TIER2 v2 deep | PARTIAL | Core proven in P-REG (v2 tree .felhom-tier2-layout=2, recovery-unit + userdata leg, másik adatmeghajtó). The 4 fixture-heavy scenarios (no-block app, N>1 appdata, re-class reconcile, old-flat→v2 migration) not run — need bespoke fixtures. Source guards present. |
| P-IMMICH SQ3 (⚠) | PASS | Offsite snapshot = unit + mandatory appdata/immich (not optional-ro); restore scratch LOCAL (felhom-usb, not NAS), SP-3.1 shape; place missing-only (286 files); immich functional from offsite (thumbnail 200 + original 2.07 MB 200); mandatory byte-identical. |
| P-PLACE F-3a-1..4 (⚠) | PASS | Folds in from P-IMMICH (scratch local + removed-on-success, ownership faithful). Negative: place refused with ZERO copies on no-prepared-restore. F-3a-1a/1b/4 present in source + unit-tested. |
| P3-BROWSER | PASS | Escrow typed-back ceremony completed (Viktor-driven; new code claimed → escrow_state=escrowed) — closes the long-pending supervised wizard pass. Cross-tab session shared. Hub 8-tab ring all load; live-refresh on Overview/Applications/Events/Host; dirty-form suppression via Auto-refresh "(paused)" on static/Edit tabs. Notifications tab corroborates P3-DELIVERY (OPERATOR+CUSTOMER emails SENT). Secrets not captured; recording discarded. (Deferred: session-expiry/logout re-auth.) |
| P3-DELIVERY enlarge-block | PASS | G4 email restored via real form; a 51 GiB sparse mandatory fixture tripped the gate at the real 50 GiB quota → immich enlargement blocked, unit-only push continues, run OK, EnlargedBlocked=["immich"], notifier edge-fires ONCE, both operator + customer ("Kedves Ügyfél!") emails delivered. Reverted (fixture removed, blocked-state cleared, quota untouched). |
| P4-DEEP deep tiers | PARTIAL | Snapshot coherence PASS (calibre-web + immich snapshot paths == capture set, excludes excluded/optional-ro). F7 timed-cut / restic self-heal-mid-run / restore-to-verify-compare not run (timing-sensitive). |
| P5-REST real crash (⚠) | PASS | SIGKILL host-PID mid-offbox → auto-restart ~15 s; journal marked interrupted run failed (no false success); all apps stayed up; post-crash offbox run clean (no stale lock, no marker-without-legs). |
| P-DAY0 golden provision | CORE PASS | Fresh nested PVE (qm 300 ← pre-day0-clean) → installer v1.16.0 fetched + sha-verified agent 0.88.0 (9c8daf94…) + golden 0.136.0 (e4b27fee…) vs the hub manifest → "Day-0 provision SUCCESS vmid=9201 host_id=demo-vm-felhom-2f4b00" → controller 0.136.0 Up (healthy), guest at-floor, scoped ACL, all installer fixes shipped (age/pbs-apply/guarded wrappers), root@pam rotated+vaulted. Snapshot post_day0_golden136. Deferred (agent-side, proven 07-12, not golden-specific): escrow auto-confirm (correctly PENDING — fresh repo password vs hub's stale blob; ceremony needs the DR/PBS/WG chain) + offsite round-trip (guest claimed → needs the dashboard password; the 0.136.0 offsite engine itself is already proven on the demo in P-IMMICH/P3-DELIVERY). |
| P-DAY0-DEEP escrow+offsite on drill guest | BLOCKED | Legs E (escrow ceremony) + O (offsite round-trip) could not run: the drill guest's PBS-DR chain never configured (see the MED/HIGH finding). Viktor's re-register unblock proved not cleanly achievable (reinforces the finding). Per §5 the friend-alpha provisioning gate reverts to "supervise alpha #1's escrow ceremony LIVE" (normal customer-holds-R flow). Custody note: the authorized drill deviation (CC-held R) was never exercised — no R minted/claimed; the real friend-alpha escrow runs the normal customer-holds-R supervised flow. This drill would have proved the mechanism, not a new custody model. |
| P-OBS aggregate-state | NOT REPRODUCED | No Exited(0) container present on the box → the cosmetic condition is absent right now. Observation-only. |
3. Findings (ranked)
- MED/HIGH — day-0 PBS-DR chain has no self-heal (P-DAY0-DEEP). On a fresh appliance provision the
agent's PBS-DR consume fires at install before the WG tunnel is established →
fingerprint probe dial 10.77.0.1:8007: i/o timeout, consumes nothing. Once the tunnel is up (it is: handshake fresh, :8007 OPEN) the agent does NOT re-request thepbs_drdescriptor — it idles "no-op until a descriptor arrives" and the one-shot descriptor's window has closed. On a re-provision with a reused WG peer, the hub's auto-provision-on-registration never re-fires, so the descriptor is never re-pushed at all. There is no operational re-trigger (hub UI has no per-peer delete; agent doesn't self-re-register). Net: a fresh customer whose WG handshake is slow at install lands with PBS-DR unconfigured → escrow ceremony cannot run → auto-confirm stays pending → offsite never activates, with no self-heal. Follow-up TASK: bridge-side re-request of the descriptor once the WG peer is confirmed up (+ re-issue on reused-peer re-provision). Recorded, not fixed inline (§13). - LOW — duplicate recovery units. offbox logs: "immich: multiple recovery units found, using newest (…felhom-usb…); ignoring: …felhom-flash…" (same for audiobookshelf). Controller handles it (uses newest), but a stale duplicate unit lingers on a second drive. Track: cleanup of superseded per-app recovery units. No follow-up TASK required (cosmetic/no data risk).
- LOW — G7 orphaned autofs (campaign6). A
/mnt/felhom-drives/campaign6autofs mount with no backing systemd unit persists; cannot be cleared without a host reboot. Not a registered target (inert). Track: clear on next demo-host reboot. No follow-up TASK required (track-only; operator-reboot clears it — HUMAN action, not code). - No HIGH/MED correctness findings surfaced. No inline fixes made (RUNBOOK §13).
4. Headline verdict → friend-alpha
Core promise (SQ3 immich + Accept #1) GREEN, and the customer-facing enlarge-block delivery chain (P3-DELIVERY) now PASSES — the "Kedves Ügyfél!" email is proven end-to-end. Friend-alpha's backup-safety
- customer-notification gates are satisfied on real data, and the P3-BROWSER planes (escrow typed-back ceremony completed, hub 8-tab ring, cross-tab session) now PASS. P-DAY0 CORE also PASSES — golden 0.136.0 + agent 0.88.0 provision a fresh box to a healthy controller 0.136.0 (the friend-alpha provisioning dress-rehearsal). One caveat surfaced by P-DAY0-DEEP: the fresh-provision PBS-DR chain did not self-complete (MED/HIGH finding — install-race + no self-heal), so alpha #1's escrow ceremony must be supervised live until the self-heal follow-up lands. Also remaining (nice-to-have): P-TIER2-deep / P4-timing coverage.
5. Evidence index → 180:~/campaign6/6D/evidence/
00-preflight-gate.md, 01-P-REG.md, 02-box-state-reality.md, 03-immich-prestate.manifest,
04-P-FAB-export.md, 05-P-FAB-byteidentical-diff.txt, 06-P-FAB-import.md, 07-P-IMMICH-offsite.md,
08-P-IMMICH-restore-diff.txt, 09-P-IMMICH-restore.md, 10-P-PLACE.md, 11-P5-REST.md,
12-P4-DEEP-coherence.md, 13-P3-DELIVERY.md, 14-P3-BROWSER.md, 15-P-DAY0-install.md,
16-P-DAY0-escrow-BLOCKED.md.
6. Box / morning-recovery state
- immich is now DEPLOYED on the demo (4 containers, 90 fixture photos, admin
admin@demo-felhom.eu, offbox-included). Left running as a legitimate demo app / reusable fixture — not torn down. The prior "immich nincs telepítve" offbox warning is resolved. - Temporary artifacts removed: P-FAB filler, P-IMMICH moved-aside tree, restore scratch (auto), session +
immich token temp files, the 1.7 GB
.fabbundle, the generated-photos tars, the P3 sparse fixture. - G4 email is now SET (notifications.email = nagyfenyvesi.viktor@gmail.com) — a deliberate, kept restore of the wiped value.
- A NEW recovery (escrow) code was generated during P3-BROWSER (Viktor holds it off-server; the prior code is invalidated for FUTURE backups, existing history stays valid with the old code). escrow_state = escrowed. CC never saw/stored the code.
- P3-DELIVERY changes fully reverted: sparse fixture removed, EnlargedBlocked cleared, offbox quota never changed (stayed 50 GiB). teszt_enroll kept (ruling). campaign6 orphaned mount remains (findings).
7. Outstanding queue
- P-TIER2 deep 4 scenarios + P4-DEEP timing sub-tests (F7 cut / restic self-heal / restore-verify).
- P-DAY0-DEEP (BLOCKED → follow-up TASK): PBS-DR self-heal (bridge re-requests the
pbs_drdescriptor once the WG peer is up; re-issue on reused-peer re-provision) — see the MED/HIGH finding. Until then, friend-alpha alpha #1's escrow ceremony must be supervised live (normal customer-holds-R flow). - P-DAY0 teardown: drill VM qm 300 left provisioned + healthy (snapshot post_day0_golden136); stale + new hub host records for demo-vm-felhom to delete; root@pam rotated+vaulted.
- Minor P3-BROWSER remainder: session-expiry/logout re-auth pass.
- Signed-update train (publish agent/golden to production customers) + Peti's box — out of 6D scope.
- LOW: duplicate recovery-unit cleanup; campaign6 autofs (host reboot).