Rà soát Tự động hoá — 17 Điểm gãy (7 vòng review + S106)

v7.0 | 2026-03-15 S122 — Patch: Nhiều điểm gãy đã fix từ S109→S122: 17 PG TRIGGER realtime đếm (thay 4 tầng code), verify_counts()=0 MISMATCH, system_issues lifecycle, Taxonomy 5 collections + auto-assign rules, Layer 1-5 navigation, 6 heading nhất quán, DOT Scanning song song. Luật Nhãn v1.3 ĐÓNG BĂNG. Hiến pháp v3.5 (25 Điều). PRs #444→#508. Góc nhìn: Nếu hệ thống chạy tự động 100%, đâu là chỗ sẽ GÃY? search_knowledge("điểm gãy tự động hoá automation gaps")

PHƯƠNG PHÁP

Đọc lại toàn bộ Architecture như người đọc lần đầu. Câu hỏi duy nhất: "Nếu không có con người giám sát, chỗ nào sẽ hỏng?"

ĐIỂM GÃY 1: AGENT KHÔNG ĐỌC HIẾN PHÁP — ⚠️ GIẢM (S106 — PHASE1-FOUNDATION inject)

Trạng thái cập nhật S106: PHASE1-FOUNDATION (PR #449) đã inject:

✅ .claude/skills/incomex-rules.md — 10-item Constitution checklist + PREFIX table
✅ CLAUDE.md — constitution warning + 5-rule summary
✅ AGENTS.md — agent profiles

Còn thiếu: Chưa verify thực tế agent CÓ đọc không (cần CI guard hoặc test).

Vấn đề: Hiến pháp nói "mọi AI phải đọc". Nhưng cơ chế thực tế là search_knowledge("hiến pháp") → đọc văn bản dài → trong context window giới hạn → agent sẽ SKIP hoặc đọc lướt. Đã xảy ra nhiều lần: Operating Rules ghi rõ "Assembly First" nhưng agent vẫn viết custom table.

Nguyên nhân gốc: Rules nằm trong Agent Data = agent phải CHỦ ĐỘNG đọc. Agent bận → quên → vi phạm. Giống luật giao thông: biển báo 60km/h có nhưng không có camera bắn tốc độ → ai cũng vượt.

Giải pháp (cần bổ sung):

CLAUDE.md + AGENTS.md (2 repos) phải chứa BẢN RÚT GỌN Hiến pháp — dạng machine-readable checklist, KHÔNG phải prose. Claude Code/Codex đọc 2 file này TỰ ĐỘNG khi khởi động. Đây là "camera bắn tốc độ".
.claude/skills/incomex-rules.md (đã tạo S104) cần cập nhật Hiến pháp rút gọn.
DOT scripts phải tự kiểm tra: trước khi chạy → verify "entity này đã có trong registry chưa?" → nếu chưa → TỰ ĐĂNG KÝ, không hỏi agent.

Nếu không fix: Agent MÃI vi phạm. Viết thêm rules = vô nghĩa nếu không inject vào nơi agent BUỘC PHẢI đọc.

ĐIỂM GÃY 2: DOT SCRIPT LỖI GIỮA CHỪNG — KHÔNG CÓ ROLLBACK

Vấn đề: dot-entity-create sẽ làm 7 bước: tạo collection → đăng ký registry → set metadata → permissions → log... Nếu bước 3 fail (network timeout, Directus restart) → collection tồn tại nhưng KHÔNG CÓ trong registry → bất đồng bộ NGAY LẬP TỨC.

Nguyên nhân gốc: DOT scripts hiện là bash scripts tuần tự. Không có transaction, không có rollback, không có idempotent check.

Giải pháp (cần bổ sung):

Mọi DOT script sinh entity PHẢI idempotent — chạy lại không tạo duplicate, tự phát hiện bước nào đã xong.
Mỗi script phải có verify step cuối: kiểm tra TẤT CẢ outputs tồn tại (collection + registry + permissions). Nếu thiếu → tự fix hoặc báo lỗi rõ ràng.
Sync Monitor (Tầng 5) phải phát hiện: "collection tồn tại nhưng không trong registry" → tạo task fix.

Nếu không fix: Hệ thống sẽ dần tích lũy bất đồng bộ "ẩn" — entity tồn tại nhưng vô hình.

ĐIỂM GÃY 3: CHỈ CÓ "SINH" — THIẾU "SỬA" VÀ "XOÁ"

Vấn đề: Entity Lifecycle chỉ mô tả quy trình SINH thực thể (birth checklist). Nhưng thực tế còn:

Đổi tên field → registry cũ trỏ sai → UI hỏng
Xoá collection → dependencies hỏng → pages crash
Gộp 2 collections → dữ liệu migrate → registry update → dependencies update
Đổi type field → data loss risk

Lifecycle hiện tại: draft → active → deprecated → retired nhưng KHÔNG NÓI: deprecate thì làm gì? retire thì xoá hay giữ? Ai quyết?

Giải pháp (cần bổ sung vào entity-lifecycle.md):

MODIFY workflow: Sửa entity → SCR (nếu schema) hoặc WCR (nếu workflow) → review → apply → update ALL registries + dependencies tự động
DELETE workflow: Xoá entity → query dependencies → nếu có → CHẶN xoá (phải deprecate trước, chờ 0 dependencies) → nếu không có → retire → archive
MERGE workflow: Gộp entities → tạo entity mới → migrate data → update dependencies → deprecate entities cũ

Nếu không fix: Hệ thống chỉ biết tạo mới, không biết dọn dẹp → phình to mãi → entity chết chất đống.

ĐIỂM GÃY 4: SYNC GOVERNANCE THIẾU SSOT DIRECTION

Vấn đề: sync-governance.md liệt kê 10 cặp đồng bộ nhưng KHÔNG NÓI: khi conflict → ai thắng?

Ví dụ: codebase có <DirectusTable> trên 1 page nhưng table_registry không có record. Hai hướng xử lý ngược nhau:

(A) Thêm record vào registry (codebase = SSOT)
(B) Xoá code khỏi page (registry = SSOT)

Nếu không quy định → agent tự quyết → mỗi lần khác nhau → rối.

Giải pháp (cần bổ sung vào sync-governance.md): Mỗi cặp sync phải ghi rõ: Nguồn nào là SSOT? Khi conflict → action là gì?

Nguồn A	Nguồn B	SSOT	Khi conflict
Directus schema	Codebase	Directus	Codebase phải adapt
`table_registry`	Codebase UI	Registry	Codebase phải dùng registry record
`dot/bin/` VPS	`dot_tools` registry	VPS (thực tế)	Registry phải sync theo VPS
Agent Data docs	Thực tế hệ thống	Thực tế	Docs phải cập nhật
`modules` collection	Codebase modules	Directus	Codebase phải đăng ký

Nếu không fix: Sync Monitor phát hiện bất đồng bộ nhưng không biết fix theo hướng nào → tạo task mà agent không biết làm gì.

ĐIỂM GÃY 5: PERMISSION MODEL CHO REGISTRY

Vấn đề: Entity lifecycle yêu cầu agent TỰ đăng ký vào registry. Nhưng Directus permissions hiện tại:

AI Agent token: READ all, CREATE/UPDATE hạn chế (chỉ một số collections)
Admin token: dùng cho DOT scripts (schema operations)

Nếu DOT script tạo collection (Admin token) rồi cần đăng ký vào collection_registry (AI Agent token hoặc Admin?) → permission model chưa rõ ràng cho registry collections mới.

Giải pháp (cần bổ sung):

Tất cả registry collections (table_registry, collection_registry, dot_tools...) phải có AI Agent CRUD permissions
DOT scripts dùng Admin token cho SCHEMA operations, nhưng dùng API call với AI Agent token cho REGISTRY operations (hoặc Admin token cho cả hai — đơn giản hơn)
Ghi rõ permission matrix cho mỗi registry collection

Nếu không fix: DOT script tạo entity xong nhưng không đủ quyền đăng ký registry → bất đồng bộ ngay.

ĐIỂM GÃY 6: AGENT DATA DOCUMENTS THIẾU METADATA CHUẨN

Vấn đề: Hiến pháp Điều 2+3 nói "mọi thứ có ID + metadata". Nhưng chính 250+ Agent Data documents — backbone của hệ thống — có metadata chuẩn không?

Kiểm tra nhanh:

Tags: không nhất quán (có file có tags, có file không)
Titles: không nhất quán (có file có title, có file dùng filename)
Path convention: knowledge/dev/ vs knowledge/current-state/ — quy ước gì?
Version: một số file có > v1.0, nhiều file không
Last updated: đa số thiếu hoặc sai

Agent Data = BỘ NÃO TRUNG TÂM. Nếu bộ não thiếu metadata → AI search sai → AI hành động sai.

Giải pháp (cần bổ sung):

Document metadata standard: Mỗi Agent Data document PHẢI có header chuẩn: title, version, updated, tags, layer (tầng kiến trúc), status
Batch audit + fix: DOT script quét tất cả documents → báo cáo thiếu metadata → AI auto-fill
Path convention enforcement: Ghi rõ quy tắc đặt path cho từng loại document

Nếu không fix: AI search trả kết quả không chính xác → agent đọc tài liệu cũ/sai → lặp lại lỗi.

ĐIỂM GÃY 7: TẦNG 4 HOÀN TOÀN TRỐNG — KHÔNG CÓ SKELETON

Vấn đề: 5-layers.md viết Tầng 4 = "đích đến cuối cùng" nhưng chỉ liệt kê ví dụ (đại lý, tuyển dụng, khách hàng) mà KHÔNG CÓ:

Schema skeleton cho quy trình nghiệp vụ (khác gì workflow_steps hiện tại?)
Multi-actor model (khách hàng, đại lý, nhân viên — ai làm gì?)
Temporal model (quy trình kéo dài nhiều tháng — theo dõi thế nào?)
Branching model (phân nhánh theo tình huống — cấu trúc data?)

Workflow Module (M-002) đang thiết kế cho quy trình nội bộ (duyệt task, viết mã). Quy trình nghiệp vụ Tầng 4 phức tạp hơn nhiều lần.

Giải pháp (KHÔNG cần xây ngay — nhưng cần skeleton design):

Viết 1 file knowledge/dev/architecture/layer4-skeleton.md mô tả: data model khác biệt gì? Workflow Module cần mở rộng gì? Actor model cần gì?
Đảm bảo Tầng 2-3 KHÔNG thiết kế gì chặn Tầng 4 trong tương lai (ví dụ: workflow_steps chỉ hỗ trợ linear → phải hỗ trợ branching từ bây giờ)

Nếu không fix: Xây xong Tầng 2-3 rồi mới phát hiện không đủ cho Tầng 4 → phải refactor lại từ đầu. Cần ít nhất biết Tầng 4 CẦN GÌ để Tầng 2-3 không chặn.

ĐIỂM GÃY 8: THIẾU AGENT PROFILE — AGENT KHÔNG BIẾT MÌNH LÀ AI (GPT vòng 2)

Vấn đề: Điều 10 (Inject) giải quyết "agent phải đọc rules". Nhưng chưa giải quyết: "agent biết MÌNH là ai, ĐƯỢC LÀM GÌ, KHÔNG ĐƯỢC LÀM GÌ?"

Hiện tại Operating Rules §I có bảng phân quyền (Claude Desktop điều hành, Claude Code code...) nhưng đó là text dành cho người đọc. Agent không tự biết profile của mình.

Ví dụ: Codex khởi động → đọc CLAUDE.md → biết rules chung → nhưng KHÔNG BIẾT: "tôi là Codex, tôi chỉ được dùng OPS Proxy, không dùng STDIO MCP, tôi phải báo cáo vào Agent Data".

Giải pháp:

Tạo agents registry trong Directus (hoặc Agent Data) — mỗi agent = 1 record
Mỗi agent record chứa: capabilities (tools được dùng), restrictions (không được làm gì), transport (MCP config), reporting (báo cáo đi đâu)
Khi agent khởi động → inject agent profile vào context cùng với Hiến pháp rút gọn
Không cần collection riêng ngay — giai đoạn đầu embed vào CLAUDE.md / AGENTS.md per-agent section

Nếu không fix: Agent mới (hoặc agent quen nhưng chạy context mới) không biết giới hạn → vi phạm transport rules, permission rules.

ĐIỂM GÃY 9: THIẾU ORCHESTRATION ENGINE — AI KHÔNG CÓ "BỘ NÃO ĐIỀU PHỐI" (GPT vòng 2)

Vấn đề: Automation hiện tại = DOT scripts + Directus Flows. Nhưng khi workflow phức tạp:

Step A → Step B → Step C
Step B fail → retry 3 lần? rollback A? timeout?
Step A và Step B chạy song song? Hay tuần tự?
Ai theo dõi toàn bộ pipeline? Ai biết pipeline đang ở bước nào?

Directus Flows: không có retry, không có parallel, không có timeout, không CRUD cùng collection. DOT scripts: chạy rồi xong, không có state management.

Tại sao quan trọng cho automation 100%: Tầng 4 (quy trình nghiệp vụ) = pipeline nhiều bước, nhiều tháng, nhiều agent. Không có orchestrator = không thể tự động hoá Tầng 4.

Giải pháp:

Prefect (đã planned trong Tầng 1) = orchestration engine. Task retry, dependency graph, parallel execution, state tracking, timeout.
Nhưng Prefect cần THIẾT KẾ VÀI TRÒ RÕ RÀNG — không chỉ "planned":
- Prefect chạy ở đâu? (VPS container riêng)
- Prefect gọi ai? (DOT scripts, API calls, AI agents qua ai_tasks)
- Prefect state lưu ở đâu? (Prefect DB + sync vào Directus tasks)
- Prefect UI? (Prefect Server UI hoặc tích hợp vào Nuxt)
Giai đoạn trước Prefect: Dùng ai_tasks collection + Orchestrator script (đã có PR #389) làm orchestrator tạm. Không hoàn hảo nhưng đủ cho Phase 1-3.

Nếu không fix: Automation dừng ở mức "chạy 1 script rồi xong". Không pipeline, không retry, không parallel. Tầng 4 không thể tự động.

ĐIỂM GÃY 10: THIẾU SELF-HEALING PIPELINE — CHỈ PHÁT HIỆN, KHÔNG TỰ SỬA (GPT vòng 2)

Vấn đề: Tầng 5 (Sync Monitor) thiết kế: phát hiện bất đồng bộ → CẢNH BÁO → tạo task. Nhưng dừng ở đó.

Pipeline tự động hoá đầy đủ phải là:

DETECT → CLASSIFY → PROPOSE → REVIEW → APPLY → VERIFY

Hiện chỉ có: DETECT → ALERT (tạo task). Thiếu 4 bước sau.

Ví dụ cụ thể:

Phát hiện: field mới tạo, note trống
Classify: severity = low (metadata thiếu, không phải lỗi chức năng)
Propose: AI sinh mô tả dựa trên schema + context → đề xuất note
Review: Auto-approve nếu severity=low. Human review nếu severity=high.
Apply: Cập nhật field note qua DOT script
Verify: Query lại field → confirm note đã điền

Giải pháp: Bổ sung vào sync-governance.md: mỗi loại bất đồng bộ phải có full pipeline 6 bước, không chỉ detect+alert.

Loại bất đồng bộ	Severity	Auto-fix?	Human review?
Metadata trống	low	✅ AI auto-fill + auto-approve	Batch review hàng tuần
Registry thiếu record	medium	✅ Auto-propose	Human approve
Schema drift	high	❌ Không auto-fix	Human review bắt buộc
Dependency broken	critical	❌ Block deploy	Human fix immediately

Nếu không fix: Sync Monitor phát hiện 500 vấn đề → tạo 500 tasks → không ai làm → alert fatigue → bỏ qua tất cả → hệ thống vẫn rối.

ĐIỂM GÃY 11: DOT TOOLS "HƯ CẤU" — ✅ ĐÃ GIẢI QUYẾT PHẦN LỚN (S106-S107)

Trạng thái cập nhật S107: Phần lớn DOT tools cốt lõi ĐÃ TẠO:

✅ dot-schema-snapshot (PR #449)
✅ dot-schema-diff (PR #449)
✅ dot-metadata-audit (PR #449)
✅ dot-metadata-fill (PR #450)
✅ dot-catalog-sync (PR #446)
✅ dot-registry-diff (PR #451)
✅ dot-orphan-scan (PR #455)
✅ dot-dependency-scan (PR #456)
✅ dot-registries-verify v2 (PR #457)
✅ dot-selftest-registries (PR #457)
✅ dot-cross-ref-populate (S107-LAYER3 đang triển khai)

Vẫn thiếu:

❌ dot-entity-create — script chuẩn tạo entity mới (generic)
❌ dot-duplicate-engine — chống double tổng quát (TD-083)
❌ dot-entity-deprecate / dot-entity-retire — vòng đời sửa/xoá (Điểm gãy 3)

Vấn đề CỰC KỲ NGHIÊM TRỌNG: Gemini vòng 2 ĐỌC TRỰC TIẾP thư mục dot/bin/ trên repo agent-data-test và phát hiện: các DOT tools mà Hiến pháp yêu cầu (dot-entity-create, dot-field-create, dot-schema-snapshot, dot-metadata-audit...) CHƯA TỒN TẠI. Hiến pháp ghi "mọi thao tác qua DOT script" nhưng script chưa viết.

Hệ thống đang ở trạng thái: CÓ LUẬT NHƯNG KHÔNG CÓ HÀNH PHÁP.

Chi tiết:

dot/bin/ trên repo agent-data-test chỉ có 4 files (Gemini đếm)
82 DOT tools đã audit nằm trên repo codex-web (dot/bin/) và VPS — KHÔNG nằm ở nơi Gemini kiểm tra
Tuy nhiên, các tools MỚI trong Hiến pháp (dot-entity-create, dot-schema-snapshot, dot-metadata-audit, dot-registry-scan...) thực sự CHƯA TỒN TẠI ở BẤT KỲ ĐÂU

Hệ quả: Khi agent đọc Hiến pháp và cố gọi dot-entity-create → command not found → agent tự viết script tạm → vi phạm Luật 3 (DOT 100%). Vòng lặp vi phạm không thể thoát.

Giải pháp:

Phase 1 PHẢI TẠO các DOT scripts cốt lõi TRƯỚC khi yêu cầu agent tuân thủ
Hiến pháp cần ghi rõ: tools nào ĐÃ CÓ vs tools nào CẦN TẠO
Trong giai đoạn chưa có tool → cho phép agent thao tác thủ công NHƯ PHẢI ghi nhận vào TD

ĐIỂM GÃY 12: GOVERNANCE CODE "NGỦ ĐÔNG" — CÓ NHƯNG KHÔNG TÍCH HỢP (Gemini vòng 2)

Vấn đề: security_governance.py trong repo agent-data-test chứa validators (JWS/JWT check, rate limit...) rất tốt, nhưng main.py HOÀN TOÀN KHÔNG GỌI các hàm này. Code enforcement tồn tại nhưng không chạy.

Hệ quả: Hệ thống không có "hàng rào" tự động. Agent lỗi có thể phá dữ liệu mà không bị chặn.

Giải pháp: Tích hợp governance vào API middleware — nhưng đây là việc của Phase 2-3, KHÔNG chặn Phase 1.

ĐIỂM GÃY 13: ARCH-CHECK HỜI HỢT (Gemini vòng 2)

Vấn đề: dot-arch-check (trên agent-data-test) chỉ check secret/SA, KHÔNG check tuân thủ Hiến pháp (PREFIX-NNN, Registry tồn tại, metadata đủ).

Giải pháp: Nâng cấp dot-arch-check (hoặc tạo dot-constitution-check mới) — check:

Mọi collection có record trong collection_registry?
Mọi field quan trọng có note?
Mọi DOT tool có record trong dot_tools registry?
Prefix format đúng?

ĐIỂM GÃY 14: ĐỒNG BỘ DIRECTUS → AGENT DATA GÃY NGHIÊM TRỌNG (Claude Code + Huyen phát hiện)

Vấn đề CỰC KỲ NGHIÊM TRỌNG — xác nhận bằng query thực tế:

Kiểm tra 26 Directus Flows trên production:

[DOT] Knowledge Sync to Agent Data = INACTIVE ❌
[DOT] Knowledge Delete from Agent Data = INACTIVE ❌
Workflows, table_registry, workflow_steps, modules, workflow_change_requests = KHÔNG CÓ FLOW NÀO ❌

Hệ quả:

Hướng Agent Data → Directus: ✅ hoạt động (event_system.py webhook)
Hướng Directus → Agent Data: ❌ GÃY cho knowledge_documents + KHÔNG TỒN TẠI cho tất cả collections mới

Nghĩa là: nếu ai đó sửa dữ liệu trực tiếp trong Directus (ví dụ: sửa workflow, thêm module, thay đổi table_registry) → Agent Data KHÔNG BIẾT → AI agents đọc Agent Data sẽ thấy data CŨ → quyết định SAI.

Đặc biệt nguy hiểm khi: registry data (table_registry, modules, collection_registry tương lai) nằm trong Directus nhưng AI agents chủ yếu đọc qua Agent Data. Nếu 2 nguồn lệch nhau → mọi automation đều sai.

Giải pháp:

NGAY: Kiểm tra tại sao Knowledge Sync + Delete bị INACTIVE → activate lại
Phase 1: Tạo sync flows cho TẤT CẢ registry collections mới (table_registry, modules, workflows...)
Kiến trúc: Quyết định rõ: Directus hay Agent Data là SSOT cho từng loại data? (Xem Điểm gãy 4 — SSOT direction)

Nếu không fix: Mọi registry tạo ra đều VÔ NGHĨA vì AI agents không thấy data mới nhất.

ĐIỂM GÃY 15: 5 VẤN ĐỀ THỰC TẾ TỪ CODE REVIEW (Claude Code S105)

15A. CI Workflows trùng lặp

ops-smoke.yml và sync-check.yml cùng chạy 6h, cùng 8 health checks gần giống. Lãng phí CI minutes.
guard_critical_files.yml và required-docs-guard.yml overlap.
Fix: Gộp, dọn dẹp. Effort: 🟢 Low.

15B. DOT Tools Registry lệch

Registry markdown ghi 71 tools, dot/bin/ thực tế có 83 files. 12 tools mới chưa cập nhật.
Vi phạm Điều 2 Hiến pháp (mọi thứ phải trong registry).
Fix: Sync registry. Effort: 🟢 Low.

15C. Skills file thiếu

.claude/skills/incomex-rules.md được CLAUDE.md tham chiếu nhưng chưa cập nhật Hiến pháp mới.
Đây chính là Điểm gãy #1 (Inject) trong thực tế.
Fix: Cập nhật file. Effort: 🟢 Low.

15D. Playwright có infra nhưng không có tests

package.json có test:e2e script. Không có test files. E2E = sẵn sàng dùng, chỉ thiếu test cases.
Fix: Viết tests. Effort: 🟡 Medium.

15E. Agency OS collections cần audit

20+ collections từ template (os_deals, os_invoices, os_proposals...) + Portal routes tồn tại nhưng không rõ có dùng không.
Nếu không dùng → noise trong 130+ collections, AI agents scan schema bị nhầm.
Fix: Audit + deprecate hoặc retire những collection không dùng. Effort: 🟡 Medium. (5 vòng review: Claude + GPT v1 + Gemini v1 + Claude self + GPT v2 + Gemini v2)

#	Điểm gãy	Nguồn	Mức
1	Agent không đọc Hiến pháp — ⚠️ inject done	Self-review + S106	🟡
2	DOT script không idempotent	Self-review	🔴
3	Thiếu sửa/xoá lifecycle	Self-review	🔴
4	Sync thiếu SSOT direction	Self-review	🟡
5	Permission matrix registry	Self-review	🟡
6	Agent Data docs thiếu metadata	Self-review	🟡
7	Tầng 4 trống skeleton	Self-review	🟡
8	Agent thiếu profile	GPT v2	🟡
9	Thiếu orchestration engine	GPT v2	🔴
10	Self-healing chỉ detect	GPT v2	🔴
11	DOT tools "hư cấu" — ✅ phần lớn done	Gemini v2 + S106-S107	🟢 (10+ tools done)
12	Governance code ngủ đông	Gemini v2	🟡
13	Arch-check hời hợt	Gemini v2	🟡
14	Directus → Agent Data sync GÃY	Claude Code + Huyen	🔴🔴
15	5 vấn đề code thực tế	Claude Code	🟡
16	Danh mục không tự động	Huyen	🔴🔴
17	ORPHAN SCANNER (Side B) — ✅ DONE	Huyen S106 + PR #455	🟢

TOP 3 NGHIÊM TRỌNG NHẤT (cập nhật S107 — sau Điều 0):

★ GỐC RỄ — Registry auto-refresh (TD-107): meta_catalog.record_count KHÔNG tự cập nhật. dot-orphan-scan KHÔNG scheduled. Thêm entity mới → Bảng tuần hoàn KHÔNG biết. Kết quả: "Đúng đủ sạch sống" chỉ là khẩu hiệu — thực tế data stale. Định danh không tự động + không chính xác = TẤT CẢ việc khác VÔ NGHĨA.
#14 — Sync Directus → Agent Data: Knowledge sync INACTIVE (đúng thiết kế), nhưng registry collections cần verify
#3 — Thiếu sửa/xoá lifecycle: entity_dependencies CÓ nhưng chưa có workflow deprecate/retire

Automation Maturity (cập nhật S107 — sau S107-DISCOVERY)

Layer	Maturity	Bottleneck
Infrastructure (Tầng 1)	85%	Prefect chưa deploy
Sync pipeline	65%	Knowledge INACTIVE (đúng thiết kế), registry sync 21 flows OK
Registry (Tầng 2)	90%	14/14 registries, 500+ entities, 173 dependencies, selftest 37 PASS
Metadata (Tầng 2)	95%	100% field/collection notes. DOT tools description 0% (TD-095)
DOT Tools (Tầng 2)	85%	12+ cốt lõi tools. Thiếu: dot-duplicate-engine, lifecycle scripts
Governance (Tầng 2)	25%	Code có nhưng chưa tích hợp
Lớp 3 (Hạ tầng TT)	60%	4/8 quy tắc DONE. Thiếu: DEPENDS_ON, TRANSITIVE, PEERS
Module system (Tầng 3)	75%	Registries 3-layer + Discovery mode. Cần Lớp 3 hoàn thiện
Automation pipeline	45%	Thiếu orchestrator + self-healing
Auto-catalog	80%	13 auto-ID flows, 14 meta_catalog records, selftest OK
Orphan detection	95%	dot-orphan-scan 100% coverage. Thiếu: cron auto
Self governance (Tầng 5)	25%	dot-selftest + dot-layer3-audit. Cần mở rộng