Module retention 

Historical-data retention — managing the one unbounded-growth table, historical_tasks (one per-task status snapshot per save-snapshot). The admin screen surfaces the snapshot count + the oldest snapshot, lets the admin pick a cutoff date, shows a dry-run count of exactly what a prune would remove, and only then offers a confirmed delete (gated + audited — same safety pattern as delete_corpus). The run summaries (historical_runs) are never touched, so the run history and charts survive; only the bulky per-task snapshots age out.

Structs

HistoricalStatsDto

Per-task snapshot retention stats, as exposed over the API/UI.

PruneForm

The prune form: the cutoff date the preview was shown for.

Functions

api_historical_stats

The per-task snapshot retention stats (agent twin of the /admin/retention screen). Token- gated. 503 if the pool is exhausted.

prune

Prunes per-task snapshots older than the cutoff (POST /admin/retention/prune). Confirmed by the two-step preview + the form’s confirm() dialog; gated (AdminSession) and audited (the audit fairing records the action + actor). Only historical_tasks is touched — run summaries survive. Redirects back to the screen with the count removed; a malformed cutoff is a no-op.

retention_page

The data-retention screen (GET /admin/retention?<before>&<pruned>): snapshot stats; with ?before=YYYY-MM-DD, a dry-run count of how many snapshots that cutoff would prune (the page then offers a confirmed delete). ?pruned=N flashes the result of a completed prune. Signed-in admins only (unauthenticated → sign-in, returning here).

routes

The human retention screen + prune (the agent api_historical_stats read twin is mounted via frontend::apidoc; there is intentionally no agent mutation twin — see the note above).