Severity tagging صح

Severity tags هي اللي بتخلّي code review قابل للتصرّف. "فيه bug" بتسيب الـ reviewer يخمّن إذا كان يبلوك الـ merge ولا لأ. "HIGH — SQL injection" مش بتسيبه يخمّن.

3 labels عادة كافية: HIGH، MED، LOW. أكتر من 3 بيعمل analysis paralysis. اتنين (بس "مهم" و "مش مهم") بتفقد القدرة على التفرقة بين "لازم يتصلّح قبل الـ merge" و "صلّحه في الـ sprint الجاي."

ده الـ rubric تحطه في prompts المراجعة. الفِرَق بتعاير مختلف؛ المهم إن الـ prompt بتاعك ملتزم بتعريف.

Severity	التعريف	مثال
HIGH	بيأثّر على production لو شُحن: أمان، فقد بيانات، انتهاكات في الصح	SQL injection، auth check ناقص، off-by-one في منطق مالي
MED	هيسبّب مشكلة بعدين: latent bugs، مشاكل أداء في scale، error handling ناقص	Exception path مش معالج، N+1 query، input validation ناقص
LOW	ستايل، وضوح، refactors بسيطة	تسمية variables، dead code، helpers متكررة

المراجعة في الدرس 1 معايرة صح. الـ SQL injection HIGH — قابل للاستغلال النهارده. input validation الناقص MED — مش هيعض على طول لكن بعدين. الـ variable name القصير LOW — بيبطّأ القراية بس مش بيكسر حاجة.

3 طبقات الـ severity جنب بعض:

غلط شائع إنك تسيب الموديل يعاير نفسه من غير rubric. من غير تعريفات صريحة، الموديلز بيميلوا إنهم يـover-tag HIGH (كل حاجة بتبان urgent في prose الـ code review) أو under-tag (الموديل بيلف عشان مش عارف معيار فريقك). لصق rubric في الـ prompt بيصلح الاتنين.

جرّب النسخة دي من prompt المراجعة بمعايرة صريحة:

Review this code. Use this severity rubric:

• HIGH: would cause a production incident if shipped (security, data loss, correctness)
• MED: latent issue that will surface eventually (perf at scale, error handling, hidden bugs)
• LOW: style or readability, no behavioural impact

Categories: SECURITY, PERFORMANCE, READABILITY. 0–3 issues per category. Format: SEVERITY — issue (line N) — fix in one line. End with a 1-line verdict: APPROVE / REQUEST_CHANGES / BLOCK.

المخرج هيبقى أكتر ثبات عبر المراجعات لأن الموديل دلوقتي بيستخدم معيار فريقك، مش بتاعه.

تكنيك للفِرَق اللي عايزة معايرة أصرم: اطلب من الموديل إنه يبرّر أي HIGH tag في جملة. "HIGH — SQL injection (line 5) — string concatenation directly from user input is exploitable today." دلوقتي تقدر تراجع إذا كان الـ HIGH مبرّر. اكتشاف متاجد بـ HIGH والموديل مش قادر يبرّره في جملة على الأرجح ما كانش HIGH.

تقدر كمان تستخدم severity tags لـ triage في scale. لو بتراجع PR من 50 ملف، اطلب من الموديل يطلّع بس HIGH و MED اكتشافات عبر كل الملفات في list واحدة. LOW findings تاخد low_findings.md منفصل تمسحه بعدين. نفس الـ skeleton للـ prompt، متكبّر بفلترة المخرج.

التالي: تحويل feature spec لـ pytest tests. :::