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

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 rev1

Verdict

REV2 REQUIRED — do not dispatch rev1.

Rev1 is directionally correct: it uses the existing Table Module path, includes the critical system_issues smoke gate, creates a metadata-only PG view, uses Directus/DOT/API, adds one table_registry row, and forbids Nuxt/UI special-casing.

However rev1 is not production-dispatch safe yet. It hardcodes several schema/API assumptions and does not fully protect the shared Table Module path from accidental drift.

Accepted parts

• Correct implementation target: one PG view + read-only Directus exposure + one table_registry entry.
• Correct smoke gate: if system_issues generic Table Module path fails, STOP and repair Table Module; do not create notification UI.
• Correct display source: PG_VIEW_PROJECTION rather than raw event_outbox.
• Correct hard boundaries: no Nuxt, no bespoke UI, no click-config, no mark-read/write, no IU runtime change, no worker/cron, no Đ43 machinery change.
• Correct rollback direction: unpublish/remove registry, remove permission, revoke grant, drop view.

Required rev2 patches

P1 — table_registry schema must be inventoried and used exactly, not hardcoded

Rev1 hardcodes:

INSERT INTO table_registry (... fields_config, rows_per_page, enable_pagination, ...)

But Agent’s inventory and SSOT snippets mention field config shapes as fields, while actual table schema may differ. This is a production risk.

Patch Step 0/5:

• inspect table_registry columns/types/constraints live;
• inspect the exact tbl_system_issues row shape;
• generate the tbl_event_outbox row using the same column names and JSON structure as tbl_system_issues;
• do not assume fields_config exists;
• use idempotent upsert by table_id='tbl_event_outbox' or the actual unique key;
• preserve existing row if compatible; report ALREADY_PRESENT_COMPATIBLE or CONFLICT_REVIEW_REQUIRED.

P2 — smoke gate must test the generic Table Module path, not only collection API

Rev1 says verify route render, but the concrete method only calls:

GET /items/system_issues?limit=3

That proves Directus data access, not DirectusTable/generic route rendering.

Patch:

• keep API smoke as necessary but insufficient;
• if browser/HTTP route access is available, smoke /knowledge/registries/system_issue and verify expected page/content or table bootstrap;
• if route smoke cannot be automated, set generic_route_smoke=LIMITED_MANUAL_REQUIRED and keep tbl_event_outbox.status='draft' until User/manual smoke confirms;
• do not publish tbl_event_outbox on API-only proof unless prior established rule allows it.

P3 — existing view must be handled idempotently, not “must not exist”

Rev1 says:

v_event_outbox_table must NOT exist yet

Patch to production-safe idempotency:

• if absent: create;
• if present and definition matches expected allowlist: ALREADY_PRESENT_COMPATIBLE;
• if present and differs: STOP VIEW_CONFLICT_REVIEW_REQUIRED unless explicitly approved to replace;
• do not blindly CREATE OR REPLACE over a potentially used object without definition comparison.

P4 — v_event_outbox_table should include payload_classification if present

The design note included payload_classification as a useful metadata/safety column. Rev1 omits it.

Patch:

• inspect whether event_outbox.payload_classification exists;
• if yes, include it in the view and table_registry fields;
• if absent, report payload_classification_column=ABSENT and proceed with 12-column view;
• no raw payload exposure either way.

P5 — Directus role/permission must be identified by existing read-only convention

Rev1 says “appropriate role” and “public_readonly or agent_readonly” earlier in design, but prompt should force inventory:

• list existing roles used by system_issues/registry tables;
• choose the least-privilege read-only role already used for table views;
• if no suitable role exists, STOP for review rather than inventing one;
• assert create/update/delete permissions absent after execution.

P6 — Directus collection registration for PG view must be verified against actual Directus behavior

For views, Directus often requires correct primary key/field metadata. Patch Step 3:

• verify Directus introspects v_event_outbox_table after view creation;
• verify id is recognized/usable as primary key, or set metadata as required by existing DOT convention;
• if Directus cannot safely expose the view, STOP DIRECTUS_VIEW_INTROSPECTION_BLOCKED.

P7 — No raw Directus system-table mutation unless existing DOT convention requires it

Rev1 uses Directus API wording, good. Keep that. But for table_registry, prefer the same official channel used by existing registry management:

• Directus Items API or existing DOT tool, if available;
• raw SQL only if Table Module precedent uses raw SQL and cache invalidation is handled;
• report registry_write_channel=DirectusAPI|DOT_TOOL|RAW_SQL_WITH_JUSTIFICATION.

P8 — Publish gate should be stricter

Patch Step 7:

• publish only if all critical smoke tests PASS;
• if route smoke is LIMITED_MANUAL_REQUIRED, leave status=draft and report published=DEFERRED_MANUAL_ROUTE_SMOKE;
• do not publish on partial proof.

P9 — Rollback must be idempotent and only remove objects created/changed by this pack

Patch rollback:

• if an existing compatible view/registry row/permission was reused, do not drop it on rollback;
• track created_by_pack=true|false for view, collection meta, permission, registry row;
• rollback only pack-created objects unless User approves;
• do not touch event core tables/triggers/functions.

P10 — next_required_pack should not jump to P3D5 yet

Rev1 says:

next_required_pack=P3D5_IU_EVENT_DOMAIN_ONBOARDING

That is premature. After P3D4C2U execution, next should depend on result:

• if PASS and user can view: P3D4C3U_USER_VIEW_SMOKE_AND_MARK_READ_DECISION or P3D4_COMPLETE_FOR_READONLY_VIEW;
• if draft due manual route smoke: P3D4C2U_MANUAL_ROUTE_SMOKE;
• if Table Module blocked: TABLE_MODULE_GENERIC_EXTENSION_PROMPT_REVIEW.

Do not start IU event onboarding until the read-only exposure path is confirmed end-to-end.

Directive to Opus

Patch the prompt to rev2 at:

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

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

Rev1 is close but still assumes too much. Rev2 must become inventory-driven and idempotent: use actual table_registry schema, prove the generic route or defer publish, compare existing view definitions, choose an existing read-only role, and rollback only objects created by this pack.