kt9 --fix: quy trình tự động sửa hàng loạt lỗi PR, CI, deploy

TL;DR: kt9 --fix là một lệnh duy nhất quét toàn bộ Pull Request đang mở, đối chiếu trạng thái CI theo từng commit cụ thể, tự áp các fix an toàn (rerun job lỗi tạm thời, chuẩn hoá PR template), và in ra một dashboard cho biết chỗ nào cần con người can thiệp. Bài này là phần thực hành — áp dụng trực tiếp lên chính ca lỗi đã kể ở phần 2.

Hai phần trước của series nói về lý thuyết (vaccine CI/CD) và một ca lỗi thật (chuỗi sự cố Tera parse). Phần này là hướng dẫn thực hành kt9 --fix tự động sửa lỗi CI: cụ thể phải gõ lệnh gì, đọc gì, và quyết định gì khi CI báo đỏ hàng loạt.

kt9 --fix tự động sửa lỗi CI hoạt động theo quy trình nào

Khi gõ kt9 --fix, quy trình chạy qua bốn bước:

1. Quét toàn bộ PR đang mở qua GitHub API — không chỉ PR bạn đang làm, mà TẤT CẢ.
2. Phân loại health từng PR: 🟢 Clean (sẵn sàng merge) · 🟡 Running (đang chờ CI) · 🔴 Blocked (có check fail thật) · 🟦 Review (cần người xem).
3. Tự áp fix an toàn cho những lỗi đã biết là cơ học — ví dụ rerun một job fail do lỗi mạng/rate-limit tạm thời, hoặc chuẩn hoá lại PR body cho khớp template chuẩn của repo.
4. In dashboard tổng hợp: bao nhiêu PR sạch, bao nhiêu đang chờ, bao nhiêu bị chặn, kèm danh sách "remaining issues" — những gì KHÔNG tự sửa được và cần người đọc log.

Điểm quan trọng nhất nằm ở bước 3: ranh giới giữa "an toàn để tự sửa" và "cần người quyết định". Rerun một job fail vì rate-limit là an toàn (idempotent, không đổi code). Nhưng sửa một lỗi cú pháp template — như ca ở phần 2 — thì không thể tự động đoán được cách sửa đúng; nó cần người đọc traceback, hiểu nguyên nhân, rồi viết code fix thật.

Đọc dashboard: phân biệt "PR bị chặn" và "đang chờ bình thường"

Một dashboard PR/CI hữu ích phải trả lời được câu hỏi: cái nào đang chờ tự nhiên, cái nào thực sự cần can thiệp? Nhầm hai loại này là nguyên nhân phổ biến khiến người ta hoảng loạn (rollback không cần thiết) hoặc chủ quan (bỏ qua một lỗi thật vì tưởng "đang chạy bình thường").

Trạng thái	Ý nghĩa	Việc cần làm
🟢 Clean	Mergeable, mọi check pass	Không cần làm gì
🟡 Running	Đang chờ CI, chưa có kết luận	Đợi, không rerun bừa
🔴 Blocked	Có check fail thật, không tự sửa được	Đọc log, xác định nguyên nhân
🚨 Deploy incident	Deploy production đang fail	Ưu tiên xử lý trước mọi PR khác

Trong ca ở phần 2, dashboard ban đầu cho thấy nhiều PR cùng 🔴 Blocked với cùng một dòng lỗi Tera — dấu hiệu rõ ràng đây không phải N lỗi độc lập, mà là MỘT lỗi gốc (trên main) đang lan ra nhiều PR con cùng lúc. Nhận ra pattern "nhiều PR cùng fail một kiểu" quan trọng hơn việc sửa từng PR riêng lẻ — sửa gốc rồi rebase lại toàn bộ nhánh con luôn nhanh hơn sửa từng cái một. Cách tra cứu check-run theo SHA cụ thể (gh api repos/{owner}/{repo}/commits/{sha}/check-runs) được mô tả chi tiết trong tài liệu REST API của GitHub — nguồn tham chiếu chuẩn khi cần xác nhận tuyệt đối một commit đã pass hay chưa.

Khi nào kt9 --fix không đủ — và cần đọc log thật

kt9 --fix xử lý tốt các lỗi cơ học lặp lại, nhưng có ba tình huống nó không thể tự quyết:

• Lỗi logic mới, chưa có trong thư viện vaccine — cần chẩn đoán từ đầu, không có pattern để so khớp.
• Race condition trong chính pipeline — như ca auto-merge chốt nhầm bản fix cũ ở phần 2. Đây không phải lỗi code, mà lỗi thời điểm, chỉ phát hiện được khi so sánh SHA commit cụ thể, việc mà dashboard tổng quan không tự làm thay được.
• False positive từ chính script QA — khi công cụ kiểm tra tự nó sai (ví dụ coi văn xuôi là mã quảng cáo thật), không có "auto-fix" nào đoán đúng ý định gốc của người viết script; phải đọc code kiểm tra và sửa logic detect.

Nguyên tắc thực dụng: dùng kt9 --fix như bước lọc đầu tiên — nó xử lý phần lặp lại, nhàm chán, để dành thời gian con người cho đúng phần khó: hiểu TẠI SAO một lỗi mới xảy ra, chứ không phải gõ lại các lệnh rerun quen thuộc.

Ba nguyên tắc để dùng an toàn

1. Mọi thay đổi tự động vẫn đi qua Pull Request. Không bao giờ để bot hay script push thẳng vào nhánh chính — kể cả khi fix đó "chắc chắn đúng". PR là điểm dừng bắt buộc để có thể review, dù review đó là CI tự động hay mắt người.
2. Xác nhận theo SHA, không theo tên workflow. Như đã thấy ở phần 2, tin vào "qa-check: success" hiển thị trên UI có thể chỉ đúng cho một commit CŨ. Luôn tra commits/<sha>/check-runs khi cần chắc chắn tuyệt đối.
3. Merged không đồng nghĩa live. Một PR merge xong không có nghĩa production đã build lại thành công với đúng thay đổi đó — luôn xác nhận deploy thực tế trước khi báo "đã xong" cho người khác.

Tổng kết series

Ba phần của series này đi từ lý thuyết (mô hình vaccine, severity model P0-P3) tới một ca thật (chuỗi lỗi Tera parse + auto-merge race + false positive) và cuối cùng là quy trình thực hành (kt9 --fix + cách đọc dashboard). Điểm chung xuyên suốt: tự động hoá không phải để tin tưởng mù quáng, mà để loại bỏ phần lặp lại, giải phóng thời gian cho đúng phần cần tư duy — chẩn đoán nguyên nhân gốc, chứ không phải chạy lại cùng một lệnh mỗi lần build đỏ.

Đọc thêm

• Vaccine CI/CD tự động hoá: học từ lỗi build, không lặp lại
• Case study CI/CD fail: một dòng Tera parse lỗi kéo 5 PR theo
• Giảm deploy fail từ hàng chục xuống gần 0: case study Deploy Guard + Snapshot Production
• Checklist theo dõi deploy sau khi merge: từ merge tới xác nhận production 200 OK
• Dùng codex doctor, codex mcp và config.toml để tự chẩn đoán Codex CLI
• Chuyên mục Công nghệ +++