سير عمل OPSX
يُرحب بالتعليقات على Discord.
ما هو؟
يُعد OPSX الآن سير العمل القياسي لـ OpenSpec.
إنه سير عمل سلس ومتكرر لإجراء تغييرات على OpenSpec. لا مزيد من المراحل الجامدة — فقط إجراءات يمكنك تنفيذها في أي وقت.
لماذا تم إنشاء هذا
سير عمل OpenSpec القديم يعمل، لكنه مقيد:
- التعليمات مُثبتة مسبقاً — مدفونة في TypeScript، لا يمكنك تغييرها
- الكل أو لا شيء — أمر واحد كبير ينشئ كل شيء، لا يمكنك اختبار أجزاء فردية
- هيكل ثابت — نفس سير العمل للجميع، بدون تخصيص
- صندوق أسود — عندما تكون مخرجات الذكاء الاصطناعي سيئة، لا يمكنك تعديل المطالبات
OPSX يفتحه. الآن يمكن لأي شخص:
- التجربة مع التعليمات — تعديل قالب، ورؤية ما إذا كان الذكاء الاصطناعي يعمل بشكل أفضل
- الاختبار بشكل تفصيلي — التحقق من تعليمات كل مُنتَج بشكل مستقل
- تخصيص سير العمل — تحديد المنتجات والاعتمادية الخاصة بك
- التنقيح بسرعة — تغيير قالب، واختباره فوراً، بدون إعادة بناء
Legacy workflow: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Hardcoded in package │ │ schema.yaml │◄── You edit this
│ (can't change) │ │ templates/*.md │◄── Or this
│ ↓ │ │ ↓ │
│ Wait for new release │ │ Instant effect │
│ ↓ │ │ ↓ │
│ Hope it's better │ │ Test it yourself │
└────────────────────────┘ └────────────────────────┘هذا للجميع:
- الفريق — إنشاء سير عمل يتناسب مع طريقة عملك الفعلية
- المستخدمون المتقدمون — تعديل المطالبات للحصول على مخرجات ذكاء اصطناعي أفضل لقاعدة الكود الخاصة بك
- المساهمون في OpenSpec — التجربة مع مناهج جديدة بدون إصدارات
نحن جميعنا لا نزال نتعلم ما هو الأفضل. يتيح لنا OPSX التعلم معًا.
تجربة المستخدم
المشكلة في سير العمل الخطي: أنت "في مرحلة التخطيط"، ثم "في مرحلة التنفيذ"، ثم "تم". لكن العمل الحقيقي لا يعمل بهذه الطريقة. تنفذ شيئًا ما، وتكشف أن تصميمك كان خاطئًا، وتحتاج إلى تحديث المواصفات، وتواصل التنفيذ. المراحل الخطية تتعارض مع الطريقة التي يحدث بها العمل فعليًا.
نهج OPSX:
- إجراءات، وليس مراحل — إنشاء، تنفيذ، تحديث، أرشفة — قم بأي منها في أي وقت
- الاعتمادية هي مُمكّنات — تُظهر ما هو ممكن، وليس ما هو مطلوب التالي
proposal ──→ specs ──→ design ──→ tasks ──→ implementالإعداد
bash
# Make sure you have openspec installed — skills are automatically generated
openspec initيقوم هذا بإنشاء مهارات في .claude/skills/ (أو ما يعادلها) يكتشفها مساعدو البرمجة بالذكاء الاصطناعي تلقائيًا.
بشكل افتراضي، يستخدم OpenSpec ملف تعريف سير العمل core (propose، explore، apply، archive). إذا كنت تريد أوامر سير العمل الموسعة (new، continue، ff، verify، sync، bulk-archive، onboard)، قم بتكوينها باستخدام openspec config profile وتطبيقها باستخدام openspec update.
أثناء الإعداد، سيُطلب منك إنشاء ملف تكوين المشروع (openspec/config.yaml). هذا اختياري لكنه موصى به.
تكوين المشروع
يتيح لك تكوين المشروع تعيين القيم الافتراضية وحقن سياق خاص بالمشروع في جميع المنتجات.
إنشاء التكوين
يتم إنشاء التكوين أثناء openspec init، أو يدويًا:
yaml
# 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 | نص | المخطط الافتراضي للتغييرات الجديدة (مثل spec-driven) |
context | نص | سياق المشروع المحقون في تعليمات كل منتج |
rules | كائن | قواعد لكل منتج، مُرقمة بمعرّف المنتج |
كيف يعمل
أولوية المخطط (من الأعلى إلى الأدنى):
- علامة سطر الأوامر (
--schema <name>) - بيانات التغيير الوصفية (
.openspec.yamlفي دليل التغيير) - تكوين المشروع (
openspec/config.yaml) - الافتراضي (
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:verify | التحقق من التنفيذ مقابل المنتجات (سير العمل الموسّع) |
/opsx:sync | مزامنة مواصفات الدلتا مع الرئيسية (سير العمل الموسّع، اختياري) |
/opsx:archive | الأرشفة عند الانتهاء |
/opsx:bulk-archive | أرشفة تغييرات مكتملة متعددة (سير العمل الموسّع) |
/opsx:onboard | جولة إرشادية عبر تغيير شامل (سير العمل الموسّع) |
الاستخدام
استكشاف فكرة
/opsx:exploreالتفكير في الأفكار، واستكشاف المشاكل، ومقارنة الخيارات. لا يتطلب هيكلًا - مجرد شريك تفكير. عندما تتبلور الأفكار، انتقل إلى /opsx:propose (الافتراضي) أو /opsx:new//opsx:ff (الموسّع).
بدء تغيير جديد
/opsx:proposeإنشاء التغيير وتوليد منتجات التخطيط اللازمة قبل التنفيذ.
إذا قمت بتفعيل سير العمل الموسّع، يمكنك بدلاً من ذلك استخدام:
text
/opsx:new # scaffold only
/opsx:continue # create one artifact at a time
/opsx:ff # create all planning artifacts at onceإنشاء المنتجات
/opsx:continueيُظهر ما هو جاهز للإنشاء بناءً على الاعتمادية، ثم يُنشئ منتجًا واحدًا. استخدمه بشكل متكرر لبناء تغييرك تدريجيًا.
/opsx:ff add-dark-modeيُنشئ جميع منتجات التخطيط دفعة واحدة. استخدمه عندما يكون لديك صورة واضحة عما تقوم ببنائه.
التنفيذ (الجزء المرن)
/opsx:applyيعمل من خلال المهام، ويقوم بتحديد اكتمالها أثناء سيرك. إذا كنت تتعامل مع تغييرات متعددة، يمكنك تشغيل /opsx:apply <name>؛ وإلا يجب أن يستنتج من المحادثة ويطلب منك الاختيار إذا لم يتمكن من التعرف عليها.
الإنهاء
/opsx:archive # Move to archive when done (prompts to sync specs if needed)متى التحديث مقابل البدء من جديد
يمكنك دائمًا تعديل اقتراحك أو مواصفاتك قبل التنفيذ. لكن متى يصبح التنقيح "عملًا مختلفًا"؟
ما يلتقطه الاقتراح
يُحدد الاقتراح ثلاثة أشياء:
- النية — ما هي المشكلة التي تحاول حلها؟
- النطاق — ما هو داخل/خارج النطاق؟
- المنهج — كيف ستقوم بحلها؟
السؤال هو: ماذا تغير، وبأي مقدار؟
قم بتحديث التغيير الحالي عندما:
نفس النية، تنفيذ مُنقّح
- تكتشف حالات حدودية لم تكن قد فكرت فيها
- يحتاج المنهج إلى تعديل لكن الهدف لم يتغير
- يكشف التنفيذ أن التصميم كان خاطئًا قليلاً
النطاق يتقلص
- تدرك أن النطاق الكامل كبير جدًا، وتريد إطلاق MVP أولاً
- "إضافة الوضع الداكن" → "إضافة مفتاح الوضع الداكن (تفضيل النظام في الإصدار 2)"
تصحيحات مدفوعة بالتعلم
- قاعدة الكود غير منظمة كما ظننت
- تبعية لا تعمل كما هو متوقع
- "استخدام متغيرات CSS" → "استخدام بادئة
dark:من Tailwind بدلاً من ذلك"
ابدأ تغييرًا جديدًا عندما:
النية تغيرت بشكل جوهري
- المشكلة نفسها مختلفة الآن
- "إضافة الوضع الداكن" → "إضافة نظام سمات شامل بألوان وخطوط ومسافات مخصصة"
النطاق انفجر
- نما التغيير لدرجة أنه عمل مختلف في جوهره
- الاقتراح الأصلي سيكون غير قابل للتعرف عليه بعد التحديثات
- "إصلاح خطأ تسجيل الدخول" → "إعادة كتابة نظام المصادقة"
الأصلي قابل للإكمال
- يمكن وضع علامة "مكتمل" على التغيير الأصلي
- العمل الجديد واقف بذاته، وليس ترقية
- أكمل "إضافة الوضع الداكن MVP" → أرشفة → تغيير جديد "تحسين الوضع الداكن"
المبادئ التوجيهية
┌─────────────────────────────────────┐
│ Is this the same work? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Same intent? >50% overlap? Can original
Same problem? Same scope? be "done" without
│ │ these changes?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YES NO YES NO NO YES
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
UPDATE NEW UPDATE NEW UPDATE NEW| الاختبار | تحديث | تغيير جديد |
|---|---|---|
| الهوية | "نفس الشيء، مُنقّح" | "عمل مختلف" |
| تداخل النطاق | تداخل >50% | تداخل <50% |
| الاكتمال | لا يمكن أن يكون "مكتملًا" بدون التغييرات | يمكن إنهاء الأصلي، العمل الجديد واقف بذاته |
| القصة | سلسلة التحديث تروي قصة متماسكة | الترقيات ستربك أكثر مما توضح |
المبدأ
التحديث يحافظ على السياق. التغيير الجديد يوفر الوضوح.
اختر التحديث عندما يكون تاريخ تفكيرك ذا قيمة. اختر الجديد عندما يكون البدء من جديد أوضح من الترقيات.
فكّر في ذلك مثل فروع git:
- واصل الإلتزام أثناء العمل على نفس الميزة
- ابدأ فرعًا جديدًا عندما يكون عملًا جديدًا حقيقيًا
- أحيانًا ادمج ميزة جزئية وابدأ من جديد للمرحلة الثانية
ما الذي يختلف؟
النظام القديم (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| الهيكل | مستند اقتراح واحد كبير | مكونات منفصلة مع تبعيات |
| سير العمل | مراحل خطية: تخطيط → تنفيذ → أرشفة | إجراءات مرنة — افعل أي شيء في أي وقت |
| التكرار | يصعب الرجوع للخلف | حدّث المكونات مع تعلمك |
| التخصيص | هيكل ثابت | مدعوم بمخططات (حدد مكوناتك الخاصة) |
الرؤية الأساسية: العمل ليس خطيًا. نظام OPSX يتوقف عن التظاهر بأنه كذلك.
استكشاف البنية التحتية
يشرح هذا القسم كيفية عمل OPSX تحت الغطاء وكيف يقارن بسير العمل القديم. تستخدم الأمثلة في هذا القسم مجموعة الأوسع من الأوامر (new, continue, etc.)؛ يمكن للمستخدمين الافتراضيين (core) تطبيق نفس التدفق باستخدام propose → apply → 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, Windsurf) │
│ • تستعلم المهارات من CLI للحصول على بيانات منظمة │
│ • قابل للتخصيص بالكامل عبر ملفات المخططات │
│ │
└─────────────────────────────────────────────────────────────────────────────┘نموذج مخطط التبعيات
تشكل الملفات الناتجة مخططًا أكريليكًا موجهًا (DAG). التبعيات هي ممكّنات، وليست بوابات:
proposal
(العقدة الجذرية)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(يتطلب: (يتطلب:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(يتطلب:
specs, design)
│
▼
┌──────────────┐
│ مرحلة APPLY │
│ (يتطلب: │
│ 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 يستأنف
│ │ من حيث توقفت
│ │
│ └── ينشئ ملفًا ناتجًا واحدًا، يعرض ما تم فتحه
│
└── يهيئ التغيير، ينتظر التوجيهالمخططات المخصصة
أنشئ سير عمل مخصصًا باستخدام أوامر إدارة المخططات:
bash
# إنشاء مخطط جديد من الصفر (تفاعلي)
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:
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 |
| التكرار | مقيد بالمراحل | سلس، تعديل أي شيء |
| دعم المحرر | أدوات تهيئة/محولات خاصة بأداة | دليل مهارات واحد |
المخططات
تُعرّف المخططات ما يتوفر من النماذج</tool_call>