ریویو کمپیوٹ (کوہارٹس، محور اور ڈیٹرمنسٹک ڈفز)
PR کا ریویو ٹیب اسی وقت ریویو پائپ لائن کی زندہ پیش رفت ہوتا ہے جب وہ کام کر رہی ہو، اور پھر وہ آرٹی فیکٹ جو اس نے شائع کیا، اپنے ایکشنز سمیت۔ ایک ہی ٹیب، دو حالتوں میں، کیونکہ یہ دو لمحوں میں ایک ہی چیز ہے۔ یہ کوئی ڈیفالٹ ٹیب نہیں: کسی PR کا کوئی ریویو اس وقت تک نہیں ہوتا جب تک کوئی اسے طلب نہ کرے، چنانچہ AI سے پوچھیں ہی اسے کھولتا ہے۔
اس ٹیب کے پیچھے، cc_server فائل کوہارٹس بناتا ہے، ڈیٹرمنسٹک محور چلاتا ہے
اور انہیں review_studio.* RPC آپریشنز (cohorts، blastRadius،
cohortImpact، ciSignals، dependencyDiffs، setContractDecision،
approveVisual، compute اور ان کے watch* جڑواں) کے ذریعے پیش کرتا ہے۔ کوئی
محفوظ شدہ layout جو اب بھی pr.reviewStudio کا نام لے، یہی ریویو ٹیب کھولتا
ہے۔
ریویو ٹیب پر:
- یکجا کرنے والا ایجنٹ
publish_artifactکے ساتھ ایک عام گفتگو آرٹی فیکٹ شائع کرتا ہے، چنانچہ ٹیب اسے اُسی آرٹی فیکٹ ویوور سے رینڈر کرتا ہے جو کوئی چیٹ ببل کھولتا ہے — آرٹی فیکٹ سسٹم کی کوئی ریویو نما نقل موجود نہیں۔ - نتائج اس کے پہلو میں ایک ریل میں ہوتے ہیں، اور فیصلہ ڈیش بورڈ ہیڈر کے بجائے آرٹی فیکٹ کے اوپر ایک پتلی پٹی پر سوار ہوتا ہے۔
- جب PR کا head ریویو سے آگے بڑھ جائے تو ایک پرانا بینر ظاہر ہوتا ہے۔
بہاؤ کے لیے AI سے چلنے والا ریویو استعمال کریں دیکھیں اور اس پر عمل کرنے کے لیے PR ریویو اور مرج کریں دیکھیں۔
کوہارٹس
سیکشن کا عنوان “کوہارٹس”کوہارٹس PR کی تبدیل شدہ فائلوں کو مواد سے اخذ کی گئی ایسی بالٹیوں میں گروپ کرتے ہیں جن کی فائلیں معنی کے لحاظ سے ایک ساتھ رکھی جاتی ہیں، اور انہیں اثر کے حساب سے درجہ بند کیا جاتا ہے تاکہ سب سے پرخطر گروپ پہلے پڑھا جائے۔ ہر head SHA تبدیلی پر انہیں دوبارہ شمار کیا جاتا ہے اور مکمل طور پر بدل دیا جاتا ہے؛ ہر کوہارٹ کی کلید پش کے دوران مستحکم ہوتی ہے، چنانچہ ایک خلاصہ اور ریویو کی پیش رفت ری بیس کے بعد بھی برقرار رہتے ہیں۔
اگر ریپو کوڈ انڈیکس شدہ نہ ہو تو کوہارٹس سادہ پاتھ گروپنگ پر واپس چلے جاتے
ہیں۔ کسی ریپو کو انڈیکس کرنے کے لیے ترتیبات → ورک اسپیس → ریپوزٹریز استعمال کریں — ریپو
کی ہر قطار میں کوڈ انڈیکس کریں ایکشن ہوتا ہے جو index_code پائپ لائن چلاتا ہے اور
جگہ ہی پر پیش رفت بتاتا ہے۔
کوڈ گراف صرف ان زبانوں کو پارس کرتا ہے جن کے لیے گرامر پہلے سے شامل ہو (Dart، JS/TS، PHP، Python، Rust، Zig، C/C++، Go، Java، Ruby، C#، Swift، Kotlin، R، Assembly، MATLAB، Ada)۔ کسی بھی دوسری زبان والا ریپو کبھی سیمنٹک کوہارٹس نہیں بنا سکتا، چاہے آپ اسے کتنی ہی بار انڈیکس کریں۔
ایجنٹ set_cohort_summary کے ساتھ کسی کوہارٹ کے لیے markdown خلاصہ درج کر سکتا
ہے اور add_review_diagram کے ساتھ ایک ساختی واک تھرو ڈایاگرام منسلک کر سکتا
ہے — ایک ٹائپ شدہ سیکوئنس، اینٹٹی-ریلیشن یا اسٹیٹ-مشین آبجیکٹ، کبھی mermaid
ٹیکسٹ نہیں۔ ہر ایج کو اصل کوڈ گراف کے خلاف جانچا جاتا ہے، اور جو ایج گراف تصدیق
نہ کر سکے اسے حقیقت کے طور پر کھینچنے کے بجائے غیر تصدیق شدہ نشان زد کر دیا
جاتا ہے۔
API کنٹریکٹ کا محور
سیکشن کا عنوان “API کنٹریکٹ کا محور”کنٹریکٹ محور صرف صریح اسپیک فائلوں کا ڈف لیتا ہے۔ یہ چھ ڈیفالٹ ناموں سے
میل کھاتا ہے — openapi.yaml، openapi.yml، openapi.json، swagger.yaml،
swagger.yml، swagger.json — نیز ہر اس تبدیل شدہ فائل سے جس کے نام میں
openapi یا swagger ہو اور جو .yaml، .yml یا .json پر ختم ہو۔ ہینڈلر
کوڈ سے اخذ کردہ کنٹریکٹ دائرہ کار سے باہر ہے اور GraphQL اسکیما کا ڈف نہیں لیا
جاتا۔
ہر تبدیلی کی درجہ بندی کی جاتی ہے — اینڈ پوائنٹ، پیرامیٹر، اسکیما اور رسپانس کے اضافے، حذف اور تبدیلیاں — اور اس کے ساتھ ایک شدت آتی ہے: breaking (اینڈ پوائنٹ یا پیرامیٹر کا حذف، سخت کردہ ٹائپ، نیا لازمی پیرامیٹر)، non-breaking (اضافی)، یا معلوماتی۔ مسترد شدہ تبدیلی کنٹریکٹ گیٹ کو ناکام کر دیتی ہے، اور فیصلہ طلب چھوڑا گیا breaking چینج بھی؛ breaking مگر منظور شدہ انتباہ دیتا ہے؛ کوئی breaking تبدیلی نہ ہو تو گیٹ پاس ہو جاتا ہے۔ derived (advisory) کا نشان لگا ڈف کبھی گیٹ نہیں کرتا۔
کسی تبدیلی کو منظور یا مسترد کرنا review_studio.setContractDecision ہے۔
بصری محور
سیکشن کا عنوان “بصری محور”اگر PR کسی Widgetbook ایپ والے Flutter ریپو میں UI کمپونینٹس بدلتا ہے، تو compute
پاس PR کے base اور head ورک ٹریز میں ایک ہیڈلیس flutter test golden پاس کے
ذریعے تبدیل شدہ کمپونینٹس کو پہلے اور بعد میں رینڈر کرتا ہے، پھر پکسلز کا ڈف
لیتا ہے۔
changed یا removed کا نشان لگے اسنیپ شاٹس منظور ہونے تک بصری گیٹ کو روکے رکھتے ہیں؛ unchanged، added اور approved اسنیپ شاٹس اسے کھول دیتے ہیں۔ عدم دستیابی کی چار میں سے ایک وجہ ہوتی ہے: ہوسٹ پر Flutter SDK کا نہ ہونا، ریپو میں Widgetbook ایپ کا نہ ہونا، golden کے قابل ٹیسٹ کیسز کا نہ ہونا، یا golden ہارنس کی خرابی۔
کسی ارادی تبدیلی کو منظور کرنا review_studio.approveVisual ہے۔
محور اور فیصلہ
سیکشن کا عنوان “محور اور فیصلہ”| محور | کس سے چلتا ہے |
|---|---|
| درستگی | ریویوور ایجنٹس (ٹوکنز) |
| سیکیورٹی | ریویوور ایجنٹس (ٹوکنز) |
| ٹیسٹ گیپ | ریویوور ایجنٹس (ٹوکنز) |
| بصری | ڈیٹرمنسٹک (golden ہارنس) |
| API کنٹریکٹ | ڈیٹرمنسٹک (اسپیک ڈف) |
تین ٹوکن محور اس وقت درج ہوتے ہیں جب کوئی لیڈ ایجنٹ finalize_review کال کرتا
ہے؛ دو ڈیٹرمنسٹک محور compute پاس درج کرتا ہے۔
ہر محور ان میں سے ایک رپورٹ کرتا ہے:
| اسٹیٹ | مطلب |
|---|---|
| Pass | چلا، کچھ رکاوٹ ڈالنے والا نہیں ملا |
| Warn | چلا، غیر رکاوٹی خدشات |
| Fail | چلا، ایک رکاوٹ ڈالنے والا مسئلہ ملا |
| Partial | چلا مگر مکمل نہ ہو سکا؛ نتائج ادھورے ہیں |
| Unavailable | بالکل چل ہی نہ سکا |
صرف pass اور warn ایک گیٹڈ محور کو کھولتے ہیں۔ Partial اور unavailable جان بوجھ کر fail سے الگ ہیں اور ان میں سے کوئی بھی گیٹ نہیں کھولتا۔
محور مل کر Ship، Hold یا Block میں ڈھلتے ہیں، اور وہ فیصلے کو صرف زیادہ سخت ہی بنا سکتے ہیں — اسے کبھی کم نہیں کیا جاتا۔ ناکام ہونے والا گیٹڈ محور Block نافذ کرتا ہے؛ جو partial یا unavailable ہو وہ کم از کم Hold نافذ کرتا ہے۔ چنانچہ جو رکاوٹ ڈالنے والا محور چل ہی نہ سکا وہ فیصلے کو روکے رکھتا ہے: ثبوت کی عدم موجودگی کبھی کوئی گیٹ سبز نہیں کرتی۔
ریویو ٹیب پر فیصلہ وہی ہوتا ہے جو finalize_review نے پوسٹ کیا۔