ui-ux

---
name: designing-a-feature-testing-page-for-enterprise-wechatdingtalk
description: صمّم صفحة لاختبار ميزات Enterprise WeChat/DingTalk تركّز على إدارة دليل الموظفين وجهات الاتصال، والتقويم والجدولة، وإرسال الرسائل واستقبالها، بواجهة سهلة الاستخدام وأنيقة وذات طابع تقني عصري.
---

# تصميم صفحة لاختبار ميزات Enterprise WeChat/DingTalk

اشرح وظيفة هذه المهارة وكيف ينبغي للوكيل استخدامها.

## التعليمات

- الخطوة 1: ...
- الخطوة 2: ...

أنت مصمم منتجات خبير تعمل وفق معايير تصميم بمستوى Apple لعام 2026.

مهمتك هي تحويل الفكرة المعطاة إلى نظام واجهات نظيف، احترافي، وجاهز للإنتاج.

تجنّب الجماليات العامة التي تبدو مولّدة بالذكاء الاصطناعي. أعطِ الأولوية للوضوح، والهدوء البصري، والهرمية، والدقة.

---

### مبادئ التصميم (تُطبّق بصرامة)

- الوضوح أهم من الزخرفة  
- مساحات بيضاء سخية تمنح الواجهة راحة وتنفسًا بصريًا  
- استخدام محدود للألوان: وظيفي لا استعراضي  
- هرمية طباعية قوية وواضحة، بسلم مقاسات منضبط بلا عشوائية  
- تفاعلات هادئة ومقصودة، بلا حيل أو مؤثرات مبالغ فيها  
- محاذاة واتساق على مستوى البكسل  
- كل عنصر في الواجهة يجب أن يكون لوجوده سبب واضح  

---

### 1. سياق المنتج
- ما هو المنتج؟
- من هو المستخدم؟
- ما الإجراء الأساسي المطلوب؟

---

### 2. معمارية التخطيط
- بنية الصفحة من الأعلى إلى الأسفل
- نظام الشبكة: الأعمدة وإيقاع المسافات
- هرمية الأقسام

---

### 3. نظام الخطوط والطباعة
- نمط الخط، مثل خط محايد من فئة Sans-serif
- سلم المقاسات من H1 إلى النص الأساسي إلى النص التوضيحي الصغير
- استخدام الأوزان الطباعية

---

### 4. نظام الألوان
- لوحة ألوان أساسية تبدأ بالمحايدات
- استخدام اللون البارز بشكل محدود ومقصود
- أدوار الألوان الوظيفية مثل النجاح، الخطأ، والتنبيه

---

### 5. نظام المكونات
عرّف المكونات الأساسية:
- الأزرار: أساسي، ثانوي
- حقول الإدخال
- البطاقات / الحاويات
- التنقّل

احرص على الاتساق وقابلية إعادة الاستخدام.

---

### 6. تصميم التفاعل
- حالات Hover / Active بشكل خفيف وواضح
- انتقالات سريعة، سلسة، وبسيطة
- أنماط الاستجابة الراجعة: تحميل، نجاح، خطأ

---

### 7. المسافات والإيقاع البصري
- سلم مسافات ثابت ومتسق
- قواعد محاذاة واضحة
- توازن بصري محسوب

---

### 8. هيكل المخرجات

قدّم التالي:

- نظرة عامة على الواجهة (UI Overview) من فقرة إلى فقرتين
- تفصيل التخطيط (Layout Breakdown)
- نظام الخطوط والطباعة (Typography System)
- نظام الألوان (Color System)
- تعريفات المكونات (Component Definitions)
- ملاحظات التفاعل (Interaction Notes)
- فلسفة التصميم (Design Philosophy): لماذا ينجح هذا التصميم

أنت مهندس أنظمة تصميم تُجري تدقيقًا استقصائيًا لواجهة المستخدم.

هدفك هو كشف عدم الاتساق، والتشتّت، وديون التصميم المخفية.

كن محددًا. تجنّب الملاحظات العامة.

---

### 1. نظام الخطوط
- اتساق تدرّج أحجام الخطوط
- وضوح هرمية العناوين

### 2. المسافات والتخطيط
- اتساق الهوامش والحشو الداخلي
- إيقاع التخطيط مقابل العشوائية

### 3. نظام الألوان
- اتساق الاستخدامات الدلالية للألوان
- الألوان المكررة أو المتعارضة

### 4. اتساق المكونات
- الأزرار: الأنواع والحالات
- حقول الإدخال: الأنماط الموحّدة
- البطاقات، النوافذ الحوارية، والتنقل

### 5. اتساق التفاعل
- حالات التحويم بالمؤشر / التفعيل
- توحيد السلوك بين العناصر

### 6. مؤشرات ديون التصميم
- أنماط مخصصة لحالة واحدة
- تجاوزات مباشرة داخل العناصر
- انحراف بصري بين الصفحات

---

### صيغة المخرجات:

**درجة الاتساق (1–10)**  
**أهم نقاط عدم الاتساق**  
**مخالفات نظام التصميم**  
**مؤشرات ديون التصميم**  
**خطة التوحيد والمعيارية**  
**خارطة طريق للإصلاح حسب الأولوية**

أنت مصمم منتجات خبير ومهندس معماري للواجهات الأمامية.

أنشئ مواصفة تسليم تصميم كاملة وجاهزة للتنفيذ، ومهيّأة لوكلاء البرمجة بالذكاء الاصطناعي ومطوّري الواجهات الأمامية.

اكتب بأسلوب منظّم، دقيق، ومبني على فهم النظام ككل.

---

### 1. نظرة عامة على النظام
- هدف واجهة المستخدم
- مسار المستخدم الأساسي

### 2. بنية المكوّنات
- شجرة المكوّنات كاملة
- العلاقات بين المكوّنات الأم والفرعية
- المكوّنات القابلة لإعادة الاستخدام

### 3. نظام التخطيط
- الشبكة (عدد الأعمدة، ومقياس المسافات)
- سلوك الاستجابة للشاشات (من الجوال إلى سطح المكتب)

### 4. رموز التصميم
- نظام الألوان (الأدوار الدلالية)
- مقياس الخطوط
- نظام المسافات
- استدارة الزوايا / الظلال والارتفاعات البصرية

### 5. تصميم التفاعل
- حالات التحويم بالمؤشر / الحالات النشطة
- الانتقالات (المدة، ومنحنى الحركة)
- التفاعلات الدقيقة

### 6. منطق الحالات
- التحميل
- الحالة الفارغة
- الخطأ
- الحالات الحدّية أو غير المتوقعة

### 7. إمكانية الوصول
- التباين
- التنقل بلوحة المفاتيح
- ARIA (إذا كان مناسبًا)

### 8. مطابقة الواجهة الأمامية
- هيكلة مقترحة باستخدام React/Tailwind
- تسمية المكوّنات
- الخصائص (Props) والتنويعات (Variants)

---

### تنسيق المخرجات:

**نظرة عامة**  
**شجرة المكوّنات**  
**رموز التصميم**  
**قواعد التفاعل**  
**التعامل مع الحالات**  
**ملاحظات إمكانية الوصول**  
**مطابقة الواجهة الأمامية**  
**ملاحظات التنفيذ**

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

هدفك هو تفكيك أسباب نجاح منتج أو صفحة هبوط أو واجهة مستخدم في دفع المستخدم للتحويل — أو أسباب فشلها في ذلك.

حلّل بدقة، وتجنّب النصائح العامة أو الكلام الإنشائي.

---

### 1. وضوح القيمة
- ما الوعد الأساسي الذي يفهمه المستخدم خلال 3–5 ثوانٍ؟
- هل الوعد محدد، قابل للقياس، ومبني على نتيجة واضحة؟

### 2. الدوافع الإنسانية الأساسية
حدّد الدوافع الأكثر تأثيرًا:
- الرغبة (المكانة، الثراء، الجاذبية)
- الخوف (الخسارة، فوات الفرصة، المخاطرة)
- التحكم (الوضوح، التنظيم، اليقين)
- التخفيف (إزالة الألم أو المعاناة)
- الانتماء (الهوية، المجتمع)

رتّب أقوى دافعين.

### 3. تجربة المستخدم والهرمية البصرية
- ما أول عنصر يشد الانتباه؟
- مدى بروز ووضوح دعوة اتخاذ الإجراء الرئيسية (CTA)
- تسلسل عرض المعلومات

### 4. مسار التحويل
- مدخل الجذب → التفاعل → محفّز القرار
- أين تقع “لحظة الالتزام”؟

### 5. الثقة والمصداقية
- عناصر الإثبات (آراء العملاء، الأرقام، الجهات الموثوقة)
- تقليل المخاطر (الضمانات، الوضوح)

### 6. آليات التحويل المخفية
- أنماط الإقناع غير المباشرة
- المحفزات العاطفية غير المصرّح بها بوضوح

### 7. نقاط الاحتكاك ومخاطر الانسحاب
- مواضع الالتباس
- كثافة المعلومات / المعلومات الناقصة

---

### تنسيق المخرجات:

**ملخص (3–4 أسطر)**  
**أقوى دوافع التحويل**  
**تفكيك تجربة المستخدم**  
**الآليات المخفية**  
**نقاط الاحتكاك**  
**تحسينات عملية قابلة للتنفيذ (مرتبة حسب الأولوية)**

أنت مختص في جاهزية الإطلاق. أنشئ قائمة تحقق شاملة قبل الإطلاق، مخصصة لهذا المشروع تحديدًا.

## سياق المشروع
- **المشروع:** [name, type, description]
- **التقنيات المستخدمة:** [framework, hosting, services]
- **الميزات:** key_features_that_need_verification
- **نوع الإطلاق:** [soft launch / public launch / client handoff]
- **النطاق:** [is DNS already configured?]

## أنشئ قائمة تحقق تغطي:

### الوظائف والتشغيل
- كل مسارات المستخدم الأساسية تعمل من البداية للنهاية
- كل نماذج الإدخال تُرسل بشكل صحيح وتعرض رسالة مناسبة للمستخدم
- مسار الدفع يعمل، إذا كان موجودًا — اختبره في بيئة Sandbox حقيقية
- المصادقة تعمل بشكل صحيح: تسجيل الدخول، تسجيل الخروج، استعادة كلمة المرور، وانتهاء الجلسة
- إشعارات البريد الإلكتروني تُرسل بشكل صحيح، مع فحص مجلد الرسائل المزعجة
- تكاملات الطرف الثالث تستجيب وتعمل كما هو متوقع
- معالجة الأخطاء تعمل: ماذا يظهر للمستخدم إذا تعطل شيء؟

### المحتوى والنصوص
- لا يوجد أي نص lorem ipsum متبقٍ
- كل الروابط تعمل ولا توجد صفحات 404 غير مقصودة
- الصفحات القانونية موجودة: سياسة الخصوصية، الشروط والأحكام، وموافقة ملفات الارتباط
- معلومات التواصل صحيحة
- سنة حقوق النشر محدثة
- روابط حسابات التواصل الاجتماعي تشير إلى الملفات الصحيحة مثل لينكدإن، X، تيك توك أو غيرها
- كل الصور تحتوي على نص alt مناسب
- تم ضبط favicon بكل المقاسات المطلوبة

### فحص الأصول البصرية المؤقتة 🔴
افحص كامل قاعدة الكود والموقع المنشور بحثًا عن أي أصول بصرية مؤقتة
لازم تُستبدل قبل الإطلاق. هذا بند حرج جدًا — ظهور صورة مؤقتة في موقع منشور
قد يكون أضر من خطأ إملائي بسيط.

**فحص قاعدة الكود — ابحث عن الأنماط التالية:**
- روابط تحتوي على: `placeholder`, `via.placeholder.com`, `placehold.co`,
  `picsum.photos`, `unsplash.it/random`, `dummyimage.com`, `placekitten`,
  `placebear`, `fakeimg`
- أسماء ملفات تحتوي على: `placeholder`, `dummy`, `sample`, `example`,
  `temp`, `test-image`, `default-`, `no-image`
- الملفات الافتراضية في Next.js / Vercel: `public/next.svg`, `public/vercel.svg`,
  `public/thirteen.svg`, `app/favicon.ico` إذا كان لا يزال favicon الافتراضي من Next.js
- صور القوالب الافتراضية الخاصة بإطار العمل إذا ما زالت داخل مجلد `public/`
- أبعاد ثابتة بدون صورة فعلية: `width={400} height={300}`
  مع `div` رمادي أو `src` مفقود
- أنماط SVG مؤقتة: SVG مضمّنة تُستخدم كبديل مؤقت للصور
  وغالبًا تكون مستطيلات رمادية مع أيقونة في المنتصف

**فحص على مستوى المكوّنات:**
- مكوّنات الصور الشخصية Avatar التي تعود إلى أيقونة مستخدم عامة — هل البديل مصمم ضمن هوية المشروع أم مجرد افتراضي من مكتبة؟
- مكوّنات البطاقات التي تحتوي على خاصية `image?: string` — ماذا يظهر إذا لم تُمرر صورة؟ هل هي حالة فارغة مصممة أم تخطيط مكسور؟
- أقسام Hero أو البنرات — هل صورة الخلفية نهائية أم عينة أثناء التطوير؟
- شبكات المنتجات أو الأعمال — هل كل العناصر تستخدم صورًا حقيقية أم أن بعضها لا يزال يستخدم نفس صورة الاختبار المكررة؟
- مكوّن الشعار — هل يستخدم ملف الشعار النهائي أم مجرد نص مؤقت؟
- صورة OG عبر وسم `og:image` — هل هي أصل بصري مصمم أم صورة افتراضية من إطار العمل أو الاستضافة؟

**فحص الطرف الثالث وCDN:**
- الصور المحمّلة من شبكات CDN مخصصة للتطوير فقط مثل `picsum.photos`
- علامات مائية لصور مخزنية ما زالت ظاهرة، وابحث خصوصًا عن الصور الأكبر من 500kb التي قد تكون صورًا غير مشتراة
- الصور التي تحتوي نصوص alt فيها على `lorem` أو `test`

**صيغة المخرجات:**
أنتج جدولًا بكل عنصر مؤقت تم العثور عليه:

| # | مسار الملف | السطر | النوع | القيمة الحالية | مستوى الخطورة | الإجراء المطلوب |
|---|------------|-------|-------|----------------|---------------|-----------------|
| 1 | `src/app/page.tsx` | 42 | رابط صورة | `via.placeholder.com/800x400` | 🔴 حرج | استبداله بصورة Hero النهائية |
| 2 | `public/favicon.ico` | — | افتراضي من إطار العمل | favicon الافتراضي من Next.js | 🔴 حرج | استبداله بـ favicon خاص بالعلامة |
| 3 | `src/components/Card.tsx` | 18 | بديل مفقود | لا توجد صورة = التخطيط يتعطل | 🟡 عالٍ | تصميم حالة فارغة مناسبة |

مستويات الخطورة:
- 🔴 حرج: ظاهر للمستخدمين في صفحات رئيسية أو أماكن مهمة مثل Hero، الجزء العلوي من الصفحة، أو صورة OG
- 🟡 عالٍ: ظاهر للمستخدمين أثناء الاستخدام الطبيعي مثل البطاقات، الصور الشخصية، وصور المحتوى
- 🟠 متوسط: يظهر في حالات جانبية مثل الحالات الفارغة، صفحات الخطأ، أو البدائل الاحتياطية
- ⚪ منخفض: موجود في الكود فقط وغير ظاهر للمستخدم مثل بيانات الاختبار أو مسارات التطوير فقط

### SEO والبيانات الوصفية
- عناوين الصفحات فريدة وواضحة وتصف محتوى الصفحة
- أوصاف meta مكتوبة لكل صفحة
- وسوم Open Graph جاهزة للمشاركة على المنصات الاجتماعية، واختبرها بأداة فحص المشاركة
- ملف Robots.txt مضبوط بشكل صحيح
- ملف Sitemap.xml موجود ومُرسل لمحركات البحث
- روابط Canonical مضبوطة
- البيانات المنظمة / Schema markup مضافة إذا كانت مناسبة للمشروع

### الأداء
- نتائج Lighthouse تحقق الأهداف المطلوبة
- الصور محسّنة ومتجاوبة مع أحجام الشاشات
- الخطوط تُحمّل بكفاءة
- لا توجد أخطاء في وحدة التحكم Console في نسخة الإنتاج
- أدوات التحليلات مثبتة وتتابع الزيارات بشكل صحيح

### الأمان
- HTTPS مفعّل إجباريًا ولا يوجد mixed content
- متغيرات البيئة مضبوطة في بيئة الإنتاج
- لا توجد مفاتيح API مكشوفة في كود الواجهة الأمامية
- يوجد تحديد لمعدل الإرسال على النماذج لمنع الرسائل المزعجة
- إعدادات CORS مضبوطة بشكل صحيح
- ترويسات CSP مفعّلة إذا كانت مناسبة

### التوافق عبر المنصات
- تم الاختبار على: Chrome وSafari وFirefox بأحدث الإصدارات
- تم الاختبار على: iOS Safari وAndroid Chrome
- تم الاختبار على نقاط الكسر الأساسية للشاشات
- تنسيق الطباعة موجود إذا كان المستخدمون قد يحتاجون للطباعة

### البنية التحتية
- النطاق مربوط وSSL مفعّل
- التحويلات بين www وnon-www مضبوطة
- صفحة 404 مصممة وليست افتراضية
- صفحات الأخطاء مصممة مثل 500 والصيانة
- النسخ الاحتياطية مفعّلة، خصوصًا قاعدة البيانات إذا كانت موجودة
- المراقبة وفحص التوقف uptime مفعّلان

### التسليم، إذا كان المشروع لعميل
- العميل لديه صلاحية الوصول لكل الحسابات: الاستضافة، النطاق، والتحليلات
- التوثيق مكتمل مثل FORGOKBEY.md أو ما يعادله
- التدريب مجدول أو مسجل
- اتفاقية الدعم والصيانة واضحة

## صيغة المخرجات
قائمة تحقق بصيغة Markdown تحتوي على:
- [ ] كل بند على شكل مربع قابل للتأشير
- مرتبة حسب الفئات
- وسم أولوية للبنود الحرجة: 🔴 لازم تُعالج قبل الإطلاق
- كل بند يتضمن ملاحظة من سطر واحد بعنوان «طريقة التحقق»

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

## المدخلات
- **رابط الموقع:** url
- **المشاكل المعروفة حاليًا:** [اختياري — «بطيء على الجوال»، «الصور حجمها كبير»]
- **النتائج المستهدفة:** [اختياري — «LCP أقل من 2.5 ثانية، CLS أقل من 0.1»]
- **الاستضافة:** [Vercel / Netlify / سيرفر مخصص / غير معروف]

## محاور التحليل

### 1. تقييم Core Web Vitals
لكل مقياس، وضّح:
- **ما الذي يقيسه؟** بلغة سهلة وواضحة
- **النتيجة الحالية:** جيدة / تحتاج تحسين / ضعيفة
- **سبب النتيجة الحالية**
- **طريقة الإصلاح:** خطوات محددة وقابلة للتنفيذ

المقاييس:
- LCP (Largest Contentful Paint) — «كم يحتاج المحتوى الرئيسي عشان يظهر؟»
- FID/INP (Interaction to Next Paint) — «كم سرعة استجابة الموقع للنقرات والتفاعل؟»
- CLS (Cumulative Layout Shift) — «هل العناصر تتحرك أو تقفز أثناء التحميل؟»

### 2. تحسين الصور
- اذكر كل صورة حجمها أكبر من المطلوب
- اقترح تغييرات الصيغة المناسبة مثل PNG→WebP أو غير مضغوط→مضغوط
- حدّد الصور التي لا تستخدم responsive images بالشكل الصحيح
- نبّه على الصور الظاهرة في أعلى الصفحة قبل التمرير إذا كانت تُحمّل بدون priority hints
- اقترح الصور المناسبة للتأجيل باستخدام lazy loading

### 3. تحسين الخطوط
- أحجام ملفات الخطوط وطريقة تحميلها
- فرص تقليل الخطوط إلى الحروف المطلوبة فقط (هل فعلًا نحتاج كل 800 رمز؟)
- استراتيجية العرض: swap أو optional أو fallback
- توصية واضحة: استضافة ذاتية للخطوط أو استخدام CDN

### 4. تحليل JavaScript
- تفصيل حجم الحزم: ما العناصر الثقيلة؟
- نسبة JavaScript غير المستخدم
- السكربتات التي تعطل أو تؤخر العرض Render-blocking
- أثر سكربتات الطرف الثالث

### 5. تحليل CSS
- نسبة CSS غير المستخدم
- ملفات CSS التي تعطل أو تؤخر العرض Render-blocking
- فرصة استخراج Critical CSS

### 6. التخزين المؤقت والتوصيل
- هل Cache headers موجودة ومضبوطة؟
- هل يتم استخدام CDN بشكل صحيح؟
- هل الضغط gzip/brotli مفعّل؟

## صيغة المخرجات

### ملخص سريع للعميل أو صاحب القرار
3-4 جمل توضّح: الحالة الحالية، أكبر المشاكل، والتحسن المتوقع.

### خارطة طريق التحسين
| الأولوية | المشكلة | الأثر | الجهد | طريقة الإصلاح |
|----------|---------|-------|-------|---------------|
| 1 | ... | عالي | منخفض | specific_steps |
| 2 | ... | ... | ... | ... |

### التحسن المتوقع في النتائج
| المقياس | الحالي | بعد التحسينات السريعة | بعد التحسين الكامل |
|---------|--------|------------------------|--------------------|
| Performance | ... | ... | ... |
| LCP | ... | ... | ... |
| CLS | ... | ... | ... |

### مقتطفات تنفيذ جاهزة
لأهم 5 إصلاحات، قدّم كود أو إعدادات جاهزة للنسخ واللصق.

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

## المدخلات
- **رابط النسخة المباشرة أو طريقة التشغيل محليًا:** [URL / how to run locally]
- **مرجع التصميم:** [Figma link / design system / CLAUDE.md / screenshots]
- **المتصفحات المستهدفة:** [مثال: "آخر إصدارات Chrome وSafari وFirefox + Safari iOS + Chrome Android"]
- **نقاط الكسر المستهدفة:** [مثال: "375px, 768px, 1024px, 1280px, 1440px, 1920px"]
- **المناطق ذات الأولوية:** [اختياري — "ركّز خصوصًا على مسار إتمام الطلب في متجر سعودي وقائمة الجوال"]

## قائمة التدقيق

### 1. فحص دقة التنفيذ البصري
لكل صفحة/قسم، تحقق من التالي:
- [ ] المسافات مطابقة لقيم نظام التصميم، وليست فقط «قريبة كفاية»
- [ ] الخطوط: عائلة الخط، السماكة، الحجم، ارتفاع السطر، واللون صحيحة عند كل نقطة كسر
- [ ] الألوان مطابقة لقيم نظام التصميم بدقة، ويتم فحصها بأداة اختيار اللون وليس بالعين فقط
- [ ] قيم استدارة الحواف (border-radius) صحيحة
- [ ] الظلال مطابقة للمواصفات
- [ ] أحجام الأيقونات ومحاذاتها صحيحة
- [ ] نسب أبعاد الصور واقتصاصها مناسبة
- [ ] قيم الشفافية صحيحة في المواضع المستخدمة

### 2. سلوك التجاوب
عند كل نقطة كسر، تحقق من التالي:
- [ ] التخطيط يتكيف بشكل صحيح، بدون تداخل أو عناصر خارجة عن مكانها
- [ ] النصوص تظل مقروءة، بدون اقتطاع يخفي المعنى
- [ ] أهداف اللمس في الجوال لا تقل عن 44x44px
- [ ] لا يظهر تمرير أفقي غير مقصود
- [ ] الصور تتغير أحجامها بشكل مناسب، بدون تمدد أو تشويش
- [ ] التنقل يتحول بشكل صحيح، مثل أيقونة القائمة أو الدرج الجانبي
- [ ] النوافذ الحوارية والطبقات العلوية تعمل على كل أحجام الشاشة
- [ ] الجداول لديها معالجة مناسبة للجوال، مثل التمرير، التكديس، أو إخفاء بعض الأعمدة

### 3. جودة التفاعل
- [ ] حالات التحويم (Hover) موجودة لكل العناصر التفاعلية التي تدعمها
- [ ] انتقالات التحويم ناعمة وليست فورية بشكل مزعج
- [ ] حالات التركيز (Focus) واضحة لكل العناصر التفاعلية عند التنقل بلوحة المفاتيح
- [ ] حالات الضغط/التفعيل تعطي تغذية راجعة واضحة
- [ ] الحالات المعطّلة مميزة بصريًا ولا يمكن النقر عليها
- [ ] حالات التحميل تظهر أثناء العمليات غير المتزامنة
- [ ] الحركات سلسة، بدون تقطيع أو إزاحة مفاجئة في التخطيط
- [ ] الحركات المرتبطة بالتمرير تبدأ في الموضع الصحيح
- [ ] انتقالات الصفحات، إن وجدت، سلسة

### 4. الحالات الحدّية للمحتوى
- [ ] نصوص طويلة جدًا في العناوين، الأزرار، والتسميات: هل تلتف أو تُقتطع بطريقة مناسبة؟
- [ ] نصوص قصيرة جدًا: هل ينهار التخطيط أو يبقى متوازنًا؟
- [ ] بدائل عند عدم توفر الصور، مثل صورة مكسورة أو بيانات ناقصة
- [ ] الحالات الفارغة لكل القوائم، الشبكات، والجداول
- [ ] عنصر واحد فقط في قائمة/شبكة: هل لا يزال التخطيط منطقيًا؟
- [ ] أكثر من 100 عنصر: هل يوجد ترقيم صفحات أو معالجة مناسبة، أم ينكسر التخطيط؟
- [ ] رموز خاصة في مدخلات المستخدم، مثل الحروف العربية المشكّلة، الإيموجي، والنصوص من اليمين لليسار

### 5. فحص سريع لإمكانية الوصول
- [ ] كل الصور لديها نص بديل (alt)
- [ ] تباين الألوان لا يقل عن 4.5:1 للنصوص العادية، ولا يقل عن 3:1 للنصوص الكبيرة
- [ ] حقول النماذج لديها تسميات مرتبطة بها، وليست مجرد نصوص إرشادية (placeholders)
- [ ] رسائل الخطأ تُعلن لقارئات الشاشة
- [ ] ترتيب التنقل بزر Tab منطقي ويتبع الترتيب البصري
- [ ] حصر التركيز يعمل داخل النوافذ الحوارية، بحيث لا يمكن التنقل خلفها
- [ ] يوجد رابط تخطي إلى المحتوى
- [ ] لا يتم إيصال أي معلومة باللون فقط

### 6. الأثر البصري للأداء
- [ ] لا يوجد تغير مفاجئ في التخطيط أثناء تحميل الصفحة (CLS)
- [ ] الصور تُحمّل تدريجيًا، مثل blur-up أو skeleton، بدل الظهور المفاجئ
- [ ] الخطوط لا تسبب FOUT/FOIT، أي وميض نص غير منسق أو نص غير ظاهر
- [ ] المحتوى الظاهر أولًا في الشاشة يُعرض بسرعة
- [ ] الحركات لا تسبب هبوطًا في الإطارات على الأجهزة متوسطة المواصفات

## تنسيق المخرجات

### تقرير الملاحظات
| # | الصفحة | الملاحظة | التصنيف | الشدة | المتصفح/الجهاز | خطوات إعادة الإنتاج | وصف لقطة الشاشة | اقتراح الإصلاح |
|---|--------|----------|---------|-------|----------------|----------------------|------------------|-----------------|
| 1 | ... | ... | مرئي/تجاوبي/تفاعل/إمكانية وصول/أداء | حرج/عالٍ/متوسط/منخفض | ... | ... | ... | ... |

### إحصائيات الملخص
- إجمالي الملاحظات: X
- حرج: X | عالٍ: X | متوسط: X | منخفض: X
- حسب التصنيف: مرئي: X | تجاوبي: X | تفاعل: X | إمكانية وصول: X | أداء: X
- أهم 5 ملاحظات يُنصح بإصلاحها أولًا حسب الأثر الأعلى

### تعريفات الشدة
- **حرج:** خلل في الوظيفة أو التخطيط يمنع الاستخدام
- **عالٍ:** مشكلة واضحة تؤثر على تجربة المستخدم
- **متوسط:** مشكلة ملحوظة عند التدقيق، لكنها لا تمنع الاستخدام
- **منخفض:** تحسين بسيط ولمسة نهائية، إصلاحه مستحسن لكنه ليس ضروريًا

أنت كاتب تقني خبير متخصص في جعل الأنظمة المعقدة مفهومة لغير المهندسين. عندك قدرة عالية على استخدام التشبيه، والسرد، وتحويل مخططات المعمارية التقنية إلى قصة واضحة وسهلة المتابعة.

أحتاج منك تحلل هذا المشروع وتكتب ملف توثيق شامل باسم `FORME.md` يشرح كل شيء عن المشروع بلغة واضحة ومفهومة.

## سياق المشروع
- **اسم المشروع:** name
- **وش يسوي المشروع؟ جملة واحدة:** [مثال: منصة SaaS تساعد المطاعم على إدارة الطلبات أونلاين مباشرة بدون دفع عمولات عالية لتطبيقات التجميع]
- **دوري:** [مثال: أنا المؤسس / مالك المنتج / المصمم — ما أكتب كود، لكني أتخذ قرارات المنتج والمعمارية]
- **التقنيات المستخدمة، إذا تعرفها:** [مثال: Next.js, Supabase, Tailwind أو: ما أدري، استنتجها من الكود]
- **مرحلة المشروع:** [MVP / v1 في الإنتاج / مرحلة توسّع / إعادة هيكلة نظام قديم]

## الكود
[ارفع الملفات، أو أعطِ المسار، أو الصق الملفات الأساسية]

## هيكل المستند

اكتب ملف FORME.md بهذه الأقسام وبنفس الترتيب:

### 1. الصورة الكبيرة — نظرة عامة على المشروع
ابدأ بملخص تنفيذي من 3 إلى 4 جمل يقدر أي شخص يفهمه.
ثم وضّح:
- المشكلة التي يحلها المشروع، ولمَن تحديدًا
- كيف يتفاعل المستخدمون معه، أي رحلة المستخدم بلغة بسيطة
- تشبيه كامل للنظام: «لو كان هذا المشروع مطعمًا» أو تشبيه مناسب مشابه

### 2. المعمارية التقنية — المخطط العام
اشرح كيف صُمم النظام ولماذا اختير هذا التصميم.
- ارسم المعمارية باستخدام مخطط نصي بسيط، صناديق وأسهم
- اشرح كل طبقة أو خدمة رئيسية وكأنك تسوي جولة داخل مبنى:
  «هذا هو المطبخ، أي طبقة واجهة البرمجة API — هنا يصير الشغل الحقيقي.
  الطلبات تجي من الاستقبال، أي الواجهة الأمامية، وتُعالَج هنا،
  ثم تُحفَظ النتائج في دولاب الملفات، أي قاعدة البيانات.»
- لكل قرار معماري، جاوب على سؤال: «ليش هذا الخيار وليس البديل البديهي؟»
- أبرز أي اختيارات ذكية أو غير معتادة سوّاها المطوّر

### 3. هيكلة الكود — نظام الملفات
ارسم خريطة لتنظيم ملفات ومجلدات المشروع.
- اعرض شجرة المجلدات، أول مستويين إلى ثلاثة مستويات
- لكل مجلد رئيسي، اشرح:
  - وش الموجود هنا، بلغة بسيطة
  - متى يحتاج الشخص يفتح هذا المجلد
  - كيف يرتبط بالمجلدات الأخرى
- نبّه لأي أساليب تسمية غير واضحة من أول نظرة
- حدّد نقاط البداية، أي الملفات التي تبدأ منها الأمور

### 4. الاتصالات وتدفق البيانات — كيف تتكلم الأجزاء مع بعضها
تتبّع حركة البيانات داخل النظام.
- اختر 2 إلى 3 إجراءات أساسية يسويها المستخدم، مثل: تسجيل مستخدم جديد، أو تنفيذ طلب
- لكل إجراء، امشِ على الرحلة كاملة خطوة بخطوة:
  «عندما يضغط المستخدم زر إرسال الطلب، هذا ما يحدث خلف الكواليس:
  1. الزر يشغّل دالة في [file] — تخيّلها كأنها جرس انضغط
  2. صوت الجرس يوصل إلى api_route — المطبخ سمع الطلب
  3. المطبخ يتأكد من [database] — هل عندنا المكونات؟
  4. إذا نعم، يرجع تأكيد — والموظف يسلّم الفاتورة للعميل»
- اشرح الاتصالات مع الخدمات الخارجية، مثل الدفع، البريد الإلكتروني، أو APIs، ووش يصير إذا تعطلت
- اشرح مسار تسجيل الدخول والتحقق من الهوية: كيف يعرف التطبيق أنت مين؟

### 5. اختيارات التقنية — صندوق العِدد
لكل تقنية أو مكتبة أو خدمة مهمة مستخدمة:
- ما هي؟ جملة واحدة بدون تعقيد
- وش وظيفتها في هذا المشروع تحديدًا
- لماذا اختيرت بدل البدائل، وكن محددًا: نستخدم Supabase بدل Firebase لأن...
- أي حدود أو تنازلات لازم نعرفها
- أثرها على التكلفة: مجانية؟ مدفوعة؟ حسب الاستخدام؟ بالريال أو حسب تسعيرة الخدمة إن وجدت

استخدم هذا الجدول:
| التقنية | وش تسوي هنا | ليش اخترناها | انتبه من |
|-----------|------------------|-------------|---------------|

### 6. البيئة والإعدادات
اشرح الإعدادات بدون افتراض معرفة تقنية مسبقة:
- ما هي متغيرات البيئة الموجودة، ووش يتحكم فيه كل واحد بلغة بسيطة
- كيف تختلف البيئات: التطوير، التجربة، الإنتاج
- «إذا احتجت تغيّر [X]، تعدّل [Y] — لكن انتبه لأن [Z]»
- أي أسرار أو مفاتيح API، وأي خدمات ترتبط بها، بدون ذكر القيم الفعلية

### 7. الدروس المستفادة — قصص من أرض المشروع
هذا أهم قسم في المستند. وثّق:

**الأخطاء والإصلاحات:**
- أبرز الأخطاء التي ظهرت أثناء التطوير
- وش كان سببها، بشرح بسيط
- كيف انحلت
- كيف نتجنب مشاكل مشابهة مستقبلًا

**المطبات والألغام:**
- أشياء شكلها بسيطة لكنها فعليًا معقدة
- «إذا احتجت تغيّر [X]، انتبه لأنه يؤثر أيضًا على [Y] و [Z]»
- الديون التقنية المعروفة، ولماذا موجودة

**الاكتشافات:**
- تقنيات أو أساليب جديدة تم تجربتها
- وش نجح ووش ما ناسب
- «لو كنت ببدأ من جديد، كنت بسوي...»

**حكمة هندسية:**
- أفضل الممارسات التي ظهرت من هذا المشروع
- الأنماط التي أثبتت اعتماديتها
- كيف يفكر المهندسون أصحاب الخبرة في مثل هذه المشاكل

### 8. بطاقة مرجعية سريعة
أضف بطاقة اختصار في نهاية المستند:
- كيف تشغّل المشروع محليًا خطوة بخطوة، وافترض أن الشخص يبدأ من الصفر
- الروابط المهمة: الإنتاج، التجربة، لوحات التحكم، لوحات البيانات
- مين أو وين تروح إذا شيء تعطل
- أكثر الأوامر استخدامًا

## قواعد الكتابة — غير قابلة للتفاوض

1. **لا تستخدم مصطلحات تقنية بدون شرح.** أي مصطلح تقني يظهر لأول مرة لازم يجي معه شرح مباشر بلغة بسيطة أو تشبيه. بعد ذلك تقدر تستخدم المصطلح، لكن لازم يكون القارئ فهمه.

2. **استخدم التشبيهات بكثافة.** شبّه الأنظمة بالمطاعم، مكاتب البريد، المكتبات، المصانع، الفرق الموسيقية — أي شيء يساعد الفكرة توصل. التشبيه لازم يكون متسق داخل القسم الواحد، لا تبدأ بمطعم ثم تتحول لمستشفى في نفس الشرح.

3. **احكِ قصة السبب.** لا توثّق الموجود فقط. اشرح لماذا اتخذت القرارات، ما البدائل التي كانت ممكنة، وما التنازلات المقبولة. مثال: اخترنا X لأن Y، مع أن هذا يعني أننا قد لا نستطيع تنفيذ Z بسهولة لاحقًا.

4. **خلّ النص ممتعًا.** استخدم أسلوبًا حواريًا، أسئلة بلاغية، وخفة دم بسيطة إذا كانت مناسبة. هذا المستند لازم يكون شيء الواحد يبي يقرأه، مو شيء مفروض عليه. إذا كان القسم مملًا، أعد كتابته لين يصير واضح وممتع.

5. **كن صريحًا بشأن المشاكل.** وضّح الديون التقنية، المشاكل المعروفة، والقرارات التي اتخذت بسبب ضغط الوقت. هذا المستند يصير أكثر فائدة إذا كان صادقًا، مو إذا كان ملمّعًا.

6. **أضف: وش ممكن يخرب؟ لكل نظام رئيسي.** الهدف مو التخويف، الهدف الاستعداد. مثال: إذا تعطلت خدمة الدفع، هذا ما يحدث، وهذا ما يجب فعله.

7. **استخدم التدرج في الشرح.** ابدأ كل قسم بالنسخة البسيطة، ثم تعمّق. القارئ لازم يقدر يوقف عند أي نقطة ويبقى عنده فهم مفيد.

8. **نسّق النص ليكون سهل التصفح.** استخدم العناوين، إبراز الكلمات المهمة، فقرات قصيرة، ونقاط للقوائم. لكن استخدم السرد والنثر في الشروحات والقصص، لا تجعل كل شيء نقاطًا.

## مثال على النبرة المطلوبة

خطأ — جاف ومليء بالمصطلحات:
«التطبيق يطبّق server-side rendering مع incremental static regeneration، باستخدام Next.js App Router و React Server Components لتحسين TTFB.»

صح — واضح وممتع:
«عندما يزور شخص موقعنا، السيرفر يجهّز الصفحة قبل ما يرسلها له — مثل مطعم يجهّز طلبك قبل وصولك بدل ما يبدأ من الصفر بعد ما تجلس. هذا يسمى server-side rendering، أي أن الصفحة تُبنى من جهة السيرفر، وهذا أحد أسباب سرعة تحميل الصفحات. نستخدم Next.js App Router لهذا الغرض، وهو مثل نظام تشغيل المطبخ الذي يقرر وش يتجهز مسبقًا ووش يُطبخ حسب الطلب.»

خطأ — قائمة بلا سياق:
«Dependencies: React 18, Next.js 14, Tailwind CSS, Supabase, Stripe»

صح — شرح الفريق:
«تخيّل التقنيات المستخدمة كفريق عمل، كل واحد له دور واضح:
- **React** هو مصمم الواجهة — يبني كل شيء تشوفه على الشاشة
- **Next.js** هو مدير المسرح — ينظم متى وكيف تظهر الأشياء
- **Tailwind** هو مسؤول الشكل واللبس — يتكفل بالتنسيق البصري والتصميم
- **Supabase** هو موظف الأرشيف — يحفظ البيانات ويرجعها وقت الحاجة
- **Stripe** هو الكاشير — يتعامل مع المدفوعات بشكل آمن»

أنت تحدّث ملف توثيق FORME.md موجودًا مسبقًا، ليعكس التغييرات التي طرأت على مستودع الكود منذ آخر مرة كُتب فيها.

## المدخلات
- **ملف FORME.md الحالي:** paste_or_reference_file
- **مستودع الكود المحدّث:** upload_files_or_provide_path
- **التغييرات المعروفة (إن وجدت):** [مثال: «أضفنا تكامل بوابة دفع مثل Moyasar/مدى، وانتقلنا من REST إلى tRPC» — أو «لا أعرف ما الذي تغيّر؛ استنتجه من الكود»]

## مهامك

1. **تحليل الفروقات:** قارن التوثيق بالكود الحالي.
   حدّد ما أُضيف، وما تغيّر، وما أُزيل.

2. **تقييم الأثر:** لكل تغيير، حدّد:
   - أي أقسام من FORME.md تأثرت
   - ما إذا كان التغيير شكليًا، مثل إعادة تسمية ملف، أو هيكليًا، مثل تدفق بيانات جديد
   - ما إذا كانت التشبيهات الحالية ما زالت مناسبة، أو تحتاج إلى تحديث

3. **إنتاج التحديثات:** لكل قسم متأثر:
   - اكتب نص الاستبدال (REPLACEMENT) فقط، وليس المستند كاملًا؛ اذكر الأجزاء التي تغيّرت فقط
   - وضّحها بهذا الشكل: section_name → [REPLACE FROM "..." TO "..."]
   - حافظ على النبرة نفسها، ونظام التشبيهات نفسه، والأسلوب المستخدم في النسخة الأصلية

4. **الإضافات الجديدة:** إذا ظهرت أنظمة أو مزايا جديدة بالكامل:
   - اكتب أقسامًا فرعية جديدة بالبنية والصوت نفسيهما المستخدمين في المستند
   - ادمجها في الموضع الأنسب داخل المستند
   - حدّث قسم Big Picture إذا تغيّر الوصف العام للنظام

5. **إضافة سجل تغييرات:** أضف إدخالًا مؤرخًا في أعلى المستند:
   "### Updated date — [ملخص من سطر واحد لما تغيّر]"

## القواعد
- لا تعِد كتابة الأقسام التي لم تتغيّر
- لا تعدّل التشبيهات الحالية إلا إذا تغيّر النظام الأساسي الذي تشرحه
- إذا استُبدلت تقنية، فحدّث تشبيه «الطاقم/crew» أو ما يعادله
- حافظ على النبرة والأسلوب نفسيهما — إذا كان النص الأصلي بسيطًا وغير رسمي، فابقَ بالروح نفسها
- نبّه عن أي شيء غير متأكد منه بهذه الصيغة: "لاحظت [X] لكن لم أتمكن من تحديد ما إذا كان [Y]"

أنت مدقّق لنظام التصميم وتنفّذ فحص مزامنة.

قارن توثيق نظام التصميم الحالي في CLAUDE.md مع
الكود الفعلي، ثم أنشئ تقريرًا يوضح الانحرافات بينهما.

## المدخلات
- **CLAUDE.md:** paste_or_reference_file
- **قاعدة الكود الحالية:** path_or_uploaded_files

## افحص التالي:

1. **رموز تصميم (Tokens) جديدة غير موثّقة**
   - قيم ألوان موجودة في الكود وغير مذكورة في CLAUDE.md
   - قيم مسافات مستخدمة لكنها غير معرّفة
   - أحجام خطوط أو أوزان خطوط جديدة

2. **رموز تصميم مهملة ما زالت مستخدمة في الكود**
   - رموز تصميم موثّقة على أنها مهملة لكنها ما زالت مستخدمة
   - عدد الاستخدامات المتبقية لكل رمز تصميم مهمل

3. **مكوّنات جديدة غير موثّقة**
   - مكوّنات أُنشئت بعد آخر تحديث لـ CLAUDE.md
   - مكوّنات غير موجودة في قسم مكتبة المكوّنات

4. **مكوّنات معدّلة**
   - تغييرات في الـ props (إضافة/حذف/إعادة تسمية)
   - تنويعات جديدة غير موثّقة
   - تغييرات بصرية (استخدام رموز تصميم مختلفة)

5. **مراجع معطّلة**
   - ملف CLAUDE.md يشير إلى رموز تصميم لم تعد موجودة
   - مسارات ملفات تغيّرت
   - مسارات استيراد قديمة

6. **مخالفات لقواعد النظام**
   - كود يخالف قواعد CLAUDE.md (ألوان مكتوبة مباشرة داخل الكود، حالات تركيز ناقصة، إلخ.)
   - عدد وموقع كل نوع من المخالفات

## المخرجات
تقرير Markdown يحتوي على:
- **إحصائيات مختصرة:** X رموز تصميم جديدة، Y مهملة، Z مكوّنات معدّلة
- **بنود تنفيذ** مرتبة حسب درجة الخطورة (تعطيلي → غير متسق → تجميلي)
- **أقسام CLAUDE.md المحدّثة** جاهزة للنسخ واللصق (الأجزاء التي تغيّرت فقط)

أنت تجمع ملف CLAUDE.md النهائي كمرجع رسمي ومعتمد لنظام التصميم.
سيكون هذا الملف في جذر المشروع، ويمثّل المصدر الوحيد للحقيقة لأي مساعد ذكاء اصطناعي
أو مطوّر يعمل على قاعدة الكود هذه.

## المدخلات
- **معمارية التوكنز:** [مخرجات المرحلة 2]
- **توثيق المكوّنات:** [مخرجات المرحلة 3]
- **بيانات المشروع:**
  - اسم المشروع: name
  - الحزمة التقنية: [Next.js 14+ / React 18+ / Tailwind 3.x / وغيرها]
  - إصدار Node: version
  - مدير الحزم: [npm / pnpm / yarn]

## هيكلة ملف CLAUDE.md

اجمع الملف النهائي بالأقسام التالية، وبنفس هذا الترتيب:

### 1. هوية المشروع
- اسم المشروع، وصفه، ومكانته أو توجهه
- ملخص الحزمة التقنية في جدول واحد
- نظرة عامة على هيكلة المجلدات، خصوصًا تخطيط src/

### 2. بطاقة المرجع السريع
ملخص مركز لأكثر المعلومات المطلوبة، بحيث تكون واضحة من أول نظرة:
- الألوان الأساسية مع قيم hex، بحد أقصى 6 ألوان
- مجموعة الخطوط المستخدمة
- مقياس المسافات بعرض بصري: 4, 8, 12, 16, 24, 32, 48, 64
- نقاط التوقف للشاشات
- قيم استدارة الزوايا
- قيم الظلال
- خريطة z-index

### 3. توكنز التصميم — المرجع الكامل
تنظّم حسب المستوى: Primitive → Semantic → Component.
كل توكن يجب أن يحتوي على: الاسم، القيمة، متغير CSS، وما يقابله في Tailwind.
استخدم الجداول لتسهيل القراءة السريعة.

### 4. نظام الخطوط
- جدول مقياس الخطوط: الاسم، الحجم، الوزن، ارتفاع السطر، تباعد الحروف، الاستخدام
- قواعد التجاوب مع أحجام الشاشات
- استراتيجية تحميل الخطوط

### 5. نظام الألوان
- لوحة الألوان الكاملة مع وصف لكل عينة: الاسم، hex، وسياق الاستخدام
- جدول ربط الألوان الدلالية
- ربط ألوان الوضع الداكن إذا كان مطبقًا
- ملاحظات الالتزام بنسب التباين وإمكانية الوصول

### 6. نظام التخطيط
- مواصفات الشبكة
- عروض الحاويات
- نظام المسافات مع مقياس بصري
- سلوك نقاط التوقف حسب حجم الشاشة

### 7. مكتبة المكوّنات
[أدرج مخرجات المرحلة 3 لكل مكوّن]

### 8. الحركة والتحريك
- جدول الإعدادات المسمّاة: الاسم، المدة، منحنى الحركة، الاستخدام
- القواعد: متى نستخدم الحركة ومتى نتجنبها
- قيود الأداء

### 9. اتفاقيات كتابة الكود
- أنماط تسمية الملفات
- ترتيب الاستيراد
- قالب هيكلة ملف المكوّن
- ترتيب كلاسات CSS إذا كان المشروع يستخدم Tailwind
- أنماط إدارة الحالة المستخدمة

### 10. القواعد والقيود
قواعد صارمة لا يجوز كسرها أبدًا:
- «لا تستخدم ألوان hex مباشرة داخل الكود — استخدم التوكنز دائمًا»
- «كل العناصر التفاعلية لازم يكون لها حالة تركيز واضحة»
- «الحد الأدنى لمساحة اللمس: 44x44px»
- «كل الصور لازم تحتوي على نص بديل (alt)»
- «لا تستخدم أي قيم z-index خارج المقياس المحدد»
- [أضف قواعد خاصة بالمشروع]

## متطلبات التنسيق
- استخدم جداول Markdown لكل خرائط التوكنز والقيم
- استخدم كتل كود لكل أمثلة الكود
- اجعل كل قسم مكتفيًا بذاته، بحيث ينفهم بدون الرجوع لأقسام أخرى
- أضف جدول محتويات في أعلى الملف مع روابط مراسي (anchor)
- الحد الأقصى لطول السطر: 100 حرف لتحسين القراءة
- فضّل القيم الصريحة بدل عبارات مثل «راجع أعلاه»

## قاعدة حرجة
هذا الملف لازم يكون المرجع الرسمي المعتمد. إذا صار فيه تعارض بين CLAUDE.md
والكود الفعلي، يتم تحديث CLAUDE.md ليطابق الواقع — وليس العكس.
هذا الملف يوثق ما هو موجود فعليًا، وليس ما يفترض أن يكون؛ خارطة التطوير مكانها ملف مستقل.

أنت مختص بتوثيق أنظمة التصميم، ومهمتك إعداد مواصفة المكوّن
لملف CLAUDE.md. سيستخدم هذا التوثيق مساعدو البرمجة بالذكاء الاصطناعي
(Claude, Cursor, Copilot) لتوليد كود واجهات موحّد ومتّسق.

## السياق
- **نظام رموز التصميم (Tokens):** [الصق ناتج المرحلة 2 أو أشر إليه]
- **المكوّن المطلوب توثيقه:** [اسم المكوّن، أو كل المكوّنات من قائمة الحصر]
- **إطار العمل:** [Next.js + React + Tailwind / إلخ]

## لكل مكوّن، وثّق ما يلي:

### 1. نظرة عامة
- اسم المكوّن بصيغة PascalCase
- وصف مختصر من سطر واحد
- التصنيف (Navigation / Input / Feedback / Layout / Data Display)

### 2. بنية المكوّن
- اذكر كل جزء مرئي في المكوّن (مثال: Button = container + label + icon-left + icon-right)
- وضّح الأجزاء الاختيارية والإلزامية
- قواعد التداخل: ما الذي يمكن أو لا يمكن وضعه داخل هذا المكوّن

### 3. مواصفة الخصائص (Props)
لكل خاصية (prop):
- الاسم، والنوع، والقيمة الافتراضية، وهل هي إلزامية أو اختيارية
- القيم المسموح بها إذا كانت من نوع enum
- وصف مختصر لما تتحكم فيه بصريًا
- مثال استخدام

### 4. التنويعات المرئية (Variants)
- تنويعات الحجم مع قيم رموز التصميم الدقيقة (padding, font-size, height)
- تنويعات الألوان مع مراجع رموز التصميم الدقيقة
- حالات المكوّن: default, hover, active, focus, disabled, loading, error
- لكل حالة: حدّد رموز التصميم التي تتغير والقيم التي تتغير إليها

### 5. خريطة استهلاك رموز التصميم (Tokens)
Component: Button
├── background → button-bg-variant → color-brand-shade
├── text-color → button-text-variant → color-white
├── padding-x → button-padding-x-size → spacing-{n}
├── padding-y → button-padding-y-size → spacing-{n}
├── border-radius → button-radius → radius-md
├── font-size → button-font-size → font-size-{n}
├── font-weight → button-font-weight → font-weight-semibold
└── transition → motion-duration-fast + motion-ease-default

### 6. إرشادات الاستخدام
- متى يُستخدم المكوّن، ومتى لا يُستخدم، مع اقتراح بدائل مناسبة
- الحد الأعلى لعدد مرات ظهوره داخل نفس الشاشة/القسم، مثل: «زر إجراء رئيسي (Primary CTA) واحد فقط لكل قسم»
- إرشادات المحتوى: طول النص، أسلوب الصياغة، استخدام الأيقونات، وحالة الأحرف عند الحاجة

### 7. إمكانية الوصول (Accessibility)
- سمات ARIA المطلوبة
- نمط التفاعل باستخدام لوحة المفاتيح
- قواعد إدارة التركيز (Focus)
- سلوك قارئ الشاشة
- الحد الأدنى لنسب التباين التي تحققها رموز التصميم الافتراضية

### 8. مثال كود
قدّم مثال كود جاهزًا للنسخ واللصق باستخدام أنماط الكود الفعلية في المشروع،
مثل مسارات الاستيراد، اصطلاحات className، وأي أنماط معتمدة في قاعدة الكود.

## تنسيق الناتج

بتنسيق Markdown، ومنظّم بعناوين واضحة لكل قسم. سيُدرج الناتج مباشرةً
داخل ملف CLAUDE.md.

أنت مهندس معمارية أنظمة تصميم. سأزوّدك بملف JSON خام لتدقيق التصميم من قاعدة كود قائمة. مهمتك تحويل هذه الفوضى إلى معمارية توكنز منظّمة.

## المدخلات
[الصق هنا مخرجات JSON من المرحلة الأولى، أو اذكر مسار الملف]

## هرمية التوكنز

صمّم نظام توكنز من 3 مستويات:

### المستوى 1 — Primitive Tokens (القيم الأولية الخام)
قيم مسمّاة وثابتة، بدون أي معنى دلالي.
- الألوان: `color-gray-100`, `color-blue-500`
- المسافات: `space-1` إلى `space-N`
- أحجام الخط: `font-size-xs` إلى `font-size-4xl`
- استدارة الزوايا: `radius-sm`, `radius-md`, `radius-lg`

### المستوى 2 — Semantic Tokens (المعنى الدلالي/السياقي)
اربط القيم الأولية بالغرض منها. هذه المراجع قد تتغير بين الثيمات.
- `color-text-primary` → `color-gray-900`
- `color-bg-surface` → `color-white`
- `color-border-default` → `color-gray-200`
- `spacing-section` → `space-16`
- `font-heading` → `font-size-2xl` + `font-weight-bold` + `line-height-tight`

### المستوى 3 — Component Tokens (خاصة بالمكوّنات)
- `button-padding-x` → `spacing-4`
- `button-bg-primary` → `color-brand-500`
- `card-radius` → `radius-lg`
- `input-border-color` → `color-border-default`

## قواعد التوحيد والدمج
1. ادمج القيم التي يكون الفرق بينها ضمن 2px (مثل: 14px و15px → اختر قيمة واحدة، ووضّح أي قيمة تم اعتمادها)
2. ابنِ مقياس مسافات متّسقًا (يفضّل أساس 4px، مع توضيح أي انحرافات)
3. اختصر لوحة الألوان إلى ≤60 توكن إجمالًا (وحدّد ما يُقترح إيقاف استخدامه)
4. وحّد مقياس أحجام الخط ليكون بتدرّج منطقي
5. أنشئ إعدادات حركة مسبقة ومسمّاة بدل القيم المستخدمة لمرة واحدة

## صيغة المخرجات

قدّم الآتي:
1. **خريطة توكنز كاملة** بصيغة JSON — تشمل المستويات الثلاثة مع المراجع
2. **جدول ترحيل** — القيمة الحالية → اسم التوكن الجديد → الملفات التي تستخدمها
3. **قائمة الإيقاف** — القيم المطلوب حذفها مع البدائل المقترحة
4. **سجل القرارات** — كل قرار اجتهادي اتخذته (لماذا دمجت X في Y، وهكذا)

لكل قرار، اشرح المقايضة أو الأثر الناتج. قد لا أتفق مع اختيارات الدمج التي تقترحها، لذلك الشفافية أهم من الثقة الزائدة بالقرار.

أنت مهندس أول في أنظمة التصميم، وتُجري تدقيقًا استقصائيًا لقاعدة كود قائمة. مهمتك استخراج كل قرار تصميم مضمّن في الكود — سواء كان صريحًا أو ضمنيًا.

## سياق المشروع
- **إطار العمل:** [Next.js / React / etc.]
- **نهج كتابة الأنماط:** [Tailwind / CSS Modules / Styled Components / etc.]
- **مكتبة المكوّنات:** [shadcn/ui / custom / MUI / etc.]
- **موقع قاعدة الكود:** [path or "uploaded files"]

## نطاق الاستخراج

حلّل قاعدة الكود بالكامل واستخرج ما يلي في تقرير JSON منظّم:

### 1. نظام الألوان
- كل قيمة لون مستخدمة (hex, rgb, hsl, css variables, Tailwind classes)
- صنّفها حسب: primary, secondary, accent, neutral, semantic (success/warning/error/info)
- ضع علامة على أوجه عدم الاتساق، مثل: استخدام 3 درجات رمادي مختلفة للحدود
- اذكر اختلافات الشفافية وخرائط الوضع الداكن إن وجدت
- استخرج تعريفات CSS variables الفعلية وقيم fallback الخاصة بها

### 2. الخطوط والنصوص
- عائلات الخطوط (الخطوط المحمّلة، fallback stacks، واستيرادات Google Fonts)
- أحجام الخطوط (كل حجم فريد مستخدم، سواء px/rem/Tailwind classes)
- أوزان الخطوط المستخدمة لكل عائلة خط
- ارتفاعات الأسطر المرتبطة بكل حجم خط
- قيم تباعد الأحرف
- أنماط النصوص كتركيبات مستخدمة فعليًا، مثل: "heading-large" = Inter 32px/700/1.2
- قواعد الخطوط المتجاوبة (أحجام الجوال مقابل سطح المكتب)

### 3. المسافات والتخطيط
- سلّم المسافات (كل قيمة margin/padding/gap مستخدمة)
- عروض الحاويات وقيم max-widths
- نظام الشبكة (الأعمدة، المسافات بينها، نقاط التوقف)
- تعريفات نقاط التوقف
- طبقات z-index والغرض من كل طبقة
- قيم استدارة الزوايا (border-radius)

### 4. جرد المكوّنات
لكل مكوّن قابل لإعادة الاستخدام يتم العثور عليه:
- اسم المكوّن ومسار الملف
- واجهة الخصائص (Props interface)، مع أنواع TypeScript إن وجدت
- المتغيرات البصرية (الحجم، اللون، الحالة)
- رموز المسافات والأحجام المستخدمة داخليًا
- الاعتماديات على مكوّنات أخرى
- عدد مرات الاستخدام داخل قاعدة الكود، بشكل تقريبي

### 5. الحركة والتحريك
- مدد الانتقال (Transition durations) ودوال التوقيت (Timing functions)
- Keyframes الخاصة بالتحريك
- انتقالات حالات hover/focus/active
- أنماط الانتقال بين الصفحات
- التحريكات المرتبطة بالتمرير، إن وُجدت مكتبة مثل Framer Motion أو GSAP

### 6. الأيقونات والأصول
- نظام الأيقونات المستخدم (Lucide, Heroicons, custom SVGs, etc.)
- أحجام الأيقونات المستخدمة
- نسخ favicon والشعار

### 7. تقرير عدم الاتساق
- القيم المكررة التي يفترض أن تكون رموز تصميم، مثل: `#1a1a1a` مستخدمة 47 مرة لكنها ليست متغيرًا
- الأنماط المتعارضة، مثل: بعض الأزرار تعتمد على padding لتحديد الحجم، وأخرى تعتمد على ارتفاع ثابت
- الحالات الناقصة، مثل المكوّنات التي لا تحتوي على hover/focus/disabled states
- فجوات إمكانية الوصول (Accessibility)، مثل غياب focus rings أو ضعف تباين الألوان

## صيغة الإخراج

أرجع كائن JSON واحدًا فقط بهذا الهيكل:
{
  "colors": { "primary": [], "secondary": [], ... },
  "typography": { "families": [], "scale": [], "styles": [] },
  "spacing": { "scale": [], "containers": [], "breakpoints": [] },
  "components": [ { "name": "", "path": "", "props": {}, "variants": [] } ],
  "motion": { "durations": [], "easings": [], "animations": [] },
  "icons": { "system": "", "sizes": [], "count": 0 },
  "inconsistencies": [ { "type": "", "description": "", "severity": "high|medium|low" } ]
}

لا تحاول تنظيم أي شيء أو تحسينه الآن.
لا تقترح أسماء رموز تصميم أو إعادة هيكلة.
فقط استخرج الموجود كما هو، بالضبط.

راجع صفحة page الحالية وفق المعايير التالية:
- هل يخلق القسم الافتتاحي (Hero) انطباعًا عاطفيًا واضحًا خلال أقل من 3 ثوانٍ؟
- هل التسلسل الهرمي للخطوط والعناوين واضح عبر جميع أحجام الشاشات؟
- هل التفاعلات مقصودة وتدعم تجربة المستخدم، أم مجرد عناصر زخرفية؟
- هل يرتقي التصميم لمستوى جودة reference_site_x مع حفاظه على هوية مميزة ومختلفة؟

اقترح 3 تحسينات محددة مع توضيح المبررات، ثم نفّذها.

بناءً على التصوّر المعتمد، ابنِ صفحة [Homepage/About/etc.].

المتطلبات والقيود:
- مكوّن React واحد في ملف واحد باستخدام Tailwind
- تصميم يبدأ من الجوال أولاً، ومتجاوب مع مختلف الشاشات
- ميزانية الأداء: لا تعتمد على أي مكتبة يتجاوز حجمها 50kb إلا إذا كان ذلك مبررًا بوضوح
- يجب أن تكون [Specific interaction from Phase 1] هي اللحظة الأبرز في قسم الهيرو
- استخدم مهارة frontend-design لضمان جودة التصميم

اعرض لي المكوّن. سأراجعه قبل الانتقال إلى الصفحة التالية.

أنت مدير إبداعي خبير في استوديو تصميم معروف بتجارب ويب جريئة وذات موقف تصميمي واضح. أقدّم لك موجزًا لمشروع جديد.

**العميل:** company_name
**القطاع:** industry
**الموقع الحالي:** if_there_is_one_or_delete_this_line
**التموضع السوقي:** [مثال: "أفخم استوديو تصميم داخلي في الرياض، ولا يتعامل إلا مع 5 عملاء سنويًا"]
**الجمهور المستهدف:** [من هم؟ ما الذي يبحثون عنه؟ وما دوافعهم؟]
**النبرة:** [3-5 صفات، مثل: "واثقة، بسيطة، هادئة الإيقاع، تحريرية"]
**مراجع يجب تجنّبها:** [مثال: "لا نريد قوالب SaaS عامة، ولا إحساس الصور الجاهزة، ولا تصميمًا استعراضيًا هدفه لفت الانتباه على Dribbble فقط"]
**المراجع:** [2-3 روابط مواقع أو توجهات أسلوبية]
**الصفحات الأساسية:** [الرئيسية، من نحن، الخدمات، تواصل معنا — أو غيرها]

قبل كتابة أي كود، اقترح:
1. مفهومًا تصميميًا في 2-3 جمل؛ يكون هو "الفكرة الكبيرة" للموقع
2. استراتيجية تخطيط لكل صفحة: سلوك التمرير، وطريقة بناء الشبكة
3. توجه الخطوط والألوان
4. تفاعلًا مميزًا واحدًا يعرّف شخصية الموقع
5. قرارات الحزمة التقنية: الحركة، المكتبات، مع توضيح السبب

لا تكتب أي كود الآن. اعرض المفهوم أولًا للمراجعة.