---
name: ghayth-constitution
description: الدستور والقواعد الملزمة لنظام غيث (Ghayth ERP). حمّل هذه المهارة دائمًا قبل أي عمل في النظام — قبل كتابة أي كود، أو إنشاء/تعديل أي ملف أو جدول أو هجرة (migration)، أو اعتماد أي تطوير. هذه القواعد غير قابلة للتفاوض، وأي عمل يخالفها مرفوض تلقائيًا. استخدمها حتى لو لم يُطلب ذلك صراحةً، طالما السياق يخص أي تطوير أو تعديل أو قرار معماري في نظام غيث.
---

# دستور نظام غيث — القواعد الملزمة (تُحمّل دائمًا)

> أنت وكيل تنفيذ منضبط داخل نظام غيث ERP، لا مهندس مشروع. **لا تقرر، لا تضيف، لا تتجاوز المواصفات.** قبل أي خطوة، طبّق هذا الدستور. أي مخالفة = رفض العمل.

## قواعد التشغيل للوكيل (اقرأها أولًا)

1. **تدقيق ضد الكود الفعلي، لا ضد الملخصات.** افتح الملفات والـ diff بنفسك قبل أي حكم أو تعديل.
2. **لا توقف لتسأل عن ما هو محدد أصلًا.** نفّذ المهمة المحددة كاملة حتى معيار "خلص" (اختبار يثبت أنها تعمل). لا ترجع بعمل ناقص.
3. **سلامة القيود (Ledger) قاعدة صارمة:** أي تغيير يمس القيود المحاسبية يلزمه اختبار assertion على سطور القيد. **لا تغيير قيد بدون اختبار = رفض تلقائي.** لا تتجاوز هذا الحارس مهما كان السبب.
4. **قفل الحدود (Boundary Lock):** صفر كتابات عابرة للنطاقات. لا تعدّل ملفًا يملكه مسار آخر. لا تنقل سياسة أو قرارًا بين المسارات.
5. **إذا وجدت نفسك تعيد صياغة طلب ليبدو مقبولًا، أو تضيف افتراضات غير مذكورة — توقف واطلب إذنًا، لا تكمل.**
6. **كل تسليم يجب أن يشمل:** المرجع (الملف ورقم السيناريو) + الاستعلامات + التحققات + الأفعال التلقائية + الإشعارات + اختبار يدوي يثبت العمل. أي عنصر ناقص = تسليم مرفوض.

---

# القسم 1: هوية المشروع

| البند | القيمة |
| --- | --- |
| اسم النظام | منصة غيث — ERP |
| ما هو النظام | نظام تشغيل مؤسسي متكامل يدير: شركات متعددة وفروع وموظفين وعملاء ومالية وأسطول ومستودعات وأملاك ومشاريع ودعم وCRM وتواصل |
| لمن | مجموعة الدور الحديثة وشركاتها التابعة |
| مَن يستخدمه | أي موظف في أي شركة وأي فرع بأي صفة + العميل عبر بوابته |
| الرؤية | الموظف يدخل ويرى كل ما عليه في صفحة واحدة ويتصرف. كل عملية تنشئ سلسلة أفعال تلقائية. العميل مركز كل شيء |
| الموقع | hr.door.sa |
| المستودع | barhom64/ghayth-erp |

> ملاحظة على البنية التقنية: المواصفات الأصلية كُتبت على MySQL + tRPC. الواقع الحالي للمستودع تطوّر إلى pnpm monorepo (api-server: Node.js/Express + PostgreSQL + Drizzle ORM) و(ghayth-erp: React 19 + TypeScript + Tailwind). راجع مهارة `ghayth-state` للحالة الجارية، واعتمد الكود الفعلي عند أي تعارض.

# القسم 2: الوثائق المرجعية — 10 ملفات

هذه الملفات هي المرجع الأعلى. أي كود يخالفها يُرفض. أي إضافة غير موجودة فيها ممنوعة بدون إذن مكتوب. (المحتوى الكامل في مهارة `ghayth-specs`.)

| # | الملف | المحتوى |
| --- | --- | --- |
| 00 | الملخص التنفيذي | خارطة الطريق 9 مراحل × 20 أسبوع والبنية التقنية |
| 01 | البنية وملف العميل | تعدد التعيينات والتصفّح المتعدد وملف العميل 360 وبوابة العميل والصلاحيات وإنشاء شركة 16 عملية والأمان والإعدادات |
| 02 | الموارد البشرية | إضافة موظف 11 خطوة وحضور 17 خطوة وإجازة 18 خطوة و3 مسارات ورواتب 12 بند وسلم مخالفات |
| 03 | المالية والمحاسبة | فاتورة 7 خطوات وتحصيل 6 مراحل تصاعدية ودورة شراء P2P 8 خطوات وميزانية 4 مستويات |
| 04 | الأسطول والنقل | رحلة توصيل 10 خطوات بالحسابات وصيانة دورية 8 خطوات و7 تنبيهات ذكية |
| 05 | المستودعات والأملاك والقانونية | حد أدنى مخزون 7 خطوات وبلاغ صيانة من العميل 12 خطوة مع Load Balancing وإيجار متأخر 6 مراحل |
| 06 | المشاريع والدعم وCRM | مشروع 7 خطوات وCritical Path وتذكرة عميل 8 خطوات وSLA وفرصة بيع 7 مراحل |
| 07 | الذكاء التشغيلي | خوارزميات Haversine وMoving Average وLoad Balancing وتقويم يومي ومؤشرات KPIs وتنبيهات |
| 08 | الأتمتة الشاملة | نظام الأحداث Event System و26 وظيفة Cron وخريطة ترابط 10 عمليات |
| 09 | منصة التواصل الموحد | رقم واحد وواتساب Cloud API ونظام PBX وتحويلات وإيميلات وذكاء اصطناعي 6 أدوار |

# القسم 3: قواعد المطور — 10 قواعد ملزمة

هذه القواعد غير قابلة للتفاوض.

1. **لا تبني شيء غير موجود في المواصفات.** أي صفحة/جدول/حقل/وظيفة غير مذكورة في الملفات العشرة ممنوعة. إذا رأيتها مطلوبة: اكتب اقتراحًا وانتظر الموافقة المكتوبة.
2. **لا تنشئ جدولًا في قاعدة البيانات بدون إذن.** اكتب اسم الجدول والحقول والسبب والجداول المتأثرة، أرسله، نفّذ بعد الموافقة فقط.
3. **لا تنشئ صفحة غير مربوطة.** كل صفحة لها: مصدر في المواصفات + من أين تجلب البيانات + من يراها + كيف يصلها المستخدم + ماذا تفعل. أي جواب ناقص = الصفحة مرفوضة.
4. **كل حفظ يمر بالتحققات المذكورة.** المواصفات تحدد لكل عملية: ماذا يُرفض/يُحذّر/يُقبل. لا "أنفّذها لاحقًا" — التحققات جزء من العملية.
5. **كل حفظ يُطلق الأفعال التلقائية.** حفظ موظف بدون إنشاء أرصدة إجازات وربط وردية = عمل ناقص مرفوض.
6. **كل جدول عملياتي يحتوي assignmentId.** موجود ← السجل يتبع تعيينًا محددًا في شركة وفرع. null ← يتبع الشخص (مثل الإجازة). راجع القاعدة الذهبية في ملف 01.
7. **كل SELECT يمر بفلتر الصلاحيات.** لا استعلام بدون WHERE يحدد الشركة والفرع والصلاحية. `SELECT * FROM employees` ممنوع مطلقًا.
8. **لا تصف الشكل — صف البيانات والتدفق.** ممنوع "زر أخضر كبير". مسموح "الصفحة تعرض 4 بطاقات ثم تقويم المهام ثم طلبات الموافقة".
9. **لا تقفز بين المراحل.** لا تبدأ التالية حتى تنتهي وتُختبر السابقة 100%.
10. **كل تسليم يشمل:** المرجع + الاستعلامات + التحققات + الأفعال التلقائية + الإشعارات + الاختبار. أي عنصر ناقص = مرفوض.

# القسم 4: ترتيب البناء — 5 مراحل

لا تبدأ المرحلة التالية حتى تنجح السابقة في كل اختبارات القبول.

| # | المرحلة | المرجع |
| --- | --- | --- |
| 1 | البنية التحتية (Event System، scopedProcedure، employees، assignments، clients، tasks، settings، seed 16 عملية، الصفحة الرئيسية، الفلتر المتعدد) | ملف 01 |
| 2 | الموارد البشرية (موظف 11 خطوة، حضور 17، إجازة 18 و3 مسارات، رواتب 12 بند، مخالفات 5 درجات) | ملف 02 |
| 3 | المالية (فاتورة 7 خطوات، قيد تلقائي، تحصيل 6 مراحل، P2P 8 خطوات، ميزانية 4 مستويات) | ملف 03 |
| 4 | باقي الوحدات (الأسطول، المستودعات، الأملاك، القانونية، المشاريع، الدعم SLA، CRM) | ملفات 04–06 |
| 5 | الذكاء والأتمتة والتواصل (خوارزميات، 26 Cron، واتساب، PBX، AI) | ملفات 07–09 |

# القسم 5: القواعد المعمارية الملزمة (من وثيقة المراجعة)

أي مخالفة لها = خلل معماري يُرفض.

1. **ممنوع الصفحات المنبثقة.** كل كيان رئيسي له صفحة أم؛ ما يتفرع عنه تبويبات أو صفحات تفصيلية مرتبطة (مشروع/موظف/عقار/عميل/مركبة/عقد/قضية).
2. **ممنوع كيان فرعي بدون كيان جذر.** لا وحدة بدون عقار، لا مهمة بدون مشروع، لا فاتورة بدون عميل.
3. **ممنوع إدخال حر في حقل مرتبط بكيان.** كل ما يُربط بكيان حي = بحث ذكي / اختيار متسلسل / قيمة مقترحة. لا حقول نصية حرة في مواضع الربط.
4. **السياق قبل الفعل:** عند اختيار موظف/عقار/عميل/مركبة/عقد، اعرض السجل المرتبط وعبّئ تلقائيًا ما يمكن. أظهر "الأثر المتوقع" قبل الحفظ. أظهر التحذيرات السياقية.
5. **نمط AllowCreateDrawer:** النموذج الموحّد الكامل في درج (Drawer)، لا QuickCreateDialog مصغّر.
6. **قالب إدخال التاريخ الموحّد (One Date Input) — المادة 15/10:** قالب إدخال التاريخ الوحيد هو `UnifiedDateInput` (`@/components/ui/unified-date-input`) وعائلته المبنية عليه حصرًا: `DateRangeInput` (فترة من–إلى)، `DatePicker` (غلاف توافق)، `DateField` (غلاف حقل معنون) — والنواة `lib/date-utils.ts`. **ممنوع أي حقل تاريخ HTML خام** (`<input type="date">` / `<input type="datetime-local">`، عبر `<Input>` أو مباشرة) أو أي قالب تاريخ بديل — الخام لا يدعم الهجري ولا العرض الثنائي ولا تفضيل المستخدم. البديل الصحيح: `<UnifiedDateInput value={iso} onChange={fn} />` (أو `<DateRangeInput>` لفترة). يحرسه `check:unified-date-input` (أساس مُجمّد يمنع أي جديد ويُكنَس تباعًا). العقيدة: `docs/governance/system-doctrine-libraries/04_التقويم_الموحّد_والتواريخ.md`.

# القسم 6: المبادئ الحاكمة — 7 مبادئ

1. **الموظف شخص واحد وله عدة تعيينات.** كل تعيين مستقل في بياناته؛ العرض المجمّع يجمع عند القراءة فقط.
2. **ما يتبع الشخص ≠ ما يتبع التعيين.** القاعدة الذهبية: الإجازة والمستندات والبيانات الشخصية تتبع الشخص (assignmentId = null). الحضور والراتب والمهام والمخالفات والتقييم والموافقات الشرائية تتبع التعيين (assignmentId مطلوب).
3. **العميل مركز كل شيء.** كل عملية مرتبطة بعميل؛ له ملف 360؛ بوابة العميل يخدم نفسه فيها.
4. **كل استعلام يتفلتر حسب الصلاحيات.** لا SELECT بدون WHERE الشركة والفرع. العادي يرى بياناته، المدير قسمه، المالك الكل.
5. **كل حفظ يُطلق أفعالًا تلقائية.** لا حفظ بسيط — كل حفظ يُطلق سلسلة.
6. **الإعدادات تورث على 3 مستويات:** نظام ← شركة ← فرع. الأقرب يفوز.
7. **البناء بالترتيب وليس دفعة واحدة.**

# القسم 7: قواعد استخدام الذكاء الاصطناعي

الذكاء الاصطناعي أداة تنفيذ منضبطة، لا مهندس مشروع.

**مسموح:** تنفيذ خطوات محددة مرتبطة بالمواصفات؛ السؤال عن قاعدة واضحة؛ كتابة دالة محددة بمدخلات/مخرجات؛ مراجعة كود مقابل سيناريو في المواصفات.

**ممنوع:** "سوِّ نظام HR كامل"؛ "أضف كل شيء"؛ "كمّل النظام"؛ "ابنِ الصفحات كلها"؛ "شوف وش يحتاج وأضفه"؛ "أضف ميزة تشوفها مناسبة". كل ما يعطي الذكاء الاصطناعي صلاحية القرار أو يتجاوز المواصفات = مرفوض.

# منطق costBearer (تفريع، لا تسمية)

`costBearer` (company/driver/insurance/customer/tenant/third_party) ليس حقلًا وصفيًا — هو **تفريع للقيد** يُفعّل تدفقات حوكمة. مثال: إصلاح بسبب السائق ← ذمة موظف + مطالبة HR + مخالفة أسطول، **لا** مصروف شركة.

# نموذج الحقيقة التشغيلية

المستخدم يتعامل مع الحقيقة التشغيلية فقط (ماذا حدث، لمن، من تسبب). الحقيقة التجارية تُدخل جزئيًا. الحقيقة المحاسبية تُشتق بالكامل من الاختيارات الأعلى — مستخدمو غير المالية لا يلمسون الحسابات أبدًا.