Branch J — Risk Review

Risks in the UI handoff and the mitigations baked into the contracts. Severity: 🔴 high · 🟡 medium · 🟢 low-with-control.

---

#	Risk	Sev	Mitigation (where enforced)
1	Cognitive load — six tiers + proposal mode + governance could overwhelm a non-technical operator	🟡	One frame, identical grammar at every tier (doc 01); T3 default; operators land on the Task Card (Surface 2) with 4-level progressive disclosure (L1 = name+countdown+badge+one action), not the full canvas
2	10k+ scale — client-side scans / OFFSET pagination would collapse at fleet size	🔴	Keyset pagination, server sort/filter, pre-aggregated counts, <VirtualGrid>, hard page cap + refine guard, pre-agg fix for v_mow_design_workflow correlated subqueries (doc 04/08); heatmaps for fleet rollup
3	Permission leakage — UI showing rows/actions a role shouldn't see	🔴	Backend-only visibility: view + Directus policy + per-tier Điều-37 predicate (super-admin included); action chips rendered only from server permission_actions; no client permission logic (doc 08 §5)
4	Hardcoding risk — workflow/task/tier names or rules baked into Nuxt	🟡	Điều-28 render-shell rule; all config from registry; do-not-hardcode constraint in both briefs; test: removing backend leaves zero stranded logic (doc 08 §8)
5	DOT-action failure handling — a failed/absent DOT crashing the UI or silently dropping a mutation	🟡	DOT-existence guard (render disabled+explained, never crash); error banner+retry; no optimistic governance updates; stale-data re-fetch on completion (doc 08 §4/§6)
6	UI vs runtime confusion — users thinking the canvas runs workflows	🟡	Explicit design-vs-runtime boundary (doc 01 #4, Phase 1 doc 08): Phase 1 = blueprint only; no instance creation/event/job from UI; instance mode is a clearly-separate view_mode
7	Proposal-flow complexity — too many fields deters Kaizen participation	🟡	Minimal input + auto context capture (doc 06): user types only intent+reason; system captures node/tier/workflow/step/neighbors; queue note sets expectation
8	Self-approval / governance bypass — agent or proposer approving its own change	🔴	Proposal-only editing; ≥2 human cross-signs; automated-agent CHECK rejects agent apr_approvals; activation council-owned (doc 06/08); backend rejects, UI shows read-only
9	Mobile constraints — premature responsive work derailing desktop-first	🟢	Constraint: no mobile before desktop complete; Task Card (operator surface) designed to collapse to L1 single-column later
10	Accessibility — color-only status illegible to color-blind/low-vision users	🟡	Color+icon+text triplet always; distinct shapes (✕/✓/⚠); WCAG AA; high_contrast token pairs; keyboard nav + aria (doc 02/07)
11	Tier-table absence — T6–T4 tbl_* not yet born → broken nav	🟡	Build T6–T4 against mock/config behind the same DOT interface; switch to tbl_* when ratified; live-PG reuse-first survey is the first engineering task (doc 08 §3)
12	Theme ambiguity — brief says dark, prototypes are light	🟢	Explicit decision deferred to Claude Design with token-pair recipe (doc 07 §6); brand accent + status colors locked in both themes
13	Design gaps (reorder, comment/audio) — referenced but never prototyped	🟢	Flagged as explicit design tasks in doc 06/07; not silently assumed
14	Stale data in governance — approver acting on out-of-date proposal state	🟡	as_of + per-row last_updated_at; optimistic updates forbidden for governance; re-fetch on action (doc 03/08)
15	Two traffic-light scales confusing implementers — 4-state nav vs 9+2 instance	🟢	Explicit reconciliation: 4-state = subtree health rollup, 9+2 = single-run state, mapped onto 6-color chip set (doc 03/07)

---

Residual / watch items

• Scale fix is a prerequisite, not optional: the correlated-subquery v_mow_design_workflow must be pre-aggregated before any thousands-row exposure (🔴 if skipped).
• Reuse-first survey blocks live wiring: the v1 pack's one open item (P2) must close before Stage 3.
• DOT registration is the real Phase-2 gate: canvas read DOTs are DOT_SPEC_ONLY today; nothing live until they exist with paired tests.

Risk review verdict

Complete. All nine campaign-listed risk areas (cognitive load, 10k scale, permission leakage, hardcoding, DOT-failure, UI-vs-runtime, proposal complexity, mobile, accessibility) plus six implementation risks are enumerated with severity and a contract-anchored mitigation. The three 🔴 risks (scale, permission leakage, self-approval) are each closed by backend enforcement, not UI promises.