chore(i18n): refresh ar translations

docs/ar/concepts/qa-e2e-automation.md

@@ -1,32 +1,32 @@
 ---
 read_when:
     - توسيع qa-lab أو qa-channel
-    - إضافة سيناريوهات QA مدعومة من المستودع
-    - بناء أتمتة QA أكثر واقعية حول لوحة تحكم Gateway
-summary: شكل أتمتة QA الخاصة لـ qa-lab وqa-channel والسيناريوهات المُهيأة مسبقًا وتقارير البروتوكول
-title: أتمتة QA من طرف إلى طرف
+    - إضافة سيناريوهات ضمان جودة مدعومة بالمستودع
+    - بناء أتمتة ضمان جودة ذات واقعية أعلى حول لوحة معلومات Gateway
+summary: شكل أتمتة ضمان الجودة الخاص لـ qa-lab وqa-channel والسيناريوهات المُهيأة مسبقًا وتقارير البروتوكول
+title: أتمتة ضمان الجودة الشاملة E2E
 x-i18n:
-    generated_at: "2026-04-13T07:28:53Z"
+    generated_at: "2026-04-16T21:51:15Z"
     model: gpt-5.4
     provider: openai
-    source_hash: a4a4f5c765163565c95c2a071f201775fd9d8d60cad4ff25d71e4710559c1570
+    source_hash: 7deefda1c90a0d2e21e2155ffd8b585fb999e7416bdbaf0ff57eb33ccc063afc
     source_path: concepts/qa-e2e-automation.md
     workflow: 15
 ---
 
-# أتمتة QA من طرف إلى طرف
+# أتمتة ضمان الجودة الشاملة E2E
 
-تهدف حزمة QA الخاصة إلى اختبار OpenClaw بطريقة أكثر واقعية وبنيةً شبيهة بالقنوات مقارنةً بما يمكن أن يقدمه اختبار وحدات واحد.
+تهدف حزمة ضمان الجودة الخاصة إلى اختبار OpenClaw بطريقة أكثر واقعية وتشبه القنوات أكثر مما يمكن أن يقدمه اختبار وحدة واحد.
 
-المكوّنات الحالية:
+المكونات الحالية:
 
-- `extensions/qa-channel`: قناة رسائل اصطناعية بواجهات للرسائل الخاصة DM، والقنوات، والخيوط، والتفاعلات، والتحرير، والحذف.
-- `extensions/qa-lab`: واجهة مستخدم لتصحيح الأخطاء وناقل QA لمراقبة النصّ الحواري، وحقن الرسائل الواردة، وتصدير تقرير Markdown.
-- `qa/`: أصول تهيئة مدعومة من المستودع لمهمة البدء وسيناريوهات QA الأساسية.
+- `extensions/qa-channel`: قناة رسائل اصطناعية تتضمن أسطح الرسائل الخاصة DM، والقنوات، والخيوط، وردود الفعل، والتحرير، والحذف.
+- `extensions/qa-lab`: واجهة تصحيح وحافلة QA لمراقبة النص الحواري، وحقن الرسائل الواردة، وتصدير تقرير Markdown.
+- `qa/`: أصول تمهيدية مدعومة بالمستودع لمهمة الانطلاق وسيناريوهات QA الأساسية.
 
-تدفق عمل مشغّل QA الحالي هو موقع QA بلوحتين:
+مسار عمل مشغّل QA الحالي هو موقع QA ذو لوحتين:
 
-- اليسار: لوحة تحكم Gateway ‏(Control UI) مع الوكيل.
+- اليسار: لوحة معلومات Gateway ‏(Control UI) مع الوكيل.
 - اليمين: QA Lab، ويعرض النص الحواري الشبيه بـ Slack وخطة السيناريو.
 
 شغّله باستخدام:
@@ -35,9 +35,9 @@ x-i18n:
 pnpm qa:lab:up
 ```
 
-يؤدي ذلك إلى بناء موقع QA، وبدء مسار Gateway المعتمد على Docker، وإتاحة صفحة QA Lab حيث يمكن لمشغّل أو لحلقة أتمتة تكليف الوكيل بمهمة QA، ومراقبة سلوك القناة الحقيقي، وتسجيل ما نجح وما فشل وما بقي معطّلًا.
+يقوم ذلك ببناء موقع QA، وبدء مسار Gateway المدعوم بـ Docker، وإتاحة صفحة QA Lab حيث يمكن لمشغّل أو حلقة أتمتة إعطاء الوكيل مهمة QA، ومراقبة سلوك القناة الحقيقي، وتسجيل ما نجح وما فشل وما بقي معطّلًا.
 
-للتكرار الأسرع على واجهة مستخدم QA Lab بدون إعادة بناء صورة Docker في كل مرة، ابدأ الحزمة باستخدام حزمة QA Lab مربوطة بالتحميل:
+للحصول على تكرار أسرع في واجهة QA Lab دون إعادة بناء صورة Docker في كل مرة، ابدأ الحزمة باستخدام حزمة QA Lab مُركّبة عبر bind mount:
 
 ```bash
 pnpm openclaw qa docker-build-image
@@ -46,102 +46,102 @@ pnpm qa:lab:up:fast
 pnpm qa:lab:watch
 ```
 
-يحافظ `qa:lab:up:fast` على خدمات Docker على صورة مبنية مسبقًا ويربط تحميل `extensions/qa-lab/web/dist` داخل حاوية `qa-lab`. ويعيد `qa:lab:watch` بناء تلك الحزمة عند التغيير، ويُعاد تحميل المتصفح تلقائيًا عندما يتغير تجزئة أصول QA Lab.
+يحافظ `qa:lab:up:fast` على خدمات Docker على صورة مبنية مسبقًا ويقوم بتركيب `extensions/qa-lab/web/dist` داخل حاوية `qa-lab` عبر bind mount. ويعيد `qa:lab:watch` بناء تلك الحزمة عند التغيير، ويُعاد تحميل المتصفح تلقائيًا عند تغيّر قيمة hash لأصول QA Lab.
 
-لتشغيل مسار Matrix اختباري يعتمد نقلًا حقيقيًا، شغّل:
+لتشغيل مسار Matrix تجريبي واقعي من ناحية النقل، نفّذ:
 
 ```bash
 pnpm openclaw qa matrix
 ```
 
-يوفّر هذا المسار خادم Tuwunel منزليًا مؤقتًا في Docker، ويسجل مستخدمين مؤقتين للسائق وSUT والمراقب، وينشئ غرفة خاصة واحدة، ثم يشغّل Plugin Matrix الحقيقي داخل child خاص بـ QA gateway. ويحافظ مسار النقل الحي على إعدادات child محصورة ضمن النقل قيد الاختبار، لذلك يعمل Matrix من دون `qa-channel` في إعدادات child.
+يقوم هذا المسار بتوفير خادم Tuwunel منزلي مؤقت داخل Docker، ويسجّل مستخدمين مؤقتين للسائق وSUT والمراقب، وينشئ غرفة خاصة واحدة، ثم يشغّل Plugin الحقيقي الخاص بـ Matrix داخل عنصر فرعي QA gateway. يحافظ مسار النقل الحي على إعداد العنصر الفرعي محصورًا بالنقل قيد الاختبار، لذا يعمل Matrix بدون `qa-channel` في إعداد العنصر الفرعي. ويكتب عناصر التقرير المنظَّمة وسجلًا مدمجًا لـ stdout/stderr داخل دليل إخراج Matrix QA المحدد. لالتقاط مخرجات البناء/التشغيل الخاصة بـ `scripts/run-node.mjs` الخارجية أيضًا، اضبط `OPENCLAW_RUN_NODE_OUTPUT_LOG=<path>` إلى ملف سجل محلي في المستودع.
 
-لتشغيل مسار Telegram اختباري يعتمد نقلًا حقيقيًا، شغّل:
+لتشغيل مسار Telegram تجريبي واقعي من ناحية النقل، نفّذ:
 
 ```bash
 pnpm openclaw qa telegram
 ```
 
-يستهدف هذا المسار مجموعة Telegram خاصة حقيقية واحدة بدلًا من توفير خادم مؤقت. ويتطلب `OPENCLAW_QA_TELEGRAM_GROUP_ID` و`OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` و`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`، بالإضافة إلى روبوتين مختلفين داخل المجموعة الخاصة نفسها. يجب أن يمتلك روبوت SUT اسم مستخدم على Telegram، وتعمل المراقبة بين الروبوتات على أفضل نحو عندما يكون Bot-to-Bot Communication Mode مفعّلًا لكلا الروبوتين في `@BotFather`.
+يستهدف هذا المسار مجموعة Telegram خاصة حقيقية واحدة بدلًا من توفير خادم مؤقت. ويتطلب `OPENCLAW_QA_TELEGRAM_GROUP_ID` و`OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` و`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`، بالإضافة إلى روبوتين مختلفين داخل المجموعة الخاصة نفسها. يجب أن يمتلك روبوت SUT اسم مستخدم على Telegram، وتعمل المراقبة بين الروبوتات على أفضل وجه عندما يكون كلا الروبوتين قد فُعّل لهما Bot-to-Bot Communication Mode في `@BotFather`.
 
-تتشارك مسارات النقل الحية الآن عقدًا أصغر واحدًا بدلًا من أن يخترع كل منها شكل قائمة السيناريوهات الخاصة به:
+تشارك مسارات النقل الحي الآن عقدًا أصغر واحدًا بدلًا من أن يخترع كل منها شكل قائمة سيناريوهات خاصًا به:
 
-يبقى `qa-channel` مجموعة اختبار واسعة لسلوك المنتج الاصطناعي وليس جزءًا من مصفوفة تغطية النقل الحي.
+يبقى `qa-channel` مجموعة السلوكيات الاصطناعية الواسعة للمنتج وليس جزءًا من مصفوفة تغطية النقل الحي.
 
-| المسار | Canary | بوابة الإشارات Mention | حظر قائمة السماح | رد على المستوى الأعلى | استئناف بعد إعادة التشغيل | متابعة الخيط | عزل الخيط | مراقبة التفاعلات | أمر Help |
-| ------- | ------ | ---------------------- | ----------------- | ---------------------- | -------------------------- | ------------ | ---------- | ---------------- | -------- |
-| Matrix  | x      | x                      | x                 | x                      | x                          | x            | x          | x                |          |
-| Telegram | x      |                        |                   |                        |                            |              |            |                  | x        |
+| المسار     | Canary | تقييد الإشارة | حظر قائمة السماح | رد على المستوى الأعلى | استئناف بعد إعادة التشغيل | متابعة الخيط | عزل الخيط | مراقبة التفاعل | أمر المساعدة |
+| ---------- | ------ | -------------- | ----------------- | ---------------------- | -------------------------- | ------------- | ---------- | --------------- | ------------ |
+| Matrix     | x      | x              | x                 | x                      | x                          | x             | x          | x               |              |
+| Telegram   | x      |                |                   |                        |                            |               |            |                 | x            |
 
-يحافظ ذلك على `qa-channel` باعتباره مجموعة واسعة لسلوك المنتج، بينما تتشارك Matrix وTelegram ووسائل النقل الحية المستقبلية قائمة تحقق صريحة واحدة لعقد النقل.
+يُبقي ذلك `qa-channel` باعتباره مجموعة سلوكيات المنتج الواسعة، بينما تشارك Matrix وTelegram ووسائط النقل الحية المستقبلية قائمة تحقق صريحة واحدة لعقد النقل.
 
-لتشغيل مسار Linux VM مؤقت من دون إدخال Docker في مسار QA، شغّل:
+لتشغيل مسار Linux VM مؤقت دون إدخال Docker في مسار QA، نفّذ:
 
 ```bash
 pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
 ```
 
-يقوم هذا بتشغيل ضيف Multipass جديد، وتثبيت الاعتماديات، وبناء OpenClaw داخل الضيف، وتشغيل `qa suite`، ثم نسخ تقرير QA والملخص المعتادين مرة أخرى إلى `.artifacts/qa-e2e/...` على المضيف.
+يقوم هذا بتشغيل ضيف Multipass جديد، وتثبيت التبعيات، وبناء OpenClaw داخل الضيف، وتشغيل `qa suite`، ثم نسخ تقرير QA والملخّص المعتادين مرة أخرى إلى `.artifacts/qa-e2e/...` على المضيف.
 ويعيد استخدام سلوك اختيار السيناريو نفسه الذي يستخدمه `qa suite` على المضيف.
-تُنفَّذ عمليات suite على المضيف وMultipass لعدة سيناريوهات محددة بالتوازي مع عمال Gateway معزولين افتراضيًا، حتى 64 عاملًا أو عدد السيناريوهات المحددة. استخدم `--concurrency <count>` لضبط عدد العمال، أو `--concurrency 1` للتنفيذ التسلسلي.
-تعيد عمليات التشغيل الحية تمرير مدخلات مصادقة QA المدعومة والعملية للضيف: مفاتيح المزوّد المعتمدة على env، ومسار إعدادات موفّر QA الحي، و`CODEX_HOME` عند وجوده. أبقِ `--output-dir` تحت جذر المستودع حتى يتمكن الضيف من الكتابة مرة أخرى عبر مساحة العمل المركّبة.
+تنفّذ عمليات suite على المضيف وMultipass عدة سيناريوهات محددة بالتوازي مع عمّال gateway معزولين افتراضيًا، حتى 64 عاملًا أو بعدد السيناريوهات المحدد. استخدم `--concurrency <count>` لضبط عدد العمّال، أو `--concurrency 1` للتنفيذ التسلسلي.
+تقوم التشغيلات الحية بتمرير مدخلات مصادقة QA المدعومة والعملية للضيف: مفاتيح الموفّر المعتمدة على env، ومسار إعداد موفّر QA الحي، و`CODEX_HOME` عند وجوده. أبقِ `--output-dir` تحت جذر المستودع حتى يتمكن الضيف من الكتابة مرة أخرى عبر مساحة العمل المركّبة.
 
-## البذور المدعومة من المستودع
+## البذور المدعومة بالمستودع
 
-توجد أصول التهيئة في `qa/`:
+توجد الأصول التمهيدية في `qa/`:
 
 - `qa/scenarios/index.md`
 - `qa/scenarios/*.md`
 
-هذه الملفات موجودة عمدًا في git حتى تكون خطة QA مرئية لكل من البشر والوكيل.
+وهذه موجودة عمدًا في git بحيث تكون خطة QA مرئية للبشر وللوكيل معًا.
 
-يجب أن يبقى `qa-lab` مشغّل Markdown عامًا. يجب أن يكون كل ملف Markdown للسيناريو هو مصدر الحقيقة لتشغيل اختبار واحد، وأن يعرّف ما يلي:
+يجب أن يظل `qa-lab` مشغّل Markdown عامًا. كل ملف Markdown للسيناريو هو مصدر الحقيقة لتشغيل اختبار واحد، ويجب أن يعرّف:
 
-- بيانات السيناريو الوصفية
-- مراجع الوثائق والكود
-- متطلبات Plugin الاختيارية
-- تصحيح إعدادات Gateway اختياري
+- بيانات وصفية للسيناريو
+- مراجع الوثائق والشفرة
+- متطلبات Plugin اختيارية
+- تصحيح إعداد Gateway اختياري
 - `qa-flow` القابل للتنفيذ
 
-يُسمح لسطح وقت التشغيل القابل لإعادة الاستخدام الذي يدعم `qa-flow` بأن يبقى عامًا وعابرًا لعدة أجزاء. على سبيل المثال، يمكن لسيناريوهات Markdown أن تجمع بين مساعدات جهة النقل ومساعدات جهة المتصفح التي تقود Control UI المضمّن عبر واجهة Gateway ‏`browser.request` من دون إضافة مشغّل خاص بحالة معينة.
+يُسمح لسطح وقت التشغيل القابل لإعادة الاستخدام الذي يدعم `qa-flow` بأن يظل عامًا وعابرًا للجوانب. على سبيل المثال، يمكن لسيناريوهات Markdown أن تجمع بين مساعدات جانب النقل ومساعدات جانب المتصفح التي تقود Control UI المضمّنة عبر منفذ Gateway ‏`browser.request` دون إضافة مشغّل خاص بحالة معينة.
 
-يجب أن تبقى القائمة الأساسية واسعة بما يكفي لتغطية:
+يجب أن تظل القائمة الأساسية واسعة بما يكفي لتغطية:
 
 - محادثات DM والقنوات
 - سلوك الخيوط
 - دورة حياة إجراءات الرسائل
 - استدعاءات Cron
-- استدعاء الذاكرة
+- استرجاع الذاكرة
 - تبديل النماذج
-- تسليم الوكيل الفرعي
+- تسليم المهام إلى وكيل فرعي
 - قراءة المستودع وقراءة الوثائق
-- مهمة بناء صغيرة مثل Lobster Invaders
+- مهمة بناء صغيرة واحدة مثل Lobster Invaders
 
-## محولات النقل
+## محوّلات النقل
 
-يمتلك `qa-lab` واجهة نقل عامة لسيناريوهات QA المبنية على Markdown.
-ويُعد `qa-channel` أول محول على هذه الواجهة، لكن هدف التصميم أوسع: يجب أن تتصل القنوات الحقيقية أو الاصطناعية المستقبلية بالمشغّل نفسه للمجموعة بدلًا من إضافة مشغّل QA خاص بالنقل.
+يمتلك `qa-lab` منفذ نقل عامًا لسيناريوهات QA المعتمدة على Markdown.
+ويُعد `qa-channel` أول محوّل على هذا المنفذ، لكن الهدف التصميمي أوسع: يجب أن تندمج القنوات المستقبلية الحقيقية أو الاصطناعية في مشغّل suite نفسه بدلًا من إضافة مشغّل QA خاص بالنقل.
 
 على مستوى البنية، يكون التقسيم كما يلي:
 
-- يمتلك `qa-lab` التنفيذ العام للسيناريوهات، وتوازي العمال، وكتابة المخرجات، وإعداد التقارير.
-- يمتلك محول النقل إعدادات Gateway، والجاهزية، ومراقبة الوارد والصادر، وإجراءات النقل، وحالة النقل الموحّدة.
-- تحدد ملفات سيناريوهات Markdown تحت `qa/scenarios/` تشغيل الاختبار؛ ويوفّر `qa-lab` سطح وقت التشغيل القابل لإعادة الاستخدام الذي ينفذها.
+- يمتلك `qa-lab` تنفيذ السيناريو العام، وتوازي العمّال، وكتابة العناصر الناتجة، وإعداد التقارير.
+- يمتلك محوّل النقل إعداد Gateway، والجاهزية، ومراقبة الوارد والصادر، وإجراءات النقل، وحالة النقل الموحّدة.
+- تحدد ملفات سيناريو Markdown ضمن `qa/scenarios/` تشغيل الاختبار؛ ويقدّم `qa-lab` سطح وقت التشغيل القابل لإعادة الاستخدام الذي ينفّذها.
 
-توجد إرشادات الاعتماد الخاصة بالمشرفين لمحولات القنوات الجديدة في
-[Testing](/ar/help/testing#adding-a-channel-to-qa).
+توجد إرشادات الاعتماد الموجّهة للمشرفين لمحوّلات القنوات الجديدة في
+[الاختبار](/ar/help/testing#adding-a-channel-to-qa).
 
 ## إعداد التقارير
 
-يُصدّر `qa-lab` تقرير بروتوكول بصيغة Markdown من الخط الزمني لناقل الأحداث المرصود.
+يصدّر `qa-lab` تقرير بروتوكول Markdown من المخطط الزمني للحافلة المرصودة.
 ويجب أن يجيب التقرير عن:
 
 - ما الذي نجح
 - ما الذي فشل
 - ما الذي بقي معطّلًا
-- ما سيناريوهات المتابعة الجديرة بالإضافة
+- ما سيناريوهات المتابعة التي تستحق الإضافة
 
-لإجراء فحوصات الطابع والأسلوب، شغّل السيناريو نفسه عبر عدة مراجع نماذج حية واكتب تقرير Markdown مُقيّمًا:
+لإجراء فحوصات الشخصية والأسلوب، شغّل السيناريو نفسه عبر عدة مراجع نماذج حية واكتب تقرير Markdown مُحكَّمًا:
 
 ```bash
 pnpm openclaw qa character-eval \
@@ -160,21 +160,22 @@ pnpm openclaw qa character-eval \
   --judge-concurrency 16
 ```
 
-يشغّل هذا الأمر عمليات child محلية لـ QA gateway، وليس Docker. يجب أن تضبط سيناريوهات تقييم الطابع الشخصية عبر `SOUL.md`، ثم تشغّل أدوار مستخدم عادية مثل الدردشة، والمساعدة في مساحة العمل، ومهام الملفات الصغيرة. يجب ألا يُخبَر النموذج المرشح بأنه قيد التقييم. يحتفظ الأمر بكل نص حواري كامل، ويسجّل إحصاءات تشغيل أساسية، ثم يطلب من نماذج التحكيم في وضع fast مع استدلال `xhigh` ترتيب التشغيلات بحسب الطبيعية والأجواء والفكاهة.
-استخدم `--blind-judge-models` عند المقارنة بين المزوّدين: ستظل مطالبة التحكيم تتلقى كل نص حواري وحالة تشغيل، لكن تُستبدل مراجع المرشحين بتسميات محايدة مثل `candidate-01`؛ ويعيد التقرير ربط التصنيفات بالمراجع الحقيقية بعد التحليل.
-تستخدم تشغيلات المرشحين افتراضيًا مستوى تفكير `high`، مع `xhigh` لنماذج OpenAI التي تدعمه. يمكنك تجاوز مرشح محدد مباشرةً باستخدام
-`--model provider/model,thinking=<level>`. وما يزال `--thinking <level>` يضبط قيمة احتياطية عامة، كما جرى الإبقاء على الصيغة الأقدم `--model-thinking <provider/model=level>` للتوافق.
-تستخدم مراجع المرشحين من OpenAI وضع fast افتراضيًا حتى تُستخدم المعالجة ذات الأولوية حيث يدعمها المزوّد. أضف `,fast` أو `,no-fast` أو `,fast=false` مباشرةً عندما يحتاج مرشح واحد أو حكم واحد إلى تجاوز. مرّر `--fast` فقط عندما تريد فرض وضع fast على كل نموذج مرشح. تُسجَّل مدد المرشحين والحكام في التقرير لتحليل المقاييس، لكن مطالبات التحكيم تنص صراحةً على عدم الترتيب بحسب السرعة.
-تستخدم كل من تشغيلات نماذج المرشحين والحكام توازيًا افتراضيًا مقداره 16. خفّض
-`--concurrency` أو `--judge-concurrency` عندما تجعل حدود المزوّد أو ضغط Gateway المحلي التشغيل شديد الضوضاء.
-عند عدم تمرير أي مرشح `--model`، يستخدم تقييم الطابع افتراضيًا
-`openai/gpt-5.4` و`openai/gpt-5.2` و`openai/gpt-5` و`anthropic/claude-opus-4-6` و`anthropic/claude-sonnet-4-6` و`zai/glm-5.1` و`moonshot/kimi-k2.5` و`google/gemini-3.1-pro-preview` عندما لا يتم تمرير `--model`.
-وعند عدم تمرير أي `--judge-model`، تكون النماذج الحَكَم الافتراضية هي
+يقوم هذا الأمر بتشغيل عمليات فرعية محلية لـ QA gateway، وليس Docker. يجب أن تضبط سيناريوهات تقييم الشخصية الـ persona عبر `SOUL.md`، ثم تشغّل أدوار مستخدم عادية مثل الدردشة، والمساعدة في مساحة العمل، والمهام الصغيرة المتعلقة بالملفات. يجب ألا يُخبَر النموذج المرشح بأنه قيد التقييم. يحافظ الأمر على كل نص حواري كامل، ويسجل إحصاءات التشغيل الأساسية، ثم يطلب من نماذج التحكيم في الوضع السريع مع استدلال `xhigh` ترتيب التشغيلات بحسب الطبيعية والطابع والفكاهة.
+استخدم `--blind-judge-models` عند المقارنة بين الموفّرين: سيظل موجّه التحكيم يحصل على كل نص حواري وحالة تشغيل، لكن تُستبدل مراجع المرشحين بتسميات محايدة مثل `candidate-01`؛ ثم يربط التقرير التصنيفات مرة أخرى بالمراجع الحقيقية بعد التحليل.
+تستخدم تشغيلات المرشحين افتراضيًا مستوى تفكير `high`، مع `xhigh` لنماذج OpenAI التي تدعمه. يمكنك تجاوز مرشح محدد مباشرة باستخدام
+`--model provider/model,thinking=<level>`. ولا يزال `--thinking <level>` يضبط قيمة احتياطية عامة، كما يُحتفظ بالصيغة الأقدم `--model-thinking <provider/model=level>` من أجل التوافق.
+تستخدم مراجع مرشحي OpenAI الوضع السريع افتراضيًا بحيث تُستخدم المعالجة ذات الأولوية عندما يدعمها الموفّر. أضف `,fast` أو `,no-fast` أو `,fast=false` مباشرة عندما يحتاج مرشح واحد أو حكم واحد إلى تجاوز. مرّر `--fast` فقط عندما تريد فرض تفعيل الوضع السريع لكل نموذج مرشح. تُسجَّل مدد المرشحين والحكام في التقرير لتحليل القياس المعياري، لكن موجّهات التحكيم تنص صراحة على عدم الترتيب بحسب السرعة.
+تستخدم تشغيلات نماذج المرشحين والحكام افتراضيًا توازيًا بمقدار 16. خفّض
+`--concurrency` أو `--judge-concurrency` عندما تجعل حدود الموفّر أو ضغط Gateway المحلي التشغيل مشوشًا أكثر من اللازم.
+عند عدم تمرير أي `--model` للمرشحين، يستخدم تقييم الشخصية افتراضيًا
+`openai/gpt-5.4` و`openai/gpt-5.2` و`openai/gpt-5` و`anthropic/claude-opus-4-6` و`anthropic/claude-sonnet-4-6` و`zai/glm-5.1` و`moonshot/kimi-k2.5` و
+`google/gemini-3.1-pro-preview` عند عدم تمرير `--model`.
+وعند عدم تمرير أي `--judge-model`، يستخدم الحكام افتراضيًا
 `openai/gpt-5.4,thinking=xhigh,fast` و
 `anthropic/claude-opus-4-6,thinking=high`.
 
-## وثائق ذات صلة
+## الوثائق ذات الصلة
 
-- [Testing](/ar/help/testing)
+- [الاختبار](/ar/help/testing)
 - [QA Channel](/ar/channels/qa-channel)
-- [Dashboard](/web/dashboard)
+- [لوحة المعلومات](/web/dashboard)