การแก้ไขและการปรับปรุงการเปลี่ยนแปลง

อาร์ติแฟกต์ทุกชิ้นในการเปลี่ยนแปลงคือไฟล์ Markdown ที่คุณสามารถแก้ไขได้ตลอดเวลา ไม่มี "ขั้นตอนการวางแผน" ที่ถูกล็อกไว้ ไม่มีเกตอนุมัติ และไม่มีโหมดการแก้ไขพิเศษที่ต้องเข้าถึง หากต้องการเปลี่ยนข้อเสนอหลังจากเริ่มสร้างไปแล้ว? ให้เปิด proposal.md แล้วทำการเปลี่ยนแปลง ปรับปรุงการออกแบบกลางระหว่างการนำไปใช้ผิดพลาดหรือไม่? แก้ไข design.md และดำเนินการต่อไป นั่นคือคำตอบทั้งหมดและเป็นไปตามการออกแบบ

หน้านี้มีไว้สำหรับช่วงเวลาที่คุณคิดว่า "เดี๋ยวก่อน ฉันสามารถย้อนกลับไปแก้ไขสิ่งนั้นได้ไหม?" คำตอบคือได้ นี่คือวิธีการสำหรับกรณีทั่วไปแต่ละกรณี

สองวิธีในการแก้ไขทุกสิ่ง

คุณมีทั้งสองอย่างเสมอ:

1. แก้ไขไฟล์โดยตรง อาร์ติแฟกต์เป็น Markdown ธรรมดาที่อยู่ใน openspec/changes/<name>/ เปิด proposal.md, design.md, tasks.md, หรือ delta spec ภายใต้ specs/ ในโปรแกรมแก้ไขของคุณและทำการเปลี่ยนแปลง ไม่จำเป็นต้องมีสิ่งอื่นใดอีก
2. ขอให้ AI ปรับปรุง ในแชท เพียงแค่บอกว่าคุณต้องการอะไร เช่น "อัปเดตข้อเสนอเพื่อยกเลิกแนวคิดเรื่องแคชและการเพิ่มส่วนจำกัดอัตรา (rate-limit)" หรือ "การออกแบบควรใช้คิว ไม่ใช่การ polling" AI จะแก้ไขอาร์ติแฟกต์ให้คุณ โดยใช้บริบทของการเปลี่ยนแปลงที่เหลือ

เลือกใช้วิธีใดก็ได้ที่เหมาะสมกับสถานการณ์ การปรับคำเล็กน้อย? แก้ไขไฟล์ การคิดทบทวนอย่างมีนัยสำคัญ? ให้ AI ปรับปรุงโดยใช้บริบททั้งหมด

"ฉันจะอัปเดตข้อเสนอ (หรือ specs) ได้อย่างไรหลังจากที่เริ่มไปแล้ว?"

เพียงแค่ทำการอัปเดต เปลี่ยนแปลงเดิมให้ได้รับการปรับปรุงแก้ไข

หากคุณกำลังใช้คำสั่งแบบขยาย (expanded commands) ลำดับที่เป็นธรรมชาติคือ: แก้ไขอาร์ติแฟกต์ จากนั้นรัน /opsx:continue เพื่อดำเนินการต่อจากสถานะใหม่ หรือ /opsx:apply เพื่อดำเนินการตามแผนที่อัปเดตแล้ว หากคุณใช้คำสั่ง core แบบเริ่มต้น ให้แก้ไขอาร์ติแฟกต์และรัน /opsx:apply; คำสั่งนี้จะอ่านไฟล์ปัจจุบัน ดังนั้นจึงสร้างงานโดยอิงตามสิ่งที่อาร์ติแฟกต์ระบุไว้ในขณะนั้น

แบบจำลองทางความคิด (Mental model): อาร์ติแฟกต์คือแผนการทำงานจริง ไม่ใช่สัญญาที่ลงนามแล้ว AI จะทำงานจากเนื้อหาปัจจุบันเสมอ ดังนั้นการแก้ไขจึงเป็นการชี้นำทิศทางการทำงาน

You: ฉันต้องการเปลี่ยนแนวทางในการเปลี่ยนแปลงนี้

You: [แก้ไข design.md หรือบอก AI:]
     อัปเดต design.md ให้ใช้ background job แทน synchronous call

AI:  อัปเดต design.md แล้ว รายการงานยังคงเหมาะสม ต้องการให้ดำเนินการต่อหรือไม่?

You: /opsx:apply

สิ่งนี้ตอบคำถามที่พบบ่อยมาก: ไม่มีคำสั่ง "อัปเดตข้อเสนอ" แยกต่างหาก็เพราะคุณไม่จำเป็นต้องมี ไฟล์คือแหล่งความจริง (source of truth) และการแก้ไขมัน (ด้วยตนเองหรือผ่าน AI) คือการอัปเดต

"ฉันจะกลับไปทบทวนได้อย่างไรหลังจากที่นำไปใช้แล้ว?"

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

กล่าวโดยเฉพาะ หลังจากทำงานด้วย /opsx:apply บางส่วน:

• ต้องการพิจารณาแผนอีกครั้งหรือไม่? เปิดอาร์ติแฟกต์และอ่าน หรือรัน openspec show <change> ในเทอร์มินัลของคุณเพื่อดูภาพรวม
• พบสิ่งที่ต้องเปลี่ยนแปลงหรือไม่? แก้ไขอาร์ติแฟกต์ (หรือขอให้ AI ทำ) จากนั้นดำเนินการต่อ
• ต้องการการตรวจสอบที่เป็นโครงสร้างว่าโค้ดตรงตามแผนหรือไม่? รัน /opsx:verify (คำสั่งแบบขยาย) คำสั่งนี้จะรายงานความสมบูรณ์ ความถูกต้อง และความสอดคล้องโดยไม่บล็อกสิ่งใด ๆ ดู Workflows: Verify

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

"ฉันแก้ไขโค้ดด้วยตนเอง ฉันจะประสานงานสิ่งนี้กับ OpenSpec ได้อย่างไร?"

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

• โค้ดถูกต้องแล้ว แต่สเปคล้าสมัย อัปเดต delta spec (และ tasks หากเกี่ยวข้อง) เพื่ออธิบายพฤติกรรมที่คุณได้ส่งมอบไปจริง สเปคควรจะตรงกับความเป็นจริงก่อนที่คุณเก็บถาวา เพราะการเก็บถาวาคือการรวมสเปคเข้ากับแหล่งความจริงของคุณ
• สเปคถูกต้องแล้ว แต่โค้ดเกิดการเบี่ยงเบน ทำการสร้างหรือแก้ไขต่อไปจนกว่าที่โค้ดจะตรงตามสเปค

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

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

การปรับปรุงข้อเสนอที่คุณไม่พอใจ

หากข้อเสนอที่สร้างขึ้นมายังไม่ตรงตามความต้องการ คุณมีสามทางเลือกที่ดี:

• ทำซ้ำในที่เดิม บอก AI ว่าอะไรผิด ("ขอบเขตกว้างเกินไป ยกเลิกฟีเจอร์ผู้ดูแลระบบ") และปล่อยให้มันปรับปรุง แก้ไขได้ถูกที่สุดและมักจะถูกต้อง
• สำรวจก่อน แล้วค่อยเสนอใหม่ หากปัญหาคือแนวคิดเองยังไม่ชัดเจน ให้ถอยกลับไปยัง /opsx:explore คิดทบทวน และปล่อยให้ข้อเสนอที่เฉียบคมกว่าออกมาจากสิ่งนั้น ดู Explore First
• เริ่มต้นใหม่ หากความตั้งใจได้เปลี่ยนไปโดยพื้นฐาน การสร้างการเปลี่ยนแปลงใหม่อาจจะชัดเจนกว่าการแก้ไขของเก่า

ทางเลือกสุดท้ายนี้มีคู่มือการตัดสินใจเป็นของตัวเองต่อไป

เมื่อไหร่ควรอัปเดตเทียบกับการเริ่มการเปลี่ยนแปลงใหม่

ฉบับย่อ: ให้ทำการอัปเดตเมื่อมันคืองานเดิมที่ได้รับการปรับปรุงแก้ไข ให้เริ่มใหม่เมื่อความตั้งใจเปลี่ยนไปโดยพื้นฐานหรือขอบเขตขยายตัวจนกลายเป็นงานที่แตกต่างกัน

• เป้าหมายเดียวกัน แต่แนวทางดีขึ้น? อัปเดต
• การจำกัดขอบเขต (ส่ง MVP ก่อน ส่วนอื่นทีหลัง)? อัปเดต จากนั้นเก็บถาวา แล้วจึงสร้างการเปลี่ยนแปลงใหม่สำหรับเฟสสอง
• ปัญหาเองเปลี่ยนไป ("เพิ่ม dark mode" กลายเป็น "สร้างระบบธีมแบบเต็มรูปแบบ")? สร้างการเปลี่ยนแปลงใหม่

มีผังงานฉบับเต็มและตัวอย่างที่ทำงานได้ใน Workflows: When to Update vs Start Fresh และการกล่าวถึงเชิงลึกใน OPSX: When to Update vs. Start Fresh

ข้อสังเกตเกี่ยวกับงาน (Tasks)

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

จะไปต่อที่ไหน

• Workflows - รูปแบบและคู่มือการตัดสินใจเรื่องการอัปเดตเทียบกับการสร้างใหม่
• Explore First - สถานที่สำหรับถอยกลับเมื่อแนวคิดต้องการการคิดทบทวน
• Commands - /opsx:continue, /opsx:apply และ /opsx:verify โดยละเอียด
• Concepts: Artifacts - อาร์ติแฟกต์แต่ละชิ้นมีไว้เพื่ออะไร