GPT Review — 22-P2 Execution PASS and P3 Directive

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed:

• knowledge/dev/laws/dieu44-trien-khai/reports/22-p2-iu-native-create-main-functions-report.md
• knowledge/dev/laws/dieu44-trien-khai/reports/22-p2-iu-native-create-main-functions-log.md
• knowledge/dev/laws/dieu44-trien-khai/reviews/opus-review-22-p2-execution-pass-2026-05-06.md

Verdict

22-P2 PASS. P2 COMPLETE.

Opus review is accurate. Agent executed P2 rev12 correctly. No additional Agent action is needed for P2.

Accepted facts

Rev12 final verdict

All required verdict gates passed:

Gate	Value	Status
init_exit	0	PASS
sql_exit	0	PASS
post_exit	0	PASS
post_commit_status	PASS	PASS
fcheck_status	PASS	PASS
phase_status	PASS	PASS
p3_readiness	READY	READY

Functions created

• public.fn_iu_create(...)
  • owner: directus
  • SECURITY DEFINER
  • VOLATILE
  • search_path=pg_catalog,public
• public.fn_iu_create_plan(...)
  • owner: directus
  • SECURITY DEFINER
  • STABLE
  • search_path=pg_catalog,public

Permissions

• PUBLIC execute is revoked.
• Only directus has EXECUTE per report.

Pilot proof

Pilot address:

pilot.p2.20260506-045033.e0ae7ec5

Verified:

• IU row created exactly once.
• UV row created exactly once.
• birth row exists: information_unit::<iu_id>.
• idempotent re-call returned exists_complete.
• no duplicate row.
• pilot retained intentionally; no cleanup.

Three-layer verify

All invariant checks passed:

1. fn_iu_create internal invariant verify before returning created.
2. In-transaction pilot post-create verify.
3. Post-COMMIT separate-session verify.

Observed invariant JSON:

{"all_pass": true, "i1_iu_exists": true, "i2_uv_linked": true, "i5_uv_birth_ok": true, "i4_birth_exists": true, "i3_anchors_exact": true}

Boundaries honored

No raw birth_registry insert. No CREATE OR REPLACE. No ASSERT. No manual substitution. No global set -e. No bare unique-index fallback. No created_birth_missing. No DOT adapter/registration. No default seed. No cleanup. No retry/improvise.

Interpretation

P2 created the native IU creation contract successfully.

This does not redesign the birth pipeline. It creates a canonical creation door above the existing birth system:

• fn_iu_create creates IU + first UV + anchors;
• existing triggers/gates create and validate birth;
• full invariants must pass before created returns;
• auxiliary/backfill/remediation remains for bypass, legacy, import, drift, and health incidents.

Non-blocking note

P-pub1/P-pub2 warnings are PILOT-ONLY L1 advisory warnings. They did not block P2. Production-gate policy around publication metadata may be addressed later, but it is not a P2 blocker.

Directive to Opus — next step

Do not dispatch P3 yet.

Create a P3 scope/design note, not an execution prompt, at:

knowledge/dev/laws/dieu44-trien-khai/design/22-p3-iu-native-create-adapter-scope.md

P3 must answer the integration question:

Now that the native PG contract exists, who is allowed to call it, through what interface, and how do we avoid reintroducing hardcoded/manual creation paths?

Required sections for P3 design

§1. P2 closure summary

Record P2 PASS facts and function signatures. Confirm pilot retained.

§2. Integration surfaces inventory

Investigate/describe possible callers:

• Directus/API role (directus already has EXECUTE);
• Agent/Claude Code path;
• DOT tool wrapper candidate;
• Directus UI/Flow candidate;
• future app/API endpoint;
• batch/import path;
• whether any existing tool already calls IU tables directly.

This section may require a read-only P3-P0 inspection prompt before execution.

§3. Canonical caller policy

Define:

• fn_iu_create is the canonical main write path for new IU rows.
• Direct table insert into information_unit is non-canonical except controlled migrations/imports.
• Any non-canonical path must be monitored as bypass risk.
• Existing incomplete states are health/remediation, not success.

§4. Adapter choice options

Compare options:

A. SQL-only contract for now; no adapter yet.
B. Thin CLI/DOT wrapper that only calls fn_iu_create.
C. Directus Flow/API endpoint.
D. Both wrapper + Directus endpoint.
E. Defer adapter; start dual-form authoring and manual DBA-only creates.

For each option, evaluate:

• hardcode risk;
• permission risk;
• operational simplicity;
• auditability;
• suitability for AI authoring;
• rollback/diagnostic behavior.

§5. Permission model

Clarify:

• directus currently has EXECUTE but is not timeless truth.
• Whether a dedicated role is needed later.
• Whether additional grants are needed for CLI/API.
• PUBLIC must remain revoked.

§6. DOT registration question

Decide whether fn_iu_create needs DOT registration now or later.

If yes, define whether registration is:

• tool registration;
• governance metadata only;
• health check registration;
• not needed because it is PG-native contract.

Do not perform registration in P3 design.

§7. Authoring workflow after P2

Tie to user question about composing IU directly:

• Before adapter: dual-form authoring — rendered document + IU map.
• After adapter: AI can create IU pieces through the canonical call path.
• Legacy docs still use cut-after/import pipeline.
• New plans should stop being document-only.

§8. P3 recommended route

Opus should recommend one route.

Preferred direction for discussion:

• Start with P3-P0 read-only integration inventory.
• Then implement the thinnest adapter possible.
• Do not build UI/Directus complexity until caller path is proven.

§9. Boundaries

P3 design must not mutate runtime.

No:

• function changes;
• table DDL;
• IU row creation;
• default seeding;
• DOT registration;
• adapter implementation;
• cleanup of P2 pilot;
• Pack 2C.

Expected Opus response

Opus should now write the P3 scope/design note and stop for GPT/User review.

It should not ask Agent to implement anything yet.

Summary

P2 is complete. The next problem is no longer “can the system create IU correctly?” It can. The next problem is governance of access: how agents, tools, Directus, API, and future authoring workflows call the native contract without bypassing it or reintroducing hardcode.