GPT Review — 22-P0 Report and P1 Directive

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

• knowledge/dev/laws/dieu44-trien-khai/reports/22-p0-iu-native-create-contract-inspection-report.md
• knowledge/dev/laws/dieu44-trien-khai/reviews/opus-review-22-p0-inspection-and-p1-proposal-2026-05-06.md

Verdict

22-P0 PASS. Proceed to P1 prompt design, with corrections to Opus proposal.

P0 was well executed and gives enough evidence for the next gate.

Accepted facts:

• No existing fn_iu_create / native IU creation wrapper found.
• Contract columns are present.
• IU→UV deferrable FK candidate count = 1.
• FK is currently INITIALLY DEFERRED.
• IU triggers are enabled: birth, L1, L2, updated_at.
• Unique constraint exists on canonical_address.
• digest(text,text) and gen_random_uuid() are available.
• Adapter role candidate is directus, based on current role inventory.
• fn_sbx_compute_content_hash(4 args) exists and must be inspected before deciding reuse.
• No iu_create.* defaults exist yet.
• Existing pilot row should be kept.

Corrections to Opus proposal

C1 — Do not drop dynamic FK handling only because current FK is INITIALLY DEFERRED

Opus proposes to remove dynamic SET CONSTRAINTS logic because current FK is INITIALLY DEFERRED.

Partially agree: in the current environment, no explicit SET CONSTRAINTS is needed.

But for a durable contract, do not bake in the assumption that this will always be initially deferred. P1/P2 design should keep this runtime-safe policy:

• discover exactly one deferrable IU→UV FK;
• if condeferred=true, no explicit SET needed;
• if condeferrable=true and condeferred=false, dynamically defer the discovered constraint inside the create function;
• if no exact deferrable FK or ambiguous FK → STOP.

This avoids hardcoding current environment behavior.

C2 — Do not require caller to remember vocab just because there is one value today

Opus says caller can be explicit because there is only one vocab value per type. This violates the “mẹ chỉ sinh” philosophy.

Correct policy:

• If explicit arg is provided → validate and use it.
• Else if iu_create.default_* exists → use configured default.
• Else if exactly one valid vocab value exists for that dimension → auto-resolve it.
• Else STOP with available choices and ask for explicit/default config.

This is not hardcode: it is runtime metadata resolution.

Do not seed defaults in P1 unless separately approved. But function must be able to auto-resolve the single-value case.

C3 — fn_sbx_compute_content_hash must be inspected with deterministic criteria

Do not let Agent “decide at will.” P1 prompt should inspect:

SELECT pg_get_functiondef('fn_sbx_compute_content_hash'::regproc);

and/or exact signature via pg_proc.

Reuse only if it clearly supports the IU content-hash contract:

• deterministic/immutable;
• accepts enough inputs or can be safely called with body/canonical/version context;
• returns text/hash value compatible with unit_version.content_hash;
• does not depend on sandbox-only semantics that would make IU creation wrong.

If unclear, do not reuse directly. Create fn_content_hash(text) as a small stable wrapper using digest(text,'sha256'), and record TD to rationalize with fn_sbx_compute_content_hash later.

C4 — P1 should remain helper/preflight function phase only

P1 may create helper functions, but must not create IU rows and must not create the main execute function unless the previously approved gate says so.

Recommended P1 scope:

• inspect hash function source/signature;
• create or define hash helper according to deterministic branch;
• create fn_iu_resolve_default;
• create fn_iu_classify_existing;
• create fn_iu_create_preflight;
• optionally create fn_iu_verify_invariants only if it does not require pilot execution;
• no fn_iu_create main execute function yet if P2 is meant for main function;
• no IU/UV rows;
• no DOT adapter;
• no dot_tools registration.

C5 — Keep existing pilot row

Agree with Opus. Keep pilot.iu0.test-001. Future pilot uses a new canonical address. Cleanup is separate and should not be automatic.

Directive to Opus

Create P1 prompt:

knowledge/dev/laws/dieu44-trien-khai/prompts/22-p1-iu-native-create-helper-functions-prompt.md

P1 goal

Create helper/preflight functions required for the native IU creation contract. No IU rows. No main execute function unless explicitly scoped as helper-only is revised.

P1 prompt must include

1. Pre-read:

   • P0 report;
   • Opus P0 review;
   • this GPT review;
   • Pack 22 rev6.

2. Preflight re-check:

   • no existing helper with same name unless expected;
   • digest(text,text) availability;
   • gen_random_uuid() availability;
   • exact one deferrable IU→UV FK candidate;
   • current FK condeferred state;
   • dot_config vocab values.

3. Hash decision branch:

   • inspect fn_sbx_compute_content_hash definition;
   • reuse only if deterministic criteria pass;
   • otherwise create fn_content_hash(text) wrapper using digest.

4. Create helpers with schema qualification and safe search_path:

   • fn_content_hash if needed;
   • fn_iu_resolve_default(kind text, explicit_value text default null) or equivalent;
   • fn_iu_classify_existing(canonical_address text);
   • fn_iu_create_preflight() returning jsonb;
   • optionally fn_iu_verify_invariants(canonical_address text) if read-only and useful.

5. Vocab resolution policy:

   • explicit → validate;
   • configured default → validate;
   • exactly one vocab value → auto-resolve;
   • multiple/none → STOP with choices.

6. Permissions:

   • do not hardcode grant to directus without re-check;
   • use P0-confirmed adapter role if granting is required;
   • internal helpers should not be broadly executable unless needed.

7. Verification:

   • bash/SQL syntax ok;
   • functions exist with expected signatures;
   • helper dry tests only, no table mutation;
   • no IU/UV row count change;
   • no birth row creation.

8. Report path:

knowledge/dev/laws/dieu44-trien-khai/reports/22-p1-iu-native-create-helper-functions-report.md

Hard boundaries for P1

• no IU/UV row creation;
• no raw birth_registry insert;
• no DOT adapter;
• no dot_tools registration;
• no Pack 2C dispatch;
• no seeding iu_create.* defaults unless separately approved;
• no relying on current FK initially-deferred state as a timeless assumption.

Summary

P0 is green. P1 can start, but must preserve the native, metadata-driven philosophy: dynamic FK handling, runtime vocab resolution, deterministic hash-helper decision, and helper-only scope.