DWP v5: คำสัญญา ที่ตอนนี้ได้รับการรับประกัน

วันนี้เราเปิดตัว Deep Work Plan v5 นี่ไม่ใช่การเขียนใหม่: แต่เป็นผลจากการใช้งานจริงหลายเดือน — รวมถึงการตรวจสอบโดยตรงกับแผนจริง 108 แผน — ที่เปิดเผยทีละช่องว่างว่าคำสัญญาของระเบียบวิธีกับพฤติกรรมจริงของเอเจนต์อาจแตกต่างกันตรงไหนบ้าง สรุปอย่างตรงไปตรงมาของรีลีสนี้คือ: ระเบียบวิธีนี้สัญญาทุกอย่างเหล่านี้ไว้แล้ว — ตอนนี้มันรับประกันพวงมัน ก่อน v5 เอเจนต์ที่ทำตามเอกสารอย่างถอดข้อความก็ยังอาจตกไปอยู่ในสถานการณ์ล้มเหลวที่เป็นจริง สถานการณ์เหล่านั้นทุกรายการ ซึ่งถูกระบุได้จากการใช้งานและฟีดแบ็กนี้ ถูกปิดตอนนี้แล้วและถูกตรึงไว้ด้วยการทดสอบที่เรียกใช้ได้ ไม่ใช่แค่ปะด้วยข้อความเพิ่มเติม ชุดสัญญาของสกิลเติบโตจาก 132 เป็น 258 การทดสอบในรอบนี้ และทุกการรับประกันด้านล่างได้รับการตรวจสอบสดต่อแท็กที่ปล่อยออกมา — ติดตั้งลงในรีโพซิทอรีที่สะอาดและพาผ่านโฟลว์ของมันเอง ก่อนที่รายการนี้จะถูกเขียนขึ้น

ตัวตรวจสอบที่ไม่เคยอ้างความสำเร็จที่ยังไม่ได้ตรวจสอบ การตรวจสอบความสอดคล้องเดิมเสื่อมถอยลงอย่างเงียบ ๆ: เมื่อไม่มีอินเทอร์พรีเตอร์ที่มีความสามารถ มันข้ามการตรวจสอบทั้งหมดแต่ยังพิมพ์คำตัดสินว่าสอดคล้อง และข้อความตัวหนาภายในฟิลด์อาจถูกเข้าใจผิดว่าเป็นฟิลด์ที่หายไป ตอนนี้ตัวตรวจสอบจบด้วยคำตัดสิน UNVERIFIED ที่ชัดเจนทุกครั้งที่มันตรวจสอบได้จริงไม่ได้ ตัวตรวจสอบไม่เคยรายงานความสำเร็จที่ตัวเองไม่ได้ตรวจ — ความเชื่อใจต่อเกตคือข้อเสนอทั้งหมด และเกตที่ข้ามการตรวจของตัวเองได้ย่อยทำลายห่วงโซ่นั้น

สัญญาการอนุมัติเดียวสำหรับแผน Lite พื้นผิวทั้งสามเคยตอบคำถามว่า “การเริ่มแผนนี้อนุมัติขอบเขตปัจจุบันของมันหรือไม่?” ด้วยวิธีที่ต่างกันสามแบบ และเอเจนต์อาจติดตายหรือทำงานโดยไม่มีอำนาจอนุมัติตรงพรมแดนที่อันตรายที่สุด v5 กำหนดสัญญาเดียวทุกที่: execute หรือ resume ที่ชัดเจนอนุมัติขอบเขต ready ปัจจุบันและบันทึกการอนุมัตินั้นก่อนทำงานใด ๆ ข้อเสนอที่ค้างอยู่โดยตัวมันเองไม่อนุมัติสิ่งใด และการเลื่อนระดับที่ถูกขัดจังหวะจะได้รับการกู้คืนก่อนที่งานผลิตภัณฑ์ใด ๆ จะเริ่มทำงาน

การจัดหาหลายรีโพซิทอรีที่ไม่ทำให้เสียหาย ตัวแปรสภาพแวดล้อมของฮับผู้จัดหาเคยรั่วไหลลงสู่รีโพซิทอรีลูก — ลูกหนึ่งเขียนสถานะแผนลงในโฟลเดอร์ของฮับเองได้ เทมเพลตของผู้จัดหายังพิมพ์ FAIL แต่ออกด้วยโค้ดความสำเร็จ และการตรวจสอบความสมบูรณ์ที่ grep สตริงสถานะอาจอ่านงานเดียวที่เสร็จเป็นแผนที่เสร็จ ตอนนี้รากของฮับถูกบันทึกก่อนเข้าสู่ซับรีโพซิทอรี ลูกทุกตัวแก้ไข .dwp/ ของตัวเองแบบแยกส่วน ทุกกิ่งที่ล้มเหลวออกด้วยข้อผิดพลาด ความสมบูรณ์ถูกแยกวิเคราะห์จากสถานะระดับบนสุดของแผน และจุดเข้า devcontainer ส่งต่อข้อผิดพลาดการคัดลอกก่อนลบสิ่งใด ๆ

เมทริกซ์ความยินยอมเดียวสำหรับแอดออน แอดออนใดติดตั้งโดยค่าเริ่มต้น แอดออนใดเพียงถูกเสนอ และการรีวิวใดบังคับ — พื้นผิวเดิมตอบต่างกัน v5 ประกาศเมทริกซ์เดียว: AI Diff Reviewer จำเป็นสำหรับการรีวิวภายในเครื่อง ถูกตรึงกับรีลีสที่ผ่านการตรวจสอบ โดยการรีวิวบน CI เป็น opt-in ที่ชัดเจนซึ่งไม่เคยติดตั้งตัวเอง แอดออน design-system เป็นข้อเสนอบังคับเมื่อตรวจพบงาน UI แต่ติดตั้งเฉพาะเมื่อได้รับการยอมรับอย่างชัดเจน แอดออน dependency-upgrade มาในรูปผู้มอบหมายเฉย ๆ ที่เกือบเป็นค่าเริ่มต้นพร้อมการย้อนกลับแบบสแนปช็อตที่แม่นยำ และ dailybot รายงานเฉพาะที่ที่มันได้รับอำนาจ diff ที่ว่างเปล่าไม่ถูกนับเป็นการรีวิวที่เสร็จสมบูรณ์อีกต่อไป

เครื่องจักรจริงสำหรับแผนยาว การตรวจสอบแผนจริง 108 แผนชี้ว่างานที่ทำขนานได้เป็นเรื่องปกติ แต่การตัดสินใจทำตามลำดับแทบไม่เคยถูกประกาศ และ stage gate มีอยู่เพียงเป็นแนวปฏิบัติฉับพลัน v5 บังคับให้การตัดสินใจการดำเนินการถูกประกาศเสมอ — เรียงลำดับพร้อมเหตุผลที่บันทึกไว้เมื่อการทำขนานไม่เหมาะสม — เพิ่ม Stage Gates แบบเลือกได้สำหรับแผนยี่สิบงานขึ้นไป และเสริม Plan Variables ด้วยระดับความเข้มงวด เกณฑ์หลักฐาน และการกระทำที่ห้าม ทั้งหมดนี้โหลดแบบไล่ระดับและไม่เคยเป็นภาระแก่แผน Lite

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

เส้นทางอัปเกรดที่ปลอดภัย /dwp-upgrade เป็นของใหม่ ขั้นตรวจสอบของมันอ่านอย่างเดียวและไม่ติดตั้งสิ่งใด การอัปเกรดเริ่มจากการยอมรับที่ชัดเจนเท่านั้น โดยการปรับแต่งภายในเครื่องถูก diff และเปิดเผยก่อนเขียนทับสิ่งใด ๆ การติดตั้งมุ่งที่แท็กที่แน่นอนและตรวจสอบตัวเอง และ onboarding ทำงานใหม่เหมือน init ที่สดใหม่ การอัปเกรดไม่เคยแตะ .dwp/ — ไม่มีแผน ไฟล์สถานะ ระเบียนเกต หรือหลักฐานใดถูกย้าย เขียนใหม่ หรือทำให้ใช้ไม่ได้

หลักฐานที่ซื่อสัตย์และวัดได้ ข้ออ้างด้านประสิทธิภาพถูกวัดใหม่บนเบสไลน์สามตัว — v3.0.0, v4.0.3 และทรีสุดท้าย — พร้อมสคริปต์วัดที่คอมมิตไว้ในรีโพซิทอรี ผลลัพธ์รายงานเป็นไบต์ของระบบไฟล์และไม่เคยถูกแปลงเป็นตัวเลขโทเคนหรือต้นทุนที่เรายืนหยัดไม่ได้ ข้ออ้างที่ตรวจสอบไม่ได้ทุกข้อถูกกักกันไว้เช่นนั้นในบันทึกการประเมิน

สัญญาที่มีเวอร์ชันและเผยแพร่แล้ว คำสัญญาทุกข้อข้างต้นได้รับการหนุนหลังด้วยข้อมูลที่เครื่องมืออื่นอ่านได้ ไม่ใช่แค่ข้อความ: รูปแบบ plan-manifest และ plan-state ตอนนี้มีเวอร์ชันเป็นสาย schema v5 — plan-manifest/v5.json และ plan-state/v5.json — ทำให้แผน ตัวตรวจสอบ หรือเครื่องมือของบุคคลที่สามสามารถตรวจสอบความสอดคล้องกับสัญญาที่เผยแพร่และเครื่องอ่านได้ แทนที่จะเป็นย่อหน้าเอกสาร ไม่มีสิ่งใดในสาย v5 เปลี่ยนรูปแบบไปจาก v2: แผนที่มีอยู่ซึ่งอ้างอิง schema v1 หรือ v2 ยังคงใช้ได้และจะไม่ถูกเขียนใหม่เลย

Deep Work Plan v5 ยึดตามมาตรฐาน DWP 5.0.0 อ่านข้อกำหนดเชิงบรรทัดฐาน ดูรีโพซิทอรีของสกิล หรือเริ่มนำไปใช้จาก /init

อัปเดต — 2026-09-17 · สกิล v5.4.0

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

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

หลักฐานของแผนเป็นของแผนนั้น มาตรฐานวางบันทึกการวิเคราะห์ บัญชี skills การตรวจสอบความปลอดภัย และบันทึกของเกทไว้ใน analysis_results/ ของแผนเองอยู่แล้ว แต่ไม่เคยระบุความเป็นเอกสิทธิ์นั้นเป็นกฎ ด้วยเหตุนี้ เครื่องมือตรวจสอบของที่เก็บโค้ดเอง ซึ่งเส้นทางรายงานตั้งค่าเริ่มต้นไว้ที่ไดเรกทอรีทำงาน จึงอาจเขียนหลักฐานของแผนลงที่รากของที่เก็บโค้ดโดยไม่มีขั้นตอนใดสังเกตเห็น ข้อกำหนดกำหนดเรื่องนี้แล้ว ทุกสิ่งที่ขั้นตอนหนึ่งผลิตขึ้นเกี่ยวกับแผนหนึ่งจะเข้าไปในโฟลเดอร์ของแผนนั้น และเครื่องมือที่ผลลัพธ์เริ่มต้นคือไดเรกทอรีทำงานต้องได้รับตัวเลือกผลลัพธ์อย่างชัดแจ้ง หลักฐานที่ไม่ได้อยู่ในที่ที่แผนบอกไว้คือหลักฐานที่สูญหายไปแล้ว นั่นคือเหตุผลเชิงปฏิบัติของกฎนี้ ไม่ใช่ความชอบในการจัดเก็บแฟ้ม

การตรึงเวอร์ชันของ AI Diff Reviewer ขยับเป็น v2.3.0 การตรวจสอบในเครื่องที่บังคับ ตอนนี้ติดตั้งตัวตรวจทานที่แยก runner ออกจาก backend การตรวจสอบเดียวกันจึงสามารถทำงานกับ endpoint ที่เข้ากันได้ใด ๆ โดยไม่เปลี่ยนสิ่งที่ DWP พึ่งพา การรับประกันความเป็นกลางจึงแข็งแรงขึ้น ไม่ใช่หลวมลง นอกจากนี้ยังมีตัวติดตั้งที่ตรวจสอบด้วยเช็กซัม ค่าต้นทุนเริ่มต้นที่มาจากการวัดจริงแทนการเดา และรอบติดตามผลที่ตรวจ diff ใหม่ของจริงพร้อมกับส่งต่อข้อค้นพบที่ยังค้างอยู่ ข้อสุดท้ายมีผลทางสัญญาที่ควรพูดตรง ๆ การที่ตัวโมเดลเองอ้างว่าข้อค้นพบหนึ่งได้รับการแก้แล้ว ไม่ได้ทำให้ข้อนั้นถูกถอนออก ผู้ที่ถอนคือผู้ดูแล

หลักการทำงานเดินทางมาพร้อมกับ harness แล้ว v5.5.0 ซึ่งออกในวันเดียวกัน ทำให้ onboarding ไม่เพียงบอก agent ของที่เก็บโค้ดว่าในนั้นมีอะไร แต่ยังสอนว่าควรทำงานอย่างไร ด้วยสิบพฤติกรรมที่กระชับ ได้แก่ รับผิดชอบผลลัพธ์ ค้นคว้าก่อนถาม ตัดสินใจเรื่องประจำได้เอง ยกระดับขึ้นไปเมื่อขาดข้อมูลตัดสินหรือขาดอำนาจจริง ๆ และตรวจสอบก่อนอ้างว่าเสร็จ เป็นต้น ทั้งหมดเขียนแบบอินไลน์ไว้ใน AGENTS.md ที่ซึ่ง agent ซึ่งอ่านเพียงจุดเริ่มต้นก็จะพบ สิ่งเหล่านี้เป็นค่าตั้งต้นภายในคำขอหนึ่ง ไม่ใช่อำนาจใหม่ จะไปลบล้างสิทธิ์ของโฮสต์ ขอบเขตที่แคบกว่า เกทของแผน หรือกฎการอนุมัติของที่เก็บโค้ดเองไม่ได้ การอัปเกรดจะปรับให้สอดคล้องกันตามความหมาย ไม่ใช่ตามคำสำคัญ กฎที่เทียบเท่ากันซึ่งมีอยู่แล้วในไฟล์จึงถูกเก็บไว้แทนที่จะถูกเขียนใหม่

การตรึงเวอร์ชันของ AI Diff Reviewer ขยับเป็น v2.3.1 สกิล v5.5.1 ติดตั้งตัวตรวจทานที่ check เนื้อหาการตรวจทาน และความคิดเห็นติดตามผลสอดคล้องกัน เนื้อหาที่เขียนว่า Recommendation: approve ไม่ใช่หลักฐานว่า check ผ่านแล้ว — อ่านบล็อก Check status ของเครื่องหมายติดตามผล ในโหมด advisory การแก้ไขที่ได้รับการยืนยันสามารถถอนข้อค้นพบที่เธรดถูกยุบแล้วได้ ดังนั้น PR ที่ค้างอยู่สามารถเป็นสีเขียวหลังการแก้ไขจริง

อ่านข้อกำหนดสำหรับตัวบทเชิงบรรทัดฐาน เอกสารอ้างอิงส่วนเสริมสำหรับสิ่งที่ตัวตรวจทานทำได้ในตอนนี้ หรือการเผยแพร่ v5.5.1สำหรับแหล่งที่มา

อัปเดต — 2026-09-25 · skill v5.5.3 + ตัวตรวจทาน v3.1.1

ส่วนเสริม AI Diff Reviewer ตอนนี้จัดทำเอกสารและติดตั้งเส้นทาง v3 ของตัวตรวจทาน ซึ่งเผยแพร่เมื่อ 2026-09-24 (v3.0.0 → v3.1.1, pin เคลื่อนที่ @v3) skill v5.5.2 ได้เขียนใหม่เอกสารเชิงบรรทัดฐานของส่วนเสริม ฮุค onboarding และเทมเพลตการเชื่อมต่อ ให้สอดคล้องกับสิ่งที่ตัวตรวจทาน v3 ทำจริง และ v5.5.3 ส่งมอบฝั่ง CI ข้อเปลี่ยนแปลงที่สำคัญที่สุด ตรวจสอบกับตัวตรวจทานที่เผยแพร่ที่ tag v3.1.1:

critical จะกั้นก็ต่อเมื่อผ่านการตรวจสอบแล้วเท่านั้น ตั้งแต่ v3 ข้อค้นพบระดับ critical แต่ละรายการที่โมเดลอ้างสิทธิ์ — บวกตัวอย่าง 30 % ของคำเตือน — จะได้รับการตรวจสอบครั้งที่สองอย่างสั้นที่อิงโค้ดโดยการเรียกโมเดลแยกต่างหาก (≈ 3 k โทเค็น 10 วินาที และ $0.009 ต่อข้อค้นพบที่ผ่านการตรวจสอบ) critical จะถูกเผยแพร่ — และบล็อก Final Review — เมื่อตัวตรวจสอบนั้นยืนยันเท่านั้น ส่วนการอ้างสิทธิ์ที่ถูกหักล้างยังคงมองเห็นได้เป็นคำเตือนพร้อมหมายเหตุและถูกระบุไว้ในผลลัพธ์ที่มีโครงสร้าง ไม่เคยโพสต์แบบอินไลน์ การตรวจสอบที่ใช้หมดเพดานรอบ (incomplete) หรือนาฬิกาจับเวลา (timeout) เป็นสีแดงภายใต้ความเข้มงวดแบบบล็อก — “ไม่มีข้อค้นพบ” หมายความว่าตัวตรวจทานได้ดูแล้วและไม่พบอะไรเสมอ

งบประมาณตามระดับความเสี่ยง งบประมาณการตรวจทานอนุมานจากระดับความเสี่ยงเชิงกำหนดของการเปลี่ยนแปลง — 8/20/30/40 รอบจาก low ถึง critical — และ push ที่ไม่เปลี่ยนโค้ดจะรันหนึ่งรอบเฉพาะตัวตรวจสอบด้วยต้นทุน −93 % budget-profile: fixed คืนค่าคงที่ก่อน v3 ระหว่างการเปลี่ยนผ่าน รอบแบบเพิ่มเติมตัดโทเค็นอินพุตลง 62–76 %

หก sub-skill หนึ่งในนั้นคือลูป ตัวกำหนดเส้นทางได้ address-review เพิ่มเข้ามา (ใหม่ใน v3.1.1) คำสั่งเดียวจะค้นหา PR ที่เปิดอยู่ของ branch ตรวจว่าการตรวจทานครอบคลุม head ปัจจุบันหรือไม่ นำเสนอข้อค้นพบพร้อมแผนนำไปใช้/เลื่อน/ข้าม แล้ว — เมื่อได้รับคำว่าใช่เพียงครั้งเดียว — นำไปใช้ commit เป็นชุด Conventional Commits ขนาดเล็ก push และติดอาวุธตัวตรวจทานใหม่ตามวิธีที่ repo ทริกเกอร์มัน apply-review ยังคงอ่านอย่างเดียว ผลลัพธ์ที่มีโครงสร้าง (review-output/3.0) คือเส้นทางสำหรับเครื่องจักรของการทำงานอัตโนมัติใด ๆ ไลน์ @v2 ยังคงแช่แข็งที่ release/v2 พร้อมการบำรุงรักษาด้านความปลอดภัยและแคตตาล็อกหกเดือน — v3 เป็นคำแนะนำ ไม่ใช่การย้ายถิ่นแบบบังคับ

ตัวตรวจทานตรวจบ้านของตัวเองแล้ว ทั้ง repository ของ skill และเว็บไซต์นี้ต่างรันการตรวจทาน CI แบบกั้นด้วยป้าย — ขา grok เดียวผ่าน DailybotHQ/ai-diff-reviewer@v3 ทริกเกอร์หนึ่งครั้งต่อการติดป้าย ready (ถอดและติดป้ายใหม่เพื่อรันซ้ำ) พร้อมการข้ามอย่างตรงไปตรงมาเมื่อไม่มี secret ของผู้ให้บริการ เว็บไซต์นี้ยัง vendorize ตัวตรวจทาน v3.1.1 ด้วย ทำให้ Final Review ในเครื่องและเอกสารสอนสัญญาเดียวกันแล้ว

อ่าน ข้อกำหนด คู่มือส่วนเสริม สำหรับรายการความสามารถ v3 ฉบับเต็ม รีลีส v5.5.3 สำหรับแหล่งที่มา หรือ รีลีส v3.1.1 ของตัวตรวจทาน สำหรับสิ่งที่เปลี่ยนแปลงจากต้นทาง