Pack 23 P3D UI Boundary — Directus/Nuxt Assembly Only

Date: 2026-05-08
Source: User operational note + existing Assembly First rules.

Rule

All notification / IU edit UI exposure must follow the already-established assembly-first path:

Postgres tables/functions/views
→ Directus collections / permissions / REST or SDK
→ Nuxt existing screens/components read from Directus

Hard boundaries

• No Nuxt custom business logic.
• No new Nuxt code by default.
• No direct PG access from Nuxt.
• Nuxt is only a screen reading from Directus.
• Directus reads from PG.
• PG remains the source of truth for IU workflow, notification events, read state, and board state.
• Any later UI work must first inspect existing Directus/Nuxt capability and reuse/assemble existing pieces.

Implication for P3D

P3D notification runtime can create PG-native objects such as:

• iu_notification_event;
• iu_notification_read;
• fn_iu_unread;
• fn_iu_mark_read;
• fn_iu_notification_board;
• notification triggers.

But any UI/dashboard exposure must be done later through Directus configuration or existing Nuxt assembly, not new Nuxt code.

Future context pack requirement

P3D3 context update must include this boundary explicitly so future AI/Agent sessions do not drift into Nuxt code-first work.

Suggested wording:

UI boundary: PG is source of truth; Directus exposes PG; Nuxt only reads from Directus through existing assembled screens/components. Do not add Nuxt business logic or direct PG access from Nuxt.