GPT Review — Pack 22 rev5 Final Hardcode Audit

Date: 2026-05-06 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/22-dot-iu-create-wrapper-design.md rev5

Verdict

Pack 22 rev5 is substantially strong, but still needs rev6 before execution prompt.

Rev5 fixed the major hardcode issues from rev4: constraint names, trigger names, unique constraint discovery, default vocab seeding. However, under the User’s strict “no hardcode, do once and survive change” principle, several remaining identifiers are still too fixed for a core native creation contract.

What is now acceptable

• Constraint names are discovered.
• Trigger names are no longer hardcoded.
• Unique constraint is discovered from catalog.
• UV birth expectation is metadata-driven.
• Default vocab is not blindly seeded.
• Search path is safer.
• Execution gates are separated.
• Advisory lock pushback is accepted: unique constraint is correctness; advisory lock is optimization.

Remaining issues requiring rev6

P1 — Role directus must not be hardcoded as the only grant target

Rev5 still says:

GRANT EXECUTE ON FUNCTION fn_iu_create TO directus;

This is a role hardcode. It may be true today, but not portable.

Rev6 should define role discovery/approval:

• P0 inspects roles and current execution identities:

SELECT current_user, session_user;
SELECT rolname FROM pg_roles ORDER BY rolname;

• Execution pack chooses grant targets from approved adapter roles.
• Design language should say GRANT EXECUTE TO <approved_adapter_role>.
• directus may be recorded as a snapshot/likely current adapter role, not a timeless target.

P2 — Gate function names as preflight dependencies need a catalog/metadata rationale

Rev5 improved from trigger-name hardcode to function-name discovery:

• fn_birth_registry_auto
• fn_iu_birth_gate_layer1
• fn_iu_birth_gate_layer2

This is better, but still name-coupled. For a durable contract, rev6 should clarify which names are:

• canonical law-governed function names that are part of the current contract; versus
• runtime observations that P0 must discover and verify.

Preferred rev6 design:

• P0 inventory lists all enabled triggers on information_unit with function names and trigger timing.
• P1/P2 implementation uses the P0-approved trigger inventory.
• Preflight verifies either:
  1. expected canonical functions are present, or
  2. equivalent trigger categories are present as approved by P0 report.

At minimum, the document must not imply those function names will always remain unchanged without governance.

P3 — Required column arrays are acceptable, but must be labelled as contract fields, not discovered truth

Rev5 uses arrays of required columns. That is not necessarily bad: a creation contract must require the fields it writes.

But the §0-AU audit says “mọi identifier ... discover from catalog,” which conflicts with array-defined contract columns.

Rev6 should clarify:

• required columns are contract requirements;
• preflight discovers whether runtime satisfies the contract;
• they are not dynamic facts or stale counts.

This prevents future reviewers from treating all column names as forbidden literals.

P4 — Function names fn_iu_create, fn_iu_create_plan should be declared as proposed contract names, after P0 no-existing check

Rev5 says P0 inspects existing mechanisms, but the document still reads like these names are already final.

Rev6 should state:

• proposed names are provisional until P0 confirms no existing native IU creation function/tool exists;
• if one exists, the implementation must extend/adopt existing mechanism instead of creating duplicate names.

P5 — Adapter body safety should not include psql :'var' as a generic safe claim

Rev5 lists psql :'var' among safe options. This can still be unsafe or awkward for large multiline body unless implemented very carefully.

Rev6 should say:

• preferred adapter implementation: proper DB driver parameter binding or temp table/COPY reviewed pattern;
• psql variable interpolation requires separate review and is not automatically safe for arbitrary body.

P6 — Dynamic deferrable FK discovery must enforce “exactly one”

Rev5 discovers deferrable FK and says no hardcode, but the example uses LIMIT 1. That is unsafe if multiple candidates exist.

Rev6 should require:

• count candidates;
• if count != 1 → STOP;
• only then defer discovered constraint.

P7 — P0 should be the immediate next step, not execution function creation

Pack 22 is design. The next prompt should not jump to CREATE FUNCTION.

Next should be 22-P0 read-only inspection:

• existing PG functions;
• existing DOT/API/Directus hooks;
• actual IU/UV schema;
• current trigger inventory;
• actual roles;
• available vocab/defaults;
• exact deferrable FK candidates;
• required extensions/functions;
• current permissions.

Only after P0 report should Opus finalize the exact execution design.

Directive to Opus

Patch Pack 22 to rev6 with P1–P7.

Then create only a read-only P0 inspection prompt, not an execution prompt:

knowledge/dev/laws/dieu44-trien-khai/prompts/22-p0-iu-native-create-contract-inspection-prompt.md

P0 report path:

knowledge/dev/laws/dieu44-trien-khai/reports/22-p0-iu-native-create-contract-inspection-report.md

Required P0 inspection contents

1. Existing native creation mechanisms:
   • pg_proc search for IU/create functions;
   • DOT bin grep;
   • app/API hook search if accessible;
   • Directus extensions/hooks if present.
2. IU/UV schema required columns and constraints.
3. Deferrable FK IU→UV candidates; count must be shown.
4. Trigger inventory on information_unit:
   • timing;
   • enabled state;
   • function name;
   • trigger definition.
5. collection_registry metadata for IU/UV.
6. Vocab/default inventory:
   • vocab.unit_kind.%;
   • vocab.section_type.%;
   • iu_create.default_% keys if any.
7. Function/extension availability:
   • gen_random_uuid;
   • digest/pgcrypto;
   • any existing hash helper.
8. Roles/permissions:
   • current_user/session_user;
   • candidate adapter roles;
   • current direct table privileges on IU/UV if queryable.
9. Recommendation:
   • create new fn_iu_create or extend existing;
   • exact grant target candidates;
   • whether defaults should be explicit only or configured.

Hard boundaries

• read-only only for P0;
• no CREATE FUNCTION;
• no DDL/DML;
• no DOT patch;
• no Pack 2C dispatch;
• no adapter implementation.

Summary

Rev5 is close, but the “no hardcode” standard now needs one final tightening: roles, gate-function dependency semantics, exactly-one constraint discovery, and a mandatory P0 runtime inventory before any function creation.