Skip to content
Deep Work Plan เปิดตัวบน Product Hunt วันนี้ โหวตเลย
← เอกสารข้อกำหนดทั้งหมด

ความสอดคล้อง

เวอร์ชัน 1.3 สถานะ: เสถียร เอกสารนี้นิยามว่าการที่ repository สอดคล้องกับ Deep Work Plan หมายถึงอะไร — นั่นคือ เป็น AI-first และเอเจนต์ขับเคลื่อนได้ คำสำคัญ MUST, MUST NOT, SHOULD, SHOULD NOT และ MAY ให้ตีความตามที่อธิบายไว้ใน RFC 2119

ความสอดคล้องมีอยู่เพื่อให้ “AI-first” เป็นคุณสมบัติที่เป็นวัตถุวิสัยและตรวจสอบได้ แทนที่จะเป็นความรู้สึก repository หนึ่งเป็นไปตามเกณฑ์ด้านล่างหรือไม่ก็ตาม sub-skill verify (/dwp-verify) ตรวจสอบเกณฑ์เหล่านี้โดยอัตโนมัติ

repository ที่สอดคล้อง

repository ที่สอดคล้องกับ DWP MUST เป็นไปตามทุกข้อต่อไปนี้ สิ่งประดิษฐ์ทุกอย่าง MUST ผ่านการให้เหตุผลสำหรับ repository — ปรับให้เข้ากับภาษา เฟรมเวิร์ก และคำสั่งจริงของมัน สตับทั่วไป เพลซโฮลเดอร์ หรือเนื้อหาที่คัดลอกมาจาก repository อื่นไม่เป็นไปตามเกณฑ์

  1. AGENTS.md ที่ราก repository MUST มี AGENTS.md ที่รากซึ่งประกอบด้วย (ก) ดัชนีของเอกสาร (ข) กฎที่บังคับสำหรับ repository และ (ค) บล็อก Quick Commands ที่คำสั่ง มีอยู่จริงและรันได้ ใน repository นี้ คำสั่งเพลซโฮลเดอร์ (เช่น npm test ใน repository ที่ไม่ใช้ npm) MUST NOT ปรากฏ ดัชนี MUST NOT ลิงก์ไปยังไฟล์ docs/ ที่ไม่มีอยู่จริง และไฟล์ SHOULD อยู่ภายในงบประมาณ 150–500 บรรทัด โดยย้ายรายละเอียดไปยัง docs/ และลิงก์ไปยังมันแทนการเติบโตอย่างไม่มีขอบเขต
  2. CLAUDE.md แปลงไปยัง AGENTS.md CLAUDE.md MUST มีอยู่และแปลงไปยัง AGENTS.md (symlink หรือสิ่งเทียบเท่าที่รับประกันแหล่งความจริงเดียว) ทั้งสอง MUST NOT แตกต่างกัน
  3. ลำดับชั้น docs/ repository MUST มีไดเรกทอรี docs/ ที่ครอบคลุมหมวดมาตรฐาน (สถาปัตยกรรม มาตรฐาน การทดสอบ คำสั่งสำหรับการพัฒนา ความปลอดภัย และการออนบอร์ดเอเจนต์) ด้วยเนื้อหาจริงที่เฉพาะกับ repository โมดูลที่ซับซ้อน SHOULD มี README.md ของตัวเอง คู่มือการทดสอบ MUST นิยาม toolchain การทดสอบ, lint และ type-check ที่มีอยู่จริง — หรือสำหรับ repository ที่ไม่มีเลย ก็เป็นการตั้งค่าที่เป็นรูปธรรมซึ่ง ถูกเสนอ จากสแตกระหว่างการออนบอร์ด คู่มือการทดสอบที่ว่างเปล่าหรือ “ไม่มีการทดสอบ” ไม่เป็นไปตามเกณฑ์นี้ เพราะหากไม่มีวิธีที่นิยามไว้สำหรับตรวจสอบพฤติกรรม แผนก็ไม่มี validation gate ที่เป็นวัตถุวิสัย
  4. บ้าน .agents/ repository MUST มีไดเรกทอรี .agents/ พร้อม agents/, commands/ และ skills/ รวมถึงแคตตาล็อกภายใต้ .agents/docs/ ที่ ตรงกับสิ่งที่อยู่บนดิสก์ คำสั่ง dwp-* MUST เป็นตัวส่งต่อบาง ๆ ไปยัง skill ที่ติดตั้งไว้ พาธ .claude MUST แปลงไปยัง .agents
  5. พื้นที่ทำงาน .dwp/ ที่ถูก gitignore repository MUST มีไดเรกทอรี .dwp/ พร้อม plans/ และ .dwp/ MUST ถูก gitignore พื้นที่ scratch tmp/ SHOULD มีอยู่และ SHOULD ถูก gitignore
  6. skill ของระเบียบวิธีแปลงได้ skill ของ Deep Work Plan MUST ถูกติดตั้งหรืออ้างอิงในลักษณะที่เอเจนต์ใน repository สามารถเรียกใช้ sub-skill ของมันได้

repository สอดคล้องอย่างสมบูรณ์โดยไม่มี addon แบบเลือกใช้ใด ๆ addon แบบเลือกใช้ (devcontainer, Dailybot, dependency-upgrade, design-system) MUST NOT จำเป็นต่อความสอดคล้อง ตั้งแต่มาตรฐาน 2.3.0 การตรวจสอบในเครื่องของ AI Diff Reviewer (vendored skill + ไฟล์ส่วนขยาย) เป็นส่วนหนึ่งของพื้นฐาน: การไม่มีมันเป็นความล้มเหลวสำหรับ repository ที่ประกาศ 2.3.0 หรือใหม่กว่า และเป็นข้อค้นพบเวอร์ชัน harness สำหรับ repository แบบ legacy พื้นผิว CI ของมันยังคงเป็นแบบเลือกใช้

แผนที่มีรูปแบบที่ถูกต้อง

Deep Work Plan ใน .dwp/plans/ มีรูปแบบที่ถูกต้องเมื่อ

  1. ทุกงาน MUST ประกาศ ขอบเขต, เกณฑ์การยอมรับ และ validation gate อย่างน้อยหนึ่งอย่าง (คำสั่งหรือการตรวจสอบที่ผ่านหรือไม่ผ่านอย่างเป็นวัตถุวิสัย) ที่ชัดเจน
  2. ทุกงานที่เพิ่มฟังก์ชันหลักใหม่หรือเปลี่ยนพฤติกรรมของผลิตภัณฑ์ MUST รวมความครอบคลุมของการทดสอบอัตโนมัติสำหรับพฤติกรรมนั้นไว้ในเกณฑ์การยอมรับของมัน และ MUST รันการทดสอบของ repository ร่วมกับการตรวจ lint และ type-check ใน validation gate ของมัน — ไม่ใช่เพียง build เท่านั้น การทดสอบที่มีอยู่ MUST ยังคงผ่าน การเปลี่ยนพฤติกรรม MUST อัปเดตการทดสอบที่มันทำให้ล้มเหลวแทนที่จะลบหรือข้ามมัน งานที่เป็นเอกสารล้วน การกำหนดค่า หรือการวิจัยได้รับการยกเว้นจากการสร้างการทดสอบ แต่ยังคงต้องรัน gate ของ repository
  3. ทุกงานที่แตะการยืนยันตัวตน การจัดการอินพุต ความลับหรือการกำหนดค่า พื้นผิวเครือข่าย หรือ dependency MUST ระบุความคาดหวังด้านความปลอดภัยของการเปลี่ยนแปลงนั้นไว้ในเกณฑ์การยอมรับของมัน และทุก commit MUST ปลอดจากเนื้อหาที่เป็นความลับ
  4. แผน MUST บันทึกความคืบหน้าเพื่อให้งานรอดพ้นการขัดจังหวะและดำเนินต่อได้โดยเอเจนต์ตัวอื่น งาน MUST NOT ถูกบันทึกว่า completed ขณะที่บันทึก validation-gate ใดของมันยังแสดงการรันที่ล้มเหลวและยังไม่ได้แก้ไข และ log การเสร็จสิ้นของงานเองต้อง MUST NOT ขัดแย้งกับสถานะที่บันทึกไว้ (เช่น งานที่ completed แต่ log ของมันยังคงอ่านว่า “Status: pending” คือข้อบกพร่อง ไม่ใช่การผ่าน)
  5. แผน MUST ปิดลงด้วยการทบทวนสุดท้ายที่ถูกบันทึกไว้ของมัน แผนที่เขียนขึ้นภายใต้เวอร์ชันนี้ MUST จบด้วย Final Review ที่บังคับเพียงหนึ่งเดียวพอดี — การตรวจความปลอดภัย การตรวจสอบครบวงจรบนสถานะสุดท้าย และการกระทบยอดเรื่อง skill แผนที่เขียนขึ้นภายใต้เวอร์ชันก่อนหน้าจบด้วยสามงานสุดท้ายที่บังคับ (การทบทวนความปลอดภัย การค้นพบ Skills และ Agents และรายงานสรุปสำหรับผู้บริหาร) และยังคงสอดคล้อง สิ่งที่พบด้านความปลอดภัยในระดับวิกฤตจะปิดกั้นการเสร็จสิ้นจนกว่าจะได้รับการแก้ไขหรือถูกยอมรับอย่างชัดแจ้ง การเสร็จสิ้นเองคือธุรกรรมที่ผ่านการยืนยันและกู้คืนได้ ไม่ใช่แค่การพลิกสถานะ: งานปิดท้ายปิดผ่านขั้นตอนการเผยแพร่ที่มีการป้องกัน ซึ่งตรวจสอบสิ่งประดิษฐ์ของแผนที่เสร็จสมบูรณ์แล้วก่อนเขียนสถานะ และทิ้งใบเสร็จ FINALIZATION.json ที่เครื่องตรวจสอบได้ไว้; การเผยแพร่ที่ถูกขัดจังหวะจะถูกกู้คืนจากหลักฐาน ไม่เคยถูกประกาศว่าเสร็จสมบูรณ์ซ้ำอย่างเงียบ ๆ ตัวชี้หลักฐานใด ๆ ที่บันทึก gate อ้างถึง MUST คลี่คลายอยู่ภายในโฟลเดอร์ของแผนเอง — ตัวชี้ที่ค้างหรือหลุดขอบเขตคือข้อค้นพบ ไม่ใช่หลักฐานที่ผ่าน
  6. งาน SHOULD ยึดโยงกลับไปยังเป้าหมายของแผนก่อนดำเนินการ เพื่อป้องกันการเบี่ยงเบนตลอดช่วงเวลายาวนาน

การตรวจสอบความสอดคล้อง

ความสอดคล้อง SHOULD ถูกตรวจสอบโดยอัตโนมัติแทนที่จะตรวจด้วยสายตา การรัน /dwp-verify ให้รายงานผ่าน/ไม่ผ่านเทียบกับเกณฑ์ด้านบน ได้แก่ การมีอยู่และเนื้อหาจริงของ AGENTS.md การแปลงของ CLAUDE.md หมวด docs/ การตรงกันของแคตตาล็อก .agents/ เทียบกับดิสก์ สถานะ gitignore ของ .dwp/ และ tmp/ และ — สำหรับแผน — ว่าทุกงานมีเกณฑ์การยอมรับและ validation gate พร้อมความครอบคลุมของการทดสอบสำหรับงานที่เปลี่ยนพฤติกรรม และการทบทวนสุดท้ายที่ถูกบันทึกไว้มีอยู่ สำหรับแผน มันยังตรวจสอบด้วยว่า markdown ของแผนกับสถานะที่เครื่องอ่านได้ของมันตรงกัน (README กับ state.json ที่ไม่ตรงกันคือข้อค้นพบ ไม่เคยผ่านอย่างเงียบ ๆ) ว่างานที่เสร็จสมบูรณ์พกหลักฐาน gate และ log ที่ไม่ขัดแย้งกัน และ — เมื่อแผนที่เสร็จสมบูรณ์ไปถึงจุดนั้น — ว่ามีใบเสร็จการเผยแพร่หนุนหลังการเสร็จสิ้นที่มันอ้างไว้ ตัวตรวจสอบเป็น แบบรู้เวอร์ชัน: มัน MUST ยอมรับแผน legacy (สามงานสุดท้ายที่บังคับ ไม่มีพื้นผิวที่แตะต้อง) ว่าสอดคล้อง และ MUST ปฏิเสธแผนที่ประกาศเวอร์ชันนี้แต่เป็นโมฆะอย่างเป็นวัตถุวิสัยภายใต้มัน มันยังรายงานบรรทัดแหล่งที่มา DWP standard: ที่หายไปหรือล้าสมัยเป็นข้อค้นพบที่ระบุการอัปเกรด harness แบบเจาะจงที่เป็นเป้าหมาย ชั้นกลไกซื่อสัตย์ต่อข้อจำกัดของตัวเอง: โดยไม่มีอินเทอร์พรีเตอร์ที่มีความสามารถ (Python 3.9+) มันจบด้วยรหัสออกที่ไม่ใช่ศูนย์และคำตัดสิน UNVERIFIED ที่ชัดเจนแทนที่จะข้ามการตรวจของตัวเอง — ตัวตรวจสอบไม่เคยรายงานผลลัพธ์ที่ตัวเองไม่ได้ตรวจ

repository SHOULD ถูกตรวจสอบซ้ำหลังการออนบอร์ดและหลังแผนแต่ละแผนที่เสร็จสิ้น เพื่อให้ความสอดคล้องได้รับการดูแลรักษาแทนที่จะถูกยืนยันเพียงครั้งเดียว