کوڈ انٹیلیجنس

Control Center ایجنٹ کو کوڈ کو محض پڑھنے سے آگے بڑھ کر سمجھنے کے چار طریقے دیتا ہے۔ یہ چاروں واقعی الگ الگ سوالوں کے جواب دیتے ہیں، اور ایک کے بجائے چار ہونے کی وجہ یہ ہے کہ کوئی اکیلا طریقہ ان سب کا جواب نہیں دیتا۔

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

لینگویج سرور جو خلا پُر کرتا ہے

کوڈ گراف tree-sitter سے بنتا ہے: علامات، کال ایجز، اور اثر کا دائرہ۔ یہ تیز ہے، سستا ہے، اور ٹائپوں کے بارے میں کچھ نہیں جانتا۔ نہ یہ بتا سکتا ہے کہ ابھی آپ نے جو کال لکھی وہ کمپائل ہوتی ہے یا نہیں، نہ یہ کہ وہ فیلڈ آبجیکٹ پر موجود ہے، اور نہ یہ کہ آپ کے ری نیم سے کوئی ری ایکسپورٹ رہ گیا۔

لینگویج سرور کے بغیر ایجنٹ کو پتہ ٹیسٹ کے وقت چلتا ہے — یا کبھی نہیں۔ وہ کوئی معقول سا کوڈ لکھ کر آگے بڑھ جاتا ہے، اور ناکامی تین باریں بعد کسی اور تبدیلی سے منسلک ہو کر سامنے آتی ہے۔

تو اصل فائدہ درحقیقت lsp ٹول نہیں ہے۔ اصل بات یہ ہے کہ write، edit اور apply_patch لپیٹ دیے گئے ہیں: ہر تحریر کے بعد فائل لینگویج سرور سے گزرتی ہے اور نئی سامنے آنے والی تشخیصات ٹول کے نتیجے میں شامل کر دی جاتی ہیں۔ ایجنٹ کو اُسی لمحے پتہ چل جاتا ہے جب اس نے بلڈ توڑا، چاہے اس نے پوچھنے کے بارے میں سوچا ہو یا نہ۔

صرف نئی تشخیصات

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

سست، اور اپنی غیر موجودگی پر سچا

بوٹ پر کوئی سرور شروع نہیں ہوتا۔ سرور پہلی ایسی درخواست پر شروع ہوتا ہے جسے اُس کی ضرورت ہو — جو تقریباً ہمیشہ اُس فائل کی پہلی ترمیم ہوتی ہے جس پر وہ دعویٰ کرتا ہے — اور بیکار پڑے سرورز صاف کر دیے جاتے ہیں۔ جو ہوسٹ کبھی Dart کو چھوتا ہی نہیں، وہ کبھی اینالائزر شروع نہیں کرتا۔

پہچان ایک تقاطع پر ہوتی ہے: چیک آؤٹ میں روٹ مارکر کا موجود ہونا چاہیے اور بائنری کا حل ہونا چاہیے۔ صرف مارکر یہ بتاتا ہے کہ “یہ پروجیکٹ Python ہے” اور یہ نہیں کہ سرور انسٹال ہے یا نہیں؛ اور صرف حل ہونے والی بائنری یہ بتاتی ہے کہ ہوسٹ پر ٹول چین موجود ہے، مگر اس چیک آؤٹ کے بارے میں کچھ نہیں۔ صرف دونوں کے اکٹھے ہونے کا مطلب یہ ہے کہ کوئری کامیاب ہو سکتی ہے، اور ایسا ٹول جو پیش کیا جائے مگر ہمیشہ ناکام ہو، غیر موجود ٹول سے بدتر ہے۔

جب grep موجود ہے تو ساختی تلاش کیوں

grep حروف سے میل کھاتا ہے۔ یہ کسی نام کے لیے صحیح ٹول ہے اور کسی شکل کے لیے غلط۔

ساختی پیٹرن کو فائل ہی کے گرامر سے پارس کیا جاتا ہے، اس لیے dispose($X) کال کو اُس کی ہر شکل میں ڈھونڈ لیتا ہے — خواہ وہ کس طرح پھیلی، لپٹی یا لائنوں میں ٹوٹی ہو — اور کسی سٹرنگ لٹرل یا تبصرے کے اندر انہی حروف سے کبھی میل نہیں کھاتا۔

جس خاصیت کی وجہ سے یہ محض چند اضافی قدموں والا ریجیکس نہیں رہتا، وہ یہ ہے کہ ایک ہی پیٹرن میں دہرایا گیا میٹا متغیر لازماً وہی متن پکڑتا ہے:

if ($X != null) $X.dispose()

یہ ایسی گارڈ سے میل کھاتا ہے جو اُسی چیز کو ڈسپوز کرتی ہے جس کی اس نے جانچ کی تھی، اور ایسی گارڈ سے میل نہیں کھاتا جو کسی اور چیز کو ڈسپوز کرے۔ یہ بگ کی ایسی قسم ہے جسے متنی طور پر بیان ہی نہیں کیا جا سکتا۔

یہ اُسی tree-sitter پر چلتی ہے جو پہلے سے منسلک ہے

یہاں کوئی دوسرا انجن نہیں۔ cc_natives کوڈ گراف کے لیے پہلے ہی tree-sitter اور اس کے گرامر لوڈ کرتا ہے، ساتھ میں کمپائل شدہ کوئری کیش اور زبانوں کی ٹیبل۔ میچر خالص Dart ہے اور اُن ہی درختوں پر چلتا ہے جو بہرحال پارس ہو رہے تھے۔ دوسرا ساختی انجن بنانے کا مطلب ہوگا دوسرا پارسر، گرامر کا دوسرا مجموعہ جو ہر پلیٹ فارم پر بنایا اور اسٹیج کیا جائے، اور “کال ایکسپریشن کیا ہے” کے دو جواب۔

ٹکڑے کو رہنے کے لیے جگہ چاہیے

گرامر صرف یہ بتاتا ہے کہ پوری فائل کیا ہوتی ہے۔ Dart کے ٹاپ لیول پر ننگا پارس کرنے پر dispose(x) بالکل درست فنکشن سگنیچر بنتا ہے — dispose نام کا اعلان جو x پیرامیٹر لیتا ہے — اور کوئی ایرر ایسا نہیں جو اس کی حقیقت کھول دے۔ ایسے پارس پر بنایا گیا میچر اعلانات ڈھونڈتا ہے، کوئی کال نہیں پاتا، اور ایسے پیٹرن کے لیے “کوئی میچ نہیں” بتا دیتا ہے جسے پڑھا ہی اُس نظر سے نہیں جا رہا تھا جیسا وہ دکھتا ہے۔

اس لیے پیٹرن کو سکیفولڈز کی ایک سیڑھی میں آزمایا جاتا ہے — سٹیٹمنٹ، ایکسپریشن، کلاس ممبر، ٹاپ لیول — اور جو پہلا اسے قبول کر لے، وہی جیت جاتا ہے۔ جس ٹکڑے کو کوئی سیاق قبول نہ کرے، اُسے خاموشی سے نہ پائے جانے کے بجائے ناقابلِ پارس بتا دیا جاتا ہے۔

ری رائٹ لکھنے کے بجائے اسٹیج کیوں کرتا ہے

ساختی ری رائٹ ایجنٹ کی سب سے وسیع ترمیم ہوتی ہے: ایک پیٹرن، چالیس فائلیں، اور نتیجہ کوئی لائن بہ لائن نہیں پڑھتا — نہ ماڈل، اور نہ وہ شخص جس نے یہ کام مانگا۔ اسے لکھ کر “ہو گیا” بتا دینے کا مطلب یہ ہے کہ تبدیلی پر پہلی ایماندار نظر بعد میں git diff کے ذریعے ڈالی جائے گی۔

چنانچہ ast_edit بتاتا ہے کہ وہ کیا کرے گا — گنتی، فائلیں، ملنے والی جگہیں — اور تبدیلی صرف اُس وقت پڑتی ہے جب resolve اسے کمٹ کرتا ہے۔ یہی بات کسی چیز کے ڈسک تک پہنچنے سے پہلے ایک Diff اور قبول/مسترد کا فیصلہ انسان کے سامنے رکھنے دیتی ہے۔

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

ڈی بگر ایسا کیا جواب دیتا ہے جو پرنٹ سٹیٹمنٹ نہیں دے سکتا

پرنٹ سٹیٹمنٹ کا چکر یہ ہے: ایک پرنٹ ڈالیں، پوری چیز دوبارہ چلائیں، آؤٹ پٹ پڑھیں، پرنٹ ہٹا دیں۔ اس میں ہر سوال پر پورا ٹیسٹ رَن خرچ ہوتا ہے، اور یہ صرف اُسی سوال کا جواب دیتا ہے جو چلانے سے پہلے آپ کو سوچنے میں آیا تھا۔

رکا ہوا فریم اُس لمحے کے ہر سوال کا جواب ایک ہی بار میں دے دیتا ہے — ہر لوکل، ہر کالر، اور فریم کے اپنے اسکوپ میں جانچا گیا ایکسپریشن۔ پھنسے ہوئے پروسیس یا ایسی ناکامی کے لیے جو دس رَن میں ایک بار دہرائی جائے، یہی فرق ایک پوری سہ پہر اور ایک منٹ کا ہے۔

انکلوژر کی طرح محدود، اور اسی وجہ سے

ڈی بگ اڈاپٹر ایک رکے ہوئے پروسیس کا مالک ہوتا ہے، اور وہ سب تھامے ہوتا ہے جو وہ پروسیس تھامے ہوتا ہے — کوئی پورٹ، کوئی لاک، کوئی ڈیٹا بیس کنکشن۔ جس سیشن کو کوئی چلا نہ رہا ہو، وہ ایسا رساؤ ہے جو اُس باری سے بھی آگے چلتا ہے جس نے اسے شروع کیا تھا۔ اس لیے ایک سخت TTL ہے، ہر گفتگو میں بالکل ایک سیشن، اور دوسری launch کو خاموشی سے پہلی کی جگہ لینے کے بجائے مسترد کر دیا جاتا ہے: جو ایجنٹ پہلا ختم کیے بغیر دوسرا شروع کرتا ہے، وہ تقریباً یقینی طور پر پہلے کا سراغ کھو چکا ہوتا ہے۔

ایک ٹرانسپورٹ، دو پروٹوکول

Debug Adapter Protocol، Language Server Protocol کی Content-Length فریمنگ استعمال کرتا ہے اور اس کے اوپر کچھ مشترک نہیں — الگ کوریلیشن کیز، ناکامی کی الگ شکل، اور پیغام کی ایک تیسری قسم (ایونٹس) جس کا LSP میں کوئی متبادل نہیں۔ فریمنگ ایک ہی جگہ رہتی ہے؛ پروٹوکول اس کے اوپر الگ الگ بیٹھتے ہیں۔

فریمنگ دو بار لکھنے کا مطلب ہوگا “ایک پیغام دو چنکس پر پھیلا ہے”، “ایک چنک میں تین پیغام ہیں” اور “سرور نے اپنے پہلے فریم سے پہلے stdout پر بینر لکھا” کے دو دو جواب، اور درستی صرف ایک کو ملتی۔