Skip to content
← ทุกบท

บท 03

เทมเพลตแผนและงาน

Deep Work Plan คือไดเรกทอรีของไฟล์ markdown รูปร่างของไดเรกทอรีนั้น — และของแต่ละไฟล์ภายใน — คือสิ่งที่ทำให้แผนทบทวนได้โดยทั้งมนุษย์และเอเจนต์

โครงสร้างแผน

แผนคือไดเรกทอรีภายใต้ .dwp/plans/ ที่ตั้งชื่อว่า PLAN_001_<slug>/ ภายในประกอบด้วย:

  • manifest.json — เอกลักษณ์ของแผนและตัวชี้ไปยังสัญญาที่มีผล ซึ่งถูกเขียนขึ้นเป็นอันดับแรกเมื่อแผนถูกสร้างขึ้น
  • contract.json — สัญญาผลลัพธ์แบบระบุเนื้อหาและไม่เปลี่ยนรูป (เกณฑ์การยอมรับ ขอบเขต กฎคงที่)
  • journal.ndjson — log การทำงานแบบ append-only ของเหตุการณ์ใน ledger
  • state.json — สแนปช็อตที่ฉายจาก journal และไม่เคยถูกแก้ไขด้วยมือ
  • README.md — ภาพรวมของแผน ได้แก่ เป้าหมาย วัสดุต้นทาง ตารางงาน และสถานะ
  • PROGRESS.md — log การทำงานที่มนุษย์อ่านได้และบันทึกต่อเนื่อง
  • 1.task_<slug>.md, 2.task_<slug>.md — ไฟล์ markdown ของแต่ละงาน
  • analysis_results/ — ไดเรกทอรีสำหรับผลลัพธ์ของงาน รายงานการวิเคราะห์ และหลักฐาน gate

แพ็ก 7.x ปัจจุบันสร้างแผน v7 เป็นค่าเริ่มต้นโดยมี slug 2–5 คำ เช่นเดียวกับแผน v6 โฟลว์ v5 เดิมใช้ 2–4 คำเนื่องจากสคีมาที่ตรึงไว้นับ ID ตัวเลขเป็นหนึ่งคำ แผนใหม่จะได้รับ ID ตัวเลขที่เพิ่มขึ้นตามลำดับและมีอย่างน้อยสามหลัก (เช่น PLAN_001_add_payment_webhooks/) โฟลเดอร์เดิมที่ไม่มีหมายเลข PLAN_<slug>/ ยังคงอ่านได้และจะไม่มีการเปลี่ยนชื่อ และจะไม่มีการย้ายแผนเดิมโดยนัย หากมีแผนที่มีหมายเลข latest จะหมายถึงแผนที่มี ID ตัวเลขสูงสุด

โครงสร้างไฟล์งาน

แต่ละไฟล์งานตั้งชื่อว่า <n>.task_<slug>.md และปฏิบัติตามสิบส่วนมาตรฐานที่นิยามโดยสกิลที่ติดตั้ง (ดู ลูปหลัก สำหรับโครงสร้างงาน) แต่ละงานยึดโยงกลับไปยังเป้าหมายของแผนก่อนลงมือ ซึ่งช่วยกันไม่ให้เอเจนต์เบี่ยงเบนไปตลอดช่วงเวลายาวนานหลายชั่วโมง

Final Review

ทุกแผนต้องจบด้วยงานบังคับเพียงหนึ่งเดียวพอดี นั่นคือ Final Review มันปิดแผนด้วยห้าขั้นตอนตามลำดับ — ไม่มีการผ่อนปรนสิ่งใดในการตรวจความปลอดภัยหรือ gate:

  1. การตรวจความปลอดภัย — ตรวจสอบทุกสิ่งที่แผนเปลี่ยนแปลงเพื่อหาความลับ ความเสี่ยงจาก injection และพื้นผิวการโจมตีใหม่ คง docs/SECURITY.md ให้เป็นปัจจุบัน และรันการตรวจทาน AI Diff Reviewer เฉพาะที่ตามที่กำหนดครอบคลุมขอบเขตทั้งหมดของแผน (หากไม่มีตัวตรวจทานจะถูกบันทึกเป็นข้อค้นพบ local reviewer not installed และไม่เคยถูกข้ามไปอย่างเงียบ ๆ) สิ่งที่พบในระดับวิกฤตจะปิดกั้นการเสร็จสิ้น
  2. การตรวจสอบสถานะสุดท้าย — ชุดการทดสอบ lint และ type-check ที่ใช้ได้ทั้งหมดของ repository รันและผ่านบนสถานะสุดท้าย การแก้ไขใด ๆ ระหว่างการตรวจทานจะทำให้ผลลัพธ์ที่ได้รับผลกระทบเป็นโมฆะและต้องรันใหม่
  3. การกระทบยอดเรื่อง skill — ตรวจสอบว่าทุกงานได้บันทึกการจัดการเรื่อง skill เฉพาะงานไว้แล้ว และกระทบยอดการประพันธ์ที่สมควรใน analysis_results/SKILLS_CANDIDATES.md
  4. การกระทบยอดเอกสาร — กวาดตรวจพื้นผิวที่แตะต้องของทุกงานที่เปลี่ยนพฤติกรรมเทียบกับเอกสารที่ลงทะเบียนไว้ (docs/TESTING_GUIDE.md, เอกสารสถาปัตยกรรม และ AGENTS.md)
  5. การเสร็จสิ้น — บันทึกของแผนสอดคล้องกัน (รายการงาน, progress log และในแผน v6 และ v7 คือสแนปช็อตและใบเสร็จที่ได้จาก journal); รายงานผลงานที่ส่งมอบ หลักฐาน และข้อจำกัด และเสนอ Executive Report หนึ่งครั้ง

ข้อตกลงของ README และ PROGRESS

README.md ของแผนต้องมีชื่อเรื่อง (# Deep Work Plan: <name>) คำบอกกล่าวเป้าหมายแบบร้อยแก้ว ส่วนวัสดุต้นทางที่เป็นทางเลือก ตารางงาน (หมายเลข ชื่องาน ช่องทำเครื่องหมายสถานะ) และบรรทัดสถานะแผนในรูปแบบ <n>/<total> tasks complete

PROGRESS.md คือ log การทำงานแบบเพิ่มได้อย่างเดียว แต่ละรายการบันทึก timestamp แบบ ISO 8601 หมายเลขและชื่องาน สิ่งที่ทำไป และการเบี่ยงเบนหรือเหตุผลในการข้ามใด ๆ เพราะมันมีแต่จะเติบโตขึ้นเรื่อย ๆ มันจึงเป็นประวัติที่เชื่อถือได้ว่าแผนคลี่คลายไปอย่างไรจริง ๆ

หัวข้อและการอ้างอิงข้าม

หัวข้อทั้งหมดใช้ตัวพิมพ์แบบประโยค และเอกสารหลีกเลี่ยงภาษาเชิงการตลาดและเครื่องหมายอัศเจรีย์ ข้อตกลงเหล่านี้ทำให้แผนสอดคล้องกันข้ามเอเจนต์และตลอดเวลา