felhom-controller/REPORT.md

REPORT — controller v0.109.1: SLICE 4 soft-quota + offsite health — DEPLOYED + live-verified

Date: 2026-07-10 · Class: implementation. Baseline v0.108.0 → v0.109.0 → v0.109.1 (live on 9201, Up (healthy)). Pairs with hub v0.41.0 (OffsiteChecker + freeze lever) — live. The offsite arc's last build item.

What shipped (controller)

• Data: OffboxTarget.QuotaGB (bridge maps it from the descriptor; the descriptor hash now includes it so a hub-side quota change re-applies — via key-auth-first, no password consumed) + RepoSizeBytes (persisted from restic stats; failed stats keeps last-known — stale-but-safe).
• Pre-run soft-quota gate: ≥100% refuses NEW backups (Hungarian: "A NAS-mentés túllépte a tárhelykeretet (X/Y GB)…", LastStatus=error, operator alert via the existing notify) — but offboxPruneOnly still runs the retention step (pruning is the only way back under quota) and restore is never gated. ≥80% (<100%) sets the Hungarian usage LastWarning. Quota 0 = no gate.
• UI: /backups usage bar (used/quota + %, green/amber/red) when quota>0. Template gates green.
• Report: the hub report carries the non-secret offsite:{enabled, escrow_state, last_run, last_status, snapshot_count, repo_size_bytes, quota_gb}.
• v0.109.1 (live finding): the deploy's own re-apply DEMOTED the escrowed demo to pending + wiped its runtime status (ApplyOffsiteTarget replaced the whole target). Now a re-apply preserves the existing EscrowState (custody tracks the preserved repo password, not the coords) + runtime status; a fresh guest still lands pending.

Tests + companion red-proofs (ALL-GREEN, all three fired)

• Scenario A: over-quota → backup 0 calls, prune 1 call, Hungarian status, restore reaches the runner. Red-proof: gated the prune too → "prune MUST still run over quota, got 0" → FAIL.
• Scenario B: 84% → run ok + "A NAS-mentés a keret 84%-át használja (42/50 GB)." + bytes persisted.
• Scenario C: quota 0 → no gate/warn at any size. Bridge quota mapping + quota-change re-apply (panicking consumer) tested.
• v0.109.1 preserve: red-proof dropped the EscrowState carry-over → "must NOT demote an escrowed target, got pending" → FAIL.
• Report object present when enabled / nil when unconfigured (nil-safe hub-side).

Live verification (all through the real pipeline)

• Key-auth-first proven LIVE: the quota-hash change triggered a real re-apply — "existing key still authenticates … re-pinned + reconfigured without consuming a password" against the real box.
• v0.109.1 deployed; demo repaired via the deprecated manual confirm (truthful — same escrowed password; the confirm's wipe also removed the re-staged agent secret, verified empty) + a manual run: 2 snapshots, 41s, escrowed, quota_gb: 50, repo_size_bytes 45 MB.
• The next report carried the full offsite object hub-side; the OffsiteChecker held it healthy (0 offsite_* events — 0% fill, not stale). The /backups usage bar renders live: "Tárhelykeret: 43.2 MB / 50 GB (0%)" (curl through the in-guest UI).

NOT live-exercised (per the STOP)

The freeze lever (would write-lock the demo's working offsite) and the 100% quota-refusal (demo repo is 0.08% of quota) — unit red-proofs cover both; live exercise waits for a real need / the Peti window.

NEXT

Peti onboarding runbook (live-exercises auto-confirm + F4 + fresh-provision quota), NEW-box restore round-trip → retire the old-box archive.