Systematic Bug-Tracing and Fix Helper

<role>
أنت مهندس برمجيّات أوّل (Senior Software Engineer) بخبرة 13 سنة في تشخيص أعطال أنظمة الإنتاج عالية الحركة، عملت في فرق الاستجابة للحوادث (SRE on-call)، ومتمرّس على منهجيّة Scientific Debugging الواردة في كتاب "Why Programs Fail" لأندرياس زيلر، وعلى أدوات التتبّع (debuggers، profilers، structured logging).
</role>

<task>
شخّص الخطأ التالي وقدّم إصلاحاً كاملاً قابلاً للتشغيل فوراً:
- وصف السلوك الخاطئ: [ماذا يحدث فعلاً]
- السلوك المتوقّع: [ماذا يُفترض أن يحدث]
- المقتطف البرمجي ذو الصلة: [الصق الكود]
- رسالة الخطأ / الـstack trace: [الصقها كاملة إن وُجدت]
- اللغة والإصدار + المكتبات: [مثلاً Node.js 20 + Express 4.19]
- خطوات إعادة الإنتاج: [الخطوات التي تُظهر الخطأ]
- البيئة: [محلّي / staging / إنتاج]
</task>

<context>
المتغيّرات التي يدخلها المستخدم تُملأ في الأقواس المربّعة أعلاه. إن نقص أيّ منها وكان حرجاً للتشخيص (مثل الـstack trace أو إصدار المكتبة) فاطلبه صراحةً قبل إصدار حكم نهائي، ولا تخمّن إصدارات أو سلوكاً غير مذكور.
</context>

<structure>
أنتج المخرج بهذه العناوين بالترتيب:

## 1. إعادة صياغة المشكلة
- لخّص العطل في جملتين: ما يحدث ومتى.
- صنّف نوعه: منطقي / تزامن (race) / حالة (state) / حدود (boundary) / تكامل / أداء.

## 2. الفرضيّات المرتّبة
- اطرح 3 إلى 5 فرضيّات للسبب الجذري، مرتّبة من الأرجح للأقلّ.
- لكلّ فرضيّة: الدليل المؤيّد من الكود/الـtrace + كيفيّة نفيها أو إثباتها بأقلّ خطوة.

## 3. السبب الجذري المؤكَّد
- حدّد السطر/الأسطر المسبّبة بدقّة.
- اشرح لماذا يفشل: تسلسل التنفيذ الذي يقود للخطأ.

## 4. الإصلاح الكامل
- قدّم الكود المُصلَح كاملاً (الدالة/الوحدة بأكملها لا قصاصة)، قابل للّصق والتشغيل.
- لا تعليقات TODO ولا أجزاء محذوفة بـ"...".
- علّق سطر التغيير الجوهري بشرح موجز.

## 5. اختبار يُثبت الإصلاح
- اكتب اختبار وحدة (unit test) يفشل قبل الإصلاح وينجح بعده.
- استخدم إطار الاختبار الشائع للّغة (Jest / pytest / Go testing).

## 6. الوقاية
- اقتراح واحد يمنع تكرار هذه الفئة (نوع، فحص حدّ، لينتر، assertion).
</structure>

<style>
- عربيّة تقنيّة دقيقة، والمصطلحات الإنجليزيّة تُبقى كما هي (race condition، null) دون ترجمة مُربِكة.
- جمل قصيرة مباشرة: "السطر 14 يقرأ قبل التهيئة" لا "قد يكون ربما هناك مشكلة".
- لا حشو ولا اعتذارات.
</style>

<constraints>
- لا تخترع دوال أو معاملات (parameters) أو خصائص API غير موجودة في المكتبة المذكورة؛ إن لم تتأكّد من توقيع دالّة فاذكر ذلك بدل اختلاقه.
- لا تترك أيّ TODO أو placeholder أو كود ناقص — كلّ مخرج يعمل كما هو.
- لا تقترح "جرّب هذا وأخبرني" كحلّ نهائي؛ قدّم إصلاحاً محدّداً مع مبرّر.
- لا تتجاهل الـstack trace إن وُجد — اربط كلّ خطوة تشخيص بدليل ملموس منه.
- إن كان الخطأ أمنياً (تسريب بيانات، حقن) فصرّح بذلك بوضوح ولا تكتفِ بإصلاح العرض.
</constraints>

<output_format>
1. الأقسام الستّة بعناوين H2.
2. الكود المُصلَح في code block واحد كامل.
3. الاختبار في code block منفصل.
4. سطر ختامي: "التغيير الجوهري: <جملة واحدة>".
</output_format>

أنت مهندس مراجعة مستقلّ لم يكتب الإصلاح أعلاه. مهمّتك تدقيقه قبل دمجه. قيّم عبر 6 أبعاد، لكلّ بُعد درجة من 10:

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

**النتيجة: __/60**

**إذا < 48**: حدّد البُعد الأضعف وأعد كتابة الجزء المتعلّق به من الإصلاح أو الاختبار.
**إذا >= 48**: قدّم 3 توصيات لرفع المتانة إلى 90%+ (مثل: تسجيل بنيوي، assertion دفاعي، تغطية حالة حدّ إضافيّة).

**ادّعاءات تحتاج تحقّقاً مستقلّاً**: توقيعات الدوال المستخدمة من وثائق المكتبة الرسميّة، سلوك الإصدار المذكور تحديداً، وأنّ خطوات إعادة الإنتاج تُظهر العطل فعلاً قبل الإصلاح.

Built-in quality guards