GPT Review — 23-P3B Schema Prompt rev2

Date: 2026-05-07
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3b-iu-edit-draft-schema-prompt.md rev2

Verdict

Rev2 is much stronger but NOT ready to dispatch. Rev3 required.

Opus correctly implemented 19/20 requested hardening fixes and the schema remains within P3B boundaries. The pushback on cross-field workflow CHECK constraints is accepted.

However, rev2 has one execution blocker and a few reporting/robustness issues that should be patched before Agent execution.

Accepted Opus pushback: no cross-field workflow CHECKs

GPT accepts the pushback on fix #9.

Do not add schema CHECKs such as:

• applied_version_ref IS NULL OR draft_status='applied'
• stale_at IS NULL OR draft_status='stale_base'

Reason: these are workflow/business rules and should be enforced by canonical functions, not rigid table constraints. Field-level integrity checks are enough for P3B:

• enum values;
• non-empty text;
• positive base_version_seq;
• non-empty hashes.

This preserves Phase 1.5 flexibility such as stale → withdrawn without ALTER CONSTRAINT debt.

Accepted rev2 improvements

• Environment defaults added.
• Missing variables initialized.
• Similar-table check narrowed.
• Schema sanity is a hard gate.
• iu_edit.% keys reconciled.
• Owner change moved toward transaction-safe pattern.
• Owner quoting uses format('%I').
• PUBLIC write grants are disallowed.
• canonical_address denormalized caveat added.
• base_version_seq > 0 check added.
• hash non-empty checks added.
• columns/constraints/indexes verified by name/type.
• JSONB defaults fail if missing.
• no-new-functions verification added.
• partial DDL failure can become CRITICAL.
• owner/grants verification added.
• action fields added to report.

Required rev3 fixes

P1 — BLOCKER: owner GUC is set in the wrong psql session

Rev2 runs:

"${PSQL[@]}" -c "SELECT set_config('app.p3b_owner', '$IU_OWNER', false);"

Then it opens a new psql session for the DDL heredoc. Session GUCs do not carry over to the new session. Therefore:

current_setting('app.p3b_owner')

inside the DDL transaction will fail or be missing.

Patch by passing the owner into the same psql session that runs DDL:

"${PSQL[@]}" -v p3b_owner="$IU_OWNER" <<'DDL_SQL' || DDL_EXIT=$?
BEGIN;
SELECT set_config('app.p3b_owner', :'p3b_owner', true);
...
DO $$
DECLARE
  v_owner text := current_setting('app.p3b_owner');
BEGIN
  EXECUTE format('ALTER TABLE public.unit_edit_draft OWNER TO %I', v_owner);
  EXECUTE format('ALTER TABLE public.unit_edit_comment OWNER TO %I', v_owner);
END;
$$;
COMMIT;
DDL_SQL

Remove the separate pre-DDL set_config psql call.

P2 — Initialize V1–V13 variables explicitly

Rev2 report references V1–V13, but setup no longer initializes them. Bash currently does not use set -u, so this may not crash, but reports on preflight failure become messy.

Initialize:

V1="NOT_RUN"; V2="NOT_RUN"; V3="NOT_RUN"; V4="NOT_RUN"; V5="NOT_RUN"; V6="NOT_RUN"; V7="NOT_RUN"
V8="NOT_RUN"; V9="NOT_RUN"; V10="NOT_RUN"; V11="NOT_RUN"; V12="NOT_RUN"; V13="NOT_RUN"

P3 — Make POLICY_KEYS_ACTION truthful

Rev2 always sets:

POLICY_KEYS_ACTION="SEEDED"

even when both keys already existed and ON CONFLICT DO NOTHING skipped them.

Patch after successful DDL:

• if no relevant keys existed before → SEEDED
• if exact keys existed before → SKIPPED_EXISTING
• if one existed and one inserted → PARTIAL_SEEDED

Simple acceptable version: capture POLICY_KEY_COUNT_BEFORE and POLICY_KEY_COUNT_AFTER for the two exact keys and set action accordingly.

P4 — Partial DDL failure CRITICAL check must include sort_order and policy keys

Rev2 captures:

• partial draft table;
• partial comment table;
• partial sort column;

but only uses draft/comment table existence to mark CRITICAL.

Patch:

If DDL fails and any of these exist unexpectedly, mark PHASE_STATUS=CRITICAL:

• unit_edit_draft;
• unit_edit_comment;
• information_unit.sort_order newly added when it did not exist before;
• iu_edit.policy.default_mode / iu_edit.schema.version newly inserted.

This is mostly defensive because PG DDL is transactional, but the report should be accurate.

P5 — Verify sort_order index by intended state, not only added state

Rev2 checks idx_iu_parent_sort only if SORT_ORDER_ACTION=ADDED.

If sort_order already existed from a previous partial/approved run, the intended schema should still be reconciled. Patch:

• If sort_order exists and idx_iu_parent_sort exists → OK.
• If sort_order existed but index missing → either STOP preflight for reconciliation or create the index in DDL and report SORT_ORDER_ACTION=INDEX_ADDED_FOR_EXISTING_COLUMN.

Recommended: preflight detects this state and STOPs, because rev2 design is not intended as an idempotent repair pack.

P6 — Constraint verification should schema-qualify

Rev2 checks information_schema.table_constraints by constraint_name and table_name only. Add table_schema='public' to avoid false matches.

Apply to V6 and V7.

P7 — Function-count check should list unexpected functions if changed

Current V12 compares counts. If fail, report the before/after list to speed debugging.

Patch:

• capture FN_LIST_BEFORE and FN_LIST_AFTER for matching edit/draft/comment functions;
• include in report when V12 fails.

P8 — Add final explicit boundaries check for no IU/UV row mutation

V10 counts IU/UV unchanged. Good. Add exact statement in report:

• iu_uv_rows_unchanged=PASS/FAIL

This makes boundary compliance machine-readable.

Directive to Opus

Patch P3B prompt to rev3 with P1–P8.

Path:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3b-iu-edit-draft-schema-prompt.md

Do not dispatch after patch. Return for GPT/User review.

Hard boundaries remain

• No functions.
• No trigger changes.
• No gateway changes.
• No IU/UV row mutations.
• No vector mutation.
• No cleanup.
• No retry / no improvise.

Summary

Rev2 is close. The main blocker is that owner GUC is set in a separate psql session, so ownership changes inside the DDL transaction will fail. Rev3 should fix that and tighten reporting/partial-state checks. After rev3, the prompt should likely be dispatch-ready if no new issue appears.