Prompt Commitment

Hãy giải thích việc nhận được tài trợ sẽ cho phép tôi dành ra [X hours/days] mỗi tuần/tháng cho mã nguồn mở như thế nào, có sự so sánh giữa quỹ thời gian tình nguyện hiện tại với quỹ thời gian tiềm năng khi có tài trợ.

---
name: implementation-workflow
description: Triển khai các thay đổi mã nguồn với việc kiểm soát phạm vi có kỷ luật, bảo toàn trạng thái kho mã nguồn, kiểm chứng phù hợp và tạo các commit gom theo từng mối quan tâm. Sử dụng khi triển khai tính năng, sửa lỗi, tái cấu trúc hoặc khắc phục vấn đề trên một cơ sở mã nguồn (codebase) hiện có.
---

# Quy trình Triển khai Mã nguồn

Triển khai thay đổi được yêu cầu một cách an toàn, tối giản và ở định dạng dễ dàng rà soát (review).

## Phạm vi và thứ tự ưu tiên

Tuân thủ nhiệm vụ hiện tại, các hướng dẫn áp dụng trong kho mã nguồn như `AGENTS.md`, và các quy ước đã được thiết lập của dự án.

Không mở rộng phạm vi chỉ vì thấy có thể thực hiện thêm các cải tiến lân cận.

Kỹ năng này điều phối giai đoạn triển khai và khắc phục lỗi. Việc rà soát độc lập sau khi triển khai thuộc về kỹ năng `post-implementation-audit`.

## 1. Kiểm tra trước khi thay đổi

Trước khi chỉnh sửa:

- hiểu rõ hành vi được yêu cầu và các tiêu chí nghiệm thu (acceptance criteria);
- kiểm tra phần mã nguồn triển khai hiện có liên quan;
- kiểm tra trạng thái kho mã nguồn khi có sẵn Git;
- xác định các tệp đã bị chỉnh sửa, đã đưa vào vùng chờ (staged), đã xóa hoặc chưa được theo dõi (untracked) tồn tại từ trước.

Coi các thay đổi hiện có không liên quan là phần được bảo vệ.

Không ghi đè, loại bỏ, chuẩn hóa lại hoặc vô tình đưa các phần việc không liên quan vào.

## 2. Quyết định xem có cần lập kế hoạch hay không

Tiến hành làm trực tiếp khi nhiệm vụ nhỏ, cục bộ, rủi ro thấp và đã đủ rõ ràng.

Đối với công việc có quy mô đáng kể, hãy lập kế hoạch triển khai trước trừ khi đã có sẵn một bản kế hoạch được phê duyệt.

Công việc được coi là có quy mô đáng kể khi liên quan đến sự không chắc chắn lớn về mặt kiến trúc, nhiều thành phần tương tác qua lại với nhau, di chuyển dữ liệu (migrations), thay đổi giao ước công khai (public contracts), thay đổi hành vi trên diện rộng, hoặc có rủi ro đáng kể về bảo mật/độ tin cậy.

Khi cần một kế hoạch mới, hãy lập kế hoạch đó và dừng lại trước khi sửa đổi kho mã nguồn để bản kế hoạch có thể được duyệt trước.

Không lập những bản kế hoạch mang tính hình thức rườm rà cho các công việc nhỏ nhặt.

## 3. Triển khai trong phạm vi hẹp

Sau khi việc triển khai đã được cho phép:

- thực hiện thay đổi mạch lạc nhỏ nhất đáp ứng được nhiệm vụ;
- giữ nguyên kiến trúc và các quy ước hiện có trừ khi nhiệm vụ chủ đích yêu cầu thay đổi chúng;
- ưu tiên tận dụng các cơ chế sẵn có hơn là tạo thêm các lớp trừu tượng song song không cần thiết;
- tránh tái cấu trúc, dọn dẹp, đổi tên, định dạng lại mã hàng loạt, thay đổi thư viện phụ thuộc (dependencies) hoặc cải tiến mang tính phỏng đoán không liên quan;
- bảo toàn các thay đổi không liên quan nằm trong những tệp buộc phải chỉnh sửa cùng.

Không làm suy yếu các bài kiểm thử (tests), bước xác thực dữ liệu (validation), xử lý lỗi hoặc các cam kết đảm bảo hiện có chỉ để làm cho phần mã triển khai mới vượt qua bài kiểm tra.

## 4. Bảo toàn trạng thái kho mã nguồn

Không vứt bỏ công việc đang có sẵn chỉ để có được một kho mã nguồn sạch sẽ.

Trừ khi được yêu cầu và cho phép một cách rõ ràng, không sử dụng các thao tác mang tính phá hủy hoặc viết lại lịch sử như:

- `git reset`
- `git restore`
- `git stash`
- `git clean`
- rebase
- amend
- squash
- các thao tác viết lại lịch sử khác

Hãy làm việc khéo léo xung quanh trạng thái chưa sạch (dirty state) không liên quan thay vì xóa bỏ nó.

## 5. Kiểm chứng phần triển khai

Sử dụng bước kiểm chứng liên quan nhỏ nhất trước, sau đó mới mở rộng khi phạm vi hoặc mức độ rủi ro đòi hỏi.

Các bước kiểm chứng phù hợp có thể bao gồm kiểm thử có mục tiêu (targeted tests), phân tích tĩnh, kiểm tra quy tắc mã (linting), kiểm tra kiểu dữ liệu (type checking), biên dịch (builds), hoặc các bước kiểm tra đặc thù của kho mã nguồn.

Thêm mới hoặc cập nhật các bài kiểm thử khi cần thiết để chứng minh hành vi đã thay đổi hoạt động đúng.

Kiểm thử các hành vi có ý nghĩa thực tế và các luồng xử lý lỗi thay vì chỉ viết bài kiểm thử sao chép lại chi tiết triển khai bên trong.

Không bao giờ tuyên bố đã kiểm chứng những gì thực tế chưa được thực hiện.

Nếu không thể chạy bước kiểm chứng liên quan, hãy báo cáo rõ hạn chế đó thay vì mặc nhiên coi là đã thành công.

## 6. Chỉ tạo commit khi được cho phép

Chỉ tạo các bản commit khi được nhiệm vụ hiện tại hoặc hướng dẫn của kho mã nguồn cho phép một cách rõ ràng.

Khi được phép tạo commit:

- mỗi commit phải đại diện cho một mối quan tâm (concern) mạch lạc duy nhất;
- tách riêng các mối quan tâm không liên quan về triển khai tính năng, dọn dẹp mã, định dạng, tài liệu và tái cấu trúc trừ khi không thể tách rời;
- giữ cho các commit có thể hiểu được một cách độc lập, dễ rà soát và có thể hoàn tác (revert) hợp lý;
- sử dụng thông điệp commit (commit messages) có ý nghĩa rõ ràng.

Trước mỗi lần commit:

1. kiểm tra trạng thái kho mã nguồn;
2. xác định chính xác những thay đổi nào thuộc về mối quan tâm đang xét;
3. chỉ đưa vào vùng chờ (stage) đúng những thay đổi đó;
4. kiểm tra lại bản so sánh khác biệt đã đưa vào vùng chờ (staged diff);
5. chỉ thực hiện commit sau khi đã xác nhận đúng phạm vi của nó.

Ưu tiên việc stage tường minh theo từng tệp hoặc từng khối thay đổi (hunk).

Không sử dụng lệnh stage diện rộng như `git add .` khi nó có nguy cơ gom nhầm cả các thay đổi không liên quan.

Không viết lại các commit đã tồn tại trừ khi được yêu cầu rõ ràng.

## 7. Hoàn tất và bàn giao

Trước khi tuyên bố hoàn tất việc triển khai:

- xác nhận hành vi được yêu cầu và các tiêu chí nghiệm thu đã được giải quyết đầy đủ;
- chạy bước kiểm chứng cuối cùng phù hợp;
- kiểm tra bản diff cuối cùng để phát hiện các thay đổi vô tình hoặc không liên quan;
- báo cáo trung thực các hạn chế chưa được giải quyết.

Đối với các phần triển khai có quy mô đáng kể, hãy bàn giao sang quy trình `post-implementation-audit` sau khi đã ngừng việc chỉnh sửa mã nguồn.

Nếu quá trình hậu kiểm (audit) báo cáo có các phát hiện lỗi (findings):

1. quay trở lại giai đoạn triển khai/khắc phục;
2. chỉ sửa các phát hiện có căn cứ bằng thay đổi mạch lạc nhỏ nhất;
3. kiểm chứng lại phần đã khắc phục;
4. chạy lại `post-implementation-audit`.

Lặp lại cho đến khi kết quả hậu kiểm là `CLEAR` hoặc một hạn chế không thể giải quyết được báo cáo rõ ràng.

Các thay đổi nhỏ, cục bộ chỉ cần hậu kiểm độc lập khi nhiệm vụ, hướng dẫn của kho mã nguồn hoặc mức độ rủi ro đòi hỏi điều đó.

## Đầu ra

Khi hoàn tất, hãy báo cáo ngắn gọn:

- những gì đã thay đổi;
- các quyết định triển khai quan trọng;
- các bước kiểm chứng thực tế đã thực hiện;
- các hạn chế đáng kể hoặc vấn đề chưa được giải quyết;
- các commit đã tạo, nếu có.

Không lặp lại quy trình này dưới dạng danh sách đánh dấu (checklist) trong câu trả lời cuối cùng.