GPT Correction S191 — P10D v0.2 invalid under Assembly First; reset to PG→Directus→Nuxt assembly design

Date: 2026-04-30
Phase: TAC MVP / P10D
Verdict: Prior GPT approval of P10D Design Brief v0.2 is withdrawn. v0.2 is invalid as implementation direction.

---

1. Reason for correction

User correctly flagged that GPT drifted from the constitutional operating model and under-reviewed Assembly First constraints.

The prior P10D v0.2 design incorrectly authorized a web-app style architecture:

• custom Nuxt server routes;
• direct PG access from Nuxt server routes;
• custom reader/tree/markdown renderer logic;
• server adapter combining sources;
• implementation discussion before exhausting existing PG→Directus→Nuxt assembly path.

This violates the Assembly First order and gateway architecture.

---

2. Laws / evidence checked

Checked KB evidence:

1. knowledge/dev/laws/law-07-assembly-first.md

   • Priority order: PostgreSQL first, Directus existing capabilities second, Nuxt UI / Agency OS third, external OSS fourth, new code only last and only after 0–3 fail + approval.

2. Red Zone context packs / template

   • No built-in renderer fallback.
   • No case-dispatch per section.
   • No business logic in Nuxt.
   • No direct/manual KB table mutation.

3. knowledge/current-state/reform-PG-tools/01-kien-truc.md

   • Gate layer / Nuxt is display/input gateway, not SSOT and must not access DB directly.
   • Nuxt reads through Directus REST/SDK pattern, not direct PG.

4. knowledge/dev/laws/dieu38-trien-khai/reports/p9-gate-b-directus-collection-registration-log-2026-04-28-run2.md

   • 14 tac_* Directus collections registered.
   • tac_logical_unit, tac_unit_version, tac_publication, tac_publication_member are available as collections / API surfaces.

---

3. Correct constitutional interpretation

P10D must not start by coding Nuxt server routes or direct PG pool access.

Correct priority order:

1. PG first: if tree/render shape is needed, create or reuse a PG VIEW/CTE/function as data model, through a separate gate if mutation/DDL is required.
2. Directus second: expose existing TAC collections or approved PG view through Directus REST/SDK permissions.
3. Nuxt third: assemble UI from existing Nuxt/Agency OS components and Directus SDK data. Nuxt is display gateway, not business logic engine.
4. DOT: any repeated transformation/check/render step should be modeled as DOT / registered operational unit if needed.
5. Custom code last: only after PG/Directus/Nuxt assembly options fail and after explicit approval.

---

4. Invalidated items from P10D v0.2

The following are withdrawn and must not be used as implementation direction:

• Custom Nuxt API endpoints /api/laws/publications and /api/laws/publications/:pubId/tree as first design path.
• Direct PG pool from Nuxt server route.
• Nuxt server route owning lifecycle visibility / query business rules.
• Custom Vue tree/reader implementation as default before inspecting existing UI/Agency components.
• Custom markdown renderer selection in Nuxt before proving Directus/Nuxt existing rendering path is insufficient.
• Server adapter combining governance_docs and tac_publication as new code before Directus assembly is exhausted.

---

5. Correct P10D reset direction

Opus must write P10D Design Brief v0.3 — Assembly First Reset.

Required design direction:

5.1 No Nuxt code-first

State explicitly:

P10D does not authorize Nuxt code-first implementation. Nuxt may only assemble existing components/config against Directus API unless a later gate proves assembly is insufficient.

5.2 Data path

Use:

PG tac_* tables / approved PG view
→ Directus collections / Directus REST or SDK
→ Nuxt existing page/component assembly

No direct PG from Nuxt.

5.3 First task is capability inventory, not implementation

Before design implementation, inspect and report:

• Existing Directus API shape for tac_publication, tac_publication_member, tac_logical_unit, tac_unit_version.
• Existing Directus role/policy permissions for TAC read.
• Existing Nuxt /knowledge/laws page and available page/component assembly options.
• Existing Directus SDK usage pattern in Nuxt.
• Existing markdown/rendering components already in Agency OS.
• Whether Directus relational deep queries can assemble publication tree without new PG view.
• If not, propose PG VIEW as a separate gated design, not hidden inside Nuxt.

5.4 Possible implementation patterns, ranked

1. Directus collection deep-read assembly: Use Directus API/SDK to fetch publication + memberships + related units/versions; Nuxt only arranges display.
2. PG VIEW exposed via Directus: If Directus deep query is too awkward, create tac_publication_tree or equivalent view through a separate DDL gate, register/expose through Directus.
3. Directus Flow/operation: If transformation is needed server-side without Nuxt business logic, evaluate Directus Flow/DOT path.
4. Custom Nuxt code: last resort only; requires separate proof that 1–3 fail and explicit GPT/User authorization.

5.5 UI target remains the same, architecture changes

User-facing view still may be:

• listing / reader;
• left tree / right document;
• clean reader mode;
• review overlay;

But it must be assembled through existing PG/Directus/Nuxt mechanisms, not custom Nuxt server/renderer first.

---

6. Immediate directive to Opus

Do not proceed with implementation prompt based on v0.2.

Write v0.3 as a correction brief with:

• “v0.2 invalidated” note;
• law references;
• Assembly First order;
• PG→Directus→Nuxt data path;
• Directus collection inventory requirement;
• no custom Nuxt API / no direct PG from Nuxt;
• possible need for PG VIEW only via separate gate;
• no code implementation yet.

---

7. Accountability note

This was an AI council governance failure. GPT approved a design that should have been rejected under Assembly First and Red Zone constraints. This correction must be treated as the authoritative replacement for the prior v0.2 final review.