Council Review — Gói DOT Repair Governance — Round 1 — Gemini

Ngày: 2026-04-18 | Điểm tổng: 9.2/10 | Phán quyết: APPROVE WITH CHANGES

1. Tóm tắt 1 câu

Gói amend đồng bộ hoá 4 điều luật nhằm chính quy hoá tầng "ops-code", xoá bỏ hardcode whitelist và thiết lập quy trình sửa lỗi DOT canonical đã enacted theo đúng tinh thần NT4, NT9 và NT12 của Hiến pháp.

2. Đánh giá từng Patch (P1 Đ41 / P2 Đ32 / P3 Đ35 / P4 Đ22)

P1 (Đ41 v1.1): Điểm 9/10

• Triết lý: Đạt. Việc định nghĩa layer ops-code/ (tầng trung gian giữa infra và app) là bước đi đúng đắn để quản lý các DOT bash scripts vốn đang "vô chủ".
• Wording: Cần làm rõ "deploy đơn giản hơn app" ở §3.3. Dù không canary, nhưng vẫn cần cơ chế "rollback tức thì" nếu verify thất bại.
• Đề xuất: Bổ sung yêu cầu: "Mọi thay đổi ops-code phải đảm bảo tính tương thích ngược (backward compatibility) với các request đang chạy (in-flight requests) nếu không có cơ chế dừng queue."

P2 (Đ32 v1.1): Điểm 9.5/10

• Triết lý: Rất tốt. Chuyển whitelist từ hardcode bash sang PG-native (apr_action_types) triệt để thực thi NT4 (Config > Hardcode).
• Wording: §3.2 seed edit_dot_file cần đổi thành patch_ops_code để nhất quán với danh từ layer vừa tạo ở P1.
• Đề xuất: Bảng apr_action_types cần thêm cột risk_level (low/medium/high) để tự động hóa việc quyết định "Chủ tịch" hay "Council" duyệt ở bước P3.3.

P3 (Đ35 v5.2): Điểm 8.5/10

• Triết lý: Đạt. Xây dựng flow fix_repair_dot 6 bước khép kín. Tuy nhiên, bước 4 (APPLY) đang gộp quá nhiều trách nhiệm vào agent thực thi.
• Wording: §5.3 "paired test script" là điểm sáng nhưng "Retrofit 90 ngày" là quá dài cho các DOT canonical quan trọng (như nrm-enact).
• Đề xuất: Rút ngắn retrofit §5.3 xuống 30 ngày cho nhóm DOT nrm-* và apr-*. Bổ sung bước "7. Post-mortem" (tùy chọn) cho các lỗi gây [BLOCKED] nghiêm trọng.

P4 (Đ22 v1.1): Điểm 9/10

• Triết lý: Tuyệt vời. Kỹ thuật hoá triết lý "phơi bày ra ánh sáng" bằng lệnh set -e và cấm 2>/dev/null câm. Đây là "vaccine" cho hệ thống.
• Wording: §4.1(a) cho phép 2>/dev/null ở "probe tồn tại" cần ví dụ code chuẩn (e.g. if command -v ... >/dev/null 2>&1).
• Đề xuất: Cần quy định rõ: Việc sử dụng || true chỉ được phép ở các lệnh "cleanup" (như rm -f) và phải có comment giải trình.

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

• NT4 (Config > Hardcode): Chấp hành nghiêm túc qua P2 (PG-native whitelist).
• NT9 (Không chắc = Sai): Được củng cố qua P4 (cấm nuốt lỗi) và P3 (flow rõ ràng).
• NT10 (Danh-Thực tương xứng): Sửa lỗi "nhắc tên fix_repair_dot nhưng không có flow" ở Đ35.
• NT12 (DOT cặp đôi): Áp dụng triệt để ở P4 (silent-fail-scan + repair).
• NT2/NT13 (PG First): P2 đưa whitelist vào DB Main là chuẩn bài.

3. Tương tác giữa 4 Patch

• Thứ tự: P1 -> P2 -> P3 -> P4 là logic. Tuy nhiên, P2 cần được thực thi (về mặt SQL DDL) TRƯỚC khi agent có thể dùng dot-apr-propose phiên bản mới để thực hiện P3.
• Xung đột: Không thấy xung đột trực tiếp. Các patch hỗ trợ lẫn nhau theo mô hình lớp (layer).

4. Retrofit clause

• §6.7 (14 ngày cho P4) là thực tế vì số lượng DOT cần sửa lớn (13/13).
• §4.2 (90 ngày cho test script) cần phân loại: DOT lõi (30 ngày), DOT phụ (90 ngày).

5. Bỏ sót / rủi ro

• Rủi ro: Khi dot-ops-silent-fail-scan phát hiện lỗi hàng loạt, hệ thống có thể bị tràn ngập system_issues. Cần cơ chế "coalesce" (gộp) các lỗi cùng pattern.
• Lỗ hổng: Chưa quy định việc "sửa bug trong chính DOT sửa bug" (vòng lặp vô hạn). Cần fallback mode cho ADMIN.

6. Patch đề xuất bổ sung

• P5 (Đ38): Cập nhật dot-nrm-enact (canonical) ngay lập tức sau khi P1-P4 enacted để thông luồng S178 Fix 14.

7. Quyết định cuối + lý do

Phán quyết: APPROVE WITH CHANGES Lý do: Gói amend giải quyết triệt để gốc rễ vấn đề, tuân thủ nghiêm ngặt Hiến pháp. Các thay đổi về wording và retrofit clause mang tính hiệu chỉnh thực tế, không thay đổi triết lý cốt lõi.

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