Jev GUI Delegate ٹیوٹوریل: Codex کو Windows اور Chrome کے GUI آپریشنز سونپیں

پروجیکٹ کا جائزہ

Jev GUI Delegate، Codex کے لیے Windows اور Chrome GUI delegation کا ایک پروٹوٹائپ ہے۔ مرکزی ماڈل کام کے اہداف اور قبولیت کی شرائط فراہم کرتا ہے، جبکہ مقامی کنٹرولر انٹرفیس کا مشاہدہ، کنٹرولز کی مطابقت، کارروائیوں کا نفاذ، اور ہر مرحلے پر حقیقی نتائج کی جانچ کرتا ہے۔ کنٹرولر صرف اس وقت TypeSafe Jev کو کال کرتا ہے جب کسی معنوی انتخاب کو قطعی قواعد کے ذریعے حل نہ کیا جا سکے۔

یہ جس بنیادی مسئلے کو حل کرتا ہے وہ یہ ہے: اگر مرکزی ماڈل ویب صفحے یا ڈیسک ٹاپ ایپلیکیشن کو مرحلہ وار چلائے، تو اسے بار بار انٹرفیس پڑھنا، کنٹرول منتخب کرنا اور ٹول کے نتائج سنبھالنا پڑتا ہے، جس سے آپریشن کا مہنگا چکر بنتا ہے۔ Jev GUI Delegate واضح طور پر قابلِ قبولیت جانچ والے آپریشن کا ایک حصہ مقامی کنٹرولر کو مسلسل انجام دینے کے لیے دیتا ہے، جبکہ حالت کی جانچ، خرابی سے بحالی اور صارف کے کنٹرول سنبھالنے کی صلاحیت برقرار رہتی ہے۔

یہ پروجیکٹ ذاتی طور پر ڈیزائن کیا گیا، AI کی مدد سے نافذ کیا گیا اور مسلسل قبولیت جانچ سے گزرنے والا پروٹوٹائپ ہے۔ ٹاسک کنٹریکٹ، ٹول آرکیسٹریشن، بحالی کا طریقہ کار، اجازت کی جانچ، ٹیسٹ اور فیڈبیک کی بنیاد پر تکرار پروجیکٹ کی شراکتیں ہیں؛ Jev ماڈل، TypeSafe SDK، Codex اور براؤزر پلگ اِن upstream مصنوعات ہیں۔

کام کا طریقہ

1. Codex کا مرکزی ماڈل ہدف اور قبولیت کی شرائط جمع کراتا ہے۔

2. ٹاسک کو مقامی طور پر جانچے جا سکنے والے ٹاسک کنٹریکٹ میں ترتیب دیا جاتا ہے۔

3. کنٹرولر موجودہ انٹرفیس کا مشاہدہ کرتا ہے اور قطعی کنٹرول مطابقت کی کوشش کرتا ہے۔

4. جب براہِ راست فیصلہ ممکن نہ ہو تو کنٹرولر معنوی انتخاب کے لیے Jev کو کال کرتا ہے۔

5. Chrome آپریشنز میزبان کے فراہم کردہ سرکاری براؤزر سیشن کے ذریعے، جبکہ Windows آپریشنز UI Automation کے ذریعے انجام پاتے ہیں۔

6. کنٹرولر حقیقی نتیجے کی تصدیق کرتا ہے، پیش رفت محفوظ کرتا ہے، اور فیصلہ کرتا ہے کہ جاری رکھنا ہے، بحال کرنا ہے، روکنا ہے، یا مرکزی ماڈل سے مزید معلومات طلب کرنی ہیں۔

یہ طریقہ ذاتی براؤزر کی ترتیب نقل نہیں کرتا اور نہ ہی Cookie حاصل کرتا ہے۔ Chrome کا راستہ Codex میزبان کے فراہم کردہ مطابقت رکھنے والے سرکاری براؤزر سیشن API پر منحصر ہے؛ خود repository یہ سیشن تخلیق یا اس کا متبادل فراہم نہیں کر سکتی۔

اہم خصوصیات

GUI نفاذ کے دو راستے

• Chrome: میزبان کے فراہم کردہ سرکاری براؤزر سیشن کو دوبارہ استعمال کرتا ہے۔

• Windows: قابلِ رسائی ڈیسک ٹاپ کنٹرولز کو چلانے کے لیے Windows UI Automation استعمال کرتا ہے۔

واضح ٹاسک کنٹریکٹ

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

ضرورت کے مطابق Jev کو کال کرنا

جن کنٹرولز کا تعین مقامی قواعد سے ہو سکتا ہے، انہیں کوڈ براہِ راست ملاتا ہے؛ Jev صرف اس وقت کال کیا جاتا ہے جب متن کے مفہوم یا امیدوار اختیارات کی معنوی نوعیت کو سمجھنا ضروری ہو۔ پروجیکٹ حقیقی صورتِ حال کے مطابق صفر ماڈل کالز ریکارڈ کرتا ہے اور انہیں غلطی سے Jev کی کامیاب reasoning کے طور پر شمار نہیں کرتا۔

مسلسل نفاذ اور بحالی

کنٹرولر نفاذ کی پیش رفت محفوظ کر سکتا ہے اور ان پٹ کی کمی، جزوی انتخاب کی غلطی، توقف، منسوخی اور صارف کے کنٹرول سنبھالنے جیسی صورتِ حال کو سنبھال سکتا ہے۔ اگر جمع کرانے کی کارروائی کامیاب ہوئی یا نہیں، اس کی تصدیق نہ ہو سکے تو تکراری جمع کرانے کے خطرے کو کم کرنے کے لیے یہ خودکار طور پر دوبارہ جمع نہیں کراتا۔

نتائج اور حفاظتی جانچ

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

رن ٹائم ماحول اور پیشگی شرائط

پروجیکٹ درج ذیل ماحول کے لیے ہے:

• Windows x64

• Python 3.12

• Node.js

• native GUI آپریشنز کے لیے انٹرایکٹو ڈیسک ٹاپ

• Chrome راستہ استعمال کرنے کی صورت میں Codex میزبان کا فراہم کردہ مطابقت رکھنے والا سرکاری براؤزر سیشن API

پروجیکٹ کو C:\jev\jev-bridge میں انسٹال کرنے کی سفارش کی جاتی ہے۔ کچھ تاریخی کمانڈز اور Codex skill کی مثالیں بطورِ ڈیفالٹ اسی مقام کو استعمال کرتی ہیں۔ اگر کوئی دوسرا فولڈر منتخب کیا جائے تو متعلقہ مثالوں اور ترتیب کو بھی اسی کے مطابق تبدیل کرنا ہوگا۔

پروجیکٹ انسٹال کرنا

پہلا مرحلہ: repository کلون کریں اور virtual environment بنائیں

git clone https://github.com/YUTA-fywoo/jev-gui-delegate.git C:\jev\jev-bridge
cd C:\jev\jev-bridge
py -3.12 -m venv .venv

دوسرا مرحلہ: locked dependencies انسٹال کریں

.\.venv\Scripts\python.exe -m pip install --require-hashes -r requirements.lock

--require-hashes، lock فائل میں موجود hashes کی بنیاد پر dependencies انسٹال کرتا ہے، جس سے یہ یقینی بنانے میں مدد ملتی ہے کہ انسٹال کیا گیا مواد پروجیکٹ کے ریکارڈ سے مطابقت رکھتا ہے۔ Third-party dependencies کی directory repository کے ساتھ عوامی طور پر فراہم نہیں کی جاتی؛ انہیں اصل distribution channels سے انسٹال کیا جائے۔

تیسرا مرحلہ: runtime تیار کریں

.\.venv\Scripts\python.exe scripts/setup-runtime.py

چوتھا مرحلہ: offline tests چلائیں

.\.venv\Scripts\python.exe -m unittest discover -s gui_delegate/tests -p "test_*.py"

یہ tests کنٹرولر، بحالی کے عمل اور boundary conditions کا احاطہ کرتے ہیں۔ Offline regression synthetic data اور controlled substitutes استعمال کرتا ہے، حقیقی GUI آپریشن کے برابر نہیں ہے، اور نہ ہی حقیقی وقت کی Jev requests کا دعویٰ کرتا ہے۔ مزید مکمل نتائج کے لیے repository میں موجود release validation documentation دیکھیں۔

Jev key ترتیب دینا

Key مقامی environment variable TYPESAFE_API_KEY یا Windows Credential Manager کے ذریعے فراہم کی جا سکتی ہے۔ پروجیکٹ ترتیب دینے کے لیے set-key.cmd سے کھلنے والی مقامی input window استعمال کرنے کی سفارش کرتا ہے۔

set-key.cmd

Key کو Git repository، task contract یا chat content میں شامل نہ کریں۔ انسٹالر کی مشین پر تیار ہونے والی chrome-runtime.json کو ignore کیا گیا ہے؛ repository اصل مصنف کی مشین کے environment paths اپنے ساتھ نہیں لے جائے گی۔

Codex میں رجسٹر کرنا

جب پروجیکٹ کو Codex سے جوڑنا ہو تو پروجیکٹ directory میں درج ذیل installation scripts چلائیں:

install.cmd
gui-install.cmd

Installer صارف کی سطح کی MCP، skill اور routing configuration میں ترمیم کرتا ہے، ساتھ ہی backup محفوظ کرتا اور conflicts کی جانچ کرتا ہے۔ اگر مشین پر پہلے سے اسی نام کی directory موجود ہو تو پہلے اس کا مقصد چیک کریں؛ installer مقامی طور پر زیرِ استعمال پروجیکٹ کو براہِ راست overwrite نہیں کرے گا۔

انسٹال کیا جا سکنے والا ذاتی Codex skill gui_delegate/skill/SKILL.md میں موجود ہے۔ اگر پروجیکٹ default directory میں انسٹال نہ ہو تو اس میں موجود path سے متعلق مثالوں کو بھی چیک کرنا چاہیے۔

بنیادی استعمال اور تصدیق

مقامی readiness چیک کرنا

انسٹالیشن کے بعد یہ چلایا جا سکتا ہے:

health.cmd

health.cmd صرف یہ چیک کرتا ہے کہ components تیار ہیں یا نہیں؛ یہ حقیقی وقت کی Jev validation کے نفاذ کی نمائندگی نہیں کرتا، اور نہ ہی اس بات کی کہ موجودہ مشین حقیقی GUI scenarios کی acceptance سے گزر چکی ہے۔

حقیقی وقت کی validation چلانا

پروجیکٹ کی فراہم کردہ verify.cmd جیسی real-time validation workflows Jev service کو کال کرتی ہیں:

verify.cmd

چلانے سے پہلے تصدیق کریں کہ key درست طور پر ترتیب دی گئی ہے، اور offline regression کے نتائج کو real-time service کے نتائج سے الگ رکھیں۔ README تاریخی development environment میں موجود “مقامی طور پر verified” کو ایسا نتیجہ نہیں سمجھتی جسے ہر installer براہِ راست وراثت میں حاصل کر سکے۔

Delegation کے لیے موزوں task ڈیزائن کرنا

یہ پروٹوٹائپ واضح حدود، محدود کیے جا سکنے والے مراحل اور قابلِ جانچ نتائج والے GUI آپریشنز کے لیے موزوں ہے۔ کنٹرولر کو task دیتے وقت کم از کم درج ذیل چیزیں واضح ہونی چاہئیں:

• ہدف: آخر میں کون سی حالت حاصل کرنی ہے۔

• دائرہ کار: کن صفحات، ونڈوز یا objects کے اندر کارروائی کی اجازت ہے۔

• مجاز کارروائیاں: کنٹرولر کس قسم کے interactions انجام دے سکتا ہے۔

• ان پٹ: task کے نفاذ کے لیے ضروری اور استعمال کی اجازت رکھنے والا data۔

• مراحل: مسلسل انجام دیے جا سکنے والے operation stages۔

• کامیابی کی شرائط: تکمیل کے بعد کون سی حقیقی قدر یا صفحے کی حالت مشاہدے میں آنی چاہیے۔

مثلاً، ایک task کنٹرولر سے کہہ سکتا ہے کہ مخصوص page scope میں target control تلاش کرے، مجاز input درج کرے، اور page state کے ذریعے نتیجے کی تصدیق کرے۔ مخصوص contract fields اور result model کے لیے gui_delegate/schema.py میں موجود implementation کو معیار بنائیں؛ README میں غیر بیان کردہ format کا خود سے اندازہ نہ لگائیں۔

Source code پڑھنے کا راستہ

اگر نفاذ کے طریقہ کار کو سمجھنا یا مزید development کرنا ہو تو درج ذیل ترتیب سے پڑھا جا سکتا ہے:

1. gui_delegate/schema.py: task contract، state اور result model کو سمجھیں۔

2. gui_delegate/controller.py: دیکھیں کہ controller execution loop کو کیسے منظم کرتا ہے۔

3. gui_delegate/drivers.py: drivers اور structured interface observation کو سمجھیں۔

4. gui_delegate/security.py: scope، authorization اور input checks دیکھیں۔

5. gui_delegate/chrome_gateway.mjs: official browser session entry point کو سمجھیں۔

6. jev_client.py: Jev SDK wrapper، version check اور usage logging دیکھیں۔

7. gui_delegate/tests: tests کے ذریعے recovery logic اور boundary behavior سمجھیں۔

Advanced استعمال کی تجاویز

Deterministic matching کو ترجیح دیں

اگر کسی control کی شناخت stable attributes یا structured information کے ذریعے کی جا سکتی ہو تو اسے پہلے local code سے match کریں۔ Jev کو صرف معنوی فیصلے کی ضرورت پر کال کریں؛ یہ پروجیکٹ کے design کے مطابق بھی ہے اور model usage کو درست طور پر record کرنا بھی آسان بناتا ہے۔

ہر مرحلے کے لیے قابلِ مشاہدہ نتیجہ مقرر کریں

صرف “button پر click کریں” جیسی action متعین نہ کریں؛ click کے بعد متوقع value، control state یا page change بھی بیان کریں۔ پروجیکٹ حقیقی نتیجے کی تصدیق پر زور دیتا ہے، نہ کہ tool call کی کامیابی کو براہِ راست task کی کامیابی سمجھنے پر۔

Submission actions کو احتیاط سے سنبھالیں

اگر submission کے بعد نتیجہ واضح نہ ہو تو ناکامی فرض کر کے action خودکار طور پر دوبارہ نہ چلائیں۔ یہ پروجیکٹ نتیجہ غیر واضح ہونے پر submission کو خودکار طور پر replay کرنے سے واضح طور پر گریز کرتا ہے۔ ایسی حالت میں pause کرنا، progress محفوظ کرنا اور user یا main model سے تصدیق کرانا زیادہ مناسب ہے۔

Missing input اور selection error کو الگ سنبھالیں

ضروری input غائب ہو تو اسے مکمل کر کے جاری رکھیں؛ صرف مقامی semantic selection error کی صورت میں اسی selection کی اصلاح کریں۔ اس طرح task کو ابتدا سے دوبارہ چلانے سے بچا جا سکتا ہے اور پہلے سے verified progress بھی برقرار رہتی ہے۔

Jev version upgrade کے بعد دوبارہ validation کریں

موجودہ settings.json میں تاریخی tests میں استعمال ہونے والا jev-1.13.0 مقرر ہے۔ Server version تبدیل ہونے کے بعد دوبارہ verification کر کے configuration update کریں؛ پرانے version کے test results کو نئے version کی quality assurance نہ سمجھیں۔ مثال کی strategy بھی اس بات کی نمائندگی نہیں کرتی کہ موجودہ machine calibration مکمل کر چکی ہے۔

Benchmark tests کو درست طور پر سمجھیں

README میں 2026年 9月 23日 کو کیے گئے synthetic task tests کے دو rounds درج ہیں۔ ہر round میں وہی 4 tasks اور 24 actions شامل تھے، اور دونوں task groups نے 4/4 مکمل کیے۔

• پہلے round میں Astra token 2,266,693 سے کم ہو کر 236,295 رہ گیا، یعنی 89.6% کمی، جبکہ end-to-end task rate baseline کا 3.05 گنا تھا۔

• دوسرے round میں Astra token 2,256,091 سے کم ہو کر 192,752 رہ گیا، یعنی 91.5% کمی، جبکہ end-to-end task rate baseline کا 3.53 گنا تھا۔

یہاں Astra token میں cached input شامل ہے، جبکہ Jev کا اضافی usage الگ شمار کیا گیا ہے۔ دونوں rounds میں وہی چار tasks دہرائے گئے، اس لیے یہ آٹھ آزاد scenarios کی نمائندگی نہیں کرتے؛ یہ اعداد billing savings ratio بھی نہیں ہیں، اور نہ ہی یہ ثابت کرتے ہیں کہ ہر application، ہر task یا ہر deployment environment میں یکساں نتیجہ حاصل ہوگا۔ ابتدائی تین-task version کے non-cached token results میں بہتری نہیں آئی؛ تفصیلی scope کے لیے test documentation دیکھیں۔

معلوم حدود

• یہ پروٹوٹائپ readable DOM یا accessibility information پر منحصر ہے۔

• Canvas، image understanding، secure desktop اور بعض cross-framework controls کو براہِ راست handle کرنا ممکن نہ ہو۔

• میزبان کی جانب سے فراہم نہ کی گئی functionality کے لیے main model کی اضافی کارروائی درکار ہو سکتی ہے۔

• Chrome path مطابقت رکھنے والے host کے official session کے بغیر آزادانہ طور پر نہیں چل سکتا۔

• تاریخی machine validation records اس بات کے برابر نہیں کہ نیا installation environment acceptance سے گزر چکا ہے۔

• Runtime logs، browser configuration، keys، ذاتی task materials، machine installation state اور rollback package عوامی طور پر فراہم نہیں کیے گئے۔

خلاصہ

Jev GUI Delegate قابلِ قبولیت جانچ والے GUI آپریشنز کو main model کے مرحلہ وار loop سے الگ کرتا ہے، اور deterministic matching، ضرورت کے مطابق semantic selection، state validation اور fault recovery کو local controller کے ذریعے مکمل کرتا ہے۔ Installation کے وقت پہلے locked dependencies، runtime setup اور offline tests مکمل کریں، پھر key configure کر کے Codex سے integrate کریں۔ عملی استعمال میں واضح task scope، قابلِ مشاہدہ success conditions، submission recovery کی محتاط strategy اور version change کے بعد دوبارہ validation قابلِ اعتماد نتائج کے لیے بنیادی اہمیت رکھتے ہیں۔

اپ اسٹریم اجزا کے بارے میں مزید جاننے کے لیے TypeSafe دستاویزات، MCP Python SDK اور pywinauto ملاحظہ کریں۔