08 — UI Architecture Audit

Score: UI architecture readiness = 55/100 (design) · source = UNVERIFIED_SOURCE_ACCESS.

Source access status

The live Nuxt source (/opt/incomex/docker/nuxt-repo/web) is outside the read-file allowlist (/opt/incomex/docs, /opt/incomex/dot/specs, /var/log/nginx). I could not read the actual .vue/.ts files. UI is audited from the package handoff docs (readable under knowledge/.../*/06-ui-route-package-v2.md and the v1 package), plus the PG contract the UI binds to. Treat all UI-internals statements as package-doc-level, not source-verified.

What the package docs assert (primary evidence)

From 06-ui-route-package-v2.md (read live):

• v2 routes are "thin rpQuery() pass-throughs — no business math in Nuxt."
• Files: server/api/registries-pivot/grouping.get.ts (→ v_rp_pxt_grouping_surface, v_pxt_grouped_children), plus contract/substrate/proof pass-throughs.
• Package located at /opt/incomex/docs/mcp-writes/rp-dynamic-drill-grouping-2026-06-05/ui-package-v2/ — not deployed (divergent git ahead17/behind13, no push creds).
• The real PR (feat/process-axis-dashboard) is 2 files / +159 — a thin slice, not the full RP UI.

Audit findings (against the checklist)

Q1 — Any Nuxt math? → NO (per package docs)

Routes are pass-throughs; PG computes everything. This matches the no_direct_PG_from_Nuxt / "PG renders business logic" constitutional guardrail. Cannot source-verify, but the contract design (drill_action, grouping_status, routes all computed in PG) makes Nuxt math unnecessary by construction.

Q2 — Hardcoded axis list in UI? → RISK (indirect)

The UI shouldn't need one if it iterates the contract. But because the PG contract itself hardcodes the 5 axes (H1), the axis list is effectively hardcoded upstream of the UI. A new axis won't appear even with a generic UI. So "no hardcoded axis list in Nuxt" is true but moot — the hardcode is one layer down.

Q3 — Hardcoded level/depth? → UNVERIFIED — drill is recursive-by-contract (drill_action drives next step), so depth shouldn't be fixed; cannot confirm in source.

Q4 — Hardcoded route per axis? → YES, upstream

Routes are built in PG as '/registries-pivot/node/' || axis_code || '/' || node_code (mostly), but some branches hardcode the axis segment literally (H2). If the UI pages are file-routed per axis, that would be a second hardcode — UNVERIFIED in source.

Q5 — Generic fallback for unknown axis/node? → UNVERIFIED / likely missing

No evidence of a generic [axis]/[node] catch-all in package docs; routes are enumerated per known axis. A new axis would likely 404. Cannot confirm.

Q6 — Does UI show confidence / source_scope? → PARTIAL (data available, rendering unverified)

The contract exposes count_status (pivot_backed/ledger_backed/census_backed/assignment_backed/candidate/verified), governance_status, owner_blocker, warning_flags. The data to label exists. Whether the UI renders these as confidence/scope badges is UNVERIFIED.

Q7 — Does UI distinguish official/candidate/synthetic/partial/unknown/stale? → PARTIAL (data yes, render unknown)

• official/candidate: governance_status carries it. ✔ data
• synthetic: NOT distinguished — AX-BASE/AX-TRIGGER/AX-PXT carry no synthetic/derived flag (finding from doc 06). ✘
• partial/unknown: trigger 525 partial scope and KB-SOP unknown are not surfaced as labels in the contract. ✘
• stale: ledger-literal staleness (residual=8 vs live 2) is not flagged stale in the contract (only count_status='ledger_backed'). ✘

Q8 — Does UI show not-additive / partition-law warnings? → PARTIAL

warning_flags exists and prior work labeled non-partition parents ADVISORY_NO_PARTITION_LAW. But whether the UI renders an additivity warning is UNVERIFIED, and the synthetic-axis sums (e.g. AX-PXT total) are not additive with AX-PROCESS/AX-TRIGGER (overlap) — no cross-axis double-count warning was found.

UI verdict

The UI architecture intent is sound: PG-rendered, pass-through, label-data available. But: (1) it is not deployed; (2) source is unverifiable from this audit's read scope; (3) the PG contract it binds to is the hardcoded, dual-versioned, partially-stale v1 — so even a perfect generic UI would render hardcoded axes and stale AX-PXT counts; (4) the contract lacks synthetic/partial/stale flags the UI would need to label honestly. Recommend: do not deploy the UI as a "supervision surface" until the contract is unified (v1/v2), registry-driven, and carries synthetic/partial/stale labels.