سير عمل OPSX

نرحب بتعليقاتكم على ديسكورد.

ما هو؟

أصبح OPSX الآن سير العمل القياسي لـ OpenSpec.

إنه سير عمل مرن وتكراري لتغييرات OpenSpec. لم تعد هناك مراحل جامدة — بل مجرد إجراءات يمكنك تنفيذها في أي وقت.

لماذا هذا موجود

سير عمل OpenSpec القديم يعمل، لكنه مُقيَّد بشدة:

• التعليمات مكتوبة بشكل ثابت — مدفونة في TypeScript، لا يمكنك تغييرها
• كل شيء أو لا شيء — أمر واحد كبير ينشئ كل شيء، لا يمكنك اختبار الأجزاء بشكل منفصل
• هيكل ثابت — نفس سير العمل للجميع، بدون تخصيص
• صندوق أسود — عندما يكون مخرَج الذكاء الاصطناعي سيئًا، لا يمكنك تعديل الاستدعاءات (prompts)

OPSX يفتح هذا المجال. الآن يمكن لأي شخص:

1. تجربة التعليمات — عدّل قالبًا، وشاهد إذا كان الذكاء الاصطناعي يعمل بشكل أفضل
2. الاختبار بدقة — تحقق من تعليمات كل مُخرَج بشكل مستقل
3. تخصيص سير العمل — حدد المُخرَجات والتبعيات الخاصة بك
4. التكرار بسرعة — غيّر قالبًا، واختبر فورًا، بدون إعادة بناء

سير العمل القديم:                      OPSX:
┌────────────────────────┐           ┌────────────────────────┐
│  مُرمَّز في الحزمة      │           │  schema.yaml           │◄── أنت تعدّل هذا
│  (لا يمكن تغييره)      │           │  templates/*.md        │◄── أو هذا
│        ↓               │           │        ↓               │
│  انتظر إصدارًا جديدًا  │           │  تأثير فوري            │
│        ↓               │           │        ↓               │
│  أمل أن يكون أفضل      │           │  اختبره بنفسك          │
└────────────────────────┘           └────────────────────────┘

هذا مخصص للجميع:

• الفرق — أنشئ سير عمل يطابق طريقة عملك الفعلية
• المستخدمون المتقدمون — عدّل الاستدعاءات للحصول على مُخرَجات ذكاء اصطناعي أفضل لقاعدة الأكواد الخاصة بك
• مساهمو OpenSpec — جرّبوا أساليب جديدة بدون إصدارات

ما زلنا جميعًا نتعلم ما هو الأفضل. OPSX يتيح لنا التعلم معًا.

تجربة المستخدم

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

نهج OPSX:

• إجراءات، وليس مراحل — أنشئ، نفّذ، حدّث، أرشِف — قم بأي منها في أي وقت
• التبعيات هي عوامل تمكين — تُظهر ما هو ممكن، وليس ما هو مطلوب بعد ذلك

  proposal ──→ specs ──→ design ──→ tasks ──→ implement

الإعداد

# تأكد من تثبيت openspec — يتم إنشاء المهارات تلقائيًا
openspec init

ينشئ هذا مهارات في .claude/skills/ (أو ما يعادله) تكتشفها مساعدات البرمجة بالذكاء الاصطناعي تلقائيًا.

بشكل افتراضي، يستخدم OpenSpec ملف تعريف سير العمل core (propose, explore, apply, update, sync, archive). إذا كنت تريد أوامر سير العمل الموسعة (new, continue, ff, verify, bulk-archive, onboard)، فقم بتكوينها باستخدام openspec config profile وطبّقها باستخدام openspec update.

أثناء الإعداد، ستتم مطالبتك بإنشاء إعداد مشروع (openspec/config.yaml). هذا اختياري لكنه مُوصى به.

إعداد المشروع

يتيح لك إعداد المشروع تعيين القيم الافتراضية وحقن سياق خاص بالمشروع في جميع المُخرَجات.

إنشاء الإعداد

يتم إنشاء الإعداد أثناء openspec init، أو يدويًا:

# openspec/config.yaml
schema: spec-driven

context: |
  Tech stack: TypeScript, React, Node.js
  API conventions: RESTful, JSON responses
  Testing: Vitest for unit tests, Playwright for e2e
  Style: ESLint with Prettier, strict TypeScript

rules:
  proposal:
    - Include rollback plan
    - Identify affected teams
  specs:
    - Use Given/When/Then format for scenarios
  design:
    - Include sequence diagrams for complex flows

حقول الإعداد

الحقل	النوع	الوصف
schema	string	المخطط الافتراضي للتغييرات الجديدة (مثل spec-driven)
context	string	سياق المشروع الذي يتم حقنه في جميع تعليمات المُخرَجات
rules	object	قواعد لكل مُخرَج، مرتبة حسب معرف المُخرَج

كيفية العمل

أولوية المخطط (من الأعلى إلى الأدنى):

1. علامة CLI (--schema <name>)
2. بيانات التغيير (.openspec.yaml في دليل التغيير)
3. إعداد المشروع (openspec/config.yaml)
4. الافتراضي (spec-driven)

حقن السياق:

• يتم إضافة السياق في بداية تعليمات كل مُخرَج
• يُغلَّف بوسوم <context>...</context>
• يساعد الذكاء الاصطناعي على فهم اصطلاحات مشروعك

حقن القواعد:

• يتم حقن القواعد فقط للمُخرَجات المطابقة
• تُغلَّف بوسوم <rules>...</rules>
• تظهر بعد السياق، قبل القالب

معرفات المُخرَجات حسب المخطط

spec-driven (الافتراضي):

• proposal — اقتراح التغيير
• specs — المواصفات
• design — التصميم التقني
• tasks — مهام التنفيذ

التحقق من الإعداد

• معرفات المُخرَجات غير المعروفة في rules تولّد تحذيرات
• يتم التحقق من أسماء المخططات مقابل المخططات المتاحة
• حجم السياق محدود بـ 50 كيلوبايت
• يتم الإبلاغ عن YAML غير صالح مع أرقام الأسطر

استكشاف الأخطاء وإصلاحها

"معرف مُخرَج غير معروف في القواعد: X"

• تحقق من أن معرفات المُخرَجات تطابق مخططك (انظر القائمة أعلاه)
• شغّل openspec schemas --json لرؤية معرفات المُخرَجات لكل مخطط

عدم تطبيق الإعداد:

• تأكد من أن الملف في openspec/config.yaml (وليس .yml)
• تحقق من صحة صياغة YAML باستخدام أداة تحقق
• تغييرات الإعداد تُطبَّق فورًا (لا حاجة لإعادة تشغيل)

السياق كبير جدًا:

• السياق محدود بـ 50 كيلوبايت
• لخّصه أو اربطه بوثائق خارجية بدلاً من ذلك

الأوامر

الأمر	ما يفعله
/opsx:propose	إنشاء تغيير وتوليد مُخرَجات التخطيط في خطوة واحدة (المسار السريع الافتراضي)
/opsx:explore	التفكير في الأفكار، والتحقيق في المشكلات، وتوضيح المتطلبات
/opsx:new	بدء هيكل تغيير جديد (سير عمل موسّع)
/opsx:continue	إنشاء المُخرَج التالي (سير عمل موسّع)
/opsx:ff	تمرير سريع لمُخرَجات التخطيط (سير عمل موسّع)
/opsx:apply	تنفيذ المهام، مع تحديث المُخرَجات حسب الحاجة
/opsx:update	مراجعة مُخرَجات تخطيط التغيير والحفاظ على تماسكها
/opsx:verify	التحقق من التنفيذ مقابل المُخرَجات (سير عمل موسّع)
/opsx:sync	دمج المواصفات التفصيلية (delta specs) في المواصفات الرئيسية (اختياري)
/opsx:archive	الأرشفة عند الانتهاء
/opsx:bulk-archive	أرشفة تغييرات مكتملة متعددة (سير عمل موسّع)
/opsx:onboard	جولة إرشادية لتغيير شامل من البداية إلى النهاية (سير عمل موسّع)

الاستخدام

استكشاف فكرة

/opsx:explore

فكّر في الأفكار، وحقق في المشكلات، وقارن الخيارات. لا حاجة لهيكل محدد — مجرد شريك تفكير. عندما تتبلور الأفكار، انتقل إلى /opsx:propose (الافتراضي) أو /opsx:new//opsx:ff (الموسّع).

بدء تغيير جديد

/opsx:propose

ينشئ التغيير ويولّد مُخرَجات التخطيط المطلوبة قبل التنفيذ.

إذا فعّلت سير العمل الموسّع، يمكنك بدلاً من ذلك استخدام:

/opsx:new        # الهيكل فقط
/opsx:continue   # إنشاء مُخرَج واحد في كل مرة
/opsx:ff         # إنشاء جميع مُخرَجات التخطيط دفعة واحدة

إنشاء المُخرَجات

/opsx:continue

يعرض ما هو جاهز للإنشاء بناءً على التبعيات، ثم يُنشئ مُخرَجًا واحدًا. استخدمه مرارًا لبناء تغييرك تدريجيًا.

/opsx:ff add-dark-mode

ينشئ جميع مُخرَجات التخطيط دفعة واحدة. استخدمه عندما تكون لديك صورة واضحة عما تبنيّه.

التنفيذ (الجزء المرن)

/opsx:apply

يعمل عبر المهام، ويحددها كمكتملة أثناء تقدمك. إذا كنت تدير تغييرات متعددة، يمكنك تشغيل /opsx:apply <name>؛ وإلا، يجب أن يستنتج من المحادثة ويطلب منك الاختيار إذا لم يستطع تحديد ذلك.

تحديث تغيير

/opsx:update add-dark-mode - we're storing the theme in a cookie now

يراجع مُخرَجات التخطيط الحالية للتغيير ويحافظ على تماسكها — في أي اتجاه (قد ينعكس تعديل التصميم على الاقتراح). مُخرَجات التخطيط فقط: لا يعدّل الكود أبدًا، ولا ينشئ مُخرَجات مفقودة أبدًا (ذلك /opsx:continue). يتم تأكيد كل تعديل معك أولاً. إذا كان التغيير قد نُفِّذ بالفعل، فإنه يوصي بـ /opsx:apply حتى يواكب الكود الخطة المنقحة. إذا غيّر مراجعتك نية التغيير، فابدأ من جديد بدلاً من ذلك — انظر متى تقوم بالتحديث مقابل البدء من جديد.

مزامنة المواصفات التفصيلية (delta specs)

/opsx:sync

يدمج المواصفات التفصيلية للتغيير الحالي في openspec/specs/ الرئيسية دون أرشفة — يظل التغيير نشطًا. يطبّق الدلتا بأكملها: يُحذف متطلب تحت ## REMOVED من المواصفات الرئيسية، ويُعاد تسمية المُعاد تسميته في مكانه، بينما يُترك المحتوى الذي لا تذكره الدلتا دون تغيير. المزامنة اختيارية — تطلب منك الأرشفة المزامنة أولاً إذا لم تقم بذلك. استخدمها عندما تريد تحديث المواصفات الرئيسية قبل الأرشفة، أو عندما يحتاج تغيير موازٍ إلى البناء على مواصفات أضافها هذا التغيير للتو، أو عندما تريد مراجعة المواصفات الرئيسية المدمجة قبل الأرشفة.

إنهاء العمل

/opsx:archive   # الانتقال إلى الأرشفة عند الانتهاء (تطلب مزامنة المواصفات إذا لزم الأمر)

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

يمكنك دائمًا تعديل اقتراحك أو مواصفاتك قبل التنفيذ. لكن متى يصبح التحسين "عملًا مختلفًا"؟

ما يلتقطه الاقتراح

يحدد الاقتراح ثلاثة أشياء:

1. النية — ما هي المشكلة التي تحلها؟
2. النطاق — ما هو داخل/خارج الحدود؟
3. النهج — كيف ستحلها؟

السؤال هو: أيٌّ منها تغيّر، وبأي مقدار؟

قم بتحديث التغيير الحالي عندما:

نفس النية، تنفيذ مُحسَّن

• تكتشف حالات حافة لم تأخذها في الاعتبار
• يحتاج النهج إلى تعديل لكن الهدف لم يتغير
• يكشف التنفيذ أن التصميم كان غير دقيق قليلاً

النطاق يضيق

• تدرك أن النطاق الكامل كبير جدًا، وتريد تسليم MVP أولاً
• "أضف الوضع الداكن" → "أضف زر تبديل الوضع الداكن (تفضيل النظام في الإصدار 2)"

تصحيحات مدفوعة بالتعلم

• قاعدة الأكواد ليست منظمة كما ظننت
• تبعية لا تعمل كما هو متوقع
• "استخدم متغيرات CSS" → "استخدم بادئة Tailwind للوضع الداكن بدلاً من ذلك"

ابدأ تغييرًا جديدًا عندما:

النية تغيّرت جوهريًا

• المشكلة نفسها أصبحت مختلفة الآن
• "أضف الوضع الداكن" → "أضف نظام سمات شامل بألوان وخطوط وتباعد مخصص"

النطاق انفجر

• نما التغيير كثيرًا لدرجة أنه أصبح عملًا مختلفًا جوهريًا
• سيكون الاقتراح الأصلي غير معروف بعد التحديثات
• "إصلاح خطأ تسجيل الدخول" → "إعادة كتابة نظام المصادقة"

الأصلي قابل للإكمال

• يمكن وضع علامة "مكتمل" على التغيير الأصلي
• العمل الجديد قائم بذاته، وليس تحسينًا
• أكمل "إضافة نسخة MVP للوضع الداكن" → أرشفة → تغيير جديد "تحسين الوضع الداكن"

الاستدلالات

                        ┌─────────────────────────────────────┐
                        │     هل هذا هو نفس العمل؟            │
                        └──────────────┬──────────────────────┘
                                       │
                    ┌──────────────────┼──────────────────┐
                    │                  │                  │
                    ▼                  ▼                  ▼
             نفس النية؟         تداخل >50%؟        هل يمكن أن يكون
             نفس المشكلة؟       نفس النطاق؟        الأصلي "مكتملًا"
                    │                  │          بدون هذه التغييرات؟
                    │                  │                  │
          ┌────────┴────────┐  ┌──────┴──────┐   ┌───────┴───────┐
          │                 │  │             │   │               │
         YES               NO YES           NO  NO              YES
          │                 │  │             │   │               │
          ▼                 ▼  ▼             ▼   ▼               ▼
       UPDATE            NEW  UPDATE       NEW  UPDATE          NEW

الاختبار	تحديث	تغيير جديد
الهوية	"نفس الشيء، مُحسَّن"	"عمل مختلف"
تداخل النطاق	>50% تداخل	<50% تداخل
الإكمال	لا يمكن أن يكون "مكتملًا" بدون تغييرات	يمكن إنهاء الأصلي، والعمل الجديد قائم بذاته
القصة	سلسلة التحديثات تحكي قصة متماسكة	الترقيعات ستُربك أكثر مما توضح

المبدأ

التحديث يحافظ على السياق. التغيير الجديد يوفر الوضوح.

اختر التحديث عندما يكون تاريخ تفكيرك ذا قيمة. اختر الجديد عندما يكون البدء من جديد أوضح من الترقيع.

فكر في الأمر مثل فروع git:

• استمر في الالتزام (committing) أثناء العمل على نفس الميزة
• ابدأ فرعًا جديدًا عندما يكون عملًا جديدًا حقًا
• أحيانًا ادمج ميزة جزئية وابدأ من جديد للمرحلة الثانية

ما الجديد؟

	القديم (/openspec:proposal)	OPSX (/opsx:*)
الهيكل	مستند مقترح واحد ضخم	عناصر منفصلة ذات تبعيات
سير العمل	مراحل خطية: تخطيط → تنفيذ → أرشفة	إجراءات مرنة — قم بأي شيء في أي وقت
التكرار	صعب العودة إلى الوراء	حدّث العناصر كلما تعلمت أكثر
التخصيص	هيكل ثابت	قائم على المخطط (عرّف عناصرك الخاصة)

الرؤية الأساسية: العمل ليس عملية خطية. يتوقف OPSX عن التظاهر بأنه كذلك.

استكشاف معمقي للعمارة

يشرح هذا القسم كيفية عمل OPSX من الداخل وكيف يقارن بالعملية التقليدية. تستخدم الأمثلة في هذا القسم مجموعة الأوامر الموسعة (new، continue، إلخ)؛ حيث يمكن لمستخدمي core الافتراضيين ربط نفس التدفق بـ propose → apply → sync → archive.

الفلسفة: المراحل مقابل الإجراءات

┌─────────────────────────────────────────────────────────────────────────────┐
│                         العملية التقليدية                                      │
│                    (مقيدة بالمرحلة، الكل أو لا شيء)                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐             │
│   │   التخطيط    │ ───► │ التنفيذ     │ ───► │ الأرشفة     │             │
│   │   المرحلة    │      │   المرحلة    │      │   المرحلة    │             │
│   └──────────────┘      └──────────────┘      └──────────────┘             │
│         │                     │                     │                       │
│         ▼                     ▼                     ▼                       │
│   /openspec:proposal   /openspec:apply      /openspec:archive              │
│                                                                             │
│   • ينشئ جميع العناصر مرة واحدة                                           │
│   • لا يمكن العودة لتحديث المواصفات أثناء التنفيذ                          │
│   • بوابات المرحلة تفرض تسلسلاً خطياً                                     │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────────────────────┐
│                            تدفق OPSX                                          │
│                      (إجراءات مرنة، تكرارية)                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│              ┌────────────────────────────────────────────┐                 │
│              │           الإجراءات (وليس المراحل)          │                 │
│              │                                            │                 │
│              │   new ◄──► continue ◄──► apply ◄──► archive │                 │
│              │    │          │           │           │    │                 │
│              │    └──────────┴───────────┴───────────┘    │                 │
│              │              بأي ترتيب                     │                 │
│              └────────────────────────────────────────────┘                 │
│                                                                             │
│   • إنشاء العناصر واحداً تلو الآخر أو التقدم بسرعة                           │
│   • تحديث المواصفات/التصميم/المهام أثناء التنفيذ                              │
│   • التبعيات تمكّن التقدم، ولا توجد مراحل                                    │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

عمارة المكونات

تستخدم العملية التقليدية قوالب ثابتة مكتوبة بلغة TypeScript:

┌─────────────────────────────────────────────────────────────────────────────┐
│                   مكونات العملية التقليدية                                   │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   قوالب ثابتة (سلاسل نصية TypeScript)                                       │
│                    │                                                        │
│                    ▼                                                        │
│   مهيئات/محولات خاصة بالأدوات                                                │
│                    │                                                        │
│                    ▼                                                        │
│   ملفات الأوامر المولدة (.claude/commands/openspec/*.md)                  │
│                                                                             │
│   • هيكل ثابت، بدون وعي بالعناصر                                            │
│   • التغيير يتطلب تعديل الكود وإعادة البناء                                  │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

تستخدم OPSX مخططات خارجية ومحرك رسم بياني للتبعيات:

┌─────────────────────────────────────────────────────────────────────────────┐
│                         مكونات OPSX                                          │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   تعريفات المخطط (YAML)                                                    │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  name: spec-driven                                                  │   │
│   │  artifacts:                                                         │   │
│   │    - id: proposal                                                   │   │
│   │      generates: proposal.md                                         │   │
│   │      requires: []              ◄── التبعيات                         │   │
│   │    - id: specs                                                      │   │
│   │      generates: specs/**/*.md  ◄── أنماط Glob                       │   │
│   │      requires: [proposal]      ◄── يتم التمكين بعد proposal        │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   محرك رسم العناصر البياني                                                   │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  • الترتيب الطوبولوجي (ترتيب التبعيات)                               │   │
│   │  • كشف الحالة (وجود نظام الملفات)                                    │   │
│   │  • توليد تعليمات غنية (قوالب + سياق)                                │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   ملفات المهارات (.claude/skills/openspec-*/SKILL.md)                      │
│                                                                             │
│   • متوافقة عبر المحررات (Claude Code, Cursor, Devin)                       │
│   • المهارات تستعلم CLI للحصول على بيانات مهيكلة                            │
│   • قابلة للتخصيص بالكامل عبر ملفات المخطط                                 │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

نموذج الرسم البياني للتبعيات

تشكل العناصر رسماً بيانياً موجهاً غير دائري (DAG). التبعيات هي مُمَكِّنات، وليست بوابات:

                              proposal
                             (عقدة الجذر)
                                  │
                    ┌─────────────┴─────────────┐
                    │                           │
                    ▼                           ▼
                 specs                       design
              (يتطلب:                  (يتطلب:
               proposal)                   proposal)
                    │                           │
                    └─────────────┬─────────────┘
                                  │
                                  ▼
                               tasks
                           (يتطلب:
                           specs, design)
                                  │
                                  ▼
                          ┌──────────────┐
                          │ مرحلة التطبيق  │
                          │ (يتطلب:      │
                          │  tasks)      │
                          └──────────────┘

انتقالات الحالة:

   محظور ────────────────► جاهز ────────────────► مكتمل
      │                        │                       │
   تبعيات مفقودة            جميع التبعيات           الملف موجود
                           مكتملة                   على نظام الملفات

تدفق المعلومات

العملية التقليدية — يتلقى الوكيل تعليمات ثابتة:

  المستخدم: "/openspec:proposal"
           │
           ▼
  ┌─────────────────────────────────────────┐
  │  تعليمات ثابتة:                         │
  │  • إنشاء proposal.md                    │
  │  • إنشاء tasks.md                       │
  │  • إنشاء design.md                      │
  │  • إنشاء ملفات مواصفات delta           │
  │                                         │
  │  لا يوجد وعي بما هو موجود أو            │
  │  التبعيات بين العناصر                   │
  └─────────────────────────────────────────┘
           │
           ▼
  ينشئ الوكيل جميع العناصر دفعة واحدة

OPSX — يستعلم الوكيل للحصول على سياق غني:

  المستخدم: "/opsx:continue"
           │
           ▼
  ┌──────────────────────────────────────────────────────────────────────────┐
  │  الخطوة 1: استعلام عن الحالة الحالية                                     │
  │  ┌────────────────────────────────────────────────────────────────────┐  │
  │  │  $ openspec status --change "add-auth" --json                      │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "artifacts": [                                                  │  │
  │  │      {"id": "proposal", "status": "done"},                         │  │
  │  │      {"id": "specs", "status": "ready"},      ◄── الأول الجاهز     │  │
  │  │      {"id": "design", "status": "ready"},                          │  │
  │  │      {"id": "tasks", "status": "blocked",                          │  │
  │  │       "missingDeps": ["specs", "design"]}                          │  │
  │  │    ]                                                               │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  الخطوة 2: الحصول على تعليمات غنية للعنصر الجاهز                         │
  │  ┌────────────────────────────────────────────────────────────────────┐  │
  │  │  $ openspec instructions specs --change "add-auth" --json          │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "template": "# المواصفات\n\n## متطلبات مُضافة...",              │  │
  │  │    "dependencies": [{"id": "proposal", "path": "...", "done": true}│  │
  │  │    "unlocks": ["tasks"]                                            │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  الخطوة 3: قراءة التبعيات → إنشاء عنصر واحد → عرض ما تم فتحه             │
  └──────────────────────────────────────────────────────────────────────────┘

نموذج التكرار

العملية التقليدية — صعب التكرار فيها:

  ┌─────────┐     ┌─────────┐     ┌─────────┐
  │/proposal│ ──► │ /apply  │ ──► │/archive │
  └─────────┘     └─────────┘     └─────────┘
       │               │
       │               ├── "انتظر، التصميم خاطئ"
       │               │
       │               ├── الخيارات:
       │               │   • تحرير الملفات يدوياً (يكسر السياق)
       │               │   • التخلي والبدء من جديد
       │               │   • الاستمرار وإصلاح الأمر لاحقاً
       │               │
       │               └── لا توجد آلية رسمية للعودة للخلف
       │
       └── ينشئ جميع العناصر دفعة واحدة

OPSX — تكرار طبيعي:

  /opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
      │                │                  │
      │                │                  ├── "التصميم خاطئ"
      │                │                  │
      │                │                  ▼
      │                │            فقط قم بتحرير design.md
      │                │            واستمر!
      │                │                  │
      │                │                  ▼
      │                │         سيقوم /opsx:apply بأخذ
      │                │         حيث توقفت
      │                │
      │                └── ينشئ عنصراً واحداً، ويعرض ما تم فتحه
      │
      └── يهيئ التغيير، وينتظر التوجيه

المخططات المخصصة

أنشئ عمليات عمل مخصصة باستخدام أوامر إدارة المخطط:

# إنشاء مخطط جديد من الصفر (تفاعلي)
openspec schema init my-workflow

# أو نسخ مخطط موجود كنقطة انطلاق
openspec schema fork spec-driven my-workflow

# التحقق من صحة هيكل المخطط الخاص بك
openspec schema validate my-workflow

# معرفة مصدر حل المخطط (مفيد لتصحيح الأخطاء)
openspec schema which my-workflow

يتم تخزين المخططات في openspec/schemas/ (محلي للمشروع، خاضع للتحكم بالإصدار) أو ~/.local/share/openspec/schemas/ (عام للمستخدم).

هيكل المخطط:

openspec/schemas/research-first/
├── schema.yaml
└── templates/
    ├── research.md
    ├── proposal.md
    └── tasks.md

مثال لملف schema.yaml:

name: research-first
artifacts:
  - id: research        # يُضاف قبل proposal
    generates: research.md
    requires: []

  - id: proposal
    generates: proposal.md
    requires: [research]  # يعتمد الآن على research

  - id: tasks
    generates: tasks.md
    requires: [proposal]

الرسم البياني للتبعيات:

   research ──► proposal ──► tasks

الملخص

الجانب	التقليدي	OPSX
القوالب	TypeScript ثابت	YAML و Markdown خارجي
التبعيات	لا توجد (كل شيء دفعة واحدة)	DAG مع ترتيب طوبولوجي
الحالة	نموذج ذهني قائم على المراحل	وجود ملف على نظام الملفات
التخصيص	تعديل المصدر، إعادة البناء	إنشاء schema.yaml
التكرار	مقيد بالمرحلة	مرن، تحرير أي شيء
دعم المحرر	مهيئ/محولات خاصة بالأداة	دليل مهارات واحد

المخططات

المخططات تُعرّف المخرجات الموجودة وتبعياتها. المتاح حاليًا:

• spec-driven (الافتراضي): proposal → specs → design → tasks

# قائمة المخططات المتاحة
openspec schemas

# عرض جميع المخططات مع مصادر حلّها
openspec schema which --all

# إنشاء مخطط جديد تفاعليًا
openspec schema init my-workflow

# تفرّع مخطط موجود للتخصيص
openspec schema fork spec-driven my-workflow

# التحقق من بنية المخطط قبل الاستخدام
openspec schema validate my-workflow

نصائح

• استخدم /opsx:explore للتفكير في فكرة قبل الالتزام بتغيير
• استخدم /opsx:ff عندما تعرف ما تريد، و/opsx:continue عند الاستكشاف
• أثناء /opsx:apply، إذا كان هناك خطأ — أصلح المخرج ثم تابع
• تتبّع تقدم المهام عبر مربعات الاختيار في tasks.md
• تحقق من الحالة في أي وقت: openspec status --change "name"

الملاحظات

هذا غير مصقول. وهذا مقصود — نحن نتعلم ما الذي يعمل.

وجدت خطأ؟ لديك أفكار؟ انضم إلينا على Discord أو افتح مشكلة على GitHub.