หลักการ

ผู้อ่าน: ผู้ใช้โปรเจกต์ อ่านหน้านี้หลัง Change Loop คืออะไร เพื่อเข้าใจว่าทำไม harness จึงทำงานแบบนี้ แต่ละหลักการเป็นบทสรุปของสัญญา กติกาที่แน่นอนอยู่ในหน้าที่ลิงก์ไว้

Change Loop ตั้งอยู่บนหลักการแปดข้อ ทั้งหมดตอบคำถามเดียวกัน: เมื่อ AI coding agent บอกว่า change เสร็จแล้ว อะไรทำให้คำพูดนั้นเชื่อถือได้

หลักการ	สรุปในหนึ่งบรรทัด
Proof-Driven Development	change เสร็จก็ต่อเมื่อหลักฐานที่รันได้จริงและเป็นปัจจุบันยืนยัน
Spec-Driven Development	ข้อตกลงที่อนุมัติแล้ว ไม่ใช่โค้ด เป็นตัวกำหนดว่าพฤติกรรมไหนถูก
Clear ownership	คุณตัดสินใจ agent ลงมือทำ harness ทำงานอัตโนมัติ
Isolation until Land	งานเกิดนอก checkout ของคุณจนกว่าคุณจะอนุญาต
Fail closed	หลักฐานที่ขาดหรือไม่รู้ผล ไม่มีวันถูกรายงานว่าผ่าน
Risk sets the rigor	ความเข้มของการตรวจตามความเสี่ยง ขนาดกำหนดแค่งบและการแบ่งงาน
Reuse before rerun	ใช้ผลที่ยังใช้ได้ซ้ำ รันใหม่เฉพาะ check ที่ถูก invalidate
Recoverable by design	ทุกครั้งที่หยุด งานถูกเก็บไว้และมีทางไปต่อที่ชัดเจน

Proof-Driven Development

change ยังไม่ถือว่าเสร็จ จนกว่าจะมีหลักฐานที่รันได้จริงและเป็นปัจจุบัน ยืนยันว่ามันทำตามที่ตกลงไว้ รายงานว่าสำเร็จจาก agent ไม่เคยนับเป็นหลักฐาน

• กำหนดวิธีพิสูจน์ก่อน ข้อตกลงระบุ claim แต่ละข้อและวิธีตรวจไว้ก่อนเริ่ม Build
• เครื่องมือเป็นผู้พิสูจน์ ไม่ใช่ agent นับเฉพาะ receipt ที่เกิดจากการรัน เครื่องมือของโปรเจกต์คุณเอง
• หลักฐานต้องเป็นปัจจุบัน receipt ผูกกับโค้ดและข้อตกลงที่ตรวจจริง ถ้าเปลี่ยนอย่างใดอย่างหนึ่ง receipt จะ stale
• proven ยังไม่ใช่ส่งมอบ proven แปลว่าหลักฐานดี flow การส่งมอบจะจบก็ต่อเมื่อ Land ไปถึง archived

ต่างจาก test-driven development ตรงที่หลักฐานไม่ได้จำกัดแค่เทส การรันบน browser, การตรวจ accessibility, review และ human acceptance ก็กำหนดให้ต้องมีได้ รายละเอียด: Claims, Receipts, Prove

Spec-Driven Development

ข้อตกลง OpenSpec ที่อนุมัติแล้วคือ source of truth ของพฤติกรรม โค้ดและเทสเป็น หลักฐานว่าข้อตกลงเป็นจริง แต่ไม่ได้นิยามข้อตกลงใหม่

• เจตนาถูกตกลงให้ชัดในขั้น Change ก่อนเขียนโค้ดของผลิตภัณฑ์
• ถ้าระหว่าง Build พบพฤติกรรมที่ข้อตกลงไม่ได้ครอบคลุม agent จะเสนอ amendment ภายใต้ change ID เดิม และทำ proof ใหม่เฉพาะส่วนที่ได้รับผลกระทบ
• ข้อตกลงยังคงอ่านได้โดยคน: เขียนเป็น scenario ไม่ใช่บันทึกการ implement

รายละเอียด: Change

Clear ownership

ทุกขั้นมีเจ้าของคนเดียว และคุณจะถูกขัดจังหวะเฉพาะเรื่องที่เป็นการตัดสินใจของคุณจริง ๆ

เจ้าของ	ความรับผิดชอบ
คุณ	เจตนา ความหมายเชิงผลิตภัณฑ์ trade-off สำคัญ acceptance และการอนุญาต Land หรือ side effect ภายนอกใด ๆ
AI coding agent	การสำรวจ ข้อตกลง การ implement เทส และการแก้ไข
Harness	state ของ lifecycle, isolation, การรันหลักฐาน, งบ, การกู้คืน และ guard ตอน Land

ก่อน Land, flow จะหยุดเฉพาะเมื่อต้องการการตัดสินใจจากคุณ การ setup การเตรียมเครื่องมือ การซ่อม sandbox และการแก้ซ้ำ ยังอยู่กับ agent หรือ harness ส่วน Land เป็น gate แข็งเพียงจุดเดียว harness เป็นซอฟต์แวร์แบบ deterministic ไม่ใช่ AI: มันไม่เดา และไม่อนุมานสิทธิ์ของคุณเอง รายละเอียด: การอนุมัติโดยคน

Isolation until Land

agent ลงมือทำและพิสูจน์ใน sandbox ที่แยกออกมา working tree, index และ branch ของคุณไม่ถูกแตะจนกว่าคุณจะอนุญาต Land อย่างชัดเจน

• Land ตรวจปลายทางก่อนนำเข้า และหยุดเมื่อเจอ conflict แทนที่จะเขียนทับการแก้ไขอื่น
• sandbox ยังเป็นสิ่งที่ถูกพิสูจน์จนกว่า archive จะเสร็จ

isolation ปกป้องความถูกต้องของ workspace ของคุณ แต่ไม่ใช่ขอบเขตด้านความปลอดภัย: มันไม่ได้กักกัน process การเข้าถึงเครือข่าย หรือ secret บนเครื่อง รายละเอียด: Build

Fail closed

เมื่อ harness ยืนยันไม่ได้ว่าบางอย่างผ่าน มันจะไม่ถือว่าผ่าน

• ไม่พบเทสเลย หรือหลักฐานที่คาดไว้หายไป ไม่สามารถผ่านแบบเงียบ ๆ ได้
• check ที่รันไม่ได้เป็น error ส่วน check ที่รันแล้วแต่ไม่ได้ตัดสิน claim เป็น inconclusive ทั้งสองแบบ block ไม่ว่า exit code จะเป็นอะไร
• proof ที่ fail, stale หรือถูก waive ยังมองเห็นได้ตอน Land waiver คือการตัดสินใจ ที่บันทึกไว้ของคุณ และไม่เคยแสดงเป็นการผ่าน
• ค่าที่วัดไม่ได้ เช่นต้นทุนหรือจำนวน token ยังคงเป็น “ไม่ทราบ” ไม่กลายเป็นศูนย์

รายละเอียด: Receipts

Risk sets the rigor

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

Reuse before rerun

receipt แต่ละใบบันทึก input ที่มันพึ่งพา ตราบใดที่ input เหล่านั้นไม่เปลี่ยน ผลจะถูก ใช้ซ้ำ เมื่อมีตัวใดเปลี่ยน จะรันใหม่เฉพาะ check ที่ขึ้นกับมัน การพิสูจน์ซ้ำจึงเร็ว โดยไม่ยอมรับผลที่ stale รายละเอียด: Receipts

Recoverable by design

งานที่ใช้เวลานานย่อมถูกขัดจังหวะ ไม่ว่าจาก failure, credential ที่ขาด หรือการตัดสินใจ Change Loop ถือว่านี่เป็นเรื่องปกติ

• ทุกครั้งที่หยุด change ถูกเก็บไว้และมีขั้นถัดไปที่ชัดเจน: ใครเป็นเจ้าของ ทำไม และวิธี resume ที่แน่นอน
• เมื่อเป็นการตัดสินใจของคุณ จะมีตัวเลือกที่เป็นรูปธรรมพร้อมคำแนะนำ
• ความล้มเหลวซ้ำที่ไม่มีความคืบหน้าจะถูกส่งกลับไปที่เจ้าของพร้อมคำขอให้เปลี่ยนวิธี แทนที่จะวนซ้ำ
• Land มี journal: Land ที่ถูกขัดจังหวะหรือเป็นงานหลาย repository จะ resume จาก journal และการนำเข้าที่ล้มเหลวจะถูก rollback

รายละเอียด: Land