HIẾN PHÁP KIẾN TRÚC HỆ THỐNG INCOMEX

(Architecture Constitution — Văn bản tối cao về thiết kế hệ thống)

Hiến pháp v3.9 | Ban hành: S105, mở rộng S106-S141 | 34 Điều Luật (Điều 0-24 + 0-B + 0-G + 0-S + 0-M + 0-L + 26-31) | +Điều 26 MỚI v3.5 BAN HÀNH (S141, Pivot Table, gộp Điều 32). +Điều 0-S/0-M/0-L (S132). +Điều 31 BAN HÀNH v1.2 (S131) VĂN BẢN NÀY CÓ HIỆU LỰC TỐI CAO TRONG MỌI QUYẾT ĐỊNH THIẾT KẾ. Mọi AI, Agent, Script, và Con người làm việc trên hệ thống Incomex PHẢI tuân thủ. Vi phạm Hiến pháp = vi phạm nghiêm trọng nhất. Không có ngoại lệ, không có "trường hợp đặc biệt". Khi có mâu thuẫn giữa Hiến pháp này và bất kỳ tài liệu nào khác → Hiến pháp thắng. search_knowledge("hiến pháp kiến trúc architecture constitution")

LỜI MỞ ĐẦU

Hệ thống Incomex tồn tại để phục vụ CON NGƯỜI — cụ thể là các quy trình nghiệp vụ thực tế (Tầng 4). Mọi tầng khác trong kiến trúc tồn tại ĐỂ PHỤC VỤ mục đích đó.

NỀN TẢNG CƠ BẢN NHẤT: NGUYÊN TỬ THÔNG TIN (Điều 0). Giống thế giới vật lý xây VÔ VÀN vật thể phức tạp từ ~118 loại nguyên tử, hệ thống Incomex xây mọi workflow phức tạp từ Nguyên tử Thông tin — đơn vị nhỏ nhất có ID, có metadata, có quan hệ, có "DB về chính nó". Hiểu nguyên tử → hiểu mọi thứ. Không hiểu → mọi thứ phía trên là đoán mò. Đọc Điều 0 TRƯỚC mọi Điều khác.

MỤC TIÊU TỐI THƯỢNG: TỰ ĐỘNG HOÁ HOÀN TOÀN.

Hệ thống này được xây dựng với đích đến cuối cùng là: CON NGƯỜI CHỈ RA QUYẾT ĐỊNH, MÁY LÀM TẤT CẢ. Mọi quy trình nghiệp vụ tiêu chuẩn, lặp đi lặp lại phải chạy tự động — không cần con người can thiệp. Con người chỉ cần nói Yes hoặc No với những quyết định quan trọng.

Mọi Điều Luật trong Hiến pháp này, mọi nguyên tắc thiết kế, mọi registry, metadata, lifecycle, sync governance — tất cả chỉ là PHƯƠNG TIỆN để đạt mục tiêu tự động hoá hoàn toàn. Nếu bất kỳ thiết kế nào cản trở tự động hoá → thiết kế đó SAI, phải sửa.

Thước đo thành công: Nếu con người biến mất 1 tuần, hệ thống có tự vận hành — tự phát hiện lỗi — tự sửa — tự mở rộng được không? Khi câu trả lời là CÓ → hệ thống đạt mục tiêu.

Hiến pháp này được ban hành sau nhiều tháng xây dựng mà thiếu nền tảng kiến trúc, dẫn đến: lặp đi lặp lại cùng một lỗi, xây trên nền bùn, chạy theo vụ việc thay vì giải quyết từ gốc. Hiến pháp chấm dứt tình trạng đó.

ĐIỀU 0: THỰC THỂ ĐƯỢC QUẢN TRỊ — NỀN TẢNG CƠ BẢN NHẤT (S107 — Huyen, S111 sửa thuật ngữ)

Mọi Điều khác trong Hiến pháp này đều xây trên Điều 0. Không hiểu Điều 0 = không hiểu hệ thống.

THUẬT NGỮ (v2.0 — GPT/Gemini review S111):

"Thực thể được quản trị" (Managed Entity) = BẤT KỲ entity nào có ID + registry + metadata + Lớp 3. Dùng cho MỌI tầng.
"Nguyên tử" (Atom) = CHỈ Tầng 1 cấu tạo — entity không chứa entity khác. (Điều 0-B)
WF-001 = thực thể được quản trị (có ID WF-001) nhưng KHÔNG phải nguyên tử (chứa ND + CPS + CP → hợp chất)
CP-005 = thực thể được quản trị VÀ nguyên tử (không chứa entity khác)

Điều 0 = Luật NHẬN DIỆN. search_knowledge("luật thực thể được quản trị") Điều 0-B = Luật PHÂN TẦNG CẤU TẠO. search_knowledge("luật phân tầng cấu tạo") — 7 tầng: hạ nguyên tử → nguyên tử → phân tử → hợp chất → vật liệu → sản phẩm → công trình.

Khoản 1: Phép so sánh Vật lý

Thế giới vật lý phức tạp nhất mà con người biết — nhưng TẤT CẢ xây từ ~118 loại nguyên tử. Hiểu nguyên tử → làm chủ vật chất. Hệ thống Incomex cũng vậy: mọi thứ phức tạp (quy trình, workflow, ứng dụng) đều xây từ Nguyên tử Thông tin.

Vật lý	Incomex	Ví dụ
Quark	Field value	`status = "active"`
Nguyên tử ★	Entity có ID (PREFIX-NNN)	CP-005, ND-0007, DOT-042
Nguyên tố	Entity Type (loại)	Checkpoint, Workflow, DOT tool
Bảng tuần hoàn	`meta_catalog`	14 loại hiện tại
Phân tử	Tổ hợp (Set/Template)	CPS-001 = {CP-003 + CP-005 + CP-008}
Hợp chất	Module / Workflow	WF-001 gồm 10 nodes
Vật thể	Ứng dụng Tầng 4	Customer Journey
Liên kết hoá học	8 Quy tắc Quan hệ	BELONGS_TO, DEPENDS_ON...
Phản ứng hoá học	Thao tác nghiệp vụ	Tạo/sửa/gộp entities

Khoản 2: Định nghĩa formal

Nguyên tử Thông tin (Information Atom) = đơn vị nhỏ nhất trong hệ thống được:

Gán ID duy nhất (PREFIX-NNN)
Đăng ký trong registry (Directus collection)
Mang metadata đầy đủ — "Đúng, đủ, sạch, sống"
Tuân thủ 8 quy tắc quan hệ (Điều 21)
Có Lớp 3 — trang Wikipedia = "DB về chính nó"

Thoả 5 điều kiện = Nguyên tử. Không thoả = Hạ nguyên tử (tồn tại nhưng không quản lý bằng registry).

Khoản 3: Luật Lắp ráp + Di chuyển + Bảo toàn

Nguyên tử kết hợp thành phân tử, hợp chất, vật thể — theo QUY TẮC (giống hoá học). Nguyên tử có lifecycle (draft→active→deprecated→retired) — theo ĐIỀU KIỆN (giống chuyển pha vật lý). ID không tái sử dụng, quan hệ không tự mất, metadata không giảm — NGUYÊN TẮC BẢO TOÀN (giống bảo toàn năng lượng).

Khoản 4: Tầm nhìn

Xây dựng VÔ VÀN thứ phức tạp từ việc sắp xếp những thứ NHỎ, ĐƠN GIẢN theo quy tắc. Đó là cách thế giới vật lý hoạt động — và là cách Incomex hoạt động.

SSOT chi tiết: search_knowledge("luật thực thể được quản trị") (Điều 0 — nhận diện) Luật Phân tầng: search_knowledge("luật phân tầng cấu tạo vật chất thông tin") — Điều 0-B: 7 tầng. KHÔNG ĐƯỢC gọi tất cả là "nguyên tử". "Nguyên tử" = CHỈ Tầng 1. Đếm RIÊNG từng tầng.

ĐIỀU 1: NĂM LUẬT BẤT BIẾN

Năm luật này là nền tảng tối cao. Mọi quyết định, thiết kế, và dòng code phải tuân thủ cả 5 luật đồng thời. Không luật nào được hy sinh để đạt luật khác.

LUẬT 1: LÀM MỘT LẦN, DÙNG MÃI MÃI

Mỗi nội dung, mỗi tính năng, mỗi cơ chế chỉ tồn tại ở MỘT NƠI DUY NHẤT (Single Source of Truth). Không duplicate. Không làm lại từ đầu. Không có phiên bản song song. Sửa 1 chỗ = thay đổi mọi nơi dùng nó.

LUẬT 2: TỰ ĐỘNG HOÁ TỐI ĐA, TỰ ĐỘNG SCALE

Con người chỉ ra quyết định Yes/No. MỌI THỨ KHÁC = máy làm. Thiết kế cho 1 item VÀ 10.000 items. Config thay cho code. Nếu phải làm thủ công → thiết kế SAI.

LUẬT 3: DOT 100% — MỌI THAO TÁC QUA SCRIPT

Mọi thao tác trên hạ tầng, schema, registry, metadata = qua DOT tool hoặc script chuẩn. Không thao tác thủ công. Không chạy SQL trực tiếp. Không sửa config bằng tay. AI/Agent chỉ được GỌI script, không được tự viết logic trực tiếp.

LUẬT 4: SẴN SÀNG CHO MỌI THAY ĐỔI

Thứ duy nhất không thay đổi là mọi chuyện sẽ thay đổi ngày mai. Kiến trúc phải cho phép thêm, sửa, bỏ bất kỳ thành phần nào mà KHÔNG PHÁ VỠ hệ thống. Mọi thực thể có vòng đời: draft → active → deprecated → retired.

LUẬT 5: TỰ PHÁT HIỆN, TỰ CẢNH BÁO

Hệ thống phải biết khi nào nó sai, thiếu, lệch — KHÔNG CHỜ con người phát hiện. Bất kỳ 2 nguồn thông tin nào về cùng 1 thực thể mà khác nhau = bất đồng bộ = PHẢI phát hiện tự động + cảnh báo + tạo task fix.

ĐIỀU 2: LUẬT REGISTRY — MỌI THỨ PHẢI CÓ ID VÀ DANH SÁCH QUẢN LÝ

Đây là Luật nền tảng quan trọng nhất. Vi phạm Điều 2 = vi phạm Hiến pháp.

Khoản 1: Nguyên tắc cốt lõi

Mọi thực thể sinh ra trong hệ thống — từ cái nhỏ nhất (field, checkpoint) đến cái lớn nhất (quy trình nghiệp vụ) — đều BẮT BUỘC phải có:

Mã định danh duy nhất (ID) do hệ thống cấp, theo format PREFIX-NNN
Nằm trong một registry (Directus collection), có thể query được
Metadata tối thiểu: name, description, classification, owner, status vòng đời
Công cụ quản lý tự động: DOT/script sinh ra, đăng ký, cập nhật

NGUYÊN TẮC "1 THỰC THỂ = 1 ID = 1 SSOT" (S106 — Huyen xác lập):

Mỗi thực thể chỉ có DUY NHẤT 1 ID trong toàn hệ thống. ID đó là SSOT của thực thể.
KHÔNG BAO GIỜ tồn tại 2 bản sao của cùng 1 thực thể ở 2 nơi khác nhau. Nếu cần dùng ở nhiều nơi → TẤT CẢ trỏ về 1 ID gốc (reference), không copy.
Ví dụ: 1 checkpoint type (CP-001 "CI phải GREEN") dùng trong 10 quy trình khác nhau → 10 nơi đều trỏ về CP-001. Sửa CP-001 = tự động áp dụng 10 nơi. KHÔNG CÓ 10 bản copy.
Nếu phát hiện cùng 1 thực thể tồn tại ở 2 nơi với 2 ID khác nhau → VI PHẠM NGHIÊM TRỌNG → phải merge ngay, giữ 1 ID, xoá bản sao.

Khoản 2: Hệ quả pháp lý

Thực thể không có ID = KHÔNG TỒN TẠI đối với hệ thống
Thực thể không trong registry = VÔ HÌNH, không ai kiểm soát
Hỏi "có bao nhiêu X?" mà phải grep code hoặc đếm tay = VI PHẠM HIẾN PHÁP
Câu trả lời phải là 1 query vào Directus

Khoản 3: Bảng mã Prefix chuẩn (S107 v3.0 — phân biệt Active vs Planned)

Mọi ID phải tuân theo format: PREFIX-NNN (prefix viết hoa, 3+ chữ số tự tăng).

✅ ACTIVE — Đã có collection + meta_catalog + auto-ID flow:

Prefix	Loại thực thể	Ví dụ	Registry	CAT code
CAT	Catalog (Bảng tuần hoàn tự tham chiếu)	CAT-001	meta_catalog	CAT-000
TBL	Bảng UI	TBL-001	table_registry	CAT-001
M	Module	M-001	modules	CAT-002
WF	Quy trình (Workflow)	WF-001	workflows	CAT-003
ND	Node / Workflow Step	ND-0001	workflow_steps	CAT-004
WCR	Đề xuất thay đổi workflow	WCR-001	workflow_change_requests	CAT-005
DOT	DOT tool	DOT-001	dot_tools	CAT-006
PG	Trang/Route	PG-001	ui_pages	CAT-007
COL	Collection (bảng DB)	COL-001	collection_registry	CAT-008
TSK	Task	TSK-001	tasks	CAT-009
AGT	Agent	AGT-001	agents	CAT-010
CP	Checkpoint type (định nghĩa)	CP-001	checkpoint_types	CAT-011
CPS	Checkpoint set (tổ hợp)	CPS-001	checkpoint_sets	CAT-012
DEP	Dependency record	DEP-0001	entity_dependencies	CAT-013

🔴 CẦN THÊM NGAY — Collection tồn tại nhưng CHƯA trong Bảng tuần hoàn (TD-106):

Prefix	Loại thực thể	Registry	Vấn đề
TP	Đề xuất bảng (Table Proposal)	table_proposals	Collection có, meta_catalog THIẾU
CPI	Checkpoint instance (thực tế)	checkpoint_instances	Collection có, meta_catalog THIẾU

⬜ KẾ HOẠCH — Chưa tạo collection, cần khi mở rộng:

Prefix	Loại thực thể	Khi nào	TD
SCR	Đề xuất thay đổi schema	Điều 9 enforce	—
API	API endpoint	Scale API routes	—
CMP	Component chia sẻ	Scale components	—
JT	Journey Template (tổ hợp node)	Tầng 4	TD-082
EVT	Event	Event registry	—
DOM	Domain	Multi-domain	TD-086

Quy tắc:

Prefix = 2-4 ký tự viết HOA, gợi nhớ loại thực thể
Số = 3 chữ số tối thiểu (001, 002...), tự tăng. Với loại lớn (fields, dependencies) dùng 4 chữ số (0001)
ID một khi cấp = KHÔNG ĐỔI, kể cả khi rename thực thể
DOT script sinh ID = tự query max ID hiện tại + 1

Khoản 3: Áp dụng

Xem chi tiết: search_knowledge("entity lifecycle quy trình sinh thực thể")

ĐIỀU 3: LUẬT METADATA — MỌI THỨ PHẢI CÓ NHÃN DÁN

Khoản 1: Nguyên tắc

Mỗi thực thể, kể cả đơn vị nhỏ nhất (field, checkpoint), phải mang metadata đầy đủ: thuộc chuyên môn nào, loại nào, mảng nào, tầng nào, lưu ý gì. Metadata phải tìm kiếm được (search/query).

Khoản 2: Khung metadata mở rộng (S106 — sẵn sàng cho tương lai)

Metadata không chỉ là "mô tả" — metadata là ngôn ngữ để hệ thống TỰ HIỂU MÌNH. Khi metadata đủ tốt, AI có thể tự trả lời: thực thể này dùng ở đâu? ai quản lý? liên quan gì tới ai? đang ở trạng thái nào?

Khung metadata tối thiểu cho MỌI thực thể:

Field	Mục đích	Bắt buộc
code	Mã PREFIX-NNN duy nhất	✅
name	Tên hiển thị (Vietnamese)	✅
name_en	Tên tiếng Anh (cho AI/agents)	✅
description	Mô tả mục đích kinh doanh	✅
classification	Phân loại: core/module/data/governance/operational	✅
status	Vòng đời: draft → active → deprecated → retired	✅
owner	Ai/agent chịu trách nhiệm	✅
layer	Tầng kiến trúc (1-5)	✅
tags	Nhãn tự do, dùng cho search/filter	🟡
used_by	Danh sách thực thể đang dùng (dependency ngược)	🟡
triggers	Danh sách sự kiện mà thực thể này kích hoạt	🟡
triggered_by	Danh sách sự kiện kích hoạt thực thể này	🟡
related_to	Liên kết tới thực thể liên quan (không phải dependency cứng)	🟡

Nguyên tắc mở rộng: Khi tương lai phát sinh loại metadata mới → thêm field vào khung này. KHÔNG tạo bảng riêng cho metadata. Metadata gắn liền với thực thể, không tách rời.

Khoản 3: Hệ quả

Nếu cần thêm 1 label mới cho 20.000 fields → phải có cơ chế batch update 1 lệnh. Nếu phải làm thủ công từng field → thiết kế SAI, vi phạm Luật 2.

Khoản 4: Công cụ có sẵn

Directus meta.note (mô tả), meta.group (phân loại), translations (đa ngôn ngữ) đã có sẵn cho collections và fields. ✅ ĐÃ KHAI THÁC: meta.note 100% filled (PR #450), meta.group 86.8% filled. Tools: dot-metadata-audit + dot-metadata-fill.

Khoản 5: Metadata cho checkpoint và quy trình (S106)

Checkpoint là thực thể → cần metadata đầy đủ:

CP type: nằm trong bao nhiêu tổ hợp? trigger bao nhiêu quy trình? đang dùng ở đâu?
CP set: chứa bao nhiêu checkpoints? gắn với node nào? quy trình nào dùng?
CP instance: đang ở trạng thái nào? ai verify? bằng chứng gì?

Quy trình Tầng 4 (khách hàng) sẽ có hàng ngàn checkpoint instances → metadata PHẢI query được để trả lời: "Khách hàng X đã qua những checkpoint nào? Còn thiếu gì?"

ĐIỀU 4: LUẬT SINH SẢN — KHÔNG AI ĐƯỢC "ĐẺ BỪA BÃI"

Khoản 1: Nguyên tắc

Hệ thống xây ra quy trình quản lý cho người khác — nhưng chính AI/Agent xây hệ thống cũng PHẢI tuân thủ quy trình đó. Lãnh đạo phải làm gương.

Khoản 2: Quy trình bắt buộc

Mọi thực thể mới sinh ra trên hệ thống PHẢI:

Được tạo qua DOT/script chuẩn (KHÔNG viết code trực tiếp tạo)
Được cấp ID tự động
Được đăng ký vào registry tự động
Được gán metadata tối thiểu
Được thông báo cho các hệ thống liên quan

Khoản 3: Hình phạt

AI/Agent tạo thực thể không qua quy trình = PR bị reject. Không ngoại lệ, kể cả "khẩn cấp" hay "tạm thời".

Chi tiết: search_knowledge("entity lifecycle quy trình sinh thực thể")

ĐIỀU 5: KIẾN TRÚC 5 TẦNG

Khoản 1: Cấu trúc

┌─────────────────────────────────────────────────────────┐
│  TẦNG 5: GIÁM SÁT + CẢI TIẾN                          │
│  Phát hiện bất đồng bộ, đề xuất cải tiến, auto-fix     │
├─────────────────────────────────────────────────────────┤
│  TẦNG 4: CHUYÊN MÔN (ĐÍCH ĐẾN CUỐI CÙNG)             │
│  Quy trình nghiệp vụ: đại lý, tuyển dụng, khách hàng  │
│  Diễn biến nhiều tháng, phân nhánh phức tạp            │
├─────────────────────────────────────────────────────────┤
│  TẦNG 3: MODULES NỀN TẢNG                              │
│  Table, Comment, Workflow, Tester, CI/CD, viết mã...    │
├─────────────────────────────────────────────────────────┤
│  TẦNG 2: CƠ SỞ (NGUYÊN LIỆU)                         │
│  Registries, Metadata, DOT, Fields, Schemas, Events     │
├─────────────────────────────────────────────────────────┤
│  TẦNG 1: HẠ TẦNG                                       │
│  VPS, Docker, DB, Directus, Nuxt, Agent Data, AI conn   │
└─────────────────────────────────────────────────────────┘

Khoản 2: Luật xây dựng

KHÔNG BAO GIỜ xây tầng trên khi tầng dưới chưa vững. Tầng 2 chưa xong → cấm xây thêm tính năng Tầng 3. Tầng 3 chưa xong → cấm bắt đầu Tầng 4. Vi phạm = xây trên bùn = sẽ sụp.

Khoản 3: Hiện trạng (2026-03-24 S133 — sau S105→S133)

Tầng 1: ✅ Ổn định. VPS Contabo EU ($8/tháng). Docker 6 services. PostgreSQL 16 DUY NHẤT. MySQL RETIRED (S115). GH → VPS direct deploy. GCP: chỉ Secret Manager (~$2/tháng).
Tầng 2: ✅ HOÀN THÀNH — 138 collections (33 species, 100% coverage). 15,307 births (Gap=0). 17 PG TRIGGER realtime. verify_counts()=0 MISMATCH. Health 18 KHỚP. 0 Orphan. 0 Phantom. 5-Layer Registries UI.
Tầng 3: 🟡 Modules hoạt động. Registries 5-layer UI. DirectusTable. Lớp 3 per entity. Cần: state machine, Label Law deploy.
Tầng 4: ⬜ Chưa bắt đầu (đúng — Tầng 3 chưa hoàn thiện)
Tầng 5: 🟡 TIẾN BỘ LỚN — Điều 30 BAN HÀNH (Playwright E2E). Điều 31 contracts 100% (37P/0F). Universal Measurement Framework đang implement (S133-M3). WATCHDOG cần fix (TD-350).

Chi tiết: search_knowledge("5 tầng kiến trúc chi tiết")

ĐIỀU 6: LUẬT ĐỒNG BỘ

Khoản 1: Nguyên tắc

Bất kỳ 2 nguồn thông tin nào về cùng 1 thực thể mà KHÁC NHAU = bất đồng bộ = vi phạm. Hệ thống phải có cơ chế phát hiện TỰ ĐỘNG cho MỌI cặp nguồn, không chỉ 1-2 cặp đã biết.

Khoản 2: Cấm tư duy vụ việc

Khi phát hiện vấn đề đồng bộ ở 1 chỗ → PHẢI tư duy: "vấn đề này có xảy ra ở chỗ khác không?" → giải quyết ở tầm KIẾN TRÚC, không chỉ fix 1 chỗ rồi xong.

Chi tiết: search_knowledge("sync governance đồng bộ bất đồng bộ")

ĐIỀU 7: LUẬT TẬN DỤNG

Khoản 1: Thứ tự ưu tiên bắt buộc

★ Khai thác PostgreSQL trước nhất — VIEW, TRIGGER, CTE, CONSTRAINT, FUNCTION. Đếm? DB đếm. Quan hệ? DB FK. Bắc cầu? DB recursive CTE. Tự cập nhật? DB TRIGGER. "Stupid = đi làm lại cái xã hội đã làm rồi." (Huyen S111, bài học hơn 10 lần vi phạm)
Khai thác Directus có sẵn (system collections, APIs, Flows, metadata fields)
Khai thác Nuxt UI / Agency OS có sẵn
Khai thác nguồn mở bên ngoài
Code mới — CHỈ KHI 0-3 thất bại + được phê duyệt

Khoản 2: Phát hiện quan trọng

70% nhu cầu metadata = KHAI THÁC Directus có sẵn. ✅ HOÀN THÀNH 100% (PR #450). 20% = tạo registry collections mới. ✅ HOÀN THÀNH 13/13 (PR #451+#454). 10% = viết tools mới. ✅ 9+ DOT tools cốt lõi S106. Orphan Scanner coverage: 100% (PR #455).

Khoản 3: Ưu tiên Directus system collections trước (Gemini Council Review S105)

Trước khi tạo registry collection mới → kiểm tra: Directus meta.note (hỗ trợ text dài) có thể chứa metadata mở rộng dạng JSON không? Nếu có → dùng luôn, tránh tạo collection thừa. Ví dụ: collection_registry có thể KHÔNG CẦN nếu directus_collections.meta.note chứa đủ thông tin phân loại + owner + tầng. Tuy nhiên, system collections hạn chế thêm custom fields qua API → đánh giá trước khi quyết định.

Chi tiết: search_knowledge("tools inventory công cụ có sẵn")

ĐIỀU 8: LUẬT PHỤ THUỘC — MỌI LIÊN KẾT PHẢI ĐƯỢC GHI NHẬN (GPT Council Review S105)

Khoản 1: Nguyên tắc

Mọi thực thể trong hệ thống đều phụ thuộc vào thực thể khác. Nếu không biết ai phụ thuộc ai → không thể retire, deprecate, hoặc sửa đổi an toàn. Một thay đổi nhỏ có thể phá hàng chục nơi mà không ai biết.

Khoản 2: Entity Dependency Graph

Hệ thống PHẢI có registry entity_dependencies ghi nhận mọi liên kết:

field → collection → page → module → workflow
Khi deprecate/retire 1 thực thể → query dependencies → biết chính xác nơi bị ảnh hưởng
Không có dependency graph = KHÔNG ĐƯỢC deprecate (vì không biết impact)

Khoản 3: Schema cơ bản

entity_dependencies:
  source_type   (enum: collection, field, table, page, module, workflow, dot_tool)
  source_id     (string: mã ID của source)
  target_type   (enum: tương tự)
  target_id     (string: mã ID của target)
  relation_type (enum: uses, requires, extends, displays, triggers)

ĐIỀU 9: LUẬT SCHEMA GOVERNANCE — MỌI THAY ĐỔI SCHEMA PHẢI QUA DUYỆT (GPT Council Review S105)

Khoản 1: Nguyên tắc

Schema (collections, fields, relations) là NỀN MÓNG. Thay đổi schema không kiểm soát = drift = hệ thống vỡ dần. DOT 100% chặn thao tác thủ công, nhưng chưa có QUY TRÌNH DUYỆT cho thay đổi schema.

Khoản 2: Schema Change Request (SCR)

Mở rộng concept WCR (Workflow Change Request) cho schema:

Thay đổi schema (thêm/sửa/xóa collection, field, relation) → tạo SCR
SCR → AI Council review → Approve → DOT script thực thi
SCR lưu trong schema_change_requests collection (hoặc mở rộng workflow_change_requests thêm type=schema)

Khoản 3: Ngoại lệ

Schema changes trong Phase 0-1 (xây nền tảng) được miễn SCR vì đang bootstrap. Bắt buộc SCR từ Phase 2 trở đi.

ĐIỀU 14: LUẬT CHỐNG TRÙNG LẶP — KHÔNG HAI THỨ CÙNG BẢN CHẤT (S105 Huyen + S106 nâng cấp + S109 Luật chi tiết)

Khoản 1: Nguyên tắc

Không được tồn tại 2 fields, 2 collections, 2 scripts, 2 checkpoints, 2 nodes, hay 2 bất kỳ thực thể nào cùng bản chất nội dung. Trùng lặp gây lỗi cực kỳ khó tìm: data ghi vào field A nhưng AI đọc field B → sai mà không ai hiểu tại sao. Bản copy của 1 thực thể = phá vỡ SSOT = vi phạm Luật 1 + Điều 2.

Khoản 1b: Ba cấp độ trùng (S109 — Luật chi tiết)

Cấp 1 — Trùng chính xác: Tên/code giống 100% sau chuẩn hoá → CHẶN, không cho tạo
Cấp 2 — Nghi ngờ trùng: Mô tả tương tự ≥70% (vector semantic) → CẢNH BÁO + system_issues
Cấp 3 — Trùng cấu trúc: 2 tổ hợp chứa ≥80% cùng items (Jaccard) → CẢNH BÁO + review bắt buộc

Khoản 1c: Kiến trúc scale (S109)

Tầng 1 (realtime): Chuẩn hoá tên → exact match → CHẶN. O(1), instant.
Tầng 2 (scheduled): Qdrant vector search → semantic similarity. O(log n), scale 100K+.
Mô tả (description) ≥20 từ tiếng Việt = NGUYÊN LIỆU cho Engine. Thiếu mô tả = Engine mù.

SSOT chi tiết: search_knowledge("luật chống trùng lặp duplicate")

Khoản 1: Nguyên tắc

Khoản 2: Áp dụng cho MỌI loại thực thể (S106 — mở rộng)

Fields: 2+ collections có field cùng concept → PHẢI chuẩn hoá tên hoặc ghi rõ metadata phân biệt
Checkpoints: 2 CP types cùng mô tả/mục đích → PHẢI merge thành 1, mọi nơi trỏ về 1 ID
Checkpoint sets: 2 sets chứa cùng tập CP types → PHẢI merge hoặc ghi rõ khác biệt
Nodes: 2 workflow_steps cùng logic/title trong cùng domain → PHẢI dùng chung 1 node definition
Journey templates: 2 templates chứa cùng tập nodes + cùng thứ tự → PHẢI merge
Collections: 2 collections chứa data tương tự → PHẢI ghi rõ ranh giới
DOT tools: 2 scripts làm cùng việc → PHẢI gộp hoặc deprecate 1
Documents: 2 SSOT docs nói cùng topic → PHẢI merge thành 1

Khoản 3: Engine chống double — 2 cấp độ (S106)

GIẢI PHÁP TỔNG QUÁT — 1 engine, quét MỌI entity type:

dot-duplicate-engine (1 tool duy nhất — thay tất cả script vụ việc)

CẤP 1 — NGHI NGỜ (semantic similarity ≥70%):
  → Cảnh báo: "CP-015 'Kiểm tra tồn kho' ≈ CP-003 'Verify inventory'"
  → Tạo ai_task type=review_duplicate
  → KHÔNG block — chỉ cảnh báo, chờ quyết định

CẤP 2 — TRÙNG CHÍNH XÁC (tên/code/logic giống 100%):
  → STOP NGAY — không cho tạo
  → Trả về: "BLOCKED: entity X đã tồn tại với ID=Y"
  → DOT script reject, Directus Flow cancel

Khoản 4: Tích hợp vào vòng đời thực thể

TRƯỚC KHI TẠO bất kỳ thực thể nào:
  1. dot-duplicate-engine --check --type=<type> --name=<name> --desc=<desc>
  2. CẤP 2 (trùng chính xác) → STOP, trả lỗi, không tạo
  3. CẤP 1 (nghi ngờ) → WARNING, cho phép tạo + tạo ai_task review
  4. Clean → cho phép tạo

SCHEDULED SCAN (mỗi ngày):
  dot-duplicate-engine --scan --type=ALL
  → Quét: fields, checkpoints, checkpoint_sets, nodes, journey_templates,
           collections, DOT tools, documents
  → Report: reports/duplicate-scan-[DATE].md
  → Nếu phát hiện → tạo ai_tasks tự động

Khoản 5: Kỹ thuật phát hiện

Exact match: Tên/code giống 100% (case-insensitive, trim whitespace)
Semantic match: Dùng vector embeddings (Agent Data Qdrant ĐÃ CÓ) — so sánh mô tả/description → cosine similarity ≥0.7 = nghi ngờ
Structural match (cho sets/templates): 2 sets chứa ≥80% cùng items → nghi ngờ
Field name normalization: lowercase, remove prefix, split camelCase/snake_case → "assigned_to" ≈ "assignedTo" ≈ "owner" (semantic)

Khoản 6: Kiểm soát Double trong đồng bộ

Khi data sync giữa 2 hệ thống (Directus ↔ Agent Data):

Mỗi collection sync MỘT CHIỀU DUY NHẤT — không bao giờ 2 chiều
Data sinh từ Directus → sync sang Agent Data → Agent Data KHÔNG ĐƯỢC fire event ngược → tránh loop vô hạn
Mỗi sync flow phải có origin marker hoặc path prefix riêng để phân biệt "data gốc" vs "data sync"

ĐIỀU 10: LUẬT INJECT — RULES PHẢI ĐẾN ĐÚNG NƠI AGENT ĐỌC (Self-review S105)

Khoản 1: Nguyên tắc

Rules chỉ có giá trị nếu agent BUỘC PHẢI đọc. Rules nằm trong Agent Data mà agent phải chủ động search → agent bận → quên → vi phạm. Giống biển báo tốc độ không có camera.

Khoản 2: Cơ chế bắt buộc

CLAUDE.md + AGENTS.md (2 repos) phải chứa BẢN RÚT GỌN Hiến pháp — dạng checklist, KHÔNG phải prose dài. Claude Code/Codex đọc TỰ ĐỘNG khi khởi động.
.claude/skills/incomex-rules.md phải cập nhật mỗi khi Hiến pháp thay đổi.
DOT scripts phải TỰ KIỂM TRA tuân thủ — không phụ thuộc agent "nhớ".

Khoản 3: Kiểm chứng

Nếu agent vi phạm rule mà rule đó KHÔNG nằm trong CLAUDE.md/AGENTS.md → lỗi thuộc về HỆ THỐNG (chưa inject), không phải agent.

ĐIỀU 11: LUẬT IDEMPOTENT — SCRIPT PHẢI CHẠY LẠI ĐƯỢC (Self-review S105)

Khoản 1: Nguyên tắc

Mọi DOT script PHẢI idempotent — chạy lại không tạo duplicate, tự phát hiện bước nào đã xong, tự bỏ qua bước đã hoàn thành.

Khoản 2: Verify step bắt buộc

Mỗi DOT script sinh entity PHẢI có bước VERIFY CUỐI: kiểm tra TẤT CẢ outputs tồn tại (collection + registry record + permissions + metadata). Nếu thiếu bất kỳ output nào → tự fix hoặc báo lỗi rõ ràng với danh sách cụ thể thiếu gì.

Khoản 3: Hệ quả

Script lỗi giữa chừng + không có verify = bất đồng bộ ẩn tích lũy. Đây là loại bug nguy hiểm nhất vì không ai thấy cho đến khi hệ thống đủ lớn rồi vỡ.

ĐIỀU 12: LUẬT VÒNG ĐỜI ĐẦY ĐỦ — SINH + SỬA + XOÁ (Self-review S105)

Khoản 1: Nguyên tắc

Entity Lifecycle phải cover TOÀN BỘ vòng đời, không chỉ "sinh":

SINH (Create): Qua DOT script → ID → registry → metadata (Điều 4 đã cover)
SỬA (Modify): Sửa entity → cập nhật TẤT CẢ registries + dependencies tự động. Đổi tên field → mọi nơi dùng field đó phải biết.
XOÁ (Delete/Retire): Query dependencies → nếu có nơi đang dùng → CHẶN xoá → phải deprecate trước → chờ 0 dependencies → mới retire
GỘP (Merge): Tạo entity mới → migrate data → update dependencies → deprecate entities cũ

Khoản 2: Hệ quả

Hệ thống chỉ biết tạo mới mà không biết dọn dẹp = phình to mãi mãi. Entity chết chất đống, metadata cũ gây nhầm lẫn, dependencies trỏ vào thực thể không còn tồn tại.

ĐIỀU 13: LUẬT DANH MỤC SỐNG — TẠO = TỰ XUẤT HIỆN, XOÁ = TỰ BIẾN MẤT (S105 — Huyen phát hiện)

Đây là "điểm gãy của điểm gãy". Điều 2 (Registry) nói "mọi thứ phải trong registry" — nhưng NẾU việc đăng ký vào registry vẫn phải NHỚ, phải làm tay → sẽ quên → registry lệch → Registry-First = vô nghĩa.

Khoản 1: Nguyên tắc LIVE CATALOG

Mọi danh sách (catalog/list) trong hệ thống PHẢI là live view — phản ánh thực tế NGAY LẬP TỨC, không phải bản sao phải sync thủ công.

TẠO thực thể → danh sách TỰ ĐỘNG hiện thực thể mới
XOÁ thực thể → danh sách TỰ ĐỘNG ẩn
SỬA thực thể → danh sách TỰ ĐỘNG cập nhật

Nếu phải "nhớ cập nhật danh sách" sau khi tạo/xoá → THIẾT KẾ SAI. Vi phạm Luật 2 (Tự động hoá).

Khoản 2: Cơ chế thực hiện — 2 mô hình

Mô hình A — Registry IS the source (ưu tiên): Thực thể được TẠO TRONG registry → hệ thống đọc từ registry → UI hiện.

Ví dụ: table_registry → DirectusTable đọc config → UI hiện bảng. ĐÃ LÀM ĐÚNG.
Ví dụ: modules collection → trang /knowledge/modules đọc từ Directus → UI hiện. ĐÃ LÀM ĐÚNG.
Đây là mô hình tốt nhất. Tạo record = xuất hiện. Không cần sync.

Mô hình B — Source tách rời → auto-sync vào registry: Thực thể tồn tại ở nơi khác (ví dụ: file trong dot/bin/) → registry phải TỰ ĐỘNG scan và cập nhật.

Ví dụ: DOT tools nằm trong dot/bin/ → cần script dot-catalog-sync chạy tự động → scan dot/bin/ → so sánh với dot_tools registry → thêm/xoá records cho khớp.
Ví dụ: Vue pages nằm trong web/pages/ → cần script scan → so sánh với ui_pages registry.
Mô hình này kém hơn A (vì có delay + có thể lệch) nhưng bắt buộc khi source không phải Directus.

Khoản 3: Quy tắc chọn mô hình

Thực thể	Source thực tế	Mô hình	Giải pháp
Bảng UI	`table_registry` (Directus)	A — registry IS source	✅ Đã đúng
Modules	`modules` (Directus)	A — registry IS source	✅ Đã đúng
Workflows	`workflows` (Directus)	A — registry IS source	✅ Đã đúng
DOT tools	Files trong `dot/bin/`	B — auto-sync	Cần `dot-catalog-sync` script
Pages/Routes	Files trong `web/pages/`	B — auto-sync	Cần scan script
API endpoints	Files trong `web/server/api/`	B — auto-sync	Cần scan script
Components	Files trong `web/components/`	B — auto-sync	Cần scan script
Collections	Directus system (`directus_collections`)	A — Directus IS source	Query trực tiếp, không cần registry riêng nếu dùng `meta.note` + `meta.group`
Fields	Directus system (`directus_fields`)	A — Directus IS source	Query trực tiếp
Agent Data docs	Agent Data API	A — API IS source	`list_documents` đã có

Nguyên tắc: Mô hình A > Mô hình B. Nếu có thể di chuyển source vào Directus → chuyển sang Mô hình A.

Khoản 4: Auto-sync cho Mô hình B — BẮT BUỘC

Mỗi thực thể dùng Mô hình B PHẢI có:

Script scan (DOT tool): quét source → so sánh registry → thêm/xoá/update
Cron trigger: chạy scan định kỳ (mỗi deploy, hoặc mỗi 30 phút)
Event trigger: khi CI merge PR → chạy scan ngay (file mới = registry cập nhật)

Nếu thiếu bất kỳ 1 trong 3 → registry CHẮC CHẮN sẽ lệch theo thời gian.

Khoản 5: Danh sách phải đọc được bởi CẢ AI VÀ Con người

Mỗi danh mục (catalog) phải có 2 giao diện:

AI đọc: Query Directus API hoặc Agent Data search → trả JSON/structured data
Con người đọc: UI page trên Nuxt (dùng DirectusTable) hiển thị danh sách + metadata chính + filter/search

Con người xác nhận đúng trên UI → chắc chắn đúng cho AI. Một nguồn sự thật, hai cách truy cập.

Khoản 6: Quản lý Danh mục của Danh mục (Catalog of Catalogs)

Khi số lượng registry collections lên vài chục → cần 1 meta-catalog: danh sách TẤT CẢ registries.

meta_catalog (Directus collection):
  registry_name     (string: tên registry, ví dụ "table_registry")
  entity_type       (string: loại thực thể, ví dụ "Bảng UI")
  source_model      (enum: A hoặc B)
  source_location   (string: nơi source thực tế, ví dụ "dot/bin/" hoặc "Directus collection")
  sync_script       (string: tên DOT script sync, null nếu Mô hình A)
  sync_frequency    (string: "on-deploy" hoặc "30min" hoặc "realtime")
  record_count      (integer: số records hiện tại — auto-query)
  ui_page           (string: URL trang UI hiển thị danh sách)
  status            (enum: active/planned/deprecated)

AI hỏi "hệ thống có những danh mục nào?" → query meta_catalog → trả lời CHÍNH XÁC. Con người mở /knowledge/registries → thấy TẤT CẢ danh mục + trạng thái + số lượng + link.

ĐIỀU 15: LUẬT STATE MACHINE — TẦNG 4 DÙNG TRẠNG THÁI, KHÔNG CHỈ QUY TRÌNH TUYẾN TÍNH (S106 — Huyen + Claude)

Khoản 1: Phân biệt 2 mô hình

	Quy trình tuyến tính (Process)	Máy trạng thái (State Machine)
Thứ tự	Cố định: A → B → C	Linh hoạt: bất kỳ → bất kỳ
Hoàn thành	Đi từ đầu tới cuối	Có thể ở 1 trạng thái mãi
Skip bước	Không (hoặc nhánh cố định)	Tự do — nhảy thẳng nếu đủ điều kiện
Trigger	Bước trước xong → bước sau bắt đầu	Sự kiện xảy ra → chuyển trạng thái
Ví dụ	Quy trình duyệt công việc (M-002)	Tiến trình phát triển khách hàng

Khoản 2: Tầng 4 dùng State Machine là CHÍNH

Quy trình nghiệp vụ thực tế (khách hàng, đại lý, cộng tác viên) hầu hết KHÔNG tuyến tính. Ví dụ:

Khách hàng: Biết → Quan tâm → Mua hàng → Giới thiệu → Cộng tác viên
Nhưng: có người chưa mua đã giới thiệu, có người từ "Biết" nhảy thẳng "Cộng tác viên"
Mỗi thực thể (khách hàng, đại lý) có trạng thái hiện tại + nhiều mục tiêu tiếp theo song song

Workflow Module (M-002) PHẢI hỗ trợ CẢ HAI mô hình:

Process mode (hiện tại): quy trình nội bộ, tuần tự, kiểm soát chặt
State machine mode (Tầng 4): trạng thái linh hoạt, chuyển tự do theo điều kiện

Khoản 3: Schema hỗ trợ — KHÔNG CẦN REFACTOR

workflow_steps = các node (trạng thái hoặc bước). Thêm step_type = "state". Thêm code field format ND-0001 (global unique). workflow_step_relations = các transition. Thêm relation_type = "state_transition" + condition_expression. workflows = container. Thêm workflow_mode = "process" | "state_machine".

Khoản 4: Node là thực thể — PHẢI có ID (S106 — Huyen xác lập)

Node (workflow_step) cũng là thực thể như checkpoint — phải có:

Mã ND-0001 (PREFIX chuẩn, global unique, không chỉ unique per workflow)
Metadata đầy đủ: description, classification, owner, status
Registry query: "Node này dùng ở workflow nào? Gắn checkpoint set nào? Có trong journey template nào?"
Hiện tại 70 nodes dùng step_key text tự do → cần chuẩn hoá sang ND-0001 format

Khoản 5: Journey Templates — Tổ hợp trạng thái (S106 — Huyen ý tưởng)

Vấn đề: Có ~5-10 trạng thái cố định nhưng TỔ HỢP đường đi có thể lên hàng trăm, hàng ngàn. Nếu ghép lẻ → khó tự động, dễ sai. Đẻ sẵn tổ hợp cố định (Journey Templates) → kiểm soát được.

Kiến trúc — song song hoàn toàn với Checkpoint Sets (cùng design pattern):

workflow_steps / nodes (NODE đơn lẻ — SSOT)
  ND-0001 "Biết", ND-0002 "Quan tâm", ND-0003 "Mua hàng"...
  → 1 node = 1 SSOT duy nhất. Sửa = áp dụng mọi nơi.

journey_templates (TỔ HỢP node — đường đi chuẩn)
  JT-001 "Hành trình khách hàng tiêu chuẩn" (4 states)
  JT-002 "Fast track CTV" (2 states)
  JT-003 "Warm lead → Mua" (3 states)
  → Mỗi template = 1 bộ states + thứ tự ưu tiên + điều kiện chuyển

journey_template_steps (M2M)
  JT-001 + ND-0001 (vị trí 1, checkpoint_set: CPS-020)
  JT-001 + ND-0002 (vị trí 2, checkpoint_set: CPS-021)
  JT-001 + ND-0003 (vị trí 3, checkpoint_set: CPS-022)
  → Mỗi bước trong template gắn checkpoint set riêng

Khi dùng:

Gán khách hàng → journey_template_id = JT-001
Hệ thống TỰ BIẾT: "Khách A đang ở ND-0002, mục tiêu tiếp = ND-0003, cần hoàn thành CPS-021"
Thay đổi JT-001 (thêm state) → TẤT CẢ khách dùng JT-001 tự cập nhật → SSOT

Design Pattern thống nhất (áp dụng cho MỌI loại tổ hợp):

Thực thể đơn lẻ	Tổ hợp	M2M	Prefix
checkpoint_types (CP)	checkpoint_sets (CPS)	checkpoint_set_items	CP/CPS
workflow_steps / nodes (ND)	journey_templates (JT)	journey_template_steps	ND/JT
Tương lai: fields, rules...	field_sets, rule_sets...	M2M tương ứng	...

Nguyên tắc: Khi phát hiện loại thực thể nào cần tổ hợp → áp dụng cùng pattern: entity → entity_set → entity_set_items (M2M). Không phát minh lại.

Khoản 6: Entity state tracking (cần khi bắt đầu Tầng 4)

Field current_step_id trên collections có lifecycle (contacts, agents, deals...)
Field journey_template_id trên cùng collections
State history collection: ghi lại lịch sử chuyển trạng thái (từ node nào → node nào, khi nào, trigger gì)
Multi-target: M2M relation — 1 entity → nhiều target steps (mục tiêu song song)

Khoản 7: Checkpoint gắn vào Node

Mỗi node (dù là step trong process hay state trong state machine) có thể gắn 1 checkpoint set (tổ hợp checkpoint). Khi entity đến node → hệ thống tạo checkpoint instances từ set → phải hoàn thành checkpoints → mới đủ điều kiện chuyển sang node tiếp.

Trong state machine: hoàn thành checkpoint set KHÔNG BẮT BUỘC phải chuyển state — chỉ là 1 trong nhiều điều kiện. Ví dụ: khách hàng hoàn thành tất cả checkpoint "Quan tâm" nhưng vẫn ở state "Quan tâm" cho đến khi có trigger "đặt đơn".

ĐIỀU 16: LUẬT CHECKPOINT — ĐỊNH DANH + TỔ HỢP + TÁI SỬ DỤNG (S106 — Huyen + Claude)

Khoản 1: Checkpoint là thực thể — phải có ID + metadata

Checkpoint KHÔNG phải text ghi trong checklist. Checkpoint là thực thể có ID chính thức trong hệ thống, tuân thủ đầy đủ Điều 2 (Registry) và Điều 3 (Metadata).

3 tầng checkpoint:

checkpoint_types (ĐỊNH NGHĨA — SSOT duy nhất)
  Mã: CP-001, CP-002...
  Ví dụ: CP-001 = "CI phải GREEN", CP-002 = "Code review pass"
  → 1 type = 1 SSOT. Dùng ở 100 nơi = 100 nơi trỏ về 1 ID.
  → Sửa CP-001 = tự động áp dụng mọi nơi dùng CP-001.

checkpoint_sets (TỔ HỢP — gom types thành bộ)
  Mã: CPS-001, CPS-002...
  Ví dụ: CPS-001 = "Bộ kiểm tra chất lượng đơn hàng" (gồm CP-003, CP-004, CP-005)
  → 1 set gắn vào nhiều workflow nodes. Thêm/bớt CP trong set = áp dụng mọi nơi.
  → 1 CP type có thể nằm trong nhiều sets (M2M).

checkpoint_instances (THỰC TẾ — ghi nhận kết quả)
  Mã: CPI-0001, CPI-0002... (tự tăng, số lượng lớn)
  → Khi entity đến node có checkpoint set → hệ thống TỰ SINH instances.
  → Instance ghi: đã verify chưa? ai verify? bằng chứng? thời gian?

Khoản 2: Kiến trúc 3 bảng

checkpoint_types (ĐÃ CÓ — cần thêm code PREFIX CP-NNN)
  id, code (CP-001), name, description, layer, category,
  requires_evidence, auto_verifiable, status

checkpoint_sets (CẦN TẠO)
  id, code (CPS-001), name, description, status,
  applicable_to (enum: process/state_machine/both),
  trigger_config (json: khi nào set này kích hoạt)

checkpoint_set_items (CẦN TẠO — M2M)
  id, set_id (FK → checkpoint_sets), type_id (FK → checkpoint_types),
  sort_order, is_required (boolean),
  trigger_on_complete (json: action khi CP này pass — trigger gì?),
  override_config (json: config đặc thù cho CP trong set này)

checkpoint_instances (ĐÃ CÓ — đã đúng kiến trúc)
  id, checkpoint_type_id, target_collection, target_item_id,
  set_id (FK → checkpoint_sets — biết instance thuộc set nào),
  status, verified_by_type, verified_by_id, evidence, notes

Khoản 3: Tái sử dụng — SSOT tuyệt đối

1 checkpoint type (CP-001) → nằm trong nhiều sets → dùng trong nhiều workflows.
Sửa CP-001 (mô tả, tiêu chí) = sửa 1 chỗ → áp dụng mọi nơi. ĐÂY MỚI LÀ SSOT THỰC SỰ.
Trước đây: copy checkpoint text vào mỗi task → sửa 1 chỗ, quên 9 chỗ → mỗi checkpoint thành nhiều SSOT → SAI.
Sau này: trỏ về CP-001 → sửa CP-001 → 10 task tự cập nhật → 1 SSOT duy nhất.

Khoản 4: Metadata checkpoint

Mỗi checkpoint type phải trả lời được:

"CP này nằm trong tổ hợp nào?" → query checkpoint_set_items WHERE type_id = CP-001
"CP này đang dùng ở đâu?" → query checkpoint_instances WHERE checkpoint_type_id = CP-001
"CP này là trigger của gì?" → query trigger_on_complete trong set_items
"CP này mồ côi không?" → type mà không trong set nào + không có instance → mồ côi → cảnh báo

Khoản 5: Liên kết với Node và State Machine

workflow_steps thêm field: checkpoint_set_id (FK → checkpoint_sets)
Khi entity đến node → hệ thống đọc checkpoint_set_id → tạo instances cho mọi CP types trong set
Process mode: hoàn thành set → auto chuyển next step
State machine mode: hoàn thành set = 1 điều kiện, nhưng có thể cần thêm trigger khác để chuyển state

Các đề xuất sau từ GPT Council Review đã được xem xét nhưng KHÔNG bổ sung vào Hiến pháp vì vi phạm Luật Tận dụng (Điều 7):

Đề xuất	Lý do không áp dụng
Event Bus riêng	Directus Flows + Hooks + Agent Data Event System đủ. Xây event bus = over-engineering. Chỉ cần `event_registry` (danh sách events) — không cần bus mới.
UI Layouts Registry	Nuxt layout system + Agency OS đã có. Registry cho layouts = duplicate công cụ có sẵn. `ui_pages` đủ.
Module Runtime Contract riêng	Mở rộng `modules` collection thêm fields (data_sources, events, dependencies) — không tạo collection riêng.
Config Versioning riêng	Directus `directus_revisions` ĐÃ CÓ version history cho MỌI item change. Chỉ cần khai thác, không cần xây mới.

MỤC LỤC VĂN BẢN KIẾN TRÚC

File	Hiệu lực	Nội dung
`index.md`	HIẾN PHÁP	Văn bản này — 34 Điều Luật tối cao (v3.8 S133)
`information-atom-law.md`	LUẬT NỀN TẢNG v2.0	Luật Thực thể Được Quản trị (Điều 0) — Nhận diện: ID + registry + metadata + Lớp 3. Thuật ngữ sửa S111.
`composition-level-law.md`	LUẬT PHÂN TẦNG v3.0	Điều 0-B: 7 tầng cấu tạo. Nguyên tử (Tầng 1) → Phân tử → Hợp chất → Vật liệu → Sản phẩm → Công trình. Hoà giải Điều 0 + 0-B. GPT/Gemini reviewed.
`constitution-amendment-measurement.md`	BỔ SUNG v3.8	Điều 0-S (Single Provider), 0-M (Đo lường phổ quát), 0-L (Dùng lại). Bảng 10 providers. S132.
`layer3-information-law.md`	LUẬT PHỨC TẠP NHẤT	Luật Tổ chức Lớp 3 v2.0 — 8 Quy tắc Quan hệ, Discovery-First, ER Model + Graph Theory + Ontology
`semantic-linking-engine.md`	SSOT kỹ thuật v1.2	Kiến trúc Vòng lặp Vô tận — 3 lớp kết nối, UI Wikipedia, Lớp 3 bốn sections
`label-law.md`	LUẬT v1.3 CHÍNH THỨC	Luật Nhãn (Điều 24) — ĐÓNG BĂNG. 6×6 Faceted Classification. 8 rounds GPT+Gemini review. ĐỒNG THUẬN.
`duplicate-prevention-law.md`	LUẬT v1.2	Luật Chống Trùng Lặp — 3 cấp, namespace, canonical dictionary, AI tự điền, SLA. Council: Gemini + GPT
`vps-infrastructure-law.md`	LUẬT v1.0	Luật Hạ tầng VPS — VPS-First, PostgreSQL đích đến, Local Storage, Danh sách trắng dịch vụ ngoài
`regression-protection-law.md`	LUẬT v1.2 BAN HÀNH	Điều 30: Luật Bảo vệ Hồi quy — Playwright E2E, 4 tầng bảo vệ, contracts. Council approved.
`system-integrity-law.md`	LUẬT v1.2 BAN HÀNH	Điều 31: Luật Toàn Vẹn — Contracts, Runner, WATCHDOG, Methodology "2 bài toán". Council approved.
`dieu31-methodology.md`	Phương pháp v2.0	Methodology: PG = chân lý, 2 bài toán, evidence reproducible. S132.
`dieu31-pg-technical-design.md`	Thiết kế v2.0	Universal Measurement Framework — 3 lớp kiến trúc, law_catalog, measurement_registry, measurement_log. S132.
`species-taxonomy-complete.md`	SSOT v1.2	Species Taxonomy — 33 species, 7 dimensions, 138 mappings. S157.
`birth-registry-law.md`	LUẬT v1.0	Điều 0-G: Luật Khai Sinh — birth_registry, inspection pipeline, orphan detection. S157.
`collection-classification-law.md`	LUẬT v2.0	Điều 29: 1 hệ thống, species gom, governance_role. S160.
`5-layers.md`	Luật chi tiết v2.0	5 tầng kiến trúc — S109 cập nhật Tầng 2+5
`entity-lifecycle.md`	Luật chi tiết	Quy trình sinh thực thể — checklist bắt buộc
`sync-governance.md`	Luật chi tiết	Đồng bộ + phát hiện bất đồng bộ
`tools-inventory.md`	Tài liệu kỹ thuật	Rà soát công cụ có sẵn — gaps analysis
`automation-gaps-review.md`	Self-review	7 điểm gãy tự động hoá — Claude đọc lại từ đầu
`roadmap.md`	Kế hoạch	Lộ trình xây dựng kiến trúc

LỘ TRÌNH XÂY DỰNG KIẾN TRÚC — XƯƠNG SỐNG

PHASE 0: NỀN TẢNG TÀI LIỆU (S105 ✅ hoàn thành)

Ban hành Hiến pháp Kiến trúc (v1.7 — 14 Điều)
Soạn 5-layers, entity-lifecycle, sync-governance, tools-inventory
Self-review tự động hoá → 16 điểm gãy → Điều 10-14
7 vòng review (Claude + GPT v1/v2 + Gemini v1/v2 + Claude Code + Huyen)
Inject Hiến pháp (Điều 10): ✅ PR #449 — CLAUDE.md + AGENTS.md + .claude/skills/incomex-rules.md cập nhật checklist 10 mục + PREFIX table
Điều chỉnh cấu trúc tài liệu cho phù hợp tầm nhìn mới
Fix DOT tools registry ✅ (PR #451): dot_tools collection tạo, 97 records populated. dot-catalog-sync có nhưng chưa auto cron.
Audit Agency OS collections: 20+ os_* collections → chưa audit
Dọn CI workflows ✅ (PR #453): Xoá firebase-deploy + terraform-infra + terraform-apply. Fix deploy chain: Nuxt CI → VPS → E2E. 11 workflows GREEN.
Bổ sung SSOT direction vào sync-governance
Bổ sung MODIFY + DELETE + MERGE vào entity-lifecycle.md (Điều 12)
Viết skeleton Tầng 4 (layer4-skeleton.md)
Ghi permission matrix cho tất cả registry collections mới

PHASE 1: VÁ TẦNG 2 — METADATA + REGISTRY (ưu tiên cao nhất)

Chiến lược 4 bước: EXPLOIT → FILL → LOCK → ENFORCE (Gemini vòng 2)

EXPLOIT: ✅ DONE — Khai thác /schema/snapshot, meta.note, meta.group
FILL: ✅ DONE — 100% field notes, 100% collection notes, 86.8% groups (PR #450)
LOCK: 🔴 CHƯA — Hook enforcement chặn "đẻ bừa"
ENFORCE: 🟡 BẮT ĐẦU — CLAUDE.md injected (PR #449), CI guard chưa deploy

Checklist:

FIX SYNC ✅ CHECKPOINT 1 PASS (S105): 21 [DOT-REG] flows cho 7 registry collections. Anti-loop verified. DOT tool: dot-flow-setup-registry-sync. PR #446.
TẠO DOT TOOLS CỐT LÕI ✅ (PR #449+#450): dot-schema-snapshot ✅, dot-schema-diff ✅, dot-metadata-audit ✅, dot-metadata-fill ✅. 4/7 tools cốt lõi đã có.
Schema snapshot baseline ✅ (PR #449): dot/snapshots/schema-2026-03-06.json — 106 collections, 1091 fields
Metadata audit ✅ (PR #449): 468/695 fields thiếu note (67.3%), 38/106 collections thiếu note → báo cáo uploaded
AI auto-fill metadata ✅ (PR #450): dot-metadata-fill — 695 fields filled Vietnamese, 38 collections filled, 28 groups assigned. Coverage: fields 32.7% → 100%, collections 64.2% → 100%.
Điền meta.group ✅ (PR #450): 86.8% coverage (14 ungrouped = top-level parents, đúng thiết kế)
meta_catalog ✅ (S105): 11 records, trang /knowledge/registries hoạt động. PR #446.
dot-catalog-sync ✅ (S105): Script scan DOT tools + pages + collections. PR #446.
TABLE-100% ✅ (S105): DirectusTable + tableId pattern. table_registry 8 records. PR #444+#445.
FIX-PRODUCTION ✅ (S105): Permissions, health check GREEN. PR #447+#448.
Tạo 4 registry collections ✅ (PR #451): dot_tools (97), ui_pages (39), collection_registry (113), agents (6)
Auto-ID flows ✅ (PR #451+#454): 13 flows total — PREFIX-NNN tự gán khi tạo item
Auto-count mechanism ✅ (PR #455): dot-orphan-scan updates actual_count + record_count
Drill-down UI 3 lớp ✅ (PR #451): Lớp 1→Lớp 2→Lớp 3 liên thông, dynamic [entityType] pages
Diff detection tool ✅ (PR #451): dot-registry-diff quét thực tế vs SSOT
Fix modules ✅ (PR #451): Permissions fixed + 4 modules populated
Nâng cấp modules collection theo schema chuẩn
Ban hành bảng mã Prefix chuẩn ✅: 13 auto-ID flows enforce PREFIX, bảng Prefix trong Điều 2

PHASE 2: ENTITY LIFECYCLE + DEPENDENCY + SCHEMA GOVERNANCE + CHECKPOINT/NODE IDENTITY

Tạo DOT scripts chuẩn: dot-entity-create, dot-field-create, dot-table-register, dot-module-register — TẤT CẢ phải idempotent + verify step cuối (Điều 11)
Bổ sung MODIFY + DELETE scripts: dot-entity-deprecate, dot-entity-retire, dot-field-rename (Điều 12)
Tạo entity_dependencies collection (Điều 8) — ghi nhận mọi liên kết giữa thực thể
dot-dependency-scan — quét Directus relations + codebase → populate dependencies
Populate dependencies cho thực thể hiện có (field→collection→page→module)
Tạo schema_change_requests hoặc mở rộng WCR thêm type=schema (Điều 9)
Tạo checkpoint_sets + checkpoint_set_items ✅ (PR #454): 2 collections, M2O relations, permissions, 2 seed sets
Chuẩn hoá checkpoint_types.code → CP-NNN ✅ (PR #454): 31 records CP-001..CP-031, legacy_code preserved
Chuẩn hoá workflow_steps.code → ND-0001 ✅ (PR #454): 70 records ND-0001..ND-0070, auto-ID flow
Gắn checkpoint_set_id vào workflow_steps ✅ (PR #454): Nullable FK → checkpoint_sets
Tạo dot-duplicate-engine (Điều 14 — TD-083): 1 tool quét MỌI entity type, 2 cấp độ (nghi ngờ + trùng chính xác), tích hợp vào vòng đời sinh thực thể
Mở rộng modules collection: thêm data_sources, events, dependencies
Tạo event_registry — danh sách events trong hệ thống
Directus Hook extension: chặn tạo collection/field không qua DOT (enforcement)
CI guard: tạo file mới phải có registry record
ORPHAN SCANNER ✅ (PR #455 — Điều 19): dot-orphan-scan 488 lines, quét 12 nguồn, Coverage 100% (399 entities). 3 fields mới meta_catalog (actual_count, orphan_count, last_scan_date). 6 orphans found + registered. Side B hoạt động.
Entity Dependencies ✅ (PR #456 — Điều 8): entity_dependencies 90 records, DEP-NNNN, dot-dependency-scan
Lớp 3 Section-Based ✅ (PR #460-#461 — Điều 20): 6 entity types, auto-link, SectionRelation, SectionDependency
Lớp 3 Discovery-First (TD-105 — Điều 21): ĐANG CHẠY. dot-relation-discover + discovery fallback + dot-layer3-audit
Tạo dot-duplicate-engine (Điều 14 — TD-083): 1 tool quét MỌI entity type, 2 cấp độ

PHASE 3: SYNC MONITOR + SELF-HEALING + SEMANTIC LINKING + MULTI-DOMAIN — TẦNG 5 CƠ BẢN

dot-schema-diff ✅ (PR #449) — phát hiện schema drift
dot-metadata-audit ✅ (PR #449) — phát hiện metadata trống
dot-registry-diff ✅ (PR #451) — phát hiện lệch registry vs thực tế
dot-registry-sync + dot-registry-scan — so sánh registries ↔ codebase CHỦ ĐỘNG
Cron job (Directus Flow hoặc external) chạy tất cả checks mỗi 30 phút
SEMANTIC LINKING ENGINE (Điều 20 — TD-100):
- Nâng cấp Lớp 3 UI: crossRefConfig per entity type, Lớp A + B hiển thị
- Embed entity descriptions vào Qdrant (batch job)
- API endpoint cross-references
- Lớp C hiển thị trên UI với confidence score
dot-catalog-sync auto (TD-085): Chạy tự động sau mỗi deploy
Trigger realtime mở rộng (TD-089): Audit + tạo flows cho collections quan trọng thiếu trigger
domains collection (TD-086): Thay thế globals singleton, multi-domain ready
i18n foundation (TD-087): vi-VN + ja-JP vào languages, @nuxtjs/i18n, locale files
dot-domain-create workflow (TD-088): Script tự động thêm domain (nginx + SSL + record)
Disaster recovery runbook (TD-090)
dot-duplicate-engine (TD-083): Chống double tổng quát
Auto tạo ai_task khi phát hiện vấn đề
Self-healing pipeline: detect → classify → propose → review → apply → verify
Orchestrator tạm: ai_tasks + Orchestrator script (PR #389)
Prefect design: CHƯA DEPLOY — chỉ thiết kế

PHASE 4: XÂY LẠI TẦNG 3 TRÊN NỀN ĐÚNG + STATE MACHINE

Table Module đọc 100% config từ table_registry (đã bắt đầu PR #445)
Workflow Module dùng entity lifecycle chuẩn
Workflow Module hỗ trợ state machine mode (Điều 15 — TD-079)
Journey Templates collection (Điều 15 Khoản 5 — TD-082): journey_templates + journey_template_steps (M2M)
Checkpoint set integration (Điều 16): Node gắn checkpoint_set_id → auto tạo instances
Entity state tracking: current_step_id + journey_template_id trên contacts/agents/deals
State history collection: Lịch sử chuyển trạng thái
Tester Module tích hợp Sync Monitor + Duplicate Engine

PHASE 5: SẴN SÀNG TẦNG 4

Tầng 2 metadata PASS ✅ (100%)
Tầng 2 registry đủ ✅ (13/13 active, 13 auto-ID flows, coverage 100%)
Tầng 3 modules ổn định
State machine mode hoạt động (Điều 15)
Checkpoint sets hoạt động (Điều 16)
Entity state tracking cho contacts/agents/deals
Bắt đầu quy trình nghiệp vụ đầu tiên (Customer Journey state machine)
Multi-domain live (Điều 17): domains collection, ≥2 domains
i18n live (Điều 17): ≥2 ngôn ngữ
dot-domain-create (Điều 18): thêm domain = 1 lệnh
Duplicate Engine (Điều 14): chống double mọi entity

Nguyên tắc lộ trình: Mỗi Phase PHẢI PASS trước khi sang Phase tiếp. Không nhảy cóc.

ĐIỀU 17: LUẬT ĐA NGÔN NGỮ + ĐA DOMAIN — 1 HỆ THỐNG, NHIỀU GƯƠNG MẶT (S106 — Huyen)

Khoản 1: Nguyên tắc

Hệ thống Incomex PHẢI sẵn sàng phục vụ NHIỀU domain, NHIỀU ngôn ngữ, NHIỀU thương hiệu — từ 1 codebase duy nhất + 1 Directus instance duy nhất. Mỗi domain là 1 "gương mặt" khác nhau của cùng 1 hệ thống.

Tầm nhìn: Mỗi mảng kinh doanh có domain riêng. Nhiều công ty dùng hệ thống tương đồng, chỉ khác logo + domain + theme. i18n: Việt-Nhật-Anh (ít nhất).

Khoản 2: Kiến trúc Multi-Domain

User → Nginx (route by domain) → Nuxt SSR (đọc host header)
  → Query `domains` WHERE domain_name = request.host
  → Lấy: brand, logo, theme, languages, content filters
  → Render cùng code, khác UI/nội dung

1 Directus + 1 Nuxt + 1 VPS. Thêm domain = thêm record + nginx config + SSL. Không deploy lại code.

Khoản 3: Collection `domains` — thay thế `globals` singleton

domains: id, code (DOM-001), domain_name (unique), brand_name, tagline,
  logo_light, logo_dark, favicon, theme (json), languages (M2M),
  default_language, contact_*, social_links, og_image,
  ssl_status, dns_status, nginx_configured, status

Khoản 4: i18n — 3 ngôn ngữ tối thiểu (vi-VN, ja-JP, en-US)

Thêm vi-VN + ja-JP vào languages (hiện THIẾU)
Cài @nuxtjs/i18n module
Content translations qua Directus _translations pattern
UI translations qua locale files
Permalink KHÔNG dịch — giữ slug tiếng Việt

Khoản 5: Workflow thêm Domain — tự động tối đa

dot-domain-create --name="domain2.com" --brand="X" --languages="vi-VN,en-US"
  → 1. Tạo record `domains` (DOM-NNN)
  → 2. Generate nginx server block (template)
  → 3. Certbot SSL
  → 4. Reload nginx
  → 5. Content skeleton
  → 6. Verify: curl → 200
  → 7. Update registries

User chỉ cần: mua domain + trỏ DNS. Còn lại hệ thống tự làm.

Khoản 6: Trigger/Webhook — Mọi biến động phản hồi ngay

Lớp 1 — Realtime: Directus Flows event trigger → action ngay. Lớp 2 — Safety net: Scheduled scan mỗi 30 phút → phát hiện diff nếu Lớp 1 fail → cảnh báo + ai_task.

ĐIỀU 18: LUẬT SẴN SÀNG CHO THAY ĐỔI — WORKFLOW CHO MỌI LOẠI THAY ĐỔI (S106 — Huyen)

Khoản 1: Nguyên tắc

Hệ thống PHẢI có workflow sẵn sàng cho MỌI loại thay đổi có thể xảy ra. Không "xảy ra rồi mới nghĩ cách".

Khoản 2: Danh sách thay đổi cần workflow

Thay đổi	Workflow	Status
Thêm domain	dot-domain-create + checklist	❌ TD-088
Bỏ domain	dot-domain-retire	❌
Thêm ngôn ngữ	languages record + locale files	❌ TD-087
Thêm collection	dot-entity-create	🟡
Thêm module	dot-module-register	🟡
Thêm agent	agents record + config	🟡
Thêm workflow (state machine)	Chưa thiết kế	❌ TD-079
Backup restore test	dot-backup-test-restore	❌ TD-091
VPS migration	dot-vps-setup	❌ TD-092
Chuyển Firestore → PostgreSQL	dot-migrate-firestore	✅ DONE S109b
Chuyển GCS Buckets → VPS local	dot-migrate-buckets	✅ DONE S109b
Chuyển Artifact Registry → GH direct	dot-migrate-artifact	✅ DONE S109b
Chuyển Directus MySQL → PostgreSQL	dot-migrate-directus-pg	✅ DONE S109b
Disable GCP billing	manual (1 click)	🔴 CHỜ Huyen xác nhận
Directus upgrade	dot-directus-upgrade	❌ TD-093
Scale VPS	Thủ công	❌
Disaster recovery	Recovery runbook	❌ TD-090
Rotate secrets	keys-refresh	✅

Khoản 3: Mỗi workflow phải có

Trigger rõ ràng, checklist bước có verify, rollback plan, notify, registry update.

Khoản 4: Phát hiện "chưa sẵn sàng"

Loại thay đổi nào CHƯA CÓ workflow → GHI TD ngay. Tư duy PHÒNG NGỪA.

ĐIỀU 19: LUẬT KIỂM KÊ NGƯỢC — ORPHAN SCANNER (S106 — Huyen đề xuất)

Đây là LÁ CHẮN CUỐI CÙNG đảm bảo mục tiêu "100% có ID".

Định nghĩa orphan (v3.9 — đồng thuận hội đồng Điều 26): Một thực thể bị xem là orphan khi thiếu birth record HOẶC thiếu tập quan hệ tối thiểu bắt buộc để được nhìn thấy và quản trị trong graph hệ thống.

Khoản 1: Nguyên tắc 2 chiều

Hệ thống PHẢI có 2 cơ chế kiểm soát chạy SONG SONG:

SIDE A — BIRTH REGISTRY (thuận — phòng ngừa):
  Khi sinh ra → gán ID → đăng ký
  Lỗ hổng: agent bỏ qua, hệ thống tự tạo, thao tác thủ công

SIDE B — ORPHAN SCANNER (ngược — phát hiện):
  Quét MỌI THỨ tồn tại → so với TẤT CẢ registries
  Bất kỳ thứ gì KHÔNG trong registry = ORPHAN = cảnh báo
  BẮT MỌI THỨ SIDE A ĐỂ LỌT.

Side A + Side B = ĐẢM BẢO 100% entities có ID + registry.

Side A đã có (Auto-ID Flows, DOT scripts, entity lifecycle). Side B ✅ ĐÃ TẠO (PR #455 dot-orphan-scan, coverage 100%).

Khoản 2: Orphan Scanner — quét MỌI nguồn

Tool dot-orphan-scan quét TOÀN BỘ hệ thống, so sánh với TOÀN BỘ registries:

Nguồn thực tế	Cách quét	So với registry
Directus collections	API list_collections	collection_registry
Fields (có note?)	API /fields per collection	meta.note != null
DOT tools	ls dot/bin/dot-*	dot_tools
Pages/Routes	find web/pages/ *.vue	ui_pages
Workflow steps	query workflow_steps	field code != null
Checkpoint types	query checkpoint_types	field code format CP-NNN
Checkpoint sets	query checkpoint_sets	field code format CPS-NNN
Nginx server blocks	grep server_name	domains registry
Docker containers	docker ps	infrastructure docs
Env vars	printenv	documented
CI workflows	ls .github/workflows/	documented
Agent Data docs	list_documents	có title + tags?

Khoản 3: Coverage Dashboard — output bắt buộc

dot-orphan-scan output 1 COVERAGE REPORT:

═══ SYSTEM COVERAGE REPORT ═══
TỔNG QUAN: X/Y entities có ID + registry = Z% coverage
           N ORPHANS cần xử lý

CHI TIẾT:
  Collections:      113 actual, 106 registered → 93.8% ⚠️ 7 orphans
  DOT Tools:         95 actual,  93 registered → 97.9% ⚠️ 2 orphans
  Workflow Steps:    72 actual,  72 registered → 100%  ✅
  ...

ORPHAN LIST:
  COL: checkpoint_sets (mới tạo, chưa đăng ký)
  ...

Report upload tự động vào Agent Data. Nếu coverage < 100% → tạo ai_tasks cho từng orphan.

Khoản 4: Mối quan hệ Side A ↔ Side B

Agent tạo entity MỚI:
  → Side A (Birth Registry): gán ID + đăng ký → thành công? → OK
  → Side A fail (quên/lỗi)? → entity tồn tại nhưng vô hình
  → Side B (Orphan Scanner) quét → phát hiện orphan → cảnh báo
  → Fix: đăng ký retroactive HOẶC xoá nếu không cần

Scheduled:
  → Side B chạy mỗi ngày (hoặc sau mỗi deploy)
  → Output: coverage % → target 100%
  → Nếu < 100% → User + AI biết CHÍNH XÁC cái gì mồ côi
  → TỆ NHẤT: user vẫn được biết tình trạng thực tế

Khoản 5: Mục tiêu coverage

Giai đoạn	Mục tiêu	Hành động	Trạng thái
Phase 2	≥95% coverage	Fix orphans, auto-ID hoạt động	✅ ĐẠT 100% (PR #455)
Phase 3	≥99% coverage	Orphan scan sau mỗi deploy	🟡 Tool có, cron chưa cài
Phase 4+	100% duy trì	Orphan scan + auto-fix	🔴 Chưa

Khoản 6: Không có Side B = mục tiêu chỉ là lý thuyết

Nếu chỉ có Side A mà không có Side B: mọi thứ sinh ra "lý thuyết" đều có ID, nhưng thực tế luôn có lỗ hổng. Càng xây cao, lỗ hổng càng tích lũy. Đến lúc phát hiện → gỡ cực khó. Side B là bảo hiểm — không phải luxury, mà là BẮT BUỘC.

ĐIỀU 20: LUẬT KẾT NỐI NGỮ NGHĨA — VÒNG LẶP VÔ TẬN (S107 — Huyen + Claude)

Đây là ĐÍCH ĐẾN CUỐI CÙNG của hệ thống Registry. Điều 2-19 xây nền — Điều 20 biến ID thành MẠNG LƯỚI TRI THỨC.

Khoản 1: Nguyên tắc Wikipedia

Mọi thực thể trong hệ thống khi đã có ID (Điều 2) và metadata (Điều 3) phải được KẾT NỐI với nhau qua 3 lớp liên kết. Click vào bất kỳ link → trang mới → link mới → không bao giờ có "trang cuối cùng". Giống Wikipedia: mạng lưới tri thức tự mở rộng vô tận.

Khoản 2: Ba lớp kết nối bắt buộc

Lớp A — Explicit Relations (quan hệ cứng): Quan hệ trực tiếp trong schema Directus (M2O, M2M, FK). Đọc từ entity_dependencies collection (Điều 8) và Directus relations. Ví dụ: CP-005 thuộc CPS-001, ND-0007 thuộc WF-001. Confidence = 1.0 (chắc chắn).

Lớp B — Classification Relations (cùng nhóm): Entities cùng classification, category, layer, owner → tự động hiển thị cạnh nhau. Không cần khai báo thủ công — logic đọc metadata có sẵn. Ví dụ: CP-005 + CP-012 cùng category: "ci".

Lớp C — Semantic Relations (AI phát hiện): Dùng vector embeddings (Qdrant đã có trên VPS) so sánh description của entities. Cosine similarity ≥ 0.70 = liên quan. Ưu tiên cross-type (khác loại entity) để mạng lưới đa chiều. Ví dụ: CP-005 "Code Review" ≈ DOT-042 "dot-health-check" (cùng domain CI).

Khoản 3: UI — Trang Lớp 3 = Trang Wikipedia

Trang /knowledge/registries/[entityType]/[id] PHẢI hiển thị đầy đủ: thông tin cơ bản + Lớp A (link trực tiếp) + Lớp B (cùng nhóm) + Lớp C (ngữ nghĩa) + lịch sử. Mỗi link trong cross-references → trang Lớp 3 tương ứng → có cross-references riêng → VÒNG LẶP.

Khoản 4: Config-driven, không code

Thêm entity type mới = thêm crossRefConfig block. KHÔNG viết component mới cho mỗi loại. Assembly First (Điều 7).

Khoản 4b: ID là chìa khoá vạn năng — Linking + Permissions (S107 — Huyen)

Tư duy cốt lõi: ID không chỉ để LIÊN KẾT — ID còn là nền tảng PHÂN QUYỀN. Mọi section trong Lớp 3 đọc data từ Directus collection → Directus permission system (Role → Collection → Field) TỰ ĐỘNG kiểm soát ai thấy gì.

Super Admin  → READ all collections → thấy MỌI section
Admin nhóm A → READ workflows, checkpoints → thấy sections liên quan
Nhân viên    → READ tasks only → chỉ thấy section tasks
Public       → READ public fields only → thấy basic info

UI Logic: section trống/403 → TỰ ĐỘNG ẩn. KHÔNG code permission riêng.

Kết quả: 1 trang Lớp 3, nhiều "gương mặt" tuỳ role. Cùng CP-005 nhưng Super Admin thấy 6 sections, nhân viên thấy 2 sections. Directus làm tất cả — không cần 1 dòng permission code.

Khoản 5: Tự duy trì

dot-dependency-scan: quét Directus relations → populate entity_dependencies. Chạy sau mỗi deploy.
Semantic embed: batch job hàng ngày, embed descriptions mới/thay đổi.
Lớp A + B hoạt động KHÔNG CẦN Lớp C. Lớp C là bonus, không blocking.

Khoản 6: Hệ thống kiểm soát 4 tầng hoàn chỉnh

Tầng 1: BIRTH REGISTRY      → Sinh ra có ID           (Side A)
Tầng 2: ORPHAN SCANNER      → Tìm mồ côi             (Side B)  
Tầng 3: DUPLICATE ENGINE    → Không trùng             (Điều 14)
Tầng 4: SEMANTIC LINKER     → Kết nối ngữ nghĩa      (Điều 20) ★

Tầng 1-3 = BẢO VỆ (đảm bảo sạch). Tầng 4 = GIÁ TRỊ (biến data thành tri thức).

SSOT chi tiết: search_knowledge("semantic linking engine vòng lặp")

ĐIỀU 21: LUẬT TỔ CHỨC LỚP 3 — MỖI OBJECT LÀ 1 DB VỀ CHÍNH NÓ (S107 — Huyen)

Đây là LUẬT PHỨC TẠP NHẤT trong hệ thống Hiến pháp. Tách riêng thành văn bản chi tiết.

Khoản 1: Nguyên tắc "Đúng, đủ, sạch, sống"

Mỗi entity có ID trong hệ thống KHÔNG CHỈ là 1 dòng data — nó phải là 1 DB VỀ CHÍNH NÓ. Áp dụng nguyên tắc dữ liệu quốc gia Việt Nam: Đúng (data khớp thực tế), Đủ (không thiếu quan hệ nào), Sạch (không trùng, không orphan), Sống (tự cập nhật khi data thay đổi).

Khoản 2: 8 Quy tắc Quan hệ Phổ quát (v2.0 — nâng từ 6 → 8)

BẤT KỲ entity nào có ID đều có ĐÚNG 8 loại quan hệ — dựa trên Entity-Relationship Model (Chen 1976) + Graph Theory + Ontology (OWL/RDF):

Nhóm A (Bản thân): 1-IDENTITY. Nhóm B (Cấu trúc): 2-BELONGS_TO ↑, 3-CONTAINS ↓. Nhóm C (Phụ thuộc): 4-DEPENDS_ON → ★, 5-USED_BY ←, 6-TRANSITIVE →→→ ★. Nhóm D (Ngầm): 7-PEERS ↔, 8-SIMILAR ~.

★ DEPENDS_ON = "tôi CẦN gì?" (khác BELONGS_TO = "tôi NẰM TRONG ai?"). Page depends_on collection nhưng không belongs_to collection. ★ TRANSITIVE = bắc cầu: CP-005→CPS-001→ND-0007→WF-001. Nhìn toàn cảnh mà không click 3 lần.

Khi phát hiện thiếu → kiểm tra 8 quy tắc → sửa quy tắc/DOT → áp dụng TOÀN HỆ THỐNG.

BẤT KỲ entity nào có ID đều có ĐÚNG 6 loại quan hệ — không liệt kê từng case mà áp dụng quy tắc:

#	Quy tắc	Hướng	Câu hỏi
1	IDENTITY	—	"Tôi là ai?"
2	BELONGS_TO	↑	"Tôi thuộc về ai?"
3	CONTAINS	↓	"Tôi chứa gì?"
4	USED_BY	←	"Ai đang dùng tôi?"
5	PEERS	↔	"Ai giống tôi?"
6	SIMILAR	~	"Ai liên quan ngữ nghĩa?"

Khi phát hiện thiếu → kiểm tra quy tắc nào vi phạm → sửa quy tắc hoặc sửa DOT → áp dụng TOÀN HỆ THỐNG. KHÔNG sửa cho 1 object rồi bỏ qua.

Khoản 3: Discovery-First

Entity type mới = TỰ CÓ Lớp 3 mà KHÔNG CẦN viết config. Hệ thống tự phát hiện quan hệ từ Directus schema + entity_dependencies. Config chỉ dùng khi cần TUỲN CHỈNH, không phải bắt buộc.

Khoản 4: Hạ tầng Thông tin

Lớp 3 là ĐẠI DIỆN của Tầng 2 (Hạ tầng Thông tin). Tầng 1 = hạ tầng kỹ thuật. Tầng 2 = hạ tầng thông tin. Lớp 3 phục vụ MỌI nhu cầu tương lai của Tầng 4 (Business workflows).

Ma trận đa chiều (v3.9 — đồng thuận hội đồng Điều 26): Ma trận đa chiều là hình thức biểu diễn chuẩn của Layer 5 để thể hiện quan hệ thật và dữ liệu dẫn xuất từ PostgreSQL theo nhiều chiều đồng thời. Layer 5 = GROUP BY N chiều, số chiều KHÔNG cố định.

SSOT chi tiết: search_knowledge("luật lớp 3 hạ tầng thông tin")

ĐIỀU 22: LUẬT TỰ SỬA CHỮA + TỰ CẢI TIẾN — HỆ THỐNG PHẢI TỰ BIẾT MÌNH SAI VÀ TỰ SỬA (S108 — Huyen)

Đây là TẦM NHÌN CUỐI CÙNG. Mọi Điều trước (0-21) chỉ là PHƯƠNG TIỆN để đạt Điều 22.

Khoản 1: Nguyên tắc — Vòng lặp Tự sửa chữa (Self-Healing Loop)

Hệ thống PHẢI có khả năng TỰ PHÁT HIỆN vấn đề, TỰ LIỆT KÊ, TỰ SỬA CHỮA, và TỰ CẢI TIẾN — mà KHÔNG CẦN con người chỉ ra từng lỗi. Con người chỉ kiểm tra mang tính XÁC SUẤT, không phải kiểm tra TOÀN BỘ.

NHẬN DIỆN → LIỆT KÊ → XỬ LÝ → XÁC NHẬN → CẢI TIẾN → (lặp lại)

1. NHẬN DIỆN: DOT/Script quét định kỳ + Directus Flows realtime
   → Phát hiện: Lớp 2 trống, Lớp 3 thiếu link/quan hệ, orphan, diff, data sai
2. LIỆT KÊ:   Ghi vào `system_issues` collection
   → Phân loại: lỗi (bug) | thiếu dữ liệu | cần tối ưu | đề xuất cải tiến
3. XỬ LÝ:     Script tự fix (rule rõ) HOẶC Agent đọc → tạo task → fix → verify
4. XÁC NHẬN:  Quét lại → issue resolved? → đóng. Chưa → escalate
5. CẢI TIẾN:  Phân tích pattern lỗi → đề xuất thay đổi quy trình/kiến trúc

Bài học S108: 1 hệ thống chỉ báo cáo mà KHÔNG tự kiểm tra = thảm hoạ nếu báo cáo sai. Cần kiểm tra CHÉO: hệ thống A kiểm tra hệ thống B, hệ thống B kiểm tra hệ thống A. Nếu phát hiện khác → cảnh báo NGAY.

Khoản 2b: Nguyên tắc Kiểm chứng ngược — Sổ kế toán kép (S108 — Huyen)

"2×3=6, kiểm chứng 6÷3=2." — MỌI số liệu trong hệ thống phải có ÍT NHẤT 2 hướng đếm ĐỘC LẬP.

Áp dụng cho TẤT CẢ thống kê đã làm VÀ sẽ làm từ nay — không chỉ nhật ký, không chỉ 1 nơi:

Summary cards (tổng nguyên tử, tổng loại, tổng mồ côi)
Mỗi dòng meta_catalog (record_count, actual_count, orphan_count)
system_issues count
Changelog count
Lớp 2 item counts
BẤT KỲ thống kê nào tạo ra trong tương lai

2 hướng đếm bắt buộc:

HƯỚNG XUÔI (snapshot): "Bây giờ có bao nhiêu?" → đếm trực tiếp từ nguồn
HƯỚNG NGƯỢC (transaction log): "Bắt đầu bao nhiêu + tạo - xoá = bao nhiêu?" → tính từ nhật ký
SO SÁNH: Xuôi = Ngược → TIN ĐƯỢC. Xuôi ≠ Ngược → CẢNH BÁO NGAY.

Quy tắc cho tương lai: Bất kỳ script/tính năng MỚI nào tạo ra số liệu → BẮT BUỘC kèm cơ chế kiểm chứng ngược TRƯỚC KHI deploy. Không có kiểm chứng ngược = số liệu NGHI VẤN = không được dùng để ra quyết định.

Nguyên tắc này áp dụng giống sổ kế toán kép (double-entry bookkeeping) — bảng cân đối phải khớp với tổng giao dịch. Không khớp = có lỗi.

Khoản 2: Ba danh mục song song trên Registries

Danh mục	Nội dung	Trạng thái
Danh mục hệ thống	17 loại nguyên tử, 711 atoms, tổng hợp	✅ Có
Danh mục vấn đề (Bugs/Issues)	Lỗi tự phát hiện: Lớp 2 trống, Lớp 3 thiếu link, orphan...	🔴 CẦN XÂY
Danh mục cải tiến (tương lai)	Đề xuất tối ưu từ AI + Con người + Quy trình Tầng 4	⬜ Kế hoạch

Ba danh mục = ba "kênh giám sát" bổ sung nhau. Mỗi kênh PHẢI tự cập nhật, không dựa vào người nhớ.

Khoản 3: Cơ chế kiểm tra chéo Lớp 2 + Lớp 3 (Integrity Audit)

Mỗi entity type trong meta_catalog PHẢI vượt qua kiểm tra tự động:

Kiểm tra	Câu hỏi	Ví dụ
Lớp 2 có DATA không?	Click Lớp 1 → Lớp 2 có danh sách items?	CAT-001 "Bảng UI" → 18 bảng phải hiện
Lớp 2 items có ID không?	Mỗi item trong Lớp 2 có field `code`?	TBL-001, TBL-002...
Lớp 3 có QUAN HỆ không?	Mỗi item có entity_dependencies?	TBL-001 → depends_on COL-xxx
Lớp 3 có LINK không?	Nếu entity có dedicated page → link hoạt động?	WF-001 → /knowledge/workflows/1
Cross-check nhất quán?	record_count khớp items thực tế?	meta_catalog ghi 18 = table_registry có 18

Script dot-layer-integrity-audit quét TẤT CẢ 17 entity types → output danh sách vấn đề → ghi vào system_issues.

Khoản 3: Chiến lược "Phơi bày ra ánh sáng" — DOT Tầng 5 tự quét, tự liệt kê (S108 — Huyen)

Nguyên tắc cốt lõi: MỌI VẤN ĐỀ PHẢI ĐƯỢC PHƠI BÀY RA ÁNH SÁNG. Không giấu, không chờ ai hỏi.

DOT scripts Tầng 5 = hệ thống kiểm tra tự động. Chúng TỰ CHẠY (scheduled hoặc sau deploy), TỰ PHÁT HIỆN vấn đề theo các nguyên tắc Hiến pháp, TỰ LIỆT KÊ vào system_issues. Phần còn lại (AI/Agent sửa) đơn giản hơn rất nhiều khi vấn đề đã được nhận diện rõ ràng.

Phạm vi phủ sóng — mở rộng tới đâu, DOT quét tới đó:

DOT Script Tầng 5	Quét gì	Nguyên tắc kiểm tra
`dot-registry-count-refresh`	3 cột đếm per entity type	Số lượng ĐỘC LẬP, tìm khác biệt
`dot-registry-integrity-check`	Cross-check 3 cột	Nhất quán giữa các nguồn
`dot-layer-integrity-audit`	Lớp 2 có data? Lớp 3 có quan hệ? Link hoạt động?	Kiến trúc 3 lớp hoạt động đúng
`dot-selftest-registries`	Tổng hợp toàn bộ	Smoke test nhanh
`dot-orphan-scan`	Entity không có code/registry	Điều 2 (Registry-First)
`dot-duplicate-engine` (tương lai)	Entity trùng lặp	Điều 14 (Chống trùng)
`dot-relation-discover`	Entity thiếu quan hệ	Điều 21 (Luật Lớp 3)

Mỗi DOT Tầng 5 phát hiện vấn đề → ghi system_issues → hiện trên UI "Vấn đề hệ thống". Khi thêm loại kiểm tra mới = thêm DOT script → phủ sóng rộng hơn. Hệ thống TỰ PHÁT HIỆN ngày càng nhiều loại vấn đề mà không cần viết lại kiến trúc.

DOT Tầng 5 cũng là nguyên tử — cũng nằm trong Registries. Chúng đã nằm trong CAT-006 (DOT Tools). Phân loại category: "tầng_5_giám_sát" để phân biệt với DOT schema/data/flow. Khi mở rộng phủ sóng = thêm DOT vào registry = hệ thống TỰ BIẾT mình có bao nhiêu cơ chế giám sát.

Bằng chứng chiến lược hoạt động (S108): dot-layer-integrity-audit chạy lần đầu → tự phát hiện 15 vấn đề (1 nghiêm trọng: Lớp 2 trống, 14 cảnh báo: thiếu quan hệ, thiếu mã) → hiện ngay trên UI → AI/Agent/Con người THẤY NGAY mà không ai phải nhớ kiểm tra.

Khoản 4: Áp dụng cho Tầng 4 (Business) tương lai

Cùng cơ chế áp dụng cho quy trình nghiệp vụ: đề xuất của nhân viên, phản hồi khách hàng, cải tiến quy trình → tất cả vào system_issues với type="improvement" → phân loại → quy trình xử lý. Hệ thống không chỉ sửa bug mà CẢI TIẾN LIÊN TỤC.

Khoản 5: Thước đo

Hệ thống đạt Điều 22 khi: (1) Mọi vấn đề tự phát hiện TRƯỚC khi người dùng thấy. (2) ≥50% vấn đề tự sửa không cần người can thiệp. (3) Pattern lỗi lặp lại → hệ thống tự đề xuất thay đổi quy trình để không lặp lại nữa.

SSOT chi tiết: (cần tạo) search_knowledge("luật tự sửa chữa self-healing")

ĐIỀU 24: LUẬT NHÃN — PHÂN LOẠI ĐA CHIỀU CHO TOÀN HỆ THỐNG (S122 — Huyen)

Đây là LUẬT NỀN TẢNG cho phân loại. Không có Luật Nhãn → "Cùng nhóm" không hoạt động → không thể lắp ráp → mục tiêu hệ thống thất bại.

Khoản 1: Vấn đề gốc rễ

7+ hệ thống nhãn rời rạc (dot_tools.category, meta_catalog.atom_group, system_issues.issue_type...). Agent đặt tên ngẫu hứng. Không có bảng tổng. Scale = rối loạn.

Khoản 2: Giải pháp — Faceted Classification (Phân loại đa chiều)

6 CHIỀU × 6 LỚP. Mỗi chiều = 1 câu hỏi. Tổng hợp = phân loại đầy đủ.

Chiều	Câu hỏi	Đơn/Đa	Bắt buộc cho
1. Chuyên môn	Entity thuộc lĩnh vực nào?	Nhiều	Mọi lớp ★
2. Vai trò	Entity đóng vai trò gì?	1	Nguyên tử ★, Phân tử ★
3. Hành động	Entity làm gì?	Nhiều	Nguyên tử ★
4. Phạm vi	Entity ảnh hưởng đến đâu?	1	Hợp chất+ ★
5. Giai đoạn	Entity đang ở giai đoạn nào?	1	Vật liệu+ ★
6. Phục vụ ai	Entity phục vụ đối tượng nào?	Nhiều	Vật liệu+ ★

Chiều "Chuyên môn" có cấu trúc 3 tầng cha-con-cháu (M2O self-ref). Dự kiến: ~15 cha × ~10 con × ~8 cháu = ~1200 nhãn. PG recursive CTE xử lý tốt.

Khoản 3: Nhãn là thực thể được quản lý

Label CỦA nguyên tử = hạ nguyên tử (về cấu tạo)
Label CỦA phân tử trở lên = nguyên tử (về cấu tạo)
TẤT CẢ label đều được QUẢN LÝ như thực thể có ID (LBL-NNN), có registry, có metadata, có Layer cuối với 6 heading. Dù cấu tạo là hạ nguyên tử hay nguyên tử — quản lý giống nhau.

Khoản 4: SSOT DUY NHẤT — 1 bảng taxonomy

Collection taxonomy (M2O self-ref, cây phân cấp) = SSOT DUY NHẤT. Mọi nơi dùng nhãn đọc từ đây. Không dropdown hardcode. PG FK constraint enforce nhãn hợp lệ. UNIQUE constraint chặn duplicate.

Khoản 5: Gán tự động — 3 tầng quy tắc

Tầng 1 (Collection): 17 rules gán theo LOẠI entity → phủ 100% ở chiều Vai trò
Tầng 2 (Keyword): ~40 rules pattern match trên tên + mô tả → phủ ~90% chiều Chuyên môn
Tầng 3 (AI đề xuất): Entity không match → system_issues "cần phân loại" → User duyệt → thêm rule

User KHÔNG chọn tay cho từng entity. User duyệt 85 quy tắc 1 LẦN → hệ thống gán cho 500+ entities MÃI MÃI.

Khoản 6: Layer cuối — Nhãn = ĐẦU VÀO, Quan hệ = ĐẦU RA

Ma trận nhãn hiển thị ở Layer cuối mỗi entity. DOT gán tự động (chính). User chỉnh tay khi cần (phụ). Quan hệ "Cùng nhóm" + "Tương tự" = KẾT QUẢ tính từ nhãn. Chỉnh nhãn → quan hệ tự thay đổi.

Khoản 7: DOT kiểm tra

dot-label-validate: quét thiếu nhãn bắt buộc, nhãn ngoài scope → ghi system_issues
dot-label-auto-assign: gán tự động từ label_rules (PG TRIGGER hoặc scheduled)
dot-label-coverage: báo cáo % phủ sóng nhãn

Khoản 8: Assembly First — PG + Directus có sẵn

7/9 bài toán = 0 dòng code mới. PG: FK self-ref, WITH RECURSIVE, UNIQUE, TRIGGER. Directus: M2O Tree View, M2M junction, CRUD API. KHÔNG phát minh lại.

SSOT chi tiết: search_knowledge("luật nhãn label law taxonomy")

Hiến pháp Kiến trúc v3.9 | 34 Điều Luật (Điều 0-24 + 0-B + 0-G + 0-S + 0-M + 0-L + 26-31). +Điều 26 MỚI v3.5 BAN HÀNH (S141, Pivot Table, gộp Điều 32). +Điều 0-S/0-M/0-L: Single Provider, Đo lường Phổ quát, Dùng lại (S132). +Điều 31: Luật Toàn Vẹn (BAN HÀNH v1.2). +Điều 30: Luật Bảo vệ Hồi quy (BAN HÀNH v1.2). +Điều 29: Luật Phân loại Collection (S160). +Điều 28: Khuôn Mẫu Chuẩn v1.1 (S141). +Điều 0-G: Khai Sinh (S157). S105 ban hành, S106-S141 mở rộng.

PHỤ LỤC: CÁC ĐIỀU LUẬT BỔ SUNG (S157-S160)

Các điều luật dưới đây được viết thành văn bản riêng để hiến pháp không quá dài. AI/Agent PHẢI đọc khi liên quan.

Điều	Tên	File	Status
0-S	Nguyên tắc Single Provider — 1 bộ phận cung cấp, tất cả dùng lại	`search_knowledge("constitution amendment S132")`	v3.8 S132
0-M	Nguyên tắc Đo lường Phổ quát — 1 framework measurement cho mọi luật	`search_knowledge("constitution amendment S132")`	v3.8 S132
0-L	Nguyên tắc Dùng lại trước khi Tạo mới — Assembly Gate Q6	`search_knowledge("constitution amendment S132")`	v3.8 S132
0-G	Luật Khai Sinh — Birth Registry	`search_knowledge("birth registry law")`	✅ v1.0
26	Luật Registries & Đếm MỚI — Pivot Table, 3 bài toán (M2M + Pivot + Dây điện), gộp Điều 32	`search_knowledge("Điều 26 mới pivot table")`	BAN HÀNH v3.5 (S141)
28	Luật Khuôn Mẫu Chuẩn — TPL-002 DirectusMatrix chuẩn. Khuôn mẫu mới chỉ khi lặp ≥3 lần + không fit khuôn hiện có + có contract rõ (v3.9 S141)	`search_knowledge("standard template law")`	✅ v1.1
29	Luật Phân loại Collection — 1 hệ thống, species + birth TẤT CẢ	`search_knowledge("collection classification law")`	✅ v2.0
30	Luật Bảo vệ Hồi quy — Playwright E2E, máy kiểm tra máy	`search_knowledge("regression protection law")`	BAN HÀNH v1.2
31	Luật Toàn Vẹn Hệ Thống — Contract-driven verification, Nuxt↔DB tự kiểm tra, Universal Measurement Framework	`search_knowledge("system integrity verification law")`	BAN HÀNH v1.2

Quy trình: search_knowledge("birth procedures") — v3.0, QT-001→006. Thiết kế: search_knowledge("design feasibility formula") — 4 yếu tố khả thi. Species: search_knowledge("species taxonomy complete") — v1.2, 33 species.