Instruction file imported from toandungmediavn-sketch/DRAG-GAME-NEW (.github/instructions/response-format.instructions.md). Copyright stays with the author.

Response Format — Code Analysis & Code Changes

Mỗi lần phân tích hoặc sửa code, bắt buộc trả kết quả theo đúng 9 hạng mục sau. Không bỏ sót hạng mục nào.

Cấu trúc bắt buộc

1. Đang xử lý hạng mục gì

Nêu rõ tên hạng mục, tính năng, hoặc vùng code đang được xử lý.

2. Mục tiêu kỹ thuật của hạng mục này

Giải thích mục đích kỹ thuật: tại sao hạng mục này cần được phân tích hoặc sửa, và kết quả mong muốn là gì.

3. Hiện trạng phát hiện được

Mô tả trạng thái hiện tại của code — vấn đề, pattern đang dùng, điểm yếu hoặc điểm mạnh. Dẫn chứng bằng file và dòng code cụ thể.

4. Đã làm những gì

Liệt kê rõ từng thay đổi đã thực hiện (file nào, dòng nào, thay đổi gì).
Nếu chưa sửa code mà mới audit → ghi: "Audit only — chưa sửa code."

5. Chưa làm gì

Liệt kê những việc nằm trong phạm vi hạng mục này nhưng chưa được thực hiện và lý do (out of scope, blocked, cần thêm context, v.v.).

6. Lỗi / rủi ro / blocker

Nêu rõ:

• Lỗi tiềm ẩn hoặc bug đã biết sau thay đổi
• Rủi ro về dữ liệu, bảo mật, hiệu năng
• Blocker cần giải quyết trước bước tiếp theo

7. File liên quan

Liệt kê tất cả file đã đọc, đã sửa, hoặc bị ảnh hưởng bởi thay đổi. Dùng đường dẫn workspace-relative và số dòng nếu có.

8. Cách kiểm tra kết quả

Hướng dẫn cụ thể để verify thay đổi hoạt động đúng:

• Lệnh test nào cần chạy
• API endpoint nào cần gọi
• Hành vi observable nào cần kiểm tra

9. Bước tiếp theo đề xuất

Đề xuất bước tiếp theo có thứ tự ưu tiên rõ ràng — bước nào làm trước, bước nào phụ thuộc vào bước trước.

Quy tắc bổ sung

• Nếu chỉ audit (không sửa code): ghi rõ **Audit only** ở hạng mục 4.
• Nếu đã sửa code: hạng mục 4 phải liệt kê đầy đủ file đã thay đổi và tác động của từng thay đổi.
• Không được bỏ qua bất kỳ hạng mục nào, kể cả khi không có gì để báo cáo — ghi "Không có" nếu trống.
• Dùng link markdown cho file references: [path/file.ts](path/file.ts#L10)