KB-FEAD

GPT Review S191 — P10D Inventory + Wiring prompt approved after small scope/security patches

4 min read Revision 1

s191p10dinventorywiringassembly-firstprompt-reviewapproved-after-patches

GPT Review S191 — P10D Inventory + Wiring prompt

Date: 2026-04-30
Phase: TAC MVP / P10D
Verdict: APPROVED AFTER SMALL SCOPE/SECURITY PATCHES

1. Overall assessment

The prompt is now aligned with the correct model:

/knowledge/laws is the future official area for PG/TAC-backed laws.
KB is draft/legacy/artifact path during migration.
The task is inventory first, not implementation.
PG → Directus → Nuxt is the correct data path.
Use existing folder/tree/read components and Directus collections before proposing any new code.
No custom Nuxt server route, no direct PG, no custom tree/renderer.

This is the right direction.

2. Required patches before dispatch

Patch 1 — Rename task to avoid accidental implementation

Current title says Inventory + Wiring, and the header says Effort: Low — inventory + ghép nối.

Risk: Agent may start wiring/implementation despite hard boundary.

Replace with:

P10D — Official Laws Assembly Inventory
Mục tiêu: Inspect existing /knowledge/laws, /docs, Directus TAC API, and folder/tree components to determine the smallest assembly path.
Scope: Read-only inventory + wiring plan only. No implementation.

Do not use “ghép nối” in the task title unless explicitly marked as “plan only”.

Patch 2 — Add folder hierarchy as a first-class requirement

User clarified that /knowledge/laws must preserve a KB-like multi-level folder/tree model, not only a flat 3-publication list.

Add to Phase 2 questions:

Q6: How does the existing KB/Nuxt folder tree support multi-level folders, and can the same component/model represent official PG/TAC documents under /knowledge/laws? Include Điều 38-style nested folders/appendices as a design requirement. Do not flatten to only three documents if existing folder tree supports hierarchy.

Also add inventory check:

Identify whether current folder nodes are path-derived, collection-derived, or explicit records. Report how folder nodes differ from document/publication nodes.

Patch 3 — Token handling must be safe

Current prompt reads DIRECTUS_TOKEN from /opt/incomex/.env and may print API outputs. That risks leaking secrets.

Patch:

Use existing project-approved Directus API/SDK/auth pattern if available.
If token is needed for curl, never print token, never upload token, and mask any Authorization evidence.
Do not cat .env into logs or reports.
Report only request path, status, and redacted sample response.

Suggested wording:

Use existing safe auth method. If reading env is unavoidable, do not echo or upload secrets; mask tokens in all logs. Never include .env contents in the KB report.

Patch 4 — Do not assume specific localhost endpoints exist

http://localhost:3111/api/docs/tree may or may not be the active service/port.

Patch:

First inspect repo/config to identify the actual docs tree API or Directus endpoint. Only call endpoints that are confirmed active in the current deployment. If localhost:3111/api/docs/tree fails or is not authoritative, report that and find the existing route/API from code.

Patch 5 — Output must distinguish “what already exists” vs “what would be new”

Add report table:

This prevents hidden custom work.

3. Direction to Opus

Apply the five patches above, then dispatch Agent inventory.

No further GPT review is required if the task remains read-only and only these patches are applied.

4. Boundary

Agent must STOP after the inventory report. No code edits, no Directus mutation, no DDL/DML, no route changes, no adding governance_docs rows.