Skill / /znf:hotfix

/znf:hotfix [short-kebab-desc]

Xử lý một lỗi đang xảy ra trên production, từ chẩn đoán tới PR; /znf:fix tự chuyển sang khi có bằng chứng prd.

Cách gọi

/znf:hotfix [short-kebab-desc]

Khi nào dùng

Khi có lỗi đang ảnh hưởng production ngay bây giờ. Agent tự gọi skill này từ /znf:fix khi có bằng chứng production, và bạn vẫn gõ được trực tiếp. Xem hotfix: sửa lỗi trên production.

Cách hoạt động

1. Skill xác định repo bị ảnh hưởng, fetch trước rồi mới xác định base ref hotfix của repo đó, rồi tự xác nhận base ref bằng tag release: chỉ hỏi bạn khi base không chứa tag nào, không chứa tag mới nhất, hoặc trùng baseRef của repo (repo không khai base hotfix riêng). Base ref khác nhau tuỳ repo và tuỳ chiến lược mỗi repo khai báo.
2. Nếu được /znf:fix chuyển sang, skill dùng luôn nguyên nhân và bằng chứng đã xác nhận, không chẩn đoán lại. Nếu không, skill chẩn đoán trước khi đụng vào bất cứ thứ gì, dùng đúng hai bước đầu của /znf:fix: lấy log lỗi thật, xác nhận nguyên nhân gốc bằng bằng chứng. Ở bước này chỉ dùng các cách tái hiện chỉ đọc và lọc output thành <REDACTED>; nếu không có thì xác nhận nguyên nhân từ log, không dừng và không thêm log tạm trên production. Không đoán nguyên nhân trên production.
3. Với nguyên nhân đã xác nhận, có ba lựa chọn — revert, tắt bằng feature flag, hoặc sửa xuôi (fix forward). Skill dùng git blame trên đúng dòng lỗi để tìm commit cuối cùng chạm vào dòng đó. Khi commit này có trước tag release liền trước, skill tự sửa xuôi và ghi lý do; các trường hợp còn lại (không có tag liền trước, không chỉ ra được đúng một dòng lỗi, lỗi có thể do lần deploy gần nhất) skill hỏi bạn kèm khuyến nghị và chờ, vì đây là hành động trên production. Nếu chọn revert hoặc tắt flag, skill dừng ở đó, không tạo worktree, không sửa code.
4. Chỉ khi chọn sửa xuôi, skill mới tạo worktree từ base ref hotfix vừa xác nhận, gọi /znf:scout trên đúng ref đó, dựng lệnh đỏ và viết regression test (xác nhận nó fail trước khi sửa), sửa, rồi chạy lại lệnh đỏ và xoá log debug để xác minh lỗi đã hết.
5. Skill luôn gọi /znf:gate rồi /znf:ship, không bỏ qua vì đang gấp. Nếu diff quá 3 file (đếm cả file chưa commit và file mới) hoặc đụng tài nguyên dùng chung (collection, HTTP giữa service, pub/sub, queue), skill hỏi bạn trước và khuyên revert; việc đếm chạy lại sau mỗi vòng sửa của /znf:ship, trước khi commit. Nếu xanh hết, /znf:ship commit, push nhánh hotfix và mở PR nhắm vào base ref đã xác nhận; skill không merge.

Ví dụ

/znf:hotfix session-timeout-crash

Lưu ý

Sau khi PR được merge (việc của bạn), bạn cần đồng bộ base hotfix sang baseRef của repo (với zenify là main → staging) để lần release sau không mất bản sửa. Kiểm tra sau deploy chạy khi production đã chạy bản sửa: một tag release chứa commit merge, hoặc kiểm build (bundle, endpoint phiên bản, deploy log). Nếu việc sửa xuôi hoá ra lớn như một tính năng, đó là dấu hiệu nên chọn revert thay vì tiếp tục ở đây.