Phase A passed every gate on a fresh box built from the PUBLISHED ISO 1.26.1: install, claim, two drives enrolled through the real endpoints with the backup target healthy, four apps spanning both sides of D5's secret split, and a working discriminator across all four. Isolation gate: both denials captured, each with a positive control. The PBS control FAILED first — four clean-looking 403s were worthless because the token was denied on its own datastore too (PBS token privilege separation). Fixed and re-run; the denials stand. R-156 (new, register grepped): papra's data is neither persisted nor backed up, and it reports healthy. The template mounts papra_data:/app/data; the app writes /app/app-data/db/db.sqlite. Volume empty and root-owned against a -rootless image, real DB in the container writable layer, healthcheck only probes the HTTP port. Its Tier-1/2 backup is real, verifiable and contains nothing. Not fixed. Tier 3 could not be isolated so it was not run: offsite hard-requires the DR tier (configs.go:1300) and the DR tier only provisions on ep0 (per-endpoint allocation deferred, hub/README.md:260). Both are recorded deliberate positions, so no R-n minted. The campaign touched neither ep0 nor the Storage Box. Phase B did not start. Phase A was budgeted at ~1h and took ~5.5h (1.26.1 is a public release image with no auto-install path, so the install was a blind screendump+sendkey walk). That left the runner — which judges eleven invariants and fires destructive atoms unattended — to be written at 04:00 with ~3h of night left. Stopped on the brief's own fence: a rig producing false negatives is worse than no rig. The rig is built and idle; teardown is OWED and itemised, including hub customer c10-soak (disposition: DELETE).
4.1 KiB
REPORT — Campaign 10, two-storage adversarial soak (2026-07-31)
Follows REPORT-campaign7/8/9.md. Root REPORT.md is another session's (hub v0.85.0) and was not
clobbered — same shared-clone reasoning as REPORT-iso-release.md.
Full audit + evidence: documentation/audits/CAMPAIGN-10-two-storage-soak-2026-07-31.md,
documentation/tests/campaign10-evidence-2026-07-31/.
The sentence that matters
Phase A is complete and every gate passed. Phase B did not run. The rig is built, fenced and idle, waiting for a runner that should not be written at 04:00.
What was established
- Venue — VM 311 on demo-hp (Tier 0), 200 G system + 2 × 50 G data, scratch storage at the
/mnt/nvme-1tbmount root (a subdirectory would have emittedstorage_disconnectedfor demo-hp all night — the exact signal I1/I2 discriminate). - Baselines, all read fresh. controller
main0.188.0, golden 0.188.0 (not behind), agent 0.119.0 published+vouched, hub 0.86.0, ISO 1.26.1 (f3cc86d5…, round-trip verified live). The brief's ISO assumption (v1.25.0) was ~90 minutes stale; its "no baked SSH key" claim is R-129. - Isolation gate — both denials captured, each with a positive control. The PBS control failed first: four clean-looking 403s were worthless because the token was denied on its own datastore too (PBS token privilege separation). Fixed, re-run, denials stand.
- A1 fresh install from the published ISO. 1.26.1 is a public release image — verified against
its bytes that it has no auto-install path — so it was driven blind via screendump +
sendkeythrough the Terminal UI. Caught the Hungarian-keymap trap before typing the root password, which would otherwise have been mangled and locked the box out. - A2 claimed for real; discriminator flipped
dashboard not yet claimed→authentication required. - A3 both drives enrolled through the real endpoint;
mentesaccepted as backup target via the offer flow, endingdegraded:false / target:felhom-backup— the I5/I6 healthy baseline. Four apps healthy spanning both sides of D5's split (4 ×type: secret, 1 ×type: password). - A4 discriminators seed and read back across all four apps; rallly's over the path
DATABASE_URLactually names, not the trusted socket that produced D5's false pass.
Findings
- R-156 (new) — papra's data is neither persisted nor backed up, and it reports healthy. The
template mounts
papra_data:/app/data; the app writes/app/app-data/db/db.sqlite. The volume is empty and root-owned (the image is-rootless, so the app cannot even write there), the real DB sits in the container's writable layer, and the healthcheck only probes the HTTP port. Its Tier-1/Tier-2 backup is real, verifiable, and contains nothing. Not fixed. - Tier 3 could not be isolated, so it was not run. Offsite hard-requires the DR tier
(
configs.go:1300), and the DR tier only provisions on ep0 (per-endpoint allocation deferred,hub/README.md:260). Both are recorded deliberate positions, so no R-n minted. The campaign therefore touched neither ep0 nor the Storage Box — stronger isolation than asked for, obtained by not running the tier. Cost: all Tier-3 atoms, I8, and the Tier-3 RTO/RPO rows.
What did not run
Every B1 atom, I1–I11 across cycles, RTO/RPO, and A5's budget/watchdog. Phase A was budgeted at ~1 h and took ~5.5 h — the blind interactive install alone was ~1.5 h. That left the runner, the component that judges eleven invariants and fires destructive atoms unattended, to be written at 04:00 with ~3 h of night left. Stopped instead, on the brief's own fence: a test rig producing false negatives is worse than no rig.
Teardown — OWED, nothing removed
Deliberately intact so Phase B need not repeat Phase A. VM 311, c10-scratch, PBS datastore
felhom-c10 + user/token, restic subaccount u629488-sub4, and hub customer c10-soak (disposition:
DELETE) are all outstanding, with commands in the audit §9. Named explicitly because R-131 is four
orphaned scratch customers left by exactly this omission.