استكشف أولاً

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

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

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

متى تستكشف

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

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

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

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

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

هو يفعل:

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

لا يفعل:

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

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

مثبت بالفعل

الأخبار الجيدة: يأتي /opsx:explore ضمن ملف التعريف الأساسي (core) الافتراضي، جنباً إلى جنب مع propose و apply و update و 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.

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

التسليم إلى الاقتراح

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

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

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

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

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

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

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

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

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

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

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

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