การย้ายเฟรมเวิร์ก

ตัวอย่างขั้นตอนของงานที่ DWP ถูกสร้างมาเพื่อรองรับ นั่นคือการย้ายที่กินไฟล์หลายสิบไฟล์และเวลาหลายชั่วโมง ยาวพอที่ agent ที่ไร้การชี้นำจะหลุดจากเส้นทาง

เป้าหมาย

One big change → ordered, gated tasks

Without a plan

Big migration ✗ Build fails

As a Deep Work Plan

1. ✓ Task 1 ⬡ gate
2. ✓ Task 2 ⬡ gate
3. ✓ Task 3 ⬡ gate
4. ✓ Task 4 ⬡ gate
5. ✓ Task 5 ⬡ gate

“ย้ายชั้นข้อมูลจาก ORM เดิมไปยังตัวใหม่ตลอดทั้งบริการ”

เมื่อไม่มีแผน

agent แก้ model ไปเรื่อย ๆ จนบริบทเต็มไปด้วยการเปลี่ยนแปลงที่ทำค้างไว้ครึ่ง ๆ กลาง ๆ ลืมไปว่าได้แปลงจุดเรียกใช้ไหนไปแล้วบ้าง และทิ้ง build ที่ขึ้นสีแดงไว้โดยไม่มีบันทึกว่าเหลืออะไรอีก การทำงานต่อจึงหมายถึงต้องประกอบกระบวนคิดของตนเองขึ้นใหม่จาก log ของแชต

เมื่อทำเป็น Deep Work Plan

/dwp-create แยกเป้าหมายออกเป็น task แบบ atomic ที่เรียงลำดับ แต่ละตัวมี acceptance criteria และ validation gate ดังนี้

1. นำ ORM ตัวใหม่เข้ามาควบคู่กับตัวเดิม (ไม่เปลี่ยนพฤติกรรม gate คือ build + test ขึ้นเขียว)
2. ย้าย model และจุดเรียกใช้ของ module A (gate คือ test ของ module A ขึ้นเขียว)
3. ทำซ้ำราย module หนึ่ง task ต่อหนึ่ง module และบันทึกความคืบหน้าหลังทุก task
4. ลบ ORM เดิมและ shim ของมันออก (gate คือไม่เหลือการอ้างอิงใด และชุดทดสอบทั้งหมดขึ้นเขียว)
5. อัปเดตเอกสารและ README ราย module

/dwp-execute รัน task ตามลำดับ commit หลังแต่ละ gate ที่ผ่าน และอัปเดต PROGRESS.md หากหน้าต่างบริบทรีเซ็ตกลางคัน /dwp-resume จะอ่านแผนและความคืบหน้าจากดิสก์แล้วดำเนินต่อที่ task ถัดไปที่ยังไม่ถูกทำเครื่องหมาย

ผลลัพธ์

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