Incomex AI Portal
KB-1050

GPT Review — D28 Nuxt Display Requirements v0.1 and Scope Directive

6 min read Revision 1
gpt-reviewdieu28nuxtrequirementsscopep3dtext-as-code

GPT Review — D28 Nuxt Display Requirements v0.1 and Scope Directive

Date: 2026-05-09
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu28-trien-khai/requirements/d28-nuxt-ui-display-requirements-spec-draft.md v0.1

Verdict

ACCEPT AS STRATEGIC SCAFFOLD, BUT DO NOT EXPAND INTO A FULL NUXT PROGRAM NOW.

Opus captured the broad vision correctly, but the document is wider than the immediate objective. The current mission is still:

Finish information-unit / text-as-code infrastructure, including the small notification display checkpoint, without creating future Nuxt rework.

Therefore, D28 v0.1 should be used as a guardrail and context, not as a reason to pause for a long Nuxt redesign.

User clarification accepted

User clarified:

  • Nuxt display planning is necessary so that current notification work fits the long-term model.
  • But the primary goal is not to design all Nuxt now.
  • Primary goal remains completing the information-unit / text-as-code infrastructure.
  • D28 currently only needs enough clarity to ensure any Nuxt touchpoint belongs to the Điều 28 overall design.
  • If a Điều 28 tool is needed as prerequisite, write design and implement only that necessary piece.

Assessment of Opus spec

What is good

The spec correctly captures:

  • read/display flow: PG → Directus → Agency OS → Nuxt;
  • write/input flow: Nuxt → input collection → DOT/Agent/Workflow → PG;
  • template/khuôn principle;
  • no bespoke UI;
  • no hardcoded local workaround;
  • notification/event board must not be a separate family;
  • tbl_event_outbox belongs under DirectusTable/Table/Report family;
  • legacy Nuxt cleanup is real but should be phased;
  • generated maps unblock the Table Module infrastructure.

What is too broad for now

The spec opens many future tracks:

  • full docs reader family;
  • process view;
  • task form;
  • input form;
  • report table calculation;
  • module multi-tab;
  • Directus admin UI;
  • full legacy cleanup.

These are valid, but they should not block P3D/text-as-code work unless immediately needed.

Scope correction

For the current phase, the D28 requirements should be narrowed to a Minimum Viable Display Governance sufficient to safely resume P3D notification display.

Required now

  1. Confirm notification/event board is a standard table instance, not bespoke UI.
  2. Confirm generated map is a shared Table Module infrastructure tool, not notification-specific.
  3. Confirm Family 1 / DirectusTable rules are enough for tbl_event_outbox.
  4. Confirm no Nuxt custom page/component is needed.
  5. Confirm unsafe-field/permission allowlist rules remain enforced.
  6. Confirm route smoke and field-leak smoke are automated.
  7. Confirm future UI families are recorded as roadmap, not immediate blockers.

Not required now

Do not design deeply now:

  • full Task Form;
  • full Report Table calculation engine;
  • full Process View;
  • full Module multi-tab abstraction;
  • Directus embedded admin UI;
  • complete legacy cleanup;
  • full entity_type schema extension.

Directive to Opus — next action

Opus should revise the requirements spec lightly to add a Phase 1 Minimum Scope section.

Update:

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

Add:

New section: Phase 1 Minimum Display Governance

Must say:

Current Phase 1 is not a full Nuxt redesign.
Current Phase 1 only defines enough display governance to avoid rework while finishing information-unit/text-as-code infrastructure.

It must list:

  • Family 1 / DirectusTable is frozen enough for notification display.
  • tbl_event_outbox is a Family 1 table instance.
  • Generated map is allowed as shared Table Module infrastructure.
  • P3D notification can resume after generated map + automated route smoke.
  • Other UI families remain roadmap/future design and do not block P3D.

Revise Roadmap section

Change the roadmap to:

Phase 1A — Minimum D28 display governance checkpoint.
Phase 1B — Generated map implementation to unblock Table Module routing.
Phase 1C — Resume P3D notification display and publish tbl_event_outbox after smoke.
Phase 1D — Continue information-unit/text-as-code infrastructure.
Phase 2+ — Deep Nuxt families: docs reader, treeview, task form, report table, module tabs, input forms, legacy cleanup.

Reduce open questions for immediate decision

Do not require User to answer all Q1–Q8 now.

Immediate questions should be only:

  1. Is it acceptable that tbl_event_outbox uses Family 1 / DirectusTable as a standard table instance?
  2. Is generated map acceptable as shared Table Module infrastructure for Phase 1?
  3. Are future UI families allowed to remain roadmap until needed?

Keep the original Q1–Q8 as future questions, not blockers.

After Opus revision

If User/GPT accept the narrowed v0.2 requirements, then Opus may draft the generated-map implementation prompt.

Implementation prompt must still be reviewed before dispatch.

Do not do yet

  • Do not implement generated map yet.
  • Do not resume notification display yet.
  • Do not publish tbl_event_outbox yet.
  • Do not start deep Nuxt redesign.
  • Do not force User to answer all long-term UI-family questions now.

Current P3D state

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

Final status

requirements_v0_1=ACCEPTED_AS_STRATEGIC_SCAFFOLD
scope_correction=MINIMUM_DISPLAY_GOVERNANCE_FOR_PHASE1
next_action=OPUS_REVISE_REQUIREMENTS_V0_2_LIGHTLY
implementation_prompt_allowed=false
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-d28-nuxt-display-requirements-v01-and-scope-directive-2026-05-09.md