تصحيح
وكيل تصحيح نافين: سبب جذري مثبت وفرع معزول وتقرير HTML
5 أغسطس 2026 · 2 دقائق قراءة · فريق نافين
تصحيح منهجي: قفل الإشارة وإعادة الإنتاج والإثبات والعزل على فرع وتسليم خطة إصلاح مرقمة قبل أي ترقيع.
وكيل التصحيح في نافين لا يرقّع عشوائيا: إنه يقفل الإشارة، ويعيد إنتاج الخطأ، ويثبت السبب الجذري بدليل، ويعزل العمل على فرع، ثم يسلّم تقرير HTML مع خيارات إصلاح مرقمة. تقول #1 فيصلح الوكيل. بلا تخمين.
متى تستخدمه
عندما ينكسر شيء وتريد السبب الجذري بدليل: اختبار فاشل، stack، رمز حالة، حقل فاسد، استعلام SQL، سلوك متقلب. ليس لـ «حسّن الكود قليلا».
كيف تبدأ
- وضع Debug + نص حر (يُسبق بـ
/debug). /debug [إشارة|مسار|نطاق].- Actions ← Debug عند التوفر.
دور النموذج هو deep (وضع الواجهة debug). الأداة المخصصة هي debug_repair.
العملية خطوة بخطوة
- قفل الإشارة - الخطأ الدقيق، الاختبار الفاشل، الـ stack، رمز الحالة، الحقل/الاستعلام السيئ، أو خطوات إعادة الإنتاج. وإلا:
git status/ diff، السجلات الأخيرة، سكربتات الحزمة. - إعادة الإنتاج عبر
exec- اختبار أو typecheck أو lint أو أمر مكسور. التقاط stdout/stderr وأكواد الخروج. لـ SQL: المخطط / الاستعلامات / الهجرات. لـ API: handler → التحقق → DB. للواجهة: props/state → الشبكة → الخادم. - الفحص -
debug_repair(action=mcp_status): إن كان DebugMCP يعمل (الإعداد المسبقdebugmcp→http://127.0.0.1:3001/mcp) فاستخدم نقاط التوقف / المتغيرات / التقييم؛ وإلا السجلات /pdb. أدلة حقيقية فقط. - العزل -
debug_repair(action=start_branch)قبل أي تعديل على الكود. - التضييق -
read_fileوgit blame/diff والسجلات والمقاييس؛ أصغر أداة قياس تثبت السبب. راقب السباقات والتخزين المؤقت السيئ والبيئة الخاطئة والاختبارات المتقلبة وN+1 وتسرب الاتصالات وعواصف المهلة/إعادة المحاولة. - اللوحة - سجّل كل عيب مؤكد كمهمة (
status=fix) عند استخدام لوحة المشروع. - الختام بـ
debug_repair(action=report, …): يفتحdebug-report-[date].htmlتلقائيا (سبب جذري + أدلة، أخطاء كامنة، خيارات#N). اسأل بأي#نبدأ.
يُطبَّق الكود فقط إذا طُلب؛ وإلا قد ينتقل الوكيل إلى Agent ويشير إلى /forge بعد اختيارك.
ماذا يحتوي التقرير
نفس نمط Review وSecurity: HTML مستقل (CSS مضمّن، بلا JS خارجي)، ملخص تنفيذي، دليل السبب الجذري، أخطاء كامنة اكتُشفت في الطريق، خطة إصلاح مرقمة (جهد، خطر التأجيل، أول خطوة). الدردشة قصيرة: 3 إلى 6 جمل + «Start with #1؟».
التصحيح مقابل الترقيع العشوائي
| الأسلوب | ذكاء اصطناعي عشوائي | وكيل Debug نافين |
|---|---|---|
| الإشارة | غامضة («لا يعمل») | مقفلة (خطأ، اختبار، stack) |
| الدليل | تخمين | إعادة إنتاج + stdout/stderr + نقطة توقف |
| العزل | على فرعك | فرع مخصص قبل التعديل |
| المخرج | diff غامض | تقرير HTML + خيارات #N |
| الخطوة التالية | إعادة كتابة كل شيء | بند واحد ثم /forge |
التصحيح + اللوحة + الاستقلالية
النتائج تصبح مهاما. مع استقلالية اللوحة: فرع navin/task-*، اختبارات خضراء، PR، إغلاق القضية. السبب الجذري لا يموت في الدردشة.
الأسئلة الشائعة
هل أحتاج DebugMCP؟
لا. بدونه يستخدم الوكيل السجلات وpdb والاختبارات وقراءة الكود. معه تسرّع نقاط التوقف والتقييم الحي.
هل يصلح الوكيل كل شيء وحده؟
لا افتراضيا. يثبت ويبلّغ وينتظر رقمك. الإصلاح التلقائي فقط إذا طلبت.
ما الفرق عن وضع Agent؟
Agent ينفّذ. Debug يثبت أولا. اربطهما: Debug ← اختر #1 ← Agent / /forge.
حمّل نافين · الميزات · التوثيق
قراءات تالية
- مراجعة خبيرة → وكيل المراجعة
- تدقيق AppSec → وكيل الأمن
- الدورة الكاملة → وحدة الكود
- خط التسليم → اللوحة المستقلة
الخلاصة
تصحيح يقفل الإشارة ويعيد الإنتاج ويثبت ويعزل ويسلّم خطة مرقمة: هذه نهاية الترقيع العشوائي، وبداية خط يكون لكل خطأ فيه دليل قبل الإصلاح.