Incomex AI Portal
KB-1C4E

GPT Handoff — Pack 23/P3D Notification + Directus Exposure Continuity

15 min read Revision 1
handoffgptpack-23p3dnotificationdirectusnuxtroadmapuser-notes

GPT Handoff — Pack 23/P3D Notification + Directus Exposure Continuity

Date: 2026-05-08
Audience: GPT next session.
Purpose: preserve full context, user constraints, roadmap, and latest checkpoint so the next GPT session can continue seamlessly.
Note: This is not the Opus handoff. Opus handoffs are shorter and task-specific.

0. One-line current state

Pack 23/P3D has completed the PG edit workflow + notification runtime + Directus exposure design and DOT package review. The next step is P3D4C prompt drafting: write, but do not dispatch, an implementation prompt for public.v_iu_notification_board + Directus read-only DOT exposure.

1. Critical user notes that must not be lost

1.1 Directus / Nuxt / PG boundary

User repeated this as a hard architectural rule:

Postgres = source of truth / workflow runtime
Directus = exposure layer reading PG, driven by DOT/change packages
Nuxt = display assembly only, reading from Directus

Hard implications:

  • Directus must be DOT 100% / DOT-driven for later configuration/exposure work.
  • Directus UI is for view/inspection only.
  • User should not operate IU content in Directus UI.
  • No manual Directus UI configuration clicking.
  • No Directus content operation for IU workflow.
  • Nuxt code is absolutely forbidden by default.
  • Nuxt must not contain business logic.
  • Nuxt must not read PG directly.
  • If display is ever needed, use existing Nuxt assembly patterns only.
  • Standard Nuxt display pattern: TreeView 2 columns — folder/file list + selected file/detail.
  • If detail complexity requires: TreeView 3 columns.
  • Do not propose a new Nuxt page as a commitment.
  • No code-first Nuxt work.

1.2 Law jurisdiction principle

User clarified a governing principle:

Each law owns its specialty. Use the correct tools/rules for that specialty. Do not overlap, duplicate, or let one law/tooling layer invade another.

Practical examples:

  • Do not solve Directus exposure by coding Nuxt.
  • Do not solve user interaction by letting Nuxt connect directly to PG.
  • Do not solve workflow approval through Directus UI editing.
  • Do not solve Directus config by clicking UI; later implementation must be DOT/change package reviewed.
  • Do not solve Hermes automation in P3D4/P3D4B/P3D4C.
  • Do not duplicate Điều 43 DOT/counting conventions.

1.3 User-facing notification board goal

The notification board is for both humans and AI/Agents.

Final human goal:

  • A board showing new comments.
  • A board showing information pieces needing review.
  • A board showing official update/apply events.
  • Human can see which AI/Agent has read or not read.
  • Users monitor collaboration, not edit IU content in Directus.

Current status: PG runtime exists, but human visible board is not implemented yet.

1.4 Mark-read and write actions are deferred

Phase 1 human exposure should be read-only metadata/ref board.

Deferred:

  • Human mark-read action.
  • Directus user → actor_ref mapping.
  • Per-user Directus write endpoint/flow.
  • Hermes consumption.
  • Nuxt display assembly.

1.5 Điều 43 / DOT overlap warning

User said Điều 43 already has many DOT assets and partial relationship/counting tooling. Điều 43 is not complete due to schema blockers, but parts may be reusable.

Rule:

  • Before creating any new Directus/DOT mechanism, inspect Điều 43/DOT conventions.
  • Avoid double DOT.
  • Avoid duplicate relationship/counting logic.
  • Reuse existing DOT patterns/templates if found.
  • Do not repair Điều 43 schema blockers inside Pack 23/P3D.

P3D4B already did this inventory and found overlap risk LOW.

2. Completed chain

2.1 IU edit workflow

Completed:

  • P3B — schema for edit draft/comment.
  • P3C1 — safe functions: draft/comment/plan.
  • P3B-FU — generalized invariant for post-edit versions.
  • P3C2 — apply/edit functions.
  • P3C3 — fn_iu_save front door.
  • P3C4 — policy switched to require_review + context pack.

Operational model:

fn_iu_save(address, body, actor)          -- create new official IU or create edit draft for existing IU
fn_iu_comment(address, actor, comment)    -- free-flow comments, no approval required
fn_iu_apply_edit_draft(draft_id, actor)   -- reviewer approval/apply

Behavior:

  • New information piece: first creation is official.
  • Existing information piece: edit becomes draft, requires approval.
  • Comment: free-flow, timestamped, no approval.
  • Users/agents should not need to remember complex workflows.

2.2 PG notification runtime

Completed:

  • P3D1 — notification tables + fn_iu_unread, fn_iu_mark_read.
  • P3D2 — notification triggers + fn_iu_notification_board.

PG now automatically writes notification events for:

  • non-system comment added;
  • draft created for review;
  • official version applied.

Notification API:

fn_iu_unread(actor)                    -- actor's unread/actionable inbox
fn_iu_mark_read(event_ids, actor)      -- mark events seen for actor only
fn_iu_notification_board(actor)        -- summary board with read_status_source/latest_readers

Read-state semantics:

  • Per actor, not global.
  • GPT read state does not hide item for Opus.
  • Opus read state does not hide item for GPT.
  • Creator has implicit self-read.
  • Example: Opus creates event → Opus sees it as read (implicit_self) but GPT still sees unread.

2.3 P3D3 context and exposure design

Completed:

  • Updated AI/Agent context pack.
  • Created Directus exposure design note.
  • Established Directus/Nuxt boundary.
  • Established human users do not run SQL; AI/Agent can use PG functions, humans access later through Directus/Nuxt exposure.

2.4 P3D4 inventory/design review

Completed:

  • Read-only Directus inventory.
  • Read-only PG inventory.
  • P3D4 recommendation: staged approach / Option C.

Key findings:

  • Directus already auto-registers iu_notification_event and iu_notification_read as collections.
  • Directus item access currently 403 pre-DOT — correct posture.
  • PG has no notification view yet.
  • Phase 1 should be read-only metadata/ref board.

2.5 P3D4B package review

Completed:

  • Non-executable DOT package review.
  • No PG mutation.
  • No Directus mutation.
  • No executable SQL/DOT.
  • Recommendation: READY_FOR_IMPLEMENTATION_PROMPT.

Key decisions:

view_scope=HISTORY
payload_strategy=OMIT_RAW_PAYLOAD
role_strategy=NEW_ROLE_RECOMMENDED (notif_board_reader), but re-check/reuse if role exists at execution time
overlap_risk=LOW
go_nogo_gate=GO

Reusable conventions:

  • 3-part DOT description contract.
  • NT12 paired-DOT pattern.
  • PG-native COUNT(DISTINCT actor_ref).

Candidate DOT pair:

DOT-NOTIF-BOARD-EXPOSE
DOT-NOTIF-BOARD-EXPOSE-VERIFY

3. Current checkpoint

Latest confirmed state:

PG edit workflow: ACTIVE
PG notification runtime: ACTIVE
AI/Agent context: UPDATED
Directus exposure design: DONE
P3D4B candidate DOT package review: PASS / GO
Human-facing Directus/Nuxt board: NOT IMPLEMENTED YET

Most recent GPT directive:

knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-23-p3d4b-execution-pass-and-p3d4c-directive-2026-05-08.md

GPT-only checkpoint report:

knowledge/dev/laws/dieu44-trien-khai/reports/gpt-checkpoint-report-2026-05-08-pack23-p3d-notification-directus.md

Opus task handoff already created, but user clarified that GPT also needs this broader handoff:

knowledge/dev/laws/dieu44-trien-khai/handoffs/opus-handoff-p3d4c-directus-dot-readonly-exposure-2026-05-08.md

4. Next task for GPT / next session

The next session should instruct Opus to create P3D4C prompt, not dispatch.

Prompt to create:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c-pg-view-directus-dot-notification-readonly-implementation-prompt.md

Future execution report path:

knowledge/dev/laws/dieu44-trien-khai/reports/23-p3d4c-pg-view-directus-dot-notification-readonly-implementation-report.md

P3D4C is an implementation prompt review. It may contain executable SQL/DOT candidates for review, but must not be executed until GPT/User approve dispatch.

5. P3D4C prompt must include

5.1 Mandatory pre-read

Read:

  • P3D4B report;
  • P3D4B design note;
  • P3D4 report;
  • P3D4 design note;
  • P3D3 design note;
  • Directus/Nuxt boundary note;
  • Constitution;
  • Assembly First law;
  • data-connection law;
  • Directus/DOT law if available;
  • Display/Điều 28 law if available.

5.2 Preflight gates for eventual execution

Before any future mutation:

  • verify no existing public.v_iu_notification_board;
  • verify notification tables exist;
  • verify relevant indexes/constraints exist;
  • verify P3D2 runtime active: 4 functions + 3 triggers;
  • verify candidate view has no body and no raw payload;
  • verify role strategy at runtime:
    • reuse existing suitable role if found;
    • else create/use notif_board_reader only if explicitly approved by P3D4C prompt;
  • verify Directus inventory/read-only posture;
  • verify no Nuxt work;
  • verify no Hermes work.

5.3 Candidate view

View:

public.v_iu_notification_board

Scope:

HISTORY

Columns must be metadata-only:

  • event_id;
  • event_type;
  • event_stream;
  • canonical_address;
  • unit_id;
  • ref_id;
  • actor_ref;
  • source;
  • created_at;
  • read_count;
  • latest_readers;
  • optional safe derived fields only.

Must not include:

  • IU body;
  • unit_version body;
  • raw payload jsonb;
  • sensitive content.

Rules:

read_count = COUNT(DISTINCT r.actor_ref) WHERE r.event_id = e.id
latest_readers = top 5 by read_at DESC, actor_ref ASC

No separate counter table. No denormalized count.

5.4 Directus DOT exposure

Use existing DOT conventions from P3D4B:

  • 3-part description contract;
  • NT12 paired DOT pattern;
  • candidate pair:
    • DOT-NOTIF-BOARD-EXPOSE;
    • DOT-NOTIF-BOARD-EXPOSE-VERIFY.

DOT must cover:

  • Directus view/collection exposure for v_iu_notification_board;
  • read-only permission grant only;
  • no create/update/delete;
  • no Directus UI clicking;
  • role strategy: prefer reuse, else notif_board_reader if approved;
  • labels/descriptions only if DOT-supported;
  • rollback path.

5.5 Required future execution tests

P3D4C prompt should require tests:

  1. PG view created.
  2. View returns rows if notification events exist, or 0 rows cleanly if none.
  3. View columns exactly match approved metadata-only list.
  4. View does not expose body or raw payload.
  5. read_count matches base-table count distinct.
  6. latest_readers ordering deterministic.
  7. Directus sees/auto-registers the view or reports limited/manual DOT step.
  8. Directus role/permission grant is read-only.
  9. No create/update/delete permission exists for target role.
  10. No PG runtime mutation except the new view.
  11. No Nuxt mutation.
  12. No Hermes mutation.
  13. Rollback plan exists.
  14. Quiet period documented: 24–48h before mark-read/human-write package.

5.6 Future execution report fields

Include at least:

phase_status
view_created=PASS|FAIL
view_name=public.v_iu_notification_board
view_scope=HISTORY
metadata_only=PASS|FAIL
raw_payload_exposed=false
body_content_exposed=false
read_count_verified=PASS|FAIL
latest_readers_verified=PASS|FAIL
directus_view_visible=PASS|FAIL|LIMITED
role_strategy=REUSE_EXISTING|CREATED_NOTIF_BOARD_READER
directus_permission_read_only=PASS|FAIL
no_create_update_delete_permissions=PASS|FAIL
no_pg_runtime_mutation=true
no_nuxt_code=true
no_hermes_start=true
rollback_plan=PASS
quiet_period=24_48H_BEFORE_MARK_READ_PACKAGE

6. Roadmap after P3D4C

If P3D4C prompt is drafted and approved

Dispatch P3D4C execution to create:

  • PG view public.v_iu_notification_board;
  • Directus read-only exposure/permission via DOT;
  • verification and rollback artifacts.

After P3D4C execution PASS

Stop for quiet period 24–48h before stacking additional write actions.

Then consider:

  • P3D4D / validation of human-readable board through Directus;
  • mark-read package for human users;
  • Directus user → actor_ref mapping;
  • optional display assembly review using existing Nuxt TreeView patterns;
  • Hermes consumption only after separate review.

Still deferred

  • Human mark-read write action.
  • Directus user identity mapping.
  • Nuxt display assembly.
  • Hermes production.
  • Any body/content exposure.

7. Permanent hard boundaries to preserve

  • No Nuxt code.
  • No Nuxt business logic.
  • No direct PG from Nuxt.
  • Directus is DOT-driven.
  • Directus UI is view/inspection only.
  • User does not edit IU content in Directus.
  • PG remains source of truth.
  • Directus exposes PG.
  • Nuxt renders what Directus exposes.
  • Metadata/ref-only board first.
  • No raw payload unless separately reviewed.
  • No IU body exposure unless separately reviewed.
  • No Codex dispatch without explicit user approval.
  • No Hermes production until separately reviewed.
  • No Điều 43 schema repair in this flow.
  • No duplicate DOT/counting conventions.
  • Each law/tool owns its specialty: no overlap, no bypass, no double implementation.

8. What went wrong / lessons from this long session

  • User had to repeatedly clarify Directus/Nuxt boundaries; future prompts should include them by default whenever user-facing exposure is involved.
  • User clarified that the board is not just for Hermes/agents; it is also for human monitoring.
  • User clarified that Directus is DOT-only and view-only, not an operation surface.
  • User clarified that Nuxt TreeView patterns are existing assembly standards, not new code targets.
  • User clarified law jurisdiction: do not let one layer solve another layer’s problem.
  • Context length became long; switch sessions at P3D4B/P3D4C boundary.

9. Short answer for next GPT session

If asked “where are we?” answer:

We have completed the PG edit workflow and PG notification runtime. We have designed and reviewed the Directus DOT read-only exposure package. P3D4B passed with GO. The next step is P3D4C: draft an implementation prompt for creating public.v_iu_notification_board and exposing it read-only through Directus DOT. Do not dispatch until GPT/User review.

10. First action in next GPT session

When the user resumes:

  1. Read this handoff.
  2. Read the latest GPT directive: gpt-review-23-p3d4b-execution-pass-and-p3d4c-directive-2026-05-08.md.
  3. Instruct Opus to draft P3D4C prompt, not dispatch.
  4. Preserve all permanent hard boundaries above.
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/handoffs/gpt-handoff-pack23-p3d-notification-directus-2026-05-08.md