GPT Review — 22-P2 Main Functions Prompt Draft

Date: 2026-05-06 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/22-p2-iu-native-create-main-functions-prompt.md draft rev1

Verdict

Do not dispatch. Rev2 required.

The P2 draft has the right overall shape: native plan function, main writer function, birth by trigger, no raw birth_registry insert, idempotency, rollback discipline. But because P2 creates real rows and functions, several issues must be fixed before execution.

What is good

• Separates fn_iu_create_plan from fn_iu_create.
• Uses P1 helpers.
• Does not raw insert into birth_registry.
• Attempts idempotency via classify + unique violation handling.
• Uses transaction wrapping.
• Has post-COMMIT verification.
• Keeps adapter/DOT out of scope.

Required rev2 patches

P1 — Fix fn_iu_create_plan.would_create logic

Current code:

'would_create', v_existing IS NULL AND array_length(v_issues,1) IS NULL

But fn_iu_classify_existing() returns JSON not_found, not SQL NULL. Therefore normal new addresses produce v_existing IS NOT NULL, so would_create=false even when creation is possible.

Patch:

'would_create',
  COALESCE(v_existing->>'status','not_found') = 'not_found'
  AND array_length(v_issues,1) IS NULL

Also existing should only be non-null when status is not not_found.

P2 — Do not hardcode pilot address

pilot.p2.native.001 is a fixed runtime value. It may already exist on rerun or future environment.

Patch:

• Generate pilot address dynamically inside the test block, e.g. pilot.p2.native.<timestamp/random>.
• Record the generated address in report.
• Before execute, assert it does not exist.
• Do not cleanup unless approved.

This keeps tests rerunnable without manual edit.

P3 — REVOKE/GRANT must use full function signatures

Current:

REVOKE ALL ON FUNCTION public.fn_iu_create_plan FROM PUBLIC;
REVOKE ALL ON FUNCTION public.fn_iu_create FROM PUBLIC;
GRANT EXECUTE ON FUNCTION public.fn_iu_create TO directus;

PostgreSQL function privileges require exact function signature when overloaded/default args exist.

Patch with full signatures:

REVOKE ALL ON FUNCTION public.fn_iu_create_plan(text,text,text,text,text,text,text,text,uuid) FROM PUBLIC;
REVOKE ALL ON FUNCTION public.fn_iu_create(text,text,text,text,text,text,text,text,uuid) FROM PUBLIC;

Same for GRANT. If signature changes after schema-type review, update accordingly.

P4 — Do not hardcode directus as grant target without role gate

P0 found directus as current candidate, but P2 should still re-check and record approved role.

Patch:

• preflight records candidate adapter roles;
• if directus exists and is still approved by P0/P1 evidence, grant to it;
• report that grant target is current environment candidate, not timeless design;
• if role absent, do not silently “success”; mark permission grant skipped/blocker for adapter readiness.

P5 — Preflight must verify column types, not only helper preflight columns

P1 helper preflight verifies columns exist. P2 writes values into those columns, so types matter.

Before choosing exact function signature and INSERT casts, P2 must inspect/report types for written columns:

• information_unit.id
• canonical_address
• unit_kind
• owner_ref
• created_by
• updated_by
• identity_profile
• parent_or_container_ref
• version_anchor_ref
• content_anchor_ref
• unit_version.id
• unit_version.unit_id
• body
• content_hash
• version_seq
• created_by

Current signature uses p_parent_ref uuid, but parent_or_container_ref may not be uuid. Do not assume. Align signature/casts with actual schema or STOP for redesign.

P6 — Publication type must be validated or omitted intentionally

Current function accepts p_publication_type and puts it into identity_profile.publication_type_ref without vocab validation. P2-P0 earlier found L1 may validate publication/publication_type via dot_config.

Patch:

• If p_publication_type is provided, validate via fn_iu_resolve_default(p_publication_type, 'iu_create.default_publication_type', 'vocab.publication_type.') or the actual prefix found in P0.
• If publication type is optional and absent, omit it.
• If prefix/config is not established, reject explicit publication type with clear error rather than silently insert unvalidated value.

P7 — Existing incomplete states must not be returned as success

fn_iu_create currently returns v_existing for any status not not_found. That is okay only if caller/report treats non-complete states as warnings/blockers.

Patch:

• If exists_complete → return status exists_complete.
• If exists_missing_birth, exists_missing_version, exists_anchor_invalid, exists_duplicate_version → return same status with action_required=true and health_signal_needed=true.
• Do not let adapters interpret these as success.
• Do not auto-backfill inside create.

P8 — fn_iu_create_plan should not use SECURITY DEFINER unless justified

Plan is read-only but reads tables/config. SECURITY DEFINER may be acceptable if adapter roles lack read access, but P2 prompt must justify it.

Patch:

• Decide and document: SECURITY DEFINER for plan because adapter role may not have direct table/catalog read; or SECURITY INVOKER if direct read is intended.
• If SECURITY DEFINER, revoke PUBLIC and grant exact role as with create.

P9 — Avoid full content hash in plan output unless approved

Plan currently returns content_hash_preview but it is the full hash. This is not body leakage, but logs may become content fingerprints.

Patch:

• return hash_prefix or content_hash_preview = left(hash, 12) by default;
• full hash can be returned by fn_iu_create after actual creation.

P10 — Tests inside transaction need expected status parsing, not comments only

The prompt says expected statuses in comments, but Agent could eyeball them. For writer-phase, require explicit checks:

• plan_full JSON status/would_create must be asserted;
• row counts after plan must match baseline;
• create_result status must be created and birth_verified=true;
• idempotency result must be exists_complete;
• verify invariants all_pass=true.

If any assertion fails → ROLLBACK.

P11 — Post-COMMIT failure handling must be explicit

If COMMIT succeeds but post-COMMIT verify fails, rollback is no longer possible.

Patch report/failure section:

• mark CRITICAL;
• do not cleanup unless approved;
• record pilot address and diagnostic;
• stop before P3.

P12 — Avoid relying on current FK initially-deferred state in design

Draft has dynamic deferral in code, good. Keep it. But P2 preflight should verify exact-one FK again and record condeferred. Do not simplify based on current state.

P13 — Use CREATE FUNCTION public.*, no CREATE OR REPLACE

Draft does this correctly. Keep it and add explicit conflict check with public schema and exact names/signatures.

P14 — Grant should not be the only permission story

After grant, report routine privileges for both functions and verify PUBLIC absent. If grant target skipped, mark P3 adapter readiness blocker.

Directive to Opus

Patch P2 prompt to rev2 with P1–P14. Do not dispatch after patch; return for GPT/User review.

Hard boundaries remain

• no dispatch yet;
• no raw birth_registry insert;
• no DOT adapter;
• no dot_tools registration;
• no default seeding;
• no cleanup pilot;
• no retry/improvise on SQL failure.

Summary

The draft is conceptually correct but not execution-safe yet. The biggest bugs are would_create=false for new rows, fixed pilot address, missing function signatures in GRANT/REVOKE, missing schema type verification, and unvalidated publication type.