02 — Objective A: Coverage Regression Suite

Verdict: PASS — reusable, residue-free regression suite built and executed on the clone: 26/26 checks PASS. SQL: sql/A_coverage_regression_suite_clone.sql

What it is

A single idempotent script that re-verifies the entire Phase-1 coverage pipeline against the committed clone state, without leaving any residue. The whole run is one BEGIN..ROLLBACK; read-only checks observe committed state directly, and mutating checks undo their own DB changes via inner PL/pgSQL subtransactions (variable values survive a caught exception while DB changes roll back), recording results in the outer scope so they survive to print.

Design note (a bug fixed during this run): an earlier version wrapped mutating checks in SAVEPOINT … ROLLBACK TO, which also rolled back the result rows. The fix is the inner-subtransaction + RAISE EXCEPTION 'UNDO_*' pattern. This is the reusable idiom for "test a mutation, keep the verdict, discard the change."

Coverage (7 dimensions → 26 assertions)

Dim	Checks	Result
R1 ownership coverage	seed=30, gap=0, conflicts=0, coverage=100.00%	4/4 PASS
R2 scanner read (effective owner)	total=240, direct=30, inherited=210	3/3 PASS
R3 scanner write shape	cand_state=5, cand_object=35, scan_run=2, ruleset=1	4/4 PASS
R4 candidate idempotency	re-upsert grows neither state nor object	2/2 PASS
R5 issue/event fail-closed	inactive rejected, unknown rejected, gov emit=0	3/3 PASS
R6 worker/cursor monotonicity	stale=no-op (wm-2/20), newer=advance (wm-3/30)	4/4 PASS
R7 ownership uniqueness	duplicate accountable owner rejected	1/1 PASS
R8 rollback verification	delete→gap 210/own 0; committed state intact after undo	5/5 PASS

Summary: 26 checks / 26 passed / 0 failed → SUITE PASS. Post-suite committed state unchanged: own=30, gap=0, cand_obj=35, cursor=1, gov_emit=0.

Why this matters for production

This suite is the production acceptance test. After the gated production seed (doc 07 / F_prod_*), the same R1/R2 read-only assertions (own=30, gap=0, conflict=0, effective=240=30+210, emit=0) are exactly what F_prod_02_verify.sql checks. The clone suite is the rehearsal; the production verify is the subset that is safe to run on production.

How to re-run

cat sql/A_coverage_regression_suite_clone.sql | \
  ssh contabo "docker exec -i postgres psql -U workflow_admin -d directus_gov_test_20260602 -P pager=off -f -"

Safe to run repeatedly: it asserts the clone's committed state, exercises every mutation path, and rolls everything back. A non-zero failed count or a missing row indicates real drift in the clone.