Files
felhom.eu/documentation/audits
admin 315c469fc8 docs(R-116): v0.116.0 proven live at the payload layer; events leg blocked on an emailed claim code
audits/R116-v0116-2026-07-30.md + the R-116 register row.

WHAT PASSED, on real hardware. Agent 0.116.0 published (independent registry GET
verified the bytes), vouched, and installed UNAIDED by a fresh box -- "Artifact
manifest served for customer sess-e (agent=0.116.0 golden=0.185.1)", host
sess-e-5d4427 ... 0.116.0 ONLINE. Real day-0 on a nested PVE on demo-hp (per
runbooks/target-selection.md, which sent this run there rather than to the DooPlex
fixture the previous run used), both drives enrolled through the real endpoints,
device loss a real hot-detach.

Captured live, absent state: the target is now ONE row carrying backup_target:true
AND guest_path:/mnt/felhom-drives/cel with mount_path:"", so
isTarget[/mnt/felhom-drives/cel] = TRUE -- it was false through v0.115.0. RETURNED
gives true as well, so the pair matches. All three guards pass from the same
payload: R-114 preserved (no row combines the flag with a non-empty mount_path),
no over-correction (bound_under_parent:false), and discrimination at the payload
layer (the non-target carries the flag on no row) -- the thing neither prior run
could show.

WHAT DID NOT HAPPEN, and is not claimed. No backup_target_absent or
backup_target_restored event was observed on the wire. planDriveGates iterates
registered StoragePaths and the drill controller has none ([WARN] Storage paths:
no storage paths registered); every storage route answers 401 "dashboard not yet
claimed". The claim code is bcrypt-hashed and emailed-only, and
handleSelfBindLinkSend (selfbind_mint.go:139-161) renders a flash and never the
token, so no operator-side route exists. A gen-2 code was re-sent; the drill VM,
its storage and customer sess-e are DELIBERATELY RETAINED with teardown commands
recorded, so the leg finishes without a rebuild. Reported as not-reached rather
than as a third trivial pass.

R-119 filed: the claim gate makes drive-gate legs unreachable to CC by design, and
has now stopped three sessions at the same wall -- needs a ruling (operator-scoped
test affordance, or a documented prerequisite step), not a fix.

R-117 reproduced on real hardware with a read/write probe (EIO both directions
while /disks reports attached + bound_under_parent:true) and §5 records how it
colours the reattach leg. R-118's symptom vanishes incidentally on this one row;
R-118 is NOT fixed.

sess-c and sess-d verified GONE (404, absent from both tables) -- cleared by the
operator using the previously recorded commands, not by this session.
2026-07-30 09:13:00 +02:00
..
@
2026-07-14 00:45:20 +02:00
@
2026-07-14 10:12:21 +02:00
@
2026-07-14 12:17:26 +02:00
@
2026-07-14 12:17:26 +02:00