GPT Review — 22-P3-P2 Trigger Guard Prompt rev4

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 rev4

Verdict

Do not dispatch rev4. Rev5 required with 3 small fixes.

Rev4 fixed the load-bearing issues from rev3: GUC pilot handling, REVOKE PUBLIC, rollback cleanup, and p3p3 readiness. It is close.

Remaining issues are narrow execution/reporting fixes, not design changes.

Required rev5 patches

P1 — Post-rollback final verify must not expect pilot invariants if canonical test failed

Rev4 always runs:

POST_RESULT=$(... fn_iu_verify_invariants(:'pilot_addr') ...)

If canonical create failed, the pilot does not exist, so POST_STATUS may become CRITICAL/INVALID. That is fine for FAIL verdict, but the report should not make it look like an additional invariant failure after cleanup.

Patch:

if [ "$CANONICAL_STATUS" = "PASS" ]; then
  # run pilot invariant post verify
else
  POST_STATUS="NOT_RUN"
  POST_EXIT=0
fi

Final verdict already requires POST_STATUS=PASS for success, so this remains safe and clearer.

P2 — Failure after mode update should attempt to restore mode to prepared

Rev4 rollback cleanup only runs before mode update, when ALL_PASS=false. If mode update succeeds but final verify later fails, gateway.mode remains enforced while phase fails. That can leave misleading policy state.

Patch after final verify if final success condition is false and GW_MODE=enforced:

• If phase would fail and GW_MODE='enforced', run a small cleanup mode reset:

UPDATE public.dot_config
SET value='prepared', updated_at=now()
WHERE key='iu_create.gateway.mode';

Do not drop guard triggers/functions at this late point unless rollback path explicitly decides so; just avoid misleading policy mode. Capture:

MODE_RESET_EXIT=...
mode_reset_status=PASS/FAIL/NOT_RUN

If mode reset fails, phase_status=CRITICAL.

P3 — Final verdict should support CRITICAL when rollback/mode reset fails

Rev4 prints CRITICAL: rollback failed but still outputs phase_status=FAIL. For machine consumers, add phase_status=CRITICAL if rollback cleanup or mode reset fails.

Patch final logic:

• Success → phase_status=PASS, p3p3_readiness=READY.
• Else if ROLLBACK_STATUS=FAIL or MODE_RESET_STATUS=FAIL → phase_status=CRITICAL, p3p3_readiness=BLOCKED.
• Else → phase_status=FAIL, p3p3_readiness=BLOCKED.

Optional but useful — initialize mode reset vars

Add:

MODE_RESET_EXIT=0
MODE_RESET_STATUS="NOT_RUN"

at initialization, and echo them in final verdict.

Do not change

• Keep GUC pilot handling.
• Keep separate sessions.
• Keep SECURITY DEFINER + REVOKE PUBLIC.
• Keep rollback cleanup for failed tests.
• Keep no table permission/Directus/DOT/adapter changes.
• Do not add architecture scope.

Directive to Opus

Patch P3-P2 prompt to rev5 with exactly P1–P3. This is likely the last patch before dispatch if applied cleanly.

Return rev5 for final approval. Do not dispatch.

Summary

Rev4 is almost ready. Rev5 should make failure reporting/state restoration cleaner: skip pilot invariant verification if no pilot exists, reset mode if final verify fails after enforcement, and emit CRITICAL as a machine status when cleanup fails.