GPT Review — 23-P3D4C0Y 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-p3d4c0y-universal-phase2-poc-scope-plan-prompt.md rev1

Verdict

REV2 REQUIRED — do not dispatch rev1.

The prompt is directionally correct and incorporates the main P3D4C0X decisions: Option C locked, IU runtime untouched, P3D4C1 absorbed into universal design, event_type_registry required, LISTEN/NOTIFY deferred, and Đ45 deferred until after PoC evidence.

However rev1 should be patched before dispatch because several points could lead the Agent to design a PoC that is insufficiently grounded in live PG reality or duplicates existing configuration/Đ43 conventions.

Accepted parts

• Correctly keeps P3D4C1 IU-specific paused/absorbed.
• Correctly keeps existing iu_notification_* runtime unchanged.
• Correctly frames P3D4C0Y as design/scope plan only.
• Correctly requires candidate schema, IU compatibility C-i, routing/exposure, stream taxonomy check, Đ43 alignment, and implementation roadmap.
• Correctly keeps hard boundaries: no implementation, no PG/Directus/Nuxt mutation, no Hermes/Codex, no external tool/scheduler.

Required rev2 patches

P1 — Add live read-only inventory for candidate PoC domain

Rev1 asks Agent to evaluate system_issues, dot_execution, birth_registry, but does not require inventory of actual live PG tables/columns/triggers/functions.

Patch Step 1 to require read-only inventory for each candidate:

• Does the table exist?
• What are PK, lifecycle/status columns, timestamps, actor/owner columns?
• Are there existing triggers/events/health logs?
• Is there an existing stable correlation key?
• What write path would produce a governance-significant event?
• Is the domain low-risk enough for first PoC?

If system_issues is absent or unsuitable, Agent must choose another candidate and justify.

P2 — Do not introduce event_config if dot_config/existing config is the correct convention

Rev1 proposes event_config. P3D4C0X recommended reusing namespaced dot_config unless a review finds it incompatible.

Patch to require:

• inventory existing config tables, especially dot_config;
• prefer dot_config namespace keys like event.debounce_seconds.default, event.debounce_seconds.<domain>, event.batch_threshold.<domain>;
• propose a new event_config table only if dot_config is absent/incompatible and explicitly justify non-duplication with Đ43/DOT conventions.

P3 — event_type_registry should not be described as “CHECK constraint backed” unless exact enforcement is valid

PG CHECK constraints cannot dynamically reference registry rows. Rev1 says “CHECK constraint backed” too loosely.

Patch to ask Agent to choose one valid enforcement model:

• FK/compound FK from event_outbox(event_domain,event_type) to event_type_registry(event_domain,event_type);
• static CHECK constraints generated from registry by DOT/migration;
• trigger validation against registry, if justified;
• or registry-only advisory validation for Phase 2 PoC with hard STOP before production.

Preferred for universal core: compound FK where feasible, plus CHECKs for stream/severity enums.

P4 — Clarify pending table strategy: universal vs per-domain

Rev1 says “event_pending (per-domain staging)” but names it singular. P3D4C0X recommended per-domain pending for staging, while universal durable event/read state.

Patch to require Agent to decide and name clearly:

• event_pending universal staging; or
• {domain}_event_pending per-domain staging; or
• hybrid pattern.

The recommendation must explain hot-path cost, index strategy, cleanup, and worker complexity. Do not leave ambiguous.

P5 — Strengthen IU C-i compatibility plan

Rev1 says v_event_unified + fn_event_unread, but should explicitly protect active IU front-door APIs.

Patch:

• fn_iu_unread, fn_iu_mark_read, fn_iu_notification_board signatures and return shapes remain unchanged;
• C-i must not dual-write IU triggers;
• C-i must not migrate IU rows;
• universal board may read existing IU events via v_event_unified, but IU callers remain on current functions;
• no iu_notification_* DDL/DML in P3D4C0Y.

P6 — Add payload safety and event envelope registry to required output

Rev1 has payload safety in verification but not enough in Step 2.

Patch candidate schema section to include:

• payload key allowlist/denylist;
• payload_classification;
• no body/content/vector/secret/token/personal data;
• correlation/causation ID policy;
• idempotency key policy.

P7 — Stream taxonomy check should decide task vs review rule, not merely discuss overlap

Patch Step 6 to require a concrete rule such as:

• review = content/decision review request;
• task = operational assignment/checkpoint not primarily content review;
• or a different rule if Agent justifies.

Report must include task_review_boundary_rule=<text>.

P8 — Đ43 alignment must include exact additive-vs-review gate

Patch Step 7 to require:

• if using existing pg_query source mode and existing section schema, mark ADDITIVE_ONLY;
• if adding new context-pack section/template contract or changing Đ43 build/verify machinery, mark NEEDS_D43_REVIEW;
• if dependent Đ43 tables/functions are missing, mark BLOCKED.

P9 — Add explicit rollback and failure-mode design even though this is scope-only

Rev1 asks risk assessment and rollback, but the implementation roadmap should require rollback design for future implementation:

• drop order;
• data preservation rule;
• no destructive rollback on success;
• IU untouched guarantee;
• event registry rollback if pilot data exists;
• cron unschedule if future worker exists.

P10 — Restore detailed report fields from GPT directive

Rev1 verification is too short compared with the directive. Add fields:

phase_status=PASS|FAIL|NEEDS_MORE_INVENTORY
poc_domain_selected=<domain>
poc_domain_justification=<short>
poc_domain_pg_inventory=PASS|FAIL|LIMITED
candidate_domains_evaluated=<count>
universal_core_schema_drafted=PASS|FAIL
event_type_registry_defined=PASS|FAIL
event_type_enforcement_model=FK|STATIC_CHECK|TRIGGER|REGISTRY_ONLY_DEFERRED
config_strategy=REUSE_DOT_CONFIG|NEW_EVENT_CONFIG_JUSTIFIED|BLOCKED
event_pending_strategy=UNIVERSAL|PER_DOMAIN|HYBRID
iu_compat_c_i_plan=PASS|FAIL
v_event_unified_strategy=PASS|FAIL
routing_minimal_phase2_defined=PASS|FAIL
exposure_projection_plan=PASS|FAIL
directus_mutation_required=false
nuxt_code_required=false
d43_alignment=ADDITIVE_ONLY|NEEDS_D43_REVIEW|BLOCKED
p3d4c1_status=PAUSED_ABSORBED_INTO_UNIVERSAL
activity_log_boundary_enforced=PASS|FAIL
payload_safety_rules=PASS|FAIL
task_review_boundary_rule=<text>
hot_path_contract=O1_APPEND_ONLY
worker_strategy=PG_CRON_ONLY|NO_WORKER_NEEDED_FOR_POC
listen_notify_status=DEFERRED_PHASE3
rollback_plan=PASS|FAIL
no_pg_mutation=true
no_directus_mutation=true
no_nuxt_code=true
no_iu_runtime_change=true
recommendation=P3D4C1U_UNIVERSAL_CORE_IMPLEMENTATION_PROMPT_REVIEW|REVISION_REQUIRED|NEEDS_D43_ALIGNMENT|NEEDS_LAW_APPENDIX

Directive to Opus

Patch the prompt to rev2 at:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c0y-universal-phase2-poc-scope-plan-prompt.md

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

Hard boundaries unchanged

• No implementation during prompt patch.
• No PG mutation.
• No Directus mutation.
• No Nuxt code.
• No Hermes/Codex.
• No external scheduler/tool/service.
• No change to existing iu_notification_* runtime.
• Do not resume old IU-specific P3D4C1.

Summary

P3D4C0Y rev1 is close but should be hardened before dispatch. Rev2 must ground PoC domain selection in read-only PG inventory, avoid config duplication with Đ43/DOT, define valid event-type enforcement, clarify pending strategy, and preserve IU compatibility with no ambiguity.