GPT Review S191 — P10D-1B Public READ grant prompt

Date: 2026-04-30
Phase: TAC MVP / P10D
Verdict: NOT YET DISPATCH — patch required for least privilege and idempotency

---

1. Overall

The prompt is correct in goal:

• P10D-1A failed only because Public role lacks READ on four tac_* collections.
• Next step is a Directus permission configuration gate, not code.
• The task remains separate from Nuxt implementation.

However, the current prompt should not be dispatched as-is.

---

2. Required patch 1 — Do not grant fields:["*"] to Public

The prompt currently proposes:

"fields": ["*"]

This is too broad for Public role and contradicts the approved minimal-field decision.

Replace with exact minimal field arrays:

{
  "tac_publication": ["id", "doc_code", "version", "name", "lifecycle_status"],
  "tac_publication_member": ["id", "publication_id", "logical_unit_id", "unit_version_id", "render_order"],
  "tac_logical_unit": ["id", "canonical_address", "parent_id", "sort_order", "section_type", "doc_code"],
  "tac_unit_version": ["id", "logical_unit_id", "version_number", "title", "body", "review_state", "lifecycle_status"]
}

If Directus deep-read needs relation access to nested related fields, grant only those related collection fields above. Do not use wildcard.

---

3. Required patch 2 — Make operation idempotent

Before creating permission rows, read existing Public permissions for the four collections.

For each collection:

• If no READ permission exists: create it.
• If READ permission exists with narrower/missing fields: update only that permission to include the minimal field union.
• If READ permission already satisfies minimal fields: leave unchanged.
• Do not create duplicate permission rows.

Report before/after for each collection.

---

4. Required patch 3 — Confirm Public role identity safely

Directus Public role can be represented differently across versions/configs. Do not assume by display name only.

Find the Public role through safe metadata inspection, report role id/name only, no token.

If ambiguous, STOP and ask User to confirm role id in Directus Admin UI.

---

5. Required patch 4 — Add optional lifecycle filter decision

Because the current pilot publications are proposed and UVs are draft/unreviewed, grant is allowed only because User explicitly wants /knowledge/laws to show these official pilot docs now.

Do not add an enacted filter yet if it would hide the 3 pilot documents.

Report this explicitly:

Public READ intentionally exposes current pilot TAC publications for /knowledge/laws. Lifecycle filtering can be added later when publication states are finalized.

---

6. Required patch 5 — Use Directus API safely or Directus Admin UI

Preferred: User/admin applies via Directus Admin UI.

If Agent applies via API:

• use set +x;
• never echo token;
• never include Authorization header in report;
• do not write token-bearing temp files;
• report only permission IDs and redacted status.

---

7. Required verification after grant

Verify as anonymous/Public:

1. 4 collections return HTTP 200.
2. tac_publication returns at least 3 docs.
3. D35 member count = 36.
4. Deep read returns canonical_address, title, and non-empty body for sample rows.
5. Verify a non-granted sensitive field is not exposed if there is a known excluded field worth testing. If no known sensitive field, state not applicable.

---

8. Direction to Opus

Rewrite the P10D-1B prompt with these patches.

Do not dispatch the current wildcard version.

After patching, no additional GPT review is required if the prompt uses exact minimal fields and idempotent create/update logic.

---

9. Boundary

No Nuxt implementation, no DDL/DML, no schema change, no unrelated Directus permission changes.