GPT Review — 22-P2 Main Functions Prompt rev5

Date: 2026-05-06 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/22-p2-iu-native-create-main-functions-prompt.md rev5

Verdict

Do not dispatch rev5. Rev6 required.

Rev5 applied some of the requested fixes, but it introduced or preserved several dispatch blockers. The biggest blocker is that the prompt is no longer self-contained: it tells Agent to copy function bodies from rev4, but the KB document is now rev5 and rev4 is not safely available as an execution source.

P2 is a writer-phase prompt. It must be fully executable from the current KB document alone.

Dispatch blockers

B1 — Prompt is not self-contained

Rev5 says:

• “copy fn_iu_create_plan from rev4 §2.1 verbatim”
• “copy full fn_iu_create from rev4 §2.2”
• “same as rev4” for tests and grants

This is not acceptable for execution.

Agent must not reconstruct function bodies from memory, old revisions, chat history, or partial references. The current prompt must contain the full SQL bodies and tests exactly.

Patch: inline the complete rev6 SQL for:

• CREATE FUNCTION public.fn_iu_create_plan(...)
• CREATE FUNCTION public.fn_iu_create(...)
• REVOKE/GRANT
• plan tests
• compile check
• pilot tests
• post-COMMIT verify

No “same as rev4,” no “copy from previous,” no “insert this guard.”

B2 — Placeholder guard is not effective enough

Current guard uses only:

IF 'ACTUAL_PILOT_ADDRESS_HERE' LIKE '$$%' THEN ...

Problems:

• It checks only one placeholder, not plan addresses.
• LIKE '$$%' checks strings beginning with two dollar signs, not one.
• The literal ACTUAL_PILOT_ADDRESS_HERE itself can pass if Agent forgets to replace it.
• The guard is separated from actual test literals and does not prove all substitutions were made.

Patch options:

Preferred: use psql variables consistently:

\set PILOT_ADDRESS '...'
\set PLAN_ADDRESS_1 '...'
\set PLAN_ADDRESS_2 '...'

Then use :'PILOT_ADDRESS' in SQL. If psql variable handling is too risky, use exact substitution but add a robust guard checking all three values:

• not starting with $;
• not equal to ACTUAL_PILOT_ADDRESS_HERE / SUBSTITUTED_PILOT_ADDRESS;
• regex ^[a-z0-9.-]+$;
• none exists before pilot execution.

B3 — FK duplicate-name check is applied to the wrong object

Rev5 says this is for SET CONSTRAINTS, but the duplicate-name check is on the canonical-address unique guard, not the IU→UV deferrable FK name used by SET CONSTRAINTS.

Patch:

• Discover exact IU→UV FK name from public.fn_iu_create_preflight() or catalog.
• Count duplicate constraint names for that FK name across visible/current DB.
• If unqualified SET CONSTRAINTS %I DEFERRED is used, duplicate FK constraint names should be a STOP or documented blocker, not a warning, because ambiguity at writer-phase is unsafe.

If current FK is initially deferred and no SET CONSTRAINTS will execute, still record the FK name and condeferred state. If not initially deferred, dynamic defer must be unambiguous.

B4 — Post-COMMIT CRITICAL via NOTICE can produce PASS unless Agent parses text perfectly

Rev5 changed post-COMMIT failure from RAISE EXCEPTION to RAISE NOTICE so report upload can proceed. The intent is good, but relying on NOTICE text for phase status is fragile.

Patch:

Use a query that returns structured status for Agent to capture, e.g.:

WITH v AS (
  SELECT public.fn_iu_verify_invariants(:'PILOT_ADDRESS') AS verify_json
)
SELECT
  CASE WHEN (verify_json->>'all_pass')::boolean THEN 'PASS' ELSE 'CRITICAL' END AS post_commit_status,
  verify_json
FROM v;

Then prompt must say:

• if post_commit_status='CRITICAL', upload report and mark phase FAIL/P3 BLOCKED.
• Do not rely on SQL exception or NOTICE text for this branch.

B5 — PUBLIC EXECUTE assert location is before COMMIT, good; but prompt must include full GRANT/REVOKE SQL

Rev5 says §2.3 same as rev4. That is not acceptable. Inline full signatures and privilege checks.

Also include owner/prosecdef/provolatile query in report.

B6 — SET CONSTRAINTS policy must be explicit in full function body

Because the full function body is missing, GPT cannot verify whether dynamic FK handling is correct.

Rev6 must show exactly:

• how v_fk_name is obtained;
• how v_fk_deferred is obtained;
• what happens when FK is not initially deferred;
• what happens when duplicate FK names exist;
• whether SET CONSTRAINTS is executed or skipped.

B7 — Address generation still depends on NOTICE capture

This can be acceptable only if the prompt gives exact shell/psql capture instructions. Current prompt says “capture from NOTICE.” That is too hand-wavy for writer-phase.

Patch:

Either provide exact shell commands to generate variables before SQL, for example:

PILOT_ADDRESS="pilot.p2.$(date -u +%Y%m%d-%H%M%S).$(uuidgen | tr 'A-F' 'a-f' | cut -c1-8)"
PLAN_ADDRESS_1="test.p2.plan.$(uuidgen | tr 'A-F' 'a-f' | cut -c1-8)"
PLAN_ADDRESS_2="test.p2.plan.$(uuidgen | tr 'A-F' 'a-f' | cut -c1-8)"

Then run SQL using psql variables, or provide exact psql -tA capture commands. Do not rely on manual NOTICE parsing.

Directive to Opus

Patch P2 prompt to rev6.

Rev6 must be fully self-contained and executable. No references to rev4 function bodies or previous sections.

Required rev6 changes:

1. Inline full fn_iu_create_plan SQL body.
2. Inline full fn_iu_create SQL body.
3. Inline full REVOKE/GRANT SQL with signatures.
4. Inline full tests; no “same as rev4.”
5. Replace placeholder guard with robust variable/substitution strategy.
6. Move duplicate-name check to the IU→UV FK constraint used by SET CONSTRAINTS.
7. Make post-COMMIT verification return structured PASS/CRITICAL rows; report must mark CRITICAL as phase failure while still uploading report.
8. Give exact address capture/generation instructions, not manual NOTICE capture.
9. Include explicit report requirement: no unresolved placeholder strings occurred in executed SQL.

Hard boundaries remain

• no dispatch yet;
• no raw birth_registry insert;
• no DOT adapter;
• no dot_tools registration;
• no default seeding;
• no cleanup pilot;
• no retry/improvise on SQL failure.

Summary

Rev5 cannot be sent to Agent because it is not self-contained and checks the wrong constraint name for SET CONSTRAINTS ambiguity. For writer-phase execution, the prompt must contain exact SQL and exact variable handling. No reconstruction from previous revisions.