ڈیپلائمنٹ اور کلائنٹس

Control Center کوئی ایک پروگرام نہیں ہے۔ یہ ایک تھن کلائنٹ آرکیٹیکچر ہے: ایک ہیڈلیس سرور جو آپ کے ڈیٹا کا مالک ہے، اور کلائنٹس کا ایک مجموعہ جو اُس سے ایک ہی RPC کنکشن پر ایک انٹرفیس رینڈر کرتا ہے۔ اِس تقسیم کو سمجھنا واضح کرتا ہے کہ کچھ چیزیں وہاں کیوں چلتی ہیں جہاں چلتی ہیں، اور ہر کلائنٹ کس چیز تک پہنچ سکتا ہے اور کس تک نہیں۔

سرور ڈیٹا کا مالک ہے

cc_server نامی ایک پروسیس ڈیٹا بیسز اپنے پاس رکھتا ہے — سرور بھر کی حالت کے لیے ایک چھوٹا global.db اور ہر ورک اسپیس کے لیے ایک SQLite فائل، جو حسبِ ضرورت کھولی جاتی ہے — اور طویل المدتی کام چلاتا ہے: پائپ لائن انجنز، ری کنسلرز، MCP ٹول سطح اور آرکیسٹریشن لسنر۔ جو کچھ بھی کسی ونڈو سے زیادہ جینا چاہیے، یا جو دو کلائنٹس کو یکساں طور پر دکھائی دینا چاہیے، وہیں رہتا ہے۔

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

یہ جان بوجھ کر ایسا ہے اور اسی چیز کی بدولت ایک ہی سرور پر دو کلائنٹس مختلف ورک اسپیسز میں بیٹھ سکتے ہیں، بغیر اِس کے کہ سرور کے پاس کوئی ”موجودہ ورک اسپیس“ ہو جس پر اُن کا اختلاف ہو۔ اِس کے بجائے تنہائی فی کال نافذ کی جاتی ہے، چار مراحل میں:

آپریشن خود بتاتا ہے کہ اُس کا دائرہ ورک اسپیس ہے یا نہیں؛ اگر ہے اور workspace_id نہ آیا، تو کال رد کر دی جاتی ہے۔
بتائی گئی id ایک رجسٹر شدہ ورک اسپیس ہونی چاہیے، جس کی جانچ ڈیٹا بیس کھلنے سے پہلے ہوتی ہے — ورنہ ایک نامعلوم id ہر درخواست پر ایک خالی بھوت workspace.db بنا ڈالے گی۔ نہ ملنا ایک ناٹ-فاؤنڈ ہے۔
کال کرنے والے کا WorkspaceRole آپریشن کی کم سے کم حد پورا کرنا ضروری ہے، جو اُس کی قسم سے طے ہوتی ہے: پڑھنے کے لیے مہمان، تبدیلی کے لیے رکن، تباہ کن کے لیے ایڈمن۔
جو آپریشن ریپو کا مواد سامنے لاتا ہے، اُس کے لیے اضافی طور پر اُس سطح پر فی ریپو گرانٹ درکار ہے جو وہ خود بتاتا ہے — none / read / review / write — تاکہ ورک اسپیس کی رکنیت کبھی خاموشی سے forge کے اختیارات سے آگے نہ بڑھے۔

اصل بات یہ ہے: رسائی کی حد پیئرنگ کلید رکھنا نہیں؛ رکنیت ہے۔

یہ تقسیم اِس طرح کیوں؟

تین دباؤ نے اِسے سرور کی طرف دھکیلا:

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

اس کا نقصان یہ ہے کہ اب سرور ایک انحصار بن جاتا ہے: اگر وہ چل نہ رہا ہو تو کچھ بھی کام نہیں کرتا۔ ڈیسک ٹاپ کا ڈیفالٹ جواب یہ ہے کہ وہ خود ایک سرور شروع کر دیتا ہے۔

کلائنٹس

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

ڈیسک ٹاپ ایپ

Flutter ڈیسک ٹاپ ایپلیکیشن (macOS، Windows، Linux) مکمل کلائنٹ ہے۔ پہلی بار چلنے پر یہ پوچھتی ہے کہ اُسے کیسے چلنا چاہیے، اور پھر انتخاب یاد رکھتی ہے:

مقامی: اِس مشین پر ایک cc_server شروع کریں اور اُس کی نگرانی کریں — ڈیفالٹ، خود مکتفی، واحد صارف سیٹ اپ۔ ڈیسک ٹاپ سرور لانچ کرتا ہے، جو app-support root کے تحت ڈیٹا بیس کا مالک ہوتا ہے اور لوپ بیک پر اُس سے بات کرتا ہے۔
ریموٹ: کہیں اور چل رہے cc_server سے ایک محفوظ WebSocket پر جڑیں۔ ڈیٹا اُسی سرور پر رہتا ہے؛ یہ ڈیسک ٹاپ صرف ایک رینڈرر ہے۔

دونوں صورتوں میں بننے والا RPC کلائنٹ ایپ کے ڈیٹا پرووائیڈر کو اوور رائیڈ کرتا ہے، لہٰذا پوری UI — ہر اسکرین، ہر فیچر — سرور کے ذریعے پڑھتی اور لکھتی ہے۔ ڈیسک ٹاپ کبھی ڈیٹا بیس فائل کو براہِ راست نہیں چھوتا۔

ویب کلائنٹ

ویب بلڈ وہی Flutter ایپ ہے جو براؤزر میں چلنے کے لیے کمپائل کی گئی ہو، اور app.usectrl.dev پر میزبانی کی جاتی ہے تاکہ انسٹال کرنے کی ضرورت نہ رہے۔ براؤزر کوئی ذیلی پروسیس شروع نہیں کر سکتا، لہٰذا ویب کلائنٹ ہمیشہ ریموٹ ہوتا ہے: یہ wss:// پر ایک cc_server کو ڈائل کرتا ہے اور مکمل ڈیسک ٹاپ انٹرفیس رینڈر کرتا ہے۔ جڑنے کے بعد یہ اُسی فلیٹ کے سامنے وہی اسکرینیں دکھاتا ہے، کیونکہ یہ وہی کوڈ ہے جو اُسی RPC پر چلتا ہے۔ خلا صرف چند اُن جگہوں پر ہیں جہاں کوئی نیٹو صلاحیت درکار ہوتی ہے جو براؤزر میں نہیں ہوتی — نیچے دی گئی میٹنگ کیپچر کوالٹی لیئر سب سے بڑی ہے اور OS اطلاعات دوسری۔

اسی لیے ”ڈاؤن لوڈ کی ضرورت نہیں“ اور ”سرور کی ضرورت نہیں“ دو الگ دعوے ہیں۔ ویب کلائنٹ انسٹال کی ضرورت ختم کرتا ہے؛ سرور ختم نہیں کرتا۔ جس سے یہ جڑتا ہے وہ اُسی لیپ ٹاپ پر ایک cc_server ہو سکتا ہے — ws://localhost:9030، جس کے لیے کسی سرٹیفکیٹ کی ضرورت نہیں کیونکہ براؤزر لوپ بیک کو قابلِ اعتماد سمجھتے ہیں — یا کسی دوسری مشین پر، جس تک wss:// کے ذریعے ایسے سرٹیفکیٹ کے ساتھ پہنچا جا سکتا ہو جس پر براؤزر بھروسا کرے۔ cc_server TLS کے بغیر غیر لوپ بیک ایڈریس بائنڈ کرنے سے انکار کرتا ہے، لہٰذا ریموٹ سرور کا مطلب ہے یا تو اُس کا اپنا سرٹیفکیٹ، یا TLS ختم کرنے والا پراکسی، یا کوئی ٹنل یا VPN جو ایک مہیا کرے۔

بنڈل خود اُس سرور سے الگ میزبانی کیا جاتا ہے جس سے وہ بات کرتا ہے۔ اکیلا cc_server RPC اینڈ پوائنٹ، MCP سطح اور اُس کے پراکسیز پیش کرتا ہے، مگر ویب بنڈل نہیں — سرور میں اسٹیٹک فائل کا راستہ موجود ہے لیکن اسٹینڈ اَلون بائنری پر کوئی ویب روٹ کنفیگر نہیں، لہٰذا / پر پیش کرنے کے لیے اُس کے پاس کچھ نہیں ہوتا۔ شائع شدہ cc-webapp کنٹینر امیج ہی بنڈل کی میزبانی کرتی ہے اور scripts/build_web.sh اُسے بناتا ہے۔ سرور براؤزر اوریجنز صرف اپنی --allowed-origins فہرست پر قبول کرتا ہے، جس کا ڈیفالٹ https://app.usectrl.dev ہے، لہٰذا بنڈل کی خود میزبانی کا مطلب ہے کہ اُس کا اوریجن شامل کیا جائے۔

میڈیا (اوتار، فیڈ کی تصاویر، PR اسکرین شاٹس) اپ اسٹریم ہوسٹس کو براہِ راست ہٹ کرنے کے بجائے سرور کے پراکسی اینڈ پوائنٹ سے گزرتا ہے، لہٰذا براؤزر کبھی کسی من مانے اوریجن سے ڈیٹا نہیں لاتا۔ ڈیپلائے شدہ کلائنٹ فی درخواست ایک غیر حساس کوکی سے Content-Security Policy لگاتا ہے تاکہ صرف جڑے ہوئے سرور کا اوریجن اجازت یافتہ ہو۔

فون کمپینین (cc_remote)

ریموٹ ایپ ایک الگ، ہلکا پھلکا کلائنٹ ہے — remote.usectrl.dev پر ایک Flutter ویب PWA۔ یہ جان بوجھ کر مکمل ایپ نہیں ہے۔ یہ ایک بروکر شدہ، اینڈ ٹو اینڈ سیل شدہ WebSocket ریلے پر پیئر ہوتی ہے اور ٹول سطح کے زیادہ تر پڑھنے والے حصے سے بات کرتی ہے: ٹکٹس، پیغامات اور نیوز فیڈ پڑھنا؛ جواب بھیجنا یا ٹکٹ اپ ڈیٹ کرنا۔

ایک فون مقامی ایجنٹ سے کم تر مراعات یافتہ پرنسپل ہوتا ہے۔ ڈیفالٹ-ڈینی ٹول پالیسی، ہر فریم کو سیل کرنے والی پری شیئرڈ کلید، ایک سیشن کیپیبلٹی جو مراعات یافتہ آپریشنز (مثلاً پیئرنگ) کو کمپینین کلائنٹ سے باہر رکھتی ہے، اوپر بیان کردہ فی کال کردار اور ریپو گرانٹ جانچیں اور ریٹ لمٹنگ — یہ سب مل کر ایک منظور شدہ (یا لیک ہو جانے والی) پیئرنگ کو مکمل ریموٹ کنٹرول بننے سے روکتے ہیں۔ مکمل سیکیورٹی ماڈل کے لیے ریموٹ کنٹرول اور موبائل دیکھیں۔

MCP کلائنٹس

بیرونی ٹولز — ایڈیٹرز، دوسرے ایجنٹس، CLIs — جو Model Context Protocol بولتے ہیں، سرور کی MCP سطح سے جڑتے ہیں اور ٹائپ شدہ ٹول رجسٹری استعمال کرتے ہیں۔ یہ پروگرامیٹک انٹیگریشن کا راستہ ہے؛ یہ کوئی GUI نہیں۔ MCP سرور استعمال کریں اور MCP ٹولز کا حوالہ دیکھیں۔

فلیٹ ایگزیکیوٹرز (cc_worker)

ایک cc_worker ایک ہیڈلیس pure-Dart بائنری ہے جو ایک cc_server سے پیئر ہوتی ہے، اپنی میزبان مشین کی صلاحیتیں ظاہر کرتی ہے اور چلانے کے لیے لیز پر لیے گئے جابز کھینچتی ہے۔ یہ پروسیس ایونٹس واپس اُسی RPC پر اسٹریم کرتی ہے اور کوئی پائیدار حالت نہیں رکھتی: نہ ڈیٹا بیس، نہ تصدیق، نہ منظوریاں، نہ بجٹ — یہ سب cc_server سے کبھی باہر نہیں جاتے۔ ایک ورکر ایک عضو ہے، دوسرا دماغ نہیں۔ ایک بااختیار سرور، N گونگے اعضاء؛ نہ کوئی اتفاقِ رائے، نہ worker-to-worker ٹریفک۔

لیز پر عمل درآمد پھر بھی صرف لیز کی پلمبنگ ہے۔ agentRun واحد قسم ہے جو حقیقی کمانڈ چلاتی ہے (CC_JOB_COMMAND، یا اگر کوئی فراہم نہ کی گئی ہو تو ایک باز گشت شدہ پرامپٹ)۔ pipelineStep، codeIndex، goldenRender، benchmark اور evalBatch فی الوقت git --version / rev-parse HEAD سے پروب کرتی ہیں تاکہ اسٹریمنگ راستہ آزمایا جائے، بغیر یہ ظاہر کیے کہ وہ جابز واقعی چلے۔

یہ جو کچھ ظاہر کرتی ہے وہ ہے: آپریٹنگ سسٹم، CPU آرکیٹیکچر، کورز کی تعداد، RAM، کہ Flutter SDK قابلِ رسائی ہے یا نہیں، اور میزبان کے پاس کون سے سینڈ باکس بیک اینڈز ہیں (Windows پر کوئی نہیں)۔ ایک مختص ورکر ہمیشہ alwaysOn اور acceptsParallel بھی ظاہر کرتی ہے، اور pin → prefer → spill شیڈیولر اُنہی کے مطابق جابز رکھتا ہے۔ کوئی GPU یا ML پروب نہیں ہے۔

اکیلا ڈیسک ٹاپ اِن میں سے کچھ محسوس نہیں کرتا، کیونکہ عام ڈسپیچ فلیٹ سے ہو کر گزرتا ہی نہیں۔ سرور میزبان کے لیے ایک مضمر in-process ورکر رجسٹرڈ ضرور ہے، مگر یہ ایک رجسٹریشن سیون ہے جس میں کوئی رنر جڑا نہیں — مقامی ورکر پر واقعی رکھا گیا جاب چلنے کے بجائے ناکام ہوتا ہے۔ آج لیز پر لیے گئے جابز صرف ایک حقیقی cc_worker ہی چلاتی ہے۔

کہاں کیا چلتا ہے

شعبہ	سرور (`cc_server`)	فلیٹ ایگزیکیوٹر (`cc_worker`)	ڈیسک ٹاپ کلائنٹ	ویب / فون کلائنٹ
ڈیٹا بیسز (Drift/SQLite)	اِن کا مالک	—	—	—
تصدیق، منظوریاں، بجٹ، شناخت	اِس کا مالک	—	—	—
پائپ لائنز، ری کنسلرز، آرکیسٹریشن لسنر	اِنہیں چلاتا ہے	—	—	—
MCP ٹول سطح	اِسے پیش کرتا ہے	—	—	—
ایجنٹ کا عمل درآمد	اِسے چلاتا ہے (یا لیز پر دیتا ہے)	لیز پر لیے جابز چلاتا ہے	—	—
UI رینڈرنگ	—	—	مکمل	مکمل (ویب) / زیادہ تر پڑھنے والا (فون)
میٹنگ کیپچر (مائک + میٹنگ آڈیو)	—	—	نیٹو کیپچر	صرف ویب، اسکرین شیئر آڈیو کے ذریعے
کیلنڈر OAuth (Google)	ٹوکنز رکھتا ہے	—	—	—

یہ دونوں ٹیئرز ایک جیسا سینڈ باکسنگ نہیں کرتے۔ cc_server جو رنز خود چلاتا ہے اُنہیں میزبان کے OS سینڈ باکس میں لپیٹتا ہے جہاں کوئی بیک اینڈ موجود ہو — macOS پر Seatbelt، Linux اور WSL2 پر bubblewrap — اور Windows پر یا bwrap اور socat کے بغیر دیگر حدود پر واپس چلا جاتا ہے۔ cc_worker بالکل سینڈ باکس نہیں کرتا۔ یہ ایک sandbox کیپیبلٹی ظاہر کرتا ہے تاکہ سرور جابز کو پلیٹ فارم کے مطابق رکھ سکے، مگر ورکر میں کوئی چیز ایسا سینڈ باکس لاگو نہیں کرتی: لیز پر لیا گیا جاب براہِ راست پیدا ہوتا ہے، جس کی حدیں لیز کا ماحول اور اُسے دیا گیا worktree طے کرتے ہیں۔ لہٰذا کام لیز پر دینا عمل درآمد کو سینڈ باکس سے باہر لے جاتا ہے، چاہے میزبان میں سینڈ باکس موجود ہو۔ ہر صورت میں کسی رن کی حدود کیا ہوتی ہیں، اِس کے لیے سینڈ باکس اور سیکیورٹی دیکھیں۔

میٹنگ کیپچر کلائنٹ پر ہوتا ہے کیونکہ اُسے مائکروفون اور میٹنگ کی آڈیو درکار ہوتی ہے — الماری میں رکھا سرور آپ کی کال ریکارڈ نہیں کر سکتا۔ پھر ریکارڈنگ کا خلاصہ سرور کی پائپ لائن کرتی ہے اور نوٹس وہاں محفوظ ہوتے ہیں جہاں سے ہر کلائنٹ اُنہیں پڑھ سکے۔

ویب کلائنٹ بھی ریکارڈ کرتا ہے، جسے ٹیبل کی شکل مبہم کر سکتی ہے: یہ براؤزر میں مائکروفون کے ساتھ ایک اسکرین شیئر آڈیو ٹریک بھی لیتا ہے اور 16 kHz PCM سرور کو اسٹریم کرتا ہے۔ اُسے اُس آڈیو ٹریک کی لازماً ضرورت ہوتی ہے، لہٰذا جہاں براؤزر وہ فراہم نہ کرے وہاں یہ واضح طور پر ناکام ہو جاتا ہے۔ اصل میں صرف ڈیسک ٹاپ پر دستیاب چیز کیپچر کے گرد کوالٹی لیئر ہے — نیٹو پروسیسر کے ذریعے سگنل کی سطح پر ایکو کینسلیشن، اِن پٹ لیول میٹر اور ڈیڈ-مائک انتباہ، خلاصہ دوبارہ چلانا، پراسیسنگ روکنا اور کیلنڈر کی ریکارڈ اور لنک کارروائی۔

پیئرنگ اور اعتماد

ہر کلائنٹ اپنی شناخت ایک بار فراہم کی گئی پری شیئرڈ کلید سے ثابت کرتا ہے:

مقامی موڈ میں ڈیسک ٹاپ ہر بوٹ پر ایک نئی کلید بناتا ہے اور اُسے ماحول کے ذریعے شروع کیے گئے سرور کو دیتا ہے، لہٰذا ڈیسک ٹاپ پر کوئی راز محفوظ نہیں رہتا۔
ریموٹ کلائنٹس (ڈیسک ٹاپ ریموٹ، ویب، فون) وہ کلید استعمال کرتے ہیں جو سرور کی pair کمانڈ بناتی ہے اور OS کی چین میں محفوظ ہوتی ہے (یا فون پر مقامی طور پر)۔

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

کلید کبھی ایسے URL سے نہیں گزرتی جسے کوئی اسٹیٹک ہوسٹ دیکھ سکے۔ جب یہ لنک کے ذریعے آتی ہے — فون پر یا براؤزر میں — تو یہ URL فریگمنٹ میں سوار ہوتی ہے، یعنی # کے بعد والے حصے میں، جسے براؤزر صفحے کی میزبانی کرنے والے سرور کو کبھی نہیں بھیجتا۔ یہی وہ اصول ہے جو یاد رکھنے کے قابل ہے اور یہ دونوں پر لاگو ہوتا ہے۔ ویب کلائنٹ کے دو اور داخلی دروازے ہیں: کنیکٹ فارم، جہاں آپ سرور اور کلید براہِ راست پیسٹ کرتے ہیں، اور ایک انوائٹ کوڈ، جسے یہ ایک ایسی اسناد کے بدلے چھڑا لیتا ہے جو صرف اُس براؤزر کے لیے بنائی گئی ہو۔