Asked Campaign 11 Phase 1's question a second time, on the fixed build, on a
NEW appliance (VM 322, customer rewalk). The Campaign 11 venue was untouched.
THE DATA: PASS. All three sentinels byte-identical out of the pre-destruction
snapshot a7bc23bd in 23s through the customer's own restore flow — including a
12 MB binary and an accented Hungarian filename whose NAME BYTES are identical
too (verified as hex, not as rendered text).
THE JOURNEY: FAIL, two dead ends against Phase 1's four.
1. R-218's CONSUME half. The hub re-staged the credential at 11:44:57 saying
'the box re-consumes on its next cycle'; a full cycle ran at 11:55:46/54
(with a positive control that it ran) and it did not. A census of the
customer-reachable actions found none that fetches it. Only a command line
INSIDE THE GUEST moved it — 18s, confirming nothing was wrong with the
credential, target or key: only the trigger. R-218's row said SHIPPED and
over-claimed; it is corrected to REOPENED for the consume half.
2. R-220. Drives still unenrollable after a rebuild, needing a Proxmox-host
unmount; without it no app redeploys and the restore page stays empty.
Unaided RTO STILL UNDEFINED. Attended: +45s key placed, +24m12s tier up,
+30m13s data verified. The 30m must not be quoted as the customer number.
What passed and is new: the recovery screen appeared WITHOUT being sought,
answered all three questions with a seal date matching the hub exactly, the
emailed reset code worked first try, the unlock was a real 1.528s unseal, and
R-225's fix was seen working in the wild (unknown, not a false zero).
R-216 part 4 reproduced live: the reinstall downgraded the hand-installed agent
0.126.0 -> 0.125.0.
DELIVERY GAP recorded as owed and NOT conflated with the journey: a fresh
install landed on controller 0.201.0 / agent 0.125.0 — the vouched versions,
neither carrying the fixes — installed by hand. Nothing was vouched.
Capability map row STAYS FAIL. Campaign 11 doc gets a dated ADDENDUM, not a
rewrite.
Five closed in controller v0.202.0 + agent v0.126.0, each with its live or
red-proof evidence in the row. Five explicitly still open and named as such
rather than left to inference: R-214, R-220, R-221, R-213, R-202 — and R-220 is
flagged as currently worked around BY HAND on the campaign venue, which is the
only reason an app could be deployed there.
The capability map's recovery row STAYS FAIL and says why: fixes are not a
re-walk, nothing walked a customer end to end, and the customer-facing messages
were NOT re-driven live because /recovery correctly retires itself once the old
data is set aside — restoring that state is the reconfiguration the task forbade.
The campaign document is ANNOTATED, not rewritten: it records what was true when
it ran, and that is its value.
workspace-CLAUDE.md gains comment-vs-code entry 9 — the escrow header said the
errors were 'DISTINCT on purpose' and named THREE situations while a fourth was
folded into one of them, and a green test named the defect and did not prevent
it because it asserted a STRING one layer below the merge.
ROADMAP needed no collapse — it carries no rows for these IDs.
The recovery codes are shredded with the plant->find->shred->fail-to-find
control the brief asks for, and 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. Without it, a
'codes shredded' claim would have been false. That key was removed from the
shared file with a verified diff (every other line identical, nine keys intact)
and HUB_PW re-tested at hub:200.
Consequence stated plainly rather than left to be discovered:
/home/felhom-repo.orphaned-20260805 (12 535 KB, the three Phase 0 sentinels) is
now permanently unopenable — which is what the set-aside screen promises, and
teardown removes it anyway.
Venue left WORKING and said so: ONLINE, 4 containers healthy, backup target not
degraded, off-site on 2 snapshots. Two things a future session needs: the raw
/mnt/{adatok,mentes} mounts are deliberately left unmounted (R-220's
workaround), and the appliance root credential was shredded — re-fetch it from
the hub.
REPORT-campaign11-phase24.md rather than REPORT.md, per the repo's
parallel-session rule.
No product code changed. No version bumped.
All five daily jobs fired exactly once and completed on time. The 04:15 offsite
run produced snapshot_count 1 -> 2, last_status ok, 24.9s — unprompted, on a box
rebuilt twice and set aside four hours earlier. Nothing on the must-not list
fired, including offsiteheal: that is R-218's NEGATIVE control passing (a box
with a target must not declare), which does not substitute for its positive
half, still owed.
Investigated and DISPROVED: tier2-backup completing in 118ms looked like a
silent no-op; the copy is real and on the backup drive (818.5 KB verified).
Correction to my own pre-registration: backup_run_digest is a TEST FILENAME, not
an event type. 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 I invented. What survives: the offsite run emits no hub event while both
lesser tiers announce success; failures and staleness are covered elsewhere, so
it is a consistency wrinkle, recorded not filed.
Two absences answered rather than assumed: the restore-test's silence was
PRE-REGISTERED as correct (6h eval, 24h settle); the agent's whole-guest tier is
left explicitly UNRESOLVED because routine local-api calls are not logged at INFO
— a 5h search returns 0 on a box that demonstrably served such calls, so the
instrument cannot answer.
No product code changed.
Invariants across the phase boundaries: I1/I4(product)/I5/I7 held; I3 breached
twice (R-227's raw Bad Gateway, and R-220's refusal naming an impossible
action, reproduced live a third time); I6 breached twice (R-224, R-225). I2 is
recorded as untested rather than passed, because F10 could not be injected.
I4 was breached by the HARNESS, not the product — sourcing ~/.config/credentials
echoed two demo-box recovery codes into the transcript.
RTO unchanged and explicitly not re-measured: Phase 2's faults are not a
re-walk. Phase 1's 61 attended minutes stand; the unaided number stays
undefined.
Teardown recorded as OWED with all three layers named plus the off-site side —
including that the campaign's sub-account now holds TWO repos, the fresh one
and the 12 535 KB set-aside history, and that demo-felhom/demo-hp namespaces on
ep0 must not be touched.
The move-aside is correct and verified byte-for-byte; what follows it is not.
settings.json records orphaned_renamed_to and OrphanedRenamedTo has zero
references in any template or handler — 12.5 MB of deliberately retained
customer data at a path the box knows and never shows. Fifth instance of the
project's seam-built-but-never-wired pattern.
Campaign document gains the F7/F9/F10/F11 write-ups: F7 split (set-aside PASS,
afterwards FAIL), F9 partial (R-215's gate proven live on a narrower shape),
F10 NOT INJECTED (harness — three self-healing attempts), F11 PASS.
No product code changed.
Phase 2 (eleven injected faults) and the §4 positives that were owed.
- §4.1 MEASURED, twice: the box's rendered GetFloor() is 0.200.0, and a
cold-started controller logs "settle-gate: GO — at/above floor 0.200.0"
against the same line reading "floor still unknown" while the hold was in
force. Also corrects the brief's plan: SetFloor's line is u.dbg(), gated on
logging.level=debug and written to the logger, so it can NEVER reach the
debug ring — a restart alone would not have produced it.
- §4.2 still NOT measured, deliberately: the venue has an off-site target, so
needsOffsiteCredential correctly returns false. Recorded, not inferred from
the unit test.
- F1 PARTIAL, F2 PASS, F3 FAIL, F4 FAIL, F5 PASS, F6 PASS, F8 PARTIAL.
F3+F4: a hub outage and a stopped agent are both rendered as "this code does
not open your package", in 0.056 s and 0.030 s — no unseal attempted. The
agent's own err field distinguishes them exactly and it is discarded at the
HTTP boundary; the R-216 capability gate answers source=version and cannot
see reachability.
- R-217's fix HOLDS under exactly its fault (F5), verified with the false-claim
strings absent and accented positive controls present.
hub/CHANGELOG.md: v0.97.1 had no heading of its own — the change was written
into the v0.97.0 entry while the deployed tag is 0.97.1. Given its own entry,
marked as added retroactively. Second occurrence of the class (agent 0.90.1).
Evidence: documentation/tests/campaign11-evidence-2026-08-05/journal-phase24.md
No product code changed.
admin