ข้อกำหนด DWP

เวอร์ชัน 4.0.0. สถานะ: เสถียร เอกสารนี้คือข้อกำหนดเชิงบรรทัดฐานสำหรับระเบียบวิธี Deep Work Plan (DWP) คำสำคัญ MUST, MUST NOT, SHOULD, SHOULD NOT และ MAY ให้ตีความตามที่อธิบายไว้ใน RFC 2119

เพิ่มเติมใน 2.4.0 ไม่มีการเปลี่ยนแปลงที่ทำลายความเข้ากันได้ (1) ส่วนพื้นผิวที่แตะต้อง (Touched Surface) — สัญญาระหว่างสิ่งที่งานเปลี่ยนกับสิ่งที่ต้องตรวจสอบ พร้อมการเลือก gate ตามระดับความเสี่ยง (isolated / seam / shared-core / unknown); (2) การตรวจสอบครบวงจรกลายเป็นข้อกำหนดสถานะสุดท้ายที่รันใน Final Review เดี่ยวที่บังคับของแผน พร้อมกฎการใช้หลักฐานซ้ำอย่างชัดเจน; (3) การตัดสินใจเรื่อง skill ภายในงานย้ายเข้าไปอยู่ในงานที่เป็นเจ้าของ และรายงานสรุปสำหรับผู้บริหารกลายเป็นแบบเลือกได้ เมื่อมีคำขอ; (4) โฟลว์ create แบบรู้โหมด — โหมด trust สร้างแผนขึ้นโดยตรงโดยยังคงการวิเคราะห์และการตรวจสอบคุณภาพ; (5) การสร้างแผนแบบ Lite-first — โฟลว์ create แบบมีการแนะนำผลิตแผน Lite ที่ดำเนินการได้โดยตรงแทนร่างที่ดำเนินการไม่ได้ และสามารถเลื่อนขั้นเป็นแผน Full ได้ทุกเมื่อ (ดู แผน Lite); และ (6) เมทริกซ์ความเข้ากันได้ที่ชัดเจน: แผนและ repository จากเวอร์ชันก่อนหน้ายังคงสอดคล้อง

มาตรฐาน 4.0.0 การกระโดดของเวอร์ชันจัดหมายเลขมาตรฐานให้เข้ากับสายผลิตภัณฑ์ — 2.x เป็นประวัติศาสตร์และไม่มีมาตรฐาน 3.x — และไม่เปลี่ยนข้อกำหนดใดจาก 2.4.0 แผนและรีโพสิทอรีจากเวอร์ชันก่อนยังคงสอดคล้อง

นิยาม

Deep Work Plan คือสิ่งประดิษฐ์แบบ markdown ล้วนที่มีโครงสร้าง ซึ่งอธิบายงานวิศวกรรมที่ซับซ้อนโดยแยกย่อยเป็นหน่วยงานตามลำดับและทบทวนได้ ออกแบบมาเพื่อให้เอเจนต์เขียนโค้ด AI ที่ทำงานอย่างอิสระสร้าง ดำเนินการ และดูแลรักษา

DWP ขับเคลื่อนด้วยข้อกำหนด แผนคือข้อกำหนด และเอเจนต์ MUST ดำเนินการเทียบกับเกณฑ์การยอมรับและ validation gate ที่ชัดเจนของมันแทนที่จะด้นสด ข้อกำหนด — ไม่ใช่บทสนทนาแชต — คือแหล่งความจริงที่ยั่งยืน งานจึงตรวจสอบได้และดำเนินต่อได้ข้ามเซสชันและข้ามเอเจนต์ มันยังเป็น harness engineering ที่ทำให้พกพาได้ บริบท control loop guardrail และสถานะที่ดำเนินต่อได้ซึ่งทำให้เอเจนต์เชื่อถือได้ถูกติดตั้งลงใน repository เองในรูปของ markdown ธรรมดา เอเจนต์ที่สอดคล้องตัวใดก็ MAY ขับเคลื่อน repository ได้โดยไม่ต้องมีเฟรมเวิร์กเฉพาะเครื่องมือ

โฟลว์ create — ขั้นตอนเดียว รู้โหมด

โฟลว์ create เก็บรวบรวมวัตถุประสงค์ บริบท ข้อจำกัด และโครงร่างงานหนึ่งครั้ง ทำการวิเคราะห์ความต้องการ (ขอบเขต การเรียงลำดับส่วนพึ่งพิงระหว่างงาน การเลือก validation จากพื้นผิวที่แตะต้อง ระดับความเข้มงวดตามสัดส่วน) แล้วจึงสร้างขึ้นจริงตามโหมดที่นักพัฒนาเลือก:

• โหมดแบบมีการแนะนำ (ค่าเริ่มต้น) โฟลว์สร้างแผน Lite ขึ้นโดยตรง — ข้อเสนอที่กระชับและดำเนินการได้อยู่แล้ว พร้อมบันทึกงานแบบ inline {#task-N} ทบทวนได้ในรอบเดียว — แล้วถามนักพัฒนาว่าจะคงไว้เป็น Lite เลื่อนขั้นเป็นแผน Full ขอให้แก้ไข หรือหยุด ไม่มีการผลิตร่างระหว่างกลางที่ดำเนินการไม่ได้อีกต่อไป
• โหมด trust (trust / auto) โฟลว์สร้างรูปแบบที่เลือกไว้ขึ้นโดยตรง (Lite หรือ Lite ตามด้วยการเลื่อนขั้นเป็น Full ทันที) โดยไม่มีขั้นตอนทบทวน — นักพัฒนาสละสิทธิ์นั้น การวิเคราะห์ความต้องการ การเรียงลำดับส่วนพึ่งพิง และการตรวจสอบคุณภาพแผนยังคงรัน: trust สละสิทธิ์การทบทวน ไม่ใช่การวิเคราะห์ แผนโหมด trust ถูกบันทึกว่าได้รับอนุมัติล่วงหน้าสำหรับการดำเนินงานแบบไม่มีผู้ดูแล

ทั้งสองโหมดตัดสินใจรูปแบบของแผน (Lite หรือ Full) โดยเป็นส่วนหนึ่งของการวิเคราะห์ความต้องการเดียวกัน ไม่เคยเป็นเรื่องที่คิดทีหลัง ดูรูปแบบเต็ม การสร้างและการเลือก และวงจรชีวิตการเลื่อนขั้นได้ที่ แผน Lite

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

แผน MUST เป็นไดเรกทอรีภายใต้ .dwp/plans/ ที่ตั้งชื่อว่า PLAN_<slug>/ โดยอยู่ในหนึ่งในสองรูปแบบต่อไปนี้:

• Full ไดเรกทอรี MUST ประกอบด้วย README.md (ภาพรวมแผน เป้าหมาย ตารางงาน และสถานะ) หนึ่งไฟล์ต่อหนึ่งงานตั้งชื่อว่า <n>.task_<slug>.md และ PROGRESS.md (log การทำงานที่บันทึกต่อเนื่อง)
• Lite บันทึกงานที่กระชับและดำเนินการได้เต็มรูปแบบอยู่แบบ inline ใน README.md หลัง anchor ที่เสถียรอย่าง {#task-N} แทนที่จะเป็นไฟล์งานแยกต่างหาก — แต่ละบันทึกยังคงพกเป้าหมาย พื้นผิวที่แตะต้อง เกณฑ์การยอมรับ การตรวจสอบ และ log การเสร็จสิ้น PROGRESS.md ยังคง REQUIRED แผน Lite MAY ถูกเลื่อนขั้นเป็น Full ได้ทุกเมื่อ ดูวงจรชีวิตแบบเต็มได้ที่ แผน Lite แทนที่จะกล่าวซ้ำที่นี่

แผน MAY พกชั้นสถานะที่เครื่องอ่านได้เพิ่มเติม: manifest.json (เอกลักษณ์คงที่ เขียนหนึ่งครั้งตอน materialization) และ state.json (สถานะการดำเนินงานต่อหนึ่งงานแบบสด) ชั้นสถานะ RECOMMENDED สำหรับแผนใหม่และ REQUIRED สำหรับการดำเนินงานแบบไม่มีผู้ดูแลและสำหรับ agent workspace ที่ไม่มี git ดู สถานะแผน

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

ไฟล์งาน

1. 01 Title
2. 02 Context
3. 03 Read Before Starting
4. 04 Goal
5. 05 Touched Surface
6. 06 Instructions
7. 07 Acceptance Criteria
8. 08 Outputs
9. 09 Validation
10. 10 Execution Checklist + Completion & Log

ไฟล์งานแต่ละไฟล์ MUST มีสิบส่วนนี้ตามลำดับ

1. เป้าหมาย — คำบอกกล่าวหนึ่งย่อหน้าว่างานนี้บรรลุอะไร
2. บริบท — ภูมิหลัง ลิงก์ และเหตุผลที่งานนี้มีอยู่
3. พื้นผิวที่แตะต้อง (Touched Surface) — สัญญาระหว่างสิ่งที่งานเปลี่ยนกับสิ่งที่ต้องตรวจสอบ
4. ขั้นตอน — การกระทำที่เป็นรูปธรรมและเรียงลำดับซึ่งต้องทำ
5. เกณฑ์การยอมรับ — เช็กลิสต์ของเงื่อนไขที่นิยามว่าเสร็จ
6. การตรวจสอบ — คำสั่งหรือการทดสอบที่ต้องรันเพื่อยืนยัน เลือกจากพื้นผิวที่แตะต้อง
7. ไฟล์ — พาธที่คาดว่าจะถูกสร้างหรือแก้ไข
8. ส่วนพึ่งพิง — งานอื่นหรือเงื่อนไขเบื้องต้นภายนอก
9. ความเสี่ยง — สิ่งที่อาจผิดพลาดและการบรรเทา
10. การเสร็จสิ้นและ Log — เครื่องหมายสถานะพร้อมบันทึกตามลำดับเวลา

งาน MAY รวมส่วน Delta เพิ่มเติม (RECOMMENDED สำหรับการเปลี่ยนแปลงพฤติกรรม brownfield — ดูด้านล่าง) และส่วน Rollback (RECOMMENDED สำหรับการย้ายข้อมูล การเปลี่ยนแปลงโครงสร้างพื้นฐาน หรือการ deploy)

พื้นผิวที่แตะต้อง (Touched Surface)

พื้นผิวที่แตะต้องคือสัญญาระหว่างสิ่งที่งานเปลี่ยนกับสิ่งที่ต้องตรวจสอบ มันมีอยู่เพื่อให้การตรวจสอบถูกเลือกตามผลกระทบ ไม่ใช่ตามความเคยชิน และเพื่อให้ผู้อ่านในภายหลังเห็นได้ว่าทำไมจึงเลือก gate นั้น งานที่เปลี่ยนพฤติกรรม MUST บันทึก

• พื้นผิวที่วางแผน — พาธ โมดูล แพ็กเกจ หรือการกำหนดค่าที่งานตั้งใจจะเปลี่ยน เขียนไว้ก่อนลงมือแก้ไข
• พื้นผิวจริง — รายการที่กระทบยอดแล้วหลังการแก้ไข ซึ่งมาจาก diff จริง เอเจนต์ MUST กระทบยอดพื้นผิวที่วางแผนกับพื้นผิวจริงก่อนเลือก gate
• ผู้ใช้ที่ได้รับผลกระทบ — โมดูล แพ็กเกจ หรือบริการที่พึ่งพิงพื้นผิวจริง เท่าที่การแมปที่จัดทำเป็นเอกสารของ repository จะระบุได้ ในกรณีที่ระบุไม่ได้ รายการนั้น MUST บอกไว้เช่นนั้น
• ระดับความเสี่ยง — หนึ่งใน: isolated (จำกัดอยู่ในโมดูลเดียวและการทดสอบของมัน); seam (เปลี่ยนสัญญา การคงข้อมูล การกำหนดเส้นทาง การ serialize การยืนยันตัวตน หรือการต่อสายของเฟรมเวิร์กระหว่างผู้ร่วมงาน); shared/core (ถูก import อย่างกว้างขวาง หรือเป็นการเปลี่ยน dependency, migration, การกำหนดค่า build/test, schema หรือ toolchain); unknown (การแมปหายไป ล้าสมัย หรือยังไม่ได้ตรวจสอบ)
• การแมปการทดสอบที่ใช้ — การแมปที่จัดทำเป็นเอกสารหรือเครื่องมือใดที่ทำให้เลือกเช่นนั้น
• gate ที่เลือกและเหตุผล — คำสั่งที่แน่ชัดและเหตุผลว่าทำไมมันจึงครอบคลุมพื้นผิวจริง

ไฟล์การกำหนดค่า schema ไฟล์รายการ dependency เทมเพลต fixtures migration และไฟล์คำสั่งของเอเจนต์ เปลี่ยนพฤติกรรมได้ และ MUST ถูกจัดระดับตามผลกระทบของมัน ไม่ใช่ตามนามสกุลไฟล์ งานที่เปลี่ยนเฉพาะร้อยแก้ว คอมเมนต์ หรือสิ่งประดิษฐ์จากการวิจัย MAY ประกาศว่าพื้นผิวไม่มีผลบังคับ และยังคงรันการตรวจที่ไม่ใช่ runtime ของ repository

ส่วน Delta (การเปลี่ยนแปลง brownfield)

งานจริงส่วนใหญ่แก้ไขพฤติกรรมที่มีอยู่แทนที่จะสร้างพฤติกรรมใหม่ งานที่เปลี่ยนวิธีทำงานของระบบที่มีอยู่ SHOULD พกส่วน Delta ที่อธิบายการเปลี่ยนแปลงเป็นสัญญาก่อน/หลังที่ชัดเจน โดยใช้หัวข้อรายการสาม:

• ADDED — พฤติกรรมที่มีหลังงานและไม่มีก่อนหน้านี้
• MODIFIED — พฤติกรรมที่มีทั้งสอง ระบุเป็น was: … → now: …
• REMOVED — พฤติกรรมที่มีก่อนหน้าและหายไปอย่างตั้งใจหลังจากนั้น

แต่ละรายการ MUST เป็นพฤติกรรมที่สังเกตได้ — การตอบสนองของ endpoint flag ของ CLI สถานะ UI ค่าเริ่มต้น — ไม่ใช่รายละเอียดการ implement ส่วน Delta คือ diff ของผู้ตรวจสอบในระดับพฤติกรรม: เกณฑ์การยอมรับยืนยันรายการ ADDED/MODIFIED และรายการ REMOVED คือใบอนุญาตชัดเจนในการลบ สิ่งใดที่ไม่ได้ระบุว่า REMOVED MUST ยังคงทำงาน

Validation gate — เลือกตามระดับความเสี่ยง

การตรวจสอบคือ gate ที่เปลี่ยนการกล่าวอ้างว่าเสร็จให้กลายเป็นหลักฐานว่าเสร็จ งาน MUST NOT ถูกทำเครื่องหมายว่าเสร็จจนกว่าทุกคำสั่งในส่วนการตรวจสอบของมันจะรันและผ่านแล้ว gate ของงานที่เปลี่ยนพฤติกรรมถูกเลือกจากพื้นผิวที่แตะต้องซึ่งกระทบยอดแล้ว ตามระดับความเสี่ยง

การเปลี่ยนพฤติกรรม MUST ทำให้ได้การเลือกการทดสอบที่ไม่ว่างเปล่าและเกี่ยวข้อง — selector ที่ไม่ถูกต้องหรือ runner ที่เลือกการทดสอบได้ศูนย์รายการไม่ใช่ความครอบคลุม ในกรณีที่แผนที่การทดสอบของ repository ล้าสมัย ให้อนุมานการเรียกใช้ที่ถูกต้องและบันทึกการอัปเดตการแมปนั้นไว้ คำสั่งเล็ก ๆ ที่ขาดหายไปไม่เคยจำเป็นต้องรันการออนบอร์ดใหม่ทั้งหมด ในกรณีที่ไม่มีการเรียกใช้แบบจำกัดขอบเขตอยู่เลย ให้ใช้ชุดการทดสอบที่ใช้ได้ทั้งหมด — เป็นพฤติกรรม legacy ไม่ใช่ข้อผิดพลาด

เมื่องานเพิ่มฟังก์ชันหลักใหม่หรือเปลี่ยนพฤติกรรมที่มีอยู่อย่างมีนัยสำคัญ เกณฑ์การยอมรับของมัน MUST รวมความครอบคลุมของการทดสอบอัตโนมัติสำหรับพฤติกรรมที่ใหม่หรือเปลี่ยนไป และการตรวจสอบของมันรันการทดสอบของ repository ร่วมกับการตรวจ lint, type-check และ format — ไม่ใช่เพียง build เท่านั้น การทดสอบที่มีอยู่ MUST ยังคงผ่าน

การตรวจสอบครบวงจรบนสถานะสุดท้าย

gate ต่อหนึ่งงานตรวจสอบสิ่งที่แต่ละงานแตะต้อง มันไม่ได้แทนที่การตรวจสอบแผนทั้งแผน ก่อนที่แผนจะเสร็จสิ้น การตรวจสอบที่ใช้ได้ทั้งหมดของ repository MUST รันและผ่านบนสถานะที่เกี่ยวข้องลำดับสุดท้าย หลังการเปลี่ยนแปลงเชิงสาระครั้งสุดท้าย — ภายใน Final Review การรันที่กว้างกว่าในช่วงก่อนหน้าเกิดขึ้นที่ขอบเขตการ integrate หรือหลังการเปลี่ยนแปลงแบบ shared/core ไม่ใช่ตามตารางนับจำนวนงาน ผลลัพธ์ที่ผ่านแล้ว MAY ถูกใช้ซ้ำได้ก็ต่อเมื่อมีหลักฐานว่า input ที่เกี่ยวข้องเทียบเท่ากัน มิฉะนั้นให้รันใหม่ การรัน gate แต่ละครั้งทิ้งบันทึกที่กระชับไว้: คำสั่ง ขอบเขต revision ผลลัพธ์ และพาธของหลักฐาน

วินัยด้านความปลอดภัย

ความปลอดภัยเป็นเรื่องสำคัญลำดับแรกเช่นเดียวกับการทดสอบ และเป็นไปตามโมเดลสองชั้นเดียวกัน: วินัยต่อหนึ่งงานขณะที่งานกำลังดำเนินอยู่ บวกกับการตรวจความปลอดภัยของ Final Review ที่ครอบคลุมชุดการเปลี่ยนแปลงทั้งหมดในตอนท้าย เมื่อใดก็ตามที่งานแตะต้องการพิสูจน์ตัวตนหรือการให้สิทธิ์ การจัดการ input, secrets หรือการกำหนดค่า, พื้นผิวเครือข่าย ไฟล์ หรือ shell, หรือ dependencies:

• เกณฑ์การยอมรับ ของมัน MUST ระบุความคาดหวังด้านความปลอดภัยของการเปลี่ยนแปลงนั้น — input ถูก validate และ escape, ไม่มีสาระความลับในโค้ดหรือ fixtures, การตรวจสอบ auth ถูกรักษาไว้หรือเสริมให้แข็งแกร่งขึ้น — สอดคล้องกับ docs/SECURITY.md
• ทุก commit MUST ได้รับการยืนยันว่าปราศจาก secrets หรือ credentials ก่อนที่มันจะ land รวมถึง test fixtures และตัวอย่างในเอกสารด้วย secret ใน commit ที่ push ไปแล้ว MUST ถูกถือว่ารั่วไหลและต้อง rotate ไม่ใช่เพียงลบออก
• ในกรณีที่งานที่อ่อนไหวด้านความปลอดภัยมีสาระสำคัญ งาน hardening เฉพาะ SHOULD ถูกวางไว้ทันทีหลังงาน implementation และก่อนงาน comprehensive-tests เพื่อให้ข้อค้นพบถูกแก้ไขก่อนที่การทดสอบจะเข้ารหัสพฤติกรรมนั้น และข้อค้นพบแต่ละอย่างกลายเป็นกรณี regression แทนที่จะเป็นการทำงานซ้ำ

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

วงจรชีวิตของแผน — Final Review

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

Final Review MUST ทำตามลำดับนี้

(ก) การตรวจความปลอดภัย — ทบทวนชุดการเปลี่ยนแปลงสะสมทั้งหมดของแผนเพื่อหา secret ที่ hardcode ไว้ ความเสี่ยงจาก injection พื้นผิวการโจมตีใหม่ การยืนยันตัวตนที่อ่อนแอลง และข้อมูลอ่อนไหวใน log หรือเอกสาร ตรวจสอบ dependency ที่ถูกเพิ่มเข้ามา ยืนยันว่า docs/SECURITY.md ยังคงสะท้อนความเป็นจริง และเขียนรายงานการทบทวนความปลอดภัยแม้เมื่อไม่พบสิ่งใด ข้อค้นพบระดับวิกฤตถูกแก้ไข — หรือได้รับการยอมรับอย่างชัดเจนจากผู้ใช้ — ก่อนที่แผนจะเสร็จสิ้น

(ข) การตรวจสอบครบวงจรบนสถานะสุดท้าย — การตรวจสอบที่ใช้ได้ทั้งหมดของ repository รันและผ่านบนสถานะที่เกี่ยวข้องลำดับสุดท้าย

(ค) การกระทบยอดเรื่อง skill — ทุกงานพกการจัดการผลลัพธ์ skill มาด้วย และผู้สมัครที่ถูกบันทึกไว้ทุกรายมีการจัดการแล้ว ไม่มีรายงานการค้นพบรอบที่สอง

(ง) การเสร็จสิ้น — รายงานการเสร็จสิ้นพร้อมสิ่งที่ส่งมอบ หลักฐานการตรวจสอบ และข้อจำกัด เสนอรายงานสรุปสำหรับผู้บริหารหนึ่งครั้ง แผนเสร็จสิ้นไม่ว่าข้อเสนอนั้นจะได้รับคำตอบหรือไม่

Final Review รันตามลำดับหลังงานอื่นทั้งหมด และไม่เคยถูกวางไว้ในกลุ่มแบบขนาน

การตัดสินใจเรื่อง skill ภายในงาน

คำถามที่ว่า “งานนี้สร้างรูปแบบที่นำกลับมาใช้ใหม่ได้ซึ่งคุ้มค่ากับ skill หรือ agent หรือไม่” ถูกตอบภายในงานที่สร้างรูปแบบนั้นขึ้นมา ขณะที่หลักฐานของมันยังอยู่ในบริบท การเสร็จสิ้นและ Log ของทุกงานพกการจัดการผลลัพธ์ skill (skills disposition) มาด้วย: ไม่มี อัปเดต skill ที่มีอยู่ สร้างสิ่งประดิษฐ์ที่มีชื่อ หรือเลื่อนออกไปพร้อมเหตุผล การเขียนขึ้นที่สมควรเกิดขึ้นภายในงานนั้น ก่อน validation gate และ commit ของมัน หลังตรวจสอบแคตตาล็อกที่มีอยู่เพื่อหาความซ้ำซ้อน

รายงานสรุปสำหรับผู้บริหาร — แบบเลือกได้ เมื่อมีคำขอ

รายงานสรุปสำหรับผู้บริหารไม่ใช่งานบังคับอีกต่อไป ณ การเสร็จสิ้น เอเจนต์เสนอมันหนึ่งครั้ง มันถูกสร้างขึ้นเมื่อมีคำขออย่างชัดเจนเท่านั้น โดยอาศัยหลักฐานที่ถาวรและไม่ต้องเล่นแผนซ้ำ การไม่ตอบหรือการรันแบบไม่มีผู้ดูแลทิ้งแผนไว้ในสถานะเสร็จสิ้นโดยไม่มีรายงานถูกสร้างขึ้น

โปรโตคอลการเสร็จสิ้นงาน

หลังผ่านการตรวจสอบและก่อนก้าวไปงานถัดไป เอเจนต์ MUST ตามลำดับ: (1) ทำเครื่องหมายงานเป็น [x] ใน README ของแผน; (2) เพิ่มจำนวนสถานะแผน; (3) กรอกส่วนการเสร็จสิ้นและ Log ของงานโดยไม่มีค่า placeholder; (4) เพิ่มรายการ 3–5 bullet เข้า PROGRESS.md; (5) commit (ในกรณีที่แผน commit) ในรูปแบบ {type}({scope}): {description} — Task {N} of PLAN_{name}; (6) ในกรณีที่แผนพกชั้นสถานะ เขียน state.json ใหม่แบบ atomic — งาน completed บันทึก gate บันทึกผลลัพธ์ commit hash

หกขั้นตอนรวมเป็น transaction ตรรกะหนึ่งรายการ เอเจนต์ที่ถูกขัดจังหวะกลางโปรโตคอล MUST NOT เริ่มงานถัดไป — มันต้องเสร็จสิ้นหรือยกเลิกการเสร็จสิ้นบางส่วนก่อน

DWP Resume Protocol

Resume MUST เป็นไปได้จากไฟล์ของแผนบวก git log เท่านั้น โดยไม่มีสถานะภายนอก ใน workspace ที่ไม่มี git — ดู Archetype §3 — state.json ของแผน REQUIRED และทำหน้าที่แทน git log

เอเจนต์ที่กำลัง resume — เซสชันใหม่ เอเจนต์อื่น รอบ daemon ที่กำหนดเวลา หรือ cloud session ที่ตื่น — MUST ทำพิธีกรรมนี้ตามลำดับ:

1. Re-anchor อ่าน README ของแผน: เป้าหมาย แนวทางทั่วไป รายการงาน
2. ระบุ checkpoint หางานที่ยังไม่ได้ทำเครื่องหมายงานแรกใน README อ่าน git log และ git status (หรือ checkpoint ของ state.json ในกรณีที่ไม่มี git)
3. ปรับประสานสถานะ ในกรณีที่ state.json มีอยู่ เปรียบเทียบกับ checkbox ของ README เมื่อเบี่ยงเบน สร้าง state.json ใหม่จาก markdown ก่อนดำเนินการต่อ
4. ตรวจสอบรอยต่อ อ่านส่วนการเสร็จสิ้นและ Log ของงานจุด resume และรายการ PROGRESS.md ล่าสุด — พื้นฐานที่ยืนยันล่าสุดของเซสชันก่อนหน้า
5. Smoke-test รัน validation ราคาถูกที่สุดที่คงอยู่ของ repository เพื่อยืนยันว่าโลกยังทำงานอยู่ก่อนสร้างต่อจากมัน smoke test ที่ล้มเหลวถูกตรวจสอบก่อน ไม่ใช่สร้างต่อจากมัน
6. ดำเนินการแบบ atomic ดำเนินงานถัดไปเพียงงานเดียว อย่ารวมข้างหน้า

เอเจนต์ MUST เชื่อถือเครื่องหมาย [x] ที่เสร็จแล้ว และ MUST NOT ตรวจสอบงานที่เสร็จแล้วซ้ำ เว้นแต่ผู้ใช้ร้องขออย่างชัดเจน หรือ smoke test ล้มเหลวในลักษณะที่เกี่ยวข้องกับงานที่เสร็จแล้ว

ลูปดำเนินงาน

DWP นิยามห้าปฏิบัติการ

• create — สร้างแผนใหม่จากเป้าหมาย
• execute — ดำเนินแผนทีละงาน
• refine — แก้ไขแผนที่มีอยู่
• resume — ดำเนินแผนที่ถูกขัดจังหวะต่อ
• status — รายงานสถานะแผนโดยไม่ดำเนินการ

พื้นที่ทำงานผลลัพธ์

พื้นที่ทำงานเอาต์พุต

• .dwp/ git ละเว้น · ทิ้งได้
• plans/
• PLAN_<name>/
• README.md
• PROGRESS.md
• <n>.task_<slug>.md
• analysis_results/ รายงาน
• SECURITY_REVIEW.md การตรวจสอบความปลอดภัย
• EXECUTIVE_REPORT.md รายงานผู้บริหาร

สิ่งประดิษฐ์ทั้งหมดของ DWP MUST อยู่ภายใต้ไดเรกทอรี .dwp/ ที่ถูก gitignore ที่รากของ repository

สถานะแผนที่เครื่องอ่านได้

แผน MAY พกชั้นสถานะที่เครื่องอ่านได้ — manifest.json (เอกลักษณ์คงที่) และ state.json (สถานะต่อหนึ่งงานแบบสด บันทึก validation gate บันทึกผลลัพธ์ checkpoint สถานะ blocked) แผน markdown ยังคงเป็นแหล่งความจริง ชั้น JSON เป็นการฉายภาพที่ได้รับมา สร้างใหม่ที่จุดโปรโตคอลและปรับประสานตอน resume

ชั้นสถานะ RECOMMENDED สำหรับแผนใหม่ REQUIRED สำหรับการดำเนินงานแบบไม่มีผู้ดูแล และ REQUIRED สำหรับ agent workspace ที่ไม่มี git ดูนิยามเชิงบรรทัดฐานเต็มรูปแบบใน สถานะแผน

ความเข้มงวดตามสัดส่วน

ความเข้มงวด MUST เป็นสัดส่วนกับงาน พิธีกรรมบนการเปลี่ยนแปลงเล็กน้อยคือความล้มเหลวของระเบียบวิธี ไม่ใช่ความปลอดภัยเพิ่มเติม งานทุกชิ้นอยู่ในระดับเดียวกันพอดี:

เอเจนต์ที่ถูกขอให้สร้างแผนสำหรับงานระดับ micro MUST บอกว่าแผนไม่สมดุลและเสนอรูปแบบ inline แทน โฟลเดอร์แผน MUST NOT ถูกสร้างสำหรับการเปลี่ยนแปลงไฟล์เดียวเล็กน้อย

งานระดับ micro ยังคงรักษาสิ่งที่ต้องทำเสมอ: เป้าหมายชัดเจน validation gate ที่รันและผ่าน และวินัยการทดสอบสำหรับการเปลี่ยนแปลงพฤติกรรม ระดับเปลี่ยนการบรรจุ ไม่ใช่ gate

เมื่อขอบเขตขยายระหว่างดำเนินการ — งาน micro เปิดเผยขอบเขตจริง แผน standard แตกออกเป็น sub-repository — เอเจนต์ MUST หยุดและยกระดับงานไปยังระดับถัดไปแทนที่จะยืดระดับปัจจุบัน

ความเข้ากันได้

แผนและ repository จากเวอร์ชันก่อนหน้ายังคงสอดคล้อง และตัวตรวจสอบความสอดคล้อง MUST แยกแยะสิ่งประดิษฐ์ legacy ที่รู้จัก (ยอมรับ) ออกจากสิ่งประดิษฐ์ที่ประกาศเวอร์ชันนี้แต่ไม่ถูกต้องอย่างเป็นวัตถุวิสัยภายใต้มัน (ปฏิเสธ)

การกำหนดเวอร์ชัน

ข้อกำหนดนี้ใช้การกำหนดเวอร์ชันเชิงความหมาย