การตรวจสอบการเปลี่ยนแปลง

คำมั่นใจทั้งหมดของ OpenSpec คือ คุณและ AI ของคุณ ตกลงกันว่าจะสร้างอะไรก่อนเขียนโค้ดแม้แต่บรรทัดเดียว ความตกลงนั้นจะมีค่าเฉพาะเมื่อคุณอ่านสิ่งที่ AI เขียนร่างจริง ๆ หน้านี้เกี่ยวกับสองนาทีที่คุณทำสิ่งนั้น — จะเปิดอะไร ตามลำดับใด และจะมองหาอะไร

การเดิมพันนั้นง่าย: การจับได้ว่าทางเลือกผิดในแผนหนึ่งย่อหน้าแทบไม่มีค่าใช้จ่าย การจับทางเลือกผิดเดียวกันใน 300 บรรทัดโค้ดก็ไม่ใช่ การตรวจสอบคือจุดที่คุณเก็บผลตอบแทนจากการเดิมพันนั้น

สองช่วงเวลาที่คุณตรวจสอบ

มีเพียงสองช่วงเท่านั้น:

/opsx:propose ──► REVIEW THE PLAN ──► /opsx:apply ──► REVIEW THE CODE ──► /opsx:archive
                  (before any code)                    (/opsx:verify)

1. หลังจากรัน /opsx:propose (หรือ /opsx:ff) ก่อนรัน /opsx:apply — อ่านแผนในขณะที่มันยังเป็นคำพูดล้วน ๆ
2. หลังจากสร้างโค้ดเสร็จ ด้วย /opsx:verify — ตรวจสอบว่าโค้ดทำตามที่แผนบอกจริง ๆ

การตรวจสอบครั้งแรกเป็นอันที่ช่วยคุณได้มากที่สุด และเป็นอันที่คนส่วนใหญ่พลาดไป หน้านี้ใช้เวลาส่วนใหญ่พูดถึงมัน

อ่านตามลำดับนี้

การเปลี่ยนแปลงแต่ละครั้งเป็นโฟลเดอร์ที่มีไฟล์ Markdown ล้วน ๆ ใน openspec/changes/<name>/ อ่านไฟล์ในลำดับที่ให้คุณหยุดได้เร็วที่สุดหากมีสิ่งผิดปกติ:

openspec/changes/add-dark-mode/
├── proposal.md      1. จุดประสงค์และขอบเขต   ← หากสิ่งนี้ผิด หยุดที่นี่
├── specs/…/spec.md  2. ข้อกำหนด       ← หัวใจของการตรวจสอบ
├── design.md        (สำหรับการเปลี่ยนแปลงขนาดใหญ่เท่านั้น) — แนวทางทางเทคนิค
└── tasks.md         3. แผนงาน

คุณไม่จำเป็นต้องอ่านทุกบรรทัด คุณเพียงตอบคำถามสามข้อ หนึ่งข้อต่อหนึ่งไฟล์

ข้อเสนอ: นี่คือปัญหาที่ถูกต้องหรือไม่?

เปิด proposal.md ก่อน ไฟล์นี้จับภาพ "ทำไม" และ "ทำอะไร" — จุดประสงค์ ขอบเขต และแนวทางในหนึ่งหรือสองย่อหน้า

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

สัญญาณอันตราย:

• มันแก้ปัญหาที่แตกต่างกันเล็กน้อยจากปัญหาที่คุณขอมา
• ขอบเขตขยายใหญ่ขึ้น — คุณขอสลับธีมและข้อเสนอยังแตะเรื่องการยืนยันตัวตน "ในขณะที่เรากำลังทำอยู่"
• มันคลาดเคลื่อน "ปรับปรุงหน้าตั้งค่า" ไม่ใช่ขอบเขต; "เพิ่มสลับโหมดมืดที่เคารพค่าการตั้งค่าของระบบปฏิบัติการ" ใช่

คำถามที่ต้องตอบ: สิ่งนี้ตรงกับสิ่งที่ฉันขอจริง ๆ หรือไม่ และมีอะไรแอบเข้ามาอยู่หรือไม่? หากคำตอบคือ ไม่ หยุด — อ่านต่อไม่ได้ แก้ไขข้อเสนอ (ดู การโต้ตอบกลับนั้นคุ้มค่ากว่า)

ข้อกำหนดแบบเดลต้า: การกำหนดว่า "เสร็จสมบูรณ์" ถูกต้องหรือไม่?

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

## ADDED Requirements

### Requirement: Dark Mode Toggle
The system SHALL let a user switch between light and dark themes.

#### Scenario: Respects the OS preference on first load
- GIVEN a user who has never set a theme
- WHEN they open the app on a device set to dark mode
- THEN the app renders in dark mode

ลักษณะของข้อกำหนดที่ดีคือ: คำสั่ง SHALL/MUST หนึ่งอย่างชัดเจนที่คุณสามารถส่งให้กับผู้ทดสอบได้ และอย่างน้อยหนึ่งสถานการณ์ที่ GIVEN/WHEN/THEN ของมันทดสอบคำสั่งนั้นจริง ๆ

สัญญาณอันตราย:

• ข้อกำหนดคลาดเคลื่อน "ระบบ SHALL เร็ว" ไม่สามารถสร้างหรือทดสอบได้ เร็วคืออะไร?
• ข้อกำหนดที่ไม่มีสถานการณ์ประกอบ หรือสถานการณ์ที่ไม่ทดสอบข้อกำหนดที่อยู่ใต้มัน
• สิ่งที่จับได้มีค่าที่สุดทั้งหมด: สิ่งที่หายไป AI เขียนลงอย่างถูกต้องตามสิ่งที่คุณพูด งานของคุณคือสังเกตสิ่งที่คุณลืมพูด หากคุณสนใจที่สุดในกรณีค่าการตั้งค่าของระบบปฏิบัติการและไม่มีสถานการณ์ที่พูดถึงมัน นี่คือการตรวจสอบที่ตอบแทนตัวเอง

อ่านเดลต้าด้วยคำถาม ฉันจะพอใจหากระบบทำอย่างถูกต้อง — และเฉพาะ — สิ่งนี้หรือไม่? สิ่งนี้ยังไม่เกี่ยวกับโค้ดเลย ดังนั้นจึงยังคงมีค่าใช้จ่ายต่ำในการเปลี่ยนแปลง

งานต่างๆ: แผนงานสมเหตุสมผลหรือไม่?

เปิด tasks.md ท้ายสุด ไฟล์นี้คือรายการตรวจสอบการนำไปใช้ที่ AI จะทำงานตาม

ลักษณะที่ดีคือ: ขั้นตอนที่มีลำดับ ทุกขั้นตอนสามารถสืบทอดไปยังข้อกำหนดได้ ไม่มีสิ่งลึกลับ

สัญญาณอันตราย:

• งานที่ไม่มีข้อกำหนดที่ตรงกัน (มาจากไหน?)
• งาน "นำฟีเจอร์ไปใช้" หนึ่งชิ้นใหญ่ที่ซ่อน所有การตัดสินใจจริงทั้งหมด
• งานที่แตะสิ่งใดสิ่งหนึ่งที่อยู่นอกขอบเขตที่คุณเพิ่งอนุมัติ

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

การโต้ตอบกลับนั้นคุ้มค่ากว่า

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

• แก้ไขไฟล์ด้วยตัวเอง ไฟล์นี้เป็น Markdown ล้วน ๆ; เปลี่ยนบรรทัดขอบเขต ปรับให้ข้อกำหนดเข้มงวดขึ้น ลบงานออก
• บอก AI ว่าอะไรผิด และให้它ปรับปรุง: "ลบการเปลี่ยนแปลงเกี่ยวกับการยืนยันตัวตน — อยู่นอกขอบเขต," "เพิ่มสถานการณ์สำหรับกรณีที่ผู้ใช้ได้เลือกธีมแล้ว," "แยกงานที่ 3 เป็น schema และ UI."

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

หลังจากเขียนโค้ด: ตรวจสอบความถูกต้อง

เมื่องานถูกสร้างเสร็จ /opsx:verify คือการตรวจสอบครั้งที่สองของคุณ มันอ่านผลงานและโค้ดอีกครั้งและรายงานความไม่สอดคล้องในสามมิติ:

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

You: /opsx:verify

AI:  Verifying add-dark-mode...

     COMPLETENESS
     ✓ All 8 tasks in tasks.md are checked
     ✓ All requirements in specs have corresponding code
     ⚠ Scenario "Respects the OS preference on first load" has no test coverage

มันจะติดป้ายปัญหาเป็น CRITICAL, WARNING หรือ SUGGESTION และมันไม่บล็อกการจัดเก็บ — มันแสดงช่องว่างและให้คุณตัดสินใจเอง นี่คือความแตกต่างระหว่าง "AI เขียนโค้ดหรือไม่" และ "มันสร้างสิ่งที่เราตกลงกันหรือไม่"

/opsx:verify อยู่ในโปรไฟล์แบบขยาย หากคุณไม่มี它 เปิด它ด้วย openspec config profile (จากนั้นรัน openspec update) หรือเพียงอ่านการเปลี่ยนแปลงและ diff ด้วยตัวเองอีกครั้ง

ปรับขนาดการตรวจสอบให้เหมาะสม

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

รายการตรวจสอบสองนาที

• [ ] จุดประสงค์ของข้อเสนอตรงกับสิ่งที่ฉันขอมา
• [ ] ไม่มีสิ่งใดเพิ่มเติมแอบเข้ามาในขอบเขต
• [ ] ข้อกำหนดทุกข้อมีรายละเอียดเพียงพอที่จะทดสอบ
• [ ] ข้อกำหนดทุกข้อมีสถานการณ์ที่ทดสอบมันจริง ๆ
• [ ] กรณีที่ฉันสนใจที่สุดถูกครอบคลุม
• [ ] งานแต่ละชิ้นสอดคล้องกับข้อกำหนด; ไม่มีสิ่งลึกลับหรืออยู่นอกขอบเขต
• [ ] ฉันจะสบายใจหาก AI สร้างอย่างถูกต้อง — และเฉพาะ — สิ่งนี้และไม่มากกว่านั้น

หากทั้งหมดเจ็ดข้อผ่าน ให้รัน /opsx:apply ด้วยความมั่นใจ หากข้อใดข้อหนึ่งล้มเหลว นี่ไม่ใช่ความผิดหวัง — นี่คือสองนาทีที่กำลังทำงานตามหน้าที่

ที่น่าสนใจต่อไป

• การเขียนข้อกำหนดที่ดี — อีกด้านหนึ่ง: วิธีร่างข้อกำหนดและสถานการณ์ที่คุ้มค่าที่จะอนุมัติ
• การแก้ไขและวนซ้ำการเปลี่ยนแปลง — กลไกของการเปลี่ยนแปลงแผนหลังจากคุณเริ่มต้นแล้ว
• เวิร์กโฟลว์ — ที่ที่การตรวจสอบอยู่ในลูปการทำงานขนาดใหญ่