KB-EB5E

Branch A — Canonical UI Intent

5 min read Revision 1
mowui-handoffui-intentunified-canvasone-frame-six-tiersdieu-282026-05-29

Branch A — Canonical UI Intent

The single governing idea, carried verbatim from the Cowork locked prototype PHU-LUC-A and the v1 handoff pack:

"MỘT khuôn, SÁU tầng. Dữ liệu thay đổi khi đổi tầng, khuôn không thay đổi." (One frame, six tiers. The data changes when you change tier; the frame does not.)


1. The seven intent statements

  1. One unified canvas for T6→T1. A single component <MowHierarchyCanvas tier currentNodeId /> renders every tier. There is no per-tier component; tier-specific code branches are forbidden (Master Design Rev2 §6.6 / MP-D12).
  2. Same visual primitive across all tiers. Tabs, breadcrumb, card grid, traffic-light, action chips are identical at every tier. The only thing that changes between T6 and T1 is the data fed to the same cards.
  3. Tier changes change data, not component architecture. Switching tier re-queries the backend (dot_mow_canvas_get_nodes(tier, parent)); it never swaps layouts or mounts a different screen.
  4. MOW Design Registry is the blueprint/design surface, not runtime execution. The canvas shows what a process is designed to be (definition, bindings, health), not a live execution engine. Runtime/instance rendering is a Phase-2 mode of the same frame (see doc 04 instance-data; doc 08 Code handoff).
  5. User proposes changes; the user does not directly mutate the workflow. Every add/edit/delete/reorder is a proposal ("Đề xuất cải tiến") landing in workflow_change_requests (status=draft). There is no "Sửa trực tiếp" (direct edit) button — this is a hard constraint (v1 Component 6).
  6. Nuxt is a render shell only (Điều 28). Zero business logic, zero hardcoded workflow/task/tier data, no client-side full scans, no raw SQL. The shell requests a page and renders the server-provided rows + the server-provided per-row capability list.
  7. Backend enforces visibility and action permissions. Every list is a DB view + Directus permission policy + per-tier Điều-37 predicate; the UI cannot enumerate or act beyond its policy. Action buttons are rendered from a server-provided capability list per row, never hardcoded in the front end.

2. What the canvas IS for

  • Read structure by tier — understand the org/process hierarchy and the workflow blueprint.
  • Drill down T6→T1 — domain → company → department → specialty → workflow → task → (T0 form fields).
  • Answer the Control-Tower questions (user requirement, verbatim): "có bao nhiêu quy trình? Tự động đến đâu? Lỗi ở đâu?" — how many processes, how automated, where the errors are.
  • Propose improvements (Kaizen) via Proposal Mode.
  • View traffic-light status at a glance, rolled up by tier.

3. What the canvas is NOT (anti-scope)

  • NOT a DB editor — the screen exists to understand a process, not to edit the database.
  • NOT a workflow modeler — graph editing lives in Proposal Mode (diff against workflow_change_requests), not free-form canvas mutation.
  • NOT the super-admin cockpit — the Governance Cockpit is a separate surface (doc 04 Surface 4).
  • NOT a personal task list — the Personal JFT Dashboard / MOT Task Card is a separate surface (doc 04 Surface 3).
  • NOT a place for business logic — no rules, calculations, or workflow semantics in the front end.

4. Personas

Persona Need Default tier / surface
Vận hành (operator, non-technical) See my tasks, do them, flag problems MOT/JFT Task surface; canvas read-only
Manager See department/specialty health, propose improvements Canvas T4–T2, Proposal Mode
System designer (MOWD) Design/bind/validate/activate workflows Design Registry List/Detail, Governance Cockpit
AI / Agent Navigate, read, propose (never approve) Same surfaces, read + propose capability only

5. Invariant principles (do / don't) — from user requirements FINAL

  • IU centrality: workflow/step narrative & guidance are iu_ref (uuid into information_unit), never long inline text. Cards may render an IU body via render_iu_body (MP-D6).
  • Reuse-first: map existing PG before creating tables; no parallel hierarchy SoT (tiers map to existing tbl_* classification tables + workflows).
  • No hardcode: all config comes from registry (tier_registry, design_templates, view rows).
  • Nuxt = shell, zero business logic (Điều 28).
  • Vector guarded: no default vector write, no realtime vector in Phase 1 (vector_sync_enabled=false, never_flip).
  • Lark = external communication adapter only; PG event_outbox is the canonical event SoT.

6. UI intent verdict

Locked. The one-frame-six-tier philosophy, the proposal-only editing rule, the render-shell/backend-enforcement split, and the four-surface separation are all carried verbatim from the Cowork-locked prototypes and the user's FINAL requirements. No statement here is new invention; this doc is the single reference all later docs cite.

Back to Knowledge Hub knowledge/dev/reports/architecture/mow-unified-canvas-master-ui-handoff-pack-2026-05-29/01-canonical-ui-intent.md