المفاهيم
يشرح هذا الدليل الأفكار الأساسية وراء OpenSpec وكيف تت关联 together. للاستخدام العملي، راجع البدء وسير العمل.
الفلسفة
يعتمد OpenSpec على أربعة مبادئ:
مرونة لا صرامة — لا بوابات مراحل، تعمل على ما يُ觉得很合理
تكراري لا شلالي — تتعلم أثناء البناء، وتُحسّن أثناء المضي
سهولة لا تعقيد — إعداد خفيف، إجراءات بسيطة
أولوية للأنظمة القائمة — يعمل مع قواعد الأكواد الحالية، وليس فقط الجديدةلماذا هذه المبادئ مهمة
مرونة لا صرامة. تقفل أنظمة المواصفات التقليدية في مراحل محددة: أولاً تخطط، ثم تنفذ، ثم تنتهي. OpenSpec أكثر مرونة — يمكنك إنشاء المخرجات بأي ترتيب مناسب لعملك.
تكراري لا شلالي. تتغير المتطلبات. يتعمق الفهم. قد يبدو النهج جيداً في البداية لكنه لا يصمد بعد رؤية قاعدة الأكواد. يعتمد OpenSpec هذه الحقيقة.
سهولة لا تعقيد. تتطلب بعض أطر المواصفات إعداداً واسعاً، أو تنسيقات صارمة، أو عمليات معقدة. OpenSpec لا يعيق عملك. قم بالتهيئة في ثوانٍ، وابدأ العمل فوراً، وخصص فقط إذا لزم الأمر.
أولوية للأنظمة القائمة. معظم عمل البرمجيات ليس البناء من الصفر — بل هو تعديل الأنظمة الموجودة. يجعل نهج OpenSpec القائم على الفروقات من السهل تحديد التغييرات على السلوك الحالي، وليس فقط وصف الأنظمة الجديدة.
الصورة الكبيرة
ينظم OpenSpec عملك في منطقتين رئيسيتين:
┌────────────────────────────────────────────────────────────────────┐
│ openspec/ │
│ │
│ ┌─────────────────────┐ ┌───────────────────────────────┐ │
│ │ specs/ │ │ changes/ │ │
│ │ │ │ │ │
│ │ مصدر الحقيقة │◄─────│ التعديلات المقترحة │ │
│ │ كيفية عمل نظامك │ دمج │ كل تغيير = مجلد واحد │ │
│ │ حالياً │ │ يحتوي على الملفات + الفروقات│ │
│ │ │ │ │ │
│ └─────────────────────┘ └───────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘المواصفات (Specs) هي مصدر الحقيقة — تصف كيفية عمل نظامك الحالي.
التغييرات (Changes) هي تعديلات مقترحة — تعيش في مجلدات منفصلة حتى تكون مستعداً لدمجها.
هذا الفصل هو المفتاح. يمكنك العمل على تغييرات متعددة بالتوازي دون تعارضات. يمكنك مراجعة تغيير قبل أن يؤثر على المواصفات الرئيسية. وعند أرشفة تغيير، تندمج فروقاته بسلاسة في مصدر الحقيقة.
المواصفات
تصف المواصفات سلوك نظامك باستخدام متطلبات وسيناريوهات منظمة.
البنية
openspec/specs/
├── auth/
│ └── spec.md # سلوك المصادقة
├── payments/
│ └── spec.md # معالجة المدفوعات
├── notifications/
│ └── spec.md # نظام الإشعارات
└── ui/
└── spec.md # سلوك وسمات واجهة المستخدمقم بتنظيم المواصفات حسب المجال — مجموعات منطقية مناسبة لنظامك. الأنماط الشائعة:
- حسب منطقة الميزة:
auth/,payments/,search/ - حسب المكون:
api/,frontend/,workers/ - حسب السياق المحدد:
ordering/,fulfillment/,inventory/
تنسيق المواصفة
تحتوي المواصفة على متطلبات، وكل متطلب يحتوي على سيناريوهات:
markdown
# مواصفة المصادقة
## الغرض
المصادقة وإدارة الجلسات للتطبيق.
## المتطلبات
### المتطلب: مصادقة المستخدم
يجب على النظام إصدار رمز JWT عند تسجيل الدخول بنجاح.
#### السيناريو: بيانات اعتماد صالحة
- GIVEN مستخدم بيانات اعتماد صالحة
- WHEN يرسل المستخدم نموذج تسجيل الدخول
- THEN يتم إرجاع رمز JWT
- AND يتم توجيه المستخدم إلى لوحة التحكم
#### السيناريو: بيانات اعتماد غير صالحة
- GIVEN بيانات اعتماد غير صالحة
- WHEN يرسل المستخدم نموذج تسجيل الدخول
- THEN يتم عرض رسالة خطأ
- AND لا يتم إصدار أي رمز
### المتطلب: انتهاء صلاحية الجلسة
يجب على النظام إنهاء صلاحية الجلسات بعد 30 دقيقة من عدم النشاط.
#### السيناريو: انتهاء المهلة بسبب الخمول
- GIVEN جلسة مصادقة نشطة
- WHEN تمر 30 دقيقة بدون نشاط
- THEN يتم إبطال الجلسة
- AND يجب على المستخدم إعادة المصادقةالعناصر الرئيسية:
| العنصر | الغرض |
|---|---|
## Purpose | وصف عالي المستوى لمجال هذه المواصفة |
### Requirement: | سلوك محدد يجب أن يمتلكه النظام |
#### Scenario: | مثال محدد على المتطلب أثناء التنفيذ |
| SHALL/MUST/SHOULD | كلمات مفتاحية من RFC 2119 تدل على قوة المتطلب |
لماذا يتم هيكلة المواصفات بهذه الطريقة
المتطلبات هي "ماذا" — تنص على ما يجب أن يفعله النظام دون تحديد التنفيذ.
السيناريوهات هي "متى" — توفر أمثلة محددة يمكن التحقق منها. السيناريوهات الجيدة:
- قابلة للاختبار (يمكنك كتابة اختبار آلي لها)
- تغطي كلاً من المسار السعيد والحالات الحدية
- تستخدم صيغة Given/When/Then أو صيغة منظمة مشابهة
كلمات مفتاحية RFC 2119 (SHALL, MUST, SHOULD, MAY) تنقل النية:
- MUST/SHALL — متطلب مطلق
- SHOULD — موصى به، لكن هناك استثناءات
- MAY — اختياري
ما هي المواصفة (وما ليست عليه)
المواصفة هي عقد سلوك، وليست خطة تنفيذ.
محتوى المواصفة الجيد:
- السلوك الملموس الذي يعتمد عليه المستخدمون أو الأنظمة الطرفية
- المدخلات والمخرجات وشروط الخطأ
- القيود الخارجية (الأمان والخصوصية والموثوقية والتوافق)
- سيناريوهات يمكن اختبارها أو التحقق منها بشكل صريح
تجنب في المواصفات:
- أسماء الفئات/الدوال الداخلية
- اختيارات المكتبات أو الأطر
- تفاصيل التنفيذ خطوة بخطوة
- خطط التنفيذ التفصيلية (تلك تنتمي إلى
design.mdأوtasks.md)
اختبار سريع:
- إذا كان التنفيذ يمكن تغييره دون تغيير السلوك المرئي للخارج، فمن المحتمل أنه لا ينتمي إلى المواصفة.
حافظ على الخفة: الصارمية التدريجية
يهدف OpenSpec إلى تجنب البيروقراطية. استخدم أخف مستوى يجعل التغيير قابلاً للتحقق.
المواصفة الخفيفة (الافتراضي):
- متطلبات قصيرة تركز على السلوك
- نطاق واضح وأهداف غير مشمولة
- بعض فحوصات القبول المحددة
المواصفة الكاملة (لمخاطر أعلى):
- تغييرات عبر الفرق أو المستودعات
- تغييرات API/العقود، الترقيات، مخاطر الأمان/الخصوصية
- التغييرات التي من المرجح أن تسبب إعادة عمل مكلفة بسبب الغموض
يجب أن تبقى معظم التغييرات في الوضع الخفيف.
التعاون بين البشر والوكلاء
في كثير من الفرق، يستكشف البشر ويكتب الوكلاء الملفات. الحلقة المقصودة هي:
- يوفر الإنسان النية والسياق والقيود.
- يحول الوكيل ذلك إلى متطلبات تركز على السلوك وسيناريوهات.
- يحتفظ الوكيل بتفاصيل التنفيذ في
design.mdوtasks.md، وليس فيspec.md. - يؤكد التحقق من البنية والوضوح قبل التنفيذ.
هذا يجعل المواصفات مقروءة للبشر ومتسقة للوكلاء.
التغييرات
التغيير هو تعديل مقترح على نظامك، مُعبأ كمجلد يحتوي على كل ما هو ضروري لفهمه وتنفيذه.
بنية التغيير
openspec/changes/add-dark-mode/
├── proposal.md # لماذا وماذا
├── design.md # كيف (النهج الفني)
├── tasks.md # قائمة مهام التنفيذ
├── .openspec.yaml # بيانات التغيير الوصفية (اختياري)
└── specs/ # مواصفات الفروقات
└── ui/
└── spec.md # ما الذي يتغير في ui/spec.mdكل تغيير مكتفي بذاته. يحتوي على:
- الملفات — وثائق تلتقط النية والتصميم والمهام
- مواصفات الفروقات — مواصفات لما يُضاف أو يُعدّل أو يُحذف
- البيانات الوصفية — تكوين اختياري لهذا التغيير المحدد
لماذا التغييرات مجلدات
تعبئة التغيير كمجلد لها عدة فوائد:
كل شيء معاً. المقترح والتصميم والمهام والمواصفات تعيش في مكان واحد. لا حاجة للبحث في مواقع مختلفة.
عمل متوازٍ. يمكن أن توجد تغييرات متعددة في نفس الوقت دون تعارض. اعمل على
add-dark-modeبينماfix-auth-bugقيد التنفيذ أيضاً.سجل نظيف. عند الأرشفة، تنتقل التغييرات إلى
changes/archive/مع الحفاظ على سياقها الكامل. يمكنك الرجوع إلى الوراء وفهم ليس فقط ما الذي تغير، بل لماذا.سهل المراجعة. مجلد التغيير سهل المراجعة — افتحه، اقرأ المقترح، تحقق من التصميم، شاهد فروقات المواصفات.
الملفات
الملفات هي الوثائق داخل التغيير التي توجه العمل.
تدفق الملفات
proposal ──────► specs ──────► design ──────► tasks ──────► implement
│ │ │ │
لماذا ماذا كيف خطوات
+ النطاق التغييرات النهج للاتخاذتتبنى الملفات على بعضها البعض. يوفر كل ملف سياقاً للملف التالي.
أنواع الملفات
المقترح (proposal.md)
يلتقط المقترح النية والنطاق والنهج على مستوى عالٍ.
markdown
# المقترح: إضافة الوضع الداكن
## النية
طلب المستخدمون خيار الوضع الداكن لتقليل إجهاد العيون أثناء الاستخدام الليلي وتفضيلات النظام المطابقة.
## النطاق
ضمن النطاق:
- تبديل السمة في الإعدادات
- اكتشاف تفضيلات النظام
- حفظ التفضيل في localStorage
خارج النطاق:
- سمات ألوان مخصصة (عمل مستقبلي)
- تجاوزات السمة لكل صفحة
## النهج
استخدام خصائص CSS المخصصة للسمة مع سياق React لإدارة الحالة. اكتشاف تفضيلات النظام عند التحميل الأول، والسماح بالتجاوز اليدوي.متى يتم تحديث المقترح:
- تغييرات النطاق (تضييق أو توسيع)
- توضيح النية (فهم أفضل للمشكلة)
- تحول جوهري في النهج
المواصفات (مواصفات الفروقات في specs/)
تصف مواصفات الفروقات ما الذي يتغير مقارنة بالمواصفات الحالية. راجع مواصفات الفروقات أدناه.
التصميم (design.md)
يلتقط التصميم النهج الفني وقرارات الهيكلة.
markdown
# التصميم: إضافة الوضع الداكن
## النهج الفني
إدارة حالة السمة عبر React Context لتجنب تمرير الخصائص. تتيح خصائص CSS المخصصة التبديل في وقت التشغيل دون تبديل الفئات.
## قرارات البنية التحتية
### القرار: السياق بدلاً من Redux
يتم استخدام React Context لإدارة حالة المظهر لأن:
- حالة ثنائية بسيطة (فاتح/داكن)
- لا توجد انتقالات حالة معقدة
- يتجنب إضافة تبعية Redux
### القرار: خصائص CSS المخصصة
يتم استخدام متغيرات CSS بدلاً من CSS-in-JS لأن:
- يعمل مع ورقة الأنماط الحالية
- لا يوجد أداء تشغيل إضافي
- حل أصلي للمتصفح
## تدفق البيانات
```
ThemeProvider (سياق)
│
▼
ThemeToggle ◄──► localStorage
│
▼
متغيرات CSS (مطبقة على :root)
```
## تغييرات الملفات
- `src/contexts/ThemeContext.tsx` (جديد)
- `src/components/ThemeToggle.tsx` (جديد)
- `src/styles/globals.css` (معدل)متى يجب تحديث التصميم:
- كشف التنفيذ أن النهج لن يعمل
- اكتشاف حل أفضل
- تغيير التبعيات أو القيود
المهام (tasks.md)
المهام هي قائمة التحقق من التنفيذ — خطوات محددة مع مربعات اختيار.
markdown
# المهام
## 1. البنية التحتية للسمة
- [ ] 1.1 إنشاء ThemeContext مع حالة فاتح/داكن
- [ ] 1.2 إضافة خصائص CSS مخصصة للألوان
- [ ] 1.3 تنفيذ التخزين الدائم في localStorage
- [ ] 1.4 إضافة اكتشاف تفضيلات النظام
## 2. مكونات واجهة المستخدم
- [ ] 2.1 إنشاء مكون ThemeToggle
- [ ] 2.2 إضافة المفتاح التبديل إلى صفحة الإعدادات
- [ ] 2.3 تحديث Header لتضمين تبديل سريع
## 3. التنسيق
- [ ] 3.1 تحديد لوحة ألوان السمة الداكنة
- [ ] 3.2 تحديث المكونات لاستخدام متغيرات CSS
- [ ] 3.3 اختبار نسب التباين لإمكانية الوصولأفضل ممارسات المهام:
- تجميع المهام ذات الصلة تحت عناوين
- استخدام ترقيم هرمي (1.1، 1.2، إلخ)
- إبقاء المهام صغيرة بما يكفي للإنجاز في جلسة واحدة
- تحديد المهام عند إنجازها
مواصفات الدلتا
مواصفات الدلتا هي المفهوم الجوهري الذي يجعل OpenSpec يعمل للتطوير على الأنظمة القائمة. إنها تصف ما يتغير بدلاً من إعادة صياغة المواصفة الكاملة.
الصيغة
markdown
# دلتا للمصادقة
## متطلبات مضافة
### المتطلب: المصادقة الثنائية
يجب على النظام دعم المصادقة الثنائية المبنية على TOTP.
#### السيناريو: تسجيل المصادقة الثنائية
- بالنظر إلى مستخدم لا توجد لديه مصادقة ثنائية مفعلة
- عندما يفعّل المستخدم المصادقة الثنائية في الإعدادات
- يتم عرض رمز QR لإعداد تطبيق المصادق
- ويجب على المستخدم التحقق برمز قبل التنشيط
#### السيناريو: تسجيل الدخول بالمصادقة الثنائية
- بالنظر إلى مستخدم مفعلة لديه المصادقة الثنائية
- عندما يقدم المستخدم بيانات اعتماد صالحة
- يتم تقديم تحدّي OTP
- ويكتمل تسجيل الدخول فقط بعد OTP صالح
## متطلبات معدلة
### المتطلب: انتهاء صلاحية الجلسة
يجب على النظام إنهاء صلاحية الجلسة بعد 15 دقيقة من عدم النشاط.
(سابقاً: 30 دقيقة)
#### السيناريو: انتهاء المهلة بسبب الخمول
- بالنظر إلى جلسة مصادق بها
- عندما تمر 15 دقيقة بدون نشاط
- يتم إبطال الجلسة
## متطلبات محذوفة
### المتطلب: تذكرني
(تم إهماله لصالح المصادقة الثنائية. يجب على المستخدمين إعادة المصادقة في كل جلسة.)أقسام الدلتا
| القسم | المعنى | ما يحدث عند الأرشفة |
|---|---|---|
## متطلبات مضافة | سلوك جديد | تتم إضافتها إلى المواصفة الرئيسية |
## متطلبات معدلة | سلوك متغير | تستبدل المتطلب الحالي |
## متطلبات محذوفة | سلوك مهمل | تتم حذفه من المواصفة الرئيسية |
لماذا الدلتا بدلاً من المواصفات الكاملة
الوضوح. تُظهر الدلتا بالضبط ما يتغير. عند قراءة مواصفة كاملة، ستحتاج إلى مقارنتها ذهنياً بالإصدار الحالي.
تجنب التعارض. يمكن لتغييرين لمس ملف مواصفات واحد دون تعارض، طالما أنهما يعدّلان متطلبات مختلفة.
كفاءة المراجعة. يرى المراجعون التغيير، وليس السياق غير المتأثر. ركّز على ما هو مهم.
ملاءمة الأنظمة القائمة. معظم العمل يعدّل سلوكاً قائماً. تجعل الدلتا التعديلات أساسية، وليس أمراً تكميلياً.
المخططات
تُعرّف المخططات أنواع المخرجات وتبعياتها لسير عمل.
كيف تعمل المخططات
yaml
# openspec/schemas/spec-driven/schema.yaml
name: spec-driven
artifacts:
- id: proposal
generates: proposal.md
requires: [] # لا تبعيات، يمكن إنشاؤه أولاً
- id: specs
generates: specs/**/*.md
requires: [proposal] # يحتاج إلى المقترح قبل الإنشاء
- id: design
generates: design.md
requires: [proposal] # يمكن إنشاؤه بالتوازي مع المواصفات
- id: tasks
generates: tasks.md
requires: [specs, design] # يحتاج إلى المواصفات والتصميم أولاًالمخرجات تشكل رسمًا توضيحيًا للتبعيات:
proposal
(العقد الجذر)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(يتطلب: (يتطلب:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(يتطلب:
specs, design)التبعيات هي مُمكّنات، ليست بوابات. تُظهر ما هو ممكن إنشاؤه، وليس ما يجب عليك إنشاءه بعد. يمكنك تخطي التصميم إذا لم تحتاجه. يمكنك إنشاء المواصفات قبل أو بعد التصميم — كلاهما يعتمد فقط على المقترح.
المخططات المدمجة
spec-driven (الافتراضي)
سير العمل القياسي للتطوير المبني على المواصفات:
proposal → specs → design → tasks → implementالأفضل لـ: معظم عمل الميزات حيث تريد الاتفاق على المواصفات قبل التنفيذ.
مخططات مخصصة
أنشئ مخططات مخصصة لسير عمل فريقك:
bash
# الإنشاء من الصفر
openspec schema init research-first
# أو تفرع من مخطط موجود
openspec schema fork spec-driven research-firstمثال على مخطط مخصص:
yaml
# openspec/schemas/research-first/schema.yaml
name: research-first
artifacts:
- id: research
generates: research.md
requires: [] # إجراء البحث أولاً
- id: proposal
generates: proposal.md
requires: [research] # المقترح م informs by البحث
- id: tasks
generates: tasks.md
requires: [proposal] # تخطي المواصفات/التصميم، الانتقال مباشرة إلى المهامانظر التخصيص للتفاصيل الكاملة حول إنشاء واستخدام المخططات المخصصة.
الأرشفة
تُكمل الأرشفة تغييراً عن دمج مواصفات الدلتا الخاصة به في المواصفات الرئيسية وحفظ التغيير في السجل.
ما يحدث عند الأرشفة
قبل الأرشفة:
openspec/
├── specs/
│ └── auth/
│ └── spec.md ◄────────────────┐
└── changes/ │
└── add-2fa/ │
├── proposal.md │
├── design.md │ دمج
├── tasks.md │
└── specs/ │
└── auth/ │
└── spec.md ─────────┘
بعد الأرشفة:
openspec/
├── specs/
│ └── auth/
│ └── spec.md # يتضمن الآن متطلبات المصادقة الثنائية
└── changes/
└── archive/
└── 2025-01-24-add-2fa/ # محفوظ للسجل
├── proposal.md
├── design.md
├── tasks.md
└── specs/
└── auth/
└── spec.mdعملية الأرشفة
دمج الدلتا. يتم تطبيق كل قسم من مواصفات الدلتا (مضافة/معدلة/محذوفة) على المواصفة الرئيسية المقابلة.
النقل إلى الأرشيف. يتم نقل مجلد التغيير إلى
changes/archive/مع بادئة تاريخ للترتيب الزمني.حفظ السياق. تظل جميع المخرجات سليمة في الأرشيف. يمكنك دائماً الرجوع لفهم سبب إجراء التغيير.
لماذا الأرشفة مهمة
حالة نظيفة. تُظهر التغييرات النشطة (changes/) فقط العمل قيد التنفيذ. ينتقل العمل المكتمل بعيداً.
سجل تدقيق. يحفظ الأرشيف السياق الكامل لكل تغيير — ليس فقط ما تغير، بل المقترح الذي يشرح لماذا، والتصميم الذي يشرح كيف، والمهام التي تُظهر العمل المنجز.
تطور المواصفات. تنمو المواصفات بشكل عضوي مع أرشفة التغييرات. تدمج كل أرشفة دلتاها، مما يبني مواصفة شاملة بمرور الوقت.
كيف تتصل كل الأجزاء معاً
┌──────────────────────────────────────────────────────────────────────────────┐
│ تدفق OpenSpec │
│ │
│ ┌────────────────┐ │
│ │ 1. بدء │ /opsx:propose (أساسي) أو /opsx:new (موسّع) │
│ │ التغيير │ │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 2. إنشاء │ /opsx:ff أو /opsx:continue (سير عمل موسّع) │
│ │ المخرجات │ ينشئ proposal → specs → design → tasks │
│ │ │ (بناءً على تبعيات المخطط) │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 3. تنفيذ │ /opsx:apply │
│ │ المهام │ العمل على المهام، وتحديد إنجازها │
│ │ │◄──── تحديث المخرجات أثناء التعلم │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ │
│ │ 4. التحقق │ /opsx:verify (اختياري) │
│ │ من العمل │ التحقق من تطابق التنفيذ مع المواصفات │
│ └───────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────┐ ┌──────────────────────────────────────────────┐ │
│ │ 5. أرشفة │────►│ تتم دمج مواصفات الدلتا في المواصفات الرئيسية│ │
│ │ التغيير │ │ ينتقل مجلد التغيير إلى archive/ │ │
│ └────────────────┘ │ أصبحت المواصفات مصدر الحقيقة المحدّث │ │
│ └──────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────────────┘الدورة الفضلى:
- تصف المواصفات السلوك الحالي
- تقترح التغييرات تعديلات (كدلتا)
- يجعل التنفيذ التغييرات حقيقية
- تدمج الأرشفة الدلتا في المواصفات
- تصف المواصفات الآن السلوك الجديد
- يبني التغيير التالي على المواصفات المحدّثة
المصطلحات
| المصطلح | التعريف |
|---|---|
| Artifact | مستند داخل تغيير (مقترح، تصميم، مهام، أو مواصفات delta) |
| Archive | عملية إكمال تغيير ودمج تغييراته (deltas) في المواصفات الرئيسية |
| Change | تعديل مقترح على النظام، مُعبَّأ كمجلد يحتوي على artifacts |
| Delta spec | مواصفات تصف التغييرات (مضافة/معدلة/محذوفة) مقارنة بالمواصفات الحالية |
| Domain | تصنيف منطقي للمواصفات (مثل auth/، payments/) |
| Requirement | سلوك معين يجب أن يمتلكه النظام |
| Scenario | مثال ملموس على متطلب، عادةً بصيغة Given/When/Then |
| Schema | تعريف لأنواع الـ artifacts وعلاقاتها الاعتمادية |
| Spec | مواصفات تصف سلوك النظام، تتضمن المتطلبات والسيناريوهات |
| Source of truth | دليل openspec/specs/، الذي يحتوي على السلوك المتفق عليه حاليًا |