GPT Review — 22-P2 Main Functions Prompt rev9

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 rev9

Verdict

Do not dispatch rev9. Rev10 required.

Rev9 is stronger: env defaults, strict regex, exact helper signatures, diagnostic safety, separate post-commit machine status, and canonical birth hard-fail are all correct. However, a final shell/SQL semantics pass found several last-mile issues that should be patched before writer-phase execution.

Required rev10 patches

P1 — Use bash arrays for psql commands, not command strings

Rev9 defines:

PSQL_CMD="docker exec -i $PG_CONTAINER psql ..."
PSQL_RO="docker exec -i $PG_CONTAINER psql ..."
...
$PSQL_CMD -v pilot_addr=...
$PSQL_RO <<POSTQL

This is fragile if variables ever contain spaces/special chars, and it teaches command-string execution. Use arrays:

PSQL_CMD=(docker exec -i "$PG_CONTAINER" psql -v ON_ERROR_STOP=1 -U "$PG_USER" -d "$PG_DB")
PSQL_RO=(docker exec -i "$PG_CONTAINER" psql -U "$PG_USER" -d "$PG_DB" -tA)

"${PSQL_CMD[@]}" -v pilot_addr="$PILOT_ADDRESS" ...
"${PSQL_RO[@]}" <<POSTQL

P2 — Only run post-COMMIT verify if main psql succeeded

Rev9 always runs:

POST_RESULT=$($PSQL_RO <<POSTQL ... fn_iu_verify_invariants('$PILOT_ADDRESS') ...)

even if PSQL_EXIT != 0. If the transaction rolled back, fn_iu_verify_invariants or the pilot row may not exist, producing confusing secondary errors.

Patch:

• If PSQL_EXIT=0, run post-commit verification query.
• If PSQL_EXIT!=0, set POST_COMMIT_STATUS=NOT_RUN and POST_EXIT=not_run; rely on diagnostics.

P3 — Avoid SQL literal for PILOT_ADDRESS in post/diagnostic queries

Rev9 uses:

public.fn_iu_verify_invariants('$PILOT_ADDRESS')

The address is regex-limited, so risk is low, but we already established no manual substitution/literal insertion. Use psql variables consistently:

"${PSQL_RO[@]}" -v pilot_addr="$PILOT_ADDRESS" <<'POSTQL'
SELECT ... public.fn_iu_verify_invariants(:'pilot_addr') ...;
POSTQL

Same for diagnostics.

P4 — Unique guard count must not double-count constraint + backing index as two guards

Rev9 counts unique constraints first; if count is zero, it counts unique indexes. That is better. But inside fn_iu_create, it repeats this logic and then compares CONSTRAINT_NAME from unique_violation against v_ca_unique_guard.

If the guard is a unique index (not constraint), CONSTRAINT_NAME behavior may report index name or may not be portable. This may be okay, but the prompt should require a test for the current environment:

• force an idempotency call after pilot creation;
• ensure it returns exists_complete, which already tests normal duplicate pre-classify path;
• additionally test a direct race/catch path is hard to simulate and can be TD.

Patch report requirement:

• report whether canonical guard discovered was constraint or index;
• if index, mark unique_violation_catch_path=UNVERIFIED_TD unless explicitly tested;
• correctness still maintained because pre-classify + advisory lock avoid normal catch path.

Alternative stricter v1: require unique constraint, not bare unique index, for unique_violation catch semantics. If only index exists, STOP. Since current P0 showed a named constraint, this is acceptable and simpler.

Recommended for rev10: require unique constraint for P2 writer v1; unique-index fallback can be deferred to future design. This reduces ambiguity in CONSTRAINT_NAME.

P5 — fn_iu_create_plan SECURITY DEFINER may be unnecessary but acceptable; report rationale

Rev9 keeps plan as SECURITY DEFINER. This was previously allowed if justified. Add report field:

• plan_security_definer_rationale: adapter may lack direct reads; function output redacts body and full hash.

This is not a blocker but should be explicit.

P6 — Post-commit status should handle NULL/non-boolean all_pass

Rev9 query casts:

(v.vj->>'all_pass')::boolean

If verify_json is malformed or missing all_pass, this can error or produce NULL. For robust reporting:

CASE WHEN COALESCE((v.vj->>'all_pass')::boolean, false) THEN 'PASS' ELSE 'CRITICAL' END

Use this both in in-psql post-COMMIT SELECT and separate shell post verify.

P7 — make_uuid fallback via PG before main transaction can fail under set -e status ambiguity

The script does not set set -euo pipefail at top anymore. That may be intentional to keep reporting alive, but address generation failures should be hard fail before mutation.

Patch:

• Add set -uo pipefail at top, not -e globally; or explicitly validate each UUID suffix.
• After make_uuid | cut -c1-8, validate suffix strict [0-9a-f]{8}. Already done by address regex, so acceptable.
• Add note: address generation failure exits before any psql mutation.

P8 — Report should include whether functions existed after COMMIT if PSQL_EXIT=0

If PSQL succeeds, report should still include exact to_regprocedure check for both main functions. This helps P3 readiness and future audit.

Add to post-success read-only check or include from log.

Directive to Opus

Patch P2 prompt to rev10 with P1–P8.

Do not dispatch after patch; return for GPT/User final 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

Rev9 is very close. The remaining changes are shell-safety and ambiguity reduction. The main architectural recommendation is to require a true unique constraint for the first writer implementation, rather than supporting bare unique indexes whose exception diagnostic semantics are less clear.