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
- 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). - 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.
- 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. - 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).
- 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). - 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.
- 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 intoinformation_unit), never long inline text. Cards may render an IU body viarender_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_outboxis 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.