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

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 rev3

Verdict

REV4 REQUIRED — narrow production-safety patch. Do not dispatch rev3.

Rev3 correctly fixes the critical layer error: Postgres DB role and Directus application role are now separated. The prompt is close to dispatch-ready, but two production-safety details remain under-specified and should be patched before executing against production.

Accepted rev3 fixes

• pg_read_role and directus_read_role_id are separated.
• PG GRANT and Directus permission now use different role variables.
• system_issues smoke no longer hardcodes risky field names.
• Directus view PK convention is checked before STOP.
• Publish/report fields are clearer.
• Unsafe field denial list is comprehensive.
• Rollback tracking exists for pack-created objects.
• Hard boundaries remain correct: no Nuxt, no bespoke UI, no click-config, no mark-read/write, no IU change, no worker/cron, no Đ43 change.

Required rev4 patches

P1 — View SQL must be executable for both payload_classification cases

Rev3 Step 1 includes a commented placeholder:

-- Include payload_classification if column exists (from 0G)

This is not dispatch-safe because the execution agent may copy the SQL without adding the column, or add it when absent.

Patch rev4 to require one of two explicit executable variants:

• Variant A: if event_outbox.payload_classification exists, create view with that column;
• Variant B: if absent, create the 12-column view without it.

Report:

payload_classification_column=EXISTS|ABSENT
view_variant=WITH_PAYLOAD_CLASSIFICATION|WITHOUT_PAYLOAD_CLASSIFICATION
view_columns=13|12

Do not leave this as a comment-only instruction.

P2 — Directus permission creation must be idempotent and conflict-aware

Rev3 uses POST /permissions but does not specify how to handle an existing permission.

Patch Step 4:

• search existing directus_permissions for (role=<directus_read_role_id>, collection='v_event_outbox_table', action='read');
• if absent, create;
• if present and fields/filter are compatible, report ALREADY_PRESENT_COMPATIBLE;
• if present but broader/different/unsafe, STOP PERMISSION_CONFLICT_REVIEW_REQUIRED;
• explicitly assert no create/update/delete permissions for the collection.

Track:

permission_created_by_pack=true|false
permission_status=CREATED|ALREADY_PRESENT_COMPATIBLE|CONFLICT

P3 — table_registry row must be idempotent and conflict-aware

Rev3 says create row from tbl_system_issues shape but does not specify existing-row behavior.

Patch Step 5:

• search by table_id='tbl_event_outbox' and/or collection='v_event_outbox_table' using actual unique convention;
• if absent, create status=draft;
• if present and compatible, report ALREADY_PRESENT_COMPATIBLE and do not overwrite unexpectedly;
• if present but incompatible, STOP TABLE_REGISTRY_CONFLICT_REVIEW_REQUIRED;
• if updating a draft created by this pack, use the same write channel convention.

Track:

registry_row_created_by_pack=true|false
registry_row_status=CREATED|ALREADY_PRESENT_COMPATIBLE|CONFLICT

P4 — Field metadata registration must be idempotent

Rev3 says PATCH field labels. Patch to require:

• verify field exists before PATCH;
• if field meta absent and Directus convention supports creation, create via API/DOT;
• if field meta exists, patch only allowed display metadata and preserve unrelated settings;
• if field set differs in a way that exposes unsafe fields, STOP;
• do not hide/fork system fields outside target collection.

P5 — Publish gate must not publish if route smoke is CANNOT_VERIFY

Rev3 says this correctly, but verification should include:

published=YES|NO
publish_block_reason=NONE|ROUTE_SMOKE_CANNOT_VERIFY|SMOKE_FAIL|CONFLICT

This makes a PASS-with-draft outcome explicit and prevents silent “done” claims.

P6 — Final recommendation should distinguish read exposure created vs user-visible confirmed

Rev3 recommendation DONE is too vague. Patch values:

recommendation=READONLY_EXPOSURE_PUBLISHED|READONLY_EXPOSURE_DRAFT_PENDING_ROUTE_SMOKE|NEEDS_GENERIC_TEMPLATE_EXTENSION|DIRECTUS_VIEW_PK_BLOCKED|REVISION_REQUIRED|BLOCKED

Next pack:

• if published and route smoke passed: P3D4C3U_USER_VIEW_SMOKE_AND_MARK_READ_DECISION;
• if draft pending route smoke: P3D4C2U_MANUAL_ROUTE_SMOKE;
• if Table Module gap: TABLE_MODULE_GENERIC_EXTENSION_PROMPT_REVIEW.

Directive to Opus

Patch the prompt to rev4 at:

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

Patch narrowly. Do not reopen the architecture. Do not dispatch after patch; return for GPT/User final 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/correlation/causation exposure.
• No IU runtime change.
• No worker/cron.
• No Điều 43 machinery change.

Summary

Rev3 is close and correctly separates PG role from Directus role. Rev4 should make the view variant executable and make Directus permission, field metadata, and table_registry registration idempotent/conflict-aware before production dispatch.