GPT Review — 23-P3D4C2U Option D Prompt rev3

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c2u-option-d-base-table-field-allowlist-implementation-prompt.md rev3

Verdict

REV4 REQUIRED — consolidate before dispatch.

Rev3 adds the correct safety concepts: permission scope classification, empty-table unsafe-field proof, testing safe_payload + correlation_id + causation_id, DirectusTable field-source reporting, narrow-permission handling, and permission/registry fieldset cross-check.

However rev3 is written as an incremental delta over rev2:

Hard Boundaries — same as rev2
Step 0 — same as rev2 PLUS
Steps 2-3 — same as rev2
All other smoke tests S1-S9 — same as rev2
Steps 5-6 — same as rev2
Verification — rev2 PLUS

This is not dispatch-safe. The current document content no longer contains the full rev2 instructions. A production execution prompt must be self-contained so the Agent does not have to reconstruct missing steps from memory/history.

Accepted rev3 additions

• Permission audit classified by scope:
  • TABLE_MODULE_USER_FACING;
  • PUBLIC;
  • INTERNAL_ADMIN;
  • AGENT_INTERNAL;
  • UNKNOWN.
• User-facing/public leak = STOP.
• Admin/internal leak = report only, unless Table Module renders with admin/server token.
• directus_table_field_source=<actual table_registry column name> required.
• Narrow compatible permission handling is explicit.
• Unsafe-field smoke covers at least:
  • safe_payload;
  • correlation_id;
  • causation_id.
• Empty event_outbox cannot prove safety by empty response alone; permission metadata must be checked.
• Report fields for permission/registry fieldset match are required.

Required rev4 patches

P1 — Make the prompt fully self-contained

Rewrite rev4 as a full consolidated implementation prompt. Do not use references like:

same as rev2
same as before
rev2 PLUS
all other fields from rev2

Rev4 must contain the complete hard boundaries, all Step 0–6 instructions, all smoke tests, all rollback instructions, and the full verification block.

P2 — Restore all core rev2 content in the consolidated prompt

Rev4 must include, explicitly:

• verify clean state/residual from view path;
• verify event_outbox is base table with real PK;
• confirm Directus sees event_outbox;
• audit all existing permissions;
• prove DirectusTable fetch path;
• inventory PG role / Directus role / write channel convention;
• inventory live table_registry schema and exact config column;
• duplicate check by both table_id='tbl_event_outbox' and collection='event_outbox';
• IU + event core snapshot;
• create/update read permission with approved metadata allowlist only;
• patch field labels idempotently;
• create/update table_registry row as draft first;
• smoke S1-S9;
• publish only if S1-S9 PASS;
• rollback only pack-created changes;
• conditional next pack.

P3 — Tighten unsafe-field smoke wording

Current rev3 says each unsafe field request may return:

403 OR field omitted OR empty object

Patch to avoid ambiguity:

• If row_count > 0:
  • acceptable: HTTP 403/400 field forbidden, or non-empty data where the unsafe key is absent;
  • unacceptable: unsafe key returned with any value.
• If row_count = 0:
  • response content alone is inconclusive;
  • must verify Directus permission metadata and Table Module registry fields exclude unsafe fields.

Avoid using “empty object” as a standalone pass condition.

P4 — Explicitly require both allowlist layers to match or be safely narrowed

Rev4 must state:

permission_allowed_fields ⊇ table_registry_fields is required, unless registry is adjusted narrower.
Both sets must exclude unsafe fields.

If permission is narrower than proposed registry fields:

• adjust registry to the narrower safe set; or
• update permission only with approved metadata fields and report permission_updated_by_pack=P3D4C2U_D.

P5 — Preserve Option D boundaries

Do not reopen:

• PG view;
• materialized view;
• worker/cron;
• custom Directus extension;
• Nuxt code;
• bespoke UI.

Directive to Opus

Patch the prompt to rev4 at:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c2u-option-d-base-table-field-allowlist-implementation-prompt.md

Rev4 must be a full consolidated prompt, not an incremental patch note. Do not dispatch after patch; return for GPT/User final review.

Hard boundaries unchanged

• No PG view.
• No materialized view.
• No worker/cron/refresh.
• No new table/write path.
• No custom Directus extension.
• No Nuxt code.
• No bespoke notification UI.
• No Directus click-config.
• No Directus write/mark-read.
• No unsafe field exposure.
• No IU runtime change.
• No event core mutation except Directus permission/field metadata/table_registry exposure.
• No Điều 43 machinery change.

Summary

Rev3 contains the right additions, but it is not a standalone execution prompt. Rev4 should consolidate rev2 + rev3 into one complete, self-contained production prompt.