Summary
ADR-0080's Consequences section names this as a known, deliberate fast-follow (#1664), mirroring the same posture ADR-0071 §11 took for read-path enforcement: three local artifacts grow unboundedly and nothing prunes them today.
audit.jsonl is append-only by design (§11) — no rotation, no size cap, explicitly exempted from OMNI_DEV_LOG_DISABLE/the request log's own rotation/prune.- The lease ledger keeps every row forever, including expired and already-restored-from leases, so that
drive lease restore can find a backup by token after expiry (§4).
- The backup directory / backup folder — every
drive lease acquire writes a new byte backup or Drive copy, and nothing ever deletes an old one.
Proposal
A drive lease prune command mirroring omni-dev log prune's shape (--older-than/--max-size/--dry-run), with one load-bearing difference: a ledger row and the backup it points at must be dropped together, never one without the other — a dangling ledger row pointing at a deleted backup, or an orphaned backup with no ledger row, both defeat the recovery story #1664 exists for.
audit.jsonl is explicitly out of scope here per the ADR's own reasoning (§11's fail-closed contract treats it as forensic history, not operational state) — confirm during design whether that stays true or whether a separate, much more conservative retention policy is warranted for it.
Open questions
- Should pruning a live (non-expired) lease's row ever be possible, or only expired/restored-from ones?
- Does
require_lease: false's backup-less writes need any pruning consideration, or is there simply nothing to prune there?
- Same
--dry-run-first, exit-code-0 posture as every other Drive command in this codebase?
Context
Summary
ADR-0080's Consequences section names this as a known, deliberate fast-follow (#1664), mirroring the same posture ADR-0071 §11 took for read-path enforcement: three local artifacts grow unboundedly and nothing prunes them today.
audit.jsonlis append-only by design (§11) — no rotation, no size cap, explicitly exempted fromOMNI_DEV_LOG_DISABLE/the request log's own rotation/prune.drive lease restorecan find a backup by token after expiry (§4).drive lease acquirewrites a new byte backup or Drive copy, and nothing ever deletes an old one.Proposal
A
drive lease prunecommand mirroringomni-dev log prune's shape (--older-than/--max-size/--dry-run), with one load-bearing difference: a ledger row and the backup it points at must be dropped together, never one without the other — a dangling ledger row pointing at a deleted backup, or an orphaned backup with no ledger row, both defeat the recovery story #1664 exists for.audit.jsonlis explicitly out of scope here per the ADR's own reasoning (§11's fail-closed contract treats it as forensic history, not operational state) — confirm during design whether that stays true or whether a separate, much more conservative retention policy is warranted for it.Open questions
require_lease: false's backup-less writes need any pruning consideration, or is there simply nothing to prune there?--dry-run-first, exit-code-0 posture as every other Drive command in this codebase?Context
omni-dev log prune(src/cli/log/prune.rs,request_log::prune)