spec-driven
مخرجات سير العمل الافتراضي: ترتيبها، وصيغها، ومجلد التغيير الذي تنتجه.
spec-driven هو المخطط الافتراضي المدمج في OpenSpec. يحدد ملف schema.yaml الحقول التي يعيّنها.
المخرجات
يصوغ سير العمل أربع مخرجات:
| المخرجة | الملف | الغرض |
|---|---|---|
proposal | proposal.md | لماذا التغيير مطلوب |
specs | specs/<capability-path>/spec.md، واحد لكل قدرة | ما السلوك الذي يتغير |
design | design.md | كيفية بنائه |
tasks | tasks.md | قائمة مراجعة التنفيذ |
ترتيب الصياغة
text
┌─ specs ──┐
proposal ────┤ ├── tasks ── apply
└─ design ─┘يبدأ الأمر بالعرض التمهيدي (proposal). تتبعه مواصفات التصميم (specs) والتصميم (design) بأي ترتيب، بينما تتطلب المهام (tasks) كلا منهما معًا. تبدأ مرحلة التنفيذ (apply) بعد ضبط ملف tasks.md في مكانه.
يمكن تجاوز عنصرين من العناصر:
design: عند عدم تطبيق أي من شروطه، يستبعده الوكيل ويصوغtasksعلى أي حال.specs: اضبطskip_specs: trueفي ملف.openspec.yamlالخاص بالتغيير.
مثال على مجلد التغيير
تغيير باسم add-user-auth، مع صياغة جميع العناصر:
text
openspec/changes/add-user-auth/
├── .openspec.yaml بيانات وصفية للتغيير، تُكتب عند إنشائه
├── proposal.md
├── specs/
│ └── user-auth/
│ └── spec.md مواصفة دلتا واحدة لكل قدرة (capability)
├── design.md
└── tasks.mdproposal.md
يتضمن هذا الملف التأسيس لسبب الحاجة إلى التغيير.
الهيكلية
القالب الذي يستقبله الوكيل كصيغة مخرجات (templates/proposal.md):
md
# Proposal
## Why
<!-- اشرح الدافع وراء هذا التغيير. ما المشكلة التي يحلها؟ ولماذا الآن؟ -->
## What Changes
<!-- صف ماذا سيُغير. كن دقيقًا فيما يتعلق بالقدرة الجديدة، التعديلات، أو الإزالات. -->
## Capabilities
### New Capabilities
<!-- القدرات التي ستُقدم. سمِّ كل قدرة (capability) لسلوك نظام متماسك
يمكنه امتلاك المتطلبات ذات الصلة مع تطور النظام. لا تسمِّ مهام تنفيذية أو أقسام عرض تمهيدي. تجنَّب الأسماء العامة الواسعة. استخدم
kebab-case للمقاطع المسار التي تُقدمها (مثل user-auth أو identity/user-auth)
والتي تتبع التنظيم القياسي الموجود للمشروع. كل واحدة منها تنشئ
specs/<capability-path>/spec.md. -->
- `<capability-path>`: <وصف موجز لما تغطيه هذه القدرة>
### Modified Capabilities
<!-- القدرات الموجودة التي ستتغير متطلباتها (REQUIREMENTS) (وليس التنفيذ فقط).
اذكر هنا فقط إذا تغيّرت السلوكيات على مستوى المواصفة (spec-level behavior). كل واحدة تحتاج إلى ملف مواصفة دلتا.
استخدم المسار الموجود الدقيق تحت openspec/specs/. اتركه فارغًا إذا لم تزد متطلبات. التغيير الذي لا يملك أي قدرات على الإطلاق (إعادة هيكلة نقية، أدوات، وثائق)
يجب أن يضبط `skip_specs: true` في ملفه .openspec.yaml - يرفض openspec validate
تغييرًا صفر الدلتا دون هذه العلامة. لا تختلِش متطلبًا مجردًا فقط ل
为了满足 التحقق من الصحة. -->
- `<existing-capability-path>`: <ما هو المتطلب الذي يتغير>
## Impact
<!-- الكود المتأثر، واجهات برمجة التطبيقات (APIs)، الاعتماديات، الأنظمة -->التعليمات
التوجيه المرسل إلى الوكيل عند صياغة هذا العنصر (من schema.yaml):
md
أنشئ مستند العرض التمهيدي (proposal document) الذي يحدد لماذا هو مطلوب هذا التغيير.
الأقسام:
- **لماذا (Why)**: 1-2 جمل حول المشكلة أو الفرصة. ما المشكلة التي تحلها؟ ولماذا الآن؟
- **ماذا يتغير (What Changes)**: قائمة نقطية بالتغييرات. كن دقيقًا فيما يتعلق بالقدرة الجديدة، التعديلات، أو الإزالات. وضع علامة **BREAKING** على التغييرات المكسورة.
- **القدرات (Capabilities)**: حدد أي مواصفات سيتم إنشاؤها أو تعديلها:
- **قدرات جديدة (New Capabilities)**: اذكر القدرات المقدمة. كل واحدة تصبح `specs/<capability-path>/spec.md` جديدة. سمِّ كل قدرة لسلوك نظام دائم (على سبيل المثال، `user-auth`)، وليس العمل في هذا التغيير (على سبيل المثال، `add-login-endpoint`). اختر حدًّا متماسكًا يمكنه امتلاك المتطلبات ذات الصلة مع تطور النظام؛ تجنّب قدرات عامة واسعة. استخدم kebab-case لمقاطع المسار التي تقدمها (مثل `user-auth` أو `identity/user-auth`) وتبع التنظيم القياسي الموجود في المشروع.
- **قدرات معدلة (Modified Capabilities)**: اذكر القدرات الموجودة التي تتغير متطلباتها (REQUIREMENTS). شمل فقط إذا تغيّرت السلوكيات على مستوى المواصفة (وليس تفاصيل التنفيذ). كل واحدة تحتاج إلى ملف مواصفة دلتا. استخدم المسار الموجود الدقيق تحت `openspec/specs/`. اتركه فارغًا إذا لم تزد متطلبات.
هام: قسم القدرات حاسم. ينشئ العقد بين مراحل العرض التمهيدي والمواصفات. ابحث عن المواصفات الموجودة قبل ملء هذا القسم:
شغّل `openspec list --specs` لجرد قدرات المشروع، ثم
`openspec show "<spec-id>" --type spec --json --no-scenarios` لأي شيء يبدو ذا صلة - يعيد ذلك غرض القدر ونصوص المتطلبات
دون سحب ملفات المواصفات الكاملة إلى السياق. أضف `--store "<id>"` إلى
كلا الأمرين فقط لخزانه مستقل مسجل، واحفظ `--type
spec`: تغيير ومواصفة تتشاركان نفس الاسم هو خطأ عنصر غير محدد. `openspec list` بدون `--specs` يlist التغييرات قيد التنفيذ، وليس
المواصفات - لا يعرض أبدًا ما يغطيه المشروع بالفعل. أعد استخدام
مسار قدرة موجودة بدلاً من إدخال اسم شبه مكرر.
القراءة المفلترة هي مجرد نظرة عامة. قبل تحديد ما هو موجود بالفعل
أو ما يجب تغييره، اقرأ كل مواصفة ذات صلة بالكامل، بما في ذلك
السيناريوهات، باستخدام `openspec show "<spec-id>" --type spec` (نفس قاعدة `--store`).
كل قدرة مذكورة هنا ستحتاج إلى ملف مواصفة مطابق.
يجب أن يصرّح كل تغيير على الأقل بقدرة واحدة (جديدة أو معدلة) أو
يخرج صراحة من المواصفات: يرفض `openspec validate`
تغييرًا بصفر دلتا ما لم يضبط `skip_specs: true` في ملف `.openspec.yaml` للتغيير. استخدم `skip_specs: true` فقط عندما لا يتغير السلوك على مستوى المواصفة (إعادة هيكلة نقية، أدوات، وثائق) - تصف المواصفات
السلوك، لذلك إذا لم يتغير السلوك، لا يجب أن تتغير المواصفة.
لا تختلق متطلبًا مجردًا فقط لتلبية التحقق من الصحة.
اجعلها مختصرة (1-2 صفحة). ركز على "لماذا" وليس على "كيف" -
تفاصيل التنفيذ تنتمي إلى design.md.
هذا هو الأساس - المواصفات، التصميم، والمهام تبني جميعها على هذا.مواصفات الدلتا (spec.md)
يحدد سلوك النظام المتغير، مع مواصفة دلتا واحدة لكل قدرة يستردها العرض التمهيدي.
كل مواصفة دلتا هي ملف spec.md داخل مجلد قدرتها. يرفض openspec validate و openspec archive أقسام دلتا مكتوبة في أي ملف آخر تحت specs/، مثل specs/user-auth.md، لأن الأرشيف لا يدمجها أبدًا.
الهيكلية
القالب الذي يستقبله الوكيل كصيغة مخرجات (templates/spec.md):
md
# Spec Delta
## Purpose
<!-- للقدرات الجديدة فقط: جملة أو جملتين (50+ حرفًا) حول غرض هذه القدرة. احذف هذا القسم لقدرة موجودة. -->
## ADDED Requirements
### Requirement: <!-- اسم المتطلب -->
<!-- نص المتطلب -->
#### Scenario: <!-- اسم السيناريو -->
- **WHEN** <!-- الشرط -->
- **THEN** <!-- النتيجة المتوقعة -->التعليمات
التوجيه المرسل إلى الوكيل عند صياغة هذا العنصر (من schema.yaml):
md
أنشئ ملفات المواصفات التي تعرّف ماذا يجب أن يفعل النظام.
المواصفة (spec) عقد سلوك، وليست خطة تنفيذ.
محتوى المواصفات الجيد:
- السلوكيات المرصودة التي يعتمد عليها المستخدمون أو الأنظمة المنبثقة
- المدخلات، المخرجات، وحالات الأخطاء
- القيود الخارجية (الأمان، الخصوصية، الموثوقية، التوافقية)
- سيناريوهات يمكن اختبارها أو التحقق منها صراحة
تجنب في المواصفات:
- أسماء الفئات/الدوال الداخلية
- اختيارات المكتبات أو الإطارات
- تفاصيل التنفيذ خطوة بخطوة
- خطط التنفيذ المفصلة (تنتمي إلى design.md أو tasks.md)
اختبار سريع: إذا كان التنفيذ يمكن أن يتغير دون تغيير السلوك المرصود خارجيًا،
فإنه على الأرجح لا ينتمي إلى المواصفة.
أنشئ ملف مواصفة واحدًا لكل قدرة مذكورة في قسم القدرات في العرض التمهيدي.
`<capability-path>` هو دليل المواصفة نسبيًا إلى `specs/` (على سبيل المثال،
`user-auth` أو `identity/user-auth`). حافظ على المسار الكامل:
- القدرات الجديدة: استخدم المسار الدقيق من العرض التمهيدي في `specs/<capability-path>/spec.md`. أي مقطع مسار جديد مقدم في العرض التمهيدي يجب أن يكون kebab-case. اتبع التنظيم الموجود في المشروع؛ لا تضف مستوى مجال جديد عندما يستخدم المشروع تخطيطًا مسطحًا.
- القدرات المعدلة: استخدم المسار الموجود الدقيق من `openspec/specs/<capability-path>/` عند إنشاء الدلتا في `specs/<capability-path>/spec.md`. شغّل `openspec list --specs` لتأكيد المسار قبل كتابة الدلتا، أضف `--store "<id>"` فقط لخزانه مستقل مسجل - خطأ في الكتابة أو اختراع لمسار يستهدف قدرة غير موجودة وليس تلك التي قصدتها. لا تنقل أو تسمِّ القدرة.
اكتب ملفات المواصفات واحدًا في الوقت الذي يراه المستخدم تقدمًا، حتى يبقى الملف المكتوب السابق في حالة انقطاع التنفيذ:
- قبل كتابة أي شيء، قارن القدرات المذكورة في العرض التمهيدي
مع ملفات `specs/<capability-path>/spec.md` الموجودة بالفعل،
وابدأ بأول قدرة لا تملك ملفًا. لا تعِد الكتابة ملف موجود إلا إذا طلب منك المستخدم ذلك.
- قبل كل ملف، صغ جملة واحدة عن القدرة التي تكتبها.
- اكتب كل ملف فور صياغته. لا تخطط لكل ملف
قبل كتابة الأول.
- توقف عندما تتلقى كل قدرة مذكورة في العرض التمهيدي ملفها.
يجب أن يكون هناك على الأقل ملف مواصفة واحد ما لم يضبط ملف `.openspec.yaml` للتغيير
`skip_specs: true` (لا تغيّر سلوك على مستوى المواصفة) - يرفض `openspec validate`
تغييرًا بصفر دلتا دون هذه العلامة. إذا لم يذكر العرض التمهيدي
أي قدرات ولم يضبط `skip_specs`، راجع العرض التمهيدي أولًا.
عمليات الدلتا (استخدم ترويسات ##):
- **متطلبات مضافة (ADDED Requirements)**: قدرات جديدة
- **متطلبات معدلة (MODIFIED Requirements)**: تغيّر في السلوك - يجب أن يشمل المحتوى الكامل المحدّث
- **متطلبات محذوفة (REMOVED Requirements)**: ميزات مرفوضة - يجب أن تشمل **السبب** و**الترحيل (Migration)**
- **متطلبات معادة التسمية (RENAMED Requirements)**: تغييرات في الاسم فقط - استخدم صيغة FROM:/TO:
متطلبات التنسيق:
- كل متطلب: `### Requirement: <name>` متبوعًا بالوصف
- استخدم SHALL/MUST للمتطلبات المعيارية (تجنب should/may)
- كل سيناريو: `#### Scenario: <name>` مع صيغة WHEN/THEN
- **هام**: يجب أن تستخدم السيناريوهات بالضبط 4 هاشات (`####`). استخدام 3 هاشات أو نقاط سيؤدي إلى فشل صامت.
- يجب أن يملك كل متطلب سيناريو واحدًا على الأقل.
- يجب أن يملك كل سيناريو خطوة WHEN/GIVEN (محفّزه) وخطوة THEN (نتيجته). سيناريو يحتوي فقط على خطوط AND أو نثر عادي يحسب كسيناريو، لكن `openspec validate` يحدد كتنبيه: التحقق العادي لا يزال ناجحًا، لكن `openspec validate --strict` يفشل عليه.
- احفظ وصف كل متطلب (النص بين `### Requirement:` وأول سيناريو له) بـ 500 حرف أو أقل. يحدد `openspec validate` الأوصاف الأطول في المتطلبات المضافة وفي المواصفة الرئيسية. هذا تنبيه: التحقق العادي لا يزال ناجحًا، لكن `openspec validate --strict` يفشل عليه. عند كتابة متطلب جديد، حدّد سلوكًا واحدًا لكل متطلب: انقل الأمثلة وحالات الحد إلى السيناريوهات، وقسم متطلبات تغطي عدة سلوكيات إلى كتل `### Requirement:` منفصلة، كل واحدة بسيناريوهاتها الخاصة. تحت معدلة، حافظ على كتلة المتطلب الموجودة كاملة؛ لا تقسم، تقصّ، أو تكتب نصًا موجودًا فقط لتلبية الطول. قسّم متطلبًا طويلًا موجودًا فقط عند طلب المستخدم لذلك، في تغيير منسوق لذلك الغرض: تحت معدلة، حافظ على ترويسته وكل سيناريوهاته وقصّ وصفه إلى سلوك واحد دون تغيير معناه، ثم أضف كل سلوك أزالته كمتطلب مضاف جديد بسيناريوهاته الخاصة.
للقدرات الجديدة فقط: القسم الأول لمواصفة الدلتا هو `## Purpose` -
جملة أو جملتين (50+ حرفًا، أو يبلغ `openspec validate --strict`
بأنها قصيرة جدًا) يصفان غرض القدرة. ينسخ الأرشيف
إلى المواصفة الرئيسية التي ينشئها؛ بدونه تبقى المواصفة الرئيسية الجديدة
بعلامة فارغة `TBD ... Update Purpose after archive` لتُملأ يدويًا. لا تضف `## Purpose` إلى دلتا لقدرة موجودة -
تلك المواصفة تملكها بالفعل وتُتجاهل دلتا. لتغيير
غرض قدرة موجودة - بما في ذلك علامة فارغة `TBD` متروكة -
حرِّر `<planningHome.root>/openspec/specs/<capability-path>/spec.md`
مباشرة. يأتي `planningHome.root` من استجابة `openspec instructions ...
--json`. استخدم دائمًا وليس مسار نسبي في المستودع: يحل
للخزانة أينما كان التغيير موجودًا - سواء جاء
من `--store`، مؤشر `store:` في المشروع، أو خزانة
افتراضية عالمية - وللمستودع الحالي غير ذلك. لا تحاول تحديد
أي حالة تنطبق؛ الحقل لديه بالفعل.
سير عمل المتطلبات المعدلة:
1. حدد المتطلب الموجود في `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (نفس الجذر الذي يدعم الخزانة أعلاه)
2. انسخ كتلة المتطلب الكاملة (من `### Requirement:` عبر جميع السيناريوهات)
3. الصق تحت `## MODIFIED Requirements` وعدّل ليعكس سلوكًا جديدًا
4. تأكد من أن نص الترويسة مطابق تمامًا (غير حساس للمسافات)
مخاطرة شائعة: استخدام معدلة مع محتوى جزئي يفقد التفاصيل وقت الأرشيف.
إذا كنت تضيف أمورًا جديدة دون تغيير السلوك الموجود، استخدم مضافة بدلاً من ذلك.
مثال (قدرة جديدة، لذلك قسمه الأول هو `## Purpose`):
```
# Spec Delta
## الغرض
يتيح للمستخدمين أخذ بياناتهم من المنتج بصيغة قابلة للنقل.
## المتطلبات المضافة
### المتطلب: يمكن للمستخدم تصدير البيانات
يجب أن يسمح النظام للمستخدمين بتصدير بياناتهم بصيغة CSV.
#### السيناريو: تصدير ناجح
- **عندما** ينقر المستخدم على زر "تصدير"
- **ثم** يقوم النظام بتنزيل ملف CSV يحتوي على جميع بيانات المستخدم
## المتطلبات المزالة
### المتطلب: التصدير القديم
**السبب**: تم استبداله بنظام تصدير جديد
**الترحيل**: استخدم نقطة النهاية الجديدة للتصدير على /api/v2/export
```
## Purpose
Lets users take their data out of the product in a portable format.
## ADDED Requirements
### Requirement: User can export data
The system SHALL allow users to export their data in CSV format.
#### Scenario: Successful export
- **WHEN** user clicks "Export" button
- **THEN** system downloads a CSV file with all user data
## REMOVED Requirements
### Requirement: Legacy export
**Reason**: Replaced by new export system
**Migration**: Use new export endpoint at /api/v2/export
```
يجب أن تكون المواصفات قابلة للاختبار - كل سيناريو هو حالة اختبار محتملة.
## design.md
يشرح كيفية تنفيذ التغيير. يتم صياغته فقط عندما يحتاج التغيير إلى ذلك.
### الهيكل
القالب الذي يتلقاه الوكيل كصيغة إخراج ([templates/design.md](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/templates/design.md)):
```md
# Design
## Context
<!-- الحالة الحالية والقيود التي تشكل النهج. راجع proposal.md للدوافع - لا تكررها -->
## Goals / Non-Goals
**Goals:**
<!-- ما يهدف هذا التصميم إلى تحقيقه -->
**Non-Goals:**
<!-- ما هو خارج النطاق صراحةً -->
## Decisions
<!-- قرارات التصميم الرئيسية مع الأساس المنطقي والبدائل المدروسة -->
## Risks / Trade-offs
<!-- المخاطر والمقايضات المعروفة -->
```
### التعليمات
التعليمات المرسلة إلى الوكيل عند صياغة هذا الأثر (من [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):
```md
Create the design document that explains HOW to implement the change.
When to include design.md (create only if any apply):
- Cross-cutting change (multiple services/modules) or new architectural pattern
- New external dependency or significant data model changes
- Security, performance, or migration complexity
- Ambiguity that benefits from technical decisions before coding
Sections:
- **Context**: Only the current state and constraints needed to explain the approach. Reference the proposal for motivation instead of restating it (e.g., "See proposal.md - Why").
- **Goals / Non-Goals**: What this design achieves and explicitly excludes. Don't restate the proposal's scope - add only design-level boundaries.
- **Decisions**: Key technical choices with rationale (why X over Y?). Include alternatives considered for each decision.
- **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation
- **Migration Plan**: Steps to deploy, rollback strategy (if applicable)
- **Open Questions**: Unknowns that can safely be answered later without
changing the specs, the approach, or the task breakdown. Omit if none.
Open questions are for genuinely deferrable unknowns, not decisions you
skipped. If a question would change the specs, the chosen approach, or
the task breakdown, resolve it now - ask the user instead of guessing.
Focus on architecture and approach, not line-by-line implementation.
The proposal covers why and what; design covers how. Reference the
proposal for motivation and, once written, the specs for requirements -
if a section would only restate them, point to them instead.
Good design docs explain the "why" behind technical decisions.
```
## tasks.md
يقسم التنفيذ إلى مهام قابلة للفحص. يتتبع [apply](#apply) التقدم هنا.
### الهيكل
القالب الذي يتلقاه الوكيل كصيغة إخراج ([templates/tasks.md](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/templates/tasks.md)):
```md
# Tasks
## 1. <!-- اسم مجموعة المهام -->
- [ ] 1.1 <!-- وصف المهمة -->
- [ ] 1.2 <!-- وصف المهمة -->
## 2. <!-- اسم مجموعة المهام -->
- [ ] 2.1 <!-- وصف المهمة -->
- [ ] 2.2 <!-- وصف المهمة -->
```
### التعليمات
التعليمات المرسلة إلى الوكيل عند صياغة هذا الأثر (من [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):
````md
Create the task list that breaks down the implementation work.
Before writing tasks, check design.md for Open Questions. If any of them
would change what gets built, resolve them with the user first - do not
bake an unstated assumption into the task list.
**IMPORTANT: Follow the template below for tracked tasks.** The apply phase parses
checkbox format to track progress. A box holding only `x` counts as done,
upper or lower case and with any spacing, so `- [ x]` is done too. Every
other marker, including `- [~]`, `- [-]` and an empty `- []`, reads as
unfinished. A line with no checkbox is not tracked at all.
Guidelines:
- Group related tracked tasks under ## numbered headings
- Each tracked task MUST be a checkbox: `- [ ] X.Y Task description`
- Tasks should be small enough to complete in one session
- Order tasks by dependency (what must be done first?)
- Track implementation and verification work that can be completed before
archive. If the requested workflow includes archive or work that requires
this change to be archived, preserve those steps as plain bullets in an
optional `## Workflow follow-up` section at the end of tasks.md. These
bullets are reference information outside tracked task progress.
- Each task MUST state how to verify completion (a test, command,
observable behavior, or delivered artifact). Put the verification in
that task's checkbox description. Use a separate verification task only
when it checks broader integration or system behavior that spans
multiple implementation tasks.
- Each task group MUST land the tests and documentation its own work
calls for. Do NOT collect testing or documentation into a final group -
when a late group first exercises work from an early one, the failures
cascade back through every group in between and force rework. A group
whose work calls for neither, such as scaffolding or dependency setup,
carries neither. A final group is for integration checks only, not for
the tests and docs an earlier group owed.
Example:
```
# Tasks
## 1. Setup
- [ ] 1.1 Create new module structure and verify expected files are present
- [ ] 1.2 Add dependencies to package.json and verify package installation succeeds
## 2. Core Implementation
- [ ] 2.1 Implement data export function and verify the export test passes
- [ ] 2.2 Add CSV formatting utilities and verify unit tests cover quoting and delimiters
- [ ] 2.3 Document the export API in docs/export.md and verify the documented command runs as written
```
When applicable, append workflow follow-up as plain bullets, for example:
```
## Workflow follow-up
- Archive the change after the project's review requirements are satisfied.
- Verify the archived result.
```
Reference specs for what needs to be built, design for how to build it.التطبيق
الانتقال من التخطيط إلى التنفيذ. التطبيق هو المرحلة التي تعمل من خلال tasks.md، وليس أثرًا.
- يبدأ: بمجرد وجود
tasks.mdوقائمة تحتوي على مهمة واحدة على الأقل. - يتتبع: مربعات الاختيار في
tasks.md. تحديدها هو سجل التقدم. - ينتهي: عندما يتم تحديد كل مربع اختيار. يقترح OpenSpec بعد ذلك أرشفة التغيير.
الإعدادات
إعدادات التطبيق (من schema.yaml):
yaml
apply:
requires: [tasks]
tracks: tasks.md
# التعليمات: معروضة أدناهالتعليمات
التعليمات المرسلة إلى الوكيل عند بدء التنفيذ (من schema.yaml):
md
Read context files, work through pending tasks, mark complete as you go.
Pause if you hit blockers or need clarification.schema.yaml
ملف schema.yaml الكامل، مع حذف نصوص التعليمات. يظهر كل منها بالكامل في قسمه أعلاه.
yaml
name: spec-driven
version: 1
description: سير عمل OpenSpec الافتراضي - proposal → specs → design → tasks
artifacts:
- id: proposal
generates: proposal.md
description: مستند الاقتراح الأولي الذي يوضح التغيير
template: proposal.md
# التعليمات: معروضة بالكامل تحت proposal.md أعلاه
requires: []
- id: specs
generates: "specs/**/*.md"
description: مواصفات تفصيلية للتغيير
template: spec.md
# التعليمات: معروضة بالكامل تحت Delta specs أعلاه
requires:
- proposal
- id: design
generates: design.md
description: مستند التصميم الفني مع تفاصيل التنفيذ
template: design.md
# التعليمات: معروضة بالكامل تحت design.md أعلاه
requires:
- proposal
- id: tasks
generates: tasks.md
description: قائمة تحقق التنفيذ مع مهام قابلة للتتبع
template: tasks.md
# التعليمات: معروضة بالكامل تحت tasks.md أعلاه
requires:
- specs
- design
apply:
requires: [tasks]
tracks: tasks.md
# التعليمات: معروضة بالكامل تحت Apply أعلاه