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

# بوابة مراجعة نظام غيث

الهدف: مراجعة أي عمل (PR / صفحة / خدمة / إجراء) في نظام غيث على **ثلاث طبقات** (الطبقة 0: الامتثال للدستور، ثم اليقيني، ثم المجلس)، ثم إصدار حكم عربي منظّم.
القاعدة الذهبية: **تدقيق ضد الكود الفعلي، لا ضد ملخصات الوكلاء.** افتح الملفات والـ diff بنفسك قبل أي حكم.

## الطبقة 0 — الامتثال للدستور (المرجع الأعلى)

**المرجع:** [`docs/ghayth-constitution.md`](../../../docs/ghayth-constitution.md) — دستور غيث v3 (معتمد · مجمّد)، المرجع الأعلى لطبقة 0.

قبل أي طبقة لاحقة: اقرأ الدستور وتحقّق أن العمل لا يخالف أي بند منه. **أي عمل يخرق بندًا من الدستور = يُرفض فورًا (stop-ship) ولا يُدمج**، مهما نجح في الطبقتين 1 و2. انتبه خصوصًا إلى: استقلال المسارات وقفل الحدود الخدمية (المواد 4–9)، مصدر الحقيقة الواحد (9)، العزل متعدد الشركات (13)، المعمارية المالية ومنع الترحيل على الحسابات الأب والـ fallback الصامت (16–17)، منع الحذف الفيزيائي (18)، والقواعد المعمارية والعشر الملزمة (15، 20). نتيجة هذه الطبقة قاطعة: **PASS** (متوافق) أو **FAIL** (مخالف للدستور).

## الطبقة الأولى — التحقق اليقيني (PASS / FAIL)

أشياء تُتحقَّق بيقين، لا تُترك للتقدير. شغّل ما أمكن، وما لا يمكن تشغيله سجّله كـ "غير مُتحقَّق" بدل تخمينه.

1. **صحة الكود:** هل يبني (build) ويمر type-check بدون أخطاء؟ هل هناك كود ميت أو مستورد بلا استخدام؟
2. **تطابق الواجهة مع الـ backend:** كل زر/إجراء في الواجهة مربوط بـ endpoint حقيقي. لا أزرار ميتة، لا صفحات وهمية، لا handlers ميتة. (راجع نتائج `check-frontend-backend-wiring.mjs`.)
3. **السلامة المعمارية الآلية:** صفر كتابات عابرة للنطاقات، صفر اختراق حدود. (راجع `audit-domain-boundaries.mjs` و`audit-stop-ship.mjs` و`audit-event-bus.mjs`.)
4. **فعلية الخوارزميات:** هل المنطق يطلّع نتيجة صحيحة فعلاً على بيانات حقيقية؟ أي تغيير يمس القيود (ledger) يلزمه اختبار assertion على سطور القيد — لا اعتماد بدون ذلك.
5. **السرعة:** لا استعلامات N+1 واضحة، لا جلب بيانات زائد، لا حلقات تكلفتها مخفية على الواجهة.
6. **الهجرات (migrations):** لا أرقام مكررة، الهجرة idempotent، ولا فقد لأي seed.

> ملاحظة: الطبقة الأولى **لا تحتاج مجلس LLM** — تحتاج سكربتات واختبارات. النتيجة قاطعة: PASS أو FAIL.
> فجوة معروفة: اختبار سلوكي للواجهة (frontend) غير موجود بعد — أي مراجعة واجهة تُعلَّم "ناقصة الاختبار".

## الطبقة الثانية — مراجعة الحكم والتقدير

أشياء لا إجابة قاطعة فيها، تحتاج تقييمًا. قيّم كل بند من 1 إلى 5 مع سبب وملف مرجعي:

1. **تجربة المستخدم:** هل المسار واضح؟ كم نقرة لإتمام الإجراء؟ هل الأخطاء مفهومة؟ هل الحالة (loading / فارغ / خطأ) معالَجة؟
2. **سهولة إتمام الإجراء من الواجهة:** هل يصل المستخدم لنتيجته دون التواء؟ أم يحتاج خطوات أو شاشات زائدة؟
3. **اكتشاف الخدمة وسهولة الوصول:** هل الخدمة ظاهرة وسهلة الإيجاد؟ هل آلية تفعيلها وعملها واضحة للمستخدم بدون شرح خارجي؟
4. **اتساق المصطلحات العربية:** المصطلحات عربية بالكامل وموحّدة مع بقية النظام (نفس الكلمة لنفس المفهوم عبر كل المسارات). لا خلط عربي/إنجليزي في واجهة المستخدم.
5. **السلامة المعمارية كقرار:** هل البند يحترم مبدأ "المسار القائد / المسار الخادم"؟ هل يبقى المسار قابلًا للتشغيل المستقل؟ لا نقل سياسة أو قرار بين المسارات.
6. **قوة التشغيل:** ماذا يحدث عند الفشل الجزئي، أو غياب صلاحية، أو بيانات ناقصة؟ هل يفشل بهدوء وأمان أم ينهار؟

### المجلس — مراجعة Claude متعددة الأدوار (الوضع المعتمد للطبقة 2)

الطبقة 2 = **مجلس يؤدّيه Claude (أنت) بأدوار متعددة** على نفس الـ diff، بلا أي مفتاح API وبلا تكلفة. هذا هو الوضع المعتمد — **لا يوجد "منقوص" ولا fallback**؛ مجلس Claude متعدد الأدوار هو الأصل.

راجع الـ diff عبر **أربع عدسات خبيرة مستقلة**، كل عدسة تقيّم محاورها (1–5 مع سبب وملف)، ثم **ركّب حكمًا نهائيًا كرئيس**:

1. **عدسة معمارية:** حدود المسارات واستقلالها، القائد/الخادم، مصدر الحقيقة الواحد (SSOT)، مبدأ الأحداث (Event First)، الكيانات الجذرية المعتمدة. (دستور: مواد 4–11.)
2. **عدسة الدفتر:** GL/Subledger/Dimensions، منع الترحيل على الحسابات الأب (`allowPosting=false`)، لا fallback صامت، تشعيب `costBearer`، اختبار assertion على سطور القيد. (دستور: مواد 16–17.)
3. **عدسة أمان وعزل:** RBAC يتبع التعيين، كل `SELECT` بفلتر صلاحيات + `companyId` predicate، منع الحذف الفيزيائي. (دستور: مواد 13–14، 18.)
4. **عدسة واجهة:** فصل المنطق عن الواجهة، الاختيار المتسلسل، «الأثر المتوقع» قبل الحفظ، لا صفحات منبثقة، اتساق المصطلحات العربية. (دستور: مواد 12، 15.)

**التركيب (الرئيس):** ادمج العدسات الأربع، أبرز الإجماع والخلاف، ثم أصدر الحكم النهائي (يُعتمد / يُعتمد بشرط / يُرفض) بصيغة المخرج أدناه. كل عدسة بزاوية مختلفة فعلًا — لا تكرّر نفس الرأي أربع مرات.

> ملاحظة: سكربت `scripts/src/council.mjs` (مجلس OpenRouter متعدد النماذج بمفتاح مدفوع) يبقى خاملًا في المستودع لمسار مستقبلي اختياري — **ليس مطلوبًا** ولا يُستدعى في CI. المجلس الفعلي يؤدّيه Claude هنا.

## صيغة المخرج (إلزامية)

```
## حكم المراجعة: [اسم العمل / رقم الـ PR]

### الطبقة 0 — الامتثال للدستور
- المرجع: docs/ghayth-constitution.md
- النتيجة: ✅ متوافق / ❌ مخالف — [البند المخالف إن وُجد + سبب]

### الطبقة الأولى — يقيني
- صحة الكود: ✅/❌ — [سبب + ملف]
- تطابق الواجهة: ✅/❌ — ...
- الحدود المعمارية: ✅/❌ — ...
- فعلية الخوارزمية: ✅/❌ — ...
- السرعة: ✅/❌ — ...
- الهجرات: ✅/❌ — ...

### الطبقة الثانية — حكم (1–5)
- تجربة المستخدم: ⭐ — [سبب]
- سهولة الإجراء: ⭐ — ...
- اكتشاف الخدمة: ⭐ — ...
- اتساق المصطلحات العربية: ⭐ — ...
- السلامة المعمارية: ⭐ — ...
- قوة التشغيل: ⭐ — ...

### القرار النهائي
[ يُعتمد / يُعتمد بشرط / يُرفض ] + الأسباب الموقفة (stop-ship) إن وُجدت.

### رسالة جاهزة للوكيل (عربي)
[ نص مختصر ينسخه إبراهيم ويلصقه للوكيل المنفّذ ]
```

## قواعد صارمة

- أي تغيير يمس القيود (ledger) بدون اختبار assertion = **رفض فوري**، مهما بدا صحيحًا.
- لا تجاوز للحرّاس (guard override) في عمل يمس قاعدة البيانات.
- إن لم تستطع التحقق من شيء، اكتب "غير مُتحقَّق" — لا تخمّن.
- الصرامة قبل السرعة: أي "حل سريع" يخترق حدود المسارات = خطأ معماري حتى لو اشتغل وظيفيًا.