GPT Review — 23-P3D4C2U DOT Table Registration Implementation Prompt rev2

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c2u-dot-table-registration-implementation-prompt.md rev2

Verdict

REV3 REQUIRED — do not dispatch rev2.

Rev2 correctly fixed the main rev1 concern: it is now inventory-driven, does not hardcode table_registry shape, has stricter publish gate, idempotent view handling, scoped rollback, and correct next-pack direction.

However, rev2 still has a production-safety blocker: it conflates Postgres database roles and Directus application roles. These are different layers and must not be treated as the same <role_from_0C>.

Accepted rev2 fixes

• table_registry schema must be inventoried before insert.
• tbl_system_issues row shape must be copied rather than guessed.
• Existing view handling is now absent/compatible/conflict instead of "must not exist".
• payload_classification is checked/included only if present.
• Publish gate is strict; route smoke unavailable means draft only.
• Rollback is scoped to objects created by this pack.
• No Nuxt code, no bespoke UI, no mark-read/write, no worker/cron.
• Next pack no longer jumps prematurely to P3D5.

Required rev3 patches

P1 — Separate PG role from Directus application role

Rev2 Step 0C says:

What role reads system_issues?
SELECT grantee ... FROM information_schema.role_table_grants ...
OR via Directus: GET /permissions?filter[collection][_eq]=system_issues
Agent uses SAME role for v_event_outbox_table.

This is incorrect. There are two separate role concepts:

1. Postgres DB role — used for SQL GRANT SELECT ON v_event_outbox_table TO <pg_role>.
2. Directus application role — row in directus_roles, referenced by directus_permissions.role, used for API read permission.

Patch rev3 to create two separate inventories and variables:

pg_read_role=<database role used by Directus connection / existing view grants>
directus_read_role_id=<Directus app role id used for Table Module read access>

Use them separately:

GRANT SELECT ON v_event_outbox_table TO <pg_read_role>;

and:

POST/PATCH directus_permissions with role=<directus_read_role_id>

Do not use the same value for both unless inventory proves they are intentionally the same namespace, which is unlikely.

P2 — Inventory Directus permission convention from system_issues and/or published registry tables

Directus API read permission should follow the existing app-role convention.

Patch Step 0C into two steps:

• 0C1 PG read role inventory

  • identify DB role Directus uses to read normal tables/views;
  • inspect grants on system_issues and/or other view-backed collections;
  • if unclear, STOP or use owner-safe convention documented by DOT.

• 0C2 Directus app permission inventory

  • inspect directus_permissions for system_issues, table_registry, or similar published registry collections;
  • identify role id/name used by existing Table Module read path;
  • verify no create/update/delete for target role unless existing path demands it;
  • if no role convention found, STOP rather than inventing a role.

P3 — system_issues API smoke must not hardcode possibly absent fields

Rev2 uses:

GET /items/system_issues?limit=3&fields=id,code,title,status,severity

Earlier inventory used code as tag field; title may or may not exist. A smoke gate should not fail because one optional display field is absent.

Patch:

• build the smoke fields from the actual tbl_system_issues.fields / live schema;
• or use a minimal safe query: GET /items/system_issues?limit=3;
• if using explicit fields, only include fields confirmed present by preflight.

P4 — Directus view primary key handling should allow metadata fix through existing convention

Rev2 says if Directus cannot identify id as PK on the view, STOP. This is safe but may be too strict if existing DOT convention supports declaring the primary key in collection/field metadata.

Patch:

• first check if Directus auto-recognizes id;
• if not, check whether existing DOT metadata convention can mark id as primary/display field for view collections;
• if convention exists, apply it and verify;
• if no convention, STOP DIRECTUS_VIEW_PK_BLOCKED.

Do not create bespoke Directus behavior; only use existing convention.

P5 — Publication semantics should be explicit

Rev2 says Step 5 always creates status='draft', Step 7 may publish only if smoke passes. Good, but report fields should distinguish:

registry_initial_status=draft
registry_final_status=draft|published|removed
published_after_route_smoke=true|false

This avoids ambiguity when implementation ends successfully but remains draft due manual route smoke.

P6 — Unsafe field smoke should include payload explicitly

Rev2 smoke S5 mentions safe_payload, correlation_id, causation_id, but the live design concern is raw payload / body / vector / secret.

Patch S5 expected absence list:

payload, body, raw_payload, safe_payload, vector, embedding, secret, token, password, correlation_id, causation_id

correlation_id/causation_id are not necessarily unsafe, but omitted by design; keep them absent if the projection omits them.

P7 — Rollback must distinguish view existed-before-compatible

Rev2 says rollback only removes pack-created objects, good. Add explicit tracking fields:

view_created_by_pack=true|false
permission_created_by_pack=true|false
registry_row_created_by_pack=true|false
collection_meta_created_by_pack=true|false

Rollback must not drop/revoke/delete objects that existed before and were merely reused.

Directive to Opus

Patch the prompt to rev3 at:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c2u-dot-table-registration-implementation-prompt.md

Patch narrowly. Do not reopen the Table Module design. Do not dispatch after patch; return for GPT/User review.

Hard boundaries unchanged

• No PG mutation during prompt patch.
• No Directus mutation during prompt patch.
• No Nuxt code.
• No bespoke notification UI.
• No notification-specific page/component.
• No Directus click-config.
• No Directus write/mark-read.
• No body/raw payload/vector/secret exposure.
• No IU runtime change.
• No worker/cron.
• No Điều 43 machinery change.

Summary

Rev2 is close, but production execution must not confuse database grants with Directus application permissions. Rev3 should separate these two layers, make system_issues smoke schema-driven, and tighten view PK/rollback/report semantics.