COUNCIL REVIEW — GPT

Thời điểm: 2026-03-31
Căn cứ đọc: Hiến pháp v4.0.2, Điều 1, 2, 3, 0-B, 0-G, 0-H, 8, 10-13, 24, 26, 29, 31, 32, 33, và 2 dự thảo Điều 35-36.
Nguyên tắc chấm: 3 Tuyên ngôn + 9 Nguyên tắc Nền tảng + Luật Bảo toàn.
Lưu ý phương pháp: Tôi chỉ đánh giá trên nội dung luật đã đọc. Chỗ nào dự thảo nói “giữ nguyên v3.0” nhưng không restate đầy đủ trong bản v3.5/v2.0 thì tôi xem đó là rủi ro pháp lý/tài liệu vì người triển khai có thể viện dẫn thiếu.

ĐIỀU 35: LUẬT QUẢN TRỊ DOT v3.5

Câu 1: MỤC TIÊU

Tóm tắt 3 mục tiêu:

Nhìn toàn cảnh DOT: biết DOT nào đang làm gì, thiếu/thừa/hỏng ở đâu.
Đo được DOT bằng số: coverage, pairing, automation.
Tự vận hành khép kín: phát hiện → sửa → verify.

Đánh giá:

ĐÁNG LÀM: Có. Với ~154 DOT hiện tại và mục tiêu scale lên hàng nghìn, không có luật quản trị DOT thì Điều 13 (Danh mục sống), Điều 0-H (DOT là cổng duy nhất) và Điều 31 (giám sát 2 động cơ) sẽ không đứng vững. Đây là luật hạ tầng bắt buộc, không phải tiện ích. 🟢
Thiếu mục tiêu: Thiếu một mục tiêu nói thẳng về tính thực thi 5 tầng của DOT Cấp B. Điều 35 hiện nhấn mạnh coverage/pairing/target, nhưng chưa nêu thành mục tiêu độc lập việc bảo đảm DOT B luôn đi đúng luồng Directus/API/Agent Data theo Điều 0-H. 🟡
Không thấy mâu thuẫn nội tại giữa 3 mục tiêu. Thứ tự ưu tiên hiện tại hợp lý: nhìn thấy → đo được → tự vận hành.
Điểm cần bổ sung: “coverage” hiện thiên về đếm số DOT theo domain/operation hơn là đo chất lượng “đủ để hệ thống an toàn chưa”. Nếu chỉ phủ số lượng mà không phủ nghĩa vụ kiểm soát 2 động cơ thì mục tiêu 2 có thể đạt giả.

Kết luận: Mục tiêu hợp lý, nhưng nên thêm 1 mục tiêu rõ ràng về kiểm soát thực thi DOT B trên 5 tầng. 🟡

Câu 2: LÀM THẾ NÀO

Schema / tables / FK:

dot_tools bổ sung 10 fields là đủ tốt cho phase 1: tier, paired_dot, domain, operation, trigger_type, cron_schedule, file_path, last_executed, coverage_status, extra_metadata. Nó bám đúng Điều 2 (registry), Điều 3 (metadata), Điều 0-H (tier A/B), Điều 8 (dependencies). 🟢
dot_domains là bổ sung đúng và rất mạnh: biến domain từ text tự do thành SSOT + FK enforce. Điều này phù hợp Tuyên ngôn ② “muốn nhầm cũng không thể”. 🟢
dot_coverage_required là đúng hướng nhưng draft v3.5 chỉ nói “giữ nguyên v3.0 §2.3” mà không restate cấu trúc. Với một luật draft đang chờ ban hành, đây là lỗ hổng tài liệu: người triển khai không có schema hiện diện đầy đủ trong bản hiện hành. 🟡
Khai báo target qua entity_dependencies là đúng theo Điều 8, nhưng hiện vẫn còn mơ hồ mức bắt buộc: target ở mức collection hay entity type hay cả action scope? Ví dụ một DOT quét approval_requests và meta_catalog nhưng cũng ghi system_issues; draft chưa nói rõ phải khai báo cả collection đọc và collection ghi hay chỉ “target chính”. 🟡

Quy trình / steps / triggers / cron:

Quy trình 8 bước tạo DOT mới là hợp logic: APR → auto-approve → tạo file → register → dependencies → birth → health → issue. Chuỗi này bám Điều 32, Điều 13, Điều 0-G, Điều 31. 🟢
Điểm hở 1: Bước 3 “tạo file .ts tại bin/dot/” là bước vật lý nhưng draft không nói ai thực hiện và bằng cơ chế gì. Nếu vẫn cần con người/code agent tạo file thủ công ngoài DOT thì mục tiêu “DOT 100%” chưa khép kín. Đây là lỗ hổng giữa pháp lý và thực thi. 🔴
Điểm hở 2: dot-dot-register “auto INSERT entity_dependencies từ naming convention” là rủi ro với NT-9 “Không chắc = Sai”. Naming convention chỉ nên là gợi ý khởi tạo, không nên là nguồn chân lý cuối cùng cho dependencies thực. Nếu register tự suy đoán target sai, hệ thống sẽ có dependency graph giả nhưng trông có vẻ hợp lệ. 🔴
Điểm hở 3: last_executed được lưu nhưng draft không nói rõ nguồn cập nhật là runtime hook nào, có bắt buộc mọi DOT pass/fail đều ghi không. Nếu không bắt buộc chuẩn hóa, field này nhanh chóng thành metadata chết. 🟡

DOT tools có đủ không?

3 DOT tự quản trị (dot-dot-health, dot-dot-coverage, dot-dot-register) là đủ tối thiểu cho phase 1. Không thừa. 🟢
Nhưng thiếu một DOT chuyên trách verify file_path ↔ registry ↔ executable parity. dot-dot-health có thể đang cover trong “7 checks cũ”, nhưng v3.5 không restate. Khi luật ban hành, phần này cần hiện rõ. 🟡
Thiếu cơ chế rõ ràng cho deprecate/retire file thật: luật nói rename cấm, retire = update không xoá, mọi thay đổi qua APR. Nhưng không nói DOT retired thì file ở bin/dot/ xử lý thế nào để không bị register lại hoặc bị gọi nhầm. 🔴

Đo lường / metrics / pivot / report:

Đo coverage qua dot_coverage_required + pivot là đúng tinh thần Điều 26. 🟢
Nhưng metric % coverage chỉ đúng nếu “mẫu số” là chuẩn và cập nhật. Nếu dot_coverage_required do con người duy trì thủ công và không có scanner phát hiện Domain×Operation mới cần bổ sung, tỷ lệ coverage sẽ đẹp giả. 🟡
Báo cáo JSON chuẩn + trend là hợp lý; chưa thấy sai.

Assembly First / đơn giản hơn không?

Tôi không thấy có giải pháp đơn giản hơn mà vẫn đạt mục tiêu. Dùng dot_domains + entity_dependencies + pivot là đúng Assembly First, không đẻ thêm hệ mới. 🟢

Scale 1000+ DOT:

Mô hình nhìn chung không vỡ ở mức data model.
Rủi ro nằm ở chất lượng auto-classify và auto-dependency. Khi lên 1000+ DOT, suy luận từ naming convention sẽ tạo sai hàng loạt nếu không có bước verify chặt. 🔴

Kết luận: Phương án khá tốt nhưng chưa khép kín hoàn toàn. 3 điểm phải sửa trước: (1) làm rõ ai/cách nào tạo file DOT; (2) hạ vai trò naming convention từ “chân lý” xuống “gợi ý”; (3) quy định xử lý file vật lý khi DOT retired. Xếp hạng: 🔴 3, 🟡 4, 🟢 5.

Câu 3: TUÂN THỦ

A. 3 Tuyên ngôn

① “Nếu ngày mai thay đổi, vấn đề quay lại không?”

dot_domains và evolving fields là lời giải khá vĩnh viễn cho text tự do và metadata thiếu. 🟢
Nhưng auto-classify từ naming convention và auto-insert dependencies từ tên file chưa vĩnh viễn. Khi naming đổi hoặc tool phức tạp hơn, lỗi sẽ quay lại. 🔴

② “Muốn nhầm cũng không thể?”

FK dot_tools.domain → dot_domains.code là rất tốt.
paired_dot FK cũng chặn được cặp giả ở mức tồn tại.
Nhưng operation, file_path, cron_schedule, và dependency suy ra từ naming chưa có ràng buộc chặt tương đương. Agent vẫn có thể khai operation bừa hoặc file_path trỏ sai mà không bị schema chặn. 🟡

③ “Fix gốc, không fix vụ việc?”

Luật đúng tinh thần khi quản trị DOT từ schema/registry/coverage. 🟢
Nhưng nếu dot-dot-health chỉ tạo APR nhắc “khai báo target” sau khi phát hiện DOT lẻ, mà quy trình sinh DOT mới vẫn cho phép tạo file trước rồi đăng ký sau, thì đây vẫn là fix hậu quả chứ chưa khóa gốc ngay từ cổng vào. 🔴

B. 9 Nguyên tắc

SSOT: dot_domains là SSOT tốt. Nhưng domain tồn tại ở dot_domains, còn layer/operation/tier có vẻ chỉ nằm ở dot_tools; nếu coverage rules lại định nghĩa riêng logic ở dot_coverage_required, có nguy cơ trùng tri thức. 🟡
Tự động 100%: chưa đạt tuyệt đối vì bước tạo file thật chưa được DOT hoá rõ ràng. 🔴
DOT 100%: về pháp lý là đúng; về thực thi draft vẫn để hở chỗ file-system step. 🔴
Sẵn sàng thay đổi: đạt tốt nhờ dot_domains, evolving fields, extra_metadata. 🟢
Tự phát hiện: có dot-dot-health và dot-dot-coverage, nhưng chưa thấy scanner bắt trường hợp DOT retired mà file còn executable hoặc cron còn chạy. 🟡
5 tầng đồng bộ: Điều 35 bám Điều 0-H ở mức tier A/B, nhưng chưa mô tả rõ DOT B nào bắt buộc đi qua Directus/API và DOT nào chỉ là file local. 🟡
Dual-trigger: draft nói tier A/B, paired_dot cho B, nhưng chưa nói rõ mọi DOT B đều phải có A cùng scope, hay chỉ “có paired_dot là xong”. Scope mismatch vẫn có thể xảy ra. 🟡
Assembly First: đạt tốt. Dùng lại entity_dependencies, approval_requests, pivot. 🟢
Không chắc = Sai: vi phạm tiềm tàng ở auto-classify bằng naming convention. 🔴

C. Luật Bảo toàn

ID không tái sử dụng: rename cấm, retire không xoá → đúng. 🟢
Quan hệ không tự mất: khai target trong entity_dependencies là đúng, nhưng quy trình retire file DOT chưa rõ; nếu retire mà dependency bị xoá mềm hay file biến mất không kiểm soát thì bảo toàn quan hệ chưa chắc giữ. 🟡
Metadata không giảm: evolving fields là đúng. 🟢

D. Luật cụ thể

Điều 2 (Registry): tuân thủ tốt, vì DOT có ID, registry, fields. 🟢
Điều 3 (Metadata): tiến bộ rõ, nhưng draft chưa map đủ 13 fields của Điều 3 cho dot_tools. Ví dụ name_en, owner, layer, classification không được nhắc lại trong v3.5. Có thể fields cũ đã có, nhưng dự thảo không chứng minh. 🟡
Điều 0-H: tier A/B rất khớp. Tuy vậy, secret cho B chỉ được viện dẫn gián tiếp, không restate cơ chế secret retrieval/verify. 🟡
Điều 8: tuân thủ tốt nhờ target collection bắt buộc. 🟢
Điều 24: dự thảo nhắc 6 chiều phân loại, nhưng không chỉ rõ nhãn facet nào map cho DOT domains/operations/tier. Chưa sai, nhưng mờ. 🟡
Điều 26: có dùng pivot để đếm, đúng hướng. 🟢
Điều 29: draft không nói rõ species và governance_role của DOT thực thể trong collection_registry/entity_species; chỉ viện dẫn. Cần nêu rõ DOT = species nào, governed/observed ra sao. 🟡
Điều 31: có health/coverage; khá khớp. 🟢
Điều 32: mọi thay đổi qua APR là đúng, nhưng câu “THÊM → auto-approve” cần cẩn trọng với DOT B có secret và có quyền ghi nhiều collection. Tôi xem đây là rủi ro cần siết. 🔴

Kết luận tuân thủ Điều 35: Tuân thủ đa số đúng hướng, nhưng còn 4 vi phạm/rủi ro nghiêm trọng: auto-classify quá tin naming, bước tạo file chưa DOT-hoá rõ, retire file chưa khép kín, và auto-approve cho new_dot quá rộng. Xếp hạng: 🔴 4, 🟡 8, 🟢 9.

Câu 4: KHẢ THI

Với hạ tầng hiện tại (PG16, Directus, 1 VPS $8, ~154 DOT): Phase 1 khả thi nếu giới hạn vào data model + scanners + backfill registry, chưa làm “full auto create file”. 🟢
Dependency chưa tồn tại / đang giả định:
1. dot_domains chưa có.
2. dot_coverage_required chưa được restate schema trong v3.5.
3. Chưa thấy DOT thực sự tạo file DOT mới một cách chuẩn hóa.
4. Chưa thấy chuẩn enum/allowlist cho operation.
5. Chưa thấy policy runtime ghi last_executed.
  → Đây là dependencies còn thiếu, nhưng đa số tạo được. 🟡
Xung đột với luật hiện hành:
- Với Điều 32: new_dot auto-approve có thể mâu thuẫn tinh thần “thay đổi nguy hiểm phải duyệt”, vì DOT B có thể là tác nhân rất mạnh. 🔴
- Với Điều 0-H: nếu thực thi step 3 bằng agent tạo file trực tiếp trên VPS mà không qua cổng chuẩn, sẽ lệch tinh thần “DOT là cổng duy nhất”. 🔴
Backfill 154 DOT: thực tế cho 1 mission kỹ thuật nếu chỉ làm metadata/domain/dependencies cơ bản. Nhưng nếu kèm paired audit, target audit, coverage matrix, dependency graph đúng hết một lượt thì khối lượng lớn; nên tách ít nhất 2 pha. 🟡
Rủi ro chưa tính:
1. dot-dot-register có thể đăng ký lại file retired nếu chỉ nhìn bin/dot/. 🔴
2. Một DOT có nhiều target read/write; hiện model entity_dependencies cần quy ước loại quan hệ rõ hơn (reads, writes, verifies, fixes) chứ không chỉ “depends_on”. 🟡
3. cron_schedule text không đủ để biết cron thực tế đã được cài trên VPS hay chỉ mới khai báo metadata. Cần đối soát runtime. 🟡

Kết luận khả thi Điều 35: Khả thi cho Phase 1, nhưng không nên ban hành nguyên xi khi chưa khóa 4 điểm: auto-approve new_dot, quy trình tạo file, tái-đăng-ký file retired, và semantics dependency cho DOT. Xếp hạng: 🔴 4, 🟡 5, 🟢 2.

Câu 5: Ý KIẾN KHÁC

Điều 35 cần cập nhật Điều 8 hoặc ít nhất mở rộng relation types cho DOT dependencies: reads, writes, verifies, applies, triggers thay vì gom tất cả vào depends_on. 🟡
Anti-pattern nên thêm: “AP-XX: Auto-classify DOT bằng tên file rồi coi là chân lý.” Naming chỉ được phép là gợi ý, không phải nguồn phân loại cuối. 🔴
Cần cập nhật Điều 32: request_type='new_dot' nên tách:
- DOT A read-only có thể auto-approve nếu scope hẹp
- DOT B có secret / ghi schema-data thì không auto-approve toàn phần. 🔴
Ưu tiên triển khai: Không nên triển khai Điều 35 đơn lẻ trước Điều 36 quá xa, vì DOT quản trị collection và collection lại là target chính của DOT. Nhưng nếu bắt buộc chọn trước/sau: triển khai khung Điều 36 trước một nhịp nhỏ (SSOT groups/field standards), rồi mới khóa Điều 35 để DOT có đối tượng chuẩn mà quản trị. 🟡

ĐIỀU 36: LUẬT COLLECTION PROTOCOL v2.0

Câu 1: MỤC TIÊU

Tóm tắt 3 mục tiêu:

Mọi collection sinh ra đều chuẩn hóa: đủ fields, đủ khai sinh, đủ quan hệ.
Cross-collection truy xuất được chính xác nhờ FK + group.
Scale lên hàng nghìn collection vẫn nhất quán nhờ DOT tạo/kiểm tra/đồng bộ.

Đánh giá:

ĐÁNG LÀM: Rất đáng. Đây là luật “cổng vào” cho toàn bộ tầng collection. Nếu không có protocol, Điều 2, 3, 0-G, 29, 33 sẽ mãi bị enforce thủ công theo từng case. 🟢
Mục tiêu thiếu: Thiếu một mục tiêu nói rõ tính tương thích hồi quy với 138 collections hiện hữu. Draft có nhắc “health chạy → phát hiện → APR → sửa dần”, nhưng chưa nâng nó thành mục tiêu chính thức. Với tình trạng legacy lớn, đây là mục tiêu bắt buộc. 🟡
Không thấy mâu thuẫn nội tại. Thứ tự mục tiêu đúng.

Kết luận: Mục tiêu hợp lý và mạnh hơn Điều 35. Chỉ nên thêm mục tiêu thứ 4: “chuẩn hóa dần legacy mà không phá vận hành hiện tại.” 🟡

Câu 2: LÀM THẾ NÀO

Schema / tables / FK:

collection_groups là thiết kế đúng: biến group thành SSOT + FK, rất hợp Điều 29 và Tuyên ngôn ②. 🟢
collection_field_standards là điểm mạnh nhất của dự thảo: giải quyết trực diện yêu cầu “từ 10 → 11 fields chuẩn, 138 collections tự cập nhật”. Nó bám Điều 3, 33, 0-H, 10-13. 🟢
Điểm thiếu 1: collection_field_standards chưa có cột nào chỉ rõ scope áp dụng. Hiện mọi field Tier 2 có vẻ áp cho “tất cả collections”. Điều này sẽ đụng nhóm directus_*, logs, junction, excluded, hoặc system tables không nên mang cùng một bộ field. Cần scope như applies_to_group, applies_to_governance_role, hoặc exclude_patterns. 🔴
Điểm thiếu 2: Bảng nhóm ban đầu ghi GRP-CMS ví dụ directus_*. Nhưng Directus system collections thường không nên bị DOT tùy tiện thêm field chuẩn. Nếu luật không chặn rõ, dot-collection-field-sync có thể cố đẩy Tier 2 vào collection không kiểm soát được. 🔴
Điểm thiếu 3: Protocol nói Bước 7 tạo FK + Directus relation + universal_edges, nhưng chưa nói entity_dependencies có được ghi cho collection-level relation hay không. Điều 8 yêu cầu dependency graph; nếu chỉ có FK/universal_edges mà thiếu dependencies thì retire/change analysis vẫn hở. 🟡

Quy trình 12 bước:

Cấu trúc 4 nhóm A/B/C/D rất sạch và gần khép kín. 🟢
Điểm hở 1: Bước 6 “prefix mới → APR type='new_prefix'” đúng, nhưng input của dot-collection-create đã nhận prefix. Draft không nói prefix cũ hợp lệ thì tool tự verify bằng registry nào và block ở đâu. 🟡
Điểm hở 2: Bước 11 gộp quá nhiều thứ: entity_species + birth_registry trigger + auto-code trigger + permissions + pivot_definitions. Đây là 5 nhóm nghĩa vụ khác nhau nhưng bị nén vào 1 bước. Về pháp lý, bước này chưa đủ minh bạch để audit/fail-fast. 🟡
Điểm hở 3: Bước 12 Verify 5 tầng ghi “KB ✓” nhưng không nói rõ Agent Data sync bằng trigger nào, thời gian chờ bao lâu, tiêu chí PASS là gì. Với Agent Data đang có lúc degraded, bước verify cần định nghĩa được. 🟡

DOT tools có đủ không?

dot-collection-create, dot-collection-health, dot-collection-field-sync là bộ tối thiểu hợp lý. Không thừa. 🟢
Nhưng còn thiếu một DOT hoặc sub-flow chuyên backfill legacy collections theo batch có rollback/approval granularity. Dùng riêng health → APR → sync cho 138 collection hiện hữu có thể quá thô. 🟡

Đo lường / metrics / report:

dot-collection-health có 11 checks là tốt.
Nhưng chưa có thước đo rõ cho “protocol compliance %” theo 12 bước. Nếu chỉ log issue type rời rạc, khó biết collection nào thiếu step 4, 7, 9, 11 cụ thể. 🟡
Điều 36 có nói đếm/pivot config ở meta_catalog, nhưng chưa nói rõ collection compliance sẽ đếm qua pivot_count() như thế nào. Không sai, nhưng nên nối lại với Điều 26 rõ hơn. 🟡

Assembly First / đơn giản hơn không?

Đây đã là giải pháp Assembly First tương đối tối ưu: Directus API, PG function auto-code, SSOT tables, health scanner. 🟢

Scale 1000+ collections:

Data model không vỡ nếu có scope field standards tốt.
Nếu không có scope, dot-collection-field-sync sẽ là quả bom logic khi số collection tăng: nhiều collection không nên nhận cùng field chuẩn. 🔴

Kết luận: Điều 36 có thiết kế mạnh và rõ hơn Điều 35, nhưng còn 2 thiếu sót nghiêm trọng: collection_field_standards chưa có scope áp dụng, và luật chưa chặn rõ việc sync vào Directus/internal/system collections. Xếp hạng: 🔴 2, 🟡 6, 🟢 7.

Câu 3: TUÂN THỦ

A. 3 Tuyên ngôn

① “Nếu ngày mai thay đổi, vấn đề quay lại không?”

collection_groups + collection_field_standards là đúng tinh thần vĩnh viễn: thay đổi nhóm/field chuẩn bằng metadata. 🟢
Nhưng vì Tier 2 chưa có scope, một thay đổi “mọi collection cần field X” có thể gây hiệu ứng phụ rồi bị rollback thủ công. Đây là dấu hiệu chưa vĩnh viễn đủ. 🔴

② “Muốn nhầm cũng không thể?”

FK group rất tốt.
Bắt buộc khai báo relationship ngay khi tạo collection là đúng.
Nhưng reference là soft FK, nếu dùng quá rộng mà không có scanner/approval rule đi kèm, agent vẫn có thể “khai quan hệ kiểu text” để lách FK thật. 🟡

③ “Fix gốc, không fix vụ việc?”

Điều 36 thiên về fix gốc rõ ràng: chuẩn hóa protocol tạo collection, chuẩn hóa field standards, health → APR → sync. 🟢
Tuy nhiên compliance legacy 138 collections nếu chỉ “sửa dần” mà không có chiến lược nhóm ưu tiên + scope field standards thì dễ trượt thành vá từng vụ việc. 🟡

B. 9 Nguyên tắc

SSOT: mạnh. collection_groups và collection_field_standards là 2 SSOT đúng. 🟢
Tự động 100%: đạt khá cao, nhưng backfill legacy hiện vẫn phụ thuộc APR + rollout; chưa thể gọi 100% tự động trọn vẹn. 🟡
DOT 100%: đúng trên giấy với dot-collection-create. 🟢
Sẵn sàng thay đổi: rất tốt nhờ Tier 2 evolving fields. 🟢
Tự phát hiện: có dot-collection-health, nhưng chưa thấy scanner riêng phát hiện “field standard áp nhầm scope”. Vì scope còn chưa có. 🔴
5 tầng đồng bộ: bám Điều 0-H khá tốt; bước 12 verify đủ 5 tầng là đúng. 🟢
Dual-trigger: có create (chính) + health (phụ) + field-sync (hybrid). Tôi chấm đạt tốt. 🟢
Assembly First: dùng Directus API, PG functions, registries có sẵn. Đúng. 🟢
Không chắc = Sai: phần reference soft FK và bước verify KB/Nuxt chưa định lượng rõ làm giảm độ chắc. 🟡

C. Luật Bảo toàn

ID không tái sử dụng: protocol bám prefix + auto-code, không thấy vi phạm. 🟢
Quan hệ không tự mất: Bước 7-8 ép khai báo quan hệ là đúng. Nhưng nếu many_to_many tạo junction table mà không ghi đầy đủ dependency/universal_edges/birth cho junction, quan hệ có thể “mất trên giấy” dù còn trong PG. Draft chưa nói rõ chỗ này. 🟡
Metadata không giảm: Tier 2 chỉ thêm là đúng. 🟢

D. Luật cụ thể

Điều 2 (Registry): tuân thủ tốt; có code/prefix/registry. 🟢
Điều 3 (Metadata): khá tốt nhưng Tier 1 chỉ có 6 fields (id, code, name, status, date_created, date_updated). Điều 3 yêu cầu metadata bắt buộc rộng hơn: name_en, description, classification, owner, layer nữa. Hiện draft đẩy name_en, description sang Tier 2, còn classification, owner, layer không thấy. Đây là thiếu tuân thủ đáng kể. 🔴
Điều 0-H: create và field-sync qua Directus API là đúng. 🟢
Điều 8: quan hệ bắt buộc là rất khớp, nhưng nên ghi thêm dependency graph. 🟡
Điều 24: chưa nêu rõ labels/facets nào phải gắn cho collection mới ngoài species/group; Điều 24 chưa được thể hiện rõ trong protocol. 🟡
Điều 26: có nói pivot_definitions ở bước 11, nhưng chưa mô tả “pivot-ready by default” cụ thể đến mức field/group nào phải có. 🟡
Điều 29: rất khớp nhờ species + governance_role + group + data_tier. 🟢
Điều 31: có health scanner; đúng. 🟢
Điều 32: APR dùng cho new_prefix, new_field_standard, legacy fixes; đúng. 🟢
Điều 33: tên snake_case, fields chuẩn, auto-code chuẩn; khớp tốt. 🟢

Kết luận tuân thủ Điều 36: Tuân thủ tổng thể tốt hơn Điều 35, nhưng có 2 điểm vi phạm/rủi ro pháp lý quan trọng: (1) Tier 1/Tier 2 hiện chưa đáp ứng đầy đủ Điều 3 metadata 13 fields; (2) scope áp dụng field standards chưa rõ, có thể đâm vào collections không phù hợp. Xếp hạng: 🔴 2, 🟡 7, 🟢 11.

Câu 4: KHẢ THI

Với hạ tầng hiện tại: Phase 1 khả thi nếu giới hạn vào:
1. tạo 2 SSOT tables,
2. tạo DOT create/health,
3. seed groups + seed field standards,
4. pilot trên một số governed collections trước. 🟢
Dependency chưa tồn tại / đang giả định:
1. collection_groups chưa có.
2. collection_field_standards chưa có.
3. dot-collection-field-sync chưa có.
4. Chưa thấy policy/allowlist loại collection nào được sync field chuẩn.
5. Chưa thấy mapping rõ giữa group ↔ species/governance_role ở level enforce.
  → Đều làm được nhưng cần thiết kế chi tiết hơn. 🟡
Xung đột với luật hiện hành / với Điều 35:
- Điều 36 nói GRP-CMS ví dụ directus_*; trong khi Điều 0-H cấm bypass và Directus internals là khu vực nhạy cảm. Nếu cho dot-collection-field-sync chạm directus_* thì rủi ro cao. Đây là xung đột triển khai cần chặn. 🔴
- Với Điều 35: không xung đột bản chất, nhưng Điều 35 phụ thuộc Điều 36 ở chỗ DOT target collections/phân nhóm. Tôi xem Điều 36 là nền cho 35. 🟢
Backfill 138 collections: không thực tế cho “1 mission” nếu hiểu là full compliance end-to-end. Nên tách ít nhất 3 pha:
1. seed + health-only
2. governed collections
3. observed/excluded/system/junction
  Nếu làm một cục sẽ rất dễ chạm Directus/system collections sai. 🔴
Rủi ro chưa tính:
1. Tier 2 field sync có thể tạo field vào collection không nên có. 🔴
2. many_to_many tự sinh junction có thể kéo theo naming/prefix/species/birth/group chưa được định nghĩa rõ. 🟡
3. Bước 12 verify KB/Nuxt phụ thuộc sync/runtime, cần timeout/retry/định nghĩa PASS cụ thể. 🟡

Kết luận khả thi Điều 36: Khả thi cho pilot và Phase 1 có kiểm soát. Không khả thi nếu hiểu là “một mission làm sạch 138 collections” theo full protocol. Xếp hạng: 🔴 3, 🟡 5, 🟢 3.

Câu 5: Ý KIẾN KHÁC

Cần cập nhật Điều 3 hoặc Điều 36 cho khớp nhau: Nếu Điều 3 là luật tối cao về metadata, thì Tier 1/Tier 2 phải map đủ các field bắt buộc hoặc nêu rõ field nào lấy từ Directus system metadata. Hiện draft thiếu rõ ràng. 🔴
Cần thêm anti-pattern: “AP-XX: Dùng một bộ field standards áp mù cho mọi collection.” Điều 36 chỉ an toàn khi có scope áp dụng. 🔴
Nên cập nhật Điều 29 hoặc bổ sung rule liên kết: group không được thay species/governance_role, nhưng phải có mapping kiểm tra chéo. Ví dụ group=JUNCTION mà species/governance_role lại là governed business entity thì phải báo. 🟡
Ưu tiên triển khai: Điều 36 trước Điều 35, hoặc ít nhất khởi động Điều 36 trước 1 pha. Lý do: muốn quản trị DOT tốt thì trước hết collections — đối tượng DOT tác động — phải có protocol chuẩn. Điều 35 nên nối ngay sau 36, không nên tách xa. 🟡

TÓM TẮT

Tổng số vấn đề: 🔴 11 nghiêm trọng, 🟡 35 quan trọng, 🟢 42 gợi ý/điểm đạt
Kết luận: CẦN SỬA TRƯỚC

Phán quyết tổng quan

Điều 35: Hướng đúng, nhưng còn 4 lỗi cốt lõi phải sửa trước ban hành:
1. new_dot không nên auto-approve toàn phần, nhất là DOT B có secret
2. Auto-classify / auto-dependency từ naming convention đang quá tin
3. Quy trình tạo file DOT thật chưa DOT-hoá rõ
4. Retire DOT chưa khóa vòng đời file vật lý / cron / registry
Điều 36: Mạnh và gần sẵn sàng hơn Điều 35, nhưng còn 3 lỗi lớn:
1. collection_field_standards chưa có scope áp dụng
2. Tier 1/Tier 2 chưa chứng minh tuân thủ đầy đủ Điều 3 metadata 13 fields
3. Backfill 138 collections phải tách pha, không nên đóng gói như một mission full-cleanup

Khuyến nghị thứ tự

Vá Điều 36 trước (scope field standards + map metadata + pilot governed)
Sau đó vá Điều 35 (approval policy + dependency semantics + retire file lifecycle)
Rồi mới ban hành cặp 35-36 như bộ đôi governance cho DOT và collections