83 — SB-1 APR Action-Types Author-Mode Rehearsal Results — EXECUTED LIVE

Branch A (mission §4). Tier: author-mode BEGIN..ROLLBACK, EXECUTED LIVE on vmi3080463 / postgres / directus (PG 16.13) via ssh contabo → docker exec -i postgres psql -U workflow_admin. Mutation footprint: ZERO COMMITTED — two transactions, each ended ROLLBACK; entry==exit proven (doc 91). No approval row created, no event emitted, no DOT/law touched. Design base: doc 16 (SB-1 detailed design). Risk base: doc 27 (auto-approve bypass). Plan base: doc 19 (paste-ready script — note doc 19 was never executed live; this doc is the first live execution of SB-1). GPT authorization: gpt-review-sb2-owner-line-rehearsal-pass-authorize-sb1-rehearsal-next-2026-06-01.md. Verdict: SB-1 vocabulary REHEARSED-GREEN — with one critical build finding (F-83-1) discovered and its fix validated live. Build remains NO-GO (M-1 os_proposal_approvals=0).

83.0 What was rehearsed (GPT mandate)

GPT authorized: rehearse adding the four APR action-type rows; verify handler_ref remains fail-closed/unimplemented; avoid action='add' auto-approve bypass; prove triggers/quorum behaviour where possible; prove rollback and entry==exit. The four action-types (doc 16 §4):

code	risk	handler_ref (Phase A)	purpose
`assign_governance_owner`	high	`unimplemented`	accountable owner for (object × scope) — writes SB-2
`grant_governance_exception`	high	`unimplemented`	11-field governed exception (M-DEF-6)
`delegate_authority`	high	`unimplemented`	time-boxed scope delegation (C-5)
`assign_axis_owner`	high	`unimplemented`	accountable owner of an axis (M-DEF-8)

All four: status='active', _dot_origin='SB-1-REHEARSAL-DOC83'. Scope boundary honoured: NO approval_requests row was created in this rehearsal (mission §4 + §14). The trigger/quorum behaviour is proven from authoritative live function source (doc 84), not by inserting an APR.

83.1 Live pre-flight (read-only) — the as-is insert path

apr_action_types live schema (verified via information_schema): columns action_code(PK), description(NOT NULL), handler_ref(NOT NULL), risk_level(NOT NULL, CHECK∈{low,medium,high}), status(NOT NULL, CHECK∈{active,deprecated,retired}), _dot_origin(NOT NULL), created_at, retired_at. No id column. Triggers (4): trg_apr_action_types_no_rename (BEFORE UPDATE), trg_birth_apr_action_types (AFTER INSERT → fn_birth_registry_auto() — NO code-field arg), trg_desc_guard_apr_action_types (BEFORE INSERT/UPDATE OF description → fn_description_birth_guard), trg_desc_provenance_apr_action_types (AFTER INSERT → fn_auto_label_provenance, SECURITY DEFINER).

Pre-flight findings that shaped the rehearsal:

collection_registry: apr_action_types is governance_role='governed', description_policy='unclassified' → fn_description_birth_guard raises a non-blocking WARNING (Đ4: … chưa classified); description_enforcement_mode='warn' (not block) so no EXCEPTION.
birth_registry: 0 rows for collection_name='apr_action_types' (the 6 existing action-types predate the birth trigger) — and birth_registry.entity_code is NOT NULL + UNIQUE.
fn_birth_registry_auto() with no arg + no id column ⇒ synthetic entity_code := 'apr_action_types::' || (row->>'id') = 'apr_action_types::' || NULL = NULL ⇒ predicted NOT-NULL violation on insert. Confirmed live in Run 1.
fn_auto_label_provenance reads NEW.code/NEW.key; apr_action_types has neither ⇒ trigger no-ops (safe).

83.2 RUN 1 — as-is probe (BEGIN..ROLLBACK; proves F-83-1)

Transaction set statement_timeout='5s', lock_timeout='3s', idle_in_transaction_session_timeout='15s'; \set ON_ERROR_ROLLBACK on (per-statement implicit savepoints). Attempted the 4-row additive INSERT as-is (live triggers, no fix).

entry_count        = 6
after_asis_attempt = 6        -- INSERT failed, savepoint-rolled-back
exit_count         = 6        -- == entry

Observed (verbatim, abridged):

WARNING:  Đ4: collection apr_action_types chưa classified description_policy   (×4, non-blocking)
ERROR:  null value in column "entity_code" of relation "birth_registry" violates not-null constraint
DETAIL:  Failing row contains (1060870, null, …, apr_action_types, approval_request, compound,
         SB-1-REHEARSAL-DOC83, …, governed, …, born, …, {}).
CONTEXT:  SQL statement "INSERT INTO birth_registry (entity_code, …) … ON CONFLICT (entity_code) DO NOTHING"
          PL/pgSQL function fn_birth_registry_auto() line 50 at SQL statement

⇒ FINDING F-83-1 (critical, new). Inserting any row into apr_action_types fires trg_birth_apr_action_types → fn_birth_registry_auto() without a code-field arg; because the table has no id column the synthetic entity_code computes to NULL → not-null violation on birth_registry. SB-1 Phase-A vocabulary registration is BLOCKED as-is. (The ON CONFLICT (entity_code) DO NOTHING does not catch a NOT-NULL violation — only unique conflicts.) Root cause pinned by contrast: the sibling trigger trg_birth_approval_requests is wired fn_birth_registry_auto('code') with an arg — which is exactly why approval_requests inserts succeed. The fix is to wire apr_action_types's birth trigger with 'action_code'. Entry==exit held (6→6) even through the failed insert.

83.3 RUN 2 — additive + fail-closed proof (BEGIN..ROLLBACK; build-fix applied in-txn)

Same timeouts + ON_ERROR_ROLLBACK on. Applied the exact build fix inside the transaction, then proved additivity/fail-closed/negatives, then rolled everything back.

DROP TRIGGER trg_birth_apr_action_types ON apr_action_types;
CREATE TRIGGER trg_birth_apr_action_types AFTER INSERT ON apr_action_types
  FOR EACH ROW EXECUTE FUNCTION fn_birth_registry_auto('action_code');   -- the F-83-1 fix
INSERT INTO apr_action_types(...) VALUES (4 governance action-types, handler_ref='unimplemented', risk='high', 'active');

Assertions (live results):

entry_count               = 6
after_insert              = 10     -- additive +4
fail_closed_unimplemented = 4      -- all 4 handler_ref='unimplemented'
all_high_risk             = 4      -- all 4 risk_level='high'  (=> president + 2 ai_council quorum)
all_active                = 4
birth_rows_for_table      = 4      -- fix proven: birth rows now created
birth entity_codes        = assign_axis_owner | assign_governance_owner | delegate_authority | grant_governance_exception
                            (all governance_role='governed', certified=f)
existing6_intact          = 6      -- original vocabulary untouched
after_negatives           = 10     -- negatives left no rows

Negative tests (all rejected as designed):

test	input	result
N1 — PK collision	`action_code='amend_law'` (exists)	`ERROR: duplicate key value violates unique constraint "apr_action_types_pkey"` ✔ no silent overwrite
N2 — bad risk	`risk_level='critical'`	`ERROR: … violates check constraint "apr_action_types_risk_level_check"` ✔
N3 — bad status	`status='enabled'`	`ERROR: … violates check constraint "apr_action_types_status_check"` ✔

Post-ROLLBACK (same session):

exit_count        = 6      -- == entry
codes_absent      = 0      -- the 4 governance codes gone
birth_rows_after  = 0      -- the 4 birth rows gone
trigger def       = CREATE TRIGGER trg_birth_apr_action_types AFTER INSERT … EXECUTE FUNCTION fn_birth_registry_auto()
                    -- restored to ORIGINAL no-arg def: the in-txn DDL fix was fully reversed
idle_in_txn       = 0

Observed (non-blocking): [TRIGGER-GUARD] DROPPED … and [TRIGGER-GUARD] DDL detected: CREATE TRIGGER … WARNINGs — a DDL-audit event trigger logged the trigger DROP/CREATE (warning only; see F-83-2, doc 86). Plus the expected Đ4 … chưa classified description WARNINGs (×N, non-blocking).

83.4 What the rehearsal PROVED (against the GPT/mission checklist)

Requirement (GPT + mission §4)	Proven?	How
rows can exist as data/vocabulary	✔	after_insert=10 (additive +4) with the F-83-1 fix
no code collision	✔	the 4 codes absent at entry; N1 PK-collision on existing code rejected; existing 6 intact
risk level + handler are fail-closed	✔	all 4 `risk='high'` + `handler_ref='unimplemented'`
handler_ref stays unimplemented / non-executable	✔	`fn_apr_block_unimplemented_handler` RAISES on any `→applied` for these codes (doc 84, live-verified)
action semantics avoid `action='add'` bypass	✔ (by construction)	no APR created; the governance-APR protocol is `action='review'` (doc 84 §84.3)
no `approval_requests` row created	✔	`approval_requests`=211 pre/post (doc 91)
triggers/quorum implications understood	✔	doc 84 (live function source)
entry==exit	✔	6→6 both runs; cross-session re-verified (doc 91); trigger DDL reversed; idle_in_txn=0

83.5 Verdict

SB-1 APR action-types rehearsal = PASS (REHEARSED-GREEN), EXECUTED LIVE, ZERO COMMIT. The 4 governance action-types register as additive, fail-closed (unimplemented/high) data; the constraint surface (PK, risk CHECK, status CHECK) rejects all malformed inputs; entry==exit is proven across two channels; the transaction's DDL fix was fully reversed.

One mandatory build finding surfaced — F-83-1: the build of SB-1 Phase A MUST re-wire the apr_action_types birth trigger to fn_birth_registry_auto('action_code') (or the four INSERTs will fail on a birth_registry.entity_code not-null violation). The fix was validated live (Run 2). Folded into doc 86 (§F-83-1) and the SB-1 build prompt (doc 90).

Build remains NO-GO: os_proposal_approvals=0 (M-1), C-2 not formally intake-ruled for build, SB-2 build not done, Phase-B handler not built, no sovereign sign-off. This rehearsal authorizes nothing to COMMIT.