لیپ ٹاپ سے آگے: رن ٹائم کا فوری کورس

12 تصورات · ایسے لوپ سے جو ڈھکن بند ہوتے ہی رک جاتا ہے، اپنے گھر والے کارکن تک

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

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

شروع کرنے سے پہلے ایک وعدہ۔ یہ کورس آپ کو DevOps انجینئر نہیں بناتا۔ ہر منتقلی وہی چیزیں استعمال کرتی ہے جو پہلے سے آپ کے پاس ہیں: ایجنٹک کوڈنگ کورس کی ترتیباتی فائلیں، evals کورس کی headless کمانڈز، لوپ کورس کے شیڈول، اور منتقلی کے کام کرنے کا ثبوت دینے والا مجموعہ۔ صرف ایک واقعی نئی چیز، یعنی ایسا رن ٹائم جسے کوئی اور آپ کے لیے چلاتا ہے، پوری دیانت سے متعارف ہوتی ہے: قیمت اور سمجھوتے صاف سامنے۔

پہلے یہ درکار ہے: جانچنے والے پر اعتماد۔ اس کورس نے آپ کو eval suite دی، اور یہ کورس اس پر بہت انحصار کرتا ہے: نئے رن ٹائم کی منتقلی بالکل وہ تبدیلی ہے جس پر اعتماد سے پہلے پورا مجموعہ دوبارہ چلنا چاہیے۔ یہ Stage 3 کی پوری trilogy فرض کرتا ہے: Loop Engineering (beats، spine، human gate)، Harness Engineering (پانچ verbs، ratchet)، اور evals course (golden set، baselines، drift)۔ اگر یہ الفاظ نئے ہیں تو پہلے وہ کورسز کریں۔ یہ کورس ان کی بنائی مشینری منتقل کرتا ہے۔

یہاں نئے ہیں؟ پہلے سے درکار علم کا 2 منٹ کا خلاصہ

• بیٹ: شیڈول شدہ لوپ کی ایک مکمل run۔ صبح کا triage loop ہر weekday ایک beat چلاتا ہے۔
• ہارنس: وہ تہہ جو طے کرتی ہے کہ ایجنٹ کیا کر سکتا ہے، اسے کیا معلوم ہونا چاہیے، کام کیسے ثابت ہوگا، اور خرابی پر کیا ہوگا۔
• گولڈن سیٹ: حقیقی پکڑی گئی failures سے بنا eval cases کا folder، جو ہر تبدیلی پر دوبارہ چلتا ہے۔
• بیس لائن: درج شدہ pass rate جس سے نئی runs کا موازنہ ہوتا ہے۔ Baseline سے کمی alarm ہے۔
• ڈرفٹ: آپ کی تبدیلی کے بغیر رویہ بدلنا، عموما نیچے موجود model کے update ہونے سے۔
• انسانی دروازہ: risky یا failed work انسان کے پاس جاتا ہے۔ کوئی unattended کام main تک نہیں پہنچتا۔
• ہیڈ لیس موڈ: ایجنٹ کو interactive session کے بغیر چلانا (claude -p Claude Code میں، opencode run OpenCode میں)، تاکہ script یا schedule اسے چلا سکے۔

اگر ان میں سے کوئی بات نئی ہے تو پہلے Stage 3 کے تین کورسز پڑھیں۔ یہ کورس ان کی بنائی اور ثابت کی ہوئی مشینری کو نئی جگہ دیتا ہے۔

آسان زبان میں کلیدی الفاظ

اصطلاح	آسان مطلب
رن ٹائم	computer اور ایجنٹ کے گرد software جو اسے حقیقت میں چلاتا ہے: شروع کرتا، input دیتا، اور crash پر restart کرتا ہے۔
گھر	رن ٹائم کے انتخاب کے لیے اس کورس کا لفظ: آپ کا session، cloud schedule، managed runtime، یا آپ کا اپنا process۔
کنٹرول پلین	رن ٹائم کا حصہ جو agent loop چلاتا ہے: sessions، scheduling، event streams، restarts۔
عملی پلین	جہاں کام اترتا ہے: tools کا sandbox اور ان کا چھوا data۔ دونوں planes کے مالکان الگ ہو سکتے ہیں۔
تحویل	Data کس کے پاس اور کس کے control میں ہے: کن machines پر رہتا اور کون اس تک پہنچ سکتا ہے۔
ہیڈ لیس	ایجنٹ کو interactive session کے بغیر command سے چلانا۔ ہر منتقلی کا پل۔
شیڈول	آپ کے بغیر مقرر وقت پر loop شروع کرنے والی چیز: Claude Code Routine، Cowork Scheduled Task، یا scheduled GitHub Actions job۔
منظم رن ٹائم	ایسی service جہاں آپ agent definition بھیجتے ہیں اور vendor control plane چلاتا ہے؛ default میں sandbox بھی، مگر لازمی نہیں۔
ایجنٹ کی تعریف	ایجنٹ کو چلائے بغیر بیان کرنے والی ہر چیز: model، system prompt، tools، rules، guardrails۔
سیشن (hosted)	Managed runtime کے اندر ایک جاری کام، اپنے محفوظ state اور event log کے ساتھ۔
سینڈ باکس	بند environment جہاں agent کے actions چلتے ہیں۔ کچھ homes میں model کے پاس، کچھ میں الگ۔
منتقلی کی صلاحیت	نئے home میں منتقل ہونے پر بغیر دوبارہ بنائے system کا کتنا حصہ بچتا ہے۔
لاک اِن	Home چھوڑنے کی قیمت، ان تمام چیزوں میں جو دوبارہ بنانی پڑیں۔ کم portability، زیادہ lock-in۔
اثر کا دائرہ	کسی home کی بری رات کہاں تک پہنچ سکتی ہے۔ Harness course کا budgeting question، runtimes کے لیے۔
پیجر	رات کو system خراب ہونے پر engineer کو جگانے والی alarm۔ Pager اٹھانے کا مطلب ذمہ داری لینا ہے۔
نئی بیس لائن	New home کے existing acceptance bars pass کرنے کے بعد runtime-specific pass rate درج کرنا، old baseline کو موازنے اور تاریخ کے لیے محفوظ رکھتے ہوئے۔
آزمائشی مدت	Trial period: مکمل اعتماد سے پہلے new home کو قریب سے دیکھا جاتا اور old home دستیاب رہتا ہے۔

یہ کہاں سے آیا

صنعت کی زیادہ تر تاریخ میں deployment ڈویلپر کا لفظ تھا: کوڈ لکھا، پھر servers پر بھیجا۔ 2025 اور 2026 میں یہ بدلا کہ آپریٹرز، یعنی وہ لوگ جنہوں نے ایجنٹ نہیں لکھا بلکہ صرف configure اور prove کیا، اچانک کچھ deploy کرنے کے قابل ہو گئے۔ Measured track record والا configured loop ایک اثاثہ ہے، اور صرف laptop کھلا ہونے پر موجود اثاثہ بری طرح محفوظ ہے۔ Vendors نے یہ دیکھا۔ Anthropic نے consumer tools کے لیے cloud execution، پھر agent definitions کے لیے hosted runtime جاری کیا۔ Open-source طرف نے کم قیمت متبادل کے لیے CI schedulers اپنائے۔ نتیجہ یہ ہے کہ runtime decision، جو پہلے project کے آخر میں صرف engineers کو درپیش تھا، اب بہت پہلے آتا اور ان لوگوں تک پہنچتا ہے جو کبھی server نہیں لکھیں گے۔ یہ کورس ان کے لیے ہے۔ (Sources آخر میں ہیں۔)

ایک تصویر میں ذہنی تبدیلی

یہ کورس دو tools ساتھ سکھاتا ہے، جیسے پوری trilogy نے کیا۔ Judgment، یعنی کون سا home، move کب اور proof کیسے، دونوں میں ایک ہے۔ Mechanics پہلے کسی course سے زیادہ مختلف ہیں، اور course وجہ صاف بتاتا ہے: ایک tool کا vendor اس کے لیے cloud چلاتا ہے، دوسرے tool کا vendor آپ ہیں۔ یہ فرق footnote نہیں؛ runtime decision اسی کے بارے میں بھی ہے۔

caution

یہ بات جولائی 2026 کے وسط میں درست ہے۔ اس course کی mechanical layer کی ہر چیز، product names، endpoints، prices اور flags، section کے کسی اور course سے تیزی سے بدلتی ہے۔ Move سے پہلے claude update یا opencode upgrade چلائیں، اور کسی name یا number پر اعتماد سے پہلے live docs (code.claude.com/docs، docs.claude.com، opencode.ai/docs) دیکھیں۔

اس کورس میں کیا ہے

حصہ	موضوع	آپ کیا سیکھیں گے
1	آخری dependency	Laptop پر proven loop برا محفوظ اثاثہ کیوں، اور ہر option sort کرنے والا سوال
2	Headless پل ہے	ہر home کی مشترک invocation اور پہلی move: cloud schedule
3	Managed runtime	Agent definitions، environments، sessions: کیا دیتے، کیا ملتا، cost کیا
4	Move خود	کیا travel، کیا دوبارہ بنتا، اور new home میں track record دوبارہ کیوں
5	Home کا انتخاب	چار سوال، homes کو جان بوجھ کر mix کرنا، مکمل end-to-end move
6	دیانت برقرار رکھنا	Lock-in، ownership drift، جو کوئی home fix نہیں کر سکتا، Mode 2 کا bridge
Live	Dogfooding	اس book کے loops کہاں رہتے اور کیوں
Practice	Projects	آسان سے مشکل آٹھ moves

کر کے سیکھنا چاہتے ہیں؟ مکمل move دیکھنے کے لیے پہلے Part 5 پڑھیں، پھر واپس آئیں۔

اس کورس کو پڑھنے کے دو طریقے

پہلی بار؟ Parts 1 سے 5 ترتیب سے، "Going deeper" والی ہر note چھوڑ کر۔ تقریبا نوے منٹ۔ پھر Projects 1 سے 3 کریں، جن میں زیادہ وقت ہے۔ ان کے بعد loop ایسے schedule پر ہوگا جسے laptop نہیں چاہیے، اور آپ number سے کہہ سکیں گے کہ وہ اب بھی کام کرتا ہے۔

دوسری بار، unattended راتوں کے پہلے مہینے کے بعد: Part 6 مکمل، deeper notes اور Projects 4 سے 8۔ Lock-in تب پورا سمجھ آتا ہے جب دوبارہ بنانے والی کوئی قیمتی چیز ہو۔

انگریزی دوسری زبان کے طور پر پڑھ رہے ہیں؟ Course کی ہر picture-word کا آسان version قریب ہے۔ "In simple terms" boxes اور اوپر کی glossary وہی مطلب چھوٹے سیدھے جملوں میں دیتے ہیں۔ سجاؤٹی جملے کے پاس box یہی بات سادہ کہتا ہے۔

کیا یاد رکھنا اور کیا دیکھنا ہے

دو layers، مختلف رفتار سے پرانی ہوتی ہوئی۔ پہلی یاد رکھیں۔ دوسری دیکھ کر لیں۔

• دیرپا تہہ۔ Loop کون چلاتا اور work کہاں execute ہوتا ہے، اصل سوال یہی؛ باقی detail۔ Headless ہر move کا bridge۔ Discipline travel، mechanics rebuild، trust re-measure۔ چار سوال home چنتے ہیں۔ Blast radius move کا وقت۔ ہر home human gate رکھتا ہے۔
• Mechanical تہہ۔ نیچے کا ہر product name، endpoint، price اور flag۔ Managed-runtime APIs course لکھتے وقت چند ہفتے پرانی ہیں۔ ہر detail کو یاد کرنے کا fact نہیں، live docs کی pointer سمجھیں۔

---

📚 تدریسی مدد

مکمل سلائیڈ شو کھولیں

مکمل پریزنٹیشن دیکھیں: لیپ ٹاپ سے آگے: رن ٹائم کا فوری کورس

---

حصہ 1: آخری dependency

1. لیپ ٹاپ پر ثابت شدہ لوپ بری طرح محفوظ اثاثہ ہے

تین courses میں بنائی چیزیں گنیں۔ ایک loop جو آپ کے بیٹھنے سے پہلے morning queue کو triage کرتا ہے۔ ایک harness جو خطرناک غلطیاں ناممکن بناتا اور ہر پکڑی failure کو permanent rule بناتا ہے۔ ایک eval suite جو درمیان کے reviewer کو defended number دیتی ہے۔ سیدھا کہیں: written job description، supervisor، اور performance record والا junior colleague۔

اب dependencies گنیں۔ Laptop کھلا ہو۔ Session logged in ہو۔ Machine صبح 9 بجے awake، power، network پر ہو۔ ایک بھی miss ہو تو beat خاموشی سے نہیں چلتی، اور loop course نے skipped beat کی cost سکھائی: queue بڑھتی، escalations جمع ہوتیں، Monday والا آپ Friday کے بند lid کی قیمت دیتا ہے۔

اسے زیادہ صاف کہیں۔ Trilogy نے single points of failure ایک ایک کر کے ہٹائے: maker-checker split نے single unreviewed opinion، harness نے single unguarded action، evals نے single unchecked checker ہٹایا۔ ایک باقی ہے، اور وہ آپ ہیں: human gate کے پاس درست رہنے والی judgment نہیں، آپ کا hardware۔ System اپنی machine سے زیادہ reliable ہے۔ یہی signal ہے کہ وہ home سے بڑا ہو گیا۔

آسان زبان میں

آپ نے اچھا worker train کیا، پھر شرط لگائی کہ وہ صرف آپ کے living room میں، صرف آپ کی موجودگی میں کام کرے۔ Worker ٹھیک ہے، arrangement مسئلہ ہے۔

2. ایک سوال ہر option sort کرتا ہے: loop کون چلاتا، work کہاں execute ہوتا ہے؟

نیا home ڈھونڈتے ہی options بڑھتے اور vocabulary شور کرتی ہے: cloud sessions، hosted agents، managed runtimes، SDKs، serverless یہ، orchestrated وہ۔ سب کو ایک سوال سے کاٹ دیں۔ اس کے دو حصے ہیں: agent loop کون چلاتا ہے، اور اس کا work کہاں execute ہوتا ہے؟

دونوں حصوں کے نام اب سیکھنا مفید ہے، کیونکہ modern runtimes انہیں split کر سکتے ہیں۔ Control plane loop خود ہے: sessions شروع کرتا، model کو input دیتا، events stream کرتا اور 3am پر crash restart کرتا ہے۔ Execution plane وہاں ہے جہاں actions اترتے ہیں: tools کا sandbox اور ان کا چھوا data۔ Laptop پر دونوں planes ایک machine تھے، اس لیے فرق ضروری نہ تھا۔ آگے کے homes انہیں الگ کر سکتے ہیں، اور سب سے دلچسپ home جان بوجھ کر کرتا ہے۔

ہر option ان دو حصوں سے ترتیب پانے والے چار homes میں سے ہے:

• گھر 1: آپ کا session۔ Config، runtime، uptime سب آپ کا۔ Trilogy یہاں ہوئی، building اور proof کے لیے درست home۔ Depend کرنے کے لیے غلط۔
• گھر 2: cloud schedule۔ Config اب بھی آپ کی، وہی rules file، skills، subagents، مگر clock کسی اور کے computer پر۔ Claude Code Routine loop کو Anthropic cloud پر، scheduled GitHub Actions job OpenCode loop کو GitHub runners پر چلاتی ہے۔ سب سے چھوٹی move، سب سے بڑا فوری فائدہ۔
• گھر 3: managed runtime۔ آپ agent definition (model، prompt، tools، guardrails) دیتے، vendor service control plane (loop، sessions، crash recovery) چلاتی ہے۔ Execution plane choice: default vendor cloud sandbox، یا custody پر آپ کی controlled infrastructure کا sandbox۔ Loop وہ، گرد کا business آپ۔
• گھر 4: آپ کا process۔ Harness آپ کے software کی library اور servers کا حصہ۔ سب آپ کا، پوری responsibility۔ Agent SDK اور Mode 2؛ course دروازہ دکھاتا، پار نہیں کرتا۔

دونوں planes کو سیدھا دیکھیں۔ Home 3 اصل میں دو ہے، اس لیے پانچ rows:

گھر	کنٹرول پلین	عملی پلین	خرابی پر کون جاگتا ہے
1 · آپ کا session	آپ	آپ کا laptop	آپ
2 · Cloud schedule	آپ، scheduler کے ذریعے	Cloud runner	مشترک
3 · Managed، cloud sandbox	Vendor	Vendor	Infrastructure ان کی، outcomes آپ کے
3 · Managed، self-hosted sandbox	Vendor	آپ	Plane کے مطابق تقسیم
4 · آپ کا process	آپ	آپ	جان بوجھ کر آپ

دیکھیں سوال technical نہیں۔ ہر business ہر function پر یہی پوچھتا ہے: خود کریں یا کسی کو پیسے دیں؟ آپ یہ سوچ پہلے جانتے ہیں۔ باقی course اسی سوچ کو agent کے نیچے computer پر لگاتا ہے۔

آسان زبان میں

چار homes میں انتخاب ہے، سیڑھی نہیں: laptop (سب own)، schedule (config own)، managed runtime (definition own، sandbox ان کے cloud یا custody کے لیے آپ کی infrastructure پر)، یا اپنے servers (product scale پر جان بوجھ کر سب پھر own)۔ Rule: صرف وہ own کریں جو لازم ہے، جو چاہیں وہ نہیں۔ زیادہ readers پہلے تین میں رہتے اور اکثر ہر loop کا الگ home ساتھ چلاتے ہیں۔ چوتھا home Mode 2 شروع کرتا ہے۔

خود جانچیں

لاہور میں عائشہ freelance invoicing loop laptop پر چلاتی ہیں۔ Load-shedding زیادہ شاموں power کاٹتی ہے، اور نیا client روز local time 6pm پر invoice بغیر fail چاہتا ہے۔ انہیں پہلے کون سا home چاہیے، اور home 3 آج ضرورت سے زیادہ کیوں؟

جواب دیکھیں

درست جواب Home 2، یعنی cloud schedule ہے۔ مسئلہ صرف clock: loop proven، config کام کرتی، machine 6pm promise نہیں کر سکتی۔ Cloud runner power cut critical path سے ہٹاتا، صرف new home دوبارہ prove کرنا ہے۔ Client کے "without fail" پر honesty note: CI سمیت schedulers تقریبا وقت promise کرتے، ٹھیک وقت نہیں؛ load میں delay اور کبھی drop۔ اس لیے یہ feature نہیں، Part 2 کی kit ہے: missed-run detector، duplicate invoice نہ بھیجنے والی retry، اور 6:30 تک success نہ ہو تو alarm۔ Home 3 دوسرے users، long jobs session state اور scale operations جیسے موجود نہ مسائل حل اور charge کرتا ہے۔ Part 5 پوچھے گا: user کون؟ آج عائشہ۔ Home 2 + kit کافی۔

---

حصہ 2: ہیڈ لیس ہی پل ہے

3. ہر گھر ہیڈ لیس سمجھتا ہے

اس کورس کی ہر منتقلی ممکن بنانے والی خاموش بات یہ ہے: evals course میں آپ یہ بتائے بغیر پل پار کر چکے کہ وہ پل تھا۔ Eval runner نے claude -p اور opencode run سے agent کو گفتگو نہیں، command کی طرح call کیا۔ کھلی window نہیں، سنبھالنے کو session نہیں: prompt اندر، کام، output باہر، process بند۔

یہی headless mode ہے، اور پورا course اسی خیال پر کھڑا ہے۔ جو چیز command چلا سکتی ہے، وہ آپ کا agent چلا سکتی ہے۔ Shell script، cron job، CI runner، cloud scheduler، سب۔ Home 2 سے آگے ہر home اندر سے اس سوال کا الگ جواب ہے: headless command کس کا computer، کس کی clock پر؟

اس evals course کی mechanics بغیر بدلے ساتھ آتی ہیں: Claude Code میں machine-readable output کے لیے --output-format json، OpenCode میں JSON event stream، اور reviewer کا verdict file میں تاکہ کوئی prose parse نہ کرے۔ اب انسان نہ دیکھے تو ایک عادت جوڑیں: headless run failure پر واضح alarm دے۔ Session میں error دکھتی ہے۔ Runner پر unchecked exit code خاموشی سے miss ہوئی beat ہے، Concept 1 کی failure cloud میں دوبارہ۔ ہر wrapper exit code check اور failure پر loud ہوتا ہے۔ خاموشی success ہونی چاہیے؛ یہ rule آپ لگاتے ہیں، default نہیں۔

آسان زبان میں

اس میں Interactive mode کا مطلب ہے کہ آپ agent سے بات کرتے ہیں۔ Headless mode میں script، schedule یا server agent کو note دے کر result لیتا ہے۔ Agent note لے سکے تو جہاں note پہنچے، وہاں کام کر سکتا ہے۔

4. گھر 2، کلاؤڈ شیڈول: پہلے گھڑی باہر جاتی ہے

پہلی move جان بوجھ کر سب سے چھوٹی ہے: بنایا سب رکھیں، صرف clock منتقل کریں۔ Config، یعنی rules file، skills، subagents، hooks، وہی۔ صرف beat شروع کرنے والا بدلتا ہے۔

یہ Vendor کا راستہ وہی schedule ہے جس کا loop course نے وعدہ کیا، نام بھی وہی: Routine۔ Claude Code میں /schedule command، جس کا alias /routines ہے، گفتگو سے بناتی ہے۔ Configuration میں prompt، repositories، connectors، environment محفوظ ہوتے ہیں۔ Laptop کھلا ہو یا نہیں، Anthropic-managed cloud infrastructure پر چلتی ہے۔ Repo-attached loop، "ہر weekday 9am پر morning triage skill چلائیں، medium risk سے اوپر escalate کریں،" یہی بن جاتا ہے۔

موجودہ docs سے تین honesty notes:

• Routines research preview میں ہیں۔ سب سے mechanical layer، انحصار سے پہلے verify کریں۔
• Scheduled run گھنٹے سے چند minutes بعد شروع ہو سکتی ہے، docs اسے stagger کہتی ہیں۔ اصل وعدہ "تقریبا 9am" ہے۔
• Green status صرف infrastructure error کے بغیر session exit ہے۔ Task success نہیں۔ Loud-failure rule prompt اور checks میں آپ کا ہے۔

ایک trap کا نام friendly ہے۔ Desktop app میں Local چننے سے آپ کی machine پر Desktop scheduled task بنتی ہے۔ Timer والا home 1، move نہیں۔

Claude Cowork میں knowledge work کے لیے یہی Scheduled Task ہے۔ ایک بار describe کریں، connectors، skills، plugins کے ساتھ remotely چلے گی۔ Caveat: local files یا desktop applications مانگنے والی task locally چلتی اور laptop پھر لازم۔ Loop کیا چھوتا ہے: repository work کے لیے Claude Code Routine، connector/document کے لیے Cowork Scheduled Task۔ دونوں میں laptop صرف results پڑھنے کی جگہ۔

دو mechanical honesty notes۔ Cloud runner آپ کی machine نہیں۔ Repos، connectors، credentials کی رسائی configure ہوتی، inherit نہیں؛ پہلی Routine run نئی reach کی discovery بھی۔ Harness configured شکل میں travel کرتا، مگر verify کریں۔ Permission walls اور hooks files ہیں، صرف انہیں load کرنے والی runs کو بچاتی ہیں۔ Live docs سے config sourcing دیکھیں اور Concept 8 probation لازم رکھیں۔

ریپو سے جڑے Repository loops کے لیے vendor-neutral home 2 بھی ہے: schedule: trigger والا GitHub Actions workflow۔ Repo config checkout، CI runner پر claude -p headlessly۔ GitHub کا note: scheduled workflows best-effort، load میں late، کبھی drop، صرف default branch۔ Morning loop کا contract تقریبا 9am۔ Hard deadline کو نیچے کی kit اور شاید مضبوط scheduler چاہیے۔

اس طرف OpenCode کا first-party hosted control plane نہیں، اور course دکھاوا نہیں کرتا۔ OpenCode میں home 2 وہ scheduler ہے جو آپ چنتے ہیں۔ Repo loops کے لیے opencode run کو schedule: trigger پر چلائیں اور .opencode/ config checkout کریں۔ باقی کے لیے cron چلانے والی machine: سستا cloud server، گھر کا always-on computer، یا scheduled runner۔

آپ کو tool کا وعدہ ملتا ہے: آپ اور loop کے بیچ vendor نہیں، model اور provider آپ کی پسند۔ آپ مانتے ہیں کہ vendor اب آپ ہیں: runner uptime، credentials، updates آپ سنبھالیں۔ Actions پر burden چھوٹا، desk کے نیچے computer پر زیادہ کام سے home 1 دوبارہ۔ اس لیے Actions default recommendation ہے۔

ان Tabs کا فرق lesson ہے، defect نہیں: open tool پورا runtime decision آپ کو دیتا ہے۔ یہی trade Personal Agent Harnesses میں پھر ملے گا، جہاں runtime own کرنا ہی point ہے۔

جو version چنیں، success کی definition ایک اور measurable: laptop بند رہنے پر کم از کم ایک مکمل operating cycle اور دس successful beats، خاموشی baseline کے معنی میں۔ Cloud سے ایک بار چلنا کافی نہیں، long-term uptime کا proof بھی نہیں؛ initial operational evidence کہیں، risk کے مطابق بڑھائیں۔ Scheduled beats baseline سے checked، alarm ایک بار جان بوجھ کر tested۔ یہی home 2 میں move ہے۔

کم از کم unattended kit۔ Course نے DevOps engineer نہ بنانے کا وعدہ ایک discipline کی جگہ table سے نبھایا۔ انسان نہ دیکھے تو چھ controls optional نہیں۔ ہر ایک چھوٹا، کمی کے پیچھے مشہور failure۔

کنٹرول	قاعدہ	روکی جانے والی خرابی
Idempotency	Retried beat کو دہرانا safe ہو	Invoice یا ticket دو بار
Missed-run detection	دوسرا system دیکھے کہ پہلا شروع نہیں ہوا	نہ چلی process اپنی absence report نہیں کرتی
Concurrency lock	ایک وقت ایک beat، 8am زندہ ہو تو 9am wait	ایک queue کی files پر دو agents
Credential discipline	Scoped service credentials، least privilege، rotation، personal login کبھی نہیں	Cloud runner کے پاس پوری identity
Time semantics	Timezone لکھی، daylight-saving اور catch-up پہلے طے	6pm invoice سال میں دو بار ایک گھنٹہ move
Cost and execution limits	ہر beat کی max duration، turns، retries، spend، termination behavior	بھٹکتی run رات میں مہینے کا budget خرچ کرے

یہ Kit home 2 کی entrance fee ہے اور travel کرتی ہے۔ ہر بعد کا home یہی چھ controls مانگتا ہے، کبھی scripts کی جگہ service settings۔ Part 5 میں minimum safety gate یہی table ہے۔

آسان زبان میں

پہلی move سب سے چھوٹی: setup وہی، صرف loop شروع کرنے والی چیز بدلیں۔ Laptop کی جگہ cloud schedule clock پر شروع کرتا ہے۔ اب کوئی نہیں دیکھ رہا، اس لیے چھ safety rules جوڑیں تاکہ failure خاموش نہ ہو۔

گہرائی میں: شیڈول منتقل ہوا، انسانی دروازہ نہیں

اس Move میں subtle trap ہے۔ Laptop پر human gate کی سہولت یہ تھی کہ آپ وہاں تھے۔ Escalation دیکھی window میں آتی۔ Home 2 میں screen کے پاس ہوں یا نہیں، loop چلتا ہے۔ Unseen escalations جمع اور delayed decision بن سکتی ہیں۔ اس لیے escalation channel desk نہیں، آپ تک آئے: message، mention، یا آپ کے نام کا issue۔ Loop course کا get loud وہاں point ہو جہاں آپ واقعی رہتے ہیں۔ Gate move نہیں ہوا؛ doorbell کو ہونا پڑا۔

خود جانچیں

پہلی cloud-scheduled beat green ہے۔ Teammate کہتا ہے migration done۔ Evals کی ایک run والی سیکھ اور خاموشی سے بتائیں: done سے پہلے کون سی دو چیزیں missing؟

جواب دیکھیں

پہلا: ایک green beat ایک run کا fact، home کا نہیں۔ Migration rate سے prove، اس لیے bar پہلی رات نہیں، baseline کے خلاف full operating cycle اور دس beats۔ دوسرا: loud failure test نہیں۔ Deliberate failure plant اور alarm اپنے تک آتے دیکھے بغیر خاموشی baseline بھی ہو سکتی، runner شروع نہ ہونے کی بھی۔ Done: ایک ہفتہ green، alarm tested، escalations واقعی دیکھی جگہ۔

---

حصہ 3: منظم رن ٹائم

5. گھر 3: آپ تعریف بھیجتے ہیں، خدمت کارکن چلاتی ہے

اس Home 2 نے clock move کی۔ Home 3 control plane کو move کرتا، اور execution plane کو بھی، مگر صرف آپ کے انتخاب پر۔ Managed runtime سادہ مگر بنیادی contract والی service ہے: آپ agent کو model، system prompt، tools، connectors اور guardrails سے describe کرتے ہیں؛ service اسے چلاتی ہے۔ Loop، session state، retries، 3am crash recovery vendor computers پر vendor engineers چلاتے ہیں، default میں sandbox بھی۔ آپ loop operate کرنا چھوڑتے ہیں۔ Calling schedule، credentials، event consumption، escalations، spend limits، غلط outcome کا incident اب بھی آپ کے۔ Definition کے author اور business system کے owner آپ۔

یہ Course لکھتے وقت مثال Claude Managed Agents ہے، جو اپریل 2026 میں public beta میں آیا۔ Details بدلیں تب بھی shape سیکھیں۔ آپ تین چیزیں بناتے ہیں:

• ایجنٹ: definition، model، prompt، tools، guardrails۔ Rules file اور reviewer prompt اس form میں جو service رکھ سکے۔
• ماحول: بند جگہ جہاں agent actions execute ہوتے ہیں۔ Harness course کی fences local config نہیں، service-side object۔ یہی execution plane اور choice: default vendor infrastructure کا cloud sandbox، یا custody-required work کے لیے آپ کی controlled infrastructure پر self-hosted sandbox۔ Fences آپ set کرتے ہیں؛ production guidance least-privilege networking اور explicit allowed-hosts list ہے۔
• سیشن: ongoing work، محفوظ state اور append-only event log کے ساتھ۔ Loop course کی beat، مگر laptop نہ چاہیے تو pause، resume، کئی دن survive۔

آپ کی application، یا اس scale پر script، API سے بات اور events stream کرتی ہے۔ اہم detail: دونوں planes visible اور separable ہیں۔ سوچنے والا model اور action کا sandbox الگ pieces، service سے جڑے۔ پہلے coupled version، agent اور tools ایک machine process میں۔ Decoupled shape acting part کسی اور کو scale پر operate کرنے دیتی ہے؛ production architectures ادھر جا رہی ہیں۔ Mode 2 میں یہی آپ کی design choice ہوگا۔

دو boundary facts۔ Managed control plane vendor-specific ہے: یہ Claude اور Anthropic چلاتا ہے۔ Sandbox آپ کی infrastructure پر ہو سکتا، loop، sessions، model path نہیں۔ نیچے OpenCode tab مطلب بتاتا ہے۔ Managed runtime hosting والا SDK نہیں: Agent SDK اور Managed Agents الگ products؛ ایک کا code دوسرے پر deploy نہیں۔ Part 4 بتاتا ہے کیا ساتھ جاتا ہے۔

آپ کے ownership سے service کی چیز تک: loop job description agent prompt، permission walls اور deny rules environment config، ہر scheduled beat headless opened session۔ Endpoints، SDK call shapes، beta headers سب سے mechanical اور تیزی سے بدلتے۔ ہر detail live docs.claude.com سے لیں، اور پرانے tutorial، اسے بھی، shape سمجھیں، reference نہیں۔

اس طرف first-party home 3 نہیں، course fake نہیں کرتا۔ OpenCode remote چلتا، opencode serve headless server process دیتا، clients attach اور managed compute پر containerize ہو سکتے ہیں۔ Missing first-party managed control plane ہے: vendor loop، sessions، recovery service کی طرح چلائے۔ Interchangeable models کا ایک vendor نہیں۔ Honest equivalent: hardened home 2، scheduler + kit اور vendor آپ؛ یا آپ کا server process، home 4 اور Mode 2۔ بدلے میں managed plane سے ناممکن چیز: آپ اور loop کے درمیان کچھ نہیں۔ درست trade Part 5 کا سوال ہے۔

آسان زبان میں

ان Homes 1 اور 2 میں worker employ اور office maintain آپ کرتے ہیں۔ Home 3 میں job description اور office rules آپ لکھتے، building-services company power، security، night shifts، repairs والا office چلاتی ہے۔ آپ reports سے visit کرتے ہیں۔

6. کیا ملتا، کیا دیتے، اور قیمت کیا ہے

اس Managed contract کو دونوں طرف سے دیانت سے تولیں۔

کیا ملتا ہے۔ وہ operations جو آپ نہیں چاہتے: harness بنانے والوں کی maintained sandboxing؛ crashes اور کئی دن jobs survive کرنے والا session state؛ current model vendor کا tuned context management اور prompt caching۔ Manual compatibility work کم۔ Behavioral drift solve نہیں؛ model اور harness ساتھ update ہوں تو regression کی وجہ مشکل، کیونکہ دو چیزیں ہلیں۔ Scheduled baseline کا کام باقی۔ Infrastructure pager ان کا، 3am restart آپ کا مسئلہ نہیں۔ Business-outcome pager آپ کا: کام وقت پر ان کی machines پر غلط ہو تو escalation آپ کی۔

کیا دیتے ہیں۔ تین چیزیں، سب سے ہلکی سے سب سے بھاری تک۔ Visibility: آپ machine خود نہیں، service کا event log پڑھتے ہیں۔ Depth-3 trace grading، یعنی صرف جواب نہیں بلکہ agent کے اٹھائے قدم check کرنا، اب log میں دستیاب معلومات پر منحصر ہے۔ Custody: آپ کے prompts، fixtures اور کام کے inputs ایسی infrastructure پر execute ہوتے ہیں جسے آپ control نہیں کرتے۔ کچھ data، professions اور regulators کے لیے یہی ایک بات فیصلہ کر دیتی ہے؛ کوئی feature list جواب نہیں بدلتی۔ Portability: definition vendor کی shapes میں لکھی ہوتی ہے، اس لیے چھوڑتے وقت وہ move نہیں بلکہ rewrite ہوتی ہے۔ Part 6 اسی کا موضوع ہے۔

قیمت کیا ہے۔ Bill کی ایک نئی قسم، جو آج کے exact numbers سے زیادہ اہم ہے۔ Homes 1 اور 2 میں tokens اور runner کی cost ہوتی ہے۔ Home 3 میں runtime خود meter ہوتا ہے، بالکل بجلی کے meter کی طرح۔ اس وقت active session work تقریبا آٹھ cents per hour ہے، idle time free ہے، اور tokens اور web search جیسی metered extras الگ ہیں۔ اس shape کے دو نتائج ہیں۔ جو session تھوڑی دیر سوچ کر دیر تک سوتی ہے اسے زندہ رکھنا تقریبا free ہوتا ہے؛ اسی سے long-lived sessions affordable بنتی ہیں۔ اور جو loop بھٹکتی ہے، یعنی evals course کی depth-3 disease، وہ وقت کے ساتھ پیسہ بھی ضائع کرتی ہے۔ اس لیے eval suite صرف quality gate نہیں، cost control بھی ہے۔ Numbers بدلیں گے؛ live pricing page دیکھیں۔ اصل سبق bill کی shape ہے۔

آسان زبان میں

اس Managed runtime trade ہے۔ Vendor crashes، restarts، sandbox health سنبھالتا۔ آپ کچھ visibility، data custody، آسان portability دیتے ہیں۔ Active work-hours کا bill، idle free۔ بھٹکتا loop وقت اور پیسہ ضائع کرتا ہے۔

گہرائی میں: vendor updates ایک ساتھ مدد اور نقصان

اس Evals course کی drift story میں ایک مقرر shape تھی: unchanged harness کے نیچے model بدلا اور baseline نے جھکاؤ پکڑ لیا۔ Home 3 یہ shape بدلتا ہے، drift کو ختم نہیں کرتا۔ اب model اور harness vendor کے schedule پر، vendor engineers کی tuning کے ساتھ، ایک ساتھ بدلتے ہیں۔ عموما اس کا مطلب ان چھوٹے مسائل میں کمی ہے جنہیں آپ کی hand-tuned config پکڑتی تھی، مگر کبھی ایسا behavior بھی بدلتا ہے جس پر آپ depend کرتے تھے، حالانکہ آپ کی کوئی file نہیں بدلی۔ دفاع بالکل وہی رہتا ہے: scheduled full-set run، committed baseline اور drop پر loud alert۔ Managed runtime آپ کا operations burden ہٹاتا ہے، measurement burden نہیں۔ اس book میں کوئی چیز وہ ذمہ داری ختم نہیں کرتی۔

خود جانچیں

ایک Colleague کہتا ہے: managed sessions hourly metered، اس لیے اپنے schedule سے واضح مہنگی۔ Meter اور replaced چیز کے بارے میں دو misses؟

جواب دیکھیں

یہ Meter active runtime گنتا، idle free۔ ہر beat چند minutes کام اور باقی نیند والی session runtime line پر تقریبا کچھ نہیں۔ Per hour موجودگی کے ہر hour کا نہیں۔ Replace کیا: home 2 price صرف tokens نہیں، tokens + runner + آپ کے hours، configure، update، failure پر جاگنا۔ Honest comparison operator سمیت total cost۔ Hobby loop میں home 2؛ team-serving loops میں pager کی بھی price۔ اسی لیے cost Part 5 کا چوتھا input ہے، پہلا نہیں۔

---

حصہ 4: منتقلی خود

7. سوٹ کیس کا امتحان: نظم سفر کرتا ہے، عملی تفصیلات نہیں

گھروں کے درمیان ہر منتقلی کو یہ کورس ایک packing question میں بدلتا ہے: suitcase میں کیا جاتا، اور پہنچ کر کیا دوبارہ بنتا ہے؟

Trilogy نے جو سکھایا وہ سفر کرتا ہے۔ Spec: job اور done کا مطلب۔ محنت کے anchors والی rubric۔ ہر case کی origin line اور baselines والا golden set۔ Ratchet log، پکڑی failures کا جاری record، ہر ایک permanent test case۔ Maker-checker split، category bars، human gate۔ مشترک بات: ان میں کچھ software نہیں۔ یہ لکھے ہوئے فیصلے ہیں۔ Decision کو فرق نہیں کہ کون سا computer اسے نافذ کرتا ہے۔

Vendor یا machine کے نام والی چیز سفر نہیں کرتی۔ Flags، output formats، file paths، session state، ایک runtime API کا code۔ Concept 5 کی SDK-versus-managed boundary اس rule کی واضح شکل ہے۔ Cost assumptions بھی نہیں، جو homes کے درمیان size ہی نہیں shape بدلتی ہیں۔

یہی آخر lock-in کا اصل جواب بھی ہے، اس لیے صاف کہیں: آپ کا portable asset discipline layer ہے، اور اس کی portability کوئی موجود چیز نہیں بلکہ وہ چیز ہے جسے آپ برقرار رکھتے ہیں۔ جب بھی کوئی rule repo کے بجائے صرف vendor-side setting میں رہے، کوئی eval case صرف service کے اندر ہو، یا کوئی bar طے ہو مگر لکھی نہ جائے، suitcase کا وزن باہر fixtures میں چلا جاتا ہے۔ Move کے قابل رہنے کی عادت ایک جملے کی cost رکھتی ہے: truth repo میں ہے اور ہر home اسی سے configure ہوتا ہے۔

آسان زبان میں

گھر بدلیں تو اپنی چیزیں pack اور دیوار سے جڑی lights چھوڑ دیں۔ Spec، rubric، cases، bars آپ کی ہیں، suitcase میں جاتی ہیں۔ Flags، paths، API shapes پرانے گھر سے جڑی، پیچھے۔ Movable لوگ گھر میں رہتے ہوئے بھی valuables suitcase میں رکھتے ہیں۔

8. اعتماد منتقل نہیں ہوتا، دوبارہ کمایا جاتا ہے

اس Figure کے right panel کی آخری item اپنا concept مانگتی ہے، کیونکہ movers سب سے زیادہ اسی کو skip کرنا چاہتے ہیں۔ 35/36 ایک system کا measurement تھا: یہ config، harness، model، machine، reachable tools۔ Move نے کئی چیزیں ساتھ بدلیں۔ New home old system کا قریبی relative ہے، مگر old number اس system پر measured تھا جو اب نہیں۔ اسے inherit نہیں کیا جا سکتا۔ وہ comparison target رہتا ہے: new home کو جس standard تک پہنچنا ہے، مفت label نہیں۔

یہ Arrival protocol evals course کو جان بوجھ کر replay کرتا ہے؛ move regression discipline کا سب سے بڑا change ہے:

1. نئے گھر میں پہلے پورا golden set چلائیں۔ Smoke set نہیں، full set۔ Runner اور home headless ہیں۔ اسی لیے Concept 3 bridge ہے۔
2. Misses کو count سے پہلے category میں پڑھیں۔ Tone case down چھوٹا۔ New reach میں injection case down emergency؛ کسی اور move سے پہلے rubric یا fence fix۔
3. Bars برقرار رکھیں، پھر home-label baseline درج کریں۔ Old baseline delete نہیں، target۔ Location سے release bars نہیں بدلتے۔ New home existing bars pass کرے۔ Old rate سے meaningful gap investigate ہو، accept نہیں۔ پھر recorded date، model، rubric version اور runtime والا baseline۔ Explanation کے ساتھ دونوں history میں۔ Environment baseline بدلتا، acceptance standard خاموشی سے نہیں۔
4. انحصار سے پہلے آزمائشی مدت۔ Fixed period: کم از کم full operating cycle اور دس successful beats، riskier یا rare میں زیادہ۔ Old home available، beats روز new baseline سے checked۔ Initial operational evidence کہیں، uptime proof نہیں۔ New track record move مکمل کرتا ہے، old reputation نہیں۔

آسان زبان میں

آپ کا old score old setup پر measure ہوا تھا۔ Move نے setup بدل دیا، اس لیے score ساتھ نہیں آتا۔ New home میں اسے دوبارہ کمائیں: day one پر پورا test set چلائیں، دیکھیں کیا fail ہوا اور ہر failure کس قسم کا تھا، وہی pass-bar رکھیں جو پہلے تھا، new home کے نام کے ساتھ fresh score لکھیں اور trust کرنے سے پہلے trial period تک اسے دیکھیں۔

اس Harness course کی bad night جیسی warning۔ New home کی reach نئی: cloud runner کے credentials laptop سے الگ، managed environment کے tools local config سے الگ۔ Injection اور blast-radius cases old reach کے خلاف۔ Probation سے پہلے hard cases سے پوچھیں: جس failure سے یہ case بچاتا ہے، کیا وہ یہاں الگ دکھتی ہے؟ عموما نہیں؛ کبھی ہاں ہو تو سوال ہر future move میں شامل ہو گیا۔

خود جانچیں

اس Home 2 کے بعد full-set 33/36، old baseline 35/36: ایک clean-fix case flake، re-run green؛ باقی دو misses وہی case، old laptop کی absolute path والی fixture۔ Concept اور suitcase سے sort کریں۔

جواب دیکھیں

یہ Flake noise، re-run policy سے recorded، gating نہیں۔ Repeated miss agent regression نہیں، suitcase error: absolute path mechanics تھی اور fixture میں travel کر گئی۔ Case کو relative-path repair کریں، system کو نہیں۔ Set بدلا تو اسی commit میں re-baseline۔ Bars نہیں بدلتے، repair history میں visible تاکہ genuine regression suite fix میں نہ چھپے۔ Honest reading: new home baseline پر؛ move نے suite portability bug پکڑی، اسی لیے first run ہوتی ہے۔

---

حصہ 5: گھر کا انتخاب

9. چار سوال

یہ Course کا سب کچھ ترتیب سے چار سوالوں میں سمٹتا ہے۔ پہلے تین home چنتے ہیں، چوتھا move کا وقت۔

Q1: صارف کون ہے؟ Honest answer آپ ہو تو جلد رکیں: home 2 تقریبا ہمیشہ ceiling۔ زیادہ readers، زیادہ وقت، اور معذرت کی بات نہیں۔ جواب میں دوسرے لوگ، team، client یا customer، آتے ہی loop کو absence، vacation، login survive کرنا ہے؛ سوال Q2۔

Q2: کیا own کرنا لازم ہے؟ یہ نہیں کہ آپ کیا own کرنا چاہتے ہیں، بلکہ کیا واقعی own کرنا ضروری ہے۔ دو planes اس سوال کو تین صاف answers میں بانٹتی ہیں۔ کچھ own کرنا لازم نہیں: fully managed runtime مناسب ہے، اور vendor کو infrastructure pager سنبھالنے دینا compromise نہیں بلکہ پیسے کا درست استعمال ہے۔ صرف execution اور data plane، یعنی کام اور جس چیز کو وہ touch کرتا ہے، loop نہیں: self-hosted sandbox والا home 3 اسی کا جواب ہے۔ Custody آپ کے پاس رہتی ہے اور operations آپ rent کرتے ہیں۔ Control plane بھی: اگر prompts، sessions، model path یا agent کی product surface بھی آپ کو own کرنی ہے تو ضرورت home 3 سے آگے owned runtime، SDK path اور Mode 2 کی طرف جاتی ہے۔

Q3: کیا کوئی شخص جواب کا انتظار کرتا ہے؟ Scheduled اور background work، جیسے triage، reports اور pipelines، schedules اور managed sessions میں آرام سے fit ہوتے ہیں۔ Screen پر انتظار کرتا انسان requirements بدلتا ہے، owner لازما نہیں۔ اب predictable startup، streaming، cancellation اور concurrency والا serving runtime چاہیے۔ Managed service شاید self-operated runtime سے یہ بہتر دے، اور runtime own کرنا خود یہ صلاحیت نہیں دیتا، کیونکہ کوئی runtime model کا اپنا thinking time ختم نہیں کر سکتا۔ Ownership اب بھی Q2 سے آتی ہے۔ Q3 یہ بتاتا ہے کہ serving کام کی الگ shape ہے، یہ Mode 2 کی shape ہے، اور ابھی اسے پہچان لینا کافی ہے۔

Q4: بری رات کی قیمت؟ Harness budgeting آخری بار۔ Low radius: kit pass، جلد move، probation میں harden۔ High radius: first unattended shift سے پہلے kit اور full suite، injection categories تمام pass۔ Q4 destination نہیں، speed limit۔

آسان زبان میں

چار سوال اسی ترتیب سے پوچھیں۔ اسے کون استعمال کرتا ہے: صرف آپ یا دوسرے لوگ بھی؟ آپ کو کیا own کرنا لازم ہے: کچھ نہیں، صرف کام، یا پورا loop؟ کیا کوئی شخص screen پر جواب کا انتظار کرتا ہے؟ اور بری رات کی cost کیا ہے؟ پہلے تین سوال home چنتے ہیں۔ آخری صرف یہ طے کرتا ہے کہ آپ کتنی تیزی سے move کریں۔

10. ایک مکمل منتقلی، اور گھر جان بوجھ کر ملے ہوئے

اب پورا course ایک بار اسی morning triage loop پر چلتا دیکھیں جو اس section کے دوسرے course سے ساتھ چلا آ رہا ہے۔

سوال۔ Q1 user آپ اور report پڑھتے دو teammates۔ یہ plus trigger؛ loop login survive۔ Q2 کوئی must نہیں، repo GitHub، queue custody-restricted نہیں۔ Q3 کوئی screen پر wait نہیں۔ Verdict home 2، GitHub Actions، repo-attached اور eval gate وہی CI۔ Q4 bad labels اور ایک wrong escalation: annoying، recoverable، low radius۔ Speed: kit pass، ابھی move، دو-week probation، weekdays اور دس beats floor۔

منتقلی۔ Monday: workflow file (schedule: trigger، headless invocation، repo config checkout، exit check، واقعی پڑھے channel میں loud failure) plus concurrency lock، missed-run heartbeat، per-beat limits۔ Suitcase check میں laptop path fixture repair، same commit re-baseline۔ First full-set all categories bar، runtime: actions baseline۔ دو ہفتے lid closed، scheduled beats، silence baseline، planted failure، کیونکہ کبھی نہ سنی alarm افواہ۔ Beat ten، probation end، laptop schedule delete۔ دو track records، نیا اہم۔

ملاپ۔ اب دیکھیں کہ پورا system کیسا لگتا ہے، کیونکہ یہ جان بوجھ کر one-home نہیں ہے۔ Loop home 2 میں رہتی ہے۔ Eval gate، evals course کے مطابق، اسی CI میں رہتا ہے۔ Heavy one-off jobs، جیسے quarterly cleanup یا بڑا refactor، اب بھی home 1 میں interactively چلتی ہیں جہاں آپ انہیں دیکھ سکیں۔ اگر وہ teammates client بن جائیں تو Q1 دوبارہ اٹھتا ہے اور صرف serving path کے لیے home 3 گفتگو میں آتا ہے۔ Home مستقل وفاداری نہیں، ہر loop کے لیے چار سوالوں کا جواب ہے، اور صحت مند system عام طور پر دو یا تین homes میں پھیلا ہوتا ہے۔ Concept 7 کا ایک جملہ اس mix کو الجھن سے بچاتا ہے: repo truth رکھتا ہے اور ہر home اسی سے configure ہوتا ہے۔

آسان زبان میں

کوئی home وہ جگہ نہیں جہاں آپ ہمیشہ کے لیے بس جائیں۔ چار سوالوں کی بنیاد پر ہر loop کے لیے الگ choice ہوتی ہے۔ زیادہ تر real setups ایک وقت میں دو یا تین homes استعمال کرتے ہیں: daily loop schedule پر، اور heavy one-off job laptop پر جہاں آپ اسے دیکھ سکیں۔ ایک rule mix کو mess بننے سے روکتا ہے: truth repo میں رہتی ہے اور ہر home اسی سے setup ہوتا ہے۔

خود جانچیں

اس book کی دنیا کے ایک دوسرے loop پر چاروں سوال دوبارہ چلائیں: عائشہ کا invoicing loop اب پانچ clients کو serve کرتا ہے جو invoices سیدھے receive کرتے ہیں۔ ان میں ایک bank ہے جو شرط رکھتا ہے کہ client data اس infrastructure پر رہے جسے عائشہ کی firm control کرتی ہے۔ ہر سوال کا جواب کہاں land کرتا ہے، اور غیر آرام دہ مگر دیانت دار conclusion کیا ہے؟

جواب دیکھیں

پہلا جواب Q1: users clients ہیں، اس لیے home 1 سے آگے اور dependence کے لیے جب runner چل جائے سے بھی آگے جانا ہے۔ Q2 فیصلہ کن ہے، اور دو planes سوال کو precise بناتی ہیں: bank کا must execution اور data کے بارے میں ہے، یعنی کام کہاں چلتا اور کیا touch کرتا ہے۔ Firm کی infrastructure پر self-hosted sandbox کے ساتھ managed control plane شاید بالکل یہی ضرورت پوری کرے: client data firm کی custody میں اور loop vendor کے operations میں۔ فیصلہ عائشہ کا نہیں، bank کا ہے۔ اگر must control plane، prompts، sessions اور model path تک بھی جاتا ہے تو صرف owned runtime جواب ہے۔ Q3: invoicing scheduled background work ہے، latency pressure نہیں۔ Q4: real clients کو غلط invoices کا radius بڑا ہے، اس لیے unattended move سے پہلے kit اور full suite چاہیے۔ دیانت دار conclusion یہ ہے کہ کوئی ایک home fit نہیں۔ Bank کا راستہ یا home 3 with owned execution plane ہے، یا ضرورت زیادہ ہو تو SDK path۔ دونوں صورتوں میں عائشہ operator کے اکیلے configure کرنے کی حد پر آ گئی ہیں؛ book میں اس حد کا نام Mode 2 ہے۔ اسی لمحے کے لیے book کا fork موجود ہے۔

---

حصہ 6: دیانت برقرار رکھنا

11. لاک اِن ایک شرح ہے، ملکیت بدلتی رہتی ہے

پہلے کے بعد ہر home کے ساتھ دو slow failures، دونوں بے اعلان۔

Lock-in event نہیں، rate ہے۔ کوئی day one پر portability sign away نہیں کرتا۔ وہ آہستہ leak ہوتی ہے: vendor-side setting میں بدلا rule جو repo میں mirror نہ ہوا، service console کے اندر add ہوا eval case، یا dashboard میں دوبارہ طے کی گئی bar جس کے پیچھے کوئی commit نہیں۔ ہر چیز suitcase سے fixtures میں خاموشی سے چلی جاتی ہے۔ کسی بھی وقت lock-in کا سیدھا پیمانہ یہ سوال ہے: اگر یہ home اس quarter غائب ہو جائے تو move کی cost کیا ہوگی؟ بچاؤ وہی جملہ ہے: repo truth رکھتا ہے۔ اسے evals course کے Part 6 میں Goodhart audit کی طرح، schedule اور hold-out mindset کے ساتھ audit کریں۔ ہر quarter صرف repo سے fresh home configure کرنے کی practice portability کا hold-out set ہے۔ اگر fresh home complete نہیں ہوتا تو leak اس وقت مل گئی جب وہ ابھی صرف ایک item چوڑی تھی۔

کچھ leak نہ ہو تب بھی ownership drift کرتی ہے۔ زیادہ نازک failure files میں نہیں، آپ میں ہوتا ہے۔ مہینوں خاموشی سے چلنے والا home ذہن میں چھوٹی سی promotion پاتا ہے: system measured ہے سے system fine ہے تک۔ Evals course نے اس کا mechanical روپ بتایا تھا، جب drifted model کے ساتھ judge کا 95 اپنا مطلب بدل دیتا ہے۔ Runtime version انسانی ہے: baselines اب بھی green، schedule اب بھی silent، اور آپ آہستہ آہستہ per-category report پڑھنا، calibration دوبارہ چلانا اور vendor کی نئی capability پر Concept 8 کا new-reach سوال پوچھنا چھوڑ دیتے ہیں۔ Discipline میں پھر یہ خود کو maintain کرتا ہے نام کا کوئی step نہیں۔ Scheduled run system کو دیکھتی ہے؛ اسے پڑھنے کی calendar reminder آپ کو دیکھتی ہے۔

آسان زبان میں

دو آہستہ مسائل چھپ کر بڑھتے ہیں۔ پہلا: اگر سب کچھ repo میں نہ رکھیں تو ہر چھوٹی setting کے ساتھ وقت گزرنے پر home چھوڑنا مشکل ہوتا جاتا ہے۔ دوسرا: مہینوں خاموشی سے چلنے والا home آپ کو اسے check کرنا چھڑوا دیتا ہے۔ دونوں کا ایک ہی حل ہے: repo کو single source of truth رکھیں اور reports واقعی پڑھنے کے لیے calendar reminder لگائیں۔

12. کوئی گھر کیا درست نہیں کر سکتا، اور آگے کہاں

اس section کو اسی طرح ختم کریں جیسے اس کا ہر course ختم ہوا: دیانت دار boundary پر۔ Better home یہ بدلتا ہے کہ agent کب کام کرتا، اسے زندہ کون رکھتا اور 3am پر کیا ہوتا ہے۔ یہ اس بات کو بالکل نہیں بدلتا کہ agent کتنا اچھا کام کرتا ہے۔ Weak spec Anthropic cloud پر بھی weak ہے۔ Uncalibrated judge آٹھ cents per hour پر بھی uncalibrated ہے۔ Missing eval case دنیا کے ہر runner پر missing ہے۔ Runtime decision اسی لیے section کا آخری course ہے کہ پہلے course کے طور پر وہ بے کار ہوتا: جو کچھ move کیا جا رہا تھا اسے move کے قابل بننا تھا۔ اگر اس course میں move آسان لگا تو وجہ یہ ہے کہ hard part trilogy تھی۔ Move صرف suitcase ہے۔

آسان زبان میں

ایک better home یہ بدلتا ہے کہ agent کب چلے، اسے کون زندہ رکھے اور 3am پر کون درست کرے۔ وہ agent کو زیادہ smart یا correct نہیں بناتا۔ Weak plan cloud میں بھی weak رہتا ہے۔ اچھا کام اس spec، harness اور tests سے آتا ہے جو آپ پہلے بنا چکے ہیں۔ Home صرف طے کرتا ہے کہ system کو چلتا کون رکھے گا۔

اب section کا پورا arc سامنے ہے۔ آپ نے general agent کو drive کرنا، spec سے direct کرنا، پھر loop delegate، harness harden اور checker measure کرنا سیکھا، اور اب پورے system کو مناسب جگہ house کیا۔ آخر میں آپ کے پاس وہی چیز ہے جو book پہلے page سے خاموشی سے بنا رہی تھی: specified، guarded، measured اور housed unit of work۔ Book کی vocabulary میں اس جملے کو رکھیں تو اگلا door خود کھلتا ہے: جب یہ unit دوسرے لوگوں کے لیے بنی ہو اور اس کا owned runtime، product surface اور price ہو تو اس کا نام Digital FTE ہے۔ آپ پورے سفر میں operating scale پر اسی کو بنا رہے تھے۔

اس section سے تین doors نکلتے ہیں اور چار سوال پہلے ہی بتا چکے ہیں کہ آپ کون سا لیں۔ اگلا Personal Agent Harnesses section اس reader کے لیے ہے جس کا Q2 personal scale پر must own تھا: worker، infrastructure اور پورا runtime decision اپنے ہاتھ میں۔ Mode 1: Problem-Solving موجودہ system سے ابھی real problems solve کرنے کے لیے ہے اور زیادہ readers کا درست اگلا قدم ہے۔ Mode 2: Manufacturing میں اس course کے تمام وعدے پورے ہوتے ہیں: Agent SDK سے home 4 کھلتا ہے، decoupled architecture ورثے کے بجائے آپ کی design choice بنتی ہے اور Eval-Driven Development course اس suite کو scale کرتا ہے جس نے ابھی آپ کا move supervise کیا۔

آخری خیال: loop نے agent کو وقت دیا، harness نے limits اور evals نے track record۔ اس course نے worker کو آخری چیز دی: ایک address جو آپ کا نہیں۔ Rhetoric کے نیچے literal بات یہ ہے کہ independent address اس section کی آخری requirement ہے، production operations کی نہیں۔ Served product کو اب بھی owner، escalation path، retention policy، continuity اور اسے بند کرنے کا اختیار رکھنے والا شخص چاہیے؛ Mode 2 یہ سب سکھاتا ہے۔ مگر پہنچنا، کام کرنا، کام ثابت کرنا اور اپنی جگہ رہنا ہمیشہ پوری job description تھی۔ Agents کے لیے، اور صرف agents کے لیے نہیں۔

خود جانچیں

ایک reader course ختم کر کے کہتا ہے: "تو endgame home 3 ہے۔ آخر سب کچھ managed ہی ہوتا ہے۔" Q1 سے Q4، Concept 10 کے mix اور اوپر والی boundary کو استعمال کر کے دو جملوں کی correction لکھیں۔

جواب دیکھیں

درست بات یہ ہے کہ کوئی endgame home نہیں: چار سوال ہر loop کے لیے الگ پوچھے جاتے ہیں اور صحت مند system جان بوجھ کر کئی homes میں پھیلا ہوتا ہے۔ Home 1 میں build، home 2 میں schedule، اور جب کوئی must تقاضا کرے تو home 3 یا owned runtime سے serve کریں۔ کوئی home agent کا upgrade بھی نہیں: quality اس spec، harness اور suite میں رہتی ہے جو ساتھ travel کرتے ہیں۔ Home صرف طے کرتا ہے کہ lights on، یعنی system کو چلتا، کون رکھے گا۔

---

اس کتاب کے اپنے لوپس کہاں رہتے ہیں (dogfooding)

اس course کا decision course کے وجود سے پہلے اسی book پر چل چکا تھا۔ Book کا review loop، reviewer rubric، 95 bar اور اس سے نیچے no-merge rule، Q1 کا جواب ایک team دیتا ہے: authors اور issues file کرنے والے readers۔ اس لیے designed home، book کے repo پر home 2 کی CI ہے، اور بالکل وہی GitHub Actions version جسے course سکھاتا ہے، کیونکہ loop repo-attached ہے اور eval gate کو merge gate کے پاس رہنا چاہیے۔ Heavy interactive work، جیسے نیا course draft کرنا یا figure pipeline چلانا، اب بھی home 1 میں ہوتا ہے جہاں کوئی شخص دیکھ رہا ہو۔ اس وقت home 3 ایک کھلا سوال ہے اور book اسے بالکل Part 5 کی طرح دیکھتی ہے: serving path کو کوئی must own مجبور نہیں کرتا اور latency pressure نہیں، اس لیے managed option Q1 کا جواب دوبارہ بڑھنے تک انتظار کرتا ہے۔ Repo truth رکھتا ہے؛ homes details ہیں۔ آپ اسی arrangement کا output ابھی پڑھ رہے ہیں۔

---

🚀 منصوبے

آسان سے مشکل آٹھ moves۔ دو rules: throwaway repo اور failure خود plant کریں۔ Home اس bad night سے ثابت ہوتا ہے جسے survive کرے۔

📁Project 130-45 minHeadless wrapperایک beat command سے چلائیں، failure کو miss کرنا ناممکن بنائیں۔

مشکل کی سطح: آسان · Uses: Concept 3۔

بنائیں۔ اپنے loop کی beat کو script میں wrap کریں: headless invocation چلائیں، exit code check کریں اور failure کو ایسی جگہ واضح طور پر report کریں جہاں آپ واقعی دیکھتے ہیں۔

مکمل جب network cable نکال کر اسے چلانے پر خاموشی کے بجائے alarm آئے۔ اس course میں آگے کچھ بھی محفوظ ہونے سے پہلے خاموشی کا مطلب success ہونا چاہیے۔

⏰Project 21-2 hrsپہلی scheduled beatصرف clock منتقل کریں، lid بند beat دیکھیں۔

مشکل کی سطح: آسان سے درمیانی · Uses: Concept 4۔

بنائیں۔ Wrapper کو home 2 میں schedule پر رکھیں، یا تو Routine سے یا Actions کے schedule: trigger سے، اور config repo سے لیں۔

مکمل جب laptop بند ہونے کے باوجود ایک beat چل چکی ہو اور آپ بتا سکیں کہ result کہاں گیا۔ Kit کی پہلی تین rows بھی کسی نہ کسی صورت موجود ہوں، چاہے چھوٹی ہی کیوں نہ ہوں: idempotency، missed-run detection اور concurrency lock۔

🧳Project 345-60 minSuitcase auditDiscipline میں چھپی mechanics ڈھونڈیں۔

مشکل کی سطح: درمیانی · Uses: Concept 7۔

بنائیں۔ دو-panel والی figure کھول کر اپنی config، cases اور fixtures دیکھیں۔ Discipline layer میں چھپی mechanics کی ہر چیز list کریں: absolute paths، machine names اور prose میں جمائے گئے flags۔

مکمل جب list commit ہو اور بدترین تین چیزیں درست ہو چکی ہوں۔ کم از کم ایک ملنے کی توقع رکھیں؛ Part 4 کی story فرضی نہیں تھی۔

📏Project 41-2 hrsArrival protocolنئے گھر میں full set اور دیانت دار re-baseline۔

مشکل کی سطح: درمیانی · Uses: Concept 8۔

بنائیں۔ نئے home میں پورا golden set چلائیں۔ جو cases miss ہوں انہیں category کے لحاظ سے sort کریں۔ Runtime کے نام کے ساتھ نئی baseline درج کریں۔

مکمل جب baseline.json میں runtime: field ہو اور ہر miss کا لکھا ہوا verdict موجود ہو: noise، suite bug یا real۔ Real failures کا fix ship ہو چکا ہو۔

🌙Project 51 hr, plus two weeks of nightsProbationدس beats، planted failure، old home delete۔

مشکل کی سطح: درمیانی · Uses: Concepts 4 اور 8۔

بنائیں۔ نئے home میں کم از کم ایک پورا operating cycle اور دس scheduled beats چلائیں، روز نئی baseline سے check کریں اور old home available رکھیں۔ درمیان میں جان بوجھ کر ایک failure لگائیں۔

مکمل جب دس beats green ہوں، جان بوجھ کر لگایا گیا alarm آپ تک پہنچے اور old schedule delete ہو چکا ہو۔ Course کے مطابق اسی کا مطلب moved in ہے۔ Log کے اوپر initial operational evidence لکھیں، کیونکہ دس beats صرف اتنا ہی ثابت کرتی ہیں۔

🗺️Project 645-60 minچار سوال، لکھ کرہر loop کے Q1 سے Q4 answers commit کریں۔

مشکل کی سطح: درمیانی · Uses: Concepts 9 اور 10۔

بنائیں۔ ہر اس loop کے لیے جو آپ واقعی چلاتے ہیں، ایک committed Markdown file میں Q1 سے Q4 تک جواب دیں اور ہر جواب کے آخر میں home اور speed limit لکھیں۔

مکمل جب صرف اس file کو پڑھنے والا شخص بتا سکے کہ ہر loop کہاں رہتا ہے اور کیوں۔ کم از کم ایک loop کا جواب اتنا حیران کن ہو کہ آپ اسے move کریں۔

🏢Project 72-3 hrsگھر 3 میں ایک sessionManaged session کھولیں، event log کی حد دیکھیں۔

مشکل کی سطح: درمیانی سے مشکل · Uses: Concepts 5 اور 6۔ (Claude Code track۔ OpenCode readers: Project 2 runner harden کریں: credentials rotated، updates scheduled، uptime checked۔)

بنائیں۔ Live docs کی مدد سے ایک managed agent، ایک environment اور ایک session بنائیں جو آپ کے golden set کا ایک graded case چلائے۔ Event log شروع سے آخر تک پڑھیں۔ Active-runtime meter کو session سے پہلے اور بعد میں note کریں۔

مکمل جب آپ اپنے run کی بنیاد پر بتا سکیں کہ log نے کیا دکھایا، کیا نہیں دکھا سکتا تھا اور session کی cost کیا تھی۔ یہ تین جملے Project 6 کی file کے ساتھ commit ہوں۔

🔥Project 82 hrs, then a quarter of patienceVanishing-home drillصرف repo سے گھر دوبارہ بنائیں؛ وقت ہی lock-in ہے۔

مشکل کی سطح: capstone · Uses: Concept 11۔

بنائیں۔ صرف repo سے، vendor console یا old machine کے بغیر، اپنے loop کے home کی fresh copy configure کریں اور اسے baseline تک لے جائیں۔ وقت note کریں اور drill کو ہر quarter schedule کریں۔

مکمل جب fresh home پوری suite pass کرے اور لکھا ہوا time-cost آپ کا measured lock-in ہو۔ اگر drill fail ہو تو آپ نے leak اس وقت پکڑ لی جب وہ صرف ایک item چوڑی تھی؛ پورا مقصد یہی ہے۔

---

ماخذ اور مزید مطالعہ

اس کتاب میں

• Loop Engineering: beats، schedule، اور get loud۔
• Harness Engineering: fences اور Q4 کا blast-radius budget۔
• جانچنے والے پر اعتماد: golden set، baselines، drift gate۔
• Personal Agent Harnesses: Q2 کا personal must own۔
• اس کتاب کے Mode 2 میں Eval-Driven Development اور Deploy the Agent Harness: manufacturing size، home 4 کھلا۔

رن ٹائمز کی سرکاری دستاویزات

• دستاویزات میں Claude Code headless: claude -p، formats، scripting: https://code.claude.com/docs/en/headless
• دستاویزات میں Claude Agent SDK overview اور SDK-versus-managed: https://code.claude.com/docs/en/agent-sdk/overview
• دستاویزات میں Claude Managed Agents quickstart: agents، environments، sessions: https://platform.claude.com/docs/en/managed-agents/quickstart (اپریل 2026 public beta، سب سے تیز بدلتی docs)
• دستاویزات میں Managed environments، cloud sandboxes، least privilege، self-hosted: https://platform.claude.com/docs/en/managed-agents/environments
• دستاویزات میں Managed pricing، active session-hour meter: https://platform.claude.com/docs/en/about-claude/pricing
• دستاویزات میں Claude Code Routines، /schedule، triggers، stagger، green caveat: https://code.claude.com/docs/en/routines (research preview)
• دستاویزات میں Cowork Scheduled Tasks اور local caveat: https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork
• دستاویزات میں OpenCode CLI اور server: opencode run، opencode serve، remote attach: https://opencode.ai/docs/cli/
• دستاویزات میں GitHub Actions schedule: اور delay/drop: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule اور https://docs.github.com/en/actions/how-tos/troubleshoot-workflows

تمام links جولائی 2026 کے وسط تک current ہیں۔ Mechanical layer سب سے تیزی سے پرانی ہوتی ہے۔ انحصار سے پہلے live docs پر name، endpoint اور price کی تصدیق کریں۔

---

ایک سطر کا خلاصہ

ایک سوال سے شروع کریں: loop کون چلاتا ہے اور کام کہاں execute ہوتا ہے؟ Headless mode ہر نئے home تک bridge ہے۔ Discipline travel کرتی ہے، mechanics دوبارہ بنتی ہیں اور move کے بعد trust پھر measure ہوتا ہے۔ چار سوال home چنتے ہیں اور blast radius move کی رفتار طے کرتا ہے۔ Homes ہر loop کے لیے جان بوجھ کر mix ہوتے ہیں، اور repo truth رکھتا ہے تاکہ آپ ہمیشہ نکل سکیں۔ Worker تب مکمل ہوتا ہے جب اس کا address آپ کا نہ ہو۔

فلیش کارڈ مطالعہ

---

اپنی سمجھ جانچیں

Checking access...