MODW — Mother of Detail Workflow / Work Detail Workbench

Đề bài (Requirement Brief) — Bản tổng hợp v2.1 minor-patched (đã rà soát Hiến pháp + toàn bộ Luật + IU + Event 5 tầng)

Trạng thái: DRAFT · APPROVE WITH REQUIRED PATCHES · ready for Council/User ratification before wireframe — tài liệu "vẽ bức tranh tổng thể"; định vị lại MODW = Work Detail Workbench. Các patch nền (§4A · §5.1.1 · §5A · §5B · §10A · §10B · §11A · §12A) đã đủ để đưa ra Council/User ratify trước wireframe. Đây KHÔNG phải Master Design, CHƯA implement, CHƯA sang wireframe (xem §12A — Pre-wireframe Gate · §13 — decision list · §15 — Council checklist). Path: knowledge/dev/ui/modw/requirement-brief.md (đặt cạnh knowledge/dev/ui/mow/) Ngày: 2026-06-11 · thay cho v1. · patch v2.1 (2026-06-12): reframe Work Detail Workbench + Object Model + Legacy Harvest Matrix + Điều 39 clause + Artifact Placement Matrix + Ownership Matrix + Dev Workflow Preset + Executor Adapter Boundary + Evidence Contract + Pre-wireframe Gate. Phạm vi lần này: chỉ thiết kế UI; phần kỹ thuật chỉ phác thảo để UI tính trước. UI không phức tạp — mục tiêu là giữ trọn ràng buộc cũ để không vẽ sai. Đã rà soát: Hiến pháp v4.6.3 (15 NT); Điều 20, 26, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 45; "Điều XX Application Process Law" (extraction plan, draft); toàn bộ tiến trình IU (compose/cut/split/merge/route/vector); Event 5 tầng Rev2; queue design pack 00–17; agent-api-registry; VPS runtime; Comment Module M-001.

0. Tóm tắt & định vị chuẩn

MODW = Work Detail Workbench (Bàn việc chi tiết / UI chi tiết) — KHÔNG chỉ là "workflow builder". MODW là lớp UI/Admin/Workbench để con người, AI qua API, AI thuê bao (không API) và agent CÙNG quản lý một chuỗi công việc đang sống, từ ý tưởng → đầu bài → thiết kế → prompt → thi công → báo cáo → evidence → cập nhật roadmap. Mỗi phiên MODW quản lý một Work Object / một correlation chain, gom về một chỗ toàn bộ artifact · trạng thái · handoff · queue signal · comment · prompt · report · evidence · change proposal của việc đó. UI mỗi bước việc là trung tâm chuyển giao (kế hoạch · prompt · báo cáo · comment · chỉ thị) cho phối hợp con người + AI qua API + AI qua gói thuê bao (không API) + agent.

MODW KHÔNG sở hữu engine. Nó chỉ hiển thị · cấu hình · đề xuất thay đổi · điều phối qua substrate đã có (queue/job → Điều 45 · ngữ pháp workflow → Điều 34 · approval → Điều 32 · DOT → Điều 35 · display → Điều 28 · IU/text-as-code → Điều 38/44 · knowledge graph → Điều 39). MODW là UI chi tiết liên kết sâu với MOW/MOT, tận dụng tối đa cái đã có và không làm lại — KHÔNG phải Mother thứ 5, KHÔNG đẻ engine/hệ mới chồng lấn.

Định vị kiến trúc (quan trọng — kết quả rà soát): Hệ thống đã có sẵn lớp kiến trúc 6 tầng và một luật khung đang dự thảo cho đúng địa hạt này:

T6 GOVERNANCE UI (Nuxt render shell)      ← MODW UI nằm ở đây (chỉ là khuôn hiển thị)
T5 API / ADMIN (Directus REST/GraphQL)
T4 ORCHESTRATION & EXECUTION (workers)    ← MODW điều phối ở đây (qua queue, KHÔNG tự chạy)
T3 QUEUE & EVENT CORE — Điều 45 ENACTED   ← MODW "lắp ráp quanh", KHÔNG định nghĩa lại
T2 4 MOTHERS APPLICATION (MOW/MOT/MOIT/MOUT) ← MODW là UI Admin của tầng này
T1 KNOWLEDGE BRICK — IU (Điều 38/44)      ← MODW neo vào, KHÔNG tái thiết kế
T0 POSTGRES BASE (Điều 33: 4-DB / 3-lớp)

⚠ MODW KHÔNG phải "Mother thứ 5" độc lập, cũng KHÔNG đẻ luật mới. Nó là UI Admin "design + orchestrate" của lớp T2, tuân Điều 45 cho queue/event và neo vào "Điều XX — Luật Hạ tầng Ứng dụng Quy trình & Công việc" (đang draft trong law-extraction-plan-application-process-workflow-task.md) cùng Điều 34 (Workflow Law, draft) làm ngữ pháp workflow nền. Đây là điểm sửa lớn nhất so với v1.

1. Bối cảnh & bài học lần trước

Cái đã có: MOW ("một khuôn, sáu tầng", T6→T1, Proposal/Kaizen, traffic light) · MOT (thẻ 4 vùng) · hạ tầng IU + Event 5 tầng + Điều 45 đã ban hành + agent-data (bộ não tri thức) + DOT (đường mutation) + Directus (API/Admin).

Khoảng trống: MOW chưa "đẻ" được workflow vì thiếu chi tiết thi công (bước, sub-bước, trigger, vòng lặp, hàng đợi, handoff). MODW lấp khoảng trống này. MOW/MOT = các bề mặt tổng quan/nhiệm vụ (đầu ra, vận hành); MODW = Work Detail Workbench — bề mặt chi tiết vừa thiết kế, vừa vận hành, vừa handoff quanh một Work Object / correlation chain, nơi gom toàn bộ kế hoạch · prompt · report · comment · evidence · queue signal · proposal và trạng thái thực thi để con người + AI + Agent cùng làm việc — vẫn phản ánh PG realtime.

Bài học super-session (sai kỹ thuật lần trước — đã xác nhận trong KB):

"Nhanh hơn không phải vì thêm collection, mà vì chuyển từ document-store/KB (RAG) pattern sang event/message-log pattern."

⟹ Nguyên tắc nền cho MODW: tách runtime store (PG-native, append-only, 1 turn = 1 row, truy cập trực tiếp — cho báo cáo/comment/prompt/handoff nóng) khỏi knowledge store (agent-data/Qdrant RAG — chỉ hấp thụ summary/quyết định/tri thức đã chưng cất). KHÔNG dùng KB/RAG cho hot path vận hành.

2. 15 Nguyên tắc nền tảng (Hiến pháp v4.6.3) — MODW phải tuân

Nguồn: knowledge/dev/laws/constitution.md. Hiến pháp hiện là 15 NT (v1 nhắc thiếu). Các NT in đậm là điểm MODW dễ vi phạm nhất.

Làm một lần dùng mãi (SSOT) · 2. Tự động 100% ("làm tay = thiết kế sai") · 3. DOT 100% (trừ 5 ngoại lệ Đ33) · 4. Sẵn sàng thay đổi (thay đổi = metadata/config) · 5. Tự phát hiện tự sửa · 6. 5 tầng đồng bộ — cấm code Nuxt (PG→Directus→Nuxt) · 7. Dual-trigger · 8. Assembly First (PG→Directus→nguồn mở→code cuối) · 9. Không chắc đúng = sai (DỪNG + verify) · 10. Quản lý bằng PG không bằng text · 11. Khai tối thiểu — thông tin tối đa · 12. DOT theo cặp (2 chiều) · 13. PG First · PG Native · PG Driven · 14. Thực thi được ngay (6 câu: data ở đâu / ai làm / khi nào / ngưỡng / kiểm bằng gì / sai xử lý sao) · 15. Thiết kế trước triển khai.

NT14 (6 câu) và NT15 (thiết kế trước) là hai bổ sung quan trọng cho mọi bước MODW sinh ra.

3. Bản đồ luật liên quan — ràng buộc cốt lõi cho MODW

Điều	Tên (trạng thái)	Ràng buộc cốt lõi MODW phải tuân
45 ⭐	Hàng đợi & Điều phối PG-native (BAN HÀNH)	MOT/MODW không phải executor; queue mang tín hiệu không mang dữ liệu; event ≠ job; 9-state machine; heartbeat + silent-gap = vi phạm; trigger-in/out đăng ký bảng route + idempotency + chống cycle
Điều XX	Luật Hạ tầng Ứng dụng Quy trình (extraction plan, draft)	MOW orchestrate-không-execute; Proposal mode là đường DUY NHẤT sửa workflow; one-UI-per-role; long-running resume-safe; correlation chain xuyên nesting; no-double-ownership
34	Workflow Law (DRAFT)	WF lắp từ thành phần chuẩn; sửa WF = WCR → duyệt → DOT apply (không sửa tay); step taxonomy BPMN; block library (~50–100 block → 10.000 WF); retire không delete (Amidan)
35	DOT Governance (v5.2 BAN HÀNH)	DOT theo cặp (B ghi → A kiểm); `fix_repair_dot` 6 bước + verify 3 tầng; trigger_type vocab `cron/event/on-deploy/on-demand/manual/one-off`; cấm POST partial row
32	Phê duyệt (v1.1 BAN HÀNH)	Approval = PG collections + trigger (không chat/email); quorum theo risk; cấm self-approve high-risk; "đề xuất phải đứng được một mình"
33	PostgreSQL (v2.1 BAN HÀNH)	Khai rõ DB nào / Lớp nào (Não-Kho-Cổng); DB `workflow` engine cố ý RỖNG; 5 ngoại lệ DOT E1-E5; pivot-ready canonical fields
28	Hiển thị (v2.0 BAN HÀNH)	UI MODW = template đăng ký trong PG (`design_templates`); Nuxt zero business logic, không query DB; khuôn qua checklist 8 bộ phận + test 5/5
31	Toàn vẹn hệ thống (v1.2 BAN HÀNH)	"Mọi lệch = lỗi"; phát hiện trước fix sau; watchdog liveness; issue dedupe + severity; kiểm bằng contract JSON không bằng code
30	Bảo vệ hồi quy (v1.2 BAN HÀNH)	UI chạm người dùng phải có Playwright E2E + `data-testid`; "no blind PASS — không artifact = FAIL"
20	Thiết kế trước triển khai (v1.2 BAN HÀNH)	MODW = Tier 2-3 → full design + review độc lập + rollback + smoke + User approve; Context Graph Gate (Đ43) đọc trước
38	SQL hoá văn bản / IU text-as-code (DRAFT v3.0)	Ranh giới DOT cứng (auto 100%) vs AI mềm (đề xuất-người duyệt); văn bản đã ban hành: sửa = bản mới version++
26	Pivot (v4.0 BAN HÀNH)	Dashboard giám sát đếm bằng `pivot_count()` + meta_catalog virtual row, không tự đếm ở Nuxt
37	Tổ chức quản trị (v3.3 BAN HÀNH)	SSOT nội dung — 1 domain max 1 primary; tham chiếu liên luật tường minh; "luật enacted + 0 DOT = báo đỏ"
29 / 36	Phân loại / Collection (enacted/draft)	Mọi collection MODW cần `governance_role` + `purpose` + `description` + species + birth trigger; thiếu = CRITICAL

4. Phân biệt MOW / MOT / MODW

	MOW	MOT	MODW
Vai trò	Bản đồ tổng quan 6 tầng	Thẻ một nhiệm vụ (4 vùng)	Workbench chi tiết của 1 Work Object / workflow run / correlation chain
Trả lời	"Có việc gì, trước/sau?"	"Việc này gồm gì?"	"Chạy THẬT thế nào, ai đang giữ việc, artifact nằm đâu, evidence là gì, vòng nào, nối tiếp qua queue/handoff nào?"
Sửa DB	Không (chỉ Proposal)	Không	Có — qua DOT (cặp) + Proposal/duyệt; không sửa tay trực tiếp
Thời điểm	Đọc cấu trúc	Làm 1 việc	Lập + điều phối cả quy trình

MODW làm sâu MOW/MOT, không thay. Click một Nhiệm vụ trong MOW → mở MODW. (Câu hỏi mở: MODW là "tầng zoom sâu của MOW" hay surface độc lập liên kết 2 chiều — §13.)

4A. MODW Object Model (lớp đối tượng MODW nhìn vào)

Ý chính: MODW không chỉ nhìn workflow, mà nhìn TOÀN BỘ công việc đang sống — một Work Object / correlation chain với 6 lớp đối tượng, mỗi lớp neo vào substrate đã có (KHÔNG dựng store mới).

Lớp đối tượng	Thực thể chính (tái dùng substrate)	MODW làm gì trên lớp này
Work Object (đơn vị việc)	`work_item` / `work_package` / `workflow_run` (+ `correlation_id`, `trace_id`, `parent_run_id`)	Mở 1 "con thuyền" gom toàn bộ tài sản của việc; giữ correlation chain xuyên nesting/vòng lặp
Work Design (thiết kế)	`workflow_def`, `step_def`, `block_def` (neo `iu_unit_id`)	Hiển thị/cấu hình định nghĩa; mọi sửa đi qua Proposal → DOT, không sửa tại chỗ
Work Runtime (thực thi)	`workflow_run`, `task_run`, `job_queue` (Điều 45)	Hiển thị 9-state · SLA · heartbeat/health; KHÔNG tự claim/lease/execute
Work Memory (trí nhớ nóng)	`task_comments` (M-001) · runtime message-log · reports (append-only)	"Phòng họp của máy": handoff/comment/report/prompt discussion; KHÔNG đẩy KB/RAG vào hot path
Work Knowledge (tri thức)	IU · summary · decision · reusable pattern (Điều 38/44)	Chỉ hấp thụ tri thức đã chưng cất/duyệt; tham chiếu FK, không nhân bản
Work Intelligence (suy luận)	Knowledge Graph / Điều 39	Context/dependency/provenance · gợi ý ưu tiên/scaffold · explainability — KHÔNG phải runtime engine

5. HẠ TẦNG KẾ THỪA — MODW "lắp ráp quanh", KHÔNG định nghĩa lại

5.1. Tầng tri thức IU (miếng thông tin) — Điều 38/44

Khái niệm cốt lõi MODW phải giữ (logical-unit vs version):

Logical text unit = danh tính, giữ canonical_address bất biến suốt đời ("địa chỉ nhà").
Unit version = nội dung tại một thời điểm, lifecycle riêng draft → enacted → superseded → retired. Enacted = bất biến; sửa = tạo version mới.
Published snapshot = tập version enacted hiện hành của một tài liệu.

3 trục (đã verify PASS) — dùng cho thống kê & điều hướng:

Trục A (Source/order): tái dựng văn bản gốc theo sort_order; phát hiện gap/trùng. (fn_iu_reconstruct_source, v_iu_source_outline)
Trục B (Domain/tags): nhóm ngữ nghĩa registry-backed (doc:, kind:, sectype:…); lọc/thống kê theo lĩnh vực. (v_iu_content_group)
Trục C (Tree/hierarchy): cây cha-con acyclic; drilldown subtree, đếm con. (fn_iu_subtree, iu_tree_path)
Bề mặt thống kê chuẩn: v_iu_metadata_envelope (gộp A+B+C) — MOUT/Governance UI dùng lại, không tự đếm.

Thao tác IU — đã PASS vs còn GAP: compose / add / remove / reorder / render / validate = PASS (membership chỉ lưu order+role, piece là FK, không copy body). split / merge = PASS có điều kiện (cần review_decision_id; merge từ chối auto-concatenate). SQL-link = read PASS, enable GAP. trigger-in/out = GAP (chưa đăng ký iu.* event type; delivery OFF). edit-draft/comment/apply = thiết kế, chưa execute.

Quy tắc IU bắt buộc cho MODW:

No-duplicate-text invariant (Pack 23 §15): mọi mô tả bước / SOP / prompt / template báo cáo tồn tại một lần dưới dạng IU; workflow/task/report trỏ FK iu_unit_id và render khi đọc. Sửa nội dung = tạo version mới, không sửa tại chỗ nơi neo. Chạy preflight checklist (TABLE/FUNCTION/COLUMN/GUARD/TRIGGER CHECK → STOP nếu đã tồn tại) trước mọi DDL.
Vector boundary rule (BINDING) + NVSZ: 1 vector = 1 chunk = nội dung đúng 1 IU, không straddle 2 IU; queue/staging payload signal-only, không chở body/vector/secret; PG thắng (vector chỉ là projection); sync async outbox (debounce, retry, dead-letter).
Hot/cold path: ghi PG + birth gate + integrity trước (hot); vector/KG/enrichment async sau (cold); cold fail không rollback IU.
Invariant không-miễn-trừ: reconstruction-integrity (gap_before_count=0) + vector-consistency — MODW không bao giờ được phá.

Đề xuất phân loại IU cho từng artifact MODW (cụ thể hoá "neo vào IU"):

Mô tả bước → IU unit_kind='workflow_step' (neo workflow_step_def.iu_unit_id).
Chỉ dẫn task / prompt vận hành → IU unit_kind='task_instruction'/rule (KHÔNG để prompt ở text rời trong code/config).
Template báo cáo → IU design_doc_section hoặc iu_piece_collection(kind='document').
Workflow như tài liệu đa bước → iu_piece_collection(kind='workflow'), membership order = thứ tự bước.

Ranh giới Runtime store vs IU (chốt lại bài học super-session):

Định nghĩa (design-time, tái dùng nhiều lần) → IU: prompt template, mô tả bước, SOP, report template.
Thực thi (một lần chạy) → runtime store, KHÔNG phải IU: workflows(run), tasks(run), output_jsonb, giá trị form đã nhập, log, correlation_id — chỉ giữ FK trỏ ngược về IU.
Chưng cất runtime → IU chỉ khi kết quả được duyệt thành tri thức tái dùng (qua fn_iu_create birth gate + change-set + APR Đ32). Trước đó: tham chiếu, không nhân bản.

No-go IU còn treo (tiền điều kiện council): MODW không tự gán IU owner (OP-B blocker), không thêm trục cứng (SB-3 deferred), không bật delivery/vector chưa duyệt; cơ chế review_decision_id (C-4) chưa ratify ⇒ split/merge gated OFF.

5.1.1. Artifact Placement Matrix (IU / runtime store / queue / vector-KG)

Ý chính: mọi text tái sử dụng = IU/version; mọi text phát sinh một lần = runtime message-log; chỉ sau khi duyệt/chưng cất mới nâng thành IU. Queue chỉ chở ref, không chở body/vector/secret (NVSZ).

Artifact	Nơi lưu chuẩn	Ghi chú ranh giới
Prompt template	IU (`task_instruction`/`rule`)	Tái dùng; version++ khi sửa, không sửa tại chỗ
Prompt instance đã gửi agent	Runtime store	Một lần chạy; trỏ FK về template IU
Báo cáo một lần chạy	Runtime store	Chỉ nâng thành IU nếu được duyệt/chưng cất (birth gate + APR Điều 32)
SOP / checklist	IU	Tri thức tái dùng nhiều lần
Step definition	IU / FK IU	`workflow_step_def.iu_unit_id`
Step runtime state	Runtime PG	9-state, append-only, ghi state về PG, cấm silent change
Evidence artifact	PG metadata + file/ref	Queue chỉ chở ref; không chở body/blob/vector
Decision đã ban hành	IU version / approval record	Bất biến; sửa = version mới

5.2. Hệ Event 5 tầng — Master Design Rev2 (lắp quanh Điều 45)

Ranh giới in đậm trong nguồn: "Điều 45 v1.0 owns queue/event-core/work_state_machine/executor boundary/heartbeat caller. This document only assembles around Điều 45 — never redefines."

L1 Producers: sinh sự kiện, không thực thi. Register-before-emit (event type phải có trong event_type_registry + JSON schema trước khi emit). "Producers only produce; workers only execute. Queue does not auto-run scripts." Payload deny-list: body_text, instruction_text, payload_blob, iu_body, vector, embedding, secret, token, password không bao giờ vào payload; size cap ~4 KB. W3C trace từ ngày 1: trace_id(32hex) + correlation_id + parent_span_id.
L2 Broker: 3 substrate tách rời, không chung row — event bus (pub/sub fanout) ≠ job queue (durable lease+retry+DLQ) ≠ realtime topic. Dispatch idempotent (subscription_id, event_outbox_id) UNIQUE. Queue carry refs only; "lease + worker ACK là con đường thực thi duy nhất."
L3 Consumers/Executors: executor_class_registry (dot/sql/ai/human/external/notification/render). ACK/NACK phân loại bắt buộc transient|permanent|poison — không silent failure. Heartbeat caller cùng TX với lease; false-heal protection (silent → ok không có tick = integrity warning). Idempotency registry per class.
L4 Realtime Gateway: "Nuxt MUST NOT connect directly to event_outbox, job_queue, LISTEN/NOTIFY." Gateway là substrate realtime duy nhất hướng Nuxt; áp permission filter (Đ37/33) + relevance filter; chỉ forward summary/red-flag/progress, không raw event flood.
L5 DLQ/Recovery/Governance: job_dead_letter + dlq_replay_request ledger — "Replay never bypasses Điều 32 approval." vw_audit_event_timeline(trace_id) = timeline một truy vấn.

5.3. Vòng đời Job — Work State Machine 9 trạng thái (Điều 45 §6.7, verbatim)

queued → leased → in_progress → succeeded
                            ↘ failed → retry_waiting → queued
                            ↘ (quá max_attempts) → dead_letter → (replay) → queued
   (supersede) → cancelled → (retention) → cleaned

Transition chỉ qua gated function (fn_job_enqueue/claim/progress/succeed/fail_transient/fail_permanent/cancel/cleanup_sweep/lease_reaper); "every executor must write status back to PG; no silent state change; no untracked work."

Trigger-in: SQL event → event qua iu_sql_event_route (đăng ký bảng route; cấm trigger ẩn).
Trigger-out: event → job qua consumer_registry (event_type → executor + job_kind + idempotency template); chống cycle bằng causation_id.
Idempotency 3 lớp: UNIQUE(job_kind, idempotency_key) + FOR UPDATE SKIP LOCKED + lease_token.
Lease: dot_iu_runtime_lease TTL ~600s renewable + fn_job_lease_reaper cứu lease chết.
Retry: max_attempts (~5) + backoff exponential jittered.
DLQ replay: cần workflow_admin + Đ31 refusal + Đ32 approval.

Substrate đã LIVE vs GAP: event bus live (event_outbox 133k rows, event_type_registry 31 types); toàn bộ job_queue/job_workflow/job_dead_letter/queue_heartbeat/consumer_registry CHƯA tồn tại; pg_cron chưa cài (worker tick gọi từ ngoài: Hermes/Codex/Directus flow/host cron). Bài học live nghiêm trọng: worker iu_outbound_default im lặng ~95h → vi phạm §15.5; heartbeat là việc ưu tiên đóng trước.

5.4. Ranh giới Executor — MODW/MOT KHÔNG phải executor

Executor whitelist 7 phần tử (Đ45 §11.5, verbatim): {DOT, Agent, Hermes, Codex, PG_worker, external_worker, future_Kestra_adapter}. MOT KHÔNG nằm trong set; future_MOT_executor là label bị cấm.

CHECK từ chối 'MOT' ở 4 bề mặt: job_queue.executor, consumer_registry.executor, job_subscription.executor_kind, queue_heartbeat.executor_kind. "MOT cannot register a heartbeat, cannot subscribe, cannot claim." ⟹ MODW khi "gọi agent thực thi" phải emit job graph rồi giao cho executor đã đăng ký; MODW/MOT không tự claim job, giữ lease, ghi heartbeat.

Seam MOT (design): MOT emit 1 job_workflow + N job_queue rows (DAG qua parent_job_id); workflow status derived từ step. MODW là MOT-shaped nên dùng chung seam này.

5.5. DOT — đường mutation + 2 runtime thực thi

DOT theo cặp (NT12 + Đ35): mỗi DOT Cấp B (add-step, connect, expand-block) phải có DOT Cấp A verify cùng scope (PG trigger enforce). Sửa bước đang chạy thật → flow fix_repair_dot (backup .bak + dry-run + integration verify + rollback).
Dispatch engine 3 nhánh (execution_engine): pg_function (14 DOT PG-only) · agent_api (Langdroid/OpenRouter) · hybrid. Dispatcher fn_process_agent_api_dispatch fail-closed, không tự execute; blocker thật: endpoint agent_api chưa có (endpoint_ref NULL) — "faking = mock = forbidden".
Hai runtime thực thi MODW phải điều phối được CẢ HAI + người:
1. agent_api (trả phí): Langdroid/OpenRouter — 22 DOT cần agent; có dispatcher fail-closed, đang chờ endpoint.
2. code-agent subscription (thuê bao): Hermes v0.14 + Kilo CLI v7.3.1 trên VPS (tmux + git worktree riêng/job, key qua Secret Manager); Claude Code CLI / Codex / GPT desktop chạy bằng Max/Plus — on-demand claude -p, gemini -p, GPT qua AppleScript. Nguyên tắc: "Dùng subscription đã trả — KHÔNG dùng API tính phí cho model flagship." (Caveat: runtime VPS mới ở mức scaffold, Codex từng lỗi 401, chưa chạy việc thật.)

5.6. Handoff người ↔ AI — tái dùng Comment Module M-001 ("Phòng họp của máy")

"CommentModule không phải comment box. Đây là phòng họp của máy — nơi AIs, Agents, System, User cùng làm việc có điều phối. Mọi quy trình đều đi qua đây." (M-001 v2 COMPLETE, live /knowledge/modules/10)

task_comments: tab_scope 12 giá trị (plan/verify/rules/checklist/prompt/reports/test…), agent_type (user/claude/gpt/system/claude_code/gemini/codex/claude_desktop…), action(comment/approve/reject) hiện 75/75 NULL — chỉ cần activate để có handoff approve/reject.
4 vai trò sẵn: AI Lead soạn draft → AI Critic phản biện → User duyệt; Agent nhận việc → báo tiến độ → tick checkpoint → bàn giao.
Bảng thông báo cho AI không-API = pattern pull qua agent-data: "Agent Data = bộ nhớ duy nhất; mỗi AI đọc prompt → tự biết phải làm gì; kết quả ghi vào Agent Data → AI khác đọc tiếp."
⟹ MODW handoff tái dùng Comment Module + consumer_registry/job_subscription làm routing chính thức (thay status-field thủ công), KHÔNG xây mới.

5A. Legacy Module Harvest Matrix — gom nhặt di sản, KHÔNG dựng lại

MODW phải tận dụng tối đa cái đã có và không làm lại. Các di sản ý tưởng (Super Session, M-001, M-002, M-005, MOW/MOT UI) được gom nhặt vào MODW chứ không dựng hệ mới chồng lấn.

Di sản	Giữ lại (harvest)	KHÔNG làm (no-overlap)
Super Session	Runtime message-log · turn-by-turn · hot path PG-native	KHÔNG dùng KB/RAG làm hot path
M-001 Comment Module ("phòng họp của máy")	Phòng họp AI/User/System; nhúng vào từng work object/step; reuse cho handoff/comment/report/prompt discussion	KHÔNG tạo comment system mới
M-002 Workflow Module	Step timeline · checkpoint · nested process · block thinking	KHÔNG lấy BPMN XML làm SSOT
Task Orchestration / M-005	Lifecycle: tạo task → prompt → giao agent → review report → verify → done	KHÔNG dựng task manager độc lập
MOW UI	Overview 6 tầng · traffic light · proposal/kaizen	MODW là drill-down của MOW, không thay
MOT UI	Thẻ nhiệm vụ 4 vùng; MODW mở sâu từ MOT card	MOT KHÔNG là executor

5B. Điều 39 Integration Clause — đặt nền KG, KHÔNG biến thành engine

Điều 39 (Knowledge Graph Law v2.3, BAN HÀNH) phải được đặt nền để MODW dùng làm knowledge graph / provenance / recommendation / explainability — nhưng không được biến thành runtime engine.

Điều 39 / KG trong MODW CHỈ làm:

Context graph trước khi thiết kế (Context Graph Gate — Điều 20/43 đọc trước);
Dependency / provenance graph (việc này phụ thuộc gì; dữ liệu/quyết định đến từ đâu);
Priority / scaffold suggestion (gợi ý ưu tiên & khung bước; AI suggest → người duyệt);
Negative knowledge / anti-pattern (cảnh báo vết xe đổ);
Explainability (giải thích vì sao đề xuất thế này).

CẤM (ranh giới cứng): KG không là runtime engine · không là SSOT · không là executor · không thay queue/job/PG hot path. KG là projection để gợi ý & giải thích; mọi mutation vẫn đi qua DOT/Proposal/Điều 45 và PG vẫn thắng.

6. YÊU CẦU CHỨC NĂNG MODW (từ đầu bài, đã làm giàu)

6.1. Hai kênh thiết lập

Chính — DOT: nạp/khai báo declarative; DOT phải phủ 100% loại nhiệm vụ; mọi mutation qua DOT cặp.
Phụ — UI tay: thao tác kỹ thuật đơn giản (thêm bước, đổi trigger/tên/người/thứ tự, khai báo field). Dùng khi cần.
Mọi thay đổi cấu trúc đi qua Proposal → duyệt (xem §10) — đây là đường duy nhất, không mutate trực tiếp.

6.2. Khung dao động rộng (2 → vài trăm bước, phút → cả năm)

Resume-safe + snapshot + checkpoint cho long-running; correlation chain (correlation_id+trace_id+parent_run_id) giữ xuyên sub-workflow/vòng lặp.
Bất biến + version: workflow_def/step_def đã active = bất biến; workflow đang chạy pin version cũ; sửa = bản mới version++, retire bản cũ (không DELETE — Amidan).

6.3. Chuẩn hoá LOẠI BƯỚC (để thêm/bớt rất nhanh)

Hai họ theo nguồn gốc: bước chặng (planned/milestone) vs bước phát sinh (emergent — sinh khi đang chạy, ví dụ báo cáo không qua → phát sinh yêu cầu bổ sung, chưa cho sang bước sau). UI phải cho ai cũng phân biệt được lộ trình vs phát sinh.
Sub-bước chuẩn trong một bước (một việc nhỏ vẫn 10–20 sub-bước): ① viết prompt → ② (tuỳ) xác nhận prompt OK, lặp đến đạt → ③ gọi agent làm + viết báo cáo đúng chỗ → ④ kiểm báo cáo, cho qua/bắt bổ sung (vẫn trong bước) → ⑤ soạn prompt bước tiếp.
Bộ loại bước (ánh xạ executor_class + step taxonomy BPMN Đ34): human_input · ai_prompt_run · review_gate · dot_mutation · sql_query · external_api · notification · wait_gate (+ events start/end/timer/message, gateways condition/parallel/inclusive). Mỗi loại có form khai báo sinh từ registry; thêm loại = INSERT, không code.
Block library (Đ34 Tầng 2): lắp block sẵn (basic-approval, approval-3-level, ai-review, loop-retry) chứ không chỉ bước rời — "ít gạch nhiều công trình". ~50–100 block → 10.000 WF.
9-state runtime (§5.3) cho mỗi bước/vòng; ghi state về PG, cấm silent state change.

6.4. UI mỗi bước = "con thuyền" trung tâm chuyển giao

Mỗi bước/nhiệm vụ mang toàn bộ tài sản của việc: kế hoạch · thiết kế · prompt (+ lịch sử qua các vòng) · báo cáo (ngắn gọn, đúng chỗ) · comment · chỉ thị bước tiếp · trạng thái · evidence · log.

Payload nặng (prompt/báo cáo dài) lưu runtime store + IU; hàng đợi chỉ mang payload_ref.
Phân định DOT (cứng) vs AI (mềm) trong handoff (Đ38): phần cứng (số/status/binding) DOT tự so; phần ngữ nghĩa/logic AI đề xuất → người duyệt. AI suggest, không tự ban hành.
Làm xong → ghi báo cáo → hàng đợi bắt sự kiện → đẩy job gọi "người (gồm AI) tiếp theo".

6.5. Dual trigger & phối hợp Người + AI(API) + AI(thuê bao)

Luôn hai đường kích hoạt song song:

Qua API + hàng đợi: hệ thống emit job; agent có API (Hermes/Code CLI/Codex/Langdroid) lease job.
Qua bảng thông báo text: notification board mà bất kỳ AI/người nào vào cũng đọc được — dành cho AI không-API (ChatGPT/Claude Desktop/Cowork/gói thuê bao) đọc, làm, ghi báo cáo đúng chỗ.

Lấy cảm hứng từ dual-reading MARK/CUT (operator-driven vs puller-driven): cùng một việc, người bấm tay HOẶC puller tự lease đều được; queue chỉ là lớp audit+retry tuỳ chọn, bật per-collection qua dot_config.
Quy trình tự động hoàn toàn hoặc tự động một phần đều OK. Lý do thực tế: API đắt cho phần thiết kế/soạn prompt/kiểm → tận dụng thuê bao model mới cho rẻ.

6.6. Vòng lặp linh hoạt

3 vòng hay 30 vòng tuỳ phát sinh; AI điều hành (GPT/Claude Code) có thể mở vòng mới: đẩy prompt → gọi làm → gọi kiểm → gọi xác nhận (khi quan trọng).
Vòng lặp phải giữ correlation chain + chống cycle (causation_id); phân biệt vòng kế hoạch vs vòng phát sinh.
Ràng buộc governance: AI chỉ được tạo emergent_step_request / suggested_loop / workflow_change_request. Việc chèn bước thật, mở vòng thật, đổi graph thật hoặc đổi trigger/executor thật phải đi qua Proposal → risk/approval rule theo Điều 32 → DOT apply theo Điều 35 → version/snapshot pin. AI không được tự mutate workflow đang chạy, không được bypass approval, không được ghi trực tiếp vào job graph (Điều 45).

6.7. Checklist bắt buộc đưa vào UI

Mỗi macro 8 câu: đọc gì trước? · mục tiêu? · thế nào là hoàn thành? · chứng minh bằng gì? · không được làm gì? · xử lý khi thiếu ngữ cảnh/phát sinh? · không xong dừng ở đâu? · tự kiểm gì trước báo cáo? (cộng hưởng NT14 — 6 câu thực thi được ngay).
Kiểm tra bắt buộc: không tin report — kiểm file thật; không dùng trí nhớ — đọc governed files; tạo input xấu (không chỉ happy path); phân biệt các loại PASS (planning/dry-run/engineering/authority/implementation/production). "No blind PASS — không artifact = FAIL" (Đ30).

7. Mô hình dữ liệu sơ bộ (chỉ phác thảo cho UI)

Lưu ý (conceptual ≠ DDL): các tên như work_item, work_package, workflow_run trong §4A là tên logic/conceptual để UI và Council cùng hiểu đối tượng; chưa phải quyết định tạo collection/bảng mới. Tên bảng thật, việc tái dùng bảng cũ hay mở rộng bảng hiện hữu phải qua scan PG/Directus · Directus reuse matrix · birth gate Đ0-G · Điều 29/36 · Proposal/DOT tương ứng. MODW không tự khai sinh bảng mới.

Tái dùng + mở rộng substrate đã sống — không dựng mới trùng lặp:

Định nghĩa (design-time): workflow_registry, workflow_step_def (order_index · branch_condition · parallel_group · sub_workflow_id · trigger_in/out_config · iu_unit_id · task_def_id), task_def (executor_class · input_form_id · output_table_id · instruction_iu_unit_id · deadline/escalation/retry_policy).
Runtime (instance): workflows(run) · workflow_steps(run) · tasks(run) — correlation_id, trace_id, parent_run_id, idempotency_key, snapshot_jsonb.
Queue (Đ45, tách 3 substrate): event bus (event_outbox…) ≠ job queue (job_queue, job_workflow, job_dead_letter, queue_heartbeat — chưa tồn tại, cần tạo) ≠ realtime topic.
Handoff/hội thoại nóng: task_comments (Comment Module) + runtime message-log append-only (1 báo cáo/comment = 1 row) — không đẩy vào KB/RAG ở hot path.
Proposal/Kaizen: workflow_change_requests (reuse).
Khai báo bắt buộc (Đ33/29/36): mỗi bảng/registry MODW phải có DB+Lớp + governance_role + purpose + description + birth gate Đ0-G.

8. Quan hệ Directus — phân tích tái dùng (cần quyết kỹ)

Tái dùng: Directus = API + permissions + admin + staging (T5). Nuxt lấy data qua REST Directus, không gọi PG.
KHÔNG lạm dụng: Directus realtime/subscriptions không làm event bus của app (vi phạm ranh giới Đ45 — boundary violation L2); Directus không làm orchestration engine/executor; legacy Directus flows chỉ legacy_trace.
Hành động: lập bảng đối chiếu "chức năng MODW cần ↔ Directus có sẵn ↔ tự dựng" trước khi chốt — như cách hiện nay (UI Directus dùng khi cần, không phải mặt tiền).

9. Quy trình chuẩn 12 bước (PRESET mẫu của MODW)

Đầu bài đã cho sẵn — đưa vào MODW như template dựng sẵn (mỗi bước = một step_def neo IU + checklist 8 câu; nhiều bước có gate phê duyệt & gate bằng chứng):

Xác định đầu bài → 2. Kiểm tra nền luật/nguyên tắc → 3. Khảo sát hiện trạng → 4. Thiết kế kỹ thuật → 5. Review/phê duyệt thiết kế (gate) → 6. Chuẩn bị thi công → 7. Kiểm thử kế hoạch/dry-run → 8. Phê duyệt thi công (gate) → 9. Thi công có kiểm soát → 10. Kiểm tra sau thi công → 11. Báo cáo & đóng gói bằng chứng (gate evidence) → 12. Cập nhật trạng thái/roadmap.

Đây vừa là preset, vừa là ca kiểm thử chứng minh khuôn MODW đủ tổng quát (phủ human + ai_agent + review_gate + dot + evidence).

9A. Dev Workflow Preset — ca kiểm thử số 1 của MODW

Nâng preset dev thành ca kiểm thử số 1: nếu khuôn MODW chạy đúng cho chính quy trình phát triển (idea → evidence → roadmap), nó đủ tổng quát. Mỗi bước phải có: NT14 (6 câu) + checklist macro (8 câu) + Evidence Contract (§10B).

Nhận ý tưởng/đầu bài.
Đọc luật/KB/governed files bắt buộc (không dùng trí nhớ).
Rà hiện trạng live/PG/catalog (không giả định).
Lập thiết kế.
AI critic review (phản biện độc lập).
User/Council gate (phê duyệt — Điều 32).
Sinh prompt thi công (neo IU template).
Agent thi công qua executor hợp lệ (Điều 45 whitelist — MODW không tự chạy).
Agent báo cáo (đúng chỗ, runtime store).
AI/User verify artifact thật (no blind PASS).
Đóng evidence pack (gate bằng chứng).
Cập nhật IU/roadmap/issue/DOT registry nếu cần.

Khuôn bắt buộc cho MỖI bước trên:

NT14 — 6 câu: data ở đâu · ai làm · khi nào · ngưỡng · kiểm bằng gì · sai xử lý sao.
Checklist macro — 8 câu: đọc gì trước · mục tiêu · thế nào là hoàn thành · chứng minh bằng gì · không được làm gì · xử lý khi thiếu ngữ cảnh/phát sinh · không xong dừng ở đâu · tự kiểm gì trước báo cáo.
Evidence Contract: expected output · evidence artifact · verifier · pass/fail condition · rollback/escalation (xem §10B).

10. Governance & vòng đời thay đổi (quan trọng — còn thiếu ở v1)

Proposal/Kaizen là đường DUY NHẤT sửa workflow (Điều XX §8 + Đ34 WCR + Đ32): thêm/bớt/sửa bước/trigger/executor = INSERT workflow_change_requests/*_proposal (submitter + reason + impact preview + target version) → duyệt → DOT apply → version++. Không mutate trực tiếp.
Quorum theo risk + cấm self-approve (Đ32): high = ≥1 president + ≥2 ai_council + 0 reject; medium = ≥1 president; cấm người/agent tạo request tự duyệt high-risk. "Đề xuất phải đứng được một mình".
DOT cặp + verify 3 tầng (Đ35): mọi mutation có DOT A kiểm; sửa bước đang chạy → fix_repair_dot.
Bất biến + version (Đ34/38): def đã active không sửa tại chỗ; bản mới version++, retire không delete.
UI = template đăng ký (Đ28): sơ đồ/card/dialog qua checklist 8 bộ phận + test 5/5; Nuxt zero-logic.
Design-before-execution Tier 2-3 (Đ20): full design + review độc lập + rollback + smoke + User approve trước khi chạm DDL/runtime.
Hồi quy + toàn vẹn (Đ30/31): Playwright E2E + data-testid cho UI; watchdog liveness + system_issues dedupe cho runtime.
Birth gate Đ0-G cho mọi entry registry (workflow_def, step_def, executor_class…).

10A. Ownership / No-overlap Matrix (chủ sở hữu thật vs MODW)

Mỗi địa hạt có một chủ sở hữu thật (no-double-ownership). MODW chỉ được hiển thị / cấu hình / đề xuất / điều phối, không được sở hữu hay định nghĩa lại.

Địa hạt	Chủ sở hữu thật	MODW ĐƯỢC làm	MODW KHÔNG được làm
Workflow grammar / block / step taxonomy	Điều 34	Lắp WF từ component chuẩn; preview	Định nghĩa lại taxonomy/grammar
Queue / job / event / heartbeat / DLQ	Điều 45	Emit job graph; xem state/health	Tự claim/lease/heartbeat; định nghĩa lại queue-core
Text-as-code / IU / version	Điều 38/44	Neo FK `iu_unit_id`; render khi đọc	Tái thiết kế IU internals (axis/compose/cut/vector/owner)
Approval / quorum	Điều 32	Gửi request; hiển thị trạng thái duyệt	Sở hữu quorum; self-approve high-risk
DOT mutation	Điều 35	Soạn DOT cặp; preview impact	Mutate trực tiếp ngoài DOT/Proposal
UI template / render	Điều 28	Đăng ký template trong PG; render zero-logic	Nhúng business logic vào Nuxt; query PG trực tiếp
Integrity / regression / evidence	Điều 30/31	Cung cấp `data-testid` · evidence cho E2E/watchdog	Bỏ "no blind PASS"; tự cho PASS không artifact
KG / semantic relation	Điều 39	Dùng làm context/provenance/recommendation/XAI	Biến KG thành engine/SSOT/executor
Human role / permission	Điều 37 + human-org-role law (draft)	Hiển thị one-UI-per-role; áp permission filter	Định nghĩa lại role/permission model

"No blind PASS — không artifact = FAIL" (Điều 30). Báo cáo chỉ là claim, phải verify bằng file/log/PG/API/evidence thật.

Mỗi step BẮT BUỘC có một Evidence Contract gồm:

expected output — kết quả mong đợi (định nghĩa "thế nào là xong");
evidence artifact — bằng chứng thật (file / log / PG row / API response / screenshot);
verifier — ai/cái gì kiểm (AI critic / User / DOT-A / E2E);
pass/fail condition — điều kiện đạt/không đạt;
rollback / escalation nếu fail — đường lùi/leo thang khi không đạt.

Không có artifact thì KHÔNG được PASS. Phân biệt các loại PASS (planning / dry-run / engineering / authority / implementation / production) — một loại PASS không tự suy ra loại khác.

11. Ranh giới — MODW KHÔNG làm gì (no-double-ownership)

MODW chỉ sở hữu lớp ứng dụng "thiết kế + điều phối chi tiết workflow". Tuyệt đối KHÔNG:

Thực thi business work trực tiếp; KHÔNG tự claim job/giữ lease/ghi heartbeat (executor làm).
Định nghĩa lại queue/event-core/9-state/lease/retry/DLQ → Điều 45.
Tái thiết kế IU internals (axis/compose/cut/vector/owner) → Điều 38/44.
Sở hữu approval quorum → Điều 32; DOT lifecycle → Điều 35; display template engine → Điều 28.
Chứa business logic trong Nuxt; query PG trực tiếp; dùng Directus realtime làm event plane.
Dùng KB/RAG cho dữ liệu vận hành nóng; sửa DB ngoài đường DOT/Proposal có governance.
Đưa vector/body/secret vào queue/staging (NVSZ).

11A. Executor Adapter Boundary

Agent qua API và subscription agents (thuê bao) đều chỉ là executor/adapter đã đăng ký (Điều 45 — whitelist 7 phần tử). MODW phối hợp chúng nhưng không vượt registry.

MODW không gọi tắt ngoài registry, không tự chạy job, không giữ lease, không ghi heartbeat — executor làm.
"Gọi agent thực thi" = emit job graph → giao cho executor đã đăng ký claim/lease (MODW/MOT KHÔNG nằm trong executor set).
Với AI không API (ChatGPT/Claude Desktop/Cowork/gói thuê bao): MODW dùng M-001 / notification board / pull pattern để giao việc và nhận báo cáo (AI đọc prompt → tự làm → ghi báo cáo đúng chỗ → queue "bắt sự kiện").

12. Lộ trình & tiền điều kiện (đặt kỳ vọng đúng)

Thứ tự ưu tiên hạ tầng: Phase 3 (heartbeat) đóng TRƯỚC (vì §15.5 đã bị vi phạm — worker im 95h), rồi job_queue/state-machine/trigger-out, rồi tầng MOT/MODW (≈ Phase 6). MODW phụ thuộc Phase 1–4.
Tiền điều kiện council còn treo: OP-B (IU owner-per-scope), C-4 (review_decision vs Đ32), endpoint agent_api thật, "Điều XX Application Process Law" chỉ soạn sau khi Requirement Rev2 + Master Design Rev2 + Phase 0/1/2 đóng + Council Round 1. ⟹ MODW v1 định vị là UI Admin tuân Đ45 + dự thảo Điều XX, KHÔNG đẻ hạ tầng queue/event mới.
Mọi giá trị cụ thể (TTL, max_attempts, partition threshold) là quyết định Council, không hard-code.

12A. Pre-wireframe Gate — chốt trước khi vẽ wireframe

Trước khi vẽ wireframe phải chốt đủ 8 hạng mục nền. Thiếu bất kỳ hạng mục nào → trạng thái tài liệu là APPROVE WITH REQUIRED PATCHES, chưa sang wireframe.

#	Hạng mục phải chốt	Mục trong tài liệu
1	Object Model	§4A
2	Legacy Harvest Matrix	§5A
3	Điều 39 clause	§5B
4	Artifact Placement Matrix	§5.1.1
5	Ownership Matrix	§10A
6	Dev Workflow Preset	§9A
7	Executor Boundary	§11A
8	Evidence Contract	§10B

Trạng thái hiện tại (v2.1): 8/8 hạng mục đã được đặt nền trong tài liệu này. Vì nội dung từng hạng mục còn chờ Council/User chốt, trạng thái tài liệu vẫn là APPROVE WITH REQUIRED PATCHES — chỉ chuyển sang wireframe sau khi Council/User xác nhận từng hạng mục.

13. Các quyết định cần Council/User ratify trước wireframe

Phần lớn "câu hỏi mở" của v1 nay đã có đề xuất mặc định trong các mục nền §4A · §5.1.1 · §5A · §5B · §10A · §10B · §11A · §12A. §13 vì vậy không còn là danh sách mơ hồ, mà là danh sách quyết định chờ Council/User ratify trước khi sang wireframe.

13.1. Đã có đề xuất mặc định trong v2.1 — cần Council/User ratify

Định vị MODW = surface độc lập nhưng mở từ MOW/MOT, liên kết 2 chiều (§4, §4A).
MODW dùng Điều 34 làm grammar/block/workflow law — không thay Điều 34 (§10A).
Runtime store vs IU vs queue theo Artifact Placement Matrix §5.1.1.
Điều 39 / KG theo §5B: intelligence/provenance/recommendation/XAI — không runtime engine.
AI không-API dùng M-001 / notification board / pull pattern — không tạo comment system mới (§5A, §11A).
Hai runtime agent API và subscription đều đi qua Executor Adapter Boundary §11A.

13.2. Còn cần Council quyết sau (chưa chốt trong v2.1)

Tên collection/bảng thật sau khi scan PG/Directus (xem §7 lưu ý conceptual).
Directus reuse matrix chi tiết (§8).
Risk/quorum cụ thể cho emergent step / suggested loop (Điều 32).
UI route/navigation cuối cùng.
Điều XX Application Process Law sẽ extract những phần nào, sau khi Requirement + Master Design đủ chín.

13.3. Khoảng trống KB còn phải khảo sát

Khoảng trống KB (phải khảo sát trước khi thiết kế):

"Openclaw" và "Chatwoot/Chatwood": KHÔNG tồn tại trong KB (cả 3 agent xác nhận). Chatwoot ≈ nền tảng customer-support inbox → có thể gắn vào seam customer-care 7 job_kind đã chờ sẵn (customer_message_inbound→classify→draft→approve→send→followup→escalate). Cần định nghĩa rõ Openclaw là gì.
GAP kỹ thuật mở: job_queue/heartbeat chưa tồn tại; review_decision_id chưa ratify; trigger-in/out chưa đăng ký event type; endpoint agent_api NULL; split/merge metadata propagation P1 open.

13.4. Chi tiết từng câu hỏi (ánh xạ vào 13.1/13.2 ở trên — không còn để ngỏ vô hạn)

Định vị MODW: "tầng zoom sâu nhất của MOW" hay surface độc lập liên kết 2 chiều? (ảnh hưởng navigation + data contract)
MODW vs Điều XX / Điều 34: MODW có thúc đẩy promote Điều 34 thành luật nền không? Vị trí chính xác của MODW trong "Điều XX"?
Bảng thông báo cho AI không-API: thiết kế sao để người + mọi loại AI đọc/ghi chung, vừa cho hàng đợi "bắt sự kiện"? (điểm mới & rủi ro nhất — tái dùng Comment Module tới đâu?)
Runtime store vs IU vs queue: chốt ranh giới lưu prompt/báo cáo/comment để không lặp sai lầm super-session.
Directus reuse: chốt danh mục tận dụng lại vs tự dựng.
Bước phát sinh & mở vòng động: cơ chế cho AI điều hành chèn bước/mở vòng mà vẫn giữ governance + version pin + correlation chain.
Hai runtime thực thi: điều phối agent_api (trả phí, chờ endpoint) và code-agent subscription (thuê bao) thế nào trong cùng UI?
6 mẫu nhiệm vụ (nếu cần): ánh xạ vào 7 executor_class hay 6 tầng nghiệp vụ? (KB chưa chốt)

14. Đề xuất phạm vi UI lần này

Vì nhiệm vụ chỉ là thiết kế UI, MODW phác thảo 2 surface (hoặc 2 chế độ của 1 surface), cùng ngôn ngữ thiết kế với MOW/MOT (Be Vietnam Pro, ink, brand #639922), phản ánh PG realtime:

A. MODW Builder (Thiết kế): danh sách/đồ thị bước của 1 workflow; thêm/sửa/xoá bước (chặng vs phát sinh) + lắp block; panel khai báo từng loại bước (form sinh từ registry); nối IU/field/collection/agent/trigger; preview DOT command + impact + version tương ứng; mọi sửa → Proposal.
B. MODW Cockpit (Vận hành): workflow đang chạy theo bước & vòng lặp; mỗi bước mở "con thuyền" (kế hoạch · prompt · báo cáo · comment · chỉ thị); dual-trigger view (API queue + bảng thông báo); 9-state + SLA + escalation + heartbeat/health; DLQ + replay (qua duyệt).

3 panel/capability BẮT BUỘC cho cả hai surface (có thể là panel/tab bên trong Builder/Cockpit — không nhất thiết tách thành màn hình riêng, tránh phình thành 5 màn hình khi chưa cần):

Handoff Room — tái dùng M-001 / task_comments / message-log; chứa prompt · report · comment · approve/reject · chỉ thị bước tiếp.
Registry Inspector — soi binding IU/DOT/executor/event_type/permission/collection/trigger; không cho sửa tay trực tiếp, chỉ tạo proposal.
Evidence Pack — gom expected output · artifact · verifier · pass/fail condition · rollback/escalation; không artifact = không PASS.

15. Checklist gửi Council/User review

Mỗi dòng là một câu kiểm tra fail-closed. Bất kỳ FAIL nào → tài liệu CHƯA READY_FOR_COUNCIL_REVIEW.

MODW có còn bị hiểu là Mother thứ 5 không? Nếu có → FAIL (§0, §4A).
MODW có tự sở hữu queue/event/job không? Nếu có → FAIL (Điều 45 · §10A · §11A).
MODW có tự sở hữu workflow grammar không? Nếu có → FAIL (Điều 34 · §10A).
MODW có bypass Proposal/DOT/Approval không? Nếu có → FAIL (§6.6 · §10 · §10A).
IU có còn là trung tâm text-as-code không? Nếu không → FAIL (§5.1 · §5.1.1).
Runtime hot path có còn PG/message-log/event-log không? Nếu không → FAIL (§1 · §5.1.1).
Điều 39 có bị biến thành runtime engine không? Nếu có → FAIL (§5B).
M-001 / M-002 / Super Session / M-005 đã được harvest, không dựng lại chưa? (§5A).
Evidence Contract đã đủ để chặn "PASS mồm" chưa? (§10B).
§13 decision list đã đủ rõ để Council ratify trước wireframe chưa? (§13).

Phụ lục — Nguồn KB đã rà soát (để Claude Code CLI tra cứu khi sửa)

knowledge/dev/laws/constitution.md (15 NT)
knowledge/dev/laws/dieu45-pg-native-queue-and-task-orchestration-law.md (BAN HÀNH)
knowledge/dev/design/law-extraction-plan-application-process-workflow-task.md ("Điều XX")
knowledge/dev/laws/dieu34-workflow-law.md, dieu35-dot-governance-law.md, dieu32-approval-law.md, dieu33-postgresql-law.md, dieu28-display-technology-law.md, dieu20/26/30/31/37/38/29/36
knowledge/dev/requirements/iu-mow-mot-event-foundation-requirements.md + …/v0.6-iu-4mothers-event-foundation-rev2/00-requirement-brief-rev2.md
knowledge/dev/design/iu-mow-mot-event-foundation-design.md (master design 6 tầng)
knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/03-event-5layer-realtime-dlq-design.md
knowledge/dev/laws/dieu44-trien-khai/v0.6-dieu45-full-queue-orchestration-design-pack/ (00–17; file 11 MOT mapping, 12 customer-care)
knowledge/dev/laws/dieu38-trien-khai/C1-text-unit-operating-model.md (IU logical-unit vs version)
knowledge/dev/ui/mow/unified-canvas/spec.md (MOW canonical) + knowledge/dev/ui/mow-unified-canvas-handoff-pack-v1.md
knowledge/dev/architecture/agent-api-registry.md, knowledge/dev/architecture/vision-auto-dispatch-architecture.md
knowledge/current-state/reports/20260522-vps-agent-parallel-runtime-setup.md
knowledge/current-state/reports/proposal-super-session-pg-native-architecture-2026-04-20-gpt.md (bài học super-session)
knowledge/dev/planning/comment-module/comment-module.md (M-001)

Ghi chú cho người sửa tiếp (Claude Code CLI): file này là bản v2 đơn-file. Sửa tại chỗ qua patch_document (đoạn nhỏ) thay vì update_document (ghi đè cả file). Khi một mục phình to, cân nhắc tách thành pack knowledge/dev/ui/modw/NN-<chu-de>.md và để file này làm 00-summary. Cập nhật số version ở header mỗi lần sửa lớn.

Hết bản tổng hợp v2.1 minor-patched (2026-06-12: reframe Work Detail Workbench + 9 mục nền + Pre-wireframe Gate; minor-patch đồng bộ ngôn ngữ §1/§4/§6.6/§7/§13/§14 + §15 Council checklist — APPROVE WITH REQUIRED PATCHES · ready for Council/User ratification before wireframe).