ٹکٹس اور تفویض

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

اسائنمنٹ صرف ملکیت درج کرتی ہے؛ کچھ ڈسپیچ نہیں کرتی

ٹکٹس کے بارے میں سب سے اہم بات یہی سمجھنی ہے۔

assignedAgentId سیٹ کرنا ایک فیلڈ لکھتا ہے اور ایک TicketAssigned ڈومین ایونٹ شائع کرتا ہے۔ وہ ایونٹ ایک آڈٹ اور اطلاعات کا سگنل اور ایک پائپ لائن ٹریگر ہے۔ کسی ایجنٹ کو اسائن کرنے سے کوئی رن شروع نہیں ہوتا۔ کوئی ٹکٹ ڈسپیچر ایسا نہیں جو assignedAgentId پر نظر رکھے اور اس ایجنٹ کو جگائے۔

استثنا ایک ٹیم ہے: جب assignedTeamId سیٹ ہو، TeamRoutingService ٹیم لیڈر کو آپریٹنگ پروٹوکول اور روسٹر کے ساتھ ڈسپیچ کرتا ہے۔

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

آئینہ اور اضافی تہہ

ایک ٹکٹ خالصتاً مقامی ہو سکتا ہے یا کسی بیرونی ٹریکر کے سہارے، اور یہ دونوں چیزیں ایک ہی قطار میں رکھتا ہے۔

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

اضافی تہہ — اسائنمنٹ، تفویض، اسپیس لنک، والد، پروجیکٹ، لنک شدہ PRs — صرف Control Center میں ہوتی ہے۔ ٹریکر اس کے بارے میں کچھ نہیں جانتا اور ریفریش اسے کبھی نہیں چھوتا۔

یہی تقسیم سنک کو بہرصورت محفوظ بناتی ہے: وینڈر سے آنے والی ریفریش آئینے کے لیے تباہ کن ہو سکتی ہے مگر اوپر کی تہہ میں رکھا آرکیسٹریشن میٹا ڈیٹا کبھی ضائع نہیں ہوتا۔

لائف سائیکل گراف ایجنٹس کو باندھتا ہے، آپ کو نہیں

اسٹیٹس backlog → open → inProgress → inReview → done چلتے ہیں، جہاں blocked ایک طرفہ لوپ ہے اور failed / cancelled دیگر ٹرمینل حالتیں ہیں۔

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

UI میں صارف کے ہر عمل سے ہونے والی تبدیلی force: true بھیجتی ہے اور گراف کو مکمل طور پر نظر انداز کر دیتی ہے۔ کوئی انسان ٹکٹ کو پکر کی فہرست میں موجود کسی بھی اسٹیٹس پر لے جا سکتا ہے — بشمول ٹرمینل حالت دوبارہ کھولنے کے۔ پکر failed پیش نہیں کرتا؛ ایجنٹس یہ fail_ticket سے سیٹ کرتے ہیں۔ گراف آٹومیشن کے لیے ایک گارڈ ریل ہے، اس بات کا قاعدہ نہیں کہ کام کیسے آگے بڑھ سکتا ہے۔

TicketWorkflowService ہر میوٹیشن کی ملکیت ایک ہی چوک پوائنٹ سے رکھتی ہے جو قطار لوڈ کرتا ہے، تصدیق کرتا ہے کہ وہ کالر کے ورک اسپیس سے تعلق رکھتی ہے، اور متوقع version کے ساتھ لکھتا ہے تاکہ دو ہم وقت ترمیمات خاموشی سے ایک دوسرے کو اوور رائٹ نہ کر سکیں۔

مکمل اسٹیٹس ٹیبل، منتقلیاں، فیلڈ فہرست اور تعلق کی اقسام کے لیے ٹکٹ لائف سائیکل دیکھیں۔

ماخذ: ٹکٹ وجود میں کیسے آیا

ہر ٹکٹ کا ایک originKind ہوتا ہے۔ اس enum میں پانچ ویلیوز ہیں — manual، pipelineStep، agentDelegation، externalSync، recovery — مگر آج صرف دو لکھی جاتی ہیں: manual (createTicket پر ڈیفالٹ، بشمول تفویض شدہ ذیلی ٹکٹس) اور externalSync (سنک انجن، وینڈر سے آنے والی ریفریش پر)۔ TicketWorkflowService.createTicket کوئی origin آرگیومنٹ نہیں لیتا، اس لیے pipelineStep، agentDelegation اور recovery کبھی کسی قطار پر نہیں آتیں۔

محفوظ تفویض

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

delegate_task TicketWorkflowService.delegateGuarded سے گزرتا ہے، جو والد کی زنجیر سے چائلڈ کی گہرائی اور جڑ نکالتا ہے اور پھر DelegationGuards کے چاروں چیک چلاتا ہے: ایک ہاپ جو گہرائی کی حد 3 سے تجاوز کرے، زنجیر میں پہلے سے موجود ایجنٹ تک واپس جانے والا ہاپ (سائیکل کی نشان دہی)، خود مختاری کی چھت (اسپیس میں ڈیلیگیٹ کی مؤثر سطح تفویض کرنے والے سے زیادہ نہ ہو) اور ایک بجٹ لفافہ (تفویض، تفویض کرنے والے کے بقایا ہارڈ اسٹاپ بجٹ پر بل لگاتی ہے اور مزید نہیں بنا سکتی)۔ پروڈکشن وائرنگ دونوں ریزولور پورٹ مہیا کرتی ہے۔ جب from_agent_id چھوڑ دیا جائے تو خود مختاری اور بجٹ چھوٹ جاتے ہیں (لامحدود / بلا پالیسی بجٹ بھی پاس ہو جاتا ہے)۔ انکار DelegationRefusedException کے طور پر پھینکا جاتا ہے جس کا پیغام تفویض کرنے والے ایجنٹ تک لفظ بہ لفظ پہنچتا ہے — ایک واضح انکار، کبھی خاموش بے عملی نہیں۔

delegate_ticket پرانا، بلا گارڈ ساتھی ہے: یہ براہِ راست createTicket کال کرتا ہے اور ہر گارڈ کو چھوڑ دیتا ہے۔ delegate_task کو ترجیح دیں۔

تفویض کی گہرائی کی حد (3، delegate_task زنجیروں پر) کو بلٹ اِن ہارنس کی سب ایجنٹ نیسٹنگ کی حد (2) سے خلط نہ کریں۔ یہ مختلف میکانزم پر مختلف حدود ہیں۔

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

والد اور ذیلی ایشو کے تعلقات tickets.parent_ticket_id پر رہتے ہیں، جن کے مالک setParent / clearParent ہیں۔ یہ ticket_links قطاریں نہیں ہیں، اس لیے جو کوئی بھی ٹکٹ کے تعلقات پڑھے اسے دونوں ماخذ ضم کرنے پڑتے ہیں۔

ticket_links ورنہ غیر متعلق ٹکٹس کے درمیان سمتی کنارے رکھتا ہے:

لنک کی قسم	مطلب
blocks	ماخذ ہدف کو بلاک کرتا ہے
relatesTo	دونوں ٹکٹس متعلق ہیں (دوطرفہ)
duplicateOf	ماخذ ہدف کی نقل ہے

پروجیکٹ مشترک مقصد کی طرف ٹکٹس کی ورک اسپیس کے دائرے میں گروہ بندی ہے۔ پروجیکٹس صرف Control Center میں ہوتے ہیں اور کبھی کسی بیرونی فراہم کنندہ سے سنک نہیں ہوتے۔

تعاون کنندگان

TicketCollaborator قطاریں یہی طریقہ ہیں جس سے ایک سے زیادہ پرنسپل کسی ٹکٹ سے منسلک ہوتے ہیں، assignee، collaborator یا reviewer کے کردار پر۔ انسان اور ایجنٹ برابر درجے کی قطاریں ہیں — ایک principalId اور ایک collaboratorType — جس میں “صارف” کے لیے کوئی سینٹینل ویلیو نہیں اور کسی بھی ٹیبل کی طرف کوئی فارن کی نہیں۔

بیرونی سنک

Control Center کا ٹکٹ بنیادی ہے۔ ٹکٹ حذف کرنا صرف مقامی ہے، اس لیے وینڈر سے منسلک کوئی ٹکٹ جو آپ حذف کریں وہ ٹریکر پر حذف نہیں ہوتا اور اگلے سنک پر دوبارہ ظاہر ہو سکتا ہے۔ تعاون کنندگان اور ذیلی ٹکٹس کیسکیڈ ہوتے ہیں۔

اڈاپٹر کی اسناد سرور کے کریڈینشل اسٹورز سے حاصل ہوتی ہیں (ترتیبات میں پیسٹ کی گئی Linear کلید یا GitHub ٹوکن اگلی درخواست پر اٹھا لی جاتی ہے؛ ماحول صرف ان اسٹورز کو سیڈ کرتا ہے)۔

ٹکٹس اور پائپ لائنز

کوئی پائپ لائن نوڈ ٹکٹ نہ بناتا، نہ مکمل کرتا، نہ منسوخ کرتا ہے — پیلٹ میں ایسا کوئی قدم نہیں اور انجن TicketWorkflowService کو کال نہیں کرتا۔ پائپ لائن ٹریگر پھر بھی TicketAssigned، TicketCompleted، TicketFailed یا TicketCancelled پر چل سکتا ہے (یہ چار وہ ٹکٹ ایونٹس ہیں جو EventPayloadMapper واقعی میپ کرتا ہے)۔ ٹکٹ پر کوئی pipelineRunId کالم نہیں ہوتا؛ پائپ لائن کا جوڑ ایجنٹ رن لاگ پر رہتا ہے۔

مزید دیکھیں

• پائپ لائنز اور آٹومیشن: ٹکٹ ایونٹس ایک پائپ لائن ٹرگر کر سکتے ہیں
• آرکیسٹریشن: ذیلی ٹکٹس کا DAG کہاں سے آتا ہے
• ایجنٹ ماڈل: ٹکٹ کس کو اسائن ہوتا ہے
• ڈومین ایونٹس: ٹکٹ لائف سائیکل کے ایونٹس
• ٹکٹ لائف سائیکل: اسٹیٹس، فیلڈز، منتقلیاں، تعلقات
• ٹکٹس بنائیں اور منظم کریں
• ایجنٹس کو کام تفویض کریں
• پروجیکٹس سے کام منظم کریں