حوسبة المراجعة (المجموعات والمحاور والفروق الحتمية)

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

خلف هذا اللسان يبني cc_server مجموعات الملفات، ويشغّل المحاور الحتمية، ويقدّمها عبر عمليات RPC في review_studio.* (cohorts وblastRadius وcohortImpact وciSignals وdependencyDiffs وsetContractDecision وapproveVisual وcompute وتوائمها watch*). التخطيط المحفوظ الذي ما زال يسمّي pr.reviewStudio يفتح لسان مراجعة نفسه.

في لسان مراجعة:

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

انظر استخدام المراجعة المدعومة بالذكاء الاصطناعي لسير العمل، ومراجعة طلب سحب ودمجه للتصرف بناءً عليها.

المجموعات

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

إن لم يكن للمستودع فهرس شفرة، تعود المجموعات إلى التجميع حسب المسار. لفهرسة مستودع، استخدم الإعدادات ← مساحة العمل ← المستودعات — وإجراء فهرسة التعليمات البرمجية في كل صف يشغّل خط أنابيب index_code ويبلّغ التقدّم في موضعه.

لا يحلّل مخطط الشفرة إلا اللغات التي تُشحَن لها قاعدة نحوية (Dart و JS/TS و PHP و Python و Rust و Zig و C/C++ و Go و Java و Ruby و C# و Swift و Kotlin و R و Assembly و MATLAB و Ada). مستودع بلغة غير هذه لا ينتج مجموعات دلالية أبدًا، مهما كرّرت فهرسته.

يستطيع الوكيل أن يسجّل ملخص markdown لمجموعة عبر set_cohort_summary، وأن يرفق مخطط جولة منظَّمًا عبر add_review_diagram — كائن منمَّط لتسلسل أو علاقة كيانات أو آلة حالات، لا نص mermaid. تُراجَع كل حافة على مخطط الشفرة الحقيقي، والحافة التي لا يؤيّدها المخطط تُوسَم غير محقَّقة بدل أن تُرسَم واقعة.

محور عقد API

لا يحسب محور العقد الفروق إلا في ملفات المواصفات الصريحة. يطابق الأسماء الافتراضية الستة — openapi.yaml وopenapi.yml وopenapi.json وswagger.yaml وswagger.yml وswagger.json — وأي ملف متغيّر يحتوي اسمه openapi أو swagger وينتهي بـ .yaml أو .yml أو .json. عقد يُستنتج من شفرة المعالج خارج النطاق، ومخططات GraphQL لا تُقارَن.

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

الموافقة على تغيير أو رفضه هي review_studio.setContractDecision.

المحور البصري

إن غيّر طلب السحب مكوّنات الواجهة في مستودع Flutter فيه تطبيق Widgetbook، تعرض جولة الحوسبة المكوّنات المتغيّرة قبل التغيير وبعده عبر مرور ذهبي بلا واجهة من flutter test في شجرتَي عمل base وhead لطلب السحب، ثم تقارن البكسلات.

اللقطات الموسومة متغيّرة أو مُزالة تمسك البوابة البصرية حتى الموافقة عليها، ولقطات غير متغيّرة ومُضافة وموافَق عليها تُخليها. أسباب عدم التوفر أربعة: لا Flutter SDK على المضيف، أو لا تطبيق Widgetbook في المستودع، أو لا حالات استخدام قابلة لاختبار ذهبي، أو خطأ في عدة الاختبار الذهبي.

الموافقة على تغيير مقصود هي review_studio.approveVisual.

المحاور والحكم

المحور	مدفوع بـ
الصحة	وكلاء مراجعة (رموز)
الأمان	وكلاء مراجعة (رموز)
فجوة الاختبارات	وكلاء مراجعة (رموز)
البصري	حتمي (عدة الاختبار الذهبي)
عقد API	حتمي (فرق المواصفات)

تُسجَّل محاور الرموز الثلاثة حين يستدعي الوكيل القائد finalize_review، وتُسجِّل جولة الحوسبة المحورين الحتميين.

يبلّغ كل محور بإحدى هذه الحالات:

الحالة	المعنى
Pass	اشتغل، ولم يجد ما يعيق
Warn	اشتغل، وفيه مسائل لا تعيق
Fail	اشتغل، ووجد مشكلة تعيق
Partial	اشتغل ولم يكتمل؛ النتائج ناقصة
Unavailable	لم يستطع العمل أصلًا

لا يُخلي محورًا عليه بوابة إلا pass وwarn. Partial وunavailable مختلفان عن fail عن قصد، ولا يُخلي أي منهما بوابة.

تتجمّع المحاور في Ship أو Hold أو Block، ولا تستطيع إلا أن تجعل الحكم أشد، ولا يُخفَّض الحكم أبدًا. محور عليه بوابة وحالته fail يفرض Block؛ ومحور عليه بوابة حالته partial أو unavailable يفرض Hold على الأقل. فالمحور المعيق الذي لم يستطع العمل يمسك الحكم: غياب الدليل لا يتحوّل إلى بوابة خضراء.

الحكم في لسان مراجعة هو ما نشره finalize_review.