GPT Review — 22-P2 Main Functions Prompt rev8

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 rev8

Verdict

Do not dispatch rev8. Rev9 required.

Rev8 is operationally much better: it captures logs, uses set +e, has diagnostics, avoids manual substitution, and is self-contained. However, for a writer-phase function that will become a long-term native creation contract, several remaining gaps still matter for scale, schema evolution, and report reliability.

Required rev9 patches

P1 — Use env-configurable DB connection variables, not hardcoded container/user/db everywhere

Rev8 hardcodes:

• container: postgres
• user: directus
• database: directus

This is acceptable as current environment defaults, but not as a durable execution pattern.

Patch at top of script:

PG_CONTAINER="${PG_CONTAINER:-postgres}"
PG_USER="${PG_USER:-directus}"
PG_DB="${PG_DB:-directus}"

Then replace all docker exec postgres psql -U directus -d directus with:

docker exec -i "$PG_CONTAINER" psql -U "$PG_USER" -d "$PG_DB" ...

Same in make_uuid() fallback and diagnostics.

P2 — Address validation must be strict enough to catch empty UUID suffix

Rev8 broad regex ^[a-z0-9.\-]+$ can pass malformed addresses such as pilot.p2.20260506-101010. if UUID generation fails.

Patch:

• Generate UUID suffix into variables and validate suffix length/pattern before composing addresses.
• Use stricter address regexes:

[[ "$PILOT_ADDRESS" =~ ^pilot\.p2\.[0-9]{8}-[0-9]{6}\.[0-9a-f]{8}$ ]]
[[ "$PLAN_ADDRESS_1" =~ ^test\.p2\.plan\.[0-9a-f]{8}$ ]]
[[ "$PLAN_ADDRESS_2" =~ ^test\.p2\.plan\.[0-9a-f]{8}$ ]]

The SQL address guard should use equivalent strict patterns, not only generic allowed characters.

P3 — Helper preflight must verify exact signatures, not just names

Rev8 checks that helper names exist. That can false-pass if an overload exists or expected signature is missing.

Patch with exact signatures:

DO $$
BEGIN
  IF to_regprocedure('public.fn_content_hash(text)') IS NULL THEN RAISE EXCEPTION 'missing fn_content_hash(text)'; END IF;
  IF to_regprocedure('public.fn_iu_resolve_default(text,text,text)') IS NULL THEN RAISE EXCEPTION 'missing fn_iu_resolve_default(text,text,text)'; END IF;
  IF to_regprocedure('public.fn_iu_classify_existing(text)') IS NULL THEN RAISE EXCEPTION 'missing fn_iu_classify_existing(text)'; END IF;
  IF to_regprocedure('public.fn_iu_create_preflight()') IS NULL THEN RAISE EXCEPTION 'missing fn_iu_create_preflight()'; END IF;
  IF to_regprocedure('public.fn_iu_verify_invariants(text)') IS NULL THEN RAISE EXCEPTION 'missing fn_iu_verify_invariants(text)'; END IF;
END $$;

Do not rely on name count.

P4 — Diagnostics must not abort the script before report upload

Rev8 correctly captures the main psql exit code, but after that it calls diagnostic psql while set -e is active again. If diagnostics fail, the script can exit before the final report instruction.

Patch:

DIAG_EXIT=0
if [ "$PSQL_EXIT" -ne 0 ]; then
  set +e
  docker exec -i "$PG_CONTAINER" psql ... > "$DIAG_LOG_PATH" 2>&1
  DIAG_EXIT=$?
  set -e
fi

Then continue to report upload instruction regardless of DIAG_EXIT.

P5 — Extract post-COMMIT status explicitly after successful psql

Rev8 returns structured post_commit_status in the log, but the shell does not extract it. This can still produce PASS-by-eyeballing.

Patch:

After PSQL_EXIT=0, run a separate read-only query using the exact pilot address and capture result in a variable/log:

POST_COMMIT_STATUS=$(docker exec -i "$PG_CONTAINER" psql -U "$PG_USER" -d "$PG_DB" -tA \
  -v pilot_addr="$PILOT_ADDRESS" <<'EOSQL'
SELECT CASE WHEN (v.verify->>'all_pass')::boolean THEN 'PASS' ELSE 'CRITICAL' END
FROM (SELECT public.fn_iu_verify_invariants(:'pilot_addr') AS verify) v;
EOSQL
)

Run under set +e and capture POST_EXIT too. Report:

• PSQL_EXIT
• POST_EXIT
• POST_COMMIT_STATUS

If POST_COMMIT_STATUS=CRITICAL, report phase FAIL/P3 BLOCKED even if PSQL_EXIT=0.

P6 — Main fn_iu_create should hard-fail if birth/invariants fail, not return created_birth_missing

Rev8 function can return created_birth_missing with only a warning if birth is missing.

For the canonical fn_iu_create path, that is too weak. Since this is the main contract, if birth is missing after create despite preflight, the function should raise exception and roll back the IU/UV row. The auxiliary/backfill path remains for non-canonical direct inserts or legacy drift.

Patch inside fn_iu_create:

• after IU/UV/anchor wiring, call public.fn_iu_verify_invariants(btrim(p_canonical_address)) or at least verify birth + version + anchors;
• if not all_pass, RAISE EXCEPTION 'fn_iu_create invariant failed: %', verify_json;
• return only status='created' when invariant passes.

This keeps canonical creation strong. The backup engine handles outside-contract births; the main native contract should not knowingly commit a missing-birth result.

P7 — Unique guard discovery should support multiple equivalent guard names or fail explicitly

Rev8 selects one canonical-address unique guard. If schema evolution adds a redundant equivalent unique constraint/index, the function may catch a different equivalent unique violation and re-raise.

Choose one of two policies and state it:

Strict v1 recommended: exactly one canonical-address unique guard is allowed. If more than one equivalent sole-key unique guard exists, STOP before BEGIN and function also raises schema drift.

Implementation:

• preflight count accepted canonical guards;
• if count != 1 → STOP;
• function can safely compare one name.

This is better than silently choosing one.

P8 — If helper/preflight uses current trigger/function names, report them as observed contract evidence

Rev8 relies on public.fn_iu_create_preflight(), which already checks triggers. Good. Report should include the preflight JSON from log as evidence so future schema evolution can see which trigger/function names/timing were observed.

Patch report requirement:

• include fn_iu_create_preflight() JSON excerpt.

P9 — Report should distinguish phase result from SQL exit result

Rev8 report mentions PSQL_EXIT and post-commit. Add explicit final status fields:

## Final verdict
- sql_exit: 0/nonzero
- post_commit_status: PASS/CRITICAL/NOT_RUN
- diagnostics_exit: 0/nonzero/not_run
- phase_status: PASS/FAIL
- p3_readiness: READY/BLOCKED

This avoids treating PSQL_EXIT=0 as automatic phase PASS.

Directive to Opus

Patch P2 prompt to rev9 with P1–P9.

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

Rev8 is close. The remaining issues are exactly the kind that matter under scale and schema evolution: environment defaults must be overridable, address generation must not accept malformed UUID suffixes, helper signatures must be exact, diagnostics must not abort report upload, post-commit status must be machine-captured, and the canonical creation path must not commit if birth/invariants are missing.