มาตรฐานเอกสาร

เวอร์ชัน 5.0.0 มาตรฐานนี้นิยามว่า Deep Work Plan จัดทำเอกสารโครงสร้าง งาน และความคืบหน้าอย่างไร และ repository จัดทำเอกสารของตัวเองอย่างไรเพื่อให้ agent ลงมือกับมันได้อย่างปลอดภัย มันใช้กับทุกแผนที่สร้างขึ้นภายใต้ระเบียบวิธี DWP เวอร์ชันนี้ปรับเวอร์ชันของเอกสารเองให้สอดคล้องกับมาตรฐาน DWP ที่มันประกอบอยู่ด้วย — ไม่มีข้อกำหนดเดิมใดเปลี่ยนแปลง — และเพิ่มการบังคับใช้งบประมาณดัชนีแบบกระชับ (lean-index budget) และ feature tier ที่อธิบายไว้ด้านล่าง คำสำคัญ MUST, SHOULD และ MAY ใช้ตามที่นิยามไว้ใน RFC 2119

AGENTS.md ในฐานะจุดเริ่มต้นที่กระชับ

ไฟล์ AGENTS.md ที่ราก SHOULD อยู่ภายในงบประมาณ 150–500 บรรทัด เมื่อเนื้อหาที่ถูกสร้างขึ้นหรือดูแลโดย harness จะเกินขอบเขตนั้น เอเจนต์ MUST ย้ายรายละเอียดไปยังคู่มือ docs/ (หรือเอกสารของโมดูล/ฟีเจอร์) ที่เป็นเจ้าของมัน แล้วลิงก์กลับจากดัชนี — ไม่มีสิ่งใดถูกทิ้ง มีแต่ย้ายที่ และดัชนี MUST ลิงก์ไปยังทุกเอกสารที่ได้รับเนื้อหาที่ถูกย้ายมา AGENTS.md ที่เขียนด้วยมืออยู่แล้วและเกินงบประมาณจะไม่ถูกเขียนใหม่อย่างเงียบ ๆ เลย: เอเจนต์เสนอแผนการย้ายที่เป็นรูปธรรม (อะไรย้ายไปที่ไหน ลิงก์ใดถูกเพิ่ม) และนำไปใช้ก็ต่อเมื่อได้รับความยินยอมจากนักพัฒนาเท่านั้น ตัวตรวจสอบความสอดคล้องถือว่างบประมาณนี้เป็นคำแนะนำ (advisory) เพราะจำนวนบรรทัดเป็นวัตถุวิสัยแต่ผู้เขียนไม่ใช่ — MUST ผูกพัน harness ที่สร้างหรืออัปเดตไฟล์ ไม่ใช่การเดาของตัวตรวจสอบว่าใครเป็นผู้เขียน AGENTS.md MUST NOT ลิงก์ไปยังไฟล์ docs/ ที่ไม่มีอยู่จริง

เหนือระดับเอกสารต่อโมดูล (ด้านล่าง) มี feature tier: พื้นที่ความสามารถหลัก — ใหญ่กว่าหนึ่งโมดูล — จะได้โฟลเดอร์ docs/ ของตัวเองข้างโค้ดของมัน เข้าถึงผ่าน README.md ของตัวเอง พื้นที่หนึ่งมีคุณสมบัติเข้าเกณฑ์นี้เมื่อมันครอบคลุมสองโมดูลหลักขึ้นไป เป็นเจ้าของ sub-app หรือไดเรกทอรี subsystem ที่สมบูรณ์ในตัวเอง หรือพกสัญญาของตัวเอง (พื้นผิว API สัญญา event หรือ schema) ที่ผู้ใช้หลายรายพึ่งพา เมื่อพื้นที่หนึ่งถูกบันทึกว่าเป็นพื้นที่หลักแล้ว docs/ ของฟีเจอร์นั้น SHOULD มีอยู่ และรายการที่สำคัญที่สุดของมัน SHOULD ถูกลิงก์จากโมดูลที่มันครอบคลุมและจากดัชนี AGENTS.md ที่ราก เหมือนกับเอกสารต่อโมดูลทุกประการ พื้นที่ที่จงใจปล่อยไว้ไม่มีเอกสารต้องพกเหตุผลที่บันทึกไว้ — เป็นการตัดสินใจ ไม่ใช่การมองข้าม

README ของแผน

ทุกแผน MUST มี README.md ที่ประกอบด้วย

• ชื่อเรื่อง — # Deep Work Plan: <name>
• เป้าหมาย — คำบอกกล่าวแบบร้อยแก้วถึงวัตถุประสงค์ของแผน
• วัสดุต้นทาง — ลิงก์หรือพาธไปยังอินพุตมาตรฐาน (เป็นทางเลือก)
• งาน — ตาราง markdown ที่มีหมายเลขงาน ชื่อ และช่องทำเครื่องหมายสถานะ
• สถานะ — บรรทัดในรูปแบบ <n>/<total> tasks complete

ไฟล์งาน

ไฟล์งานแต่ละไฟล์ MUST ตั้งชื่อว่า <n>.task_<slug>.md และมีโครงสร้างสิบส่วน — ส่วนคลาสสิกเก้าส่วนบวก พื้นผิวที่แตะต้อง (Touched Surface): สัญญาระหว่างสิ่งที่งานเปลี่ยนกับสิ่งที่ต้องตรวจสอบ (พื้นผิวที่วางแผนเทียบกับพื้นผิวจริง ผู้ใช้ที่ได้รับผลกระทบ ระดับความเสี่ยงหนึ่งใน isolated, seam, shared/core หรือ unknown การแมปการทดสอบที่ใช้ และ gate ที่เลือกพร้อมเหตุผล)

PROGRESS.md

PROGRESS.md คือ log การทำงานแบบเพิ่มได้อย่างเดียว แต่ละรายการ MUST บันทึก

• timestamp แบบ ISO 8601
• หมายเลขและชื่องาน
• สิ่งที่ทำไป
• การเบี่ยงเบนหรือเหตุผลในการข้ามใด ๆ

เครื่องหมายสถานะ

• [ ] — ยังไม่เริ่ม
• [~] — กำลังทำ
• [x] — เสร็จ
• [!] — ติดขัด

หัวข้อ

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

Final Review การตัดสินใจเรื่อง skill ภายในงาน และรายงานแบบเลือกได้

ทุกแผนที่เขียนขึ้นภายใต้เวอร์ชันนี้ MUST จบด้วยงานที่บังคับเพียงหนึ่งเดียวพอดี: Final Review — การตรวจความปลอดภัยบนชุดการเปลี่ยนแปลงทั้งหมดของแผน การตรวจสอบครบวงจรบนสถานะสุดท้ายที่เกี่ยวข้องลำดับสุดท้าย และการกระทบยอดการตัดสินใจเรื่อง skill สิ่งที่พบด้านความปลอดภัยในระดับวิกฤตปิดกั้นการเสร็จสิ้น

• การตัดสินใจเรื่อง skill ภายในงาน การเสร็จสิ้นและ Log ของทุกงานมี การจัดการผลลัพธ์ skill (skills disposition) — none การอัปเดต skill หรือ agent ที่มีอยู่ การสร้างที่มีชื่อ หรือการเลื่อนออกไปพร้อมเหตุผลและเจ้าของ การเขียนขึ้นที่สมควรเกิดขึ้นภายในงานที่เป็นเจ้าของ ก่อน validation gate ของมัน หลังตรวจสอบความซ้ำซ้อนกับแคตตาล็อก .agents/; รายการที่สมควรถูกบันทึกเป็นผู้สมัครที่เสถียร (T{task}-{seq}) ในบัญชีผู้สมัคร skill ของแผน
• รายงานสรุปสำหรับผู้บริหารเป็นแบบเลือกได้ เมื่อมีคำขอ เสนอครั้งเดียว ณ การเสร็จสิ้น; สร้างเฉพาะเมื่อมีคำขออย่างชัดเจนจากหลักฐานที่ถาวร การไม่ตอบหรือการรันแบบไม่มีผู้ดูแลทิ้งแผนไว้เสร็จสิ้นโดยไม่มีรายงาน
• แผน legacy แผนที่เขียนขึ้นภายใต้เวอร์ชันก่อนหน้าจบด้วยสามงานสุดท้ายที่บังคับและยังคงสอดคล้อง — ตัวตรวจสอบความสอดคล้อง MUST ยอมรับรูปแบบนั้น