پس منظر کے ورکرز کی ہدایت

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

جب آپ /vibe ٹائپ کرتے ہیں تو کیا بدلتا ہے

دو چیزیں، اور مشینری صرف پہلی کو نافذ کرتی ہے:

1. سیشن کے اپنے ٹولز صرف پڑھنے کے لیے رہ جاتے ہیں، اور ساتھ پانچ ورکر افعال آ جاتے ہیں۔ ریپو پر اثر ڈالنے کا واحد راستہ ورکر ہے، اور یہ جاننے کا واحد طریقہ کہ کیا ہوا، ورکر کے چھوئے گئے فائلوں کو پڑھنا ہے۔
2. اسے کہا جاتا ہے کہ وہ ماننے کے بجائے پڑھ کر تصدیق کرے۔ ورکر کی رپورٹ اس کے اپنے کیے کا دعویٰ ہے، اس بات کا ثبوت نہیں کہ کام واقعی ہوا۔

پہلی بات بنیادی ہے۔ ایسا ہدایت کار جو اب بھی grep اور edit کر سکتا ہو، دباؤ میں کام خود کرنے لگتا ہے — اور یہی وہ ناکامی ہے جسے روکنے کے لیے یہ نظام موجود ہے۔

/vibe migrate the auth module to the new session API

ورکرز خالی شروع ہوتے ہیں

ورکر نے آپ کی گفتگو کبھی نہیں دیکھی اور نہ کبھی دیکھے گا۔ بریف ہی اس کا پورا سیاق و سباق ہے۔

یہی چیز اس طرز کو سستا رکھتی ہے — بیس ورکرز، جن میں سے ہر ایک ہدایت کار کی تاریخ رکھتا ہو، ہدایت کار کے سیاق و سباق سے بیس گنا مہنگے پڑیں گے — اور یہی وہ واحد چیز ہے جو بریف لکھنا مشکل بناتی ہے۔ «اب دوسرا بھی کر دو» ہدایت کار کے لیے مکمل ہدایت معلوم ہوتی ہے، مگر ایک نئے سیشن کے لیے بالکل بےمعنی۔

اچھا بریف فائلوں اور کمانڈز کا نام لیتا ہے، اور بتاتا ہے کہ کام مکمل کب مانا جائے گا:

lib/features/auth/ میں، SessionStore.read(key) کی ہر کال کو SessionStore.get(key) سے بدل دیں۔ نیا میتھڈ Future<String?> واپس کرتا ہے جبکہ پرانا String? واپس کرتا تھا، اس لیے کال کرنے والوں کو await درکار ہوگا۔ کام ختم ہونے پر fvm flutter analyze lib/features/auth چلائیں اور جو غلطیاں آپ ٹھیک نہ کر سکیں اُن کی رپورٹ دیں۔

پانچ افعال

فعل	یہ کیا کرتا ہے
vibe_spawn	ایک بریف پر ورکر شروع کرتا ہے۔ فوراً واپس آ جاتا ہے۔
vibe_list	ہر ایک کا درجہ، حیثیت، گزرا ہوا وقت اور آخری نتیجہ
vibe_send	ایسے ورکر کے لیے فالو اَپ باری جس نے اپنی باری مکمل کر لی ہو
vibe_wait	جب تک کوئی ایک ورکر اپنا کام ختم نہ کر دے، رکتا ہے
vibe_kill	کسی ایک کو روک دیتا ہے

ورکر شروع کرنے کا ڈیزائن ہی یہ ہے کہ وہ فوراً واپس آ جائے اور اپنے مکمل ہونے کا انتظار نہ کرائے۔ ایک ہدایت کار جو ہر بار ورکر شروع کرتے وقت رک جائے، وہ ورکرز کو ایک ایک کر کے چلا رہا ہوتا ہے، جو کہ وہی کام خود کرنے کا ایک سست طریقہ ہے۔ vibe_wait صرف اُس وقت استعمال کریں جب کسی مخصوص جواب کے بغیر واقعی آگے نہ بڑھ سکتے ہوں۔

دو درجے

درجہ	کس لیے
fast	واضح تفصیل والا مکینیکل کام — ترمیمات، نام کی تبدیلیاں، مسودے، کمانڈز چلانا
good	ڈیزائن، فیصلہ سازی، یا یہ جانچنا کہ fast ورکر نے کیا بنایا

عام انداز یہ ہے کہ fast ورکرز کو الگ الگ فائلوں پر پھیلا دیا جائے، پھر ایک good ورکر لگایا جائے جو ان کے مجموعی کام کا جائزہ لے۔

تصدیق کرنا

یہی وہ حصہ ہے جو طے کرتا ہے کہ اس طرز کی کوئی قیمت ہے یا نہیں۔

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

پھر اُن فائلوں کو پڑھیں جن کا اس نے نام لیا۔ ہدایت کار کے پاس read، search، lsp اور ast_grep موجود ہیں؛ اِنہیں رکھنے کا پورا مقصد یہی ہے۔ جو ہدایت کار رپورٹ کو من و عن مان لے، وہ محض دوسرے ایجنٹس کی اُمید پرستی کا خلاصہ نگار ہے۔

ورکرز کے ایک دور کے بعد lsp(action: "diagnostics", file: "*") عام طور پر سب سے تیز واحد جانچ ہوتی ہے۔

جب کوئی ورکر بھٹک جائے

اسے روک دیں اور نیا بریف دیں۔ تازہ، درست شدہ بریف بحث سے سستا پڑتا ہے، اور vibe_send صرف ایسے ورکر پر کام کرتا ہے جس نے اپنی باری پہلے ہی مکمل کر لی ہو۔

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

حدود

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

اسے کب استعمال نہ کریں

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

متعلقہ

• ایجنٹس متوازی چلائیں — پھیلانے کے دیگر طریقے
• آرکیسٹریشن — جب کام کی کوئی ساخت ہو
• بلٹ اِن ایجنٹ ٹولز — افعال اور اُن کے آرگیومنٹس