GPT Review — 23-P3 rev5 Approval and P3A Directive

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/23-p3-iu-proposal-merge-implementation-design.md rev5

Verdict

23-P3 rev5 PASS. Design approved for next-stage execution planning.

Rev5 adds the required Existing Implementation Compatibility / No-Duplicate Rule and now gives enough protection against redoing existing IU/schema work or creating a conflicting second system.

Do not execute runtime yet. Next step is to write P3A gateway allow-list execution design/prompt for review.

Accepted design state

The following are accepted as the Pack 23 design basis:

• PG-native editorial workflow: draft → comment → apply → official version.
• unit_edit_draft and unit_edit_comment as the new editorial layer.
• unit_version remains official applied history only.
• information_unit.sort_order as core column for structural ordering.
• Address-first Agent UX.
• Parent/child = structural containment only.
• Domain/professional traceability = universal_edges typed relations.
• Multi-axis text-as-code foundation retained as roadmap hooks.
• No-duplicate compatibility rules accepted.
• Pack 23 builds only the editorial edit layer; it reuses identity/versioning/registry/gateway/validation/graph/governance layers.

Accepted Opus additions

Preflight checklist as copyable execution pattern

Accepted. P3A/P3B/P3C prompts should include the preflight structure from §15.2, adapted to phase scope.

CREATE vs CREATE OR REPLACE distinction

Accepted:

• New objects: CREATE, never CREATE OR REPLACE.
• Existing patch target: CREATE OR REPLACE allowed only when patching a known existing function, with source hash before/after and rollback.

This is important for P3A because P3A will patch fn_iu_gateway_write_guard.

P3A next step

Create P3A execution design/prompt, not dispatch.

Path:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3a-iu-gateway-allow-list-patch-prompt.md

Report path:

knowledge/dev/laws/dieu44-trien-khai/reports/23-p3a-iu-gateway-allow-list-patch-report.md

P3A objective

Patch existing fn_iu_gateway_write_guard() from exact-marker mode to allow-list mode while preserving Pack 22 behavior.

Current accepted markers:

• fn_iu_create
• fn_iu_apply_edit_draft

Important: fn_iu_apply_edit_draft does not exist yet. P3A should only allow its future marker value. This is OK because no runtime call uses it until P3C.

Required P3A prompt structure

§0. Scope / boundaries

• Runtime mutation allowed only for:
  • dot_config key iu_create.gateway.allowed_marker_values;
  • patching existing public.fn_iu_gateway_write_guard().
• No table DDL.
• No new tables.
• No new edit functions.
• No trigger changes.
• No IU/UV row mutation except canonical smoke test if explicitly needed and approved in prompt.
• No cleanup pilots.
• No Pack 2C.

§1. Preflight

Must include hard gates:

1. Confirm fn_iu_gateway_write_guard() exists exactly once.
2. Capture md5(prosrc) before patch.
3. Confirm current guard still accepts fn_iu_create exact marker.
4. Confirm gateway triggers exist and are enabled:
   • trg_aa_iu_gateway_write_guard
   • trg_aa_uv_gateway_write_guard
5. Confirm dot_config table has unique key semantics / no duplicate gateway keys.
6. Check whether iu_create.gateway.allowed_marker_values already exists.
   • If exists with exact value fn_iu_create,fn_iu_apply_edit_draft, treat as already seeded.
   • If exists with incompatible value, STOP.
7. Confirm no unexpected function source patch already contains allow-list logic with different semantics.

§2. Transactional patch

Within one transaction:

1. Upsert/insert dot_config key:

iu_create.gateway.allowed_marker_values = fn_iu_create,fn_iu_apply_edit_draft

2. Patch fn_iu_gateway_write_guard() with CREATE OR REPLACE FUNCTION.

Behavior requirements:

• Read app.canonical_writer from session setting.
• Read allow-list from dot_config.
• Split by comma and trim whitespace.
• Accept if current marker equals any allowed value.
• Fallback to old exact marker key/value if allow-list key missing.
• Otherwise raise the same gateway blocked error style with README/canonical guidance.
• Preserve SECURITY DEFINER / search_path / owner/grants as Pack 22 pattern.

§3. Tests

Use separate sessions where needed.

Required tests:

1. Function source now has allow-list logic.
2. Dot_config key exists and value is exact expected value.
3. Existing fn_iu_create still works through gateway.
   • Prefer dry/small pilot canonical create only if prompt can create a unique pilot and retain it.
   • If avoiding new IU rows, use controlled transaction rollback test to set marker and test trigger behavior without commit; but ensure no false positives.
4. Direct IU INSERT without marker remains blocked.
5. Direct UV INSERT/UPDATE without marker remains blocked or remains covered as in Pack 22.
6. Marker fn_iu_apply_edit_draft is accepted by guard in a safe rollback test, since the function does not exist yet.
7. Marker not in allow-list remains blocked.
8. Gateway triggers still enabled and count unchanged.
9. PUBLIC privileges / grants are not broadened.

§4. Failure behavior

• If any test fails after patch, restore original function source if feasible and reset/remove iu_create.gateway.allowed_marker_values.
• If rollback/restore fails, report phase_status=CRITICAL.
• No retry/improvisation beyond prompt.
• Always upload report and log.

§5. Report requirements

Report must include:

• phase_status: PASS / FAIL / CRITICAL;
• p3b_readiness: READY / BLOCKED;
• source_hash_before;
• source_hash_after;
• allowed_marker_values;
• tests pass/fail table;
• rollback_status if any;
• confirmation that fn_iu_create still works;
• confirmation that wrong-door blocking still works;
• boundaries honored.

GPT review requirement

Opus should create the P3A prompt and stop for GPT/User review. Do not dispatch.

Hard boundaries

• No dispatch yet.
• No P3B schema DDL.
• No edit draft/comment tables.
• No edit functions.
• No vector mutation.
• No cleanup.
• No Pack 2C.

Summary

23-P3 design is now stable and compatible with existing IU infrastructure. The next work is a small infrastructure patch: expand the gateway from one exact marker to an explicit allow-list so future apply function can write IU/UV through the canonical path without weakening wrong-door blocking.