felhom-agent/REPORT.md

REPORT — v0.116.0: R-116, the flag and the key share a row (2026-07-30)

Overwritten per the standing rule. Agent-only fix: the controller was not touched (one fix, one place) and v0.115.0 was not reverted. Mechanism evidence: felhom.eu audits/DIAG-r116-disks-payload-2026-07-30.md.

Baselines as actually running (not as on main)

	main	running	a FRESH box gets (hub Day-0 manifest)
agent	0.115.0 → 0.116.0	felhom-pve 0.115.0, demo-hp 0.113.0	0.115.0
controller	0.186.0	felhom-pve 0.186.0, demo-hp 0.185.1	golden bakes 0.185.1
hub	0.81.0	0.81.0	min_agent 0.113.0, min_controller 0.156.0
felhom.eu	1aa1bd1	—	—

The fleet is not uniform on either component. The golden baking controller 0.185.1 while demo-felhom runs 0.186.0 is load-bearing for the ruling below: a controller-side fix would not reach a fresh box without a re-bake, whereas the agent channel already serves the newest published version.

The ruling: neither (a) nor (b) — a hybrid, because both regress R-114

primaryTargetID is a PVE storage name (felhom-backup); the registry row's Name is the drive UUID. With the device gone the two records of one drive share no runtime field — no mount, no backing device, and the Observe row's DurableID has degraded off the fs-UUID to path:/mnt/cel.

Rejected (a) — back-fill MountPath on the Observe row. The spec's lean, and it does re-activate v0.115.0. Rejected on source evidence: backup_target_offer.go:79 reads d.BackupTarget && d.MountPath != "" as "a real drive with its own mountpoint — healthy" and returns before its TargetAbsent branch. Option (a) manufactures exactly that row while the drive is missing, so it would have silently flipped R-114 — shipped 2026-07-29, proven live — back to a false healthy banner. Also MountPath's own contract is "the RAW host PVE mount" (disks.go:152-153); a path that is not mounted is not that, so the downstream reading is correct and the change would be the bug.

Rejected (b) — carry BackupTarget on the registry row. A join does exist (below), so this was available — but the registry row's MountPath is non-empty, read from the by-then-stale .mount unit file. It trips :79 identically. Same regression, same reason.

Rejected (c) — resolve controller-side. The mapping is not there to find, and the one state, one owner ruling stands: the agent owns drive identity.

Taken (d) — give the Observe row the guest path (and NO MountPath), then dedup the registry row on guest path. The gate keys on GuestPath; R-114 keys on MountPath. Separating them satisfies both: the surviving row carries the flag and the guest path with mount_path: "", so isTarget[guestPath] is true and :79 does not match, leaving R-114's TargetAbsent branch reachable.

The join: with the device gone the shared identity is configuration, not state — the storage's path from storage.cfg (Observe side) and the .mount unit's Where (registry side) are the same path, so both derive the same stable guest path. That is the key both sides can still compute.

What (d)'s dedup removes in the absent state, enumerated: the registry row's uuid: durable_id, its hardcoded and false state: "attached", its role: user-data, and its total_bytes/used_bytes copied from the root filesystem. No consumer found — wipe/decommission require the drive present; firstOfferableDrive (:138) already requires MountPath != "" and Role == "user-data"; diskKey (disk_health.go:130) changes key transiently but the health check excludes UNKNOWN verdicts, so no false degradation. R-118's symptom disappears incidentally — R-118 is NOT fixed and stays open.

Deliberately unchanged: Role (the absent target still reads system), the BoundUnderParent conjunction, and every wire field.

Files

internal/hub/report.go (ConfigPath, json:"-" — that struct is a cross-repo contract pinned by testdata/host-report.golden.json + contract_test.go's key-set comparison, so a wire-visible field would have needed a matching felhom.eu/hub change; nothing off-box needs the value) · internal/storage/observe.go (set from s.Path) · internal/localapi/disks.go (ConfigPath fallback + guest-path dedup) · internal/localapi/disks_backup_target_row_test.go (fixture corrected + 4 tests) · CHANGELOG.md.

observe.go's change is not the fallthrough its :176-183 comment forbids: that prohibition is about resolving a device or UUID from the containing filesystem, which would hand back root's identity and mis-target a DR re-attach. s.Path is the storage's own declaration, identifies nothing but itself, and is used for no resolution. MountPath stays empty, which is the truth.

§2 reconfirmation

Cited	Line now	Holds
mountPath assigned only on exactMount success	observe.go:184-190	HOLDS verbatim
empty backingDevice ⇒ RoleSystem	role.go:180-181	HOLDS verbatim
guest-path guard skipped for non-user-data	disks.go:215-217	HOLDS
Known() reads unit FILES, never the mount table	registry_known.go:40-75, MountPath: spec.Where at :70	HOLDS
driveTargetByPath keys only from non-empty fields	intermediary.go:602-618 (:611, :614)	HOLDS
the dedup keys on d.MountPath at :263	:263 is if t.BackingDevice != "". Actual: seen built :290-295, dedup :298	HOLDS; the line number in the spec is wrong
"seen[""] is set, so the union row is not skipped"	DOES NOT HOLD as stated — seen[d.MountPath] = true is guarded by if d.MountPath != "", so seen never gains "". The union row survives because /mnt/<name> is absent from seen, not because "" is present. Same outcome, different reason	corrected

Tests — 845 → 849, suite green (go build ./... && go vet ./... && go test ./... rc=0)

All PASS: TestAbsentBackupTargetIsResolvableByGuestPath (rewritten — real shape and the union loop), TestAbsentTargetAppearsExactlyOnce (new, the join), TestAbsentTargetKeepsR114DegradedSignal (new, the regression guard), TestPresentTargetPayloadUnchanged (new, fleet-wide parity), TestAbsentNonTargetKeepsItsRegistryRowAndNoFlag (new, negative + over-suppression), TestAbsentTargetRowDoesNotRegisterPresence, TestCaseBLocalTargetGetsNoGuestPath, TestSystemBackedTargetUnderMntGetsNoGuestPath, TestNonTargetDriveNeverCarriesTheFlag.

Red-proofs — each mutation asserted to have landed before the run:

1. v0.115.0's MountPath-only fallback → isTarget[…] = FALSE … rows=2. The empirical proof v0.115.0 was inert, rather than an argument for it.
2. Drop the guest-path dedup → the absent drive is carried by 2 rows, want exactly 1.
3. Give the absent row a MountPath (what option (a) produces) → the R-114 guard fires.
4. Over-broad dedup (gp != "" without seenGuest) → the non-target drive loses its own row, and two pre-existing R-113 union tests fail as well.

The corrected fixture is the headline test change. theAbsentTarget supplied MountPath: "/mnt/mentes", which production never supplies, and targetRowServer left DriveTargets nil, so the union loop never ran and the two-row shape was invisible to the entire suite. Both fixed — that combination is why an inert fix shipped green.

Process note

One red-proof was restored with git checkout <file>, which discarded the whole implementation rather than the one-line mutation. Re-applied and re-verified; later red-proofs restored from pristine copies kept outside the repo. git checkout is not an undo for a mutation on a work-in-progress file.

LIVE VALIDATION — all claims PASS (felhom.eu audits/R116-v0116-2026-07-30.md)

Fresh box, real day-0 from the v1.25.0 ISO on a nested PVE on demo-hp (per runbooks/target-selection.md), agent installed unaided from the vouched Day-0 manifest, both drives enrolled through the real endpoints, device loss a real hot-detach.

07:20:04  backup_target_absent   (error)  Cel meghajto   ← TARGET, specific (was generic through v0.115.0)
07:22:34  backup_target_restored (info)   Cel meghajto   ← its matching pair
07:24:04  storage_disconnected   (error)  Adat meghajto  ← NON-target, generic, same box 4 min later
07:25:34  storage_reconnected    (info)   Adat meghajto

All four at the hub; gate fired in 3 s. Discrimination proven non-trivially for the first time. Over-correction passes on a positive observable (0 ABSENT lines / 0 drive events over 2m14s with both drives present, target degraded:false, while two RETURNED lines prove the gate ticked). Publish observables: registry GET of the published bytes matched b47c5c4d…, the manifest was read back showing 0.116.0, and the box reported it running.

One caveat, not a regression: the drill's controller was 0.185.1 from the golden, which predates R-114, so its absent-state banner showed the old false "the backup is on the system disk" copy. The R-114 guard is pinned by unit test and by the payload (no row combines the flag with a mount path) but could not be confirmed on that box. Filed as R-120 — the golden is a release behind, which is R-115's class one layer up.

Teardown — all three §13 layers

VM 9401 destroyed --purge; r116-images removed and the space measured back (felhom-backup 928787076 KiB available vs 928787080 before); hub records gate-blocked — the cascade was attempted and correctly refused HTTP 409 host … is ONLINE, with the command recorded for once it ages to DOWN. Secrets shredded.