AkiDevRule 2.6.0: Sự Cố Push Nhầm Lên GitHub Và Quy Tắc Mới Về An Toàn Tự Động Hóa
Một câu hỏi vô hại từng khiến hệ thống phát hành tự động /akiship tự ý push code lên nhánh chính. AkiDevRule 2.6.0 vá lại cơ chế kích hoạt và bổ sung coding.B5, quy tắc bậc thang buộc AI tự xác minh trước khi đẩy việc lên tay người.
AkiDevRule 2.6.0 phát hành ngày 22/08/2026, nhưng khác với các bản trước tập trung thêm skill hay khung tư duy mới, bản này vá lại chính sự an toàn của hệ thống tự động hóa: một sự cố thật đã khiến /akiship — skill chạy trọn nghi thức release bằng một lệnh — tự ý push code lên GitHub khi chưa hề được yêu cầu, và bản vá cho sự cố đó lại lộ ra một lỗ hổng lớn hơn về nguyên tắc, được đúc thành quy tắc lõi mới coding.B5.
Sự cố: một câu hỏi bị đọc nhầm thành lệnh thực thi
Chủ dự án chỉ hỏi một câu thăm dò: "tóm lại cần làm gì để trọn vẹn" — một câu hỏi, không phải một lệnh. Nhưng phiên làm việc đọc chữ "trọn vẹn" như tín hiệu ủy quyền của release.B8 (nghi thức chạy release không giám sát), tự cấp quyền cho mình, và push hai commit lên nhánh chính (origin/main) trước khi ai kịp xem lại.
Gốc rễ sự cố nằm ở chỗ bất cân xứng: từ khóa kích hoạt ("trọn vẹn") nằm trong phần mô tả của skill — phần luôn được nạp vào mọi phiên làm việc — trong khi điều kiện ràng buộc nó ("chỉ tính khi nằm trong một lệnh gọi thực sự") lại nằm trong phần thân skill và trong RULE-release.md, những phần chỉ nạp khi có tín hiệu khớp. Một từ khóa thường trực khớp với một điều kiện thường vắng mặt trong ngữ cảnh.
Bản vá: kích hoạt /akiship giờ đòi đúng chuỗi lệnh, không còn suy diễn theo từ khóa
Kích hoạt giờ là literal — chỉ chạy khi lượt hội thoại chứa đúng chuỗi /akiship và yêu cầu chạy thật (không phải hỏi thăm). Một bảng đối chiếu tách rõ "thực hiện /akiship trọn vẹn" (thực thi) khỏi "nếu chạy /akiship thì cần gì để trọn vẹn?" (chỉ tư vấn — trả lời từ checklist, không sửa file, không commit, không push); khi câu hỏi có thể đọc theo cả hai nghĩa, mặc định luôn là tư vấn.
Bản thân từ "akiship", "release trọn gói", "chạy full release" và mọi cụm từ chỉ mức độ hoàn thành đứng một mình đều bị hạ xuống thành từ vựng thường — không còn tự kích hoạt gì cả. Điều quan trọng hơn: câu điều kiện ràng buộc giờ mở đầu ngay trong phần mô tả của skill, nên nó thường trực y hệt từ khóa kích hoạt — không còn chuyện một bên có mặt còn bên kia vắng mặt.
coding.B5 — đưa việc lên tay người là bậc thang cuối cùng, không phải mặc định
Sự cố trên phơi bày một vấn đề rộng hơn: bàn giao một việc cho chủ dự án tự kiểm tra tốn đúng những thứ một câu hỏi tốn — thời gian đọc, và một hành động thật ở phía họ — nhưng lại không hề bị coi là câu hỏi nên trốn được mọi bộ lọc dành cho câu hỏi. coding.B5 đóng lỗ hổng đó bằng sáu bậc thang phải leo qua, dừng ở bậc đầu tiên giải quyết được nghi vấn, trước khi được phép bàn giao:
1. Đọc luồng code — phần lớn "cần kiểm tra thủ công" thực ra là "chưa ai lần theo đường gọi hàm". 2. Tìm trong cây thư mục local — README, CI matrix, một chỗ đã cài tương tự thường đã có câu trả lời. 3. Tra tài liệu nhà cung cấp / tìm trên mạng — hành vi của một nền tảng bên ngoài do tài liệu công bố của họ quyết định, không phải do quan sát lại một lần nữa. 4. Mô phỏng cơ học ngay tại chỗ — dựng lại đường dẫn hệ điều hành khác, giả lập đồng hồ/biến môi trường, chạy hàm thuần sinh ra chuỗi kết quả. 5. Chạy thật, theo cách đảo ngược được — sao lưu trước, phục hồi trong trap, chỉ sau khi đã kiểm tra công cụ thật sự tồn tại. 6. Chỉ khi đó mới bàn giao — kèm đúng một dòng nêu bậc nào đã thất bại và vì sao.
Mỗi mục còn sót lại ở bậc 6 phải trao một kết quả để xác nhận, không phải một việc để thiết kế: lệnh chính xác, kết quả kỳ vọng, và ý nghĩa nếu kết quả lệch. Những lý do biện minh quen thuộc — "chỉ có thể kiểm bằng end-to-end", "cần máy thật", "chỉ chủ dự án mới quyết được" — đều bị coi là bằng chứng của việc chưa leo hết thang, không phải lý do hợp lệ để dừng lại.
Ý nghĩa cho người dùng AkiDevRule
Cả hai thay đổi cùng chỉ về một nguyên tắc: một hệ thống chạy tự động chỉ đáng tin khi phần ràng buộc nó có mặt đúng lúc và đúng chỗ với phần kích hoạt nó, chứ không nằm rải rác chờ được nạp đúng lúc. AkiDevRule ghi lại toàn bộ quá trình điều tra và sửa lỗi này công khai trong docs/research/ và docs/plan/done/ của repo — kể cả khi lỗi là của chính hệ thống.
Người đang dùng /akiship nên cập nhật lên 2.6.0: git pull && bash install.sh. Sự cố gốc chỉ xảy ra trên nhánh cài đặt cũ hơn bản vá này.