GPT Directive — Begin D28 Nuxt/UI Display Requirements from User Roadmap

Date: 2026-05-09
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Trigger: User provided roadmap and Thiết kế Nuxt.docx sketch.
Status: Start requirements/specification drafting. No implementation.

Verdict

This is now the correct point to begin the Nuxt/UI display requirements discussion and drafting.

The generated-map design is technically accepted as a candidate, but implementation must remain paused until the higher-level display requirements are captured under Điều 28.

User strategic intent

The immediate notification display problem is simple, but solving it locally would repeat the old pattern:

solve one incident → hardcode Nuxt → next incident repeats → system trash accumulates

Correct direction:

law / requirements
→ architecture / design
→ implementation / tooling

Nuxt display must be standardized by interface/template types. New UI work must use existing templates by config. New templates require formal template-design approval before use.

User's core display principles

Read/display flow

PG → Directus → Agency OS → Nuxt

Rules:

• assemble maximum possible from existing schema/config/template;
• no new Nuxt code for ordinary display flow;
• Nuxt consumes projections/config, not business logic;
• Directus/API/field allowlist govern exposed data.

Write/input flow

Nuxt → temporary input collection → DOT/Agent/Workflow → PG main DB

Rules:

• prefer embedded/configured forms over Nuxt code;
• user input must not write directly into PG truth tables;
• data passes through validation/control workflow before official PG commit;
• human-in-the-loop input is allowed where automation cannot supply data.

Template/khuôn principle

Design once → cast many products from template → use config/DOT instead of custom code.

Every UI need should map to a standard format. If no format fits, the system must pause and design/approve a new template type.

User's candidate interface/form families from uploaded sketch

The requirements spec must consider at least these UI families:

1. Document / knowledge display

   • reconstructed original document view;
   • topic/knowledge-axis view;
   • tree view for complex subject structure.

2. Governance / structure view

   • large governance catalogs;
   • tree/relationship navigation;
   • simplified human-facing structure for complex data.

3. Process / workflow view

   • process model display;
   • process steps ordered visually;
   • parent/child process relationships;
   • company → department → specialty → task → job hierarchy.

4. Work item / task form

   • information to input;
   • supplementary context;
   • work instruction;
   • metadata/logging.

5. Input form / data-entry board

   • human input data;
   • possible Directus embedded form for limited cases;
   • preferred path: Nuxt input collection → DOT/workflow → PG.

6. Report/table view

   • fields/columns configurable;
   • filters/time ranges configurable;
   • report computations such as totals/bottom row/right column handled by report/template rules, not custom Nuxt code;
   • source data queried simply from PG/Directus projection.

7. Module view

   • multi-tab process/module view;
   • comments, checkpoints, targets, reports, related rules, etc.;
   • should be template/config-driven, not Nuxt custom.

8. Notification/event board

   • current P3D event_outbox display must fit inside the table/report/notification standard, not become a bespoke UI.

Key requirement to capture

Separate UI logic into two conceptual parts where needed:

Query/retrieval layer — simple field selection/filtering/projection.
Template/form calculation layer — display-only calculations such as totals, column sums, row sums, simple report arithmetic.

Business-critical derived data should still be computed/stored upstream where appropriate. Nuxt should not own official business logic.

Directive to Opus — next action

Do not write implementation prompt. Do not resume P3D display implementation. Do not edit Nuxt.

Create requirements draft in KB:

knowledge/dev/laws/dieu28-trien-khai/requirements/d28-nuxt-ui-display-requirements-spec-draft.md

Inputs:

• User roadmap in current chat;
• uploaded file Thiết kế Nuxt.docx;
• existing D28 appendix draft;
• D28 generated map design/report;
• Assembly Module SSOT;
• Table Module SSOT;
• current P3D notification checkpoint.

The draft should not be a final law yet. It should be a requirements/specification document for User/GPT review.

Required structure for requirements draft

1. Purpose and scope.
2. Read/display flow rule: PG → Directus → Agency OS → Nuxt.
3. Write/input flow rule: Nuxt → input collection → DOT/Agent/Workflow → PG.
4. Template/khuôn model.
5. Allowed UI/interface families.
6. For each family:
   • use case;
   • template/khuôn candidate;
   • data source shape;
   • allowed fields/actions/filters/status/badges/relationships/timeline;
   • forbidden custom behavior;
   • required smoke/verify.
7. Template selection decision tree.
8. New-template creation gate.
9. Existing-template extension gate.
10. Data-entry/input governance.
11. Report/table calculation governance.
12. Process/work-item display governance.
13. Module/multi-tab governance.
14. Notification/event-board placement.
15. Legacy Nuxt cleanup principles.
16. Automation/DOT/API requirements.
17. Open questions for User.

Open questions Opus should surface for User

• What are the minimum UI families for Phase 1?
• Which templates must be frozen first to unblock P3D notification display?
• Should report-template calculations allow only simple arithmetic or also grouped aggregations?
• Which write/input forms are acceptable to embed from Directus versus requiring input collection workflow?
• How many UI formats are acceptable before training burden becomes too high?
• Which legacy Nuxt pages are business-critical and cannot be removed yet?

P3D remains paused

Current state:

table_registry_id=21
permission_id=1483
tbl_event_outbox.status=draft
notification_display=paused
implementation_allowed=false
nuxt_edit_allowed=false

P3D may resume only after the requirements draft is reviewed enough to confirm that event_outbox display belongs to an approved standard UI family.

Final status

ui_requirements_discussion_started=true
next_action=OPUS_DRAFT_D28_NUXT_UI_DISPLAY_REQUIREMENTS_SPEC
implementation_allowed=false
generated_map_implementation_prompt_allowed=false
p3d_resume_allowed=false