Browser MCP • Chromium مدمج • QA يقوده وكيل

وكلاؤك يقودون متصفحًا حقيقيًا.
ليس متصفحًا مزيفًا.

يدمج AgentsRoom متصفح Chromium حقيقيًا في كل مشروع، ويأتي بخادم AgentsRoom Browser MCP يتيح لوكلاء الذكاء الاصطناعي التحكم به. يفتح وكيل QA لديك موقع localhost، ينقر الأزرار، يملأ النماذج، يلتقط لقطات شاشة، يقرأ الـ console، ويتحقق من أن الميزة تعمل فعلًا قبل أن يقول 'تم'. أتمتة متصفح end-to-end لـ Claude Code وCodex وOpenCode وGemini CLI وAider، بصفر إعداد لـ Playwright.

اقرنه مع Agent Teams: وكيل Dev يشحن الميزة، وكيل QA يحمّل موقع localhost في المتصفح المدمج، يشغّل سيناريو التحقق، يلتقط لقطة شاشة للنتيجة، ويعتمد. أتمتة المتصفح الأصلية أيضًا على خارطة الطريق، مع خوادم MCP مستقبلية مخططة لتطبيقات React Native وElectron حتى يتمكن الوكلاء من اختبار تطبيقات الجوال وسطح المكتب كذلك.

عرض AgentsRoom Browser MCP: اختبار تطبيق ويب end-to-end يقوده وكيل QA من Claude Code عبر متصفح Chromium المدمج.

Browser Automation في AgentsRoom شيئان في واحد. أولًا، متصفح Chromium حقيقي مدمج في كل غرفة مشروع، مع شريط URL، وأزرار للأمام/للخلف، وإعادة تحميل، وتاريخ، ولقطة شاشة إلى الحافظة، وفتح في المتصفح الافتراضي، وكوكيز و localStorage مستمرة لكل مشروع. ثانيًا، خادم AgentsRoom Browser MCP (agentsroom-browser) الذي يكشف ذلك المتصفح لوكلاء الذكاء الاصطناعي عبر Model Context Protocol. يحصل الوكيل على واجهة نظيفة قابلة للبرمجة: navigate، click، type، screenshot، تنفيذ JavaScript، الانتظار لظهور عنصر، الحصول على حالة الصفحة، الحصول على سجلات الـ console، الرجوع، التقدم، إعادة التحميل.

لماذا يهم هذا؟ لأن الوعد الكامل لوكلاء البرمجة بالذكاء الاصطناعي ينهار عندما يقول الوكيل 'تم شحن الميزة' لكنه لم يفتح الصفحة للتحقق أبدًا. معظم الوكلاء اليوم يعتمدون على تشغيل اختبارات الوحدة، ثم يأملون. مع Browser MCP حقيقي، يحمّل الوكيل خادم localhost، يمارس تدفق المستخدم، يرى ما يراه المستخدم البشري، وعندها فقط يعتمد. أخيرًا، يحصل دور وكيل QA Engineer على الأدوات التي يحتاجها لإجراء QA حقيقي، وليس مجرد تحليل ثابت.

الإعداد التقني غير مرئي لك. عند تفعيل 'Browser access' على وكيل، يدمج AgentsRoom إدخال agentsroom-browser في .mcp.json الخاص بمشروعك، ويُقلِع الوكيل بأدوات المتصفح متاحة. جسر WebSocket يعمل على منفذ loopback (127.0.0.1، يحدده نظام التشغيل، يُعاد توليده عند كل إقلاع، يُصادَق برمز سداسي عشري بحجم 32 بايت) يربط عملية MCP الفرعية بـ Chromium WebContentsView في تطبيق Electron. كل نقرة وكتابة ولقطة شاشة هي استدعاء JSON-RPC. يرى الوكيل متصفحًا حقيقيًا، لا stub.

متصفح Chromium المدمج في AgentsRoom: شريط URL، أزرار التنقل، التاريخ، التقاط لقطة شاشة، ووكلاء الذكاء الاصطناعي يقودون المتصفح عبر خادم AgentsRoom Browser MCP

لوحة AgentsRoom Browser: شريط URL، تاريخ، لقطة شاشة، وسطح تحكم MCP كامل لوكلاء الذكاء الاصطناعي للتنقل والنقر والكتابة والتحقق.

متصفح حقيقي، لا stub لـ Playwright

معظم عروض وكلاء الذكاء الاصطناعي التي تتحدث عن أتمتة المتصفح تستخدم Playwright في وضع headless يُطلق عند كل استدعاء أداة. ينجح ذلك في المعايير لكنه مؤلم في الواقع: لا يمكنك رؤية ما يفعله الوكيل، كل تنقل يعيد إطلاق Chromium، الكوكيز تُفقد، localStorage فارغ، خادم التطوير لديك يعتقد أن كل زيارة جلسة جديدة تمامًا. يأخذ AgentsRoom زاوية مختلفة. المتصفح مفتوح بالفعل في غرفة مشروعك (تستخدمه أنت كمتصفح عادي)، والوكيل يقود ذلك المتصفح. الجلسات والكوكيز و localStorage وحالة تسجيل الدخول، كلها محفوظة.

كل نقرة وكتابة من الوكيل تُطلق إرسالًا أصليًا حقيقيًا عبر WebContentsView في Electron، مع أحداث مفاتيح وأحداث ماوس وتحولات DOM صحيحة. لقطات الشاشة هي PNGs حقيقية ملتقطة من الصفحة المعروضة فعليًا (ليست خدعة DOM-to-image). سجلات الـ console مخزّنة وقابلة للاستعلام، بما في ذلك التحذيرات والأخطاء. يرى الوكيل نفس ما تراه أنت لو فتحت DevTools: أداء حقيقي، سلوك شبكة حقيقي، CORS حقيقي، مصادقة حقيقية.

يُفرض عزل عبر الغرف. ينشئ AgentsRoom WebContentsView واحد لـ Chromium لكل مشروع، مع قسم جلسة خاص به (persist:agentsroom-browser-<projectId>). كوكيز المشروع A لا تتسرب أبدًا إلى المشروع B. عند تبديل المشروع، يُخفى المتصفح السابق ويأتي الجديد عبر الإنترنت بحالته الخاصة. يصل الوكيل دائمًا إلى المشروع الصحيح، بالاعتمادات الصحيحة.

طبقة MCP صغيرة عمدًا وبدون تبعيات. عملية browser-mcp-server.cjs الفرعية تتحدث ببروتوكول MCP 2024-11-05 عبر stdio (initialize، tools/list، tools/call) وتُترجمه إلى استدعاءات JSON-RPC عبر جسر WebSocket على loopback. مقارنة بخادم ثقيل قائم على SDK، يبقى هذا سريعًا (الاستدعاء الأول للأداة دون 100 مللي ثانية) وسهل التصحيح. بعد كل إجراء يُغيّر الصفحة (click، type، navigate، reload، back، forward)، تتضمن الاستجابة لقطة شاشة PNG بترميز base64 محدودة بـ 1.6 ميغابايت ليرى الوكيل دائمًا نتيجة ما فعله للتو. تبيّن أن هذا أكبر فوز لموثوقية واحد: الوكلاء الذين يرون الشاشة يفعلون الصواب أكثر بكثير من الوكلاء الذين يأملون.

مجموعة أدوات Browser MCP التي يحصل عليها وكلاؤك

كل وكيل ذكاء اصطناعي مع وصول للمتصفح يُقلع بهذه الأدوات متاحة. تُكشف عبر MCP القياسي، فأي CLI متوافق يراها: Claude Code وCodex CLI وOpenCode وGemini CLI وAider.

browser_navigate

افتح URL في المتصفح المدمج. معالجة ذكية للـ URL: localhost:3000 يصبح http://localhost:3000 بدلًا من إطلاق نافذة 'لا يمكن فتح التطبيق'. يُعيد URL النهائي ولقطة شاشة للصفحة بعد التحميل.

browser_click

انقر على عنصر بواسطة selector أو بنص مرئي. حدث نقر أصلي حقيقي، ليس JavaScript dispatch. يُعيد لقطة شاشة بعد النقر ليرى الوكيل نتيجة فعله.

browser_type

اكتب نصًا في input أو textarea. يدعم اختصارات لوحة المفاتيح والإرسال. أحداث مفاتيح حقيقية، معالجات onChange الخاصة بالصفحة تنطلق. يُعيد لقطة شاشة بعد الكتابة.

browser_screenshot

التقط الـ viewport الحالي كـ PNG. مفيد لفحوصات regression المرئية، QA التصميم، مقارنات قبل وبعد، أو مشاركة حالة خطأ مع بقية الفريق.

browser_evaluate

شغّل تعبير JavaScript في العالم الرئيسي للصفحة. احصل على النتيجة المتسلسلة. يستخدمه الوكلاء لقراءة حالة الصفحة، الاستعلام عن DOM، فحص متجر Redux، أو إطلاق إجراء ليس له زر مرئي.

browser_wait_for

انتظر ظهور عنصر، تغيّر URL، انتهاء طلب شبكة، أو إرجاع JavaScript عشوائي true. يتجنب الكلاسيكي 'الوكيل ينقر بسرعة كبيرة'.

browser_get_state

اقرأ الـ URL الحالي، العنوان، الـ viewport، موقع التمرير، ولقطة منظمة لعناصر الصفحة القابلة للوصول. الإدخال الأساسي للوكيل عندما يحتاج تخطيط فعله التالي.

browser_get_logs

اسحب مخزن الـ console (log، warn، error). يستطيع الوكيل رؤية نفس تحذيرات React وأخطاء hydration وفشل الشبكة واستثناءات وقت التشغيل التي ستراها أنت في DevTools. تقارير الأخطاء تصبح 'إليك الخطأ من الـ console'.

browser_go_back / forward / reload

تنقل متصفح قياسي، قابل للبرمجة. يستخدمه الوكلاء للتراجع عندما يسوء تدفق، أو لإعادة اختبار صفحة بعد hot reload من Vite أو Next.js أو Expo Metro.

ما يفعله الوكلاء فعلًا بالمتصفح

سير عمل حقيقي يمكنك بناؤه اليوم، مع دور QA Engineer وAgent Teams.

اختبار smoke end-to-end على كل تسليم

اربط فريق Dev إلى QA. يتنقل وكيل QA إلى خادم التطوير على localhost، ينقر عبر المسارات الحرجة (التسجيل، الدفع، لوحة التحكم)، يلتقط لقطة شاشة للنتيجة، ويعتمد فقط إذا لم يُلقَ شيء. التقط الانحدارات قبل أن يفتح إنسان الصفحة.

QA regression مرئي

لقطات شاشة قبل وبعد على تغييرات الواجهة. يحمّل الوكيل الصفحة على الالتزام السابق، يلتقط لقطة، يبدّل الفرع، يلتقط لقطة، يطلب من Claude المقارنة. QA diff مرئي رخيص بدون Percy أو Chromatic في الحلقة.

صيد أخطاء الـ console

يتنقل الوكيل في التطبيق، يستدعي browser_get_logs، يجد تحذيرات hydration من React وتحذيرات useEffect وأخطاء 404 على الشبكة وأخطاء CORS وإشعارات إيقاف الاستخدام. يُبلغ عنها كقائمة مخاطر في حمولة تسليم الفريق، يصلحها وكيل Dev التالي.

اختبار التحقق من النموذج

يملأ الوكيل النموذج ببيانات صالحة، بحقول فارغة، بحالات حافة (سلاسل XSS، إدخالات طويلة جدًا، non-ASCII). يتحقق من رسائل التحقق، طلبات الشبكة، التحويلات. QA حقيقي للنموذج، ليس اختبارات وحدة.

تدقيق إمكانية الوصول

يمشي الوكيل الصفحة، يستعلم عن شجرة إمكانية الوصول عبر browser_get_state وbrowser_evaluate، يفحص نصوص alt وسمات ARIA وإدارة التركيز والتنقل بلوحة المفاتيح. يُبلغ عن المشاكل بلقطات شاشة.

QA تصميم مقابل Figma

ادمج مع ميزة Figma to AI agents. يحمّل الوكيل إطار Figma، يلتقط لقطة، يحمّل صفحة localhost، يلتقط لقطة، يقارن المسافات والخطوط والألوان والمحاذاة. يقدّم قائمة عدم تطابق.

التحقق من نفق المعاينة المباشرة

اقرنه مع AgentsRoom localhost tunnel. يتنقل الوكيل إلى URL HTTPS العام للمعاينة (ليس localhost)، يتحقق من إمكانية الوصول إلى الموقع من العالم الخارجي، يلتقط لقطة، ويؤكد أن صاحب المصلحة يستطيع فعلًا فتح الرابط.

إعادة إنتاج خطأ عميل من تذكرة backlog عامة

تذكرة backlog عامة تأتي مع URL وخطوات لإعادة الإنتاج. يفتح وكيل QA الـ URL، يتبع الخطوات، يلتقط خطأ الـ console، يرفق لقطة شاشة، يسلّم إلى Dev بإعادة إنتاج نظيفة. لا مزيد من حلقات 'لا يمكنني إعادة الإنتاج'.

كيف يحصل وكيل على متصفح

01

افتح علامة تبويب Browser في غرفتك

في غرفة مشروعك، تكشف اللوحة اليمنى ثلاث علامات تبويب: Files وChanges وBrowser. انقر على Browser. تتسع اللوحة، ينطوي الشريط الجانبي، وتظهر طريقة عرض Chromium حقيقية. اكتب URL أو اختر من تاريخ المشروع.

02

فعّل 'Browser access' على الوكيل

افتح Edit Agent modal، وسّع Capabilities، فعّل Browser access. يدمج AgentsRoom إدخال agentsroom-browser في .mcp.json الخاص بمشروعك وسيرى الوكيل أدوات المتصفح في البدء التالي.

<project>/.mcp.json
03

يُقلع الوكيل بـ Browser MCP

عند إطلاق الوكيل، يقوم Claude (أو Codex أو Gemini، إلخ) بتهيئة خادم agentsroom-browser MCP، يسرد أدواته (browser_navigate، browser_click، browser_type، browser_screenshot، browser_evaluate، browser_wait_for، browser_get_state، browser_get_logs، browser_go_back، browser_go_forward، browser_reload)، ومن الآن فصاعدًا يستطيع قيادة المتصفح.

04

الوكيل يستخدم المتصفح

يتنقل الوكيل، ينقر، يكتب، يلتقط لقطات شاشة، يقرأ الـ console. كل إجراء يمر عبر جسر WebSocket على loopback (127.0.0.1، منفذ يحدده نظام التشغيل، رمز سداسي عشري بحجم 32 بايت، يُعاد توليده عند كل إقلاع لتطبيق سطح المكتب). بعد كل إجراء يُغيّر الصفحة، تُعاد لقطة شاشة inline ليتحقق الوكيل بصريًا من حركته.

05

استهداف تلقائي لـ localhost أو نفقك

إذا كان نفق localhost يعمل، يصل التنقل الأول إلى URL النفق. وإلا، أول خادم تطوير مكتشف. وإلا، https://localhost:3000. مدمجًا مع Dev Terminals، يبدأ الوكيل حرفيًا خادم التطوير، ثم يفتحه في المتصفح، ثم يختبره.

06

تحقّق، التقط لقطة، سلّم

عند الربط في Agent Teams، تشغّل عقدة QA سيناريوهاتها، تلتقط لقطات شاشة، تضبط flags.qaPassed في حمولة التسليم. يرث الوكيل التالي الحكم. النجاح يذهب إلى PM، الفشل يعود إلى Dev مع تلميحات الاختبار.

تحت الغطاء

للفضوليين. مكدس أتمتة المتصفح صغير عمدًا.

كل مشروع لديه Chromium WebContentsView واحد (واجهة Electron الحديثة، ليس BrowserView المهجور)، تُعرض فوق النافذة الرئيسية بحدود تُبثّ من React renderer. قسم جلسة لكل مشروع يبقي الكوكيز و localStorage والمصادقة معزولة بين المشاريع. حدود offscreen افتراضية تتيح للوكلاء استدعاء أدوات المتصفح حتى قبل أن يفتح الإنسان علامة تبويب Browser، مع timeout 5 ثوانٍ على لقطات الشاشة لتجنب التعليق.

خادم WebSocket خفيف (browser-bridge.ts) يعمل على منفذ loopback يختاره نظام التشغيل، مرتبط بـ 127.0.0.1 فقط. تستخدم المصادقة رمزًا سداسيًا عشريًا بحجم 32 بايت يُعاد توليده عند كل إقلاع لسطح المكتب. ملف الجسر ~/.agentsroom/browser-bridge.json يحمل المنفذ الحالي والرمز وPID، ويُعاد كتابته ذرّيًا عند كل إقلاع، فتلتقط عملية MCP الفرعية دائمًا اعتمادات جديدة مع إعادة محاولة تلقائية.

خادم MCP نفسه هو browser-mcp-server.cjs، نص Node بصفر تبعيات يطبّق بروتوكول MCP 2024-11-05 عبر stdio (initialize، tools/list، tools/call). يتحدث JSON-RPC إلى جسر WebSocket عبر عميل WebSocket مكتوب يدويًا (لا ws، لا @modelcontextprotocol/sdk). صغير وسريع وسهل التدقيق. مُحزّم كملف extraResources في تطبيق سطح المكتب، فكل تثبيت يُشحن وهو جاهز.

دعم المتصفح الأصلي (ميزة متصفح من الدرجة الأولى وراء MCP) على خارطة طريق AgentsRoom. وراء ذلك، تتضمن الخطة طويلة الأجل MCPs إضافية حتى يستطيع الوكلاء قيادة أهداف غير الويب: React Native MCP لتطبيقات الجوال وElectron MCP لتطبيقات سطح المكتب. الفكرة نفسها، التجربة نفسها: لا يكتب الوكيل الكود فقط، بل يمارس فعلًا التطبيق قيد التشغيل.

Shipping
Browser MCP for web apps
Roadmap
React Native MCP for mobile apps
Roadmap
Electron MCP for desktop apps
Loopback only
Bridge bound to 127.0.0.1, OS-assigned port, 32-byte hex token regenerated at every boot.
Per-project session
Cookies, localStorage and auth isolated by partition. Project A never sees project B's session.
Auditable tools
Every action goes through a small, dependency-free MCP server. Easy to read, easy to audit.

FAQ

كيف يختلف هذا عن Playwright MCP أو أدوات المتصفح المعتمدة على Puppeteer؟

MCPs المعتمدة على Playwright وPuppeteer تُطلق متصفحًا headless جديدًا في كل جلسة. هذا جيد للمهام بدون حالة، لكنه يفقد الكوكيز و localStorage والمصادقة بين الاستدعاءات، ولا يستطيع الإنسان رؤية ما يفعله الوكيل. AgentsRoom Browser هو نفس المتصفح الذي يستخدمه الإنسان داخل التطبيق، بجلسة مستمرة لكل مشروع، مرئية للمستخدم في الوقت الفعلي. يقود الوكيل نافذة تستطيع رؤيتها وتجاوزها في أي وقت. إنها أتمتة متصفح أكثر صدقًا وأسهل تصحيحًا.

هل يعمل هذا مع جميع مزوّدي الذكاء الاصطناعي، أم فقط Claude Code؟

يعمل مع كل مزوّد يدعمه AgentsRoom: Claude Code وCodex CLI وOpenCode وGemini CLI وAider. تُكشف أدوات المتصفح عبر Model Context Protocol القياسي، الذي تقرأه كل هذه الـ CLIs من .mcp.json. لا يعرف الوكيل أبدًا أنه في AgentsRoom، يرى فقط مجموعة أدوات MCP ويستخدمها كما يستخدم أي أداة أخرى.

هل يستطيع الوكيل قيادة موقع بعيد، أم فقط localhost؟

كلاهما. اكتب أي URL واذهب. localhost (وأشكال host:port) تُكتشف بذكاء، تُسبق بـ http://، وتُفتح مباشرة. المواقع العامة تعمل كما في أي متصفح عادي، مع كوكيز وحالة تسجيل الدخول محفوظة لكل مشروع. مدمجًا مع AgentsRoom localhost tunnel، يستطيع الوكيل أيضًا قيادة خادم التطوير المحلي عبر URL HTTPS عام، وهو مفيد لـ QA عبر الشبكات والجوال.

هل Browser MCP آمن؟ ما الذي يمنع إساءة استخدامه؟

الجسر يرتبط بـ 127.0.0.1 فقط، أبدًا بـ 0.0.0.0. المنفذ يحدده نظام التشغيل (لا منفذ ثابت لمسح عرضة للتصادم). رمز سداسي عشري بحجم 32 بايت مطلوب على كل اتصال، يُعاد توليده عند كل إقلاع لسطح المكتب. تتلقى عملية MCP الفرعية الاعتمادات فقط عبر متغيرات البيئة، أبدًا في أي ملف ملتزَم. الوصول للمتصفح اختياري لكل وكيل في Edit Agent modal. إذا أزلته، يُزال إدخال .mcp.json ولا يستطيع الوكيل استخدام الأدوات بعد ذلك.

هل يرى الوكيل console المتصفح (الأخطاء، التحذيرات، الشبكة)؟

نعم، عبر browser_get_logs. المخزن يحمل رسائل console.log وconsole.warn وconsole.error من العالم الرئيسي للصفحة. كثير من الأخطاء الحقيقية (أخطاء hydration في React، تحذيرات useEffect، فشل CORS) تظهر فقط في الـ console، أبدًا في اختبارات الوحدة، فيتبيّن أن هذه واحدة من أعلى الأدوات إشارة لوكيل QA.

ماذا يحدث للقطات الشاشة المُعادة إلى الوكيل؟ هل تكلّف الكثير من التوكنز؟

بعد كل إجراء يُغيّر الصفحة، تُلحق لقطة شاشة PNG بترميز base64 باستجابة الأداة، محدودة بـ 1.6 ميغابايت. فوق ذلك، يُرسل علامة نصية بدلًا من ذلك. لقطات الشاشة حاسمة للموثوقية (وكيل يرى الشاشة يرتكب أخطاء أقل بكثير)، فالمقايضة تستحق. إذا أردت تعطيل لقطات الشاشة لأسباب الميزانية، استدعاءات browser_evaluate العادية تُعيد نصًا فقط.

هل يستطيع الوكيل ملء نموذج تسجيل دخول؟ الاحتفاظ بجلسته؟

نعم. الكوكيز و localStorage تُحفظ لكل مشروع تحت قسم الجلسة persist:agentsroom-browser-<projectId>. يستطيع الوكيل تسجيل الدخول مرة واحدة بـ browser_type وbrowser_click، والبقاء مسجلًا الدخول عبر بقية التشغيل. عند تبديل المشروع، تتغير الجلسة، فالاعتمادات لا تتسرب أبدًا عبر المشاريع.

هل سينكسر الوكيل إذا لم يكن خادم التطوير قيد التشغيل؟

سيتنقل إلى الـ URL ويرى صفحة خطأ Chromium. يستطيع قراءة هذا الخطأ عبر browser_get_state وbrowser_get_logs والتفاعل وفقًا لذلك: يطلب منك بدء الخادم، أو يستدعي أمر Dev Terminals لبدئه. مع Agent Teams وDev Terminals، تستطيع ربط سير عمل يبدأ الخادم، ينتظر، ثم يفتح المتصفح، كل ذلك بدون تدخل بشري.

هل تطبيقات الجوال وسطح المكتب مدعومة أيضًا؟

الويب يُشحن اليوم، عبر Chromium المدمج وAgentsRoom Browser MCP. خارطة الطريق تتضمن AgentsRoom Browser الأصلي كميزة متصفح من الدرجة الأولى. وراء ذلك، خوادم MCP إضافية مخططة: React Native MCP حتى يستطيع الوكلاء قيادة حزم iOS وAndroid Expo، وElectron MCP حتى يستطيع الوكلاء قيادة تطبيقات سطح المكتب التي ليست ويب. نفس منطق الوكيل، مطبقًا على أهداف غير الويب.

هل يستطيع الإنسان إيقاف الوكيل وتولّي المتصفح؟

نعم. المتصفح هو نفس عرض Chromium الذي يستخدمه الإنسان. في أي لحظة، انقر في لوحة Browser وستكون أنت المتحكم. بمجرد أن تتوقف عن التفاعل، يستطيع الوكيل استئناف استدعاءات أدواته. لا يوجد مفهوم 'متصفح مقفل للوكيل'، إنه سطح مشترك، تمامًا مثل جلسة pair-programming.

امنح وكلاءك عينَي متصفح حقيقيتين

فعّل Browser access على أي وكيل في AgentsRoom. يُقلع Browser MCP تلقائيًا. أخيرًا يختبر وكيل QA لديك ما يشحن.

مجانيتحميل AgentsRoom

التطبيق المرافق: تابع وكلاءك أينما كنت

يعمل مع Claude و Codex و OpenCode و Gemini CLI و Aider

تثبيت الملحق
Chrome Web Store

أرسل الأخطاء والطلبات مباشرة إلى قائمة المهام العامة.

مشاريع متعددة
متعدد المزوّدين
وكلاء متعددون
حالة مباشرة
فرق الملفات والإيداع
تطبيق الهاتف
معاينة مباشرة
فرق الوكلاء
أتمتة المتصفح
تطوير موجّه بالـ backlog