GPT Correction — Directus/Nuxt Must Follow Template-First Assembly Path for P3D4C2U

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Trigger: User reminder that Incomex does not create one-off interfaces; every UI must be designed as reusable template/module and placed in the template/module path.

Correction

The previous informal wording “P3D4C2U — Directus DOT read-only exposure for universal event board” could be misread as building a bespoke notification UI.

That is not allowed.

P3D4C2U must follow the existing UI/template laws:

• Điều 7 — Assembly First: PG first, then Directus existing system/API/metadata, then existing Nuxt UI/Agency OS, code only after 0–3 fail and approval.
• Điều 28 — Standard Template / Display Technique: design once, declare/reuse; no one-off UI.
• Assembly Roadmap: use existing registry/module approach such as DirectusTable, table_registry, existing 3-layer UI and template path.
• Pack 23 P3D UI Boundary: PG → Directus collection/permission/API → Nuxt existing screens/components; no custom Nuxt business logic, no direct PG from Nuxt.

Revised interpretation for P3D4C2U

P3D4C2U is not “build a notification page”.

It should be reframed as:

P3D4C2U_TEMPLATE_FIRST_READONLY_EXPOSURE_SCOPE_REVIEW

Purpose:

1. Inventory existing reusable UI/template mechanisms:
   • Directus collection/view exposure via DOT;
   • DirectusTable / table module;
   • table_registry;
   • existing dashboard/list/table template routes;
   • existing Directus SDK/API patterns;
   • existing Nuxt/Agency OS components.
2. Decide whether universal event board can be represented as a reusable table/template declaration, not new UI code.
3. If the existing template path is sufficient, create only the necessary PG projection/view and Directus metadata/permission registration via DOT.
4. If existing template path is insufficient, design a reusable template/module first, not a notification-specific screen.
5. Nuxt work remains deferred unless a template/module gap is proven and User approves.

Required direction for Opus next

Do not ask Opus to draft a Directus/Nuxt implementation prompt yet.

Ask Opus to draft a design/inventory prompt first:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c2u-template-first-readonly-exposure-design-prompt.md

Expected design note:

knowledge/dev/laws/dieu44-trien-khai/design/23-p3d4c2u-template-first-readonly-exposure-design.md

Expected report:

knowledge/dev/laws/dieu44-trien-khai/reports/23-p3d4c2u-template-first-readonly-exposure-design-report.md

Scope for P3D4C2U design prompt

The prompt must require Agent to:

1. Read Điều 7, Điều 28, Assembly Roadmap, Pack 23 P3D UI Boundary, and P10D no-code assembly path report.
2. Inventory live Directus/Nuxt template/module path relevant to a read-only table/list board.
3. Verify whether existing DirectusTable / table_registry / registry UI can render event_outbox projection without new UI code.
4. Identify the minimal PG view/projection needed, metadata/ref-only.
5. Identify the minimal Directus DOT exposure needed, read-only.
6. Decide whether Nuxt requires zero code, registry declaration only, template extension, or new reusable module.
7. If new module is required, it must be generic/reusable and go to template/module inventory, not a notification-specific page.
8. Preserve live schema deviations:
   • event_subject_ref text;
   • read_status_source IN ('explicit','implicit_self').
9. Keep human mark-read UI deferred unless explicitly approved.
10. Do not touch IU runtime.

Hard boundaries

• No bespoke notification UI.
• No Nuxt custom page/component for notification specifically.
• No Directus click/config mutation.
• No Directus write/mark-read in this pack.
• No Nuxt direct PG.
• No business logic in Nuxt.
• No body/raw payload/vector/secret exposure.
• No worker/cron.
• No IU runtime change.

Required report fields

phase_status=PASS|FAIL|NEEDS_TEMPLATE_GAP_REVIEW
laws_read=<list>
assembly_first_checked=PASS|FAIL
dieu28_template_law_checked=PASS|FAIL
existing_template_inventory=PASS|FAIL
directus_table_registry_available=PASS|FAIL|UNCLEAR
can_render_with_existing_template=YES|NO|UNCLEAR
new_ui_code_required=false|true_with_justification
new_ui_code_approved=false
recommended_path=REGISTER_EXISTING_TEMPLATE|EXTEND_GENERIC_TEMPLATE|DESIGN_NEW_REUSABLE_TEMPLATE|BLOCKED
pg_projection_needed=YES|NO
pg_projection_shape=<summary>
directus_dot_needed=YES|NO
directus_readonly_only=true
nuxt_path=NO_CODE|REGISTRY_DECLARATION_ONLY|GENERIC_TEMPLATE_EXTENSION_REQUIRED|BLOCKED
human_mark_read_ui=DEFERRED
live_schema_deviations_preserved=true
no_bespoke_notification_ui=true
no_directus_mutation=true
no_nuxt_code=true
no_iu_runtime_change=true
next_required_pack=<based on recommendation>

Current GPT recommendation

P3D4C2U should become a template-first exposure design review, not an immediate Directus/Nuxt implementation.

The correct next step is to inventory and reuse existing template/module mechanisms. Only after that can GPT/User approve a minimal DOT/read-only exposure or a generic reusable template extension.