Skip to content
← Tất cả các chương

Chương 03

Mẫu kế hoạch và tác vụ

Một Deep Work Plan là một thư mục các tệp markdown. Hình dạng của thư mục đó — và của mỗi tệp bên trong nó — là điều khiến một kế hoạch rà soát được bởi cả con người lẫn agent.

Cấu trúc kế hoạch

Một kế hoạch là một thư mục dưới .dwp/plans/ được đặt tên PLAN_001_<slug>/. Nó chứa:

  • manifest.json — danh tính của kế hoạch và con trỏ tới hợp đồng trực tiếp của nó, được ghi đầu tiên khi hiện thực hóa.
  • contract.json — hợp đồng thực thi chính thức.
  • journal.ndjson — nhật ký sự kiện chỉ ghi thêm bất biến.
  • state.json — ảnh chụp nhanh được chiếu từ journal, không bao giờ chỉnh sửa bằng tay.
  • README.md — tổng quan kế hoạch: mục tiêu, tài liệu nguồn, bảng tác vụ và trạng thái.
  • Các tệp tác vụ, đặt tên <n>.task_<slug>.md.
  • PROGRESS.md — nhật ký thực thi chỉ ghi thêm.
  • analysis_results/ — kết quả phân tích, báo cáo kiểm toán và bằng chứng.

Gói 7.x hiện tại mặc định tạo kế hoạch v7. Các kế hoạch hiện có giữ nguyên thế hệ đã ghi nhận; việc di chuyển cần yêu cầu rõ ràng. Các kế hoạch mới nhận ID số tăng đơn điệu, có ít nhất ba chữ số (ví dụ PLAN_001_add_payment_webhooks/). Schema v5 đã cố định tính ID số là một từ, nên slug v5 có 2–4 từ; slug v6 và v7 có 2–5 từ. Các thư mục cũ không đánh số PLAN_<slug>/ vẫn đọc được và không bao giờ bị đổi tên. Khi có kế hoạch được đánh số, latest trỏ đến kế hoạch có ID số cao nhất.

Cấu trúc tệp tác vụ

Mỗi tệp tác vụ được đặt tên <n>.task_<slug>.md và tuân theo cấu trúc mười phần được trình bày chi tiết trong Vòng lặp lõi. Các phần luôn xuất hiện theo cùng thứ tự để người đọc lập tức biết tìm ở đâu. Mỗi tác vụ neo lại vào mục tiêu của kế hoạch trước khi hành động, giúp agent không bị trôi dạt qua một chân trời dài.

Final Review

Mọi kế hoạch phải kết thúc bằng đúng một tác vụ bắt buộc: Final Review. Nó khép lại kế hoạch qua năm bước tuần tự — không có gì trong bước rà soát bảo mật bị nới lỏng:

  1. Lượt rà soát bảo mật với đánh giá cục bộ bắt buộc — kiểm toán mọi thứ kế hoạch đã thay đổi để tìm bí mật, rủi ro tiêm nhiễm và bề mặt tấn công mới, giữ docs/SECURITY.md luôn cập nhật, và chạy đánh giá cục bộ AI Diff Reviewer bắt buộc trên toàn bộ phạm vi của kế hoạch (người đánh giá bị thiếu được ghi lại dưới dạng phát hiện local reviewer not installed, không bao giờ bị bỏ qua trong im lặng). Một phát hiện nghiêm trọng sẽ chặn việc hoàn thành.
  2. Kiểm chứng trạng thái cuối cùng — toàn bộ bộ kiểm thử, linter và kiểm tra kiểu của repository chạy và vượt qua trên trạng thái cuối cùng sau sửa đổi cuối.
  3. Đối chiếu quyết định về skill — xác minh rằng mỗi tác vụ đã ghi lại quyết định skill cục bộ, đối chiếu các ứng viên trong analysis_results/SKILLS_CANDIDATES.md.
  4. Đối chiếu tài liệu — liên kết bề mặt chạm tới của mỗi tác vụ làm thay đổi hành vi với tài liệu (docs/TESTING_GUIDE.md, kiến trúc, AGENTS.md).
  5. Hoàn thành — các bản ghi của kế hoạch đồng nhất (danh sách nhiệm vụ, nhật ký tiến độ và trong kế hoạch v6 và v7 là ảnh chụp nhanh cùng biên nhận phái sinh từ journal); báo cáo kết quả bàn giao, bằng chứng và giới hạn, đồng thời đề xuất Executive Report một lần.

Các quy ước README và PROGRESS

Tệp README.md của kế hoạch phải chứa một tiêu đề (# Deep Work Plan: <name>), một câu phát biểu mục tiêu dạng văn xuôi, một phần tài liệu nguồn tùy chọn, một bảng tác vụ (số thứ tự, tên tác vụ, ô đánh dấu trạng thái), và một dòng trạng thái kế hoạch theo dạng <n>/<total> tasks complete.

PROGRESS.md là một nhật ký thực thi chỉ ghi thêm. Mỗi mục ghi lại một dấu thời gian ISO 8601, số thứ tự và tên tác vụ, điều đã làm, và mọi sai lệch hay lý do bỏ qua. Vì nó chỉ luôn lớn lên, nó là một lịch sử đáng tin cậy về cách kế hoạch thực sự diễn ra.

Tiêu đề và tham chiếu chéo

Mọi tiêu đề dùng kiểu viết hoa đầu câu, và các tài liệu tránh ngôn ngữ tiếp thị cùng dấu chấm than. Các quy ước này giữ cho kế hoạch nhất quán qua các agent và theo thời gian.