# 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.