سير عمل OPSX

نرحب بملاحظاتكم على Discord.

ما هو؟

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

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

سير عمل OpenSpec القديم يعمل، لكنه مقيد:

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

يفتح 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، 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:
    - تضمين خطة استرجاع
    - تحديد الفرق المتأثرة
  specs:
    - استخدام تنسيق Given/When/Then للسيناريوهات
  design:
    - تضمين مخططات تسلسل للتدفقات المعقدة

حقول الإعدادات

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

آلية العمل

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

1. علامة واجهة سطر الأوامر (--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	مزامنة مواصفات التغيير الجزئية مع الفرع الرئيسي (سير العمل الافتراضي، اختياري)
/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 - نقوم بتخزين السمة في ملف تعريف ارتباط الآن

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

الانتهاء

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

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

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

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

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

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

السؤال هو: أي منها تغير، وإلى أي مدى؟

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

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

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

يضيق النطاق

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

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

• قاعدة الكود لا منظمة بالطريقة التي كنت تعتقدها
• إحدى التبعيات لا تعمل كما هو متوقع
• "استخدام متغيرات CSS" → "استخدام بادئة dark: من Tailwind بدلاً من ذلك"

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

تغيرت النية بشكل جذري

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

انفجر النطاق

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

الأصلي قابل للإنجاز

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

القواعد الإرشادية

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

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

المبدأ

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

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

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

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

ما هو المختلف؟

	القديم (/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 patterns)│   │
│   │      requires: [proposal]      ◄── يُفعّل بعد proposal               │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   محرك الرسم البياني للقطع الأثرية                                          │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  • فرز طوبولوجي (ترتيب حسب التبعيات)                                │   │
│   │  • كشف الحالة (وجود في نظام الملفات)                                │   │
│   │  • توليد تعليمات غنية (قوالب + سياق)                               │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   ملفات المهارات (.claude/skills/openspec-*/SKILL.md)                       │
│                                                                             │
│   • متوافق مع محررات متعددة (Claude Code, Cursor, Windsurf)                 │
│   • تدعم المهارات الاستعلام عبر واجهة سطر الأوامر (CLI) لاسترجاع البيانات المنظمة │
│   • قابلة للتخصيص بالكامل عبر ملفات المخططات                               │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

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

تشكل القطع الأثرية رسمًا بيانيًا موجهًا غير دوري (DAG). التبعيات هي ممكنات، وليست بوابات:

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

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

   BLOCKED ────────────────► READY ────────────────► DONE
      │                        │                       │
   تبعيات مفقودة          جميع التبعيات مكتملة       الملف موجود
                          │                       في نظام الملفات

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

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

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

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"]}│  │
  │  │    ]                                                               │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  الخطوة 2: الحصول على تعليمات غنية للقطعة الأثرية الجاهزة               │
  │  ┌────────────────────────────────────────────────────────────────────┐  │
  │  │  $ openspec instructions specs --change "add-auth" --json          │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "template": "# Specification\n\n## ADDED Requirements...",      │  │
  │  │    "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        # Added before proposal
    generates: research.md
    requires: []

  - id: proposal
    generates: proposal.md
    requires: [research]  # Now depends on research

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

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

   research ──► proposal ──► tasks

ملخص

Aspect	Legacy	OPSX
Templates	Hardcoded TypeScript	External YAML + Markdown
Dependencies	None (all at once)	DAG with topological sort
State	Phase-based mental model	Filesystem existence
Customization	Edit source, rebuild	Create schema.yaml
Iteration	Phase-locked	Fluid, edit anything
Editor Support	Tool-specific configurator/adapters	Single skills directory

المخططات

تحدد المخططات القطع الأثرية الموجودة وتبعياتها. المتاحة حالياً:

• 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.