Incomex AI Portal
KB-2C62

GPT Review S191 — P10D Nuxt Laws Page Design Brief v0.1

8 min read Revision 1
s191p10dnuxtlaws-pagedesign-briefgpt-reviewapproved-with-patches

GPT Review S191 — P10D Nuxt Laws Page Design Brief v0.1

Date: 2026-04-30
Phase: TAC MVP / P10D
Verdict: APPROVED AS DESIGN DIRECTION, WITH PATCHES BEFORE IMPLEMENTATION PROMPT

1. Law / constitution check

Checked against recent governing decisions and constraints:

  • knowledge/dev/reports/gpt-decision-s190-p10b-complete-s188-closeout-direction-2026-04-30.md
  • knowledge/dev/reports/s187-roadmap-note-nuxt-laws-page-tree-view-after-p10a2c-2026-04-29.md
  • Red Zone constraints: no document-specific renderer case-dispatch, no manual kb_documents mutation, no business logic in Nuxt where it belongs to backend/PG/domain service, no hidden hardcode.
  • VPS/KB SSOT principles from P10B: PG/VPS runtime is authoritative for TAC data; KB stores reports/artifacts; /tmp is not SSOT.

No blocking constitutional conflict was found in the design brief because it is design-only and read-only.

However, implementation must avoid three risks: hidden D28-specific rendering, Directus role assumptions, and frontend business logic creep.

2. Overall assessment

The brief is directionally correct:

  • Reuses /knowledge/laws.
  • Introduces a reader route with left tree + right reader.
  • Keeps clean reader mode default.
  • Adds admin/reviewer boundary overlay.
  • Keeps debug mode deferred.
  • Separates stable UUID, canonical address, and human-facing label.
  • Correctly defers auto-numbering.
  • Requires generic renderer and forbids doc_code branching.
  • Keeps P10D v0.1 read-only.

This is the right next step after P10B.

3. Required patches before implementation prompt

Patch 1 — Bridge decision: do not add pub_id field yet without schema/change gate

OD-P10D-01 proposes adding pub_id to governance_docs. That is a schema/config/data change outside a pure design note.

For implementation planning, use a read-only bridge first:

  • Preferred v0.1 bridge: list directly from tac_publication for TAC-backed reader, while keeping old governance_docs listing untouched or linking separately.
  • If the existing /knowledge/laws listing must show both legacy docs and TAC publications, create a server-side adapter response that combines sources read-only.
  • Adding a pub_id field to governance_docs requires a separate schema/data-change prompt/gate.

Decision: Do not authorize adding pub_id to governance_docs in P10D v0.1 implementation unless a separate change gate is approved.

Patch 2 — Move PG/query/business rules to server layer, not client renderer

The brief says Nuxt server route uses PG pool, good. Strengthen:

  • Client receives presentation-ready ordered units from server route.
  • Recursive CTE, lifecycle filters, visibility rules, auth/permission checks, and role-gated metadata exposure live in server route/service.
  • Client does tree build/render/sync only.

This avoids business logic creeping into Nuxt client.

Patch 3 — Visibility and lifecycle filter must be explicit

Current design lists publications but does not define visibility policy.

For v0.1 use explicit policy:

  • Public reader may expose only selected publication states approved for reading. Current P10B rows are proposed, so public exposure should be decided deliberately.
  • Safer default for MVP internal route: require authenticated admin/reviewer for TAC reader until User decides publication policy.
  • If public read is chosen, make it a deliberate GPT/User decision and document why proposed TAC publications are safe to expose.

Recommendation: internal authenticated reader first; public read deferred until production content policy is set.

This patches OD-P10D-03.

Patch 4 — Markdown renderer decision: choose safe rendering path, not marked by default

OD-P10D-02 recommends marked. That is acceptable only if sanitization is explicit and tested.

Patch recommendation:

  • Prefer Nuxt/MDC if already installed and compatible with server/client rendering.
  • If using marked, must pair with DOMPurify or equivalent sanitization and disable raw HTML unless explicitly needed.
  • Add test cases for code fences, tables, blockquotes, raw HTML attempts, and pipe characters.

No renderer library should be chosen without security verification.

Patch 5 — Replace D28-specific render-rule example with generic capability requirement

Section 9 / follow-up evidence notes D28 had a D28-specific rule around S1-P1. The design brief must not carry this into implementation as a rule.

Patch wording:

P10D production renderer must not encode D38-DIEU28-S1-P1 or any canonical-address-specific exception. If some unit titles are metadata-only, this must be represented by data/model metadata in TAC schema or publication membership/render profile, not by hardcoded UI logic. For v0.1, render title and body as stored; any hidden-label behavior is deferred until modeled generically.

This is important to avoid hardcode regression.

Patch 6 — Recursive CTE should include membership scoping in recursion

The sample query is mostly good. Ensure recursive step always joins tac_publication_member by both child LU and the same publication id, and uses the exact unit_version_id from membership.

Required invariant:

The tree endpoint must only return units that are members of the requested publication and must use pm.unit_version_id, not latest UV by logical_unit_id.

This prevents accidentally rendering non-member or wrong-version units.

Patch 7 — PASS criteria should include “no case-dispatch audit”

Add verify item:

  • grep/audit for no doc_code ===, no DIEU-28, DIEU-32, DIEU-35 in renderer logic except test fixtures/seed docs;
  • no canonical-address-specific exception in production renderer.

4. Answers to Open Decisions

OD-P10D-01 — Bridge governance_docs ↔ tac_publications

Answer: Do not add pub_id field yet. For v0.1, use tac_publication as the source for TAC reader. Keep governance_docs listing intact or use a read-only server adapter. Any schema/data bridge requires a separate gate.

OD-P10D-02 — Markdown renderer

Answer: Choose the safest already-supported path after repo inspection. MDC if already available and fits; otherwise marked only with sanitization and raw HTML disabled/sanitized. Do not decide purely from preference.

OD-P10D-03 — Public vs restricted API

Answer: Internal authenticated first for P10D MVP. Public read is a product/policy decision because current TAC publications are proposed and UVs are draft/unreviewed.

OD-P10D-04 — Implement timing

Answer: S189 design approval + implementation prompt preparation. S190 or next explicit execution step for implementation. Do not sneak implementation into closeout/design review.

5. Direction to Opus

Opus should patch the P10D brief to v0.2 with the above decisions, then create a concise implementation-planning prompt only if User wants to proceed.

Do not dispatch code implementation yet.

v0.2 should be a design artifact in KB, not code mutation.

6. Boundary

No DDL/DML, no Directus schema changes, no Nuxt code changes, and no production route implementation are authorized by this review.