felhom-controller/REPORT.md

REPORT — R-114 + R-112: tell the truth about the backup target, then show it (v0.186.0, 2026-07-29)

Overwritten per the standing rule. Controller v0.185.1 → v0.186.0. Session B of three (A → R-113 agent v0.114.0 shipped-unvalidated · B → this · C → one drill rebuild proving all three). felhom-agent untouched. NOTHING HERE IS LIVE-VALIDATED — see the bottom.

Baselines

felhom-controller cdaeb369726b v0.185.1 · felhom-agent b58d7bcf39a9 v0.114.0 (untouched) · felhom.eu 338b2ccf86. All clean and pushed at start.

MinAgent decision: unchanged at 0.113.0. R-114 reads BackupTarget, MountPath, GuestPath, Role — none of which R-113 altered; it changed BoundUnderParent, which this code does not read (internal/agentapi/client.go:303-338). Consequence, stated rather than discovered: demo-hp, still on agent 0.113.0, is not held and needs no move for this release.

Part 1 — R-114: the third state

resolveBackupTargetState had two outcomes — a disk claims the target (healthy), or nothing does (degraded, "the backup is on the system disk"). Configured, and its drive is gone had no branch, so it fell into the second and inherited its message and its offer. Observed live: degraded:true, target:"felhom-backup" + the system-disk copy (false) + offer_path naming the drive that had just vanished (audits/E2D-fresh-vm-2026-07-29.md §5.3).

• New BackupTargetState.TargetAbsent. Degraded keeps its meaning — is there a problem — so the wire contract is unchanged for every consumer; TargetAbsent answers which problem, because the two have opposite remedies.
• Discriminator targetIsConfiguredDrive: a real storage id, versus the builtin local or an unset tier (both = never configured).
• Copy routed through degradedMessageFor, so one place still decides what a customer reads.
• Offer suppressed on the branch itself, not left to firstOfferableDrive's Disconnected skip — that flag comes from the agent-side gate in another repo, and this state must be right without it.

Part 2 — R-112: the state gets a consumer

The endpoint was byte-correct and nothing asked for it — templates fetch 18 distinct /api/storage/* endpoints and these were the only two with zero references (§5.1).

Server-rendered on /backups, following the existing SingleCopyWarning banner at backups.html:11. backupsHandler → backupTargetView → template. Not a 19th JS fetch: the state is already resolved when the page is built, and a banner needing JavaScript to appear is one more thing that can silently not happen. backupTargetView returns nil for healthy and unknown, so a template typo cannot decorate a working box. The offer control POSTs to the existing assign endpoint behind the standard inline confirm, never auto-submits, and surfaces restart_required honestly.

Placement: the E-2 design doc names no surface — 07-backup-architecture.md has no banner or degraded reference, and the only E-2 string in the capability map is the unrelated CAMPAIGN-6E-2. So the choice is mine: the backups page already hosts a same-severity backup warning and the copy is about rendszermentés.

Files

internal/web/backup_target_offer.go (third state, view, tiers seam) · internal/web/server.go (tiersFn) · internal/web/handlers.go (one line wiring the view) · internal/web/templates/backups.html (banner + offer + assign script) · two new test files · CHANGELOG.md · REUSE.md · controller/README.md.

Tests: 326 → 338 (+12) in internal/web. Suite green (27 packages), both template gates pass.

Scenario E — the seam test, which is the one whose absence let E-2 ship. It does not call the resolver and assert a string (that proves the resolver, which was never broken). It drives backupsHandler over httptest and asserts the rendered HTML, travelling handler → backupTargetView → resolveBackupTargetState → degradedMessageFor → the production backups template.

Red-proof	Mutation	Failure text produced
1	delete the targetIsConfiguredDrive branch	TargetAbsent is false for target "felhom-backup"… and offered "/mnt/felhom-drives/mentes2" while the configured target is absent — E-2d observed this exact payload offering the drive that had just vanished
2	drop the absent case from degradedMessageFor	the customer is told the backup is on the SYSTEM DISK, which is false… + all three copy fragments missing
3	delete data["BackupTarget"] = … from the handler	the absent-drive copy never reached the page… + every render assertion in the never-configured case

All three reverted; files verified byte-identical after.

Negative assertions: healthy and unknown are checked for the absence of all three copy strings and of the banner element — not for the absence of an error.

A test caught its own imprecision: the first Scenario-C assertion matched the bare id backup-target-assign, which also appears inside the page script that always renders, so it reported a control that was not there. Tightened to the control's own markup.

NOT LIVE-VALIDATED — awaiting Session C

• Scenario C cannot occur on a healthy box. The demo guest has a present target, so the absent-drive banner is unproven live by construction.
• Untested live: the offer control's click → assign → restart_required surfacing.
• The live check in this session proves only that the seam is wired and which render a healthy box produces — that is R-112's whole point, but it is not proof of R-114.

Observations — filed, not fixed

1. The absent copy now lives in two repos — here and hub internal/notify/templates.go:93 — with nothing binding them but TestAbsentCopyMatchesTheHubEmailWordForWord, which only fails if this side drifts. Reword the hub and the test still passes while the banner and the email disagree.
2. resolveBackupTargetState bypassed the existing disksFn seam and called the client directly, which is why its branching had no test at all before this session. Now routed through fetchDisks with a sibling tiersFn — worth checking whether other agent-reading paths do the same.