برومبت تدقيق شامل للمستودع وإصلاحه

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

## المرحلة الأولى: التقييم الأولي للمستودع

### 1.1 تخطيط البنية
- تخطيط هيكل المشروع بالكامل (src/, lib/, tests/, docs/, config/, scripts/, إلخ.)
- تحديد المكدس التقني والتبعيات (package.json, requirements.txt, go.mod, pom.xml, Gemfile, إلخ.)
- توثيق نقاط الدخول الرئيسية، والمسارات الحرجة، وحدود النظام
- تحليل تكوينات البناء وخطوط أنابيب CI/CD
- مراجعة الوثائق الموجودة (README، وثائق API، رسوم بيانية معمارية)

### 1.2 تحليل بيئة التطوير
- تحديد أطر الاختبار (Jest, pytest, PHPUnit, Go test, JUnit, RSpec, إلخ.)
- مراجعة تكوينات التدقيق/التنسيق (ESLint, Prettier, Black, RuboCop, إلخ.)
- التحقق من تتبع المشكلات الموجود (GitHub Issues, تعليقات TODO/FIXME/HACK/XXX)
- تحليل سجل الالتزامات للمناطق الإشكالية الأخيرة
- مراجعة تقارير تغطية الاختبار الموجودة إن وجدت

## المرحلة الثانية: اكتشاف الأخطاء المنهجي

### 2.1 فئات الأخطاء المراد تحديدها
**الأخطاء الحرجة:**
- الثغرات الأمنية (SQL injection, XSS, CSRF, تجاوز المصادقة، إلخ.)
- مخاطر تلف البيانات أو فقدانها
- تعطل النظام أو توقفه
- تسرب الذاكرة أو استنزاف الموارد

**الأخطاء الوظيفية:**
- أخطاء منطقية (شروط غير صحيحة، حسابات خاطئة، أخطاء "أقل بواحد")
- مشكلات إدارة الحالة (شروط السباق، حالة غير متسقة، تعديلات غير صحيحة)
- عقود API غير صحيحة أو تعيينات بيانات خاطئة
- التحقق من الصحة المفقود أو غير الصحيح
- قواعد عمل أو سير عمل معطلة

**أخطاء التكامل:**
- استخدام غير صحيح لـ API خارجي
- أخطاء أو عدم كفاءة في استعلامات قاعدة البيانات
- مشكلات معالجة قائمة انتظار الرسائل
- مشكلات عمليات نظام الملفات
- أخطاء الاتصال بالشبكة

**الحالات الهامشية ومعالجة الأخطاء:**
- معالجة القيم الخالية/غير المعرفة/nil
- الحالات الهامشية للمجموعات الفارغة أو القيم الصفرية
- شروط الحدود وانتهاكات القيود
- فقدان نشر الأخطاء أو ابتلاع الاستثناءات
- مشكلات منطق المهلة وإعادة المحاولة

**مشكلات جودة الكود:**
- عدم تطابق الأنواع أو التحويلات غير الآمنة
- استخدام API مهمل
- كود ميت أو فروع لا يمكن الوصول إليها
- تبعيات دائرية
- اختناقات الأداء (استعلامات N+1، خوارزميات غير فعالة)

### 2.2 طرق الاكتشاف
- تحليل الكود الثابت باستخدام أدوات خاصة باللغة
- مطابقة الأنماط للأنماط المضادة الشائعة
- فحص تبعيات الثغرات الأمنية
- تحليل مسار الكود للكود غير القابل للوصول أو غير المختبر
- التحقق من صحة التكوين
- مقارنة الوثائق بالتنفيذ

## المرحلة الثالثة: توثيق الأخطاء وتحديد الأولويات

### 3.1 نموذج تقرير الأخطاء
لكل خطأ يتم تحديده، وثّق ما يلي:
```
BUG-ID: [معرف تسلسلي]
Severity: [CRITICAL | HIGH | MEDIUM | LOW]
Category: [Security | Functional | Performance | Integration | Code Quality]
File(s): [مسار (مسارات) الملف الكامل وأرقام الأسطر]
Component: [الوحدة/الخدمة/الميزة المتأثرة]

Description:
- السلوك الحالي (ما هو الخطأ)
- السلوك المتوقع (ماذا يجب أن يحدث)
- تحليل السبب الجذري

Impact Assessment:
- تأثير المستخدم (تدهور تجربة المستخدم، فقدان البيانات، التعرض الأمني)
- تأثير النظام (الأداء، الاستقرار، قابلية التوسع)
- تأثير الأعمال (الامتثال، الإيرادات، السمعة)

Reproduction Steps:
1. [تعليمات خطوة بخطوة]
2. [تضمين بيانات/شروط الاختبار إذا لزم الأمر]
3. [النتائج المتوقعة مقابل النتائج الفعلية]

Verification Method:
- [مقتطف كود أو اختبار يوضح الخطأ]
- [مقاييس أو سجلات تظهر المشكلة]

Dependencies:
- الأخطاء ذات الصلة: [قائمة معرفات الأخطاء ذات الصلة]
- المشكلات العالقة: [ما الذي يحتاج إلى إصلاح أولاً]
```

### 3.2 مصفوفة تحديد الأولويات
صنف الأخطاء باستخدام:
- **الخطورة**: حرج > مرتفع > متوسط > منخفض
- **تأثير المستخدم**: عدد المستخدمين/الميزات المتأثرة
- **تعقيد الإصلاح**: بسيط < متوسط < معقد
- **خطر الانحدار**: منخفض < متوسط < مرتفع

## المرحلة الرابعة: تنفيذ الإصلاح

### 4.1 استراتيجية الإصلاح
**لكل خطأ:**
1. إنشاء فرع إصلاح معزول (إذا كنت تستخدم التحكم في الإصدار)
2. كتابة اختبار فاشل أولاً (نهج TDD)
3. تنفيذ إصلاح بسيط ومركّز
4. التحقق من نجاح الاختبار
5. تشغيل اختبارات الانحدار
6. تحديث الوثائق إذا لزم الأمر

### 4.2 إرشادات الإصلاح
- **مبدأ التغيير الأدنى**: قم بإجراء أصغر تغيير يحل المشكلة بشكل صحيح
- **لا تتجاوز النطاق**: تجنب إعادة الهيكلة أو التحسينات غير ذات الصلة
- **الحفاظ على التوافق مع الإصدارات السابقة**: ما لم يكن الخطأ نفسه هو API مكسور
- **اتبع معايير المشروع**: استخدم نمط الكود والأنماط الموجودة
- **أضف برمجة دفاعية**: منع أخطاء مماثلة في المستقبل

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

## المرحلة الخامسة: الاختبار والتحقق

### 5.1 متطلبات الاختبار
**لكل خطأ تم إصلاحه، قدم:**
1. **اختبار الوحدة (Unit Test)**: اختبار معزول للإصلاح المحدد
2. **اختبار التكامل (Integration Test)**: إذا كان الخطأ يتضمن مكونات متعددة
3. **اختبار الانحدار (Regression Test)**: ضمان عدم كسر الإصلاح للوظائف الموجودة
4. **اختبارات الحالات الهامشية (Edge Case Tests)**: تغطية شروط الحدود ذات الصلة

### 5.2 هيكل الاختبار
```[language-specific]
describe('BUG-[ID]: [وصف الخطأ]', () => {
  test('يجب أن يفشل مع الخطأ الأصلي', () => {
    // سيفشل هذا الاختبار قبل الإصلاح
    // يوضح الخطأ
  });
  
  test('يجب أن ينجح بعد الإصلاح', () => {
    // ينجح هذا الاختبار بعد الإصلاح
    // يتحقق من السلوك الصحيح
  });
  
  test('يجب أن يتعامل مع الحالات الهامشية', () => {
    // تغطية إضافية للحالات الهامشية
  });
});
```

### 5.3 خطوات التحقق
1. تشغيل مجموعة الاختبار الكاملة: `[npm test | pytest | go test ./... | mvn test | إلخ.]`
2. التحقق من تغييرات تغطية الكود
3. تشغيل أدوات التحليل الثابت
4. التحقق من معايير الأداء (إن أمكن)
5. الاختبار في بيئات مختلفة (إن أمكن)

## المرحلة السادسة: التوثيق والإبلاغ

### 6.1 توثيق الإصلاح
لكل خطأ تم إصلاحه:
- تحديث تعليقات الكود المضمنة التي تشرح الإصلاح
- إضافة/تحديث وثائق API إذا تغير السلوك
- إنشاء/تحديث أدلة استكشاف الأخطاء وإصلاحها
- توثيق أي حلول بديلة للمشكلات غير المصلحة

### 6.2 تقرير ملخص تنفيذي
```markdown
# تقرير إصلاح الأخطاء - [اسم المستودع]
التاريخ: [YYYY-MM-DD]
المحلل: [اسم الأداة/الشخص]

## نظرة عامة
- إجمالي الأخطاء التي تم العثور عليها: [X]
- إجمالي الأخطاء التي تم إصلاحها: [Y]
- غير مصلح/مؤجل: [Z]
- تغيير تغطية الاختبار: [قبل]% ← [بعد]%

## النتائج الحرجة
[قائمة بأهم 3-5 أخطاء حرجة تم العثور عليها وإصلاحها]

## ملخص الإصلاح حسب الفئة
- الأمان: [X أخطاء تم إصلاحها]
- الوظيفية: [Y أخطاء تم إصلاحها]
- الأداء: [Z أخطاء تم إصلاحها]
- التكامل: [W أخطاء تم إصلاحها]
- جودة الكود: [V أخطاء تم إصلاحها]

## قائمة الإصلاحات التفصيلية
[جدول منظم مع الأعمدة: BUG-ID | الملف | الوصف | الحالة | الاختبار المضاف]

## تقييم المخاطر
- المشكلات المتبقية ذات الأولوية العالية: [قائمة]
- الخطوات التالية الموصى بها: [الإجراءات]
- الديون التقنية المحددة: [ملخص]

## نتائج الاختبار
- أمر الاختبار: [الأمر الدقيق المستخدم]
- الاختبارات التي نجحت: [X/Y]
- الاختبارات الجديدة المضافة: [العدد]
- تأثير التغطية: [التفاصيل]
```

### 6.3 قائمة مراجعة التسليمات
- [ ] جميع الأخطاء موثقة بتنسيق قياسي
- [ ] تم تنفيذ الإصلاحات واختبارها
- [ ] تم تحديث مجموعة الاختبار وتمريرها
- [ ] تم تحديث الوثائق
- [ ] تم الانتهاء من مراجعة الكود
- [ ] تم تقييم تأثير الأداء
- [ ] تم إجراء مراجعة أمنية (للإصلاحات المتعلقة بالأمان)
- [ ] تم إعداد ملاحظات النشر

## المرحلة السابعة: التحسين المستمر

### 7.1 تحليل الأنماط
- تحديد أنماط الأخطاء الشائعة
- اقتراح تدابير وقائية
- التوصية بتحسينات الأدوات
- اقتراح تغييرات معمارية لمنع مشكلات مماثلة

### 7.2 توصيات المراقبة
- اقتراح مقاييس للتتبع
- التوصية بقواعد التنبيه
- اقتراح تحسينات التسجيل
- تحديد المناطق التي تحتاج إلى تغطية اختبار أفضل

## القيود وأفضل الممارسات

1. **لا تساوم أبدًا على الأمان** من أجل البساطة
2. **حافظ على سجل تدقيق** لجميع التغييرات
3. **اتبع تحديد الإصدار الدلالي** إذا كانت الإصلاحات تغير API
4. **احترم حدود المعدل** عند اختبار الخدمات الخارجية
5. **استخدم علامات الميزات** للإصلاحات عالية المخاطر (إن أمكن)
6. **ضع في اعتبارك استراتيجية التراجع** لكل إصلاح
7. **وثق الافتراضات** التي تم إجراؤها أثناء التحليل

## تنسيق الإخراج
قدم النتائج في كل من:
- Markdown لسهولة القراءة البشرية
- JSON/YAML للمعالجة الآلية
- CSV لاستيراد أنظمة تتبع الأخطاء

## اعتبارات خاصة
- للمستودعات المتعددة (monorepos): تحليل كل حزمة على حدة
- للخدمات المصغرة (microservices): ضع في اعتبارك التبعيات بين الخدمات
- للكود القديم: وازن بين مخاطر الإصلاح والفوائد
- لتبعيات الطرف الثالث: أبلغ المصدر الأصلي إذا لزم الأمر