GPT Review — 23-P3D4 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-p3d4-directus-exposure-design-review-prompt.md rev3

Verdict

Rev3 is strong, but do not dispatch yet. Rev4 required.

Opus correctly added law jurisdiction governance and no-overlap controls. The prompt is now constitutionally safer. However, P3D4 still has one operational ambiguity: Directus inventory. The prompt allows read-only Directus inventory but does not define which tool/API to use, what credentials/source are allowed, and what to do if Directus inventory access is not available. This can cause an Agent to improvise.

Accepted rev3 improvements

• Mandatory law pre-read is present.
• Law Jurisdiction Map is present.
• No layer bypass hard rule is present.
• No-overlap checklist is present.
• Directus UI is view-only inspection, not operational/config surface.
• Recommendation wording avoids immediate implementation.
• Report fields include law jurisdiction evidence.
• Key principle “Mỗi luật giữ chuyên môn” is present.

Required rev4 fixes

P1 — Define Directus inventory method and fallback

Add a section under Step 2:

Directus inventory method

Rules:

• Prefer official Directus API read-only endpoints if an approved token/connection is already available to the Agent environment.
• Do not request or expose secrets.
• Do not create new Directus tokens.
• Do not use Directus UI for any configuration action.
• If Directus API access is unavailable, do not fail the whole pack automatically; record inventory_directus=LIMITED_NO_ACCESS and perform design from PG inventory + existing KB docs, clearly marking assumptions.
• If Directus API is available, list exact endpoints/objects inspected in the report.

Reason: P3D4 is a design review. Lack of Directus API access should not push the Agent into unsafe UI/config work.

P2 — Clarify PG inventory read-only method

Add:

• PG inventory can use read-only SQL/psql inspection only;
• no CREATE, ALTER, DROP, INSERT, UPDATE, DELETE;
• if SQL credential is not available, record inventory_pg=LIMITED_NO_ACCESS and rely on P3D2/P3D3 reports, but do not mutate anything.

P3 — Add access limitation report fields

Report must include:

inventory_directus_access=FULL_READ_ONLY|LIMITED_NO_ACCESS|FAILED_UNSAFE
inventory_pg_access=FULL_READ_ONLY|LIMITED_NO_ACCESS|FAILED_UNSAFE
inventory_assumptions_documented=PASS|FAIL

If either inventory is limited, design review may still PASS only if assumptions are explicitly documented and no unsafe access attempt occurred.

P4 — Strengthen “no body content exposure” into design requirement

Rev3 says no body content unless needed. For P3D4, make the default stricter:

• Phase 1 recommendation must be metadata/ref-only by default.
• Any proposal to expose IU body content must be marked OUT_OF_SCOPE_REQUIRES_SEPARATE_REVIEW.

Add to design note requirements and compliance checklist:

metadata_only_exposure_default: PASS/FAIL
body_content_exposure=OUT_OF_SCOPE_REQUIRES_SEPARATE_REVIEW|NOT_INCLUDED

P5 — Add DOT package output expectation for recommended next pack

If recommendation is A/B/C, the design note must outline what a future P3D4B DOT/change package would contain at high level, without implementing it:

• candidate PG view name, if any;
• Directus collection/view exposure plan;
• role/permission intent;
• read-only vs controlled mark-read boundary;
• rollback/review requirements.

This keeps the next step DOT-driven and prevents ad-hoc UI clicking.

Directive to Opus

Patch P3D4 prompt rev3 to rev4 with P1–P5.

Path:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4-directus-exposure-design-review-prompt.md

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

Hard boundaries remain

• No dispatch.
• No PG mutation.
• No Directus config mutation.
• No Directus content operation.
• No manual Directus UI changes.
• No Nuxt code.
• No Nuxt business logic.
• No direct PG from Nuxt.
• No Codex dispatch without user approval.
• No Hermes production start.
• No law/tooling jurisdiction overlap.
• No secret/token creation or disclosure.

Summary

Rev3 is constitutionally strong. Rev4 should make the read-only inventory procedure safe and explicit, handle missing Directus/PG access without unsafe improvisation, and lock Phase 1 exposure to metadata/ref-only by default.