التعديل والتكرار على التغييرات

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

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

طريقتان لتعديل أي شيء

لديك دائمًا كلتا الطريقتين:

1. تعديل الملف مباشرة. المُصنَّفات هي ملفات Markdown عادية موجودة في openspec/changes/<name>/. افتح proposal.md أو design.md أو tasks.md، أو مواصفات دلتا (delta spec) الموجودة تحت specs/ في محرر النصوص وقم بالتغيير. لا شيء آخر مطلوب.

2. طلب من الذكاء الاصطناعي مراجعته. في الدردشة، قل ما تريد ببساطة: "حدّث الاقتراح لحذف فكرة التخزين المؤقت (caching) وإضافة قسم لحدود المعدل (rate-limit)"، أو "يجب أن يستخدم التصميم طابورًا (queue)، وليس الاستقصاء (polling)". يقوم الذكاء الاصطناعي بتعديل المُصنَّف لك، باستخدام بقية التغيير كسياق.

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

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

قم بالتحديث ببساطة. نفس التغيير، ولكن بصيغة محسّنة.

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

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

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

أنت: [عدّل design.md، أو أخبر الذكاء الاصطناعي:]
     حدّث design.md لاستخدام وظيفة خلفية (background job) بدلاً من استدعاء متزامن (synchronous call).

الذكاء الاصطناعي: تم تحديث design.md. لا تزال قائمة المهام مناسبة؛ هل تريدني أن أستمر في التطبيق؟

أنت: /opsx:apply

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

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

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

بشكل ملموس، بعد بعض عمل /opsx:apply:

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

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

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

يحدث هذا باستمرار وهو أمر طبيعي. لقد أجريت تعديلاً بسيطًا في محرر النصوص الخاص بك، والآن يتناقض الكود والمُصنَّفات. أعدهما إلى التزامن في الاتجاه الصحيح:

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

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

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

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

إذا لم يكن الاقتراح المُولَّد على المستوى المطلوب، فلديك ثلاث حركات جيدة:

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

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

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

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

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

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

ملاحظة حول المهام (Tasks)

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

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

• سير العمليات (Workflows) - الأنماط، بالإضافة إلى دليل اتخاذ القرار بين التحديث والبدء من جديد
• الاستكشاف أولاً (Explore First) - المكان الذي تعود إليه عندما تحتاج الفكرة إلى إعادة تفكير
• الأوامر (Commands) - /opsx:continue و /opsx:apply و /opsx:verify بالتفصيل
• المفاهيم: المُصنَّفات (Concepts: Artifacts) - ما هو الغرض من كل مُصنَّف