Council Review — Gói DOT Repair Governance v2 — Round 2 — Gemini

Ngày: 2026-04-18 | Điểm v2: 9.8/10 | Phán quyết: APPROVE FINAL

1. Tóm tắt 1 câu (so sánh v1 → v2)

Bản v2 là một bước nhảy vọt về độ chín kiến trúc, không chỉ đóng 6 lỗ hổng Round 1 mà còn định vị chính xác "ops-code" vào Hiến pháp và chuẩn hoá toàn bộ hạ tầng phê duyệt (APR) theo hướng Data-Driven, triệt để xoá bỏ hardcode.

2. Xác nhận các fix Round 1

• P1 (Deploy/Rollback): Đã đóng đúng. §3.3 bổ sung quy trình backup, git commit repo SSOT và log rõ ràng.
• P2 (Risk-level routing): Đã đóng đúng. §3.3 tách risk high/medium/low dẫn hướng phê duyệt tương ứng.
• P3 (Retrofit DOT lõi): Đã đóng đúng. §4.3 tách thời hạn 14/30/90 ngày rất thực tế.
• P4 (Annotation markers): Đã đóng đúng. §4.1 cung cấp bộ marker chuẩn để scanner nhận diện ngoại lệ.
• Coalesce system_issues: Đã đóng đúng. §4.1 cơ chế parent/children ngăn chặn bão thông báo.
• Infinite-loop safeguard: Đã đóng đúng. §6.5 ADMIN fallback mode cho phép sửa chính DOT phê duyệt.

3. Đánh giá 5 patch v2 (P1 / P2 / P3 / P4 / P9)

• P1 (Đ41 v1.1 - Ops Layer): 10/10. Việc chuyển từ "thư mục" sang "logical deployment class" rất linh hoạt.
• P2 (Đ32 v1.1 - Type Tables): 9.5/10. Thiết kế tách proposed_action_code ra khỏi JSONB là cực kỳ xuất sắc, vừa đảm bảo FK integrity vừa giữ được NT11 (khai tối thiểu).
• P3 (Đ35 v5.2 - Repair Flow): 10/10. Quy trình 6 bước có verify 3 tầng (Shell/DDL/Data) là rào chắn an toàn tuyệt đối.
• P4 (Đ22 v1.1 - Silent Fail): 9.5/10. Scanner 3 mức (critical/warn/allow) giúp agent ưu tiên xử lý lỗi mutation trước.
• P9 (HP v4.6.3 - Positioning): 10/10. Sửa lỗi "vi hiến" của v1. Đưa ops-code vào Lớp Kho (Layer 2) là hoàn toàn hợp lý vì đây là các artifact logic đã được đóng gói.

4. RÀ CHÉO LUẬT LIÊN QUAN (TRỌNG TÂM ROUND 2)

4.1 HP v4.6.2 — Xung đột / trùng / bỏ qua?

• Trạng thái: Tương thích 100%.
• Phân tích: P9 đã giải quyết điểm yếu nhất của v1. Việc xác nhận GitHub là SSOT và VPS là live instance cho ops-code giúp duy trì tính nhất quán của NT1.

4.2 Đ33 PostgreSQL — Xung đột / trùng / bỏ qua?

• Trạng thái: Bỏ qua một chi tiết nhỏ (P10 đề xuất).
• Phân tích: Đ33 yêu cầu mọi bảng hệ thống phải có cột _dot_origin để truy xuất nguồn gốc khởi tạo. Các snippet SQL trong P2 đang thiếu cột này. Cần bổ sung khi enact.

4.3 Đ36 Collection Protocol — Xung đột / trùng / bỏ qua?

• Trạng thái: Tương thích 100%.
• Phân tích: P2 §3.4 đã bổ sung điều khoản đăng ký vào collection_registry. Sequencing tại §3.5 đặt bước Đăng ký Đ36 ngay sau khi tạo bảng là đúng quy trình khai sinh.

4.4 Đ38 Normative Document — Xung đột / trùng / bỏ qua?

• Trạng thái: Tương thích 100%.
• Phân tích: Gói v2 cung cấp amend_law action type (P2 §3.2), đây chính là hạ tầng kỹ thuật cần thiết để Đ38 có thể "số hoá" các bản amend tiếp theo qua APR.

4.5 Đ39 Knowledge Graph — Xung đột / trùng / bỏ qua?

• Trạng thái: Tương thích 100%.
• Phân tích: Việc sửa đổi normative_registry (khi enact gói này) sẽ kích hoạt shadow trigger của Đ39. Gói v2 không can thiệp vào flow này, để Đ39 tự vận hành là đúng NT7.

4.6 Đ43 Bản đồ Hệ thống — Xung đột / trùng / bỏ qua?

• Trạng thái: Trùng lặp nhẹ (P11 đề xuất).
• Phân tích: Đ43 đang quản lý context-pack. Việc tạo layer ops-code mới cần được cập nhật vào section_definitions của Đ43 để context-pack trong tương lai có thể bao phủ cả tầng vận hành này.

5. Tuân thủ 13 NT Hiến pháp

• NT4 (Config > Hardcode): Thực thi triệt để qua P2 (bảng type) và P4 (scan paths).
• NT11 (Khai tối thiểu): Rất tốt trong P2, không lạm dụng JSONB cho các trường cần index/FK.
• NT12 (DOT cặp đôi): Áp dụng cho mọi DOT mới (scan/repair, register/audit).

6. Issue còn lại / patch bổ sung

PATCH P10 (Bổ sung cho P2) — Tuân thủ Đ33/Đ35:

Bổ sung cột _dot_origin TEXT NOT NULL vào 2 bảng apr_action_types và apr_request_types. Giá trị seed mặc định là 'S178_FIX15_AMEND'.

PATCH P11 (Bổ sung cho Đ43):

Yêu cầu cập nhật context_pack_section_definitions thêm section ops_code_map (dẫn nguồn từ ops_code_registry) để đảm bảo context-pack luôn đủ "não" về các công cụ vận hành.

7. Quyết định cuối + điều kiện enact

Phán quyết: APPROVE FINAL

Điều kiện tiền đề enact (Migration sequencing):

1. Barrier 1 (DDL): Chạy SQL tạo bảng type (P2 + P10) + thêm cột vào approval_requests + đăng ký Đ36.
2. Barrier 2 (Data): Backfill dữ liệu legacy cho proposed_action_code dựa trên payload cũ.
3. Barrier 3 (Code): Deploy DOT apr-* phiên bản mới đọc DB.
4. Barrier 4 (HP): Enact P9 để chính danh hoá toàn bộ quy trình.

Ký tên: Gemini CLI — Kiến trúc sư Hội đồng.