Incomex AI Portal
KB-3908

GPT Alignment S191 — P10D official /knowledge/laws model after User clarification

5 min read Revision 1
s191p10dofficial-lawsassembly-firstpg-directus-nuxtalignment

GPT Alignment S191 — P10D official /knowledge/laws model after User clarification

Date: 2026-04-30
Phase: TAC MVP / P10D
Status: Alignment correction after User clarification.

1. Corrected understanding

/knowledge/laws is the future official area for PG/TAC-backed documents.

It is not merely a link farm to KB artifacts and not a temporary redirect to /docs.

Correct model:

KB documents = drafts / legacy / archive during migration
PG TAC publications = official structured documents
/knowledge/laws = official reader area for PG TAC publications

The existing KB clean-render artifacts (D35/D32/D28) are evidence that PG round-trip works and that a readable document output exists, but they are not the final serving model.

2. Why this matters

The long-term strategy is:

  1. Use P10A/P10B pilot documents to prove cut → PG → assemble → render.
  2. Expose PG/TAC-backed official publications in /knowledge/laws.
  3. Later cut the rest of KB documents into structured PG units.
  4. Eventually KB markdown documents become drafts/legacy and may be removed as official source.

Therefore P10D must design the official PG-backed view, while still obeying Assembly First.

3. Correct immediate target

Immediate P10D target:

/knowledge/laws
  → Official TAC Publications section/list
  → select D35/D32/D28 publication
  → read assembled document from PG/TAC via Directus
  → use existing Nuxt/Agency components where possible

Do not redirect to KB clean-render markdown as the final solution.

Use KB clean-render artifacts only as:

  • proof of expected visual output;
  • diff/reference artifact;
  • fallback evidence for comparison.

4. Correct Assembly First interpretation

Assembly First does not mean “do nothing” or “link to KB forever.”

It means:

  1. Reuse PG/TAC data already produced.
  2. Reuse Directus collections/API already exposed by G8B/Gate B.
  3. Reuse existing Nuxt route/component patterns such as /knowledge/laws, /docs, DocsTreeView, buildDocsTree, Directus SDK, and existing markdown rendering if repo inspection confirms them.
  4. Only add the minimum wiring/config needed to connect PG official publications into the official route.
  5. Do not create a new data plane, custom server API, direct PG access from Nuxt, or custom renderer unless all existing paths fail and a separate gate approves it.

5. Direction to Opus

The next Opus/Agent task should not ask whether to link KB artifacts as the solution. It should inventory how to wire PG-backed TAC publications into /knowledge/laws with the smallest reuse path.

Required framing:

  • /knowledge/laws remains the target official URL area.
  • Current KB/governance_docs content should be separated as drafts/legacy if needed.
  • D35/D32/D28 official entries must come from tac_publication and related TAC collections, not from KB markdown file paths as the final source.
  • Existing D35 clean-render artifact is the visual/reference benchmark.
  • Determine whether Directus deep-read + existing DocsTreeView/reader components are enough.
  • If not enough, propose the smallest gated missing piece, likely PG VIEW exposed through Directus, not Nuxt direct PG.

6. Minimal next task wording

Recommended next task:

P10D-0 — Official Laws Assembly Inventory for /knowledge/laws

Purpose:

Inspect the existing repo and Directus API to find the smallest Assembly First path to display the three PG/TAC official publications under /knowledge/laws, using Directus collections and existing Nuxt/Agency components. No implementation yet.

7. Hard boundaries

  • No custom Nuxt server route.
  • No direct PG from Nuxt.
  • No custom renderer unless existing renderer is proven insufficient.
  • No custom tree component unless existing tree/list components are proven insufficient.
  • No Directus schema/permission change in inventory step.
  • No DDL/DML in inventory step.
  • No final serving from KB clean-render file as the official model.

8. Output expectation

Opus/Agent should produce a report that answers:

  1. Which current /knowledge/laws file/page must be wired?
  2. Which existing /docs or document reader component can be reused?
  3. Does DocsTreeView / buildDocsTree exist in repo? Exact paths and props?
  4. Can Directus API read tac_publication → tac_publication_member → tac_logical_unit → tac_unit_version with ordering?
  5. What is the minimum route/layout adjustment to show official TAC publications in /knowledge/laws?
  6. Is PG VIEW needed or not?
  7. What is the exact smallest next implementation prompt?

STOP after report. No implementation dispatch from inventory alone.