تحرير وتكرار التغيير

كل قطعة أثرية في التغيير هي مجرد ملف Markdown يمكنك تحريره في أي وقت. لا توجد "مرحلة تخطيط" مقفلة، ولا بوابة موافقة، ولا وضع تحرير خاص للدخول. هل تريد تغيير المقترح بعد أن بدأت البناء؟ افتح proposal.md وقم بتغييره. أدركت أن التصميم خاطئ في منتصف التنفيذ؟ أصلح design.md واستمر. هذا هو الجواب الكامل، وهو مصمم بهذه الطريقة.

هذه الصفحة مخصصة لللحظة التي تفكر فيها "انتظر، هل يمكنني العودة وتغيير ذلك؟" نعم. إليك كيف، لكل حالة شائعة.

طريقتان لتحرير أي شيء

لديك دائماً كليهما:

1. تحرير الملف مباشرة. القطع الأثرية هي Markdown عادي في openspec/changes/<name>/. افتح proposal.md أو design.md أو tasks.md أو delta spec تحت specs/ في المحرر الخاص بك وقم بتغييره. لا شيء آخر مطلوب.

2. اطلب من الذكاء الاصطناعي الخاص بك مراجعتها. في الدردشة، قل فقط ما تريد: "Update the proposal to drop the caching idea and add a rate-limit section،" أو "the design should use a queue, not polling." يقوم الذكاء الاصطناعي بتحرير القطعة الأثرية لك، باستخدام باقي التغيير كسياق.

استخدم أيهما يناسب اللحظة. تعديل صغير في الصياغة؟ حرر الملف. إعادة تفكير جوهرية؟ دع الذكاء الاصطناعي يراجع بالسياق الكامل.

"كيف أقوم بتحديث المقترح (أو المواصفات) بعد أن بدأت؟"

فقط حدثه. نفس التغيير، مع تحسين.

إذا كنت تستخدم الأوامر الموسعة، التدفق الطبيعي هو: تحرير القطعة الأثرية، ثم تشغيل /opsx:continue للاستئناف من الحالة الجديدة، أو /opsx:apply لمواصلة التنفيذ وفقاً للخطة المحدثة. إذا كنت تستخدم أوامر core الافتراضية، حرر القطعة الأثرية وشغل /opsx:apply؛ فهو يقرأ الملفات الحالية، لذا فإنه يبني بناءً على ما تشير إليه القطع الأثرية الآن.

النموذج العقلي: القطع الأثرية هي الخطة الحية، وليست عقداً موقعاً. يعمل الذكاء الاصطناعي دائماً من محتوياتها الحالية، لذا فإن تحريرها يوجه العمل.

You: أريد تغيير النهج في هذا التغيير.

You: [حرر design.md، أو قل للذكاء الاصطناعي:]
     Update design.md to use a background job instead of a synchronous call.

AI:  Updated design.md. The task list still fits; want me to continue applying?

You: /opsx:apply

هذا يجيب على سؤال شائع جداً: لا يوجد أمر منفصل "لتحديث المقترح" لأنك لا تحتاج إليه. الملف هو مصدر الحقيقة، وتحريره (يدوياً أو عبر الذكاء الاصطناعي) هو التحديث.

"كيف أعود للمراجعة بعد التنفيذ؟"

ليس عليك "العودة"، لأنك لم تغادر أبداً. سير العمل سلس: المراجعة والتحرير والتنفيذ ليست مراحل متسلسلة محاصر فيها.

عملياً، بعد بعض عمل /opsx:apply:

• تريد إعادة فحص الخطة؟ افتح القطع الأثرية واقرأها، أو شغل openspec show <change> في الطرفية للحصول على عرض موحد.
• وجدت شيئاً للتغيير؟ حرر القطعة الأثرية (أو اطلب من الذكاء الاصطناعي ذلك)، ثم استمر.
• تريد فحص منظم للتأكد من أن الكود يطابق الخطة؟ شغل /opsx:verify (الأمر الموسع). يقدم تقريراً عن الاكتمال والصحة والتماسك دون حظر أي شيء. انظر سير العمل: التحقق.

لا توجد "مرحلة مراجعة" للعودة إليها، لأن المراجعة هي شيء يمكنك القيام به في أي نقطة، بما في ذلك بعد التنفيذ.

"لقد حررت الكود يدوياً. كيف أوفق ذلك مع OpenSpec؟"

يحدث هذا باستمرار وهو أمر جيد. قمت بتعديل شيء في المحرر الخاص بك، والآن الكود والقطع الأثرية متعارضان. أعد مزامنتهما في أي اتجاه هو الصحيح:

• الكود صحيح الآن، والمواصفة قديمة. حدث delta spec (والمهام، إذا كانت ذات صلة) لوصف السلوك الذي قمت بشحنه فعلياً. يجب أن تطابق المواصفة الواقع قبل الأرشفة، لأن الأرشفة تدمج المواصفة في مصدر الحقيقة الخاص بك.
• المواصفة صحيحة، والكود انحرف. استمر في البناء أو الإصلاح حتى يطابق الكود المواصفة.

طريقة سريعة لكشف عدم التطابق هي /opsx:verify: فهو يقرأ القطع الأثرية والكود الخاص بك ويخبرك أين يختلفان. تعامل مع مخرجاته كقائمة مهام للمصالحة، ثم أرشف بمجرد اتفاقهما.

المبدأ: في وقت الأرشفة، تصبح مواصفاتك حقيقة السجل. لذا قبل الأرشفة، اجعل المواصفات صادقة حول ما يفعله الكود. التعديلات اليدوية مرحب بها؛ فقط لا تدعها تفكك المواصفة بهدوء.

تحسين مقترح لست راضياً عنه

إذا كان المقترح المولد لا يلبي الغرض، لديك ثلاث خطوات جيدة:

• التكرار في المكان. قل للذكاء الاصطناعي ما هو الخطأ ("النطاق واسع جداً، أزل ميزات المسؤول") واتركه يراجع. الأرخص وعادة ما يكون صحيحاً.
• استكشف أولاً، ثم أعد المقترح. إذا كانت المشكلة هي أن الفكرة نفسها غير واضحة، ارجع إلى /opsx:explore، فكر فيها جيداً، واترك مقترحاً أكثر حدة يخرج من ذلك. انظر استكشف أولاً.
• ابدأ من جديد. إذا كانت النية قد تغيرت جوهرياً، يمكن أن يكون التغيير الجديد أوضح من إصلاح القديم.

تلك الخطوة الأخيرة لها دليل قرار خاص بها، لاحقاً.

متى نحدث مقابل بدء تغيير جديد

النسخة القصيرة: حدث عندما يكون نفس العمل محسناً؛ ابدأ جديداً عندما تتغير النية جوهرياً أو ينفجر النطاق إلى عمل مختلف.

• نفس الهدف، نهج أفضل؟ حدث.
• تضييق النطاق (شحن MVP الآن، والمزيد لاحقاً)؟ حدث، ثم أرشف، ثم تغيير جديد للمرحلة الثانية.
• المشكلة نفسها تغيرت ("إضافة الوضع الداكن" أصبحت "بناء نظام تنسيق كامل")؟ تغيير جديد.

هناك مخطط تدفق كامل وأمثلة عملية في سير العمل: متى نحدث مقابل البدء من جديد ومعالجة أعمق في OPSX: متى نحدث مقابل البدء من جديد.

ملاحظة حول المهام

tasks.md هو قائمة تحقق حية، وليست خطة مجمدة. أثناء التنفيذ، يمكنك إضافة مهام تكتشفها، إزالة تلك التي تبين أنها غير ضرورية، أو إعادة ترتيبها. يقوم الذكاء الاصطناعي بتحديد العناصر كمكتملة أثناء /opsx:apply، ويستأنف من أول مهمة غير محددة إذا عدت لاحقاً. تحرير القائمة أثناء الطيران متوقع.

إلى أين تذهب بعد ذلك

• سير العمل - الأنماط، بالإضافة إلى دليل قرار التحديث مقابل الجديد
• مراجعة التغيير -المرور السريع على الخطة قبل بنائها
• استكشف أولاً - المكان للتراجع إليه عندما تحتاج فكرة إلى إعادة تفكير
• الأوامر - /opsx:continue و /opsx:apply و /opsx:verify بتفصيل
• المفاهيم: القطع الأثرية - الغرض من كل قطعة أثرية