statev2.sqlite grows without bound: 17 GB after 76 days, ~100 MB/hour with seven orchestrators (event log has no retention)

[1kuna]

Problem

On one host running seven long-lived orchestrator threads plus their delegated children, ~/.t3/userdata/statev2.sqlite is 17.0 GB (4,155,037 pages at 4 KiB, freelist 0) and grows about 100 MB per hour. Measured read-only on 2026-10-25 (T3 Code 0.1.2):

table	rows	payload_json
orchestration_events (2026-08-10 → now)	1,955,433	4.93 GB
of which turn-item.updated	719,582	3.28 GB
of which node.updated	668,578	0.94 GB
of which provider-turn.updated	282,691	0.34 GB
orchestration_v2_projection_turn_items	418,028	2.65 GB
other V2 projections		0.15 GB

The rest of the file is indexes and per-row overhead. Nothing prunes or compacts, so the file only grows; on this host it is now the largest single file written in a day, and it sits on the same volume as every worktree and CI runner.

Related but different: #18204 (closed) removed subagent-prompt write amplification; #23482 and #23687 are about WAL and reader locking. None covers retention of the append-only event log.

Reproduction

Run several orchestrators with delegated children for a few weeks. Watch select count(*) from orchestration_events and the file size. Archived threads keep their full event history.

Proposed behavior

Keep the event log authoritative but bounded:

• snapshot projections and truncate events older than the snapshot for archived or settled threads, or
• offer a user-triggered compaction (prune, then VACUUM) with a configurable retained window, and
• at minimum, show the file size and growth rate in settings so users see it before the disk does.

Why this belongs in T3

Users cannot safely prune a live SQLite file the server has open (#23482 shows a read transaction alone can freeze writes). Only the server knows which events are replayable from projections.

[xdotli]

same here