استكشاف أولاً

/opsx:explore هو شريكك في التفكير. اعتمد عليه كلما واجهت مشكلة ولكن لم تكن لديك خطة بعد. إنه يحقق في قاعدة الكود الخاصة بك، ويوازن الخيارات معك، ويوضح ما تريده حقًا، وكل ذلك قبل إنشاء أي مُصَنَّف أو سطر من الكود. عندما تصبح الصورة واضحة، فإنه يسلم الأمر إلى /opsx:propose.

إذا أخذت عادة واحدة من هذه الوثائق، فلتكن هذه: عندما لا تكون متأكداً، استكشف قبل أن تقترح.

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

متى يجب الاستكشاف

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

• أنت تعرف المشكلة ولكن ليس لديك الحل. ("الصفحات بطيئة." "المصادقة فوضوية." "نستمر في الحصول على طلبات مكررة.")
• أنت تختار بين مقاربات مختلفة وتريد عرض المقايضات (tradeoffs) مقابل الكود الفعلي لديك.
• أنت جديد على قاعدة الكود وتحتاج إلى فهم كيفية عمل شيء ما قبل تغييره.
• المتطلبات غامضة وتريد صقلها قبل الالتزام بها.
• تشك في أن العمل أكبر أو أصغر مما يبدو وتريد تحديد نطاقه بصدق.

تخطَّ الاستكشاف فقط عندما تعرف بالضبط ما تريده وكيفية القيام به. في هذه الحالة، انتقل مباشرة إلى /opsx:propose.

ماذا يفعل (وما لا يفعله)

الاستكشاف هو محادثة، وليس مولداً.

ماذا يفعل:

• يقرأ ويبحث في قاعدة الكود الخاصة بك للإجابة على أسئلة حقيقية.
• يقارن الخيارات ويحدد المقايضات لكل منها.
• يرسم مخططات لجعل التصميم مفهوماً.
• يساعدك على تضييق فكرة غامضة إلى نطاق ملموس وقابل للبناء.
• ينتقل إلى /opsx:propose عندما تكون مستعداً.

ما لا يفعله:

• إنشاء مجلد تغييرات (change folder).
• كتابة أي مُصَنَّفات (لا اقتراح، ولا مواصفات، ولا تصميم، ولا مهام).
• كتابة أو تعديل الكود.

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

إنه مُثبَّت بالفعل

أخبار سارة: /opsx:explore مدمج في الملف التعريفي الافتراضي core، بجانب propose و apply و sync و archive. لست بحاجة إلى تمكين أي شيء. إذا كان OpenSpec مُعداً في مشروعك، فإن الاستكشاف جاهز في محادثة الذكاء الاصطناعي الخاصة بك. (كما هو الحال مع جميع أوامر /opsx:*، فأنت تكتبها في محادثة المساعد الخاص بك، وليس في الطرفية. راجع كيف تعمل الأوامر.)

مثال كامل

شاهد كيف تتحول قلق غامض إلى تغيير حاد وقابل للبناء.

You: /opsx:explore

AI:  What would you like to explore?

You: Our checkout sometimes creates duplicate orders. I don't know why
     and I don't know how to fix it safely.

AI:  Let me dig into the checkout path...
     [reads the order service, the payment webhook handler, and the
      client submit logic]

     Here's what I found. There are two ways a duplicate can happen:

     1. The client can submit twice (double-click, retry on slow network).
        Nothing debounces it.
     2. The payment webhook can fire more than once, and the handler
        creates an order each time. There's no idempotency key.

     Cause #2 is the dangerous one: it can charge and fulfill twice.

     Three ways to fix it, roughly in order of robustness:
     - Idempotency key on the order-creation endpoint (handles both causes)
     - Dedup on the webhook by payment-intent id (handles #2 only)
     - Client-side debounce (handles #1 only, papers over the real bug)

     Given your code already stores the payment-intent id, the
     idempotency-key approach is a small change with the biggest payoff.
     Want me to scope that?

You: Yes, let's do the idempotency key.

You: /opsx:propose add-order-idempotency-key

AI:  Created openspec/changes/add-order-idempotency-key/, with a proposal
     and delta spec grounded in what we just found. Ready for implementation.

لاحظ ما حدث. كانت نقطة البداية هي "هناك شيء خاطئ وأنا خائف من لمسه". حولت عشرون ثانية من الاستكشاف ذلك إلى سبب جذري مُسمّى، وثلاثة خيارات مصنفة، وتوصية مرتبطة بالكود الموجود، وتغيير دقيق. الاقتراح الذي يتبع هو حاد لأن التفكير حدث أولاً.

التسليم إلى propose

الاستكشاف لا يُؤرّش في أي شيء. عندما تكون مستعداً، فإنك تبدأ تغييرًا ببساطة، ويحمل الذكاء الاصطناعي السياق من محادثتك إلى المُصَنَّفات (artifacts).

explore  ──►  propose  ──►  apply  ──►  archive
 (think)     (agree)       (build)     (record)

يمكنك قول ذلك بلغة واضحة ("دعنا نحول هذا إلى تغيير") أو تشغيل /opsx:propose <name> مباشرة. في كلتا الحالتين، يصبح الاستكشاف الذي قمت به أساس الاقتراح، وليس مجرد محادثة عابرة.

إذا كنت تستخدم مجموعة الأوامر الموسعة، فيمكن للاستكشاف أن يسلم الأمر إلى /opsx:new بدلاً من ذلك، وذلك لإنشاء مُصَنَّفات خطوة بخطوة. راجع سير العمل.

نصائح لاستكشاف جيد

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

المقايضات الصادقة

ما تكسبه: يلتقط الاستكشاف التحولات الخاطئة في أرخص وقت ممكن، قبل وجود أي مُصَنَّف. وهو قوي بشكل خاص في الكود غير المألوف، حيث إن قدرة الذكاء الاصطناعي على قراءة النظام وتلخيصه توفر عليك فترة ما بعد الظهيرة من التنقيب العميق.

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

القاعدة العامة: كلما كانت المهمة أكثر غموضاً، زادت فائدة الاستكشاف. وكلما كانت المهمة أوضح، زادت قدرتك على الانتقال مباشرة إلى الاقتراح.

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

• الأوامر: /opsx:explore: المرجع الدقيق
• سير العمل: الاستكشاف كجزء من الحلقة اليومية
• أمثلة ووصفات: الاستكشاف في جولة شاملة
• البدء: دليل التغيير الأول، بما في ذلك الاستكشاف