GPT Review — 22-P2 Main Functions Prompt rev3

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 rev3

Verdict

Do not dispatch rev3. Rev4 required.

Rev3 fixed the previous issues and is getting close. However, P2 is the first writer-phase for the native IU contract, so the remaining risks must be fixed before execution.

Required rev4 patches

P1 — Unique violation handler must not catch unrelated unique violations as idempotency

Current code catches any unique_violation during IU insert and treats it as canonical-address race:

EXCEPTION WHEN unique_violation THEN
  RETURN public.fn_iu_classify_existing(...)

This can hide unrelated unique violations, for example a UUID collision, future unique constraint, or trigger-side unique error. At scale this is dangerous because it may return not_found or misleading JSON instead of failing.

Patch:

Use GET STACKED DIAGNOSTICS v_constraint_name = CONSTRAINT_NAME; in the exception block.

Only classify existing if the violated constraint/index is the P1/P2-approved canonical-address uniqueness guard.

Because the exact name is not hardcoded, P2 preflight/function should discover the canonical uniqueness object name and compare against it. If the violation is not that object, RAISE the original error.

If comparing index/constraint names is too complex for v1, remove the broad catch and rely on pre-insert classify + advisory lock + uniqueness error abort. Do not silently classify on any unique violation.

P2 — Column type hard gates are incomplete

Rev3 only hard-gates:

• parent_or_container_ref = uuid
• identity_profile = jsonb
• version_seq = int4

But fn_iu_create writes many more fields. Rev4 must hard-gate all written column types, at least:

Information Unit:

• id = uuid
• canonical_address text-compatible
• unit_kind text-compatible
• owner_ref text-compatible or exact current expected type
• created_by text-compatible
• updated_by text-compatible
• identity_profile = jsonb
• parent_or_container_ref = uuid or revise signature
• version_anchor_ref = uuid
• content_anchor_ref text-compatible

Unit Version:

• id = uuid
• unit_id = uuid
• body text-compatible
• content_hash text-compatible
• version_seq integer-compatible
• created_by text-compatible

If any mismatch → STOP before BEGIN.

P3 — Pilot address capture should be deterministic and not depend on NOTICE parsing if possible

Rev3 relies on Agent capturing PILOT_ADDRESS from RAISE NOTICE, then substituting it later. This is better than rediscovery, but still fragile.

Patch options:

Preferred: Agent generates a safe pilot address outside SQL and stores it in the report/task variable, e.g. using timestamp + UUID, then passes the same value into SQL. Validate it with regex before use:

PILOT_ADDRESS="pilot.p2.$(date -u +%Y%m%dT%H%M%SZ).$(uuidgen | cut -c1-8 | tr 'A-F' 'a-f')"

or SQL-generated value with psql -tA assigned to a shell variable.

The prompt must say: exact value must be captured in a variable/log before BEGIN; if capture fails, STOP. Do not rely on reading NOTICE manually.

Since pilot address is generated by a controlled pattern, using it as a SQL literal is acceptable only after regex validation ^pilot\.p2\.[A-Za-z0-9T.-]+$ or a stricter lowercase pattern.

P4 — Plan test addresses should not be fixed

Rev3 uses fixed plan address test.p2.plan.temp and checks no rows with LIKE 'test.p2.plan.%'.

If old test rows exist from a previous run or another environment, this can false-fail. Plan should not create rows; test exact dynamic plan addresses instead.

Patch:

• generate PLAN_ADDRESS_1 / PLAN_ADDRESS_2 dynamically like pilot address;
• test no row exists for those exact addresses before/after;
• do not use broad LIKE prefix count.

P5 — Preflight role grant should not be silently treated as OK if skipped

Rev3 DO block warns if directus missing. The report says grant skipped = blocker, but SQL will still COMMIT functions without adapter role grant.

This may be acceptable only if explicitly marked as P3 adapter readiness blocker, not P2 creation blocker. Rev4 must state:

• missing grant target does not rollback function install if functions are otherwise valid;
• but report must mark adapter_readiness=BLOCKED;
• if User/GPT requires adapter availability immediately, then missing grant target should be a pre-BEGIN STOP. Choose one policy and state it.

P6 — Plan function status classification should distinguish publication type invalid

Rev3 publication type invalid falls to invalid_input or unresolved path indirectly. Better report explicit invalid_publication_type or include it in unresolved_vocab.

Patch:

• If issues include publication_type: → status unresolved_vocab or invalid_publication_type.
• This helps adapters know what to ask user/config.

P7 — Post-COMMIT verification should fail the phase, not only warn

Rev3 post-COMMIT DO block raises WARNING on critical verify failure. Since rollback is impossible after commit, the phase must end with a hard failure state.

Patch:

• If all_pass=false, output the verify JSON and then RAISE EXCEPTION 'POST_COMMIT_VERIFY_CRITICAL...' or otherwise force non-zero/failed status so Agent cannot report PASS.
• Report must say COMMIT succeeded but post-commit verify failed; no cleanup without approval.

P8 — ON_ERROR_STOP / error handling must be explicit

P2 should be executed with ON_ERROR_STOP=1 or equivalent so any SQL exception stops execution and triggers rollback/report. Add this to execution instructions.

P9 — COMMIT failure handling must be explicit

L2 deferred gate can fail at COMMIT. Rev4 should specify:

• If COMMIT fails, transaction is aborted and functions/pilot row should be rolled back.
• Run post-failure checks for absence of fn_iu_create / fn_iu_create_plan and pilot address.
• Upload partial report with COMMIT error.
• Do not retry.

P10 — SECURITY DEFINER owner must be checked after creation

Rev3 report includes owner, but prompt should explicitly query owner/prosecdef/provolatile and treat unexpected owner as warning/blocker depending policy.

At minimum, report function owner and note whether owner is the expected controlled deployment role. Do not leave SECURITY DEFINER owner implicit.

P11 — p_publication_type validation via __no_default__ is acceptable only with explicit comment in both functions and report

Rev3 comments it in functions, good. Report must also state publication type is explicit-only in P2 and no default config is seeded.

P12 — No cleanup is correct, but report must mark pilot row retained intentionally

P2 creates a pilot IU. Report must say pilot retained intentionally, with canonical address, and cleanup requires separate approval.

Directive to Opus

Patch P2 prompt to rev4 with P1–P12. Do not dispatch after patch; return for GPT/User review.

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

Rev3 is close, but the broad unique_violation catch is a real correctness risk. The second major issue is incomplete type gates. The rest are execution-safety hardening: stable address capture, exact plan test addresses, hard post-commit failure, ON_ERROR_STOP, and COMMIT-failure reporting.