GPT Review — 23-P3D4C0 Prompt rev1

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c0-new-piece-document-batch-notification-design-prompt.md rev1

Verdict

Rev1 is directionally correct, but do not dispatch yet. Rev2 required.

Opus correctly pivoted from Directus exposure to new-piece/document-batch notification design and included the User’s performance principle: derived computations must not slow AI↔PG interaction. However, rev1 still risks implying triggers should do too much and does not fully pin down the lightweight/outbox-first performance model.

Accepted rev1 points

• Birth/new-piece notification gap is recognized.
• Document/batch spam problem is recognized.
• Creator implicit self-read is included.
• Debounce window 90–120s is included.
• Debounce is configurable, not hardcoded.
• PG-native approach is required.
• No external scheduler/tooling.
• No Directus/Nuxt mutation.
• Design-only scope is correct.

Required rev2 fixes

P1 — Make “hot path must be O(1) lightweight” explicit

Add a key principle and design question:

Hot path rule: triggers/functions on IU creation/edit/comment must do only minimal O(1) append to a lightweight staging/outbox table. No aggregation, no batch detection, no COUNT, no joins, no JSON building beyond minimal refs on the write path.

Derived work (grouping, debounce, rollup, latest_readers, count) happens later in scheduled processing or read view.

P2 — Prefer staging/outbox + pg_cron as the default architecture

Rev1 lists options. Make GPT/User preference explicit:

Preferred architecture: PG staging/outbox table + pg_cron worker every 90–120s.

The design may compare alternatives, but must justify any deviation from this default.

Do not use LISTEN/NOTIFY as the main design for Phase 1. It is optional signal only and deferred.

P3 — Separate three tables/concepts in the design

Rev1 mentions staging table but does not force the distinction. Add requirement to evaluate/define:

1. iu_notification_pending or equivalent — lightweight append-only staging/outbox.
2. iu_notification_event — durable notification events already exist.
3. Directus-facing view — derived read projection, later.

The design must state which computations happen in each layer.

P4 — Batch/document grouping must require a stable grouping key

Add:

No grouping by timing alone.

90–120s debounce alone is not enough to decide “same document”. Grouping must use a stable key if available:

• source_document_id;
• import_batch_id;
• parent_document_id;
• canonical address root;
• ingestion job id;
• explicit batch token.

If no stable grouping key exists, design must choose one of:

• recommend adding minimal source_document_ref / import_batch_ref later;
• emit piece-level events with gap disclosed;
• defer batch rollup.

P5 — Batch threshold and single-piece rule must be explicit

Add design parameters:

• batch_piece_threshold, default 2 or more pieces sharing same stable grouping key;
• if count >= threshold → document-level rollup event;
• if count = 1 → piece-level event;
• if existing document receives one new piece later → piece-level event.

These should be configurable.

P6 — Performance budget fields required

The output/report must include performance analysis:

hot_path_operations=<description>
hot_path_joins=0
hot_path_aggregations=0
hot_path_expected_complexity=O(1)
derived_processing_window_seconds=90_120
expected_ai_pg_latency_impact=LOW|MEDIUM|HIGH

P7 — Current P3D2 triggers must be reviewed for hot-path impact

P3D2 already has notification triggers. P3D4C0 must inventory whether those triggers currently do more than lightweight inserts.

Report:

p3d2_trigger_hot_path_review=PASS|FAIL|LIMITED
p3d2_trigger_heavy_work_found=true|false

If current triggers are heavy, recommend a later refactor; do not mutate in P3D4C0.

P8 — “New piece” should be modeled as a notification event, not necessarily a birth trigger mutation immediately

Avoid jumping straight to birth trigger. Add options:

• hook into existing fn_iu_save/creation function path if safer;
• trigger on information_unit insert if lightweight;
• trigger on unit_version version_seq=1 if canonical;
• pending/outbox append from creation function if already the controlled gateway.

The design must recommend the least invasive, fastest, law-compliant hook.

P9 — Existing notification board exposure should be paused or explicitly gap-aware

Add clear recommendation field:

p3d4c_directus_exposure_status=PAUSE_UNTIL_BIRTH_BATCH_DESIGN|ALLOW_GAP_AWARE_CURRENT_RUNTIME|DEFER

GPT preference: PAUSE_UNTIL_BIRTH_BATCH_DESIGN unless User explicitly wants a limited board first.

P10 — Add no continuous polling / no per-event immediate recomputation boundary

Hard boundary:

• no tight polling loops;
• no per-event immediate aggregation;
• no sync vector/notification computation on AI interaction path;
• no compute-heavy trigger logic.

P11 — Add future quiet-period/observability requirement

For any later implementation, require:

• metrics: pending count, processed count, processing duration, error count;
• quiet period after enabling birth/batch worker before Directus exposure;
• rollback disables worker/triggers safely.

P3D4C0 only designs this; no implementation.

P12 — Update recommendation options

Rev1’s recommendation options are good but should reflect performance/gap choice:

• EXTEND_RUNTIME_BEFORE_DIRECTUS_EXPOSURE — only if stable grouping key exists or minimal key addition is safe;
• DESIGN_STAGING_OUTBOX_FIRST — if birth/batch requires new pending table/worker design before runtime extension;
• EXPOSE_CURRENT_RUNTIME_WITH_GAP_DISCLOSED — only if User accepts incomplete new-piece visibility;
• DEFER_BIRTH_BATCH_UNTIL_SOURCE_SCHEMA_READY.

Directive to Opus

Patch P3D4C0 prompt rev1 to rev2 with P1–P12.

Path:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c0-new-piece-document-batch-notification-design-prompt.md

Do not dispatch after patch. Return for GPT/User review.

Hard boundaries remain

• No dispatch.
• No implementation.
• No PG mutation.
• No Directus mutation.
• No Nuxt code.
• No Hermes.
• No new external scheduler/tool.
• No heavy trigger logic.
• No direct PG from Nuxt.
• No user-facing board completeness claim until birth/batch gap is resolved or explicitly disclosed.

Summary

Rev1 captures the business problem. Rev2 must sharpen the performance architecture: write-path triggers/functions should only append lightweight pending events; debounce/rollup/grouping should happen asynchronously via PG-native staging/outbox + pg_cron; grouping requires a stable grouping key, not timing alone.