COUNCIL REVIEW VÒNG 2 — GPT

XÁC NHẬN ĐÃ ĐỌC

Hiến pháp v4.0.2
13 luật liên quan
Điều 35 v4.0
Điều 36 v3.0
Báo cáo vòng 1 (GPT + Gemini)

Phương pháp vòng 2: không lặp lại khen/chê vòng 1. Tôi chỉ xác nhận cái gì đã fix đúng, và tập trung vào điểm gãy tiềm năng khi triển khai thật trên production.

ĐIỀU 35 v4.0

Câu 1-4: Xác nhận sửa + vấn đề mới còn lại

Đã fix đúng 4 điểm đỏ vòng 1:
1. §6.1 bước 2 đã tách DOT A auto-approve / DOT B pending Desktop duyệt → đúng hơn Điều 32 và Tuyên ngôn ②. 🟢
2. §5.3 đã hạ naming convention xuống mức gợi ý, không còn tự suy đoán dependency → đúng NT-9. 🟢
3. §6.2 đã khóa vòng đời retire bằng move file sang bin/dot/retired/ + xoá cron entry và §5.1 check 9 retired alive → fix trúng lỗ hổng vòng 1. 🟢
4. §6.1 bước 3 đã nói rõ AI agent viết file trong PR, không giả vờ DOT tự sinh file nữa. 🟢
5. §2.1 last_executed đã chuyển từ metadata trang trí sang nghĩa vụ runtime. 🟢
Vấn đề mới còn lại, nhưng chưa tới mức thiết kế lại:
1. §2.3 dot_coverage_required.domain và §3.1 dot_domains.code chưa nói rõ domain lưu kiểu nào: gốc (monitoring) hay phân cấp đầy đủ (monitoring.dot, governance.approval). Nếu seed sai format, UNIQUE(domain, operation) vẫn pass nhưng coverage metrics sẽ lệch. 🔴
2. §5.3 dot-dot-register auto-classify theo pattern, nhưng §3.2 operation có bảng đối ứng khá giàu (create/update/delete/scan/health/propose/execute/refresh/migrate/backup/report/register), trong khi naming table ở §5.3 mới cover một phần. Kết quả: DOT mới có thể luôn rơi vào coverage_status='partial', làm coverage baseline nhiễu. 🟡
3. §8 ghi “Điều 31 ⚠️ cần update thêm §DOT monitoring” nghĩa là chính luật đang tự thừa nhận còn dependency ngược chưa hoàn tất. Về pháp lý, điều này chưa chặn ban hành, nhưng về triển khai production nó là một gap monitor-of-monitor. 🟡

★ Câu 5: ĐIỂM GÃY TRIỂN KHAI

5A. Thứ tự

Phải tạo dot_domains trước khi enforce FK trên dot_tools.domain.
- Căn cứ: §2.1 dot_tools.domain FK → dot_domains.code, §2.2 dot_domains.
- Nếu thêm field domain + FK trước khi seed dot_domains, dữ liệu backfill đang là text tự do sẽ fail ngay lúc attach constraint. 🔴
Phải seed dot_domains trước, rồi mới backfill dot_tools.domain, rồi mới ADD CONSTRAINT FK.
- Nếu đi thứ tự ngược: ALTER TABLE ADD CONSTRAINT sẽ fail vì 154 DOT hiện có chưa được chuẩn hóa domain. 🔴
Phải tạo dot_coverage_required sau khi thống nhất format domain ở dot_domains.
- Nếu chưa chốt domain là monitoring hay monitoring.dot, coverage table seed trước sẽ tạo mẫu số sai; về sau phải migrate lại toàn bộ coverage metrics. 🟡
Phải thêm 10 fields vào dot_tools trước khi chạy dot-dot-health v4.0.
- Căn cứ: §5.1 dùng tier, paired_dot, last_executed, coverage_status, file_path.
- Scanner mới mà chạy trên schema cũ sẽ fail hoặc false positive hàng loạt. 🔴
Phải backfill tier/trigger_type/file_path/status/domain/operation tối thiểu trước khi dùng các metrics coverage_pct/paired_pct/auto_pct.
- Căn cứ: §4, §5.2.
- Nếu không, dashboard ngày đầu chỉ phản ánh “thiếu metadata”, không phản ánh chất lượng DOT thật. 🟡
Điều 36 Phase 1 nên đi trước Điều 35 Phase 2.
- Vì §2.4 của Điều 35 yêu cầu DOT phải khai target collections; nếu collection governance chưa chuẩn hóa group/protocol theo Điều 36, target metadata dễ lệch. 🟡

5B. Chicken-and-egg (gà-trứng)

dot-dot-register tự đăng ký DOT mới, nhưng bản thân dot-dot-register phải được đăng ký trước.
- Căn cứ: §5.3, §6.1 bước 4.
- Đây là bootstrap problem. Luật chưa nói rõ “seed DOT nền tảng đầu tiên bằng migration one-time” hay “pre-registered bootstrap set”. Nếu không nói rõ, CLI agent sẽ hỏi: ai đăng ký dot-dot-register đầu tiên? 🔴
dot-dot-health dùng để kiểm DOT chưa đủ, nhưng DOT health itself cũng cần paired_dot, domain, target_collections, last_executed.
- Nếu bộ DOT nền tảng không được seed tay một lần có kiểm soát, scanner sẽ tự quét chính nó như orphan/partial ngay từ ngày đầu. 🟡
entity_dependencies target của DOT mới phải do agent khai báo ở §6.1 bước 5, nhưng agent chỉ biết target sau khi luật collection/protocol ổn định.
- Với DOT tạo mới phục vụ Điều 36, target có thể là collections chưa sinh ra hoặc chưa có group/registry ổn định. Đây là vòng lặp mềm giữa Điều 35 và 36. 🟡
Desktop verify coverage_status → complete ở §6.1 bước 9 phụ thuộc data từ dot-dot-health và target dependencies đã đủ, nhưng dependencies không auto-suy đoán nữa.
- Nghĩa là nếu agent quên bước 5, DOT sẽ mãi partial. Đây không sai thiết kế, nhưng là chicken-and-egg vận hành: “chưa đủ metadata thì không complete; chưa complete thì coverage dashboard nhiễu”. 🟡

5C. Production safety

Backfill 154 DOT phải chia 3 pha transaction-safe, không làm 1 migration lớn.
- Pha 1: add nullable fields, chưa FK.
- Pha 2: seed dot_domains, backfill data.
- Pha 3: attach FK/CHECK cứng + bật scanners.
- Nếu làm thẳng 1 lần, lỗi giữa chừng sẽ để dot_tools ở trạng thái nửa cũ nửa mới, scanner v4.0 sẽ báo loạn. 🔴
paired_dot self-FK có thể fail khi backfill cặp A/B nếu insert/update sai thứ tự.
- Giải pháp triển khai phải là add nullable trước, backfill sau. Nếu CLI agent cố enforce ngay NOT NULL cho tier B hoặc set pair theo thứ tự file scan, sẽ dính lỗi dữ liệu vòng tròn. 🔴
last_executed là field bắt buộc runtime, nhưng luật chưa nói migration giá trị cũ sẽ là gì.
- Nếu để NULL hết cho 154 DOT rồi bật §5.1 check 6 stale, toàn bộ cron DOT cũ có thể bị gắn stale ngay ngày đầu. Nên cần grace period hoặc baseline seed. 🟡
retired alive check 9 đòi file phải move sang bin/dot/retired/ và cron phải xoá.
- Nếu script retire fail ở bước xoá cron nhưng move file đã xong, runtime vẫn có cron gọi path cũ và sinh lỗi. Luật đúng nhưng chưa mô tả verify xoá cron bằng nguồn chân lý nào. 🔴
Report path reports/dot-dot-health-YYYY-MM-DD.json trên 1 VPS $8 nếu không có log rotation / retention sẽ phình file.
- Không phải lỗi kiến trúc, nhưng là điểm gãy vận hành production sau vài tháng. 🟡

5D. Edge cases

DOT utility / helper / one-off migration script thuộc domain nào?
- §3.1 có 11 domain gốc, nhưng không có domain “utility” hoặc “migration.oneoff”. Nếu ép vào domain gần nhất, metrics coverage sẽ méo; nếu để partial mãi, dashboard mất ý nghĩa. 🔴
Một DOT có nhiều operation thật sự thì lưu gì?
- §2.1 operation là 1 field text, §3.2 giả định 1 operation chính. Nhưng nhiều DOT thực tế vừa scan vừa report, hoặc execute + backup. Luật chưa nói chọn operation chính hay cho phép khai secondary operation trong extra_metadata. 🟡
Một DOT có nhiều target collections khác loại (read + write + verify) thì entity_dependencies relation_type nào?
- Điều 35 chỉ nói “khai báo target_collections → INSERT entity_dependencies”, nhưng không chuẩn hóa relation_type cho DOT. Điều 8 hiện có uses, requires, extends, displays, triggers, chưa thật khớp reads/writes/verifies. 🟡
trigger_type='manual' + operation cần tự động ở check 7 sẽ fail theo luật, nhưng chưa có danh sách operation nào “cần tự động” là SSOT.
- Nếu không có allowlist/denylist, scanner phải suy luận, lại vi phạm NT-9. 🔴

5E. Tương tác giữa 2 luật

Hai bảng FK độc lập dot_domains và collection_groups là đúng, không cần gộp.
- Nhưng thiếu một bảng/mapping chéo cho biết domain DOT nào thường được phép tác động group collection nào. Ví dụ collection.protocol tác động GRP-REGISTRY/GRP-GOVERNANCE/GRP-BUSINESS, còn monitoring.dot chủ yếu đọc. Không có mapping này, target_collections vẫn khai báo được nhưng khó audit “có hợp lý không”. 🟡
dot-dot-health và dot-collection-health cùng ghi approval_requests.
- Không thấy conflict schema-level, nhưng có nguy cơ APR trùng nội dung. Ví dụ collection mới tạo thiếu species: collection-health tạo APR; đồng thời DOT create chưa complete → dot-health tạo APR khác. Nếu không có dedupe key ở Điều 32, backlog APR sẽ phình đôi. 🔴
Cơ chế evolving fields ở Điều 35 §6.3 và Điều 36 §2.2 giống nhau về pattern, nhưng tách là đúng.
- Không nên gộp bảng ngay, vì đối tượng và scope khác nhau. Điểm gãy không nằm ở “tách hay gộp”, mà ở chỗ cả hai cùng tạo APR + sync. Cần bảo đảm scheduler/order không đá nhau trên production. 🟢
Điều 35 phụ thuộc Điều 36 ở mức target chuẩn hóa; Điều 36 phụ thuộc Điều 35 ở mức 3 DOT collection.
- Đây là phụ thuộc vòng, nên phải giải bằng bootstrap set seed tay có kiểm soát chứ không chờ hai luật tự cứu nhau. 🔴

5F. Đo lường thành công

Phase 1 DONE của Điều 35 không thể đo bằng coverage tổng thể ngay.
- Vì §5.3 auto-classify chỉ là gợi ý và coverage_status='partial' cho mọi DOT auto-classified.
- Tiêu chí DONE phase 1 nên là:
  - 100% dot_tools có đủ 10 fields mới
  - 100% record có tier, file_path, status
  - 100% domain backfill hợp lệ với FK dot_domains
  - 0 DOT B active mà thiếu paired_dot
  - 0 DOT retired nhưng file còn sống trong bin/dot/
- Nếu dùng coverage_pct làm success metric chính ở phase 1, sẽ đánh giá sai. 🔴
Coverage % “đủ” cho phase 1 nên đặt theo domain đã seed, không phải toàn hệ.
- Ví dụ: monitoring, collection, pivot, governance coverage đã có mẫu số rõ → target 80% hợp lý.
- Toàn hệ 154 DOT mà coverage table mới seed một phần thì % tổng không có giá trị. 🟡
Nếu metrics không đạt, phải tách 3 lớp nguyên nhân:
- luật sai (domain taxonomy/operation taxonomy sai)
- seed sai (dot_coverage_required thiếu ô required)
- triển khai sai (backfill hoặc dependency thiếu)
- Luật chưa viết rõ cách phân loại lỗi metrics này. 🟡

ĐIỀU 36 v3.0

Câu 1-4: Xác nhận sửa + vấn đề mới còn lại

Đã fix đúng 5 điểm vòng 1:
1. §2.2 thêm applies_to_groups[], exclude_groups[], exclude_patterns[] + §2.1 sync_field_standards boolean → xử lý đúng lỗ hổng scope. 🟢
2. §2.2 Tier 1 tăng từ 6 lên 8 fields với classification + owner → fix đúng thiếu Điều 3. 🟢
3. §7 tách legacy thành 3 pha → thực tế hơn. 🟢
4. §3 bước 8 thêm polymorphic → lấp lỗ hổng log/audit. 🟢
5. §3 tách 11 → 11a-11e + verify timeout/retry ở bước 12 → rõ hơn nhiều. 🟢
Vấn đề mới còn lại:
1. §2.2 vẫn là 2 tiers trong schema, nhưng tiêu đề nói “3 tầng minimum fields”. Nội dung mô tả 3 tầng ở vòng trước nay không còn nhất quán: table chỉ cho tier IN (1,2). Đây là mâu thuẫn tài liệu dễ làm agent hiểu sai. 🔴
2. §3 ghi “PROTOCOL 14 BƯỚC” nhưng bảng đánh số thực chất là 12 mục hiển thị (1-12, trong đó 11a-11e là phân rã). Nếu không quy ước rõ “14 logical steps”, agent test checklist có thể đếm lệch. 🟡
3. §5.2 check 8 Missing birth_registry entry trên collection-level hơi mơ hồ: birth registry là cho records hay cho collection entity? Nếu ý là collection phải có birth record trong registry quản trị thì cần gọi đúng tên/đúng scope để tránh lẫn với record-level birth trigger. 🟡

★ Câu 5: ĐIỂM GÃY TRIỂN KHAI

5A. Thứ tự

Phải seed collection_groups trước mọi thứ khác.
- Căn cứ: §2.1, §3 bước 2, §3 bước 10 collection_registry.group FK → collection_groups.
- Nếu chưa có group seed mà đã chạy dot-collection-create, bước 2 và 10 sẽ fail do FK. 🔴
Phải tạo collection_field_standards sau khi chốt taxonomy groups và sync_field_standards.
- Vì §2.2 scope logic dựa vào group và flags của group. Seed standards trước, groups sau → scope evaluation không ổn định. 🔴
Phải rollout dot-collection-health trước dot-collection-field-sync trên legacy.
- Nếu sync chạy trước baseline health, agent sẽ thêm field hàng loạt mà chưa biết collection nào thuộc scope thật, collection nào nên skip. Health-first mới ra baseline compliance %. 🔴
Phải chuẩn hóa scope trước khi insert Tier 2 records.
- name_en, description, sort là tier 2; nếu insert sớm trước khi xác nhận GRP-CMS/GRP-SYSTEM/GRP-LOG/GRP-JUNCTION=false, dot-sync có thể chạm nhầm collections nhạy cảm. 🔴
Bước 11a-11e phải đi theo thứ tự cụ thể:
- 11a entity_species trước 11b birth_registry verify
- 11c auto-code trigger trước khi insert test record verify
- 11d permissions trước 12 verify Directus/Nuxt
- 11e pivot_definitions trước 12 verify tab Pivot
- Luật đã tách bước nhưng chưa ghi rõ thứ tự nội bộ. 🟡
Điều 36 Phase 1 nên đi trước Điều 35 Phase 2.
- Khi collections đã có group + field standards + protocol health, Điều 35 mới audit target_collections và coverage thật có nghĩa. 🟡

5B. Chicken-and-egg (gà-trứng)

dot-collection-create là DOT B, nhưng chính DOT này cũng phải được quản trị theo Điều 35.
- Nghĩa là muốn tạo collection theo luật 36, trước hết phải có bootstrap DOT set của Điều 35. Đây là dependency vòng, không giải được chỉ bằng text hiện tại. Cần bootstrap seed. 🔴
collection_groups và collection_field_standards là collections/bảng nền, nhưng lại chưa có protocol trước khi chính chúng tồn tại.
- Ai tạo 2 SSOT tables đầu tiên? Nếu dùng dot-collection-create, lại vướng vì tool đó cần group đã tồn tại. Đây là bootstrap problem giống Điều 35. 🔴
dot-collection-health dùng để phát hiện legacy thiếu collection_registry/meta_catalog/species, nhưng để nó chạy đúng cần collection_groups và standards đã seed.
- Nghĩa là scanner phụ thuộc seed tay lần đầu. Điều này không sai, nhưng luật chưa nói rõ “bootstrap manual one-time allowed qua migration PR”. 🟡
Bước 12 verify KB (search_knowledge tìm thấy, timeout 30s, retry 1 lần) phụ thuộc Agent Data sync.
- Nhưng Agent Data hiện có lúc degraded. Nếu collection đã đúng ở PG/Directus mà KB chưa kịp sync, protocol có thể fail dù bản chất collection ổn. Đây là chicken-and-egg giữa “đồng bộ tri thức” và “hoàn thành collection”. 🔴

5C. Production safety

Backfill 138 collections phải cấm chạy sync tự động toàn bộ ngay sau khi seed standards.
- Căn cứ: §7 đã tách 3 pha. Nhưng nếu CLI agent seed xong rồi bật event trigger dot-collection-field-sync, các Tier 2 standards hiện có sẽ có thể chạy ngay trên diện rộng. Cần kill-switch hoặc mode dry_run/report_only cho phase baseline. 🔴
Thêm 8 Tier 1 fields vào collection hiện hữu qua Directus API có thể fail nửa vời.
- Ví dụ thêm được classification, fail ở owner; collection sẽ ở trạng thái nửa compliant, health báo đỏ hàng loạt. Cần idempotent + per-field retry + per-collection checkpoint rõ theo Điều 11. 🔴
GRP-SYSTEM và GRP-CMS nói “CẤM chạm”, nhưng legacy mapping group nếu sai có thể khiến sync chạm nhầm.
- Trình tự an toàn phải là: seed groups → gán group cho collections → review sample → mới bật field sync. Nếu bật sync trước khi group mapping đúng, sync_field_standards=false không cứu được. 🔴
Bước 11c auto-code trigger dùng template NEW.code := PREFIX + id.
- Nếu collection dùng UUID hoặc sequence chưa ổn định, template này sẽ fail hoặc tạo code lệch. Điều 36 nói “giữ nguyên v2.0” nhưng chưa nêu điều kiện áp dụng template. 🟡
Bước 12 verify KB/Nuxt có timeout/retry, nhưng chưa nói rollback khi KB fail còn 4 tầng kia pass.
- Nếu cứ mark FAIL toàn protocol, agent có thể retry tạo lại và sinh APR/metadata trùng. Cần quy định “4 tầng lõi pass, KB pending-sync = warning hay fail?” 🔴

5D. Edge cases

Collection thuộc 2 groups?
- §2.1 collection_groups + collection_registry.group hiện là 1 FK đơn. Luật mặc định 1 collection = 1 group. Điều này tốt cho đơn giản hóa, nhưng với collection vừa governance vừa business support thì agent sẽ hỏi chọn nhóm nào. Cần nguyên tắc: group = vai trò chính, phân loại phụ qua species/labels. Nếu không nêu, người triển khai sẽ lúng túng. 🟡
Bỏ một Tier 2 field sau khi đã sync cho 100 collections.
- §2.2 mới mô tả thêm field, chưa mô tả retire field chuẩn. Theo Luật Bảo toàn/Điều 32, không được drop tùy tiện. Cần lifecycle cho field standard: active → deprecated → retired, và sync bỏ scope chứ không drop ngay. 🔴
Polymorphic relation (entity_type + entity_id) không có FK cứng.
- Đây là edge case hợp lý cho log/audit, nhưng muốn tuân thủ Tuyên ngôn ② thì phải có scanner verify existence. Điều 36 thêm type mới nhưng chưa thêm check mới trong dot-collection-health cho polymorphic integrity. 🔴
Junction groups sync_field_standards=false đúng, nhưng vẫn cần fields tối thiểu riêng cho junction.
- Hiện luật nói “junction chỉ cần FK, không cần full fields”, nhưng chưa có junction-standard tối thiểu thành văn. Agent sẽ không biết junction có cần code/status/date_created hay chỉ 2 FK. 🟡

5E. Tương tác giữa 2 luật

Điều 35 và 36 đều ghi APR vào approval_requests; overlap là có thật.
- Ví dụ collection mới thiếu meta_catalog/species/pivot_definitions (§5.2 checks 5,6,7,10 của Điều 36) đồng thời DOT tạo collection còn coverage_status='partial' (Điều 35 §6.1 bước 9). Cùng một nguyên nhân có thể sinh 2 APR khác nhau. Nếu Điều 32 chưa có dedupe key theo (request_type, entity_code, issue_signature), production queue sẽ trùng. 🔴
dot_domains và collection_groups đang song song nhưng chưa có rule cross-map.
- Điều 35 target là collection; Điều 36 phân nhóm collection; nhưng chưa có chuẩn “domain X được phép tác động group Y”. Điều này làm Desktop review phải tự suy luận, không machine-check được. 🟡
Evolving fields cho DOT và Collections tách riêng là đúng.
- Không thấy điểm gãy ở việc tách. Điểm gãy là cả hai cơ chế đều là event-driven sync; nếu cùng bắn nhiều changes một lúc trên VPS nhỏ, cần queue/throttle. Luật chưa nói gì về giới hạn batch hay rate limit. 🟡
dot-collection-health (Điều 36) là một DOT cần hoàn chỉnh metadata theo Điều 35 trước, nhưng Điều 35 phase 1 lại bảo “backfill metadata KHÔNG dependencies”.
- Nghĩa là nếu triển khai đúng chữ Phase 1 của Điều 35, một DOT lõi của Điều 36 có thể chưa có dependencies đủ để pass check 8 no target. Hai phase phải xen đúng thứ tự, không thể tách cứng. 🔴

5F. Đo lường thành công

DONE Phase 1 của Điều 36 nên đo bằng baseline + pilot, không phải full compliance 138 collections.
- Tiêu chí nên là:
  - collection_groups và collection_field_standards đã tồn tại + seed xong
  - 100% collections được gán group hợp lệ
  - sync_field_standards=false đúng cho 4 nhóm skip (GRP-CMS, GRP-LOG, GRP-JUNCTION, GRP-SYSTEM)
  - dot-collection-health chạy baseline thành công, có compliance_pct
  - pilot governed collections pass >90% checks lõi
- Nếu đặt target “138 collections compliant” cho phase 1 thì sẽ fail giả. 🔴
Compliance % phải tách theo group và governance_role.
- Một con số tổng cho 138 collections không có nghĩa vì groups skip scope khác nhau. GRP-JUNCTION không nên bị chấm bằng rubric như GRP-BUSINESS. 🟡
Nếu metrics không đạt, luật cần chỉ rõ đường truy lỗi:
- group mapping sai
- standards scope sai
- sync bug
- health rubric sai
- Agent Data/Nuxt verify chậm
- Hiện luật chưa có “failure taxonomy” cho compliance_pct. 🟡

TÓM TẮT

Điểm gãy nghiêm trọng nhất:
1. Bootstrap gà-trứng cho cả hai luật: ai seed dot_domains, collection_groups, collection_field_standards, và đăng ký DOT nền tảng đầu tiên.
2. Thứ tự migrate/FK/backfill nếu làm sai sẽ fail production ngay.
3. APR trùng lặp giữa hai health scanners nếu Điều 32 chưa có dedupe signature.
4. Phase metrics đặt sai sẽ làm đội triển khai tưởng luật hỏng trong khi chỉ là baseline chưa phân pha.
Khuyến nghị thứ tự triển khai cụ thể:
1. Seed bootstrap one-time qua PR/migration có review: collection_groups, collection_field_standards, dot_domains, dot_coverage_required, bootstrap DOT set (dot-dot-register, dot-dot-health, dot-collection-health, dot-collection-field-sync, dot-collection-create)
2. Add nullable fields vào dot_tools → backfill → attach FK/CHECK
3. Gán group cho 138 collections → review sample → bật sync_field_standards=false đúng nhóm skip
4. Chạy health-only baseline cho cả DOT và collections
5. Sửa pilot trên governed scope
6. Sau khi baseline sạch mới bật event-driven sync và coverage metrics làm KPI chính
Phán quyết: CẦN SỬA TIẾP

Lý do phán quyết

Không còn lỗi tư duy lớn như vòng 1. Hai luật đã sửa đúng các điểm đỏ cũ. Nhưng ở góc độ triển khai thật, vẫn còn 4 điểm gãy production-level phải khóa trước khi giao agent làm:

Bootstrap path phải được viết thành luật/quy trình rõ ràng
Migration order phải được đóng đinh
APR dedupe ở Điều 32 phải có trước khi hai health scanners cùng chạy
Phase success metrics phải được định nghĩa theo baseline/pilot, không dùng % tổng quá sớm