Incomex AI Portal
KB-799A

GPT Review — 23-P3D3 Execution PASS and P3D4 Directive

6 min read Revision 1
gpt-reviewpack-23p3d3-passp3d4-directivedirectusnuxtassembly-first

GPT Review — 23-P3D3 Execution PASS and P3D4 Directive

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/reports/23-p3d3-notification-context-directus-exposure-report.md

Verdict

P3D3 PASS confirmed. No supplemental Agent action needed for P3D3.

Agent executed correctly. Opus review is accurate.

Accepted evidence

  • phase_status=PASS.
  • context_pack_upload=PASS.
  • exposure_design_upload=PASS.
  • Context pack updated and readback verified.
  • Directus exposure design note created and readback verified.
  • Notification commands documented:
    • fn_iu_unread;
    • fn_iu_mark_read;
    • fn_iu_notification_board.
  • Per-actor read state documented.
  • Implicit self-read documented.
  • Actionable board scope documented.
  • Human/user via Directus/Nuxt documented.
  • Directus/Nuxt boundary documented.
  • no_pg_mutation=true.
  • no_directus_mutation=true.
  • no_nuxt_code=true.
  • no_nuxt_page_commitment=true.
  • no_directus_exposure_implementation=true.
  • next_required_pack=P3D4_DIRECTUS_EXPOSURE_DESIGN_OR_IMPLEMENTATION_REVIEW.

Current operational state

Pack 23 + P3D are now complete for limited operational use at the PG/AI level:

  • IU edit workflow is active.
  • Notification runtime is active.
  • AI/Agent context is updated.
  • Human-facing Directus/Nuxt exposure has a design note but is not implemented.
  • Hermes production remains blocked pending separate review.

Directive to Opus — P3D4 next step

Proceed to P3D4 design prompt drafting, not implementation dispatch.

Create prompt:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4-directus-exposure-design-review-prompt.md

Report path:

knowledge/dev/laws/dieu44-trien-khai/reports/23-p3d4-directus-exposure-design-review-report.md

P3D4 scope

P3D4 should be Directus exposure design review / inventory, not direct implementation unless explicitly approved after review.

Primary goal:

Determine the safest Assembly First path for human users to see the notification board through Directus, without Nuxt business logic.

Files to read first

  • knowledge/dev/laws/dieu44-trien-khai/design/23-p3d3-user-notification-board-directus-exposure-design.md
  • knowledge/dev/laws/dieu44-trien-khai/context-packs/iu-agent-front-door-context.md
  • knowledge/dev/laws/dieu44-trien-khai/design/23-p3d-ui-boundary-directus-nuxt-assembly-note.md
  • knowledge/dev/laws/dieu44-trien-khai/reports/23-p3d2-notification-triggers-report.md
  • knowledge/dev/laws/dieu44-trien-khai/reports/23-p3d3-notification-context-directus-exposure-report.md

P3D4 design questions

The prompt should ask Agent/Opus to inventory and decide:

  1. What Directus can currently expose without custom code:

    • existing DB tables as collections;
    • existing views as collections;
    • permissions/roles;
    • read-only collections;
    • flows/endpoints if already available.

  2. Best PG primitive for Directus exposure:

    • PG view over iu_notification_event + iu_notification_read;
    • materialized view if needed later;
    • Directus collection over tables/views;
    • custom endpoint only if assembly options fail.

  3. Whether fn_iu_notification_board(actor) can be exposed through Directus without custom code.

  4. Whether a PG view is enough for Phase 1 human monitoring:

    • all events;
    • latest readers;
    • actor who created event;
    • read-state overview;
    • no per-actor filter initially if too complex.

  5. How to model human actor identity:

    • user:huyen;
    • Directus user id/email mapping;
    • stable actor_ref convention.

  6. How a human marks notifications read:

    • through Directus action/flow;
    • through PG function call exposed safely;
    • or deferred if read-only monitoring is Phase 1.

  7. Security/permissions:

    • read-only exposure for normal users;
    • avoid exposing body content unnecessarily;
    • expose refs/metadata, not sensitive content;
    • who can mark read.

  8. Nuxt boundary:

    • no Nuxt code-first work;
    • no direct PG from Nuxt;
    • Nuxt displays only what Directus exposes;
    • existing Directus/Nuxt assembly first.

P3D4 output expected

P3D4 should create a design/review note, not mutate systems:

knowledge/dev/laws/dieu44-trien-khai/design/23-p3d4-directus-notification-exposure-review.md

The note should recommend one of:

  • Option A: PG view + Directus read-only collection first;
  • Option B: Directus custom endpoint/flow backed by PG functions;
  • Option C: staged approach — read-only board first, mark-read later;
  • Option D: defer implementation if Directus inventory shows risk.

Hard boundaries

  • Do not mutate PG.
  • Do not mutate Directus config.
  • Do not write Nuxt code.
  • Do not create Nuxt page.
  • Do not implement exposure yet.
  • Do not start Hermes production.
  • Do not expose sensitive IU body content unnecessarily.

Recommendation

GPT’s current leaning for P3D4 design is:

  1. Phase 1 human board should likely be read-only through a PG view exposed as a Directus collection.
  2. Mark-read for human users can be a later step unless Directus can safely expose a function/flow without custom code.
  3. Nuxt should only render existing Directus-exposed data after the Directus exposure design is approved.

Summary

P3D3 completed the documentation/context layer. P3D4 should now inventory Directus exposure options and recommend the safest assembly-first path for a human-readable notification board. Do not implement yet.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-23-p3d3-execution-pass-and-p3d4-directive-2026-05-08.md