GPT Prompt S191 — P10D-1A Directus TAC Read Precheck for Opus

Date: 2026-04-30
Purpose: Give Opus a precise next-step prompt.
Principle: PG/render is already proven. Only verify the /knowledge/laws → Directus → tac_* read path.

---

Prompt to Opus

Opus, use this as the next directive. Do not broaden the task.

P10D-1A — Directus TAC Read Precheck for /knowledge/laws

Scope: Read-only precheck. No code implementation. No DDL/DML. No Directus permission mutation.
Goal: Verify whether the current Nuxt /knowledge/laws web role/session can read the four TAC Directus collections needed to display official PG-backed laws.
Important framing: Do not re-check whether PG can render documents. PG/render already passed with D35/D32/D28 round-trip 0 drift. This task only checks whether /knowledge/laws has the Directus “key” to read official TAC data.

---

0. Context — already proven, do not redo

The following are already proven and must not be re-litigated:

• D35, D32, D28 were cut into PG/TAC units.
• 3 publications / 86 units round-tripped with 0 content drift.
• D35 clean render exists as a visual/reference artifact: knowledge/dev/laws/dieu38-trien-khai/reports/p10a-2c-d35-human-render/d35-reconstructed-clean.md
• P10D inventory found existing Nuxt assets:
  • DocsTreeView
  • buildDocsTree
  • markdownToHtml
  • /knowledge/laws/index.vue
• P10D inventory found TAC tables/collections exist.

The only remaining pre-implementation question is:

Can the same web role/session used by /knowledge/laws read tac_publication, tac_publication_member, tac_logical_unit, and tac_unit_version through Directus with the fields needed by the existing components?

---

1. Laws / boundaries

Follow Assembly First:

PG official data → Directus collections/API → Nuxt existing components

Forbidden in this task:

• No code edits.
• No route edits.
• No new file/component.
• No custom Nuxt server route.
• No direct PG from Nuxt implementation.
• No DDL/DML.
• No Directus permission mutation.
• No adding governance_docs rows.
• No token/secret leakage.

---

2. Gate 0 — machine identity

Run via Mac → SSH VPS. All runtime/repo/API checks are on VPS.

echo "=== Control Host ==="
hostname && whoami

echo "=== Runtime Host via SSH ==="
ssh contabo 'hostname -f || hostname'
ssh contabo 'cd /opt/incomex && pwd'
ssh contabo 'docker ps --format "{{.Names}}" | grep -E "postgres|directus"'
ssh contabo 'docker exec postgres psql -U directus -d directus -tAc "SELECT current_database() || chr(47) || current_user;"'

PASS only if runtime host is VPS and DB identity trims to directus/directus.

---

3. Precheck tasks

T1 — Identify current /knowledge/laws Directus access pattern

Read only:

• web/pages/knowledge/laws/index.vue
• any composables/plugins used by that page for Directus access;
• any auth/session/role mechanism used by current laws page to read governance_docs.

Answer:

1. Does /knowledge/laws use useNuxtApp().$directus, readItems, or another existing Directus SDK pattern?
2. Is it public/anonymous, logged-in session, or server-provided token?
3. Which role/policy is effectively used for the current page, if determinable without secrets?

Do not print secrets.

T2 — Test TAC reads using the same safe access path

Using the same pattern/session as current /knowledge/laws as much as possible, test read access to:

• tac_publication
• tac_publication_member
• tac_logical_unit
• tac_unit_version

Minimum required data shape:

Publication list

Fields:

id, doc_code, version, name, lifecycle_status

Expected logical result:

• at least D35, D32, D28 are visible;
• should return 3 current pilot publications if no filter is applied.

Publication members for one known pub

Use D35 if convenient:

pub_id = 27e48995-d6a1-4a44-8559-cab6a07fdbe0

Fields needed:

render_order
logical_unit_id.id
logical_unit_id.canonical_address
logical_unit_id.parent_id
logical_unit_id.sort_order
logical_unit_id.section_type
unit_version_id.id
unit_version_id.title
unit_version_id.body
unit_version_id.review_state
unit_version_id.lifecycle_status

Expected logical result:

• 36 D35 member rows for D35;
• fields include title/body and parent/sort info needed by tree + reader.

If testing D32/D28 is easier, report expected count accordingly.

T3 — Role/permission inspection if read fails

If any TAC read fails:

• Do not mutate permissions.
• Inspect Directus metadata read-only enough to identify missing collection/action, if permitted.
• Report exact missing READ permissions.
• Propose Directus admin UI config only.

Important:

Missing permissions are not a code problem. They are a Directus config gate.

T4 — Token/secret safety

Use existing safe auth method from repo. Do not inline secrets in visible command logs.

If a token is unavoidable:

• load it inside a non-echoing shell scope on VPS with set +x;
• never print token;
• never include Authorization header in report;
• never upload .env contents;
• report only endpoint/collection, status, and redacted response shape/counts.

Do not include any secret-bearing command output in KB.

---

4. PASS / FAIL criteria

PASS

P10D-1A PASS if the current web access path can read:

1. tac_publication publication list with D35/D32/D28;
2. tac_publication_member filtered by one pub_id and sorted by render_order;
3. related LU fields needed for tree: id, canonical_address, parent_id, sort_order, section_type;
4. related UV fields needed for reader: id, title, body, review_state, lifecycle_status.

FAIL

P10D-1A FAIL if:

• current web role/session cannot read one or more required collections;
• deep/read relation fields are denied;
• required body/title/tree fields are unavailable;
• auth path cannot be determined safely.

On FAIL, report missing permissions/config. Do not fix them.

---

5. Output report

Create KB report:

knowledge/dev/laws/dieu38-trien-khai/reports/p10d-1a-directus-tac-read-precheck-2026-04-30.md

Report sections:

1. Gate 0 evidence.
2. Current /knowledge/laws Directus access pattern.
3. TAC read test results by collection.
4. Redacted response shape / row counts.
5. Whether required fields for tree/reader are available.
6. Permission gaps, if any.
7. Verdict: PASS or FAIL.
8. Next action:
   • If PASS: draft one-file assembly wiring prompt for web/pages/knowledge/laws/index.vue.
   • If FAIL: ask User/GPT to authorize Directus admin READ permission config.

---

6. STOP

STOP after uploading report. No implementation. No permission changes.