Tư vấn chiến lược — Workflow Assembly vs Kestra

Ngày: 2026-03-22 Vai trò: Kiến trúc sư phản biện / chiến lược triển khai Trọng tâm: Human-in-the-loop workflow, UI lắp ráp, Assembly First, tổng thời gian triển khai thấp, code là giải pháp cuối cùng Tài liệu đã đọc qua Agent Data:

knowledge/dev/planning/workflow-module/M-002-phase2-unified-plan.md

knowledge/dev/planning/assembly-roadmap.md

knowledge/dev/ssot/prefect/architecture.md

knowledge/dev/ssot/data-connection-law.md

knowledge/dev/architecture/entity-lifecycle.md

Kết luận ngắn

Không nên lấy Kestra làm trung tâm cho giai đoạn hiện tại.

Chiến lược đúng với Hiến pháp và Assembly First là:

Giai đoạn 1: lấy M-002 làm SSOT workflow governance (Narrative → DSL → Step Matrix → BPMN view), dùng Directus/Nuxt/DOT để lắp ráp UI human-in-the-loop.
Giai đoạn 2: chỉ khi workflow definition, block library, step schema, checkpoint, và data contracts đã ổn định mới nối thêm execution adapter sang Prefect hoặc Kestra.
Kestra không phải nơi nên khai báo logic quy trình gốc ngay bây giờ. Nó chỉ nên là executor/adaptor ở lớp dưới, và còn đang bị hoãn bởi Data Connection Law + chiến lược MySQL First.

Căn cứ luật và SSOT hiện có

1. M-002 đã chốt SSOT của workflow là Narrative + DSL, không phải engine ngoài

M-002 Phase 2 chốt:
- Narrative = SSOT đầu tiên
- DSL = SSOT
- BPMN chỉ là view
- Tầng 1 execution là sau này: DSL → Adapter → Prefect/Kestra

=> Nghĩa là hệ thống đã quyết từ trước: workflow logic gốc nằm trong Incomex, không nằm trong Kestra.

2. Assembly Roadmap cấm nhảy vào custom builder nếu còn lắp ráp được

assembly-roadmap.md chốt: Directus native → module có sẵn → code mới
Cấm thích code thay vì lắp ráp.

=> Một workflow editor/runner custom lớn hoặc chuyển logic sang YAML/engine ngoài quá sớm đều đi ngược tinh thần này.

3. Prefect/Kestra đã được phân vai rõ

prefect/architecture.md chốt: Prefect = AI orchestration layer
Cùng tài liệu đó chốt: Kestra = Human-in-the-loop & Business Workflow Layer

=> Nhưng đây là phân vai khái niệm, không có nghĩa phải triển khai Kestra ngay.

4. Data Connection Law đang hoãn Kestra

data-connection-law.md ghi rõ: Kestra HOÃN theo MySQL First
Giai đoạn 1 ưu tiên Directus Flows; n8n/Google Workflows là công cụ dự phòng; Kestra chỉ là ngoại lệ nếu thật cần.

=> Về mặt luật, chọn Kestra làm đường chính ngay bây giờ là sai nhịp triển khai.

Trả lời trực tiếp câu hỏi chiến lược

I. Có nên tự thiết kế layout quản lý cho từng nhiệm vụ hay khai báo trên Kestra?

Phán quyết

Tự thiết kế lớp quản lý ở Incomex trước; không dùng Kestra làm nơi khai báo workflow gốc ở giai đoạn này.

Lý do

Workflow của anh không chỉ là execution. Nó bao gồm:
- Narrative để con người đọc
- Step order
- Human-in-the-loop
- trường nào nhập, trường nào chỉ đọc
- checkpoint/approval
- governance/WCR/task/comment
- UI theo vai trò
Kestra mạnh ở orchestration/execution, nhưng không phải là SSOT tốt cho toàn bộ lớp governance này.
Nếu đẩy logic gốc vào Kestra quá sớm, anh sẽ tạo 2 hệ song song:
- Directus/M-002 quản governance
- Kestra quản runtime logic
Rất dễ lệch nhau.
M-002 đã có kiến trúc đúng cho bài toán này:
- Narrative
- workflow_steps
- workflow_step_relations
- block_library
- WCR/task/AI Council review
- BPMN view only

=> Đây chính là nền để “quản lý đến nguyên tử, lắp ráp, rồi mới thực thi”.

II. Với giai đoạn 1 — thứ tự workflow + trường nhập liệu/tham khảo cho Human in the loop — nên làm thế nào?

Phán quyết

Làm ngay trong M-002 + Directus, không đưa sang Kestra.

Thiết kế đề xuất

Mỗi workflow_step nên có thêm contract dữ liệu cho UI:

input_field_refs[] — các field bắt buộc nhập ở bước này
reference_field_refs[] — các field chỉ đọc để tham khảo
output_field_refs[] — các field được phép sinh/cập nhật khi hoàn thành bước
checkpoint_set_id — bộ kiểm tra cần pass trước khi qua bước sau
ui_block_type — loại màn hình: form, review panel, checklist, approval card, compare view
actor_type — ai thao tác: user/agent/orchestrator/system
completion_rule — điều kiện nào được coi là xong

Vì sao hợp luật

Điều 0 / Entity Lifecycle: mọi thực thể sinh ra phải có quy trình, metadata, cập nhật cơ quan quản lý
M-002: workflow_steps là SSOT của trình tự
Assembly Roadmap: UI nên lắp từ DirectusTable, UTabs, UTimeline, form components

Lợi ích

Con người đọc được
AI đọc được
DOT tools apply được
về sau map xuống Prefect/Kestra được
không bị khóa vào syntax của 1 engine ngoài

III. Với giai đoạn 2 — tạo UI lắp ráp để tương tác — Kestra hay DOT lắp ráp tự động hiệu quả hơn?

Phán quyết

DOT lắp ráp tự động + Nuxt/Directus hiệu quả hơn và an toàn hơn cho hiện tại.

Lý do

Assembly First: UI đang có lộ trình rõ để dùng Nuxt UI + DirectusTable + UTabs + UTimeline + UPopover + forms có sẵn.
Kestra không phải UI framework của anh. Nó có UI vận hành workflow, nhưng không phải UI nghiệp vụ lắp ráp sâu theo từng bước nhập liệu/tham khảo của Incomex.
Anh cần UI theo nhiệm vụ, không chỉ UI theo pipeline run. Đây là 2 thứ khác nhau.
DOT tools hợp hơn để sinh cấu trúc lặp lại:
- tạo field/schema
- tạo page section
- tạo step panel
- tạo checkpoint bindings
- tạo task/comment hooks

Khuyến nghị cụ thể

Không làm “workflow builder drag-drop” riêng ở giai đoạn này. Hãy làm UI assembler bán cấu hình:

input: workflow_steps + ui_block_type + field refs + actor_type + checkpoints
output: trang detail có các tab/section lắp sẵn

Ví dụ:

bước loại human_checkpoint + ui_block_type=form_review → render trái: form input; phải: reference panel + checkpoint list
bước loại approval → render card approve/reject + evidence + previous history
bước loại agent_call → render read-only status + logs tóm tắt + retry button (nếu có quyền)

IV. Có nên dùng Kestra ở đâu không?

Có, nhưng ở lớp dưới và muộn hơn

Kestra chỉ nên dùng khi cả 4 thứ sau đã ổn định:

Workflow definition trong M-002 ổn định
Data contracts per step ổn định
Checkpoints/approval/human loop đã chạy ổn trong Directus/Nuxt
Hạ tầng Postgres cho Kestra sẵn sàng đúng luật

Vai trò đúng của Kestra sau này

chạy batch nhiều bước, nhiều hệ
scheduling
retries/timeouts
external integrations phức tạp
long-running business orchestration

Không nên dùng Kestra làm

nơi người dùng viết narrative gốc
nơi quản step governance/WCR
nơi định nghĩa màn hình nhập liệu nghiệp vụ
nơi làm SSOT của workflow semantics

V. Chiến lược triển khai ít code nhất, an toàn nhất

Pha A — Chốt data contracts trong Directus (không code lớn)

Thêm metadata cho workflow_steps:

input_field_refs
reference_field_refs
output_field_refs
ui_block_type
completion_rule
checkpoint_set_id
execution_adapter (none|directus_flow|prefect|kestra)
execution_mode (human|ai|system|hybrid)

Đây là bước có ROI cao nhất vì biến workflow thành thứ lắp ráp được.

Pha B — Dùng Nuxt UI + DirectusTable + sections để dựng màn hình nhiệm vụ

Không làm visual editor mới. Dùng:

UTabs cho Mô tả / Trình tự / Tiến trình / Đề xuất
DirectusTable cho step matrix
UTimeline hoặc UStepper cho tiến trình đang chạy
USlideover / UModal cho action step
form components của Nuxt UI cho nhập liệu

Pha C — DOT assemblers thay vì custom screens

Tạo DOT tools kiểu:

dot-workflow-step-bind-fields
dot-workflow-ui-assemble
dot-step-checkpoint-attach
dot-workflow-runtime-page-ensure

Nghĩa là UI không viết tay từng màn; UI được sinh từ metadata step + template blocks.

Pha D — Execution tối thiểu trước: Directus Flows / n8n / Prefect

Theo data-connection-law.md:

ưu tiên Directus Flows cho tự động hóa đơn giản
n8n / Workflows chỉ khi Flow không đủ
Kestra hoãn

Theo prefect/architecture.md:

Prefect đã có chỗ đứng rõ cho AI orchestration

=> Nên đi theo thứ tự:

Human steps + data capture trong Directus/Nuxt
Auto bước đơn giản bằng Directus Flows
AI orchestration bằng Prefect khi cần macro lifecycle
Kestra chỉ thêm khi có case business workflow dài hơi mà 3 lớp trên không đủ

VI. Kiến trúc mục tiêu đề xuất

Narrative (workflows.narrative)
  ↓ AI draft / review / approve
Workflow DSL (workflow_steps + relations) = SSOT
  ↓
Step data contracts (input/reference/output/checkpoints/ui_block_type)
  ↓
DOT assembler
  ↓
Nuxt UI runtime pages (DirectusTable + Timeline + Forms)
  ↓
Execution adapter per step:
  - human only
  - Directus Flow
  - Prefect
  - Kestra (sau này, ngoại lệ có kiểm soát)

VII. Rủi ro nếu chọn Kestra sớm

1. Sai luật nhịp triển khai

Data Connection Law đang hoãn Kestra. Dùng sớm sẽ tạo ngoại lệ lớn.

2. Tăng hạ tầng ngay lập tức

Kestra kéo theo Postgres, ops, monitoring, auth, backup, migration.

3. Lệch SSOT

Workflow semantics ở M-002, nhưng execution semantics lại trôi sang Kestra YAML.

4. Human-in-the-loop không thuận

Anh sẽ vẫn phải tự làm UI nhập liệu/nghiệp vụ ở ngoài Kestra.

=> Cuối cùng vừa có Kestra, vừa vẫn phải viết UI riêng. Tăng chi phí, không giảm.

VIII. Câu trả lời ngắn cho 2 giai đoạn của anh

Giai đoạn 1

Dùng M-002/Directus làm lõi.

quản thứ tự bước
bind field nhập liệu/tham khảo
checkpoint/human approval
WCR/governance

Giai đoạn 2

Dùng DOT + Nuxt UI để lắp ráp UI runtime.

không làm custom builder lớn
không lấy Kestra làm nơi sinh UI
UI phải đọc từ step contracts và assemble

Khi nào mới đụng Kestra?

Chỉ sau khi cần orchestration nhiều hệ, long-running, retry/schedule phức tạp và đã ổn định DSL + data contracts.

Phán quyết cuối

Chiến lược tối ưu thời gian triển khai, khả thi và an toàn là:

Không lấy Kestra làm đầu bài bây giờ
Lấy M-002 + Directus + DOT assembly làm trục chính
Dùng Directus Flows/Prefect trước, Kestra sau
Code mới chỉ tập trung vào assembler và adapter mỏng, không làm workflow engine/UI engine từ đầu

Nói thẳng: với kiến trúc hiện tại của Incomex, chọn Kestra sớm là nhanh trước mắt nhưng chậm toàn cục. Chọn M-002 + assembly metadata-first là chậm hơn 1 nhịp đầu nhưng đúng nền móng, ít rủi ro và scale tốt hơn.