Đề bài quản lý quy trình — PG-native Procedure Intelligence

Path: knowledge/dev/laws-new/workflow-manage/de-bai-quan-ly-quy-trinh.md
Status: Đề bài / Problem Statement / Non-authorizing
Scope: Quản lý quy trình vận hành hệ thống và quy trình business bằng hướng PG-first / PG-native / PG-driven
Không phải: thiết kế DDL cuối cùng, không phải governance registry mới, không phải registries-pivot, không phải knowledge graph, không phải runtime authorization.

1. Nỗi đau gốc

Hệ thống hiện có rất nhiều nguyên liệu nằm trong PostgreSQL: DOT, collection/table/view, schema, field, label, IO contract, trigger, checker, workflow, form, business step, actor, rule, gate, report, evidence.

Nhưng các nguyên liệu này đang rời rạc. Khi cần làm một việc cụ thể, Agent không biết nhanh:

Quy trình tương ứng đã tồn tại chưa.
Nếu có, quy trình nằm ở đâu và phải gọi thế nào.
Quy trình gồm những bước nào.
Mỗi bước cần nguyên liệu gì.
Nguyên liệu nào đã có trong PG.
Nguyên liệu nào còn thiếu.
Thiếu thì phải gọi quy trình bổ sung nào.
Việc này có thể chạy bằng checklist, chuỗi DOT, hay một nút tự động.

Nỗi đau tổng quát:

PG lưu gần như toàn bộ nguyên liệu của hệ thống, nhưng PG chưa có một lớp PG-native để hiểu PG đang có gì, dùng cho việc gì, ghép thành quy trình nào, thiếu gì và nên gọi gì tiếp theo.

Nói ngắn hơn:

PG có nguyên liệu, nhưng chưa có trí nhớ quy trình.

Kết quả là mỗi việc nhỏ đều dễ biến thành một cuộc khảo sát lớn: mất thời gian, dễ làm trùng, dễ bỏ sót, khó tái sử dụng, khó tự động hóa, và đi ngược triết lý LEGO của laws-new/.

2. Đầu bài cốt lõi

Xây một lớp quản lý quy trình cực mỏng, dựa trên PostgreSQL, trong đó:

Quy trình là trung tâm.
DOT, collection, schema, field, label, IO contract, trigger, checker, form, actor, rule, gate, report, evidence là nguyên liệu.
PG là nơi đọc, nối, kiểm tra đủ/thiếu, chống làm trùng và định tuyến bước tiếp theo.
Hệ thống phải giúp AI/Agent đọc nhanh, hiểu nhanh và hành động đúng, thay vì phải khảo sát lại toàn hệ thống cho mỗi việc nhỏ.

Câu hỏi mà hệ thống phải trả lời nhanh:

Muốn làm việc X thì đã có quy trình nào chưa?
Quy trình đó cần những nguyên liệu gì?
Trong PG hiện đã có nguyên liệu nào?
Còn thiếu gì?
Thiếu thì xử lý bằng quy trình nào?
Quy trình hiện chạy được ở mức nào: mô tả, checklist, chuỗi DOT, hay một nút?

3. Bốn điểm mù cần giải quyết

3.1. Mù tồn tại

Agent không biết quy trình đã có chưa.

Ví dụ:

Cần tạo DOT mới nhưng không biết đã có quy trình tạo DOT chưa.
Cần thêm nhãn nhưng không biết quy trình thêm nhãn nằm ở đâu.
Cần xử lý một bước business nhưng không biết đã có workflow tương ứng chưa.
Cần chạy một việc lặp lại nhưng không biết đã có entry DOT hoặc checklist hay chưa.

Yêu cầu:

Có cách tìm nhanh quy trình theo việc cần làm, từ khóa, nhóm, miền, trigger, đối tượng đầu vào, đối tượng đầu ra.
Có cách phân biệt quy trình chưa có, đã có dạng text, đã có manifest máy đọc, đã chạy checklist được, đã có chuỗi DOT, hoặc đã có one-button DOT.

3.2. Mù nguyên liệu

Agent không biết một quy trình cần những nguyên liệu nào.

Ví dụ một quy trình có thể cần:

DOT để kiểm tra hoặc thực thi.
Collection/table/view để đọc/ghi.
Schema/field để biết cấu trúc dữ liệu.
Label/tag/category để phân loại.
IO contract để biết input/output.
Trigger để biết khi nào chạy.
Checker/validator để biết pass/fail.
Actor/role để biết ai làm.
Form field để biết cần điền trường nào.
Evidence/report để biết ghi nhận kết quả ở đâu.

Yêu cầu:

Mỗi quy trình phải có lớp mô tả cho người đọc và lớp manifest dạng code/JSON cho máy đọc.
Manifest phải khai được các nguyên liệu cần cho toàn quy trình và cho từng bước.
Text là lớp giải thích phụ; manifest máy đọc là lớp chính để PG có thể bóc tách và đối chiếu.

3.3. Mù đủ/thiếu

Agent không biết nguyên liệu nào đã có, nguyên liệu nào thiếu, nguyên liệu nào chưa biết nguồn kiểm tra.

Ví dụ:

Quy trình cần 8 nguyên liệu.
PG kiểm được 5 nguyên liệu đã có.
2 nguyên liệu thiếu.
1 nguyên liệu chưa rõ phải kiểm ở đâu.

Yêu cầu:

PG phải tự đọc từ PG để kiểm tra hiện trạng nguyên liệu.
DOT thì đối chiếu với nguồn DOT hiện có.
Collection/table/view thì đối chiếu với catalog/schema PG hiện có.
Field/schema thì đối chiếu với metadata/schema hiện có.
Label/tag/category thì đối chiếu với danh mục nhãn hiện có.
Trigger thì đối chiếu với trigger/rule/event metadata hiện có.
IO contract/checker/report/evidence thì đối chiếu với nơi lưu tương ứng nếu đã có.
Nếu chưa biết nguồn kiểm tra, ghi rõ UNKNOWN_SOURCE, không dừng hệ thống.

Mục tiêu không phải bắt hệ thống sạch mới dùng được. Mục tiêu là dùng được ngay trên hệ thống hiện tại, rồi để PG chỉ ra chỗ thiếu/bẩn/chưa rõ.

3.4. Mù lắp ráp

Khi xử lý một việc lớn, Agent không biết nên:

Gọi một quy trình đã có.
Gọi một quy trình con để xử lý một mảng việc.
Lắp một quy trình mới từ các nguyên liệu có sẵn.
Tạo nguyên liệu thiếu trước rồi quay lại quy trình chính.
Đề xuất đóng gói quy trình lặp lại thành one-button DOT.

Yêu cầu:

Quy trình phải có khả năng gọi quy trình con.
Một nguyên liệu thiếu phải trỏ được tới quy trình bổ sung tương ứng.
Một quy trình lớn có thể lắp từ nhiều quy trình nhỏ theo triết lý LEGO.
Một quy trình lặp lại nhiều lần có thể được nâng cấp dần: text → manifest → checklist → DOT sequence → one-button.

4. Quy trình là đơn vị lắp ráp

Định nghĩa nền:

Quy trình là đơn vị lắp ráp công việc. PG là nguồn sự thật về nguyên liệu. Mục tiêu là để máy biết quy trình nào dùng nguyên liệu nào, còn thiếu gì, và phải gọi gì tiếp theo trước khi chạy.

Một quy trình không chỉ là workflow kỹ thuật. Quy trình bao gồm cả:

Quy trình vận hành hệ thống.
Quy trình tạo/sửa DOT.
Quy trình thêm/sửa label.
Quy trình tạo/sửa collection hoặc schema.
Quy trình tạo IO contract.
Quy trình kiểm tra checker/validator.
Quy trình business.
Quy trình form/field.
Quy trình approval/gate.
Quy trình trigger/event.
Quy trình report/evidence.

Bản chất chung của mọi quy trình:

Trigger là gì?
Ai làm?
Cần input gì?
Gồm bao nhiêu bước?
Mỗi bước cần điền trường nào?
Mỗi bước gọi DOT nào?
Mỗi bước đọc/ghi collection nào?
Điều kiện pass/fail là gì?
Thiếu nguyên liệu thì làm gì?
Đầu ra là gì?

5. Hai lớp mô tả của quy trình

Mỗi quy trình cần có hai lớp.

5.1. Lớp text cho người đọc

Dùng để con người hiểu nhanh:

Tên quy trình.
Mục tiêu.
Khi nào dùng.
Ghi chú ngắn.
Cảnh báo an toàn.
Mức tự động hiện tại.

Lớp này phải ngắn, rõ, dễ đọc trên Nuxt treeview.

5.2. Lớp manifest cho máy đọc

Dùng để PG/Agent hiểu và tự động hóa:

Procedure code.
Trigger.
Input.
Output.
Steps.
Required ingredients.
Used DOTs.
Used collections.
Used fields/schema.
Used labels.
Used triggers.
Used IO contracts.
Checker/pass-fail.
On-missing route.
Sub-procedure calls.
Automation level.

Manifest có thể bắt đầu đơn giản bằng JSON/JSONB. Không cần hoàn hảo ngay; quan trọng là máy đọc được và PG có thể bóc tách.

6. Yêu cầu phân nhóm

Để con người và Agent tìm kiếm nhanh, quy trình phải được phân nhóm tốt nhưng không phức tạp.

Các trục phân nhóm tối thiểu:

Procedure domain — miền quy trình:
- system
- business
- data
- dot
- collection
- schema
- label
- io_contract
- trigger
- checker
- report
- approval
Procedure intent — mục đích:
- create
- update
- inspect
- validate
- classify
- promote
- rollback
- delete
- run
- report
- troubleshoot
Procedure maturity — mức trưởng thành:
- known
- text_ready
- machine_readable
- checklist_ready
- dot_sequence_ready
- one_button_candidate
- one_button_ready
Automation mode — mức chạy:
- manual_note
- checklist
- guided_agent
- dot_sequence
- entry_dot
- scheduled
- event_triggered
Safety class — mức rủi ro:
- read_only
- dry_run
- staging_write
- production_write
- destructive
- owner_gated
Business/system boundary:
- system_procedure
- business_procedure
- mixed

Phân nhóm phải phục vụ tìm kiếm và treeview, không biến thành governance monster.

7. Yêu cầu liên nhóm / M2M

Một quy trình thường không thuộc duy nhất một nhóm và không dùng duy nhất một nguyên liệu. Do đó cần hỗ trợ quan hệ nhiều-nhiều ở mức đơn giản.

Các quan hệ cần biểu diễn được:

Một quy trình thuộc nhiều nhóm.
Một quy trình gồm nhiều bước.
Một bước dùng nhiều nguyên liệu.
Một nguyên liệu được dùng bởi nhiều quy trình.
Một quy trình gọi nhiều quy trình con.
Một quy trình có thể là fallback khi nguyên liệu thiếu.
Một DOT có thể là entry point của nhiều quy trình.
Một collection có thể được đọc/ghi bởi nhiều quy trình.
Một trigger có thể kích hoạt nhiều quy trình.
Một label/schema/field có thể là yêu cầu của nhiều quy trình business.

Mục tiêu không phải xây graph lớn ngay. Mục tiêu là đủ để trả lời nhanh:

Cái này đang được quy trình nào dùng?
Quy trình này cần cái gì?
Thiếu cái này thì ảnh hưởng quy trình nào?
Muốn thêm cái này thì gọi quy trình nào?

8. Yêu cầu treeview trên Nuxt

Mục tiêu dài hạn là tự động hóa tối đa. Tuy nhiên con người vẫn cần một màn hình xem nhanh.

Nuxt treeview chỉ cần rất mỏng:

Hiển thị cây nhóm quy trình.
Mỗi node có tên, status, maturity, automation mode, safety class.
Mở một quy trình thấy note ngắn và danh sách bước.
Mở một bước thấy nguyên liệu liên quan.
Hiển thị thiếu/đủ bằng trạng thái đơn giản.
Cho phép nhìn nhanh quy trình nào đã checklist-ready, quy trình nào còn thiếu DOT/collection/label/IO.

Treeview không phải nơi quyết định governance. Treeview chỉ là cửa sổ đọc từ PG/views.

Treeview tối thiểu:

Procedure Domain
└── Procedure Group
    └── Procedure
        ├── Steps
        ├── Ingredients
        ├── Missing items
        └── Related sub-procedures

9. PG-first / PG-native / PG-driven

Hướng này phải khai thác tối đa PostgreSQL.

Nguyên tắc:

PG đọc từ PG để hiểu PG đang có gì.
Tận dụng bảng, view, jsonb, constraint, join, generated views, materialized view nếu cần.
Chỉ làm thêm tối thiểu.
Không xây một con quái vật mới.
Không phụ thuộc vào việc governance/birth/KG/registries-pivot hoàn chỉnh mới dùng được.
Không yêu cầu hệ thống sạch mới ghi nhận quy trình.
Không nhân đôi nguồn sự thật nếu nguồn đã có trong PG.
Những gì chưa biết thì ghi UNKNOWN/NEEDS_TRIAGE, không dừng.

PG phải giúp Agent trả lời nhanh:

Quy trình nào phù hợp với nhiệm vụ này?
Quy trình này cần nguyên liệu gì?
Nguyên liệu này đã có trong PG chưa?
Nếu thiếu thì quy trình bổ sung là gì?
Quy trình này đang ở mức tự động nào?
Có thể gom các bước thành một entry DOT không?

10. Tuân thủ triết lý LEGO của `laws-new/`

Hướng quản lý quy trình phải đi theo LEGO:

Việc lớn tách thành quy trình nhỏ.
Quy trình lớn gọi quy trình con.
Quy trình dùng nguyên liệu qua contract/manifest, không qua trí nhớ thủ công.
Thiếu nguyên liệu thì tạo/bổ sung bằng quy trình riêng.
Mỗi phần có input/output rõ.
Sai thì biết thiếu ở đâu, không khảo sát lại toàn hệ.
Nâng cấp tự động hóa theo từng mức, không đòi one-button ngay từ đầu.

Không được đi ngược LEGO bằng cách xây một bộ máy trung tâm quá nặng, đòi mọi thứ hoàn hảo trước khi dùng được.

11. Non-goals giai đoạn đầu

Giai đoạn đầu không làm các việc sau:

Không xây governance registry mới.
Không thay registries-pivot.
Không xây knowledge graph.
Không yêu cầu khai sinh hoàn chỉnh cho mọi đối tượng.
Không yêu cầu owner/gate hoàn chỉnh cho mọi quy trình.
Không auto-fix.
Không bắt mọi quy trình phải one-button ngay.
Không đòi schema hoàn hảo mới ghi quy trình.
Không tạo thêm hệ thống lớn nếu PG/view/JSONB đã đủ giải quyết.

Giai đoạn đầu chỉ cần:

Ghi được quy trình.
Máy đọc được manifest.
Máy bóc được nguyên liệu.
Máy so được đủ/thiếu với PG.
Máy chỉ được quy trình xử lý khi thiếu.
Con người xem được treeview và note ngắn trên Nuxt.

12. Kết quả mong muốn

Khi Agent nhận nhiệm vụ, ví dụ:

“Tạo một DOT mới.”

Agent phải có thể hỏi hệ thống và nhận được câu trả lời kiểu:

Quy trình: PROC_CREATE_NEW_DOT
Maturity: checklist_ready
Automation mode: checklist
Safety class: owner_gated nếu runtime registration

Bước chính:
1. Kiểm tra DOT đã tồn tại chưa.
2. Soạn DOT spec.
3. Soạn IO contract.
4. Soạn validator/bad-input matrix.
5. Ghi admission record.
6. Cập nhật handbook/report.
7. Nếu muốn runtime registration thì cần Owner gate.

Đủ:
- Có nguồn kiểm DOT hiện có.
- Có nơi lưu DOT handbook.

Thiếu/chưa mở:
- Runtime registration chưa mở.
- One-button entry DOT chưa có.

Nếu thiếu DOT hỗ trợ:
- Gọi PROC_CREATE_NEW_DOT.

Nếu thiếu IO contract:
- Gọi PROC_CREATE_IO_CONTRACT.

Khi Agent nhận nhiệm vụ business, ví dụ:

“Thiết kế quy trình xử lý hồ sơ A.”

Agent phải biết:

Đã có quy trình business tương tự chưa.
Cần form fields nào.
Cần actor nào.
Cần trigger nào.
Cần collection nào để lưu hồ sơ.
Cần label/schema nào để phân loại.
Cái gì đã có trong PG.
Cái gì thiếu.
Thiếu thì gọi quy trình bổ sung nào.

13. Câu chốt định hướng

Mục tiêu không phải xây thêm một hệ thống quản trị phức tạp. Mục tiêu là làm cho PG, bằng chính năng lực PG-first / PG-native / PG-driven, trở thành nơi giúp Agent biết nhanh: quy trình nào đã có, quy trình cần nguyên liệu gì, PG đã có gì, còn thiếu gì, thiếu thì gọi gì, và khi nào có thể nâng cấp thành một nút chạy tự động.

Đây là nền cho workflow-manage/.

Đề bài quản lý quy trình — PG-native Procedure Intelligence

1. Nỗi đau gốc

2. Đầu bài cốt lõi

3. Bốn điểm mù cần giải quyết

3.1. Mù tồn tại

3.2. Mù nguyên liệu

3.3. Mù đủ/thiếu

3.4. Mù lắp ráp

4. Quy trình là đơn vị lắp ráp

5. Hai lớp mô tả của quy trình

5.1. Lớp text cho người đọc

5.2. Lớp manifest cho máy đọc

6. Yêu cầu phân nhóm

7. Yêu cầu liên nhóm / M2M

8. Yêu cầu treeview trên Nuxt

9. PG-first / PG-native / PG-driven

10. Tuân thủ triết lý LEGO của laws-new/

11. Non-goals giai đoạn đầu

12. Kết quả mong muốn

13. Câu chốt định hướng

10. Tuân thủ triết lý LEGO của `laws-new/`