Opus Post-Dispatch Review — P3D Pack 1 Phase 4 v5 ROLLED_BACK at G7

Date: 2026-05-11 Author: Opus 4.7 (review) For: GPT-5.5 Thinking / Hội đồng AI — thẩm tra + quyết định next step Run: p3d-phase4-vocab-20260511-075422 Prompt executed: ...prompts/p3d-pack1-phase4-governance-vocab-species-prep-implementation-prompt-DRAFT.md (v5, revision 7) Agent report: ...reports/p3d-pack1-phase4-vocab-species-seed-implementation-report.md

---

1. Verdict: v5 architecture VALIDATED, G7 contract defect identified

The v5 dispatch proved that the architecture works correctly. Every structural improvement from v4→v5 performed exactly as designed:

v5 feature	Validation outcome
Single psql / single BEGIN..COMMIT	✅ Temp tables, gates, inserts, and G7 all ran in one session. No cross-session bug.
Executable DO-block gates (G1-G6)	✅ All 6 gates emitted Gn_PASS notices. G7 raised → transaction auto-rolled back.
Exact dot_config schema gate (G1)	✅ Confirmed (key, value, description, updated_at) — matches exactly.
Unique-key gate (G2)	✅ dot_config_pkey = PRIMARY KEY (key) via btree.
Live delta computation (no hardcode)	✅ 12 section_type + 1 publication_type + 1 unit_kind = 14 rows, all from live TAC data or Pack 1 contract.
RETURNING into _inserted_keys	✅ 14 rows captured pre-COMMIT. After rollback, 0 rows persisted — exact-key list available for next dispatch.
ON_ERROR_STOP=1 + set -e abort	✅ G7 raise → psql non-zero exit → script stopped. No Section C/D ran.
Value-conflict gate (G5)	✅ 0 conflicts.
Run marker via SET LOCAL GUC	✅ G6_PASS run_marker=p3d-phase4-vocab-20260511-075422.

The only failure is G7, and it is a prompt contract defect — not a database state issue, not a v5 design issue.

---

2. G7 root cause

What prompt v5 assumed

SELECT status, resolved_unit_kind, would_create
FROM   fn_iu_create_plan(
         p_canonical_address := '...',
         p_unit_kind         := 'law_unit',
         p_title             := '...',
         p_body              := '...'
       );

4 named args, returns row (status text, resolved_unit_kind text, would_create boolean).

What production actually has

fn_iu_create_plan(
  p_canonical_address text,
  p_title text,
  p_body text,
  p_actor text,
  p_unit_kind text,
  p_section_type text,
  p_owner_ref text,
  p_publication_type text,
  p_parent_ref uuid
) RETURNS jsonb

9 named args, returns jsonb.

Why this happened

The 4-arg signature was inherited from v4, which was itself a design-time assumption never validated against production pg_proc. v5's rà soát focused on fixing the five v4 structural defects (cross-session temps, prose gates, schema adaptation, inserted-key capture, planner gate executable). The planner's own call contract was not in scope of those fixes and was taken as-is from v4. This is a legitimate oversight, caught by the exact mechanism v5 was designed to catch: an executable gate failing before COMMIT.

Impact

None. Transaction rolled back cleanly. dot_config unchanged (verified: 0 rows with run_marker, vocab.* = pre-run A4 state: 3 rows). No manual cleanup needed.

---

3. Agent compliance assessment

Requirement	Complied?
Stop on failed gate, do not retry/edit/improvise (§10)	✅
Skip Section C + D after failure	✅
Capture _inserted_keys verbatim pre-COMMIT	✅ (14 rows logged, not persisted)
No seed persisted, no migration	✅
No species INSERT	✅
No hardcoded list	✅ — all 14 values live-derived
Write report with all mandatory sections	✅
Hard-boundary attestation	✅ — 12/12 items confirmed

Agent fully compliant. No supplementary action needed from agent for this run.

---

4. What DRAFT v6 must fix (minimal, targeted patch)

v6 is NOT a restructure. G1-G6, delta logic, INSERT/RETURNING, rollback model, species read-only, and hash provenance document-only all stay unchanged. Only G3 and G7 need patching.

4.1 — G3 tighten: verify fn_iu_create_plan SIGNATURE + RETURN TYPE

Current G3 only checks pg_proc.proname = 'fn_iu_create_plan'. v6 should also assert:

• Return type is jsonb (via pg_proc.prorettype = 'jsonb'::regtype).
• Argument count and names match expected (or at minimum, required args are present in the signature).

This way, a signature mismatch surfaces at G3 (cheap, before any delta/insert) instead of G7 (after 14 INSERTs that then roll back).

4.2 — G7 rewrite: match live 9-arg jsonb contract

The G7 DO block must:

1. Call with all 9 args. For probe purposes, safe defaults:
   • p_canonical_address := 'planner-probe/p3d-phase4-v6-' || current_setting('p3d.run_marker')
   • p_title := 'Phase 4 v6 planner probe'
   • p_body := 'Probe body'
   • p_actor := 'system' (or whatever the standard actor value is — needs discovery)
   • p_unit_kind := 'law_unit'
   • p_section_type := NULL (or empty — needs discovery)
   • p_owner_ref := NULL
   • p_publication_type := NULL
   • p_parent_ref := NULL::uuid
2. Parse the jsonb result:
   • v_result ->> 'status' must NOT contain unresolved_vocab.
   • v_result ->> 'resolved_unit_kind' must equal 'law_unit'.
3. If either check fails, RAISE EXCEPTION.

4.3 — Discovery probe needed BEFORE writing v6

Before writing v6's G7, we need a read-only probe to determine:

1. Which params have defaults? SELECT pg_get_function_arguments(oid), pronargdefaults, proargdefaults FROM pg_proc WHERE proname = 'fn_iu_create_plan' — if some params have defaults, the probe call can omit them.
2. What keys does the jsonb result contain? Call fn_iu_create_plan(...) in a read-only test (not inside the seed transaction) and inspect the returned jsonb keys: does it have status, resolved_unit_kind, would_create, or something else?
3. What actor value is expected? Check if p_actor has a default, or if there's a standard value like 'system' or 'anonymous'.

This probe can be a simple read-only psql call. No transaction needed. No state change.

---

5. Proposed next steps (for GPT/User decision)

Step 1: GPT confirms this review is accurate and the v5 architecture is sound.
Step 2: Agent runs read-only discovery probe for fn_iu_create_plan (args, defaults, jsonb shape).
Step 3: Opus patches G3 + G7 in DRAFT v5 → DRAFT v6 using discovery results.
Step 4: GPT reviews v6 patch (scope: only G3 + G7 changes).
Step 5: User dispatches v6.

Estimated scope of v6 patch: ~40 lines changed in G3 + G7. Everything else in v5 stays verbatim.

---

6. Risk assessment

Risk	Likelihood	Mitigation
Discovery probe reveals additional fn_iu_create_plan complexity (e.g. it writes side-effects)	Low — name says "plan" not "create"	Probe is read-only; if function has side effects, they'd show in pg_proc's provolatile flag
jsonb keys differ from expected status/resolved_unit_kind	Medium — we've never inspected the actual payload	Discovery probe (Step 2) resolves this before writing v6
Some params lack defaults and we don't know the right value	Medium	Discovery probe + KB search for fn_iu_create_plan documentation
Delta changes between v5 rollback and v6 dispatch (TAC data modified)	Very low — TAC data is stable	v6 re-computes delta live; if a new section_type appears, it gets picked up; if one is deleted, delta shrinks. Both are correct.

---

7. Summary for GPT

v5 architecture = VALIDATED. Single transaction, executable gates, live delta, RETURNING capture, auto-rollback — all worked as designed. The sole defect is a prompt-level contract mismatch on fn_iu_create_plan signature inherited from v4's unvalidated assumption. Fix is surgical: discovery probe → patch G3 + G7 → v6. No structural redesign needed.

phase4_draft_v5=EXECUTED_ROLLED_BACK_G7_CONTRACT_DEFECT
v5_architecture=VALIDATED
g1_through_g6=ALL_PASS
g7=FAIL_SIGNATURE_MISMATCH
delta_values=CORRECT_14_ROWS_LIVE_DERIVED
data_state=UNCHANGED
agent_compliance=FULL
next_action=GPT_CONFIRM_THEN_DISCOVERY_PROBE_THEN_V6_PATCH