04 — Persistent Test-Seed Decision & Readiness Packet (Objective C)

Decision: NO persistent test-mode COMMIT. Rollback-only readiness packet produced instead.

This was evaluated seriously, candidate by candidate — not declined reflexively. The mission authorizes a tiny inert reversible persistent seed if the Agent proves it safe, useful, and within delegated test authority, and says explicitly: "If in doubt, do rollback-only and produce readiness packet instead." Each candidate fails at least one bar.

Candidate-by-candidate evaluation

Candidate	Inert?	Reversible?	Useful beyond rollback-only?	Crosses a gate?	Verdict
Tiny owner seed (1–3 object×scope)	yes (0 triggers)	yes (DELETE)	no — doc 02 already proves the model at full scale	YES — this is the F-6 COMMIT step; persistently lowers gap = governed-state change requiring L2/L4 + ospa≥1	DECLINE
governance_ruleset draft row	yes (0 triggers)	yes	marginal — a rollback-only scanner can use a transient ruleset	YES — unratified governed config	DECLINE
candidate_scan_run ledger row	yes (0 triggers)	yes	no	fabricates scan provenance (asserts a scan ran)	DECLINE
gov_worker_cursor row	yes (0 triggers)	yes	no	misleads a future worker activation (resume point)	DECLINE
log-only row in an existing table	no for system_issues (9 triggers)	n/a	no	unsafe cascade / no clean generic log table	DECLINE — test logs belong in this KB package, not the prod governance DB

Why this is the correct call (not under-loading)

The mission's anti-under-loading directive is satisfied by doing the largest safe operation: a full-scale 210→0 rehearsal, the complete scanner read-path, and full payload shaping. "Run larger" ≠ "cross the sovereign ratification line." The single category being held — persisting governed ownership/config — is exactly the line the project has held for 15+ sessions, gated on os_proposal_approvals ≥ 1 (live = 0). Committing here would convert a rehearsal into the first act of production activation, which the mission also explicitly forbids. There is no separate test database: directus IS production.

Exact readiness packet — what would make a persistent owner seed GO

A future F-6 ownership-seed COMMIT (TEST_MODE) becomes executable when all hold:

1. L2 quorum approval of the auth model (human; ≥1 president-human + ≥2 ai_council, 0 rejects, proposer excluded).
2. L4 President e-signature of the auth model (human, out-of-band in Directus).
3. os_proposal_approvals ≥ 1 — the machine-checkable evidence of #1/#2 (live = 0).

When those clear, the exact committable artifact is already proven safe by doc 02:

• DDL/DML: the 30-anchor INSERT … SELECT from sql/f6_large_ownership_rollback.sql, minus the negatives/savepoints, with BEGIN; … COMMIT; instead of ROLLBACK;, plus a pre-commit re-assert of gap and conflict=0.
• Pre-staged rollback: DELETE FROM governance_object_ownership WHERE created_by LIKE 'F6_%'; (proven reversible — 0 triggers, no cascade).
• Expected deltas on COMMIT: ownership 0→30 (+1 if override), gap 210→0, eo 0→210, conflict 0, gov_emit 0, system_issues unchanged, ospa unchanged.

What was committed this run

Nothing. ownership=0 entry==exit, gap=210 entry==exit, ospa=0, no event, no issue, confirmed on both channels (doc 02).