CC: Add Codex retention policy plan
This commit is contained in:
@@ -0,0 +1,73 @@
|
||||
---
|
||||
name: cto-codex-retention-policy-packet
|
||||
tier: T1
|
||||
status: validated
|
||||
owner: jp
|
||||
source: CTO-WORK-094
|
||||
last_reviewed: 2026-06-04
|
||||
description: Local CTO policy packet for Codex retention cleanup approval.
|
||||
---
|
||||
|
||||
# CTO Codex Retention Policy Packet
|
||||
|
||||
Local planning SOT only. Not a Core Protocol. Not active Core authority.
|
||||
|
||||
## Claim
|
||||
|
||||
Codex retention cleanup now has a backup-first, approval-gated policy plan. The policy is non-mutating until JP approves a named mutation scope.
|
||||
|
||||
## Context
|
||||
|
||||
Core S411 proved current Core-owned successful Validator selectors already use compact summaries. Remaining bloat is external Codex retention: session JSONL files, active thread records, and Codex log SQLite files.
|
||||
|
||||
Current dry-run state still shows 1,038 active threads, zero archived threads, about 2.39GB session JSONL, and about 2.7GB `logs_2.sqlite` plus WAL.
|
||||
|
||||
Planner state on 2026-06-04:
|
||||
|
||||
| Surface | Count | Bytes |
|
||||
| --- | ---: | ---: |
|
||||
| archive-only candidates older than 7 days | 367 | about 405MB |
|
||||
| destructive delete candidates | 0 | 0 |
|
||||
| large active sessions over 10MiB | 51 | about 1.46GB |
|
||||
|
||||
## Planner
|
||||
|
||||
`python3 tools/plan_codex_retention_policy.py` emits metadata-only JSON. It reads only thread archive flags, timestamps, rollout paths, file sizes, and log target byte estimates. It does not read transcript bodies, thread text fields, titles, previews, secrets, or raw messages.
|
||||
|
||||
The planner classifies:
|
||||
|
||||
- archive-only candidates;
|
||||
- destructive delete candidates;
|
||||
- large active sessions;
|
||||
- top log pressure targets;
|
||||
- approval boundaries.
|
||||
|
||||
## Policy
|
||||
|
||||
1. Prevention default: use `codex exec --ephemeral` for disposable non-interactive worker runs.
|
||||
2. Phase 0: run pressure report and policy planner; no mutation.
|
||||
3. Phase 1: backup `state_5.sqlite`, `logs_2.sqlite`, WAL, and SHM files.
|
||||
4. Phase 2: archive-only candidate threads by DB flag only after explicit approval.
|
||||
5. Phase 3: delete archived session JSONL only after separate destructive approval.
|
||||
6. Phase 4: delete/truncate logs and checkpoint/vacuum only after Codex is stopped and destructive approval is explicit.
|
||||
|
||||
## Approval Boundary
|
||||
|
||||
Blocked without explicit operator approval:
|
||||
|
||||
- updating `threads.archived`;
|
||||
- deleting session JSONL;
|
||||
- deleting or truncating Codex logs;
|
||||
- SQLite checkpoint or vacuum;
|
||||
- raw transcript read/import;
|
||||
- any Core source mutation.
|
||||
|
||||
## Decision
|
||||
|
||||
Next safe action is to ask for archive-only approval. Delete and vacuum stay separate later approvals. Core remains out of raw transcript retention authority.
|
||||
|
||||
## New Issues
|
||||
|
||||
- must-fix: obtain explicit archive-only approval before any `threads.archived` update.
|
||||
- must-fix: obtain separate destructive approval before session deletion, log deletion, checkpoint, or vacuum.
|
||||
- follow-up: check native Codex retention support before custom mutation.
|
||||
Reference in New Issue
Block a user