KB-3535

GPT Review — 22-P2 Main Functions Prompt rev7

6 min read Revision 1
gpt-reviewpack-22p2fn-iu-createwriter-phaserev8-requirednot-dispatchable

GPT Review — 22-P2 Main Functions Prompt rev7

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 rev7

Verdict

Do not dispatch rev7 yet. Rev8 required.

Rev7 fixed the major prompt-structure issues: it is self-contained, uses psql variables/session settings, removes manual substitution, and fixes the int2vector unique-guard bug. However, several last execution-safety issues remain.

Required rev8 patches

P1 — set -e breaks the “always upload report” requirement

Rev7 shell uses:

set -euo pipefail
...
docker exec -i postgres psql ... <<'EOSQL'
...
EOSQL

PSQL_EXIT=$?

With set -e, if psql exits non-zero, the script exits immediately and never reaches PSQL_EXIT=$?. This directly violates the requirement that report must always be uploaded.

Patch:

Wrap the psql call with set +e / set -e, for example:

set +e
docker exec -i postgres psql ... <<'EOSQL'
...
EOSQL
PSQL_EXIT=$?
set -e

echo "PSQL_EXIT=$PSQL_EXIT"
# Continue to report generation/upload instructions regardless of PSQL_EXIT.

Or use if ! docker exec ...; then PSQL_EXIT=$?; fi carefully without losing the actual exit code.

P2 — Capture psql output to a log file for report

Rev7 says Agent should report results, but does not require capturing stdout/stderr.

For writer-phase, require:

LOG_PATH="/tmp/22-p2-iu-native-create.$(date -u +%Y%m%d-%H%M%S).log"
set +e
docker exec ... > "$LOG_PATH" 2>&1
PSQL_EXIT=$?
set -e
cat "$LOG_PATH"

Report must include LOG_PATH and relevant excerpts.

This is essential for post-COMMIT CRITICAL, COMMIT failure, or transaction rollback diagnosis.

P3 — Post-COMMIT structured result must be extracted from the log or queried separately

Rev7 returns a structured row, good. But the shell/report flow does not specify how Agent determines post_commit_status.

Patch:

After psql run:

  • if PSQL_EXIT=0, parse/report the post_commit_status row from the log; or run a separate read-only query using the captured pilot address:
SELECT CASE WHEN (v.verify->>'all_pass')::boolean THEN 'PASS' ELSE 'CRITICAL' END AS post_commit_status,
       v.verify AS verify_json
FROM (SELECT public.fn_iu_verify_invariants(:'pilot_addr') AS verify) v;
  • if PSQL_EXIT<>0, report phase_status=FAILED_BEFORE_OR_DURING_SQL; do not assume commit happened.

P4 — Failure path must run read-only post-failure checks when safe

If psql exits non-zero, Agent should run a separate read-only check to classify state:

  • do fn_iu_create / fn_iu_create_plan exist?
  • does PILOT_ADDRESS exist in information_unit?
  • does corresponding IU birth exist if pilot exists?

This is especially important if failure happened after COMMIT or during post-COMMIT query.

Patch report flow with a second read-only diagnostic query guarded by no mutation.

P5 — Address generation needs uuidgen fallback implemented, not just mentioned

Earlier versions mentioned fallback. Rev7 uses uuidgen directly. Minimal production robustness should implement fallback:

make_uuid() {
  if command -v uuidgen >/dev/null 2>&1; then uuidgen
  elif [ -r /proc/sys/kernel/random/uuid ]; then cat /proc/sys/kernel/random/uuid
  else
    docker exec postgres psql -U directus -d directus -tA -c "SELECT gen_random_uuid()"
  fi
}

Then use make_uuid for all three addresses.

P6 — Preflight exact helper count can false-pass if duplicate overloads exist

Rev7 checks count of helper function names = 5. If a duplicate overload exists for one helper and another helper is missing, count can still be 5.

Patch helper preflight to check expected signatures explicitly, or at least group by proname:

SELECT proname, count(*)
FROM pg_proc p JOIN pg_namespace n ON n.oid=p.pronamespace
WHERE n.nspname='public'
  AND proname IN (...)
GROUP BY proname;

Require exactly one row for each expected helper name and preferably exact signatures.

P7 — Main function conflict check should also block overloads explicitly

Rev7 blocks any fn_iu_create / fn_iu_create_plan by name. Good. Add wording:

  • overloads are intentionally blocked;
  • if found, STOP; no workaround.

This avoids Agent trying to create a different signature.

P8 — Report upload instruction must be operational, not just conceptual

Rev7 says “Agent: ALWAYS upload report,” but the shell block has no report upload step. That is acceptable if Agent Data upload is outside shell, but prompt must explicitly state:

  • after shell finishes, regardless of PSQL_EXIT, upload KB report;
  • if shell exits early before upload, that is a prompt violation;
  • include PSQL_EXIT, LOG_PATH, generated addresses, and diagnostic query output.

P9 — Directus grant report should distinguish owner implicit execute from explicit grant

P1 report said only owner directus had execute. In P2, if the function owner is directus, routine privileges may not show a separate explicit GRANT. The report should distinguish:

  • owner has implicit rights;
  • explicit grant exists or not;
  • adapter readiness is OK if approved adapter role is owner or has EXECUTE.

Do not rely solely on routine_privileges visual output.

Directive to Opus

Patch P2 prompt to rev8 with P1–P9.

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

Rev7 is conceptually close, but the shell error handling currently contradicts the “always upload report” rule. At writer-phase, logging and failure diagnostics are not optional. Patch rev8 so failures are captured, diagnosed, and reported instead of terminating the script silently.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-22-p2-main-functions-prompt-rev7-2026-05-06.md