Incomex AI Portal
KB-2956

GPT Prompt S191 — P10D Assembly-First Recovery Directive for Opus

9 min read Revision 1
s191p10dopus-promptassembly-firstdirectusnuxtrecovery

GPT Prompt S191 — P10D Assembly-First Recovery Directive for Opus

Date: 2026-04-30
Purpose: Directive prompt for Opus after P10D v0.2 invalidation.
Principle: Assembly First. Recover the already-working PG→Directus→Nuxt path. No reinvention.

Prompt to Opus

Opus, read carefully and execute as a governance correction + minimal recovery design task.

0. Context

We made a governance error in P10D v0.2 by drifting into a code-first web-app design: custom Nuxt server routes, direct PG from Nuxt, custom renderer, and custom assembly logic.

That direction is invalid.

The User clarified the real situation:

  • We already connected/rendered at least one document on Nuxt before.
  • The core capability already exists somewhere in the stack.
  • Tree view is also an assembly problem, not a greenfield coding problem.
  • We are not building a new app. We are arranging existing parts correctly.
  • The governing model is Assembly First and PG → Directus → Nuxt.

Your task is not to invent. Your task is to recover, inventory, and reconnect the simplest existing path.

1. Must-read laws / references first

Read from KB / Agent Data before writing any new design:

  1. knowledge/dev/laws/law-07-assembly-first.md
  2. knowledge/dev/reports/gpt-correction-s191-p10d-v0-2-invalid-assembly-first-reset-2026-04-30.md
  3. knowledge/dev/reports/gpt-decision-s190-p10b-complete-s188-closeout-direction-2026-04-30.md
  4. knowledge/dev/planning/assembly-roadmap.md
  5. knowledge/dev/ssot/assembly-module/index.md
  6. knowledge/other/guides/context-packs/web-frontend.md
  7. knowledge/dev/laws/dieu38-trien-khai/reports/p9-gate-b-directus-collection-registration-log-2026-04-28-run2.md
  8. Red Zone / context pack constraints if available:
    • no business logic in Nuxt;
    • no direct PG from Nuxt;
    • no case-dispatch per section/doc;
    • no built-in renderer fallback;
    • no custom code unless PG/Directus/Nuxt assembly options fail.

Also search for prior actual working Nuxt document render / tree view evidence. Search terms:

  • Nuxt document render one document tree view
  • laws page render Directus document Nuxt
  • assembly roadmap DirectusTable reader knowledge laws
  • governance_docs laws page Nuxt Directus
  • P10A human-readable render Nuxt view

2. Non-negotiable constitutional constraints

2.1 Correct data path

Use this path:

PG tac_* / approved PG view if already available
→ Directus collections / Directus REST or SDK
→ Nuxt existing route/component assembly

Do not propose:

Nuxt custom server route → direct PG pool

Do not create a new data plane.

2.2 Assembly priority order

Follow Điều 7 priority:

  1. PostgreSQL / existing DB shape first.
  2. Directus existing collections/API/permissions.
  3. Nuxt UI / Agency OS existing components.
  4. Existing OSS already installed.
  5. Custom code only if 0–3 fail and after explicit approval.

2.3 Scope of this task

This task is design recovery + inventory + minimal next-action plan only.

Do not dispatch implementation.
Do not propose new custom server APIs.
Do not propose direct Nuxt→PG.
Do not propose Directus schema change unless proven necessary and separated as its own gate.
Do not propose a new renderer if an existing renderer/view already works.

3. What you must determine

3.1 Find the already-working path

The User states we already connected a document and saw it in Nuxt. Find where that happened.

Inspect/research:

  • Which Nuxt route/page currently shows a connected document?
  • Which component renders it?
  • Which Directus collection/API does it read from?
  • Does it use governance_docs, TAC collections, or another collection/view?
  • Does it already support markdown rendering?
  • Does it already support tree/accordion/list structure?
  • What is missing to link the 3 TAC publications into that path?

Your report must include file paths / route names / collection names when known.

3.2 Inventory Directus TAC readiness

Confirm the existing Directus exposure:

  • tac_publication
  • tac_publication_member
  • tac_logical_unit
  • tac_unit_version

Check whether they can be read through Directus API / SDK under existing permissions. Do not mutate permissions in this task.

Questions to answer:

  • Are these collections visible in Directus metadata/API?
  • Are their fields and relations usable enough for deep reads?
  • Can Directus deep query fetch publication → memberships → logical unit → unit version?
  • If deep query is awkward, can existing collection list/detail pages already display them via DirectusTable?

3.3 Inventory Nuxt assembly assets

Check what already exists:

  • /knowledge/laws current page.
  • Current governance_docs listing and detail/read page if any.
  • Directus SDK usage pattern in Nuxt.
  • Existing Agency OS / Nuxt UI components:
    • table/list;
    • accordion/tree/menu;
    • markdown/content renderer;
    • detail page/card/reader component.
  • Any existing DirectusTable, dynamic collection view, or registry-driven page that can display TAC collections with little/no custom code.

Do not invent components until this inventory is complete.

3.4 Clarify the actual user-facing model

The immediate UI model is not topic graph yet. It is:

Document assembly first:
Publication list → select one publication → read assembled document/tree

But implement this by reusing existing routes/components as much as possible.

Do not design a new “topic/folder knowledge graph” now.

Possible later views, but not now:

  • by topic;
  • by folder;
  • by section_type;
  • cross-document search;
  • KG/vector views.

Current target is only to expose already validated publications in the existing UI path.

4. Preferred minimal implementation concept

After inventory, rank options from simplest to most invasive.

Option A — Pure existing Directus/Nuxt collection assembly

If existing collection/detail/table/view components can show TAC publications and related members:

  • Use existing /knowledge/laws listing or a TAC Publications section driven by Directus API.
  • Link to existing generic collection/detail/read view if available.
  • Use existing Directus relations/deep reads if they work.
  • Tree view may be assembled from existing accordion/tree component if already present.

This is preferred.

Option B — Directus-deep-read + existing Nuxt components

If a little route wiring is needed but no new data plane:

  • Nuxt uses existing Directus SDK only.
  • No direct PG.
  • No custom server route unless it is already the established Directus proxy pattern.
  • Use existing components for list/tree/reader.
  • Keep added code/config minimal and register it as assembly wiring, not new business logic.

Option C — PG VIEW exposed through Directus

Only if Directus deep relations cannot produce a usable ordered tree.

  • Propose a tac_publication_tree VIEW or equivalent as a separate gated PG/Directus design.
  • Do not implement it in this task.
  • Explain why existing Directus deep read is insufficient.

Option D — Custom Nuxt code

Last resort only. Do not recommend unless A–C are proven insufficient.

5. Required output

Create a KB document:

knowledge/dev/laws/dieu38-trien-khai/P10D-assembly-first-recovery-plan-v0-1.md

Title:

P10D Assembly-First Recovery Plan v0.1

The document must include:

  1. Retraction note — P10D v0.2 code-first direction invalidated.
  2. Law basis — Assembly First, PG→Directus→Nuxt, no direct PG from Nuxt, no business logic in Nuxt.
  3. Existing working Nuxt document path — what already works, with route/component/collection evidence.
  4. Directus TAC collection inventory — what is exposed and usable.
  5. Nuxt assembly inventory — what components/routes already exist.
  6. Simplest path recommendation — choose A/B/C/D, with preference for A or B.
  7. Minimal next prompt — what Agent should do next, ideally read-only/probe first.
  8. Hard boundaries — no DDL/DML, no new Nuxt server API, no direct PG from Nuxt, no custom renderer unless separately authorized.
  9. User-facing explanation — simple description: “we are only connecting existing TAC publications to the existing reader/tree path.”

6. Tone and effort

Do not over-design.
Do not rebuild.
Do not write a long speculative architecture.
This is a recovery plan to reuse what already exists.

The correct mindset:

“Find the bridge already built. Put signs and rails on it. Do not build another bridge.”

7. STOP condition

After writing the recovery plan to KB, STOP and ask GPT/User for confirmation.

No implementation dispatch yet.