M-002 Workflow Governance Engine v3 — Owner Draft
M-002 — Workflow Governance Engine v3 (Owner Draft)
Tình trạng: Draft thay thế tạm thời khi Claude server down
Soạn bởi: Incomex Hội đồng AI (thay mặt Owner)
Mục tiêu: Thiết kế sát thực tế vận hành AI-scale orchestration trước khi chốt kiến trúc chính thức
I. TẦM NHÌN MỚI (KHÔNG CÒN LÀ WORKFLOW BUILDER)
M-002 không phải công cụ vẽ sơ đồ.
M-002 là:
HỆ ĐIỀU HÀNH QUY TRÌNH CHO AI COUNCIL
Workflow phải:
- Tạo nhanh hơn viết code
- Có thể lên đến hàng trăm bước
- Điều phối AI như robot vật lý
- Có loop, trigger, retry, timeout, spawn session
- Có thể mở rộng lên hàng ngàn flow mà không hỗn loạn
II. PHÂN LOẠI WORKFLOW
1. Human-scale workflow
- 5–10 bước
- Có Human in the loop
- Đơn giản
2. AI-scale workflow (trọng tâm)
- Hàng chục đến hàng trăm bước
- Tự động hoàn toàn
- Event-driven
- State machine
- Prefect orchestration
- Agent dispatch
- Session management
=> Thiết kế phải phục vụ loại 2.
III. META-WORKFLOW: QUY TRÌNH TẠO WORKFLOW
Đây là phần quan trọng nhất.
Bước 1 — Raw Input
User cung cấp:
- Tài liệu
- Mục tiêu
- Dữ liệu
- Vấn đề
Không ép cấu trúc.
Bước 2 — AI Structuring
AI thực hiện:
- Chuẩn hóa yêu cầu
- Soạn mô tả workflow
- Sinh Matrix view
- Sinh BPMN view (viewer-only)
- Đề xuất schema mới (nếu cần)
CHƯA APPLY.
Bước 3 — Schema Integrity Scan (BẮT BUỘC)
Trước khi Admin phê duyệt, phải chạy:
- Double schema detection
- Similar field detection (semantic)
- Orphan endpoint detection
- Data flow validation
- Logic completeness check
Nguyên tắc:
- Directus = 100% DOT
- UI = view only
- Không tạo field trực tiếp qua UI
Nếu phát hiện schema tương tự:
- Liệt kê danh sách
- Hiển thị mô tả cơ bản
- Admin kiểm tra bằng mắt
- AI chỉ hỗ trợ phân tích
Bước 4 — Governance Approval
Admin:
- Xem proposal
- Xem cảnh báo schema
- Xem diff logic
- Phê duyệt hoặc yêu cầu chỉnh
AI chỉ advisory. Admin quyết định cuối.
Bước 5 — Apply & Version Lock
Sau khi approve:
- Tạo snapshot DSL mới
- Gắn version immutable
- Lưu parent_version_id
- Lưu hash integrity
- Regenerate BPMN view
Nếu sửa: Quay lại Bước 1 (loop governance)
IV. WORKFLOW DSL — ĐỊNH HƯỚNG V1
DSL không chỉ step 1-2-3.
Phải hỗ trợ tối thiểu:
Node types:
- action
- agent_call
- condition
- wait_for_event
- timeout
- loop
- parallel
- human_checkpoint
- external_trigger
- spawn_session
Tuy nhiên:
V1 có thể giới hạn:
- sequential
- exclusive condition
- parallel basic
- agent_call
- human_checkpoint
Không hỗ trợ subprocess phức tạp ở v1.
V. BLOCK LIBRARY (THAY VÌ CHỈ STEP-LEVEL)
Để đạt mục tiêu “xây flow nhanh hơn viết code”, phải có block tái sử dụng.
Ví dụ:
- AI-review-block
- Code-review-loop
- Approval-with-retry
- Agent-dispatch-block
- Validation-block
Block = tập hợp node chuẩn hóa.
Owner không nên phải lắp từ primitive node mỗi lần.
VI. EXECUTION MODEL
Flow DSL độc lập với executor.
Prefect là macro orchestration layer.
Flow DSL -> Adapter -> Prefect flow.
Không để DSL phụ thuộc chặt vào Prefect.
VII. CHỐNG DOUBLE SCHEMA (ƯU TIÊN SỐ 1)
Mỗi khi đề xuất schema mới:
- So khớp tên (string similarity)
- So khớp semantic (embedding search nếu cần)
- So khớp usage context
- Liệt kê schema gần giống
Admin phải xác nhận:
- Reuse existing field
- Hay tạo field mới
Nguyên tắc: Schema explosion = rủi ro sống còn.
VIII. NGUYÊN TẮC LẮP RÁP FIRST
Ưu tiên:
- Directus native capability
- Module đã code sẵn
- Open source trưởng thành (BPMN, Prefect, v.v.)
- Code mới (cuối cùng)
Không code mới nếu chưa soi hết 1-3.
IX. MỤC TIÊU CUỐI
- Có thể tạo hàng ngàn workflow
- Không trùng schema
- Không logic mồ côi
- Không endpoint rơi vào hư không
- Governance rõ ràng
- Admin kiểm soát cuối cùng
- AI điều hành phần nặng
X. MỞ CÂU HỎI CHO PHIÊN KIẾN TRÚC CHÍNH THỨC
- Có nên tách Schema Governance khỏi Workflow Governance?
- DSL có nên hỗ trợ event-driven + state machine ngay từ v1?
- Block Library có phải thiết kế trước DSL chi tiết?
- Có cần Migration Engine cho running instance ở Phase 1?
Đây là bản sát thực tế theo tinh thần Owner. Chờ phiên kiến trúc chính thức để refine thành kế hoạch cuối cùng.