مراجعة بالذكاء الاصطناعي

شكل المراجعة

المراجعة بالذكاء الاصطناعي تشغيل واحد لخط الأنابيب pr_review المُنشأ مع مساحة العمل، على طلب سحب مفتوح واحد. يفتح خط الأنابيب مساحة مراجعة الطلب، ويوزّع وكلاء المراجعة ليقرؤوا الفروق في السحب المعزول لتلك المساحة، ويودع كل منهم نتائجه في عقد مراجعة منظَّمة، ويجمّعها وكيل قائد في استعراض موجّه، ويحسب المُنهي حكمًا واحدًا: Ship أو Hold أو Block. النشر خارج خط الأنابيب. الإرسال إلى GitHub خطوة منفصلة ومقصودة يتخذها إنسان.

تشرح بقية الصفحة هذه الأجزاء، ولماذا اتُّخذ لها هذا الشكل.

مساحة مراجعة واحدة لكل طلب سحب

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

في شجرة العمل المعزولة للمساحة يُسحب طلب السحب عند مرجع head. الغرفة الواحدة تعني سحبًا واحدًا: المراجعون كلهم يعملون في هذه المساحة، والسحب مشترك بينهم لا نسخة لكل مراجع من مساحة العمل.

ينشر كل مراجع في مجرى مسمّى خاص به داخل هذه المساحة الواحدة، والنتائج رسائل review_node لا نثرًا عاديًا. الجمع على نطاق المساحة في النهاية مقصود: حكم يُحسب من نتائج خيط واحد يكون، في صمت، حكمًا على مراجع واحد.

يحمل الارتباط سلّم حالات، requested ثم in progress ثم awaiting approval ثم completed، وهو ما يضبط النشر على GitHub في لسان المراجعة على طلب السحب.

مستويات المراجعة

عمق المراجعة سياسة لمساحة العمل ذات ثلاثة مستويات، تُضبط من الإعدادات → مساحة العمل → عام، على بطاقة سياسة مساحة العمل:

المستوى	المراجعون الذين يُوزَّعون	الإبلاغ
light	المهندس فقط	ما يهم فعليًا فقط
balanced	المهندس، وضمان الجودة، والمعماري (الافتراضي)	التقرير المعتاد
thorough	الخمسة جميعًا، بما في ذلك الأمان والأداء	لا يُخفَّض شيء

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

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

عقد المراجعة: النتائج بيانات لا نثر

النتيجة المودَعة عبر add_review_node تصبح عقدة مراجعة على طلب السحب. لسان المراجعة يعرضها، والحكم يُحسب منها، و«النشر على GitHub» يحوّلها إلى تعليق مضمّن. مراجع لا يعيد إلا نثرًا يترك تشغيل خط الأنابيب في مظهر النجاح وسطح المراجعة فارغًا. الإيداع هو الجزء الحامل.

تحمل كل عقدة:

الحقل	القيم
النوع	bug، suggestion، recommendation، question، ticket
الأولوية	P0 (حرج) إلى P3 (ملاحظة طفيفة)
ثلاثية الفرز	الفئة (security، stability، …)، والخطورة، والجهد
المرساة	مسار الملف، وبداية السطر ونهايته
حمولة الإصلاح	أسطر استبدال مقترحة، وفرق اختياري، ومطالبة إصلاح اختيارية
الثقة	درجة ضمن [0, 1]
التعليل	التحليل، ويُكتب قبل النتيجة

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

إجماع الأقران

تنتقل العقدة عبر open ثم consensus-ready ثم resolved أو dismissed. الخطوة الوسطى قلب النموذج: لا تترقّى النتيجة إلا حين يؤكّدها مراجع نظير، ولا يستطيع الوكيل تأكيد نتيجته هو. أداة MCP publish_review_to_github والافتراضي في RPC ينشران النتائج التي أكّدها الأقران فقط. زر النشر على GitHub في لسان المراجعة يرسل كل نتيجة مفتوحة متبقية.

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

إذا اختلف المراجعون، في الملف والسطر نفسهما، أو بفارق مستويين أو أكثر في الأولوية، أو سمّاها أحدهما bug والآخر suggestion، يُبرَز الخلاف فوق قائمة النتائج. هناك يفترق الرأي، وهناك يكون حكم الإنسان أجدى ما يكون.

تجاهل نتيجة يكتب أيضًا حقيقة كبح لينة في نطاق الذاكرة، بثقة منخفضة. التجاهل مرةً تفضيل، ولا يُتَّخذ قاعدة.

المجموعات: ما تُجمَّع حوله المراجعة

تجمّع جولة حوسبة المراجعة ملفات طلب السحب المتغيّرة في مجموعات مشتقة من مخطط الشفرة: تُقابَل الملفات المتغيّرة بالرموز البرمجية التي تلمسها، وتُقابَل الرموز بالمكوّنات المتصلة، وتُرتَّب المجموعات حسب نصف قطر التأثير. تحمل المجموعة ترتيب قراءة موجّهًا ومخططات ورؤى، لا قائمة ملفات مسطّحة.

قاعدتا صدق تشكّلان هذا. مفاتيح المجموعات مشتقة من المحتوى وثابتة بين عمليات الدفع، فتبقى النتائج وتقدّم المراجعة بعد rebase أو force-push ولا تُتيتَم. وإذا لم يكن للمستودع فهرس شفرة، يعود التجميع إلى مسارات الملفات ويصرّح بذلك. البديل لا يدّعي ثقة دلالية.

محاور المراجعة وبواباتها

إلى جانب نتائج المراجعين، تجمع المراجعة نتائج محاور: ستة محاور من نوعين.

المحور	النوع	المصدر
correctness، security	مدفوع بالرموز	نتائج المراجعين أنفسهم
testGap	مدفوع بالرموز	نتائج المراجعين
visual، apiContract	حتمي	يُحسب من غير استهلاك رموز
performance	حتمي	تعداد فقط — لا شيء في المنتج يحسب نتيجة

حكم المحور أحد هذه: pass أو warn أو fail أو partial أو unavailable. لا يجتاز البوابة إلا pass أو warn. التمييز بين fail وpartial وunavailable جوهري: محور عليه بوابة ولم يكتمل، أو لم يستطع العمل أصلًا، يُمسك الحكم الكلي ولا يمرّره. غياب الدليل لا يتحوّل إلى بوابة خضراء.

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

الحكم

يحسب المُنهي الحكم من النتائج التي حالتها open أو consensus-ready:

• أي نتيجة P0 بثقة ≥ 0.7 تؤدي إلى Block
• وإلا فأي P0 (ثقة منخفضة) أو أي P1 تؤدي إلى Hold
• وإلا فالحكم Ship

يحمل الحكم ثقة مجمّعة تُشتق من تشتت درجات الثقة المساهِمة: الاتفاق يرفعها، والافتراق يخفضها.

تجميع الوكيل القائد (CEO) مرور تحريري، لا إعادة لسرد النتائج. نسخة ثانية تُكتب باليد من النتائج هي ما ينحرف عن النسخة الحقيقية. تُخفَّض النتائج المكررة ويبقى ذكرها مرة واحدة. عدة مراجعين يُوجَّهون إلى الفروق نفسها باختصاصات متداخلة عمدًا، فوصول العيب نفسه إلى المُنهي ثلاث مرات علامة على أن النظام يعمل، ونشره ثلاث مرات تسريب لبنية النظام إلى صندوق وارد القارئ. عند إعادة المراجعة تُبصَم النتائج وتُقارَن بالجولة السابقة، فيظهر الفرق.

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

النشر يبقى بيدك

خط الأنابيب لا يرسل إلى GitHub عمدًا. النشر مشروط بفعل المستخدم، حتى لا تُنشر المراجعة مرتين. حين تضغط النشر على GitHub:

• تُقدَّم مراجعة واحدة على GitHub. تُتخطى النتائج المحلولة أو المتجاهَلة أصلًا. ينشر الزر كل نتيجة مفتوحة متبقية (selection: all_open). أداة MCP publish_review_to_github تفترض النتائج التي أكّدها الأقران فقط (consensus).
• النتائج المربوطة بملف وسطر تصبح تعليقات مضمّنة، وما عداها يُطوى في متن الملخص، ويحمل كل منها تذييل “— Control Center AI review” حتى يبقى المصدر واضحًا.
• تُعاد مطابقة المراسي مع فروق طلب السحب الحالية وقت النشر. تعليق على شفرة أُعيدت كتابتها هو أشد ما يهدم الثقة مما قد يتركه مراجع. إذا رفض GitHub مرساة مضمّنة رغم ذلك، تُرسَل المراجعة كلها من جديد وكل نتيجة مطوية في المتن، حتى لا يسقط شيء في صمت.
• يُقدَّم حكم Block بصفة REQUEST_CHANGES، وHold بصفة COMMENT، وShip بصفة APPROVE من الزر (approve_on_ship: true). أداة MCP تُبقي Ship على COMMENT ما لم تُمرَّر approve_on_ship.
• تُنشر المراجعة بهوية تطبيق الخادم. يُسجَّل من ضغط النشر لبوابة الدور ولسجل التدقيق، وهو ليس مؤلف GitHub.

يصرّح النشر بفئة الإجراء prPublish، فتضبطه نقطة الاختناق في الضوابط كما تضبط أي إجراء يعدّل الحالة: الموافقة مطلوبة افتراضيًا، ويفشل الطلب مغلقًا إذا لم يكن هناك معتمِد متصل. انظر الضوابط.

ما يجوز للمراجع

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

مفاهيم ذات صلة

• الضوابط — محرك السياسات الذي يضبط النشر
• الأوضاع — ما يغيّره وضع review للوكيل
• خطوط الأنابيب والأتمتة — المحرك الذي تعمل عليه المراجعة
• دورة حياة إرسال الوكيل — من أين تأتي شجرة العمل المعزولة

أدلة ذات صلة

• استخدام المراجعة المدعومة بالذكاء الاصطناعي — تشغيل مراجعة ونشرها
• إرسال وكلاء مراجعة — اختيار المراجعين بنفسك
• حوسبة المراجعة — المجموعات والمحاور والفروق