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

Path: knowledge/dev/laws-new/workflow-manage/de-bai-quan-ly-quy-trinh.md
Status: Đề bài / Problem Statement / Non-authorizing
Revision: v0.8 — khóa tinh thần PG đọc PG, sự thật phải do PG soi PG, và lớp con mắt phải chạy nhẹ: index hóa thực tế, phân nhóm theo cái đã có, lời khai chỉ là cache/gợi ý, ref grammar là khóa sống/chết của Readiness View, readiness phải được PG/SQL xác nhận, vector/RAG chỉ hỗ trợ tìm gần đúng, inventory/readiness phải có chiến lược cache/refresh để không gây tải hệ thống
Scope: Quy trình vận hành hệ thống và quy trình business theo hướng PG-first / PG-native / PG-driven
Không phải: workflow engine, governance registry, registries-pivot, knowledge graph, DOT runtime, authorization layer, auto-fix system, hoặc thiết kế DDL cuối cùng.

0. Một câu chốt

PG đọc PG.

Nói đầy đủ hơn:

PG đang 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 index cực mỏng để biết PG có gì, quy trình nào dùng cái gì, thiếu gì, và nên gọi gì tiếp theo.

Nỗi đau gốc:

PG có dữ liệu, nhưng Agent vẫn mù quy trình.

Vì vậy, việc cần làm không phải xây thêm một hệ quản trị lớn, mà là tạo một lớp PG-native Procedure Index cực mỏng để PG tự đọc lại PG.

Có thể hiểu lớp này là con mắt, không phải bàn tay:

Con mắt: nhìn thấy, index hóa, soi đủ/thiếu, chỉ route tiếp theo.
Bàn tay: chạy workflow, cấp quyền, sửa schema, register DOT, mutate hệ thống.

Pha đầu chỉ làm con mắt.

0.1. Nguyên tắc sự thật: PG soi PG

Nguyên tắc lõi của workflow-manage/:

Sự thật vận hành phải đến từ PG soi PG. Lời khai chỉ là cache/gợi ý.

Nói rõ hơn:

PG observed fact      — sự thật mạnh nhất: PG/catalog/table/view tự soi ra.
PG computed view      — sự thật suy ra bằng SQL từ PG observed fact, ví dụ Inventory View / Readiness View.
Human/Agent declaration — lời khai: manifest, note, Ingredient Map, declared_maturity.
RAG/vector/fuzzy suggestion — gợi ý tìm kiếm gần đúng, không phải bằng chứng đủ/thiếu.

Quy tắc bắt buộc:

Inventory View và Readiness View mới là nơi xác nhận exists / missing / unknown_source / computed_readiness.
Ingredient Map, manifest_jsonb, note, report, tài liệu, hoặc lời nhớ của Agent chỉ được coi là gợi ý để PG biết cần soi cái gì.
declared_maturity chỉ là lời khai; nếu PG tính ra khác thì phải báo READINESS_DRIFT.
RAG/vector/fuzzy search chỉ được gợi ý candidate procedure hoặc khả năng trùng nghĩa; không được xác nhận nguyên liệu đã có hay quy trình đã ready.
Nếu PG không soi ra được thì trạng thái đúng là MISSING, UNKNOWN_SOURCE, UNMAPPED hoặc NOT_VERIFIED; không được suy diễn là đã có.

Câu giữ hướng:

PG là sự thật. Index là con mắt. Lời khai là gợi ý. Readiness là kết quả PG soi PG.

Nguyên tắc này nhằm chặn lỗi cũ: tài liệu nói đã xong, Agent nhớ là đã có, report nói pass, nhưng PG/runtime thực tế không khớp.

1. Đầu bài đúng

Xây một lớp rất mỏng trên PostgreSQL để trả lời nhanh 5 câu hỏi:

Việc X đã có quy trình 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ì hoặc chưa biết nguồn kiểm tra?
Thiếu thì gọi quy trình bổ sung nào / gọi gì tiếp theo?

Chỉ 5 câu này là lõi.

Nếu một thiết kế không giúp trả lời 5 câu này nhanh hơn thì không thuộc pha đầu.

2. Tên đúng của lớp pha đầu

Tên đúng cho pha đầu:

PG-native Procedure Index

Không gọi là:

Hệ quản trị quy trình.
Workflow engine.
Registry mesh.
Knowledge graph.
DOT runtime.
Governance layer.

Nó chỉ gồm 4 ý niệm:

Procedure Index     — ghi quy trình đã biết.
Ingredient Map      — khai quy trình cần nguyên liệu gì.
Inventory View      — PG tự soi PG để biết nguyên liệu có tồn tại không.
Readiness View      — PG trả lời quy trình đủ/thiếu gì và gọi gì tiếp theo.

Bốn ý niệm này là chức năng tối thiểu, không phải lời mời xây hệ lớn. Nếu prototype đầu tiên làm được bằng ít hơn 3 bảng thì chọn cách ít hơn. 3 bảng + vài view chỉ là trần tối đa pha đầu, không phải chỉ tiêu phải xây đủ.

3. Lớp này chỉ làm 5 việc

Pha đầu chỉ được làm 5 việc:

1. Ghi quy trình đã biết.
2. Khai quy trình cần nguyên liệu gì.
3. PG tự soi xem nguyên liệu đó đã có chưa.
4. Nếu thiếu thì chỉ ra quy trình bổ sung / route tiếp theo.
5. Cho Agent đọc một câu trả lời nhanh: có gì, thiếu gì, gọi gì tiếp.

Không hơn.

Đặc biệt:

Không chạy workflow.
Không tự cấp quyền.
Không tự register DOT.
Không tự sửa schema.
Không tự tạo collection.
Không thay DOT.
Không thay registry.
Không thay KG.
Không quyết định governance.

4. Nỗi đau thực tế

Hệ thống hiện có rất nhiều nguyên liệu nằm trong PG hoặc có thể đọc từ PG:

DOT.
Collection/table/view.
Schema/field.
Label/tag/category.
IO contract.
Trigger/event.
Checker/validator.
Workflow/procedure.
Form/business field.
Actor/role.
Rule/gate.
Report/evidence.
Approval/action type.
Các đối tượng nghiệp vụ business.

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 thường không biết nhanh:

Quy trình tương ứng đã có chưa.
Nếu có thì nằm ở đâu.
Phải gọi thế nào.
Quy trình gồm bao nhiêu bước.
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 thiếu.
Thiếu thì gọi quy trình nào.
Có quy trình con/tầng cao hơn để tái dùng không.
Có đang lắp trùng từ tầng quá thấp không.
Việc này hiện chỉ là note, checklist, chuỗi DOT, hay đã có một nút tự động.

Kết quả là mỗi việc nhỏ dễ biến thành khảo sát lớn, mất thời gian, dễ làm trùng, dễ bỏ sót, và làm Agent phải đọc quá nhiều thông tin không cần thiết.

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

5.1. Mù tồn tại

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

Yêu cầu tối thiểu:

Tra được quy trình theo việc cần làm.
Tra được theo procedure code, từ khóa, group, tầng, domain, trigger, input/output nếu các metadata đó đã có trong PG.
Biết trạng thái khai báo ban đầu của quy trình: known, text_ready, machine_readable, checklist_ready, dot_sequence_ready, one_button_ready.
Trạng thái khai báo không được coi là sự thật cuối cùng; readiness phải được PG tính lại nếu có ingredient.

5.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.

Yêu cầu tối thiểu:

Quy trình khai được danh sách nguyên liệu cần dùng.
Khai theo từng bước nếu có thể.
Lớp text chỉ để người/Agent đọc nhanh.
Lớp machine-readable/JSONB chỉ để ghi nhanh và bóc tách; không phải chuẩn luật mới.
Ingredient Map là cache/gợi ý để PG kiểm, không phải nguồn sự thật cuối cùng.

5.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.

Yêu cầu tối thiểu:

PG phải tự đọc từ PG để kiểm tra hiện trạng.
DOT thì soi vào nguồn DOT hiện có.
Collection/table/view thì soi vào catalog/schema metadata/Directus metadata hoặc registry hiện có nếu có.
Field/schema thì soi vào metadata/schema hiện có.
Label/tag/category thì soi vào bảng nhãn/tag hiện có nếu có.
Trigger/event thì soi vào metadata tương ứng nếu có.
IO/checker/report/evidence thì soi vào nơi lưu tương ứng nếu đã có.
Nếu chưa biết nguồn kiểm tra thì ghi UNKNOWN_SOURCE, không dừ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 ngay trên hệ thống hiện tại, để PG chỉ ra cái gì có, cái gì thiếu, cái gì chưa biết cách kiểm.

5.4. Mù lắp ráp

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

Gọi một quy trình đã có.
Gọi quy trình con.
Dùng một nguyên liệu tầng cao hơn đã có.
Lắp quy trình mới từ nguyên liệu thấp hơn.
Tạo nguyên liệu thiếu trước rồi quay lại.
Đề xuất đóng gói thành one-button DOT.

Yêu cầu tối thiểu:

Quy trình có thể link tới quy trình con.
Nguyên liệu thiếu có thể trỏ tới quy trình bổ sung.
PG có thể chỉ ra: “đã có quy trình/nguyên liệu tương tự, đừng lắp lại từ đầu”.
Không cần graph engine; quan hệ M2M đơn giản là đủ cho pha đầu.

6. LEGO và 6 tầng: chỉ đọc/index hóa cái đã có trong PG

Triết lý laws-new/ có 6 tầng lắp ráp:

Nguyên tử → Phân tử → Hợp chất → Vật liệu → Thành phẩm → Hệ con/Công trình

Nhưng trong workflow-manage/, 6 tầng không phải là việc của Procedure Index phải tự thiết kế lại.

Cách hiểu đúng:

Việc phân tầng là của mô hình LEGO và các dữ liệu/metadata đang có trong PG. Procedure Index chỉ đọc ra, index hóa và sắp xếp lại để Agent hiểu nhanh. Nếu PG chưa có metadata tầng/group thì ghi UNKNOWN/UNMAPPED, không tạo thêm phân tầng mới ở pha đầu.

Pha đầu chỉ cần:

đọc tầng nếu có;
đọc group nếu có;
thiếu thì ghi UNKNOWN/UNMAPPED;
sắp xếp lại cho Agent dễ tra;
không dừng vì thiếu phân tầng.

Điểm LEGO cần giữ duy nhất ở pha đầu:

Khi có nhiều cách lắp, ưu tiên tái dùng mảnh ở tầng cao nhất phù hợp; không lắp lại từ nguyên tử nếu PG đã cho thấy có phân tử/hợp chất/vật liệu/quy trình con có thể tái dùng.

Nhưng đây là nguyên tắc gợi ý/tìm kiếm, không phải enforcement engine.

7. Bài toán scale thật

Thiết kế phải giả định tương lai có thể có:

Khoảng 20.000 quy trình.
Nhiều chục triệu nguyên liệu khác nhau.
Quy trình hệ thống và quy trình business cùng tồn tại.
Quy trình lớn gọi quy trình nhỏ.
Nguyên liệu được tái dùng qua nhiều miền.

Nhưng cách triển khai pha đầu không được cố giải quyết toàn bộ scale bằng cách copy mọi object vào bảng mới.

Nguyên tắc sống còn:

Không đưa hàng chục triệu object vào một bảng all_objects mới.

Thay vào đó:

Dùng view để đọc inventory hiện có từ PG.
Chỉ materialize/cache summary khi thật sự cần.
Không nhân đôi nguồn thật.
Procedure Index chỉ lưu quy trình và nguyên liệu mà quy trình khai là cần.
Inventory View chỉ là “mặt kính” để nhìn vào PG, không phải registry thay thế.

8. Treeview cho người đọc/Agent: chỉ là cửa nhìn, không phải hệ mới

Người là phụ; Agent/AI đọc nhanh là chính. Treeview trên Nuxt chỉ là cửa nhìn giúp con người kiểm tra, định hướng, và vận hành khi cần.

Treeview không được biến thành UI phức tạp.

Treeview tối thiểu cần 4 thứ:

Tầng/Group — đọc từ metadata/PG nếu có; thiếu thì UNKNOWN/UNMAPPED.
Cây điều hướng ma trận — ưu tiên nhìn theo assembly_layer × domain_group.
Note mô tả ngắn — người/Agent đọc nhanh biết quy trình dùng để làm gì.
Trạng thái đủ/thiếu/tự động hóa — biết quy trình đang dùng được tới đâu.

Cấu trúc đọc tối thiểu:

Assembly Layer
└── Domain / Group
    └── Procedure
        ├── Short note
        ├── Declared maturity / Computed readiness
        ├── Required ingredients
        ├── Missing items
        └── Next route / sub-procedure

Nuxt chỉ đọc từ PG/views. Nuxt không quyết định governance, không mutate, không trở thành nguồn sự thật mới.

9. Ranh giới triển khai mỏng nhất

Pha đầu nên bị ép vào ranh giới tối đa:

3 bảng + vài view

Đây không phải DDL cuối cùng và không phải chỉ tiêu phải xây đủ. Đây là trần tối đa để chống phình. Nếu prototype đầu tiên chỉ cần 1 bảng seed + vài view đọc PG mà trả lời được 5 câu lõi thì phải chọn cách ít hơn.

9.1. Procedure Index

Một dòng = một quy trình đã biết.

Ý niệm cột tối thiểu:

procedure_code
name/title
short_note
assembly_layer
domain_group
intent
declared_maturity
automation_mode
safety_class
status
manifest_jsonb
source_ref
updated_at

Trả lời: “Quy trình này là gì, dùng khi nào, thuộc đâu, đang ở mức nào?”

9.2. Ingredient Map

Một dòng = một nguyên liệu mà quy trình cần.

Ý niệm cột tối thiểu:

procedure_code
step_code
ingredient_kind
ingredient_ref
usage_role
required_level
source_probe_kind
missing_route_procedure_code
note

Trả lời: “Quy trình này cần cái gì?”

Ingredient Map phải được hiểu đúng:

Đây là cache/gợi ý do người/Agent khai, không phải nguồn sự thật cuối cùng.
Không khai ingredient cho mọi quy trình ngay từ đầu.
Chỉ khai cho quy trình đau nhất, quy trình đang được gọi tới, hoặc quy trình cần readiness thật.
Thiếu thì để UNKNOWN / NEEDS_TRIAGE, không bịa đủ.

9.3. Procedure Link

Một dòng = một quan hệ giữa quy trình với quy trình khác.

Ý niệm cột tối thiểu:

from_procedure_code
to_procedure_code
link_type
note

Ví dụ link type:

calls_subprocedure
fallback_when_missing
successor
supersedes
related
reuse_candidate

Trả lời: “Quy trình này gọi, thay thế, liên quan, hoặc fallback sang quy trình nào?”

9.4. Inventory View

Đây là trái tim của “PG đọc PG”.

Inventory View không lưu lại mọi object làm registry mới. Nó chỉ gom/chuẩn hóa từ nguồn PG hiện có thành format chung:

object_kind
object_ref
source_schema
source_table
exists_bool
metadata_jsonb
last_seen_at

Nguồn có thể đọc tùy hệ thống đang có:

dot_tools
DOT/API contract tables nếu có
PG catalog/schema metadata
Directus metadata nếu có
approval/action/gate tables nếu có
label/tag/rule/checker tables nếu có
event metadata nếu có

Nếu nguồn nào chưa rõ thì để UNKNOWN_SOURCE, không dừng.

9.5. Readiness View

Readiness View join:

Ingredient Map × Inventory View

Để trả lời:

quy trình cần gì;
cái nào exists;
cái nào missing;
cái nào unknown_source;
thiếu thì route sang quy trình nào;
computed_readiness là gì;
có drift giữa declared_maturity và computed_readiness không.

Đây là view quan trọng nhất để Agent không phải khảo sát 30 phút cho một việc nhỏ.

10. Ref grammar: việc thiết kế duy nhất phải làm kỹ trước implementation

Readiness View sống hay chết ở chỗ join đúng giữa Ingredient Map và Inventory View. Nếu hai bên gọi tên nguyên liệu khác nhau, PG sẽ báo thiếu giả.

Vì vậy, trước mọi implementation thật phải có một trang văn phạm ref tối thiểu theo object_kind.

Ví dụ định hướng:

dot:DOT_CODE
collection:schema.table
field:schema.table.column
view:schema.view
trigger:schema.table.trigger_name
label:LABEL_CODE
procedure:PROC_CODE
io:IO_CONTRACT_CODE
checker:CHECKER_CODE
approval:ACTION_OR_GATE_CODE

Quy tắc:

Ingredient Map.ingredient_ref và Inventory View.object_ref phải nói cùng một văn phạm.
Nếu không chuẩn hóa được ref thì để UNKNOWN_SOURCE, không join ẩu.
Văn phạm ref là quy ước đặt tên tối thiểu để PG đọc PG, không phải registry mới.
Ref grammar là phần đáng thiết kế kỹ nhất vì nó quyết định readiness có đáng tin hay không.

11. Manifest phải nhẹ

Mỗi quy trình có thể có manifest_jsonb, nhưng manifest không được biến thành luật đồ sộ.

Pha đầu chỉ cần cấu trúc rất ngắn:

{
  "procedure_code": "PROC_CREATE_NEW_DOT",
  "title": "Create new DOT",
  "steps": [
    {
      "step_code": "reuse_first",
      "needs": [
        {"kind": "procedure", "ref": "procedure:PROC_REUSE_FIRST_SEARCH"}
      ]
    },
    {
      "step_code": "draft_spec",
      "needs": [
        {"kind": "template", "ref": "template:dot_spec_template"},
        {"kind": "collection", "ref": "collection:public.dot_tools"}
      ]
    }
  ]
}

Quy tắc:

JSONB chỉ là note có cấu trúc để người/Agent ghi nhanh, không phải chuẩn luật mới.
Ingredient Map là phần đã bóc tách để PG join nhanh.
Không bắt manifest hoàn hảo mới được ghi quy trình.
UNKNOWN, NEEDS_TRIAGE, DOC_ONLY, CHECKLIST_ONLY đều được phép.

12. Maturity/readiness: không được chỉ là lời khai tay

Các trạng thái như checklist_ready, dot_sequence_ready, one_button_ready không được chỉ dựa vào người khai.

Quy tắc:

Có thể lưu declared_maturity như lời khai ban đầu.
computed_readiness phải được suy ra từ Readiness View.
Nếu declared và computed mâu thuẫn, phải hiện cảnh báo READINESS_DRIFT.
Một quy trình không được coi là ready chỉ vì note nói ready; PG phải soi ingredient cần thiết có tồn tại hay không.

13. RAG/vector/fuzzy search: không dùng để trả lời đúng/sai

Có hai loại câu hỏi khác nhau:

Loại câu hỏi	Ví dụ	Công cụ đúng
Chính xác / có-không	Quy trình X có tồn tại không? Nguyên liệu Y có trong PG không? Thiếu gì?	SQL / Readiness View
Mờ / khám phá	Tôi muốn làm việc mô tả bằng lời, có quy trình nào gần giống không? Có gì để tránh lắp trùng không?	Fuzzy search / vector / RAG

Pha đầu không cần vector/RAG. Với 30–50 quy trình đầu, dùng tìm kiếm chữ trong PG là đủ. Nếu cần fuzzy nhẹ, ưu tiên giải pháp nằm trong PG để giữ đúng tinh thần PG đọc PG.

Nếu sau này số quy trình tăng lớn và cần tìm theo nghĩa, vector/RAG chỉ được dùng theo mô hình hai bước:

Bước 1 — fuzzy/vector/RAG gợi ý candidate procedure_code.
Bước 2 — SQL/Readiness View xác nhận exists/missing/route.

Vector/RAG tuyệt đối không được trả lời câu đủ/thiếu cuối cùng. Nó chỉ là radar chống trùng và cửa tìm kiếm mờ; sổ cái sự thật vẫn là PG.

14. Phạm vi business procedure

Hệ này không chỉ phục vụ quy trình kỹ thuật.

Business procedure cũng có bản chất giống nhau:

Trigger là gì?
Ai làm?
Cần điền field nào?
Đọc/ghi collection nào?
Cần label/schema nào?
Cần rule/checker nào?
Gọi procedure con nào?
Đầu ra là gì?
Pass/fail bằng gì?
Thiếu gì thì gọi quy trình nào?

Do đó, Procedure Index phải đủ rộng để chứa cả:

system procedure
business procedure
data procedure
DOT procedure
collection/schema procedure
label procedure
IO/checker procedure
approval/gate procedure
report/evidence procedure

Nhưng pha đầu vẫn giữ cùng một mô hình mỏng: procedure + ingredient + link + view.

15. Nguyên tắc PG-first / PG-native / PG-driven

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

PG đọc PG.
Dùng bảng tối thiểu.
Dùng view để soi inventory hiện có.
Dùng JSONB để ghi nhanh manifest.
Dùng join để kiểm đủ/thiếu.
Dùng materialized view/cache chỉ khi view thường không đủ nhanh.
Không copy nguồn thật nếu đã có trong PG.
Không phụ thuộ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 bắt đầu.
Thiếu nguồn kiểm thì ghi UNKNOWN_SOURCE, không dừng.

Câu giữ hướng:

PG không cần biết mọi thứ theo nghĩa governance; PG chỉ cần đủ biết để trả lời: quy trình này cần gì, PG đã có gì, thiếu gì, gọi gì tiếp.

15.1. Nguyên tắc hiệu năng: con mắt phải nhẹ

PG đọc PG không có nghĩa là Agent được phép quét sâu toàn bộ catalog/schema/metadata mỗi lần hỏi. Lớp này phải là con mắt nhẹ, không được trở thành tải nền mới cho hệ thống.

Nguyên tắc vận hành pha đầu:

đọc hẹp theo procedure_code / object_ref;
ưu tiên view/cache summary;
quét thưa, không quét dày;
force refresh chỉ khi có yêu cầu rõ;
event-driven chỉ dùng khi nguồn PG đã có sẵn tín hiệu thay đổi;
không xây scheduler/engine mới nếu chưa cần.

Chiến lược tối thiểu:

Realtime hẹp: tra procedure/readiness theo một procedure_code hoặc một nhóm nhỏ trước; không bắt đầu bằng query toàn hệ.
Cache/materialized view khi cần: nếu Inventory View hoặc Readiness View chậm, dùng materialized view/cache summary với last_seen_at và refresh_mode.
Refresh thưa: inventory tổng hợp có thể chấp nhận trễ vài phút hoặc lâu hơn tùy loại nguyên liệu; không cần realtime tuyệt đối cho mọi thứ.
Event-driven là nâng cấp nhẹ nếu đã có sẵn: nếu một collection/source đã có trigger/event/change log thì có thể dùng để đánh dấu dirty hoặc refresh phần liên quan; không tạo bus/scheduler lớn riêng ở pha đầu.
Hybrid hợp lý: dùng refresh thưa cho catalog ít đổi; dùng event/dirty flag cho nguồn thay đổi thường xuyên; dùng force refresh cho tình huống Agent cần kiểm tra trước khi thao tác nhạy cảm.
Không copy hàng chục triệu object: chỉ cache summary/index cần thiết cho readiness; nguồn thật vẫn nằm ở PG/source gốc.

Trạng thái gợi ý cho nguồn inventory:

fresh
stale_but_acceptable
refresh_required
unknown_source

Quy tắc an toàn:

Nếu cache stale nhưng chấp nhận được thì trả stale_but_acceptable kèm last_seen_at.
Nếu thao tác nhạy cảm cần sự thật mới hơn thì yêu cầu force_refresh hoặc trả refresh_required.
Nếu không biết nguồn kiểm tra thì trả unknown_source, không quét mò toàn hệ.
Tần suất refresh không được hardcode trong đề bài; thiết kế chi tiết phải chọn theo từng source và chi phí thực tế.

Mục tiêu: Agent đọc nhanh trong vài giây cho câu hỏi hẹp, còn hệ thống không bị buộc phải quét toàn PG cho mỗi nhiệm vụ nhỏ.

16. Non-goals bắt buộc

Pha đầu không làm:

Không xây workflow engine.
Không xây governance registry mới.
Không thay registries-pivot.
Không xây knowledge graph.
Không xây all_objects registry hàng chục triệu dòng.
Không tự mutate hệ thống.
Không tự register DOT.
Không tự tạo collection/schema.
Không tự cấp quyền.
Không auto-fix.
Không bắt one-button ngay.
Không bắt mọi quy trình phân loại hoàn hảo mới ghi nhận.
Không yêu cầu birth/governance/owner gate hoàn chỉnh để Procedure Index hoạt động.
Không quản lý thay mô hình 6 tầng LEGO; chỉ đọc tầng/group từ PG nếu có.
Không bắt con người đọc/duyệt hết; Agent/AI đọc nhanh là mục tiêu chính, Nuxt treeview chỉ hỗ trợ quan sát.
Không để vector/RAG trả lời câu đúng/sai về existence/readiness.
Không quét toàn bộ PG/catalog/schema cho mỗi câu hỏi nhỏ.
Không tạo scheduler/event bus/refresh engine mới nếu view/cache/refresh thưa đã đủ.
Không yêu cầu realtime tuyệt đối cho mọi loại inventory; mỗi source phải có mức freshness phù hợp chi phí.

Pha đầu chỉ là:

procedure memory + ingredient map + inventory view + readiness view + next-route suggestion

17. Kết quả mong muốn cho Agent

Khi Agent hỏi:

Muốn làm việc X, có quy trình chưa?

Hệ thống trả nhanh:

Procedure: PROC_X
Layer/Group: ...
Declared maturity: ...
Computed readiness: ...
Automation: ...
Safety: ...

Required ingredients:
- A: exists
- B: missing
- C: unknown_source

Next route:
- Missing B → call PROC_CREATE_OR_FIX_B
- Unknown C → call PROC_TRIAGE_SOURCE_FOR_C

Do not duplicate:
- Similar/reusable procedure: PROC_Y
- Higher-layer reusable component: PROC_Z

Khi quy trình chưa có, hệ thống trả:

No known procedure found.
Possible related procedures: ...
Suggested next route: PROC_CREATE_PROCEDURE_INDEX_ENTRY

Khi nguyên liệu thiếu, hệ thống không tự sửa, chỉ định tuyến:

Missing ingredient: DOT_X
Route: PROC_CREATE_NEW_DOT
Safety: owner_gated if runtime registration is required

18. Tiêu chí thành công pha đầu

Pha đầu thành công nếu đạt được các việc sau:

Có thể seed 30–50 quy trình đau nhất vào Procedure Index.
Mỗi quy trình có note ngắn và ingredient map tối thiểu, theo kiểu khai lười.
Có ref grammar v0.1 để Ingredient Map và Inventory View join cùng ngôn ngữ.
PG soi được một số nguồn inventory có sẵn: DOT, collection/table/view, field/schema, Directus metadata, approval/action/gate nếu có.
Readiness View trả được exists / missing / unknown_source cho từng ingredient.
Readiness View tính được computed_readiness và báo READINESS_DRIFT nếu trái với declared maturity.
Agent hỏi một procedure cụ thể và nhận được câu trả lời trong vài giây, không phải khảo sát lại toàn hệ.
Nuxt treeview đọc được procedure theo assembly_layer × domain_group nếu đã có dữ liệu; treeview là cửa nhìn phụ, không phải điều kiện để lõi PG đọc PG hoạt động.
Không phụ thuộc vào việc hoàn thiện governance/birth/KG/registries-pivot.
Không tạo quái vật mới.
6 tầng/group chỉ được dùng như metadata đọc từ PG; nếu PG chưa có thì để UNKNOWN/UNMAPPED, không ghi tạm metadata phân tầng mới ở pha đầu, và không trở thành blocker.
Vector/RAG chưa cần ở pha đầu; nếu dùng sau này thì chỉ dùng để gợi ý candidate, không dùng để xác nhận readiness.
Thiết kế có chiến lược hiệu năng tối thiểu: query hẹp theo procedure/object, có last_seen_at, có trạng thái freshness, và không quét toàn PG cho mỗi câu hỏi.
Nếu Inventory/Readiness chậm thì dùng cache/materialized view/refresh thưa trước; event-driven chỉ dùng khi nguồn PG đã có sẵn trigger/event/change log phù hợp.

19. Câu định hướng cuối cùng

Không xây thêm một hệ quản trị quy trình. Chỉ xây một PG-native Procedure Index cực mỏng để PG đọc PG: biết 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ì tiếp, và có gì tái dùng để tránh lắp trùng.

6 tầng, group, domain, DOT, collection, trigger, IO contract, schema, label đều là dữ liệu/nguyên liệu nằm trong PG. Procedure Index không quản lý thay chúng; nó chỉ index hóa thực tế và sắp xếp lại để AI/Agent đọc được nhanh.

Ingredient Map là cache khai lười; ref grammar là khóa join; Readiness View là nơi xác nhận; vector/RAG nếu có chỉ là cửa tìm gần đúng; Inventory/Readiness phải đọc hẹp, cache hợp lý, refresh thưa hoặc theo thay đổi nếu có sẵn tín hiệu.

Đây là nền của workflow-manage/.