GPT Review — 22-P3-P2 Trigger Guard 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-p3-p2-iu-gateway-trigger-guard-prompt.md rev3

Verdict

Do not dispatch rev3. Rev4 required.

Rev3 is structurally correct and much closer, but three issues are still load-bearing:

1. psql variable interpolation inside DO $$ ... $$ is unsafe / likely invalid.
2. SECURITY DEFINER guard function may receive default PUBLIC EXECUTE unless explicitly revoked.
3. If TX1 commits guard triggers but later tests fail, system may be left half-enforced with gateway.mode not enforced or with failing canonical path.

These must be fixed before dispatch.

Required rev4 patches

P1 — Do not use :'pilot_addr' inside DO $$ ... $$

Rev3 contains lines like:

v_a:=:'pilot_addr';
...
WHERE canonical_address=:'pilot_addr'

These are inside dollar-quoted DO bodies. psql variable substitution inside dollar-quoted bodies is not reliable and can produce syntax errors at runtime.

Patch all psql-var usages inside DO $$ blocks by setting a session GUC before the DO block:

SELECT set_config('app.p3p2_pilot_addr', :'pilot_addr', false);

Then inside DO blocks use:

v_a := current_setting('app.p3p2_pilot_addr');

For block tests:

SELECT set_config('app.p3p2_pilot_addr', :'pilot_addr', false);

DO $$
DECLARE v_a text := current_setting('app.p3p2_pilot_addr');
...
WHERE canonical_address = v_a;
$$;

Apply this to canonical test and all direct block tests. Do not embed :'pilot_addr' inside dollar-quoted bodies.

P2 — Add a narrow REVOKE for the newly created guard function

Rev3 creates a SECURITY DEFINER function and then checks PUBLIC EXECUTE is absent. In PostgreSQL, new functions may receive PUBLIC EXECUTE by default unless default privileges were changed. If PUBLIC EXECUTE appears, TX1 fails.

Patch immediately after CREATE FUNCTION:

REVOKE ALL ON FUNCTION public.fn_iu_gateway_write_guard() FROM PUBLIC;

This is the only allowed GRANT/REVOKE in P3-P2 and only for the newly created guard function. It is not role separation and does not change table/Directus permissions.

Update Hard Boundaries wording:

• No GRANT/REVOKE except REVOKE PUBLIC on newly created fn_iu_gateway_write_guard().

Keep the PUBLIC check after the revoke.

P3 — Add explicit rollback cleanup if post-deploy tests fail

Rev3 commits guard function/triggers in TX1 before canonical/direct tests. If later tests fail, the system can be left with guard triggers active but gateway.mode not enforced, or worse, a broken canonical path.

Patch with an explicit rollback cleanup path after tests and before final verdict:

If any of these fail:

• CANONICAL_STATUS != PASS
• any direct block status != PASS
• POST_STATUS != PASS
• LEAK_STATUS != PASS
• MODE_EXIT != 0 or GW_MODE != enforced

then run cleanup transaction:

BEGIN;
DROP TRIGGER IF EXISTS trg_iu_gateway_write_guard ON public.information_unit;
DROP TRIGGER IF EXISTS trg_uv_gateway_write_guard ON public.unit_version;
DROP FUNCTION IF EXISTS public.fn_iu_gateway_write_guard();
UPDATE public.dot_config
SET value='prepared', updated_at=now()
WHERE key='iu_create.gateway.mode';
COMMIT;

Capture:

ROLLBACK_GUARD_EXIT=...
rollback_guard_status=PASS/FAIL/NOT_RUN

Final verdict logic:

• PASS only if all deploy/tests/final checks pass and GW_MODE=enforced.
• If tests fail but cleanup succeeds, phase_status=FAIL and p3p3_readiness=BLOCKED, but state is safely restored to prepared.
• If cleanup fails, phase_status=CRITICAL and p3p3_readiness=BLOCKED.

This cleanup is not “improvised cleanup”; it is an explicit rollback path for an enforcement deployment.

P4 — Final verdict should include p3p3_readiness

Add:

p3p3_readiness=READY/BLOCKED

P3-P2 PASS → READY for next governance step. Anything else → BLOCKED.

Do not change

• Keep separate sessions for canonical and block tests.
• Keep SECURITY DEFINER + search_path.
• Keep no table permission changes.
• Keep no Directus changes.
• Keep no detector/adapter/DOT.
• Keep compact structure.

Directive to Opus

Patch P3-P2 prompt to rev4 with exactly P1–P4.

This is still a small patch set, but all four are load-bearing for execution correctness. Do not add new architecture or additional review sections.

Return rev4 for GPT/User final review. Do not dispatch.

Summary

Rev3 has the right shape. Rev4 must fix psql variable handling, secure the new SECURITY DEFINER function, add a rollback path for failed post-deploy tests, and make readiness explicit.