10 — Technical Addendum SCAFFOLD: Directus / API / Render Ownership

SCAFFOLD only. No route/endpoint/UI/Directus code. Frames future T8.

Purpose

Frame the future design of who owns governance render / display / API (Đ28) and how governance reads are exposed — without touching any route, endpoint, or Directus config.

Controlling inputs

• Concept canon doc 02 (Điều 37 hub; render references; C-5 render-owner).
• Round-4 doc 02 (C-5: GOV-MOUT activation vs COUNCIL delegation; Đ28 agency-orphaned today).
• Registries-Pivot patched doc 10 (UI contract / OS-Agency render-shell, Đ28) — TECHNICAL_REFERENCE for the render-shell pattern.
• This package doc 03 §3.2 (C-5); doc 04 (T8).

Current blocker status

OPEN (C-5). Đ28 (display/API/render) is agency-orphaned — no active agency owns it; GOV-MOUT is draft with 0 edges. Recommended default = COUNCIL delegation now (TTL), GOV-MOUT activation as end-state. No surface change until designed and C-5 ruled.

Exact scope of the future design (T8)

• Design the render/display ownership binding under Đ28 (delegation-now/TTL per C-5 default), with GOV-MOUT activation as the documented end-state.
• Design the API / Directus surface contract for governance reads — reuse existing Nitro/Directus patterns (the Registries-Pivot ship proved Directus cannot serve PK-less views; Nitro endpoints query read-only). Carry that constraint forward.
• Design no-hardcode acceptance for the render layer (source-model-aware counts; no hardcoded category codes — the prior surface had CAT-017 etc. hardcodes to avoid repeating).

Dependencies

• Needs C-5 framed. Consumes coverage/event outputs (T6/T7) for what to render. Overlaps T9 (Registries-Pivot is one render surface).

Known constraints

• Đ28 is the render hub; do not create a second render owner (no island).
• Directus cannot serve PK-less views → read-only Nitro pattern (reuse, documented in Registries-Pivot ship).
• No-hardcode in the render/count layer (prior violations are the cautionary reference).

Forbidden implementation shortcuts

• ❌ Any route/endpoint/UI/Directus change; ❌ activating GOV-MOUT live; ❌ new endpoints.
• ❌ Hardcoded counts/category codes; ❌ source-model-blind gap math.

Acceptance criteria for the future detailed design

Render/API ownership designed against Đ28 + C-5 default; reuse of the read-only Nitro/Directus pattern; no-hardcode acceptance designed; no surface change; no-island attestation.

Where future detailed docs must be added

This package (e.g. 10a-render-api-ownership-design.md). Pointer added here.

What old docs must NOT be used as controlling input

• Registries-Pivot ship reports as a governance render mandate (reference for the pattern only).
• Pre-Round-4 Đ28 wording where it conflicts (and note L-1 drift).