Bài 7 — Policy vận hành: khi nào chặn merge, khi nào chỉ góp ý

Agent càng có "quyền lực" (chặn merge) thì càng cần chính sách rõ ràng và lối thoát cho con người. Bài này thiết kế policy quyết định khi nào agent chỉ góp ý, khi nào chặn, và cơ chế override để không ai bị kẹt.

1. Bậc thang mức độ can thiệp

Triển khai theo giai đoạn, tăng quyền dần khi niềm tin tăng:

• Silent/log — agent chạy, chỉ ghi log, chưa comment. Đo chất lượng.
• Advisory — comment công khai, check neutral, không chặn.
• Soft block — chặn merge khi có lỗi high, nhưng cho phép override bằng label.
• Hard block — chặn cứng với một số category (vd secret bị lộ) không cho override.

Đừng nhảy thẳng lên hard block. Mỗi bậc cần dữ liệu chứng minh agent đủ chính xác.

2. Ánh xạ severity → hành động

policy:
  high:   block        # lỗi logic/bảo mật → chặn (soft)
  medium: comment      # góp ý, không chặn
  low:    comment       # góp ý nhẹ
  secret_leak: hard_block   # lộ khoá → chặn cứng
override_label: "agent-override"   # maintainer gắn để bỏ qua soft block

3. Cơ chế override cho con người

Agent có thể sai, hoặc lỗi "high" đôi khi là chấp nhận được trong ngữ cảnh. Luôn có lối thoát:

• Maintainer gắn label agent-override → check chuyển sang pass.
• Ghi lại ai override và vì sao (audit trail) để học và chịu trách nhiệm.

if has_label(pr, cfg["override_label"]):
    post_check(conclusion="success", summary="Override bởi maintainer.")
    log.info(f"Override bởi {actor} trên PR #{pr}")
    sys.exit(0)

Các bước thiết lập policy

• Khởi động ở bậc Advisory ít nhất 2–4 tuần, thu số liệu.
• Định nghĩa bảng severity → action trong config.yml.
• Bật soft block cho high khi tỷ lệ false positive đã thấp.
• Thêm label override + branch protection yêu cầu check agent-review.
• Với category cực nghiêm trọng (secret, SQL injection rõ ràng) mới cân nhắc hard block.
• Ghi audit mọi lần block và override.

Khung tư duy "quyền đi kèm trách nhiệm và lối thoát"

Mỗi khi tăng quyền cho agent, tự hỏi ba câu:

• Bằng chứng nào cho thấy agent đủ chính xác ở mức này?
• Lối thoát cho con người khi agent sai là gì?
• Ai chịu trách nhiệm khi block sai làm chậm release?

Ví dụ tình huống

Agent chặn một hotfix lúc 2h sáng vì báo "high: thiếu test". Không có override, release production bị kẹt. Bài học: hotfix cần đường override nhanh (label), và "thiếu test" nên là medium (góp ý) chứ không phải high (chặn). Policy sai còn nguy hiểm hơn agent sai.

Sai lầm thường gặp

• Bật hard block ngay từ đầu. Chưa có dữ liệu độ chính xác mà đã chặn cứng → tai nạn vận hành. Đi từng bậc.
• Không có đường override. Một false positive có thể chặn cả release. Luôn cho con người quyền phủ quyết.
• Đưa "thiếu test"/"đặt tên" lên mức chặn. Chỉ chặn thứ thật sự nguy hiểm (bug logic, bảo mật). Phần còn lại góp ý.
• Không audit các lần block/override. Không có vết thì không học được và không quy trách nhiệm được.
• Policy hard-code trong code. Để trong config.yml để chỉnh nhanh mà không cần deploy lại.

Ví dụ: hàm quyết định kết luận check từ policy

def decide(comments, cfg):
    if any(c["category"] in cfg["hard_block"] for c in comments):
        return "failure", "Hard block: phát hiện vấn đề nghiêm trọng."
    has_high = any(c["severity"] == "high" for c in comments)
    if has_high and cfg["severity_block"] == "high":
        return "failure", "Có lỗi high — cần xử lý hoặc gắn label override."
    return "neutral", "Có góp ý, không chặn merge."

Logic quyết định đọc thẳng từ config nên đội chỉnh policy được mà không đụng code. Nhớ kiểm tra label override TRƯỚC khi gọi decide để maintainer luôn có lối thoát.

Checklist trước khi tăng lên bậc chặn

• [ ] Đã chạy Advisory đủ lâu và có số liệu false positive thấp?
• [ ] Bảng severity → action đã review với đội?
• [ ] Có label override + audit log?
• [ ] Branch protection yêu cầu đúng tên check agent-review?
• [ ] Đội biết cách override khi cần gấp (hotfix)?

Còn một mảnh cuối để agent tồn tại lâu dài trong đội: đo lường, chi phí và cải tiến liên tục — Bài 8.