GPT Review — P3D4C2U Resume BLOCKED at 0F + Rev4 Directive

Date: 2026-05-10
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed:

• knowledge/dev/laws/dieu44-trien-khai/reports/p3d4c2u-resume-notification-display-report.md rev1
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d4c2u-resume-notification-display-prompt-review.md rev3
• Opus review from user-provided context

Verdict

Agent report accepted. Opus review accepted. Prompt rev4 required. Re-dispatch fresh after rev4 review.

The blocker is a prompt-design bug, not an infrastructure failure. Gate 0F is too strict because it requires event_outbox to exist in the build-time generated map while tbl_event_outbox.status=draft. The generator correctly excludes draft rows. The pack's intended mutation is what changes draft → published.

This is a classic chicken-and-egg.

Accepted evidence

Agent report shows:

0A production image d2db418 PASS
0B relations endpoint PASS
0C tbl_event_outbox status=draft PASS
0D permission #1483 exact Option D allowlist PASS
0E registry fields exact 13-field allowlist PASS
0F generated map event_outbox=0 FAIL
0G /knowledge/registries route HTTP 200 PASS
0H /knowledge/registries/event_outbox HTTP 200 pre-mutation PASS
0H DirectusTable marker found, event_outbox marker found, denylist absent PASS
0I no rollback pending PASS
0J PG event_outbox accessible PASS
0L D28 chain PASS

No mutation was executed. Hard boundaries were preserved.

Root cause

The generated map is build-time and filters:

status IN ('active','published')

Current row:

tbl_event_outbox.status=draft

Therefore:

generated_map_has_event_outbox=false

is expected before the pack's publish mutation.

To get event_outbox into the static generated map would require:

1. publish row;
2. regenerate table maps;
3. rebuild Nuxt image;
4. redeploy.

That violates this pack's hard boundaries and is unnecessary because the route already works.

Functional finding

The most important evidence is:

/knowledge/registries/event_outbox → HTTP 200 pre-mutation
DirectusTable marker present
unsafe fields absent

This demonstrates the individual route can resolve/render without a generated map entry. Therefore, the functional gate should be route-level evidence, not static-map presence.

GPT answer to Opus questions

Q1 — Accept 0F → informational?

Yes.

Patch 0F from hard gate to informational / expected-absent-for-draft.

Q2 — Hard gate with exception instead?

Not preferred. It is more complex and less clear. Use informational 0F plus required 0G/0H functional route evidence.

Q3 — Add regenerate step inside this pack?

No. Do not regenerate/build/deploy in this pack. That violates scope and is unnecessary.

Q4 — Carry-forward report or fresh re-run?

Fresh re-run after rev4. The pack is lightweight and the prompt gate semantics changed. Clean baseline is preferred.

Required rev4 patches

P1 — Change 0F from hard gate to informational

Replace:

0F generated map must contain event_outbox; if missing STOP

with:

0F generated map inspection is informational.
For tbl_event_outbox.status=draft, event_outbox absence from generated map is expected because generator excludes draft rows.

Report fields:

generated_map_has_event_outbox=true|false
generated_map_entry_expected_absent_for_draft=true|false
generated_map_status_filter=active,published
generated_map_missing_blocks_publish=false

P2 — Add functional route dependency gates

Make 0G and 0H the real pre-mutation functional gates:

0G /knowledge/registries HTTP 200 required
0H /knowledge/registries/event_outbox HTTP 200 required
0H unsafe fields absent required

If 0H returns 404/500 or unsafe fields appear, STOP before mutation.

P3 — Update preflight logic

Preflight passes if:

0A,0B,0C,0D,0E,0G,0H,0I,0J,0L PASS
0F informational, not blocking

0F missing event_outbox may be reported as:

0F=INFO_EXPECTED_ABSENT_FOR_DRAFT

P4 — Update result routing

If 0F missing but 0G/0H pass, continue.

If 0G/0H fail:

next_required_pack=D28_ROUTE_RESOLUTION_FIX

If unsafe fields appear:

next_required_pack=P3D4C2U_UNSAFE_FIELDS_LEAK_INVESTIGATION

P5 — Add note about future generated map refresh

After publish, the running generated map may still not include event_outbox until the next D28 generation/build/deploy cycle. This is acceptable for this checkpoint because route-level evidence proves display works.

Add future note:

Future D28 maintenance cycle should regenerate table-maps so event_outbox appears in the static artifact after status=published.

This must not block this pack.

P6 — Preserve rev3 field-security fixes

Do not regress:

• safe_payload, correlation_id, causation_id remain denied/unsafe probes;
• permission #1483 Option D allowlist check remains;
• registry fields denylist check remains;
• runtime field deny smoke remains;
• no auto rollback remains.

Directive to Opus

Patch prompt rev4 at:

knowledge/dev/laws/dieu44-trien-khai/prompts/p3d4c2u-resume-notification-display-prompt-review.md

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

After rev4 review

If rev4 is approved, re-dispatch the P3D4C2U resume pack fresh.

Do not carry forward rev3 blocked report as execution baseline, except as evidence that 0G/0H passed previously.

Current state

p3d_resume_report_rev1=ACCEPTED_BLOCKED_BY_PROMPT_BUG
p3d_resume_prompt_current_rev=3
p3d_resume_prompt_rev4_required=true
mutation_executed=false
tbl_event_outbox.status=draft
notification_display_checkpoint=not_unblocked
D28_chain_status=PASS
production_image=nuxt-ssr-local:d2db418

Final status

agent_report=ACCEPTED
opus_review=ACCEPTED
classification=PROMPT_CHICKEN_AND_EGG_0F
next_action=OPUS_PATCH_P3D4C2U_RESUME_PROMPT_REV4