GPT Review — 23-P3D4C2U Option D Prompt rev2

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 rev2

Verdict

REV3 REQUIRED — narrow patch before dispatch.

Rev2 is much stronger and keeps the right architecture: Option D, base table event_outbox, no view, no worker/cron, no Nuxt, no bespoke UI, and field exposure guarded by both Directus permissions and Table Module field config.

However, because Option D exposes the base table, the final prompt must be extra precise about field-leak proof. Rev2 still has a few cases where the tests could pass without actually proving safety.

Accepted rev2 fixes

• Smoke uses intended role/policy, not admin token.
• DirectusTable fetch path requires code evidence.
• table_registry config must use live schema column names.
• Existing event_outbox permissions are audited.
• Duplicate registry check covers both table_id and collection.
• Route smoke is defined for both system_issues and event_outbox.
• Fields are selected from live schema only.
• Unsafe field test explicitly checks safe_payload.
• Rollback tracking is improved.
• Next pack is conditional.

Required rev3 patches

P1 — Existing permission audit must distinguish admin/internal permissions from user-facing exposure

Rev2 says if any existing permission exposes unsafe fields, STOP. That is too broad if there are admin/internal permissions that are not used by the Table Module/user-facing path.

Patch the audit to classify permissions:

permission_scope=TABLE_MODULE_USER_FACING|PUBLIC|INTERNAL_ADMIN|AGENT_INTERNAL|UNKNOWN

Rules:

• If a public/user/Table Module-facing permission exposes unsafe fields → STOP EXISTING_PERMISSION_LEAK.
• If admin/internal permission exposes unsafe fields → report it, but do not block unless DirectusTable uses that admin/internal token for rendering.
• If DirectusTable uses admin/server token, then table_registry fields= selector becomes mandatory and must be proven; otherwise STOP.
• If permission scope cannot be classified → STOP PERMISSION_SCOPE_UNKNOWN.

P2 — Unsafe-field smoke must not pass merely because event_outbox has zero rows

Rev2 allows S3 expected result as “403 OR field omitted OR empty.” If event_outbox is empty, an empty response does not prove field-level denial.

Patch S3:

• Acceptable:
  • 403/400/field-forbidden; or
  • non-empty response with unsafe field omitted; or
  • Directus permission metadata proves unsafe field absent from allowed fields, plus request result is empty due only to zero rows.
• Not acceptable:
  • treating data=[] alone as proof.

Add report fields:

event_outbox_row_count=<N>
unsafe_field_denial_method=HTTP_FORBIDDEN|FIELD_OMITTED_IN_NONEMPTY_RESPONSE|PERMISSION_METADATA_ALLOWLIST_WITH_EMPTY_DATA|FAIL

P3 — Test more than safe_payload; at least one structural unsafe field should be tested too

safe_payload is the most important, but correlation_id and causation_id are real live columns and intentionally omitted. Patch S3/S6 to test at least:

safe_payload
correlation_id
causation_id

If feasible, test the broader denylist by metadata/fields list as well.

P4 — DirectusTable field selector proof must identify the actual config column name

Rev2 requires fields_config_column=<actual>, good. Add one required evidence item:

directus_table_field_source=<table_registry actual column name>

The report must show that DirectusTable reads the same live config column used for tbl_system_issues and will use it for tbl_event_outbox.

P5 — Registry row must be draft unless both API smoke and route smoke pass

Rev2 says publish conditional, good. Strengthen implementation text:

• Always create/update registry row as draft first.
• Publish only after S1-S9 PASS.
• If route smoke cannot be verified, final status remains draft and recommendation is READONLY_EXPOSURE_DRAFT_PENDING_SMOKE.
• Do not publish by default on a successful API-only test.

P6 — Do not change existing compatible permissions unless needed

Rev2 says create only if not exists, but directus permission may exist with compatible fields but missing one desired metadata field. Patch:

• If existing permission is compatible but narrower, either leave it as-is and adapt table_registry fields to that narrower safe set, or update only with explicit report permission_updated_by_pack=true.
• Never broaden an existing user-facing permission without proving all added fields are in the approved metadata allowlist.

P7 — Report must include final actual field lists

Add required report fields:

permission_allowed_fields=<list>
table_registry_fields=<list>
unsafe_fields_absent_from_permission=PASS|FAIL
unsafe_fields_absent_from_registry=PASS|FAIL
permission_registry_fieldset_match=PASS|NARROWER_PERMISSION|FAIL

This is important because Option D relies on two field allowlists being aligned.

Directive to Opus

Patch the prompt to rev3 at:

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

Patch narrowly. Keep Option D. Do not reopen PG view/materialized view/custom extension. Do not dispatch after patch; return for GPT/User 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

Option D remains approved as the right direction, but the final prompt must prove field safety even when event_outbox is empty and must distinguish user-facing permissions from admin/internal permissions. Once these are fixed, the prompt should be close to dispatch.