Prompt deep research và lập lịch phần việc còn lại của CXK

Ngày 26/09/2026, UTC+7 · Môi trường: tác tử AI có quyền đọc, sửa workspace CXK và tra cứu web.
Yêu cầu thực thi ngay sau khi lưu prompt. Dùng Astra cho các subagent trong phiên.
Bổ sung yêu cầu: dự án đã bắt đầu; lập lịch phần còn lại, không khởi động lại từ đầu.

Mục tiêu

Nghiên cứu sâu và hoàn thiện toàn bộ công việc còn lại tới sản phẩm nghiên cứu có thể bàn giao, cài đặt và sử dụng đúng phạm vi.
Bao phủ mọi vai trò: AI, NCS1, NCS2, CVYK, GVHD, người kiểm quyền, reviewer độc lập và người vận hành.
Bao gồm người quản dữ liệu, hỗ trợ, người tham gia và bên quyết định nghiên cứu khi hoạt động cần họ.
Mỗi vai trò phải có công việc, đầu vào, đầu ra, thời lượng, trách nhiệm và điểm bàn giao rõ.
Phân bổ từng ngày thực tế và từng tuần, theo phụ thuộc và nguồn lực.

1. Xác lập hiện trạng, không lên lịch lại việc đã làm

Đọc AGENTS, README, Glossary, INDEX, nhật ký, biên bản các đợt nâng cấp và mã hiện có.
Đối chiếu roadmap v7, kiến trúc, T01–T20, D01–D20, CAM/CYK và các quyết định còn mở.
Kiểm file thật; tên file hoặc dấu tích trong kế hoạch không chứng minh chức năng đã hoàn thành.
Phân loại từng đầu ra: đã có bằng chứng; mới làm một phần; chỉ có bản nháp; chưa làm; đang chờ quyết định.
Lưu bằng chứng, ngày, giới hạn và phần còn thiếu.
Không phủ nhận kết quả test lịch sử chỉ vì môi trường máy hiện tại khác.
Nếu môi trường hiện tại chưa tái lập được, lập việc xác minh riêng với phạm vi rõ.

Đọc lịch sử chuẩn bị từ 12–20/09 và hoạt động 23–26/09.
Lịch W1 cũ ghi 21–27/09; đây là nhãn lịch, không tự chứng minh ngày khởi công thực.
Chốt hiện trạng ngày 26/09. Lập lịch tiếp tục từ ngày làm việc kế tiếp theo dữ kiện và giả định được công khai.
Giữ lịch sử nguyên trạng. Không tạo nhật ký tương lai từ kế hoạch.

2. Deep research bằng nguồn chính thức

Tìm và đọc nguồn sơ cấp về vòng đời phần mềm, thiết kế, bảo mật, kiểm thử, triển khai và trợ năng.
Ưu tiên ISO công khai, NIST, OWASP, W3C và tài liệu chính thức của nền tảng đang dùng.
Kiểm phiên bản/ngày hiện hành; không dựa vào trí nhớ về phiên bản tiêu chuẩn.
Không tuyên bố đã đọc toàn văn tiêu chuẩn có phí khi chỉ đọc phần mô tả công khai.
Mỗi nguồn ghi URL, nội dung đã đọc, giới hạn, áp dụng cho việc/tài liệu nào và tiêu chí kiểm.
Tách yêu cầu nội bộ bắt buộc khỏi hướng dẫn tham khảo. Không tự tuyên bố chứng nhận tuân thủ.
Nguồn quản trị phần mềm không thay nguồn y khoa cho tính năng camera.

3. Bổ sung đầy đủ công việc vòng đời phần mềm

Kiểm ít nhất các phần sau:

1. Xác nhận mục tiêu sản phẩm, người dùng, phạm vi và điều kiện nghiệm thu.
2. Phân tích yêu cầu chức năng, phi chức năng, luồng sử dụng và truy vết yêu cầu.
3. Thiết kế kiến trúc, dữ liệu, API, UI, an toàn, quyền riêng tư và vòng đời phiên bản.
4. Quản lý cấu hình, môi trường, mã nguồn, phụ thuộc, bí mật, kiểm mã và bản dựng.
5. Tri thức: nguồn/quyền, thẻ, quy trình đo, review, phát hành và thu hồi.
6. Backend, frontend, bộ lọc an toàn, trích dẫn, trạng thái lỗi và các điểm tích hợp.
7. Camera: nguồn y khoa → quy trình duyệt → phép đo → kiểm chứng → tích hợp có điều kiện.
8. Chiến lược kiểm thử, bộ ca, đơn vị/tích hợp/toàn luồng, tải, bảo mật, trợ năng và riêng tư.
9. Kiểm chứng chuyên môn, người review độc lập, xử lý bất đồng và lỗi nghiêm trọng.
10. Cài đặt môi trường thử và môi trường phát hành; cấu hình IIS/SQL; phân quyền và HTTPS.
11. Đóng gói, nâng cấp, chuyển dữ liệu, sao lưu, phục hồi và quay lại bản trước.
12. Hướng dẫn cài đặt, quản trị, vận hành, sử dụng, xử lý lỗi, hỗ trợ và đào tạo.
13. Nghiệm thu, hoạt động có người được phép, tiếp nhận phản hồi và sửa lỗi.
14. Bàn giao mã/tài liệu, quyền truy cập, giấy phép, trách nhiệm vận hành và hồ sơ AI.
15. Theo dõi sau phát hành, cập nhật nguồn, xử lý sự cố và ngừng dịch vụ/xóa dữ liệu.

Tái sử dụng tài liệu/mã đã có. Phân biệt sửa/hoàn thiện với tạo mới.
Không sinh hàng loạt file trống hoặc dùng tên tài liệu để tính là hoàn tất.
Với mỗi đầu ra cần viết sau này, ghi đường dẫn dự kiến, nội dung bắt buộc, người soạn và tiêu chí nghiệm thu.
Tính năng ngoài phạm vi đã chọn phải có điểm quyết định và danh mục mở rộng; không âm thầm thêm vào bản tối thiểu.

4. Phân vai và phân rã công việc

Mỗi việc có ID ổn định, liên kết T/D/CAM/CYK, trạng thái hiện tại và ước lượng phần còn lại.
Ghi chủ trì, phối hợp, người kiểm và người có quyền quyết định.
Có đầu vào, phụ thuộc, đầu ra, đường dẫn, tiêu chí hoàn thành và cách xử lý khi bị chặn.
Tách soạn, tự kiểm, kiểm chéo, sửa và nghiệm thu khi chúng cần thứ tự rõ.
Không xếp reviewer kiểm trước khi có bản để kiểm.

AI có việc cụ thể: tìm/đối chiếu nguồn, nháp đặc tả kỹ thuật, mã/test, kiểm định dạng và tổng hợp lỗi.
Tách lượt chạy AI khỏi giờ công con người. Không bịa tốc độ hoặc tỷ lệ AI thay thế nhân sự.
NCS đọc hiểu, kiểm tra, thử, sửa, tự thực hiện phần học thuật và ghi cách dùng AI.
AI không phê duyệt y khoa, quyền dữ liệu, nghiên cứu hoặc cổng kiểm soát.
Giữ phần học thuật bắt buộc của NCS theo quy định áp dụng; không dùng lịch quản trị này làm bản nộp thay học sinh.

5. Lập lịch phần còn lại

Ước lượng lại phần còn thiếu; không coi 316/162/87/35h cũ là giờ còn lại.
Không cộng hai lần việc dùng chung hoặc trừ giờ đã làm khi không có bằng chứng về giờ thực.
Mỗi ngày có ngày lịch, thứ, tuần, vai trò, ID việc, số giờ/lượt AI, đầu ra và điều kiện.
Mỗi tuần có mục tiêu, bàn giao, tải từng vai trò, phần chờ và ngày nghỉ/dự phòng.
Ngày không có việc phải ghi nghỉ, dự phòng hoặc chờ, không để bảng tưởng như bị thiếu.
Không dồn nhiều giờ vào một ngày vượt khả năng học sinh.

Dùng dữ kiện giờ khả dụng đã có; phần chưa xác nhận ghi giả định và cơ chế thay đổi.
Tách người kiểm quyền, người kiểm độc lập, người vận hành và người giữ dữ liệu; không xem là một người thay thế được.
Khi một cá nhân kiêm vai, cộng tải của mọi vai đó trước xác nhận lịch.
Phê duyệt là việc có điều kiện; ngày kế hoạch không biến thành ngày được duyệt.
Ghi thời gian chờ riêng, cơ chế dời toàn bộ việc phụ thuộc và phương án làm việc độc lập.
Giữ GCA trước thử kỹ thuật, GCB trước tích hợp và GC trước mọi hoạt động có người.

Xác định các mốc: bản nội bộ, bản đủ kiểm tích hợp, bản được phép thử giới hạn, sản phẩm bàn giao và theo dõi sau phát hành.
Nêu ngày kết thúc theo kịch bản, đường phụ thuộc quyết định tiến độ và độ nhạy khi chậm review.
Nếu phạm vi mới cần lâu hơn lịch cũ, tính lại và giải thích; không ép vừa 38/42 tuần.

6. Đầu ra phải lưu và tích hợp

• Prompt này trong docs/research/prompts/.
• Báo cáo nghiên cứu và nguồn chính thức trong Research/.
• Bộ kế hoạch phần còn lại tại docs/research/plans/KE_HOACH_CON_LAI/.
• Bảng hiện trạng, danh mục công việc, vai trò/tài liệu, lịch tuần và lịch đủ từng ngày.
• Dữ liệu lịch máy đọc được và công cụ kiểm/generate nếu giúp tránh sai số khi cập nhật.
• Roadmap/kiến trúc/sổ tiến độ/chỉ mục được nối tới kế hoạch mới, không để hai lịch cùng điều khiển.
• Nhật ký chỉ ghi việc lập kế hoạch đã thực hiện; bản viết tay tổng hợp trong ngày được cập nhật.

7. Kiểm tra trước bàn giao

Kiểm ID duy nhất, đủ nhiệm vụ, không vòng phụ thuộc, đúng thứ tự và không bỏ bước quyết định.
Kiểm không lên lịch lại đầu ra đã hoàn tất; phần kiểm lại có lý do và phạm vi riêng.
Cộng giờ theo việc/ngày/tuần/vai trò; kiểm tải, ngày nghỉ và tổng lượt AI riêng.
Kiểm mọi việc có đầu ra/DoD; mọi đầu ra bắt buộc có người thực hiện và lịch.
Kiểm mốc sản phẩm thật, tài liệu cài đặt/sử dụng và người nhận vận hành có trong lịch.
Chạy kiểm cấu trúc, thuật ngữ, liên kết, UTF-8 không BOM; dọn file trung gian.
Đối chiếu độc lập lịch trước kết luận. Báo hạn chế, giả định và quyết định còn chờ.

Thực hiện toàn bộ nghiên cứu và cập nhật kế hoạch trên ngay trong phiên.
Các nhiệm vụ xây dựng, triển khai và thử nghiệm tương lai phải được ghi lịch; không nhận chúng đã hoàn tất vì đã lập kế hoạch.