Files
felhom.eu/REPORT-session-c.md
T
admin 06d7788392 Session C: R-113/R-114/R-112 PROVEN LIVE; C5 fails on a new defect (R-116)
Full ISO/PAIRING run on a fresh nested box. Agent 0.114.0 came from the Day-0
manifest -- the SHIPPED binary -- so C5 tested the real artifact. Controller
0.186.0 hand-deployed after install per the §3.1 ruling; the vouched golden
bakes 0.185.1, so C3/C4 prove the code not the shipped golden, and that lag is
filed against R-115 rather than a new ID.

R-113 PROVEN: detach 18:43:50, gate fired 18:43:54 -- four seconds, where E-2d
measured zero over 4.5 minutes -- and SetDisconnected was reached. It fired on
exactly the shape that defeated it: raw /mnt/mentes NOT mounted while the bind
/mnt/felhom-drives/mentes still read /dev/sdb[/felhom-data].

R-114 PROVEN: with the target absent the page rendered the absent copy, the
system-disk copy 0 and the offer block 0. Both of E-2d's falsehoods are gone.

R-112 PROVEN: the banner reached a customer's page for the first time. Healthy
renders nothing, proven POSITIVELY -- idle delta 0 /backup/tiers calls, page
load delta +1, single caller, so the seam ran and chose silence.

C5 FAILED on a fourth, separate defect. The alarm fires but as the GENERIC
storage_disconnected, while the recovery is the SPECIFIC backup_target_restored
-- a pair an operator cannot match, which is what notifyDriveReturned's own
comment forbids. backup_target_absent count 0 across the run. Root cause: the
drive is TWO /disks rows and BackupTarget and GuestPath sit on different ones;
absent they separate, on return they rejoin. v0.184.1 fixed the keying, not
this. Only reachable because R-113 made the gate fire at all. Filed as R-116.

Mirror + over-correction guard PASS: non-target drive -> storage_disconnected,
backup_target_absent 0; both drives present -> 0 ABSENT lines and the target
stayed healthy. Caveat recorded: the mirror passes trivially because the target
also produced the generic event.

E-2 and E-2d CLOSED as partially proven with R-116 the one named open leg, per
the runbook's §9 rule decided in advance rather than mid-run.

Capability map NOT touched: it has no E-2 rows at all, so nothing could move to
PROVEN-LIVE. Creating them is a design act, not a validation act.

Teardown clean: pvesm status after == before (local-lvm 38.78%), guest 9201 and
drill-r50 untouched. Customer delete attempted and correctly refused while the
host still reads ONLINE; command recorded for once it ages to DOWN.
2026-07-29 20:55:48 +02:00

4.9 KiB

REPORT — Session C: R-113, R-114, R-112 proven on a real box; C5 fails on a new defect (2026-07-29)

RUNBOOK-session-c-2026-07-29.md. Full evidence: documentation/audits/SESSION-C-2026-07-29.md. Root REPORT.md untouched.

Verdicts

Claim Fix Verdict
C4 — offer appears and moves the target R-112 PASS
C3 — absent target tells the truth, offers nothing R-114 PASS
C5backup_target_absent + backup_target_restored R-113 FAIL — generic alarm, specific recovery → R-116

All three shipped fixes work. R-113's gate fires in 4 seconds (E-2d measured zero over 4½ minutes). R-114's message is correct. R-112's banner reaches the customer. C5 fails on a fourth, separate defect that was unreachable until R-113 made the gate fire at all.

What the drill box ran

Agent 0.114.0 from the Day-0 manifest — the shipped binary, so C5 tested the real artifact and closed R-115's observation 1 for R-113. Controller 0.186.0 hand-deployed after install (§3.1 ruling (a)); the vouched golden bakes 0.185.1, so C3/C4 prove the code, not the shipped golden — that lag is filed against R-115, not a new ID.

The three headline observables

R-113 — detach at 18:43:50, gate at 18:43:54, on exactly the shape that defeated it before:

raw   /mnt/mentes               : NOT mounted
bind  /mnt/felhom-drives/mentes : /dev/sdb[/felhom-data]   <- the stale bind SURVIVED

R-114 — with the target absent: absent copy 1, system-disk copy 0, offer block 0. Both of E-2d's falsehoods gone.

R-112 — banner element 1 and the never-configured copy in the HTML; after the wizard, the offer with data-path="/mnt/felhom-drives/mentes". Healthy renders nothing, proven positively: idle delta 0 /backup/tiers calls, page-load delta +1, single caller ⇒ the seam ran and chose silence.

Decline path proven (registration confers no role), restart_required:true, agent did not self-restart, in-flight check recorded before I restarted it, wrapper created the storage at the drive's own mountpoint.

C5's failure

absent : Event pushed: storage_disconnected (error)      <- GENERIC
return : Event pushed: backup_target_restored (info)     <- SPECIFIC

backup_target_absent count 0 across the whole run. The alarm and its recovery cannot be matched — precisely what notifyDriveReturned's own comment forbids.

Root cause (R-116): driveTargetByPath builds out[GuestPath] = d.BackupTarget, but the drive is two /disks rows and the flag and the guest path sit on different ones — the felhom-backup storage row carries BackupTarget: true and gets a guest path only while classified user-data; the registry union row carries the guest path and never assigns BackupTarget. Absent ⇒ they separate ⇒ generic. Return ⇒ they rejoin ⇒ specific. v0.184.1 fixed the keying, not this.

Mirror + over-correction guard — PASS, with a caveat

Non-target drive detached ⇒ storage_disconnected, backup_target_absent count 0. Over-correction guard passes: both drives present ⇒ 0 ABSENT lines, target stayed healthy — R-113's stricter presence did not make a healthy drive read absent. Caveat: the mirror passes trivially, because the target also produced the generic event; it confirms no over-correction but cannot confirm discrimination.

Record

  • OPEN-ITEMS.mdR-113, R-114, R-112 → SHIPPED + PROVEN-LIVE; R-116 opened (READY (S), P1); E-2 and E-2d CLOSED as partially proven with R-116 as the one named open leg, per the runbook's §9 decided-in-advance rule.
  • ROADMAP.md — R-116 under P1.
  • Capability map NOT touched — it still has no E-2 / backup-target rows at all, so no row could be moved to PROVEN-LIVE. Creating them is a design act, not a validation act. Third session running that this has been noted.

Teardown

VM destroyed, storage removed, pvesm status after == before (local-lvm 38.78 %), guest 9201 and drill-r50 untouched. Customer ruling: DELETE; attempted and correctly refused (host … is ONLINE) — deletable once the destroyed host ages to DOWN (>1 h), command recorded in OPEN-ITEMS.md.

What did not happen

backup_target_absent never fired, so its severity, Hungarian copy and hub routing remain unexercised — R-116 blocks them. The offer was accepted via the endpoint the button POSTs, not a browser click (no browser automation on DooPlex); the rendered control and its non-auto-submission were verified in HTML. The stale bind still naming a dead device node after return was observed, not investigated.

The arc

E-2 ends here. Its stated definition of done is R-106 + R-109, R-108 and D5 — none of which this detour touched. The detour was worth taking: it found six real defects (R-111 through R-116), four of them customer-affecting, none of which any unit suite had caught.