GPT Review — 22-P3-P0 Inspection Prompt

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/22-p3-p0-iu-creation-gateway-inspection-prompt.md

Verdict

Direction correct. Rev2 required before dispatch.

The prompt covers the right scope and Opus’s two additions are correct:

1. §9 sequencing flag is important: current fn_iu_create does not set app.canonical_writer, so a trigger guard would block the canonical function unless the function is patched first.
2. §6 TAC deep analysis and §7 broad direct-write sweep should remain separate.

However, several inspection details need tightening to avoid false evidence, scale problems, and query fragility.

Required rev2 patches

P1 — Privilege inspection must include effective privileges, not only information_schema.table_privileges

information_schema.table_privileges can miss owner implicit privileges and role inheritance. Since L1 permission feasibility is a core question, add effective privilege checks using has_table_privilege across roles.

Add for IU/UV:

SELECT r.rolname,
       has_table_privilege(r.rolname, 'public.information_unit', 'INSERT') AS iu_insert,
       has_table_privilege(r.rolname, 'public.information_unit', 'UPDATE') AS iu_update,
       has_table_privilege(r.rolname, 'public.information_unit', 'DELETE') AS iu_delete,
       has_table_privilege(r.rolname, 'public.unit_version', 'INSERT') AS uv_insert,
       has_table_privilege(r.rolname, 'public.unit_version', 'UPDATE') AS uv_update,
       has_table_privilege(r.rolname, 'public.unit_version', 'DELETE') AS uv_delete
FROM pg_roles r
WHERE r.rolname NOT LIKE 'pg_%'
ORDER BY r.rolname;

This is more important than grant rows because owners always have implicit rights.

P2 — Function privilege inspection must include effective EXECUTE, not only routine_privileges

Add exact-signature checks:

SELECT r.rolname,
       has_function_privilege(r.rolname, 'public.fn_iu_create(text,text,text,text,text,text,text,text,uuid)', 'EXECUTE') AS can_create,
       has_function_privilege(r.rolname, 'public.fn_iu_create_plan(text,text,text,text,text,text,text,text,uuid)', 'EXECUTE') AS can_plan
FROM pg_roles r
WHERE r.rolname NOT LIKE 'pg_%'
ORDER BY r.rolname;

Report must distinguish owner implicit execute from explicit grants.

P3 — Directus dependency section should inspect admin roles and collection accessibility

Directus permissions alone may not show admin users/roles. Add read-only query on directus_roles if available:

SELECT id, name, admin_access, app_access
FROM public.directus_roles
ORDER BY name;

Also ask Agent to report whether admin_access roles can bypass collection permissions in the UI. Do not mutate permissions.

P4 — §8.1 must not run invariant check over all IUs unconditionally

The prompt currently runs fn_iu_verify_invariants on all IUs. That is fine today with 2 IUs, but it violates the scale design principle. At millions of IUs it can be expensive or disruptive.

Patch:

• First count IUs.
• If count <= 1000, run all.
• If count > 1000, run:
  • recent sample if timestamp exists;
  • pilot rows;
  • random/sample limit 100;
  • aggregate counts only.

Since current schema may not have created_at, do not rely on timestamp unless discovered. Use canonical address samples and limit.

P5 — IU birth missing count must be exact by entity_code join, not total IU minus birth count

Current §4.7 assumes count(information_unit) - count(birth_registry where collection_name='information_unit'). This can hide phantoms or duplicates.

Patch with join-based exact count:

SELECT
  count(*) AS total_iu,
  count(br.*) AS iu_with_birth,
  count(*) FILTER (WHERE br.id IS NULL) AS iu_missing_birth
FROM public.information_unit iu
LEFT JOIN public.birth_registry br
  ON br.collection_name='information_unit'
 AND br.entity_code = 'information_unit::' || iu.id::text;

Also report duplicate birth rows per IU if any.

P6 — Filesystem grep needs safety limits and excludes

Current grep scans /home /opt /root /tmp with broad includes and only pipes to head. head limits output but not necessarily scan cost.

Patch:

• use timeout if available;
• prefer rg if installed;
• exclude .git, node_modules, backups, large context-pack/log archives where possible;
• keep grep fallback;
• report if scan was truncated or timed out.

This prevents a read-only inspection from becoming slow/noisy.

P7 — Error handling must treat query errors as findings, not silently okay

The script logs SQL errors but the report template should require Agent to list query errors explicitly.

Add report section:

## Query Errors / Partial Data
- Query id:
- Error excerpt:
- Impact on recommendation:

Agent must not fix SQL or mutate schema; record errors and continue.

P8 — dot_config.description may not be stable

§5.1 selects description from dot_config. If the column is absent, the query errors. Because this prompt is about schema evolution, avoid assuming optional columns.

Patch either:

• first inspect columns of dot_config; or
• select only key, value in this read-only prompt.

Preferred: inspect columns then query key/value only.

P9 — Trigger order statement should be softened

The prompt says “ORDER BY tgname; this IS execution order for same timing.” PostgreSQL fires multiple triggers of the same kind in name order, but constraint triggers and BEFORE/AFTER categories differ. Reword to:

• “for same table/event/timing, ordinary trigger name order is relevant; report actual timing/event/type separately.”

Avoid over-claiming order.

P10 — fn_birth_registry_auto source should not be piped through head in a way that can cause noisy SIGPIPE

Not a blocker, but cleaner:

SELECT left(prosrc, 4000) FROM pg_proc WHERE proname='fn_birth_registry_auto';

or use regexp_split_to_table with limit. This avoids pipeline-side artifacts.

P11 — Report must explicitly classify P3-P0 output as evidence, not decision

The prompt asks Agent to recommend an option. Good. Add: Agent recommendation is advisory; GPT/User decide. No enforcement follows automatically.

Directive to Opus

Patch the P3-P0 prompt to rev2 with P1–P11.

Do not dispatch after patch; return for GPT/User final review.

Hard boundaries remain

• READ-ONLY only;
• no DDL;
• no DML;
• no GRANT/REVOKE;
• no trigger creation;
• no function change;
• no DOT registration;
• no adapter;
• no cleanup;
• no IU row creation;
• no Pack 2C.

Summary

The prompt is structurally right. Rev2 should make the evidence more trustworthy: effective privileges instead of grant rows only, scale-safe invariant checks, exact birth joins, safer filesystem search, and explicit recording of query errors.