Branch F — Proposal / Kaizen Flow

How a user turns a structural idea into a governed design change without ever directly mutating a workflow. Carried from Cowork-locked PHU-LUC-C (proposal flow) + Phase 1 doc 07 governance spine. No new law, no new tables — reuses workflow_change_requests + approval_requests/apr_approvals.

---

1. Principle: capture context, minimize input

The user's only job is to express intent ("add this", "change this", "remove this") and a reason. The system auto-captures the exact context — node, tier, workflow, step, neighbors — so the proposer types as little as possible. This is the Kaizen loop: anyone can propose, the structure stays governed.

2. Flow

user clicks "Đề xuất cải tiến"  (enters Proposal Mode — does NOT mutate anything)
   │  chooses one of: add / edit / delete / reorder  (+ future: comment / audio)
   ▼
system auto-captures context: {workflow_id, target_node_id, target_tier, neighbors{before,after}, current_value, iu_ref}
   │  user adds: intent + reason (minimal free text)
   ▼
dot_mow_design_propose_change  →  INSERT workflow_change_requests (status=draft, dsl_diff before/after)
   │  inline confirm "✓ Đã gửi"  ·  proposal_count++ on the card  ·  notify approver
   ▼
[dot_test_gate]  dot_mow_design_validate GREEN  +  Điều-35 paired DOT test passes
   ▼
[review]  approver reads dsl_diff + validation + schema_warnings + impact ("Ảnh hưởng N task cấp dưới")
   │  apr_approvals: ≥2 distinct human approvers (approver_type='human', decision='approve')
   ▼
[activation]  dot_mow_design_activate (GOV-COUNCIL only) → bumps active_design_version, audit row
   ▼
[active]  ── rollback path: dot_mow_design_rollback (forward-only version-pin, council)
[rejected] remains in workflow_change_requests, fully auditable (never deleted)

3. Proposal Mode interactions (from PHU-LUC-A/PHU-LUC-C, verbatim)

Trigger	Control	Captures
Toggle proposal mode	top-right "Đề xuất cải tiến" button (.btn-k.on, yellow)	enters mode; no mutation
Edit a step	yellow pill half (.dy #ef9f27, tooltip "Sửa bước") on the card	change_type=edit; form: Tên bước mới (hiện: {current}), Lý do sửa
Delete a step	red pill half (.dr #e24b4a, tooltip "Xóa bước")	change_type=delete; form: Lý do xóa bước {n} + warn-box "Ảnh hưởng {N} task cấp dưới — cần phê duyệt cấp trên."
Add a step	green "+" (.btn-plus #639922, tooltip "Thêm bước") in the gap between cards / "+ Thêm nhiệm vụ" at list end	change_type=add; form: Tên bước, Người phụ trách, Lý do thêm + auto context boxes Trước/Sau
Reorder	(not built in prototype) drag handle	change_type=reorder; captures {order_index} — design gap, see doc 07
Comment / audio	(not in any prototype)	mission-requested; design gap — capture as proposal with change_type=comment + optional audio IU attachment

Every form shows the queue note verbatim: "Đề xuất vào hàng đợi phê duyệt — thông báo gửi quản lý liên quan." Footer: "Hủy" + "Gửi đề xuất" (button bg = mode color: add #639922, edit #BA7517, delete #A32D2D). Submit → inline "✓ Đã gửi" → auto-close.

4. Context the system captures automatically (no user typing)

• workflow_id, target_node_id, target_tier
• neighbors: the step before and after (shown as Trước/Sau context boxes; "(đầu)"/"(cuối)" at boundaries)
• current_value (for edit/delete)
• iu_ref of the node (so the proposal references canonical content, not a copied string)
• author (user or agent), as_of timestamp
• impact preview: count of child tasks affected (drives the delete warn-box)

5. Approver experience (Governance Cockpit — Surface 4)

• Proposal lands in the cockpit problem queue with: entity, change_type, author, age, dsl_diff, validation result, schema_warnings, impact count.
• Approver reads the diff (current vs proposed) via fn_workflow_change_diff.
• Approval requires ≥2 distinct human cross-signs (apr_approvals); the agent may propose but is forbidden to approve (automated-agent CHECK + council-owned activation).
• Accepted → dot_mow_design_activate applies it as a design change (new active_design_version).
• Rejected → row stays status=rejected, fully auditable; nothing deleted.

6. Running-instance policy (stated now for Phase 2)

Phase 1 has no runtime. When runtime exists: activating a new design version never retroactively alters in-flight instances — they complete on their pinned version; new instances use active_design_version (rollback = version-pin, Điều 30, forward-only). Freeze blocks new instance creation against that design.

7. Proposal / Kaizen flow verdict

Defined. User clicks "Đề xuất thay đổi" → picks add/edit/delete/reorder(+comment/audio) → system auto-captures node/tier/workflow/step/neighbor context → proposal enters workflow_change_requests queue → approver reviews diff+impact → ≥2 human cross-signs → accepted becomes a design change via activate → rejected stays auditable. Minimal input, full context, proposal-only, no self-approval, no new law. Reorder and comment/audio capture flagged as design gaps for Claude Design.