منصوبے کے بارے میں

testgraph ایک journey-level ٹیسٹ سلیکٹر ہے۔ git diff کی بنیاد پر، یہ بتاتا ہے کہ کسی تبدیلی نے صارف کے سامنا کرنے والے کن فلو (flows) کو توڑا ہو سکتا ہے اور انہیں کس ترتیب میں ٹیسٹ کیا جانا چاہیے، جس کے نتیجے میں تمام ٹیسٹ دوبارہ چلانے کے بجائے ایک مختصر درجہ بند فہرست ملتی ہے۔ یہ جان بوجھ کر براؤزرز کو نہیں چلاتا، ٹیسٹ تیار نہیں کرتا یا خود کو ٹھیک (self-heal) نہیں کرتا؛ اس کا بنیادی کام موجودہ ڈرائیورز کے اوپر ایک تہہ کے طور پر کام کرنا ہے، یعنی یہ فیصلہ کرنا کہ کس چیز کی ٹیسٹنگ ضروری ہے۔ یہ کیسے کام کرتا ہے ایک journey registry ہر صارف کے سفر اور اس کے انٹری سمبلز (entry symbols) کا نام رکھتی ہے، جیسے کہ route handlers یا scheduler sweep۔ propose ماڈیول ایک نئے repo کے لیے Python route decorators اور Next.js کنونشنز کو انڈیکس کے خلاف اسکین کر کے ایک رجسٹری کا خاکہ تیار کرتا ہے، اور اسے تب تک 'approved false' رکھتا ہے جب تک کوئی انسان اسے پڑھ نہ لے، تاکہ ایک غیر منظور شدہ رجسٹری واضح طور پر الرٹ دے، خاموشی سے نہ چلے۔ ایک diff کے لیے، testgraph تبدیل شدہ لائن رینجز کو ان سمبلز سے جوڑتا ہے جو ان کے مالک ہیں (seeds)؛ پھر CodeGraph edge graph میں الٹی سمت میں transitively ہر اس سمبل تک جاتا ہے جو seed پر منحصر ہے (impacted set)؛ اور ان journeys کی رپورٹ کرتا ہے جن کے انٹری سمبلز اس سیٹ میں آتے ہیں، جنہیں fan-in کی بنیاد پر درجہ بند کیا جاتا ہے، اور ہر ایک کے ساتھ اس مضبوط ترین edge path کا اعتماد (confidence) منسلک ہوتا ہے جس نے اسے پہنچایا۔ اعتماد، راستوں کے مجموعے میں کم ترین edges کی زیادہ سے زیادہ قیمت ہے، لہذا ایک زنجیر صرف اتنی ہی قابل بھروسہ ہے جتنا اس کا کمزور ترین حصہ، جبکہ ایک ٹھوس راستہ کافی ہوتا ہے۔ ایک journey جو صرف کمزور یا مصنوعی edges کے ذریعے پہنچی ہو، اسے خاموشی سے قبول کرنے کے بجائے دستی تصدیق (manual verification) کے لیے نشان زد کیا جاتا ہے، اور اسے سلیکشن سے کبھی نہیں ہٹایا جاتا۔ یہ ٹول recall-first ہے: یہ کسی ایسی journey کو خاموشی سے چھوڑنے کے بجائے زیادہ سلیکشن کو ترجیح دیتا ہے جس پر تبدیلی کا واقعی اثر پڑا ہو۔ جواب دینے سے پہلے، ایک integrity guard خراب یا پرانے CodeGraph انڈیکس پر چلنے سے انکار کر دیتا ہے، کیونکہ غلط گراف ایک پراعتماد مگر غلط جواب پیدا کرتا ہے۔ Registry resolution میں پہلے ملنے والے نتیجے کو ترجیح دی جاتی ہے: پہلے ایک environment variable escape hatch، پھر repo کے اندر .testgraph/journeys ڈائریکٹری (جسے تجویز کردہ جگہ بتایا گیا ہے)، اور پھر پروجیکٹ کے اپنے چیک آؤٹ میں پیکیج کے ساتھ journeys ڈائریکٹری۔ ایک رجسٹری کا ملاپ اس کے خود declared ٹارگٹ پر کیا جاتا ہے نہ کہ اس کے فائل نام پر، اور کسی دوسرے پروجیکٹ سے کاپی کی گئی اور بغیر ترمیم کے چھوڑی گئی رجسٹری کو مسترد کر دیا جاتا ہے۔ ضروریات اور انسٹالیشن صرف اسٹینڈرڈ لائبریری استعمال کرنے والا Python 3.11 یا اس سے نیا ورژن، جس میں کوئی تھرڈ پارٹی ڈیپینڈینسی نہ ہو؛ diff ان پٹ کے لیے git؛ اور ایک ٹارگٹ repo جس کا CodeGraph انڈیکس codegraph init کے ذریعے تیار کیا گیا ہو۔ PyPI سے pip install testgraph کے ذریعے انسٹال کریں۔ wheel صرف پیکیج فراہم کرتا ہے، جبکہ measurement harness اور dogfood registries ریپوزٹری میں موجود ہیں۔ CLI اور MCP کمانڈ لائن انٹری پوائنٹس میں select شامل ہے، جس کا انسانی طور پر پڑھنے کے قابل یا JSON آؤٹ پٹ CI گیٹ یا کسی دوسرے ایجنٹ کے لیے ہوتا ہے؛ export، جو ایک اسٹیٹک journey map لکھتا ہے جسے ایجنٹ pre-commit پر پڑھتا ہے؛ propose؛ record؛ اور ایک summary موڈ۔ MCP stdio سرور دو ٹولز، testgraph_impact اور testgraph_journeys کو ظاہر کرتا ہے، اور اسے ہر repo کے لیے رجسٹر کیا جاتا ہے۔ یہ صرف stdlib پر مبنی ہے اور analysis modules کو lazy طریقے سے امپورٹ کرتا ہے، لہذا ایک فارغ سرور نے sqlite3 لوڈ نہیں کیا ہوتا، کوئی ڈیٹا بیس کنکشن نہیں رکھتا اور میموری میں کوئی انڈیکس نہیں رکھتا۔ README کے مطابق، مکمل ہینڈ شیک کے بعد 15.2 MB RSS ریکارڈ کیا گیا، جبکہ ایک عام Python MCP SDK سرور کے لیے یہ 62 سے 69 MB ہوتا ہے۔ وائرنگ اور لیجر hooks/install.sh ہر اس repo میں ایک pre-push hook انسٹال کرتا ہے جس کی رجسٹری منظور شدہ ہو، تاکہ ہر push ان journeys کو پرنٹ کرے جنہیں اس نے توڑا ہو سکتا ہے۔ hook پہلے codegraph sync چلاتا ہے، کیونکہ seeds لائن رینجز سے آتے ہیں اور کوڈ کی نقل مکانی سے پہلے بنایا گیا انڈیکس پرانے spans کے خلاف diff کو حل کرے گا؛ اگر تبدیل شدہ فائل کے بائٹس اب بھی انڈیکس شدہ کاپی سے مختلف ہیں، تو جواب کی معیار گر جاتا ہے اور فائل کا نام بتایا جاتا ہے۔ hook کبھی push کو فیل نہیں کرتا، ہر راستہ zero کے ساتھ ختم ہوتا ہے، اور اسے git config سیٹنگ کے ذریعے ہر repo کے لیے غیر فعال کیا جا سکتا ہے یا uninstall فلیگ کے ساتھ ہٹایا جا سکتا ہے۔ ہر رن ایک JSONL لیجر میں ایک سلیکشن رو (row) شامل کرتا ہے؛ record کمانڈ دوسرا حصہ لکھتی ہے (کہ journey چلانے سے کیا ملا)، تاکہ repo اور commit پر دونوں کو جوڑ کر ان journeys کی گنتی کی جا سکے جو کسی ایسے commit پر فیل ہوئیں جس کی سلیکشن نے اس کا نام نہیں لیا تھا، جسے silent under-selection کہا گیا ہے۔ اسٹیٹس اسے phase-1 spike اور confidence-weighted paths کے طور پر بیان کیا گیا ہے، جو ایک dogfood ٹارگٹ پر کام کر رہا ہے اور تصدیق شدہ ہے: پانچ ہاتھ سے لیبل شدہ commits پر recall 1.00 اور اوسط precision 0.68، اور ایک آزاد AST oracle کے خلاف بیس بیس seeded mutation sites پر 1.00، جس میں integrity guard ٹیسٹ شدہ اور schema-pinned ہے۔ اس کا دائرہ کار وہی ایک ٹارگٹ ہے، جو بیک اینڈ اور فرنٹ اینڈ فائلوں کا تجزیہ کرتا ہے جن کی journeys بیک اینڈ انٹری پوائنٹس پر رجسٹرڈ ہیں۔ README یہ بھی ریکارڈ کرتا ہے کہ بغیر رجسٹری والے دو repos پر بعد میں کی گئی پیمائش نے بچت کے سابقہ دعوے کو غلط ثابت کیا: 23 journeys پر ایک repo نے 38 commits کے لیے صفر journeys اور 2 commits کے لیے 23 کا ہسٹوگرام دیا، اور 207 journeys پر ایک دوسرے نے صرف 54.1 فیصد journey-runs سے بچایا جب ان commits کو نکال دیا گیا جن کا کسی رجسٹرڈ سطح سے تعلق نہیں تھا، لہذا سلیکشن نمبروں کو بچت کے وعدے کے بجائے coupling کی کم سے کم حد (floor) کے طور پر پڑھا جانا چاہیے۔ اسی پیمائش نے رینکنگ کی تصدیق کی، جہاں ایک غلط-مثبت (false-positive) پوری-رجسٹری سلیکشن کو 0.3 کے اعتماد پر دستی تصدیق کے لیے نشان زد کیا گیا، جبکہ ایک حقیقی بڑے اثر (blast radius) کا نتیجہ 0.9 پر کلین آیا۔