محاسبهٔ بازبینی (گروه‌ها، محورها و دیف‌های قطعی)
زبانهٔ بازبینی یک PR، نخست پیشرفت زندهٔ پایپ‌لاین بازبینی است هنگامی که کار می‌کند، و سپس آرتیفکتی که منتشر کرده، همراه با کنش‌های روی آن. یک زبانه با دو حالت، چون این دو در دو زمان یک چیزند. زبانهٔ پیش‌فرض نیست: هیچ PRی بازبینی ندارد تا وقتی کسی درخواستش کند، پس پرسش از AI همان چیزی است که آن را باز می‌کند.
پشت آن زبانه، cc_server گروه‌های فایل را می‌سازد، محورهای قطعی را اجرا می‌کند
و آن‌ها را از طریق عملیات‌های RPC در review_studio.* ارائه می‌دهد (cohorts،
blastRadius، cohortImpact، ciSignals، dependencyDiffs،
setContractDecision، approveVisual، compute و جفت‌های watch*شان).
یک چیدمان ماندگار که هنوز نام pr.reviewStudio را دارد، همین
زبانهٔ بازبینی را باز می‌کند.
در زبانهٔ بازبینی:
- عامل یکپارچه‌ساز یک آرتیفکت گفتگوی معمولی را با
publish_artifactمنتشر می‌کند، پس زبانه آن را از همان نمایشگر آرتیفکتی رندر می‌کند که یک حباب گفتگو باز می‌کند — هیچ نسخهٔ بازبینی‌شکلی از سیستم آرتیفکت وجود ندارد. - یافته‌ها در نواری کنار آن می‌نشینند و حکم، به‌جای ترویس‌های داشبورد، روی نواری باریک بالای آرتیفکت سوار می‌شود.
- وقتی head مربوط به PR از بازبینی جلو بزند، بنری از کهنه‌بودن بازبینی ظاهر می‌شود.
برای دیدن روند، استفاده از بازبینی مبتنی بر هوش مصنوعی را ببینید و برای اقدام بر مبنای آن، بازبینی و ادغام یک PR.
گروه‌ها
بخش با عنوان “گروه‌ها”گروه‌ها فایل‌های تغییرکردهٔ PR را به سبدهای محتوامحور از فایل‌هایی دسته‌بندی می‌کنند که از نظر معنا به هم تعلق دارند، و بر اساس اثر مرتب می‌شوند تا پرخطرترین گروه اول خوانده شود. آن‌ها با هر تغییر head-SHA دوباره محاسبه و یک‌جا جایگزین می‌شوند؛ هر گروه یک کلید پایدار نسبت به push دارد، پس یک خلاصه و پیشرفت بازبینی از 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
بخش با عنوان “محور قرارداد API”محور قرارداد تنها فایل‌های مشخصات صریح را دیف می‌کند. با شش نام پیش‌فرض تطبیق
می‌دهد — openapi.yaml، openapi.yml، openapi.json، swagger.yaml،
swagger.yml، swagger.json — به‌علاوهٔ هر فایل تغییرکرده‌ای که نامش openapi
یا swagger دارد و به .yaml، .yml یا .json ختم می‌شود. قراردادی که از کد
هندلر استنتاج شود خارج از دامنه است و شِماهای GraphQL دیف نمی‌شوند.
هر تغییر طبقه‌بندی می‌شود — افزودن، حذف و اصلاح endpoint، پارامتر، شِما و پاسخ — و یک شدت حمل می‌کند: شکننده (endpoint یا پارامتر حذف‌شده، نوع تنگ‌ترشده، پارامتر اجباری جدید)، غیرشکننده (افزودنی)، یا اطلاعاتی. یک تغییر ردشده دروازهٔ قرارداد را رد می‌کند، و همچنین یک تغییر شکننده که بی‌تصمیم رها شده باشد؛ تغییر شکننده اما تأییدشده هشدار می‌دهد؛ و اگر هیچ تغییر شکننده‌ای نباشد، قبول می‌شود. دیفی که مشتق (مشورتی) علامت خورده باشد هرگز دروازه نمی‌گذارد.
تأیید یا رد یک تغییر همان review_studio.setContractDecision است.
محور بصری
بخش با عنوان “محور بصری”اگر PR کامپوننت‌های رابط کاربری را در یک مخزن Flutter با یک اپ Widgetbook عوض کند،
گذرِ محاسبه کامپوننت‌های تغییرکرده را پیش و پس از تغییر، از طریق یک گذر گلدنِ
بدون رابط با flutter test در worktreeهای base و head آن PR رندر می‌کند، و سپس
پیکسل‌ها را دیف می‌کند.
عکس‌های فوری که changed یا removed علامت خورده‌اند، دروازهٔ بصری را تا تأیید نگه می‌دارند؛ عکس‌های فوری unchanged، added و approved آن را باز می‌کنند. عدم دسترسی یکی از چهار دلیل را دارد: 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 ثبت کرده.