AI ریویو

ریویو کی ساخت

ایک AI ریویو، کسی ایک کھلے pull request کے خلاف پہلے سے فراہم کردہ pr_review پائپ لائن کا ایک رن ہوتا ہے۔ پائپ لائن PR کا ریویو اسپیس کھولتی ہے، ریویوور ایجنٹس کو اس اسپیس کے الگ تھلگ چیک آؤٹ میں ڈف پڑھنے کے لیے پھیلا دیتی ہے، ہر ایک اپنے نتائج کو ساختہ ریویو نوڈز کے طور پر درج کرتا ہے، ایک لیڈ ایجنٹ انہیں یکجا کر کے ایک تفصیلی وضاحت بناتا ہے، اور ایک فائنلائزر ایک فیصلہ نکالتا ہے: Ship، Hold یا Block۔ پائپ لائن جو کام کبھی نہیں کرتی وہ اشاعت ہے — GitHub پر پوسٹ کرنا ایک الگ، سوچا سمجھا قدم ہے جو کوئی انسان اٹھاتا ہے۔

اس صفحے کے باقی حصے میں یہ اجزاء اور یہ کہ انہیں اس انداز میں کیوں ڈھالا گیا ہے، بیان کیا گیا ہے۔

فی PR ایک ریویو اسپیس

کسی PR کا ریویو کانٹیکسٹ ایک میسجنگ اسپیس ہوتا ہے — موڈ review، قسم pr — جو pull request سے ایک ریویو اسپیس ایسوسی ایشن کے ذریعے منسلک ہوتا ہے۔ اسے اس انداز میں بنایا جاتا ہے کہ دہرانے پر بھی وہی ایک اسپیس رہے: PR صفحہ، ریویو پائپ لائن اور چیٹ کی سطحیں سب ایک ہی کوڈ پاتھ کے ذریعے PR کے ایک بیکنگ اسپیس تک پہنچتی ہیں، چنانچہ کوئی ٹیمپلیٹ جو PR کا ریویو کرتا ہے اور کوئی انسان جو اسے کھولتا ہے، کبھی دو مختلف کمروں میں دو مختلف چیک آؤٹس دیکھتے ہوئے نہیں پہنچ سکتے۔

اسپیس کے الگ تھلگ ورک ٹری میں PR اس کے head ref پر چیک آؤٹ ہوتا ہے۔ ایک کمرہ ایک ہی چیک آؤٹ کا مطلب بھی ہے: ہر ریویوور ایک ہی اسپیس میں کام کرتا ہے، بجائے اس کے کہ ہر ایک کو ورک اسپیس کا اپنا کلون ملے۔

ہر ریویوور اسی ایک اسپیس کے اندر اپنی نامزد اسٹریم میں پوسٹ کرتا ہے، اور نتائج سادہ نثر کے بجائے review_node پیغامات ہوتے ہیں۔ آخر میں پوری اسپیس پر محیط یکجا کرنا جان بوجھ کر ہے — ایک تھریڈ کے نتائج سے نکالا گیا فیصلہ خاموشی سے ایک ہی ریویوور کے بارے میں فیصلہ ہوگا۔

ایسوسی ایشن ایک اسٹیٹس سیڑھی رکھتی ہے — requested → in progress → awaiting approval → completed — اور یہی PR کے ریویو ٹیب پر GitHub پر شائع کریں کو گیٹ کرتی ہے۔

ریویو کی سطحیں

ریویو کتنا گہرا جائے، یہ ایک ورک اسپیس پالیسی ہے جس کی تین سطحیں ہیں، جو ترتیبات → ورک اسپیس → عام پر، ورک اسپیس پالیسی کارڈ میں سیٹ ہوتی ہے:

سطح	کون سے ریویوورز پھیلتے ہیں	رپورٹنگ
`light`	صرف انجینئر	صرف وہی جو واقعی اہم ہو
`balanced`	انجینئر، QA، آرکیٹیکٹ (ڈیفالٹ)	معمول کا پاس
`thorough`	پانچوں، بشمول سیکیورٹی اور پرفارمنس	کچھ بھی نیچے نہیں کیا جاتا

سطح بیک وقت دو ڈائل گھماتی ہے: کون سے ریویوورز پھیلتے ہیں، جو پائپ لائن ٹیمپلیٹ کے runWhen اسٹیٹ گیٹس سے نافذ ہوتا ہے نہ کہ پرامپٹ کے الفاظ سے — پرامپٹ کے الفاظ نظر انداز کیے جا سکتے ہیں، گیٹ نہیں — اور یہ کہ حد سے کم نتائج کہاں دکھائے جائیں۔ کوئی بھی ڈائل کبھی کوئی نتیجہ حذف نہیں کرتا: جو سطح کم رپورٹ کرتی ہے وہ بھی اتنا ہی درج کرتی ہے اور باقی کو گروپ کر دیتی ہے۔

سیکیورٹی اور پرفارمنس پاس نئے ایجنٹس متعارف کرانے کے بجائے پہلے سے فراہم کردہ آرکیٹیکٹ اور انجینئر ایجنٹس کو دوبارہ استعمال کرتے ہیں۔ تخصص وہ بریف ہے جس کے ساتھ ریویوور کو بھیجا جاتا ہے، نہ کہ ہر محور کے لیے ایک الگ ایجنٹ — ہر محور کے لیے ایک ایجنٹ کا مطلب ہر ورک اسپیس میں پانچ اضافی قطاریں ہوں گی، بغیر کسی اضافی صلاحیت کے۔ ریویوور کے انتخاب میں کبھی زبان یا ڈومین کے لیے ڈف کا معائنہ نہیں کیا جاتا۔

ریویو نوڈز: نتائج بطور ڈیٹا، نثر کے طور پر نہیں

add_review_node کے ذریعے درج کیا گیا نتیجہ PR پر ایک ریویو نوڈ بن جاتا ہے — یہی وہ چیز ہے جو ریویو ٹیب دکھاتا ہے، جس سے فیصلہ شمار کیا جاتا ہے، اور جسے “GitHub پر شائع کریں” ایک اِن لائن تبصرے میں بدلتا ہے۔ جو ریویوور صرف نثر واپس کرتا ہے وہ ایک ایسا پائپ لائن رن پیدا کرتا ہے جو کامیاب دکھائی دیتا ہے اور ایک ایسی ریویو سطح جو خالی ہوتی ہے؛ درج کرنا ہی اصل بنیاد ہے۔

ہر نوڈ یہ رکھتا ہے:

فیلڈ	اقدار
قسم	`bug`, `suggestion`, `recommendation`, `question`, `ticket`
ترجیح	P0 (سنگین) → P3 (معمولی)
ٹرائیج ٹرپل	category (`security`, `stability`, …)، severity، effort
اینکر	فائل پاتھ، لائن کی شروعات اور اختتام
فکس کریریج	تجویز کردہ متبادل لائنیں، ایک اختیاری ڈف، ایک اختیاری فکس پرامپٹ
اعتماد	ایک [0, 1] اسکور
استدلال	وہ تجزیہ، جو نتیجے سے پہلے لکھا گیا

دو تفصیلیں جان بوجھ کر ہیں۔ ایک کلک والی GitHub تجویز صرف اسی صورت پیش کی جاتی ہے جب ریویوور نے عین متبادل لائنیں فراہم کی ہوں — انہیں کسی unified ڈف سے اخذ کرنا خاموشی سے غلط ہو جاتا ہے، اور غلط اخذ کردہ چیز کا ایک کلک میں کمٹ کرنا کسی بٹن کے نہ ہونے سے بدتر ہے۔ اور add_review_node اسکیما نتیجے سے پہلے reasoning پیش کرتا ہے، چنانچہ جو ماڈل آبجیکٹ کو اسکیما کی ترتیب سے بھرتا ہے وہ پہلے تجزیہ لکھتا ہے۔ یہ فیلڈ اختیاری ہے: اسے چھوڑ دینے سے نوڈ مسترد نہیں ہوتا۔ جس نوڈ کا پے لوڈ خراب ہو وہ ریویو کو آلودہ کرنے کے بجائے غائب ہو جاتا ہے۔

ساتھیوں کا اتفاقِ رائے

ایک نوڈ open → consensus-ready → resolved یا dismissed کے مراحل سے گزرتا ہے۔ درمیانی قدم اس ماڈل کا دل ہے: کوئی نتیجہ صرف اسی وقت ترقی پاتا ہے جب کوئی ساتھی ریویوور اس کی تصدیق کرے، اور کوئی ایجنٹ کبھی اپنے ہی نتیجے کی تصدیق نہیں کر سکتا۔ MCP ٹول publish_review_to_github اور RPC ڈیفالٹ اب بھی صرف ساتھی کی تصدیق شدہ نتائج شائع کرتے ہیں۔ اس کے بجائے ریویو ٹیب کا GitHub پر شائع کریں بٹن ہر باقی ماندہ کھلے نتیجے کو بھیج دیتا ہے۔

یہ اصول تین آزاد مقامات پر نافذ کیا جاتا ہے — کنفرم ٹول، فائنلائزر اور پبلشر — چنانچہ ان میں سے کسی ایک میں خراب کالر ہونے پر بھی یہ برقرار رہتا ہے۔ تمام اسٹیٹس تبدیلیاں ایک ہی سروس سے گزرتی ہیں، اور یہی چیز اسٹیٹس کو معنی خیز بناتی ہے: اس سے پہلے، دو ادھورے راستے اس بات پر متفق نہیں ہو سکتے تھے کہ ایک ہی نتیجہ حل ہوا تھا یا نہیں۔

جب ریویوورز میں اختلاف ہو — ایک ہی فائل اور لائن، ترجیحات دو یا زیادہ درجوں کے فاصلے پر، یا ایک اسے bug کہے جبکہ دوسرا اسے suggestion کہے — تو یہ اختلاف نتائج کی فہرست کے اوپر نمایاں کیا جاتا ہے۔ یہی وہ جگہ ہے جہاں ریویوورز کی رائے الگ ہوتی ہے اور انسان کی رائے سب سے زیادہ قیمتی ہوتی ہے۔

کسی نتیجے کو برطرف کرنا میموری ڈومین میں کم اعتماد کے ساتھ ایک نرم سپریشن فیکٹ بھی لکھتا ہے — ایک بار برطرف کرنا ایک ترجیح ہے، کوئی اصول نہیں۔

کوہارٹس: ریویو کس چیز کے گرد گروپ کیا جاتا ہے

ریویو کمپیوٹ پاس PR کی تبدیل شدہ فائلوں کو کوہارٹس میں گروپ کرتا ہے جو کوڈ گراف سے اخذ کیے جاتے ہیں: تبدیل شدہ فائلیں ان سمبلز پر نقش ہوتی ہیں جنہیں وہ چھوتی ہیں، سمبلز منسلک کمپونینٹس پر، اور کوہارٹس کو blast radius کے حساب سے درجہ بند کیا جاتا ہے۔ ایک کوہارٹ ایک فلیٹ فائل فہرست ہونے کے بجائے ایک رہنمائی شدہ پڑھنے کی ترتیب، خاکے اور بصیرتیں ساتھ رکھتا ہے۔

دو دیانت داری کے اصول اسے تشکیل دیتے ہیں۔ کوہارٹ کیز مواد سے اخذ شدہ اور پشز کے دوران مستحکم ہوتی ہیں، چنانچہ نتائج اور ریویو کی پیش رفت ری بیس یا فورس پش کے بعد بھی یتیم ہونے کے بجائے برقرار رہتی ہے۔ اور جب ریپو میں کوڈ انڈیکس موجود نہ ہو تو گروپ بندی سادہ پاتھز پر واپس چلی جاتی ہے اور یہ بات بتا دیتی ہے — یہ فال بیک کبھی سیمنٹک اعتماد کا جھوٹا روپ نہیں دھارتی۔

ریویو محور اور گیٹس

ریویوورز کے نتائج کے ساتھ ساتھ، ایک ریویو محور نتائج بھی جمع کرتا ہے: چھ محور، دو اقسام کے۔

محور	قسم	کہاں سے لیا گیا
`correctness`, `security`	ٹوکن سے چلنے والا	خود ریویوورز کے نتائج
`testGap`	ٹوکن سے چلنے والا	ریویوورز کے نتائج
`visual`, `apiContract`	ڈیٹرمنسٹک	ٹوکن خرچ کیے بغیر شمار کیا جاتا ہے
`performance`	ڈیٹرمنسٹک	صرف enum — پروڈکٹ میں کوئی چیز نتیجہ شمار نہیں کرتی

ایک محور کا فیصلہ pass، warn، fail، partial یا unavailable ہوتا ہے — اور صرف pass یا warn گیٹ پاس کراتا ہے۔ fail، partial اور unavailable کے درمیان فرق بنیادی اہمیت کا حامل ہے: کوئی گیٹڈ محور جو مکمل نہ ہو سکا یا بالکل چل ہی نہ سکا، مجموعی فیصلے کو پاس کرانے کے بجائے روکے رکھتا ہے۔ ثبوت کی عدم موجودگی کبھی سبز گیٹ میں تبدیل نہیں ہوتی۔

کچھ محور جان بوجھ کر مشورہ دینے والے ہوتے ہیں۔ کوہارٹس سے اخذ کردہ ٹیسٹ گیپ محور dependency-injection یا فیکٹری کوریج نہیں دیکھ سکتا — ایک غیر انڈیکس شدہ ریپو جس میں مکمل ٹیسٹ سوٹ ہو اور ایک جس میں بالکل ٹیسٹ نہ ہوں، وہاں سے بالکل ایک جیسے دکھائی دیتے ہیں، چنانچہ ان میں سے کسی ایک کا دعویٰ کرنا جھوٹ ہوگا؛ یہ گیٹ کیے بغیر ڈیش بورڈ میں نمایاں ہوتا ہے۔ ٹوکن والے محور مشورہ دینے والے ہیں کیونکہ نتائج کی ترجیحات پہلے ہی فیصلہ چلاتی ہیں، اور ان پر دوبارہ گیٹ لگانا دوہرا شمار کرنا ہوگا۔

فیصلہ

فائنلائزر ان نتائج پر فیصلہ شمار کرتا ہے جن کا اسٹیٹس 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” فوٹر رکھتا ہے تاکہ ماخذ واضح رہے۔
اشاعت کے وقت اینکرز کی PR کے موجودہ ڈف کے خلاف دوبارہ تصدیق کی جاتی ہے۔ ایسے کوڈ پر تبصرہ جو پہلے ہی دوبارہ لکھا جا چکا ہو، سب سے زیادہ اعتماد تباہ کرنے والی چیز ہے جو ریویوور چھوڑ سکتا ہے؛ اگر GitHub پھر بھی کوئی اِن لائن اینکر مسترد کر دے تو پورا ریویو دوبارہ بھیجا جاتا ہے اور ہر نتیجہ باڈی میں شامل کر دیا جاتا ہے تاکہ کچھ بھی خاموشی سے ضائع نہ ہو۔
Block فیصلہ REQUEST_CHANGES کے طور پر جمع ہوتا ہے؛ Hold بطور COMMENT؛ Ship بٹن سے بطور APPROVE (approve_on_ship: true)۔ MCP ٹول Ship کو COMMENT ہی رہنے دیتا ہے جب تک آپ approve_on_ship نہ بھیجیں۔
ریویو سرور کی ایپ شناخت کے تحت پوسٹ کیا جاتا ہے۔ کس نے Publish دبایا یہ رول گیٹ اور آڈٹ لاگ کے لیے ریکارڈ کیا جاتا ہے؛ یہ GitHub مصنف نہیں ہوتا۔

اشاعت prPublish ایکشن کلاس کا اعلان کرتی ہے، چنانچہ گارڈریل چوک پوائنٹ اسے کسی بھی میوٹیٹنگ ایکشن کی طرح گیٹ کرتا ہے — یہ بطور ڈیفالٹ پرامپٹ کرتا ہے اور جب کوئی منظور کنندہ منسلک نہ ہو تو بند ہو کر ناکام ہو جاتا ہے۔ گارڈریلز دیکھیں۔

ریویوور کیا کر سکتا ہے

ریویوور ایجنٹس review موڈ میں چلتے ہیں: ایک صرف پڑھنے کے لیے سینڈ باکس اور ایک ترتیب شدہ ٹول اجازت فہرست جو نتائج، تبصروں، ٹکٹس اور ساتھی ریویو کا احاطہ کرتی ہے — لیکن کوئی میوٹیشن نہیں۔ ایک ریویوور جس کوڈ پر تنقید کرتا ہے اسے خود ٹھیک نہیں کر سکتا؛ وہ ایک تجویز کردہ فکس منسلک کر سکتا ہے جسے کوئی انسان لاگو کرتا ہے۔ موڈ کا انکار کا پیغام ایسے ایجنٹ کو جو پھر بھی عمل کرنے کی کوشش کرے، بتاتا ہے کہ ریویو مکمل کرے اور صارف کو شائع شدہ سمری پر عمل کرنے دے۔