extensions/qa-channel: قناة رسائل اصطناعية تتضمن أسطح الرسائل الخاصة، والقنوات، والسلاسل، والتفاعلات، والتعديل، والحذف.extensions/qa-lab: واجهة مصحح أخطاء وناقل QA لمراقبة النص المنسوخ، وحقن الرسائل الواردة، وتصدير تقرير Markdown.extensions/qa-matrix، وPlugins تشغيل مستقبلية: محولات نقل حية تشغّل قناة حقيقية داخل QA gateway فرعي.qa/: أصول تأسيسية مدعومة من المستودع لمهمة البدء وسيناريوهات QA الأساسية.- Mantis: تحقق حي قبل وبعد للأخطاء التي تحتاج إلى وسائل نقل حقيقية، ولقطات شاشة للمتصفح، وحالة VM، وأدلة PR.
سطح الأوامر
يعمل كل تدفق QA تحتpnpm openclaw qa <subcommand>. لدى الكثير منها أسماء مستعارة
للسكربتات بصيغة pnpm qa:*؛ كلا الشكلين مدعومان.
| الأمر | الغرض |
|---|---|
qa run | فحص QA ذاتي مضمّن بدون --qa-profile؛ مشغّل ملف نضج مدعوم بالتصنيف باستخدام --qa-profile smoke-ci، أو --qa-profile release، أو --qa-profile all. |
qa suite | تشغيل السيناريوهات المدعومة من المستودع على مسار QA gateway. الأسماء المستعارة: pnpm openclaw qa suite --runner multipass لاستخدام Linux VM مؤقت. |
qa coverage | طباعة مخزون تغطية سيناريوهات YAML (--json للمخرجات الآلية). |
qa parity-report | مقارنة ملفي qa-suite-summary.json وكتابة تقرير التكافؤ الوكيلي، أو استخدام --runtime-axis --token-efficiency لكتابة تقارير تكافؤ وقت تشغيل Codex مقابل OpenClaw وكفاءة الرموز من ملخص زوج وقت تشغيل واحد. |
qa character-eval | تشغيل سيناريو QA الخاص بالشخصية عبر عدة نماذج حية مع تقرير محكّم. راجع إعداد التقارير. |
qa manual | تشغيل مطالبة لمرة واحدة على مسار المزوّد/النموذج المحدد. |
qa ui | بدء واجهة مصحح QA وناقل QA المحلي (الاسم المستعار: pnpm qa:lab:ui). |
qa docker-build-image | بناء صورة QA Docker المجهزة مسبقًا. |
qa docker-scaffold | كتابة هيكل docker-compose للوحة معلومات QA + مسار Gateway. |
qa up | بناء موقع QA، وبدء الحزمة المدعومة بـ Docker، وطباعة عنوان URL (الاسم المستعار: pnpm qa:lab:up؛ يضيف متغير :fast الخيار --use-prebuilt-image --bind-ui-dist --skip-ui-build). |
qa aimock | بدء خادم مزوّد AIMock فقط. |
qa mock-openai | بدء خادم مزوّد mock-openai الواعي بالسيناريوهات فقط. |
qa credentials doctor / add / list / remove | إدارة مجموعة بيانات اعتماد Convex المشتركة. |
qa matrix | مسار نقل حي ضد خادم Tuwunel homeserver مؤقت. راجع Matrix QA. |
qa telegram | مسار نقل حي ضد مجموعة Telegram خاصة حقيقية. |
qa discord | مسار نقل حي ضد قناة خادم Discord خاصة حقيقية. |
qa slack | مسار نقل حي ضد قناة Slack خاصة حقيقية. |
qa whatsapp | مسار نقل حي ضد حسابات WhatsApp Web حقيقية. |
qa mantis | مشغّل تحقق قبل وبعد لأخطاء النقل الحي، مع أدلة تفاعلات حالة Discord، واختبار Crabbox لسطح المكتب/المتصفح، واختبار Slack داخل VNC. راجع Mantis ودليل تشغيل Mantis Slack Desktop. |
qa run المدعوم بملف تعريف العضوية من taxonomy.yaml، ثم يرسل
السيناريوهات المحلولة عبر qa suite. يقوم --surface و
--category بتصفية ملف التعريف المحدد بدلًا من تعريف مسارات منفصلة.
يتضمن ملف qa-evidence.json الناتج ملخص بطاقة تقييم ملف التعريف مع
أعداد الفئات المحددة ومعرفات التغطية المفقودة؛ وتظل إدخالات الأدلة
الفردية مصدر الحقيقة للاختبارات، وأدوار التغطية، والنتائج.
معرفات تغطية ميزات التصنيف هي أهداف إثبات دقيقة، وليست أسماء مستعارة. تحقق
تغطية السيناريو الأساسية المعرفات المطابقة؛ وتبقى التغطية الثانوية إرشادية.
تستخدم معرفات التغطية صيغة namespace.behavior المنقطة مع مقاطع
أبجدية رقمية/شرطات صغيرة؛ وقد تستمر معرفات ملف التعريف والسطح والفئة في استخدام
معرفات التصنيف الحالية ذات الشرطات أو النقاط.
تحذف الأدلة المختصرة execution لكل إدخال وتعيّن evidenceMode: "slim"؛
ويستخدم smoke-ci الوضع المختصر افتراضيًا، بينما يعيد --evidence-mode full الإدخالات الكاملة:
smoke-ci لإثبات ملف تعريف حتمي مع مزودي نماذج وهميين وخوادم
مزود Crabline محلية. استخدم release لإثبات Stable/LTS ضد قنوات حية.
استخدم all فقط لتشغيلات أدلة التصنيف الكامل الصريحة؛ فهو يحدد
كل فئة نضج نشطة ويمكن إرساله عبر سير عمل QA Profile Evidence باستخدام qa_profile=all. عندما يحتاج أمر أيضًا إلى ملف تعريف جذر OpenClaw،
ضع ملف تعريف الجذر قبل أمر QA:
تدفق المشغّل
تدفق مشغّل QA الحالي هو موقع QA بلوحتين:- اليسار: لوحة معلومات Gateway (Control UI) مع الوكيل.
- اليمين: QA Lab، يعرض النص المنسوخ الشبيه بـ Slack وخطة السيناريو.
qa:lab:up:fast خدمات Docker على صورة مجهزة مسبقًا ويركب بالربط
extensions/qa-lab/web/dist داخل حاوية qa-lab. يعيد qa:lab:watch
بناء تلك الحزمة عند التغيير، ويعيد المتصفح التحميل تلقائيًا عندما يتغير
هاش أصول QA Lab.
لاختبار إشارة OpenTelemetry محلي، شغّل:
otel-trace-smoke مع تمكين Plugin diagnostics-otel، ثم يتحقق من أن المسارات،
والمقاييس، والسجلات قد صُدّرت. يفك ترميز مقاطع تتبع protobuf المصدّرة
ويتحقق من الشكل الحرج للإصدار:
يجب أن تكون openclaw.run، وopenclaw.harness.run، ومقطع استدعاء نموذج
وفق أحدث اصطلاح دلالي GenAI، وopenclaw.context.assembled، وopenclaw.message.delivery
موجودة. يفرض الاختبار
OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental، لذلك يجب أن يستخدم مقطع استدعاء النموذج
اسم {gen_ai.operation.name} {gen_ai.request.model}؛
يجب ألا تصدّر استدعاءات النموذج StreamAbandoned في الدورات الناجحة؛ ويجب أن تبقى معرفات التشخيص الخام
وسمات openclaw.content.* خارج التتبع. يجب ألا تحتوي حمولات OTLP الخام
على حارس المطالبة، أو حارس الاستجابة، أو مفتاح جلسة QA.
يكتب otel-smoke-summary.json بجانب آثار حزمة QA.
لاختبار OpenTelemetry مدعوم بالمجمّع، شغّل:
docker-prometheus-smoke مع تمكين
diagnostics-prometheus، ويتحقق من رفض عمليات الكشط غير المصادق عليها،
ثم يتحقق من أن الكشط المصادق عليه يتضمن عائلات المقاييس الحرجة للإصدار
من دون محتوى المطالبات، أو محتوى الاستجابات، أو معرّفات التشخيص الخام، أو رموز
المصادقة، أو المسارات المحلية.
لتشغيل اختباري الدخان الخاصين بقابلية الملاحظة بالتتابع، استخدم:
qa.
استخدم pnpm qa:otel:smoke أو pnpm qa:prometheus:smoke أو
pnpm qa:observability:smoke من نسخة مصدرية مبنية عند تغيير أدوات
التشخيص.
لمسار دخان Matrix يستخدم نقلًا حقيقيًا ولا يتطلب بيانات اعتماد موفّر النماذج،
شغّل ملف التعريف السريع مع موفّر OpenAI الوهمي الحتمي:
qa-channel)، ثم يكتب تقرير Markdown وملخص JSON ومصنوع أحداث مرصودة وسجل خرج مدمج تحت .artifacts/qa-e2e/matrix-<timestamp>/.
تغطي السيناريوهات سلوك النقل الذي لا تستطيع اختبارات الوحدة إثباته من البداية إلى النهاية: بوابة الإشارات، وسياسات السماح للبوتات، وقوائم السماح، والردود في المستوى الأعلى والردود المتفرعة، وتوجيه الرسائل المباشرة، ومعالجة التفاعلات، وكبت التعديلات الواردة، وإزالة تكرار إعادة التشغيل عند الاستئناف، والتعافي من انقطاع الخادم المنزلي، وتسليم بيانات تعريف الموافقة، ومعالجة الوسائط، وتدفقات تمهيد/استرداد/تحقق E2EE في Matrix. كما يقود ملف تعريف CLI الخاص بـ E2EE أوامر openclaw matrix encryption setup والتحقق عبر الخادم المنزلي المؤقت نفسه قبل فحص ردود Gateway.
لدى Discord أيضًا سيناريوهات اختيارية خاصة بـ Mantis لإعادة إنتاج الأخطاء. استخدم
--scenario discord-status-reactions-tool-only للمخطط الزمني الصريح لتفاعل الحالة،
أو --scenario discord-thread-reply-filepath-attachment لإنشاء سلسلة Discord
حقيقية والتحقق من أن message.thread-reply يحافظ على مرفق
filePath. تبقى هذه السيناريوهات خارج مسار Discord الحي الافتراضي
لأنها مجسات إعادة إنتاج قبل/بعد وليست تغطية دخان واسعة.
يمكن لسير عمل مرفق السلسلة في Mantis أيضًا إضافة فيديو شاهد Discord Web
مسجّل الدخول عند تكوين MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR أو
MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64 في بيئة QA.
ملف تعريف العارض هذا مخصص للالتقاط المرئي فقط؛ ما زال قرار النجاح/الفشل
يأتي من عرّاف Discord REST.
يستخدم CI سطح الأوامر نفسه في .github/workflows/qa-live-transports-convex.yml.
تشغّل عمليات التشغيل المجدولة واليدوية الافتراضية ملف تعريف Matrix السريع مع
بيانات اعتماد live-frontier المقدمة من QA، و--fast، و
OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000. يؤدي التشغيل اليدوي matrix_profile=all
إلى التفرع إلى خمس شظايا لملفات التعريف.
لمسارات دخان Telegram وDiscord وSlack وWhatsApp ذات النقل الحقيقي:
slack-qa/ وslack-desktop-smoke.png وslack-desktop-smoke.mp4
عندما يكون التقاط الفيديو متاحًا إلى دليل مصنوعات Mantis. توفر إيجارات
سطح المكتب/المتصفح من Crabbox أدوات الالتقاط وحزم مساعد المتصفح/البناء الأصلي
مسبقًا، لذلك ينبغي للسيناريو تثبيت البدائل فقط على الإيجارات الأقدم.
يبلّغ Mantis عن التوقيتات الإجمالية وتوقيتات كل مرحلة في
mantis-slack-desktop-smoke-report.md حتى توضّح عمليات التشغيل البطيئة ما إذا كان الوقت
ذهب إلى إحماء الإيجار، أو الحصول على بيانات الاعتماد، أو الإعداد البعيد، أو نسخ المصنوعات.
أعد استخدام --lease-id <cbx_...> بعد تسجيل الدخول إلى Slack Web يدويًا عبر VNC؛
تحافظ الإيجارات المعاد استخدامها أيضًا على سخونة ذاكرة تخزين pnpm في Crabbox. يتحقق الوضع الافتراضي
--hydrate-mode source من نسخة مصدرية مستخرجة ويشغّل التثبيت/البناء
داخل VM. استخدم --hydrate-mode prehydrated فقط عندما تحتوي مساحة العمل البعيدة المعاد استخدامها
بالفعل على node_modules وdist/ مبني؛ يتخطى ذلك الوضع خطوة
التثبيت/البناء المكلفة ويفشل مغلقًا عندما لا تكون مساحة العمل جاهزة.
مع --gateway-setup، يترك Mantis Gateway دائمًا لـ OpenClaw Slack
قيد التشغيل داخل VM على المنفذ 38973؛ وبدونه، يشغّل الأمر مسار QA الطبيعي
من بوت إلى بوت في Slack ويخرج بعد التقاط المصنوعات.
لإثبات واجهة موافقة Slack الأصلية مع دليل سطح مكتب، شغّل وضع نقاط تحقق الموافقة
في Mantis:
--gateway-setup. يشغّل سيناريوهات موافقة Slack،
ويرفض معرّفات السيناريوهات غير الخاصة بالموافقة، وينتظر عند كل حالة موافقة معلّقة
ومحلولة، ويعرض رسالة Slack API المرصودة إلى
approval-checkpoints/<scenario>-pending.png و
approval-checkpoints/<scenario>-resolved.png، ثم يفشل إذا كانت أي نقطة تحقق،
أو دليل رسالة، أو إقرار، أو لقطة شاشة معروضة مفقودة أو فارغة.
قد تظل إيجارات CI الباردة تعرض تسجيل الدخول إلى Slack في slack-desktop-smoke.png؛
صور نقاط تحقق الموافقة هي الدليل المرئي لهذا المسار.
تعيش قائمة تحقق المشغّل، وأمر إطلاق سير عمل GitHub، وعقد تعليق الأدلة،
وجدول قرار وضع الإرواء، وتفسير التوقيت، وخطوات معالجة الفشل في دليل تشغيل Mantis لسطح مكتب Slack.
لمهمة سطح مكتب بأسلوب وكيل/CV، شغّل:
visual-task أو يعيد استخدام جهاز سطح مكتب/متصفح من Crabbox، ويبدأ
crabbox record --while، ويقود المتصفح المرئي عبر
visual-driver متداخل، ويلتقط visual-task.png، ويشغّل openclaw infer image describe
على لقطة الشاشة عند تحديد --vision-mode image-describe، ويكتب
visual-task.mp4 وmantis-visual-task-summary.json و
mantis-visual-task-driver-result.json وmantis-visual-task-report.md.
عند ضبط --expect-text، تطلب مطالبة الرؤية حكم JSON منظمًا
ولا تنجح إلا عندما يبلّغ النموذج عن دليل مرئي إيجابي؛ تفشل الاستجابة السلبية
التي تقتبس النص المستهدف فقط في التأكيد.
استخدم --vision-mode metadata لدخان بلا نموذج يثبت وصلات سطح المكتب
والمتصفح ولقطة الشاشة والفيديو من دون استدعاء موفّر فهم صور.
التسجيل مصنوع مطلوب لـ visual-task؛ إذا لم يسجّل Crabbox ملف
visual-task.mp4 غير فارغ، تفشل المهمة حتى إذا نجح برنامج التشغيل المرئي.
عند الفشل، يحتفظ Mantis بالإيجار لـ VNC ما لم تكن المهمة قد نجحت بالفعل
ولم يتم ضبط --keep-lease.
قبل استخدام بيانات اعتماد حية مجمّعة، شغّل:
تغطية النقل الحي
تشترك مسارات النقل الحي في عقد واحد بدل أن يخترع كل منها شكل قائمة سيناريوهات خاصًا به.qa-channel هي حزمة سلوك المنتج الاصطناعية الواسعة وليست جزءًا من مصفوفة تغطية النقل الحي.
ينبغي لمشغلات النقل الحي استيراد معرّفات السيناريوهات المشتركة، ومساعدات
تغطية الأساس، ومساعد اختيار السيناريو من
openclaw/plugin-sdk/qa-live-transport-scenarios.
| المسار | الكناري | بوابة الإشارات | بوت إلى بوت | حظر قائمة السماح | رد في المستوى الأعلى | رد مقتبس | استئناف إعادة التشغيل | متابعة السلسلة | عزل السلسلة | مراقبة التفاعلات | أمر المساعدة | تسجيل أمر أصلي |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Matrix | x | x | x | x | x | x | x | x | x | |||
| Telegram | x | x | x | x | ||||||||
| Discord | x | x | x | x | ||||||||
| Slack | x | x | x | x | x | x | x | x | ||||
| x | x | x | x | x | x | x | x |
qa-channel كحزمة سلوك المنتج الواسعة، بينما تشترك Matrix
وTelegram ووسائل النقل الحية الأخرى في قائمة تحقق صريحة لعقد النقل.
لمسار VM Linux مؤقت من دون إدخال Docker في مسار QA، شغّل:
qa suite، ثم ينسخ تقرير QA الطبيعي والملخص
إلى .artifacts/qa-e2e/... على المضيف.
يعيد استخدام سلوك اختيار السيناريو نفسه الذي يستخدمه qa suite على المضيف.
تنفّذ عمليات تشغيل الحزمة على المضيف وMultipass سيناريوهات محددة متعددة بالتوازي
مع عمال Gateway معزولين افتراضيًا. يستخدم qa-channel قيمة تزامن افتراضية
4، محددة بعدد السيناريوهات المختارة. استخدم --concurrency <count> لضبط
عدد العمال، أو --concurrency 1 للتنفيذ التسلسلي.
استخدم --pack personal-agent لتشغيل حزمة معيار المساعد الشخصي. محدد
الحزمة إضافي مع أعلام --scenario المتكررة: تعمل السيناريوهات الصريحة
أولًا، ثم تعمل سيناريوهات الحزمة بترتيب الحزمة مع إزالة التكرارات.
استخدم --pack observability عندما يوفّر مشغل QA مخصص بالفعل إعداد
مجمّع OpenTelemetry ويريد اختيار سيناريوهات دخان تشخيصات OpenTelemetry وPrometheus
معًا.
يخرج الأمر برمز غير صفري عند فشل أي سيناريو. استخدم --allow-failures عندما
تريد المصنوعات من دون رمز خروج فاشل.
تمرر عمليات التشغيل الحية مدخلات مصادقة QA المدعومة والعملية للضيف:
مفاتيح الموفّر المستندة إلى البيئة، ومسار تكوين موفّر QA الحي، و
CODEX_HOME عند وجوده. أبقِ --output-dir تحت جذر المستودع حتى يستطيع الضيف
الكتابة مرة أخرى عبر مساحة العمل المركّبة.
مرجع ضمان الجودة لـ Telegram وDiscord وSlack وWhatsApp
لدى Matrix صفحة مخصصة بسبب عدد سيناريوهاته وتجهيز خادم homeserver المدعوم بـ Docker. يعمل Telegram وDiscord وSlack وWhatsApp على وسائل نقل حقيقية موجودة مسبقًا، لذلك يوجد مرجعها هنا.أعلام CLI المشتركة
تُسجَّل هذه المسارات عبرextensions/qa-lab/src/live-transports/shared/live-transport-cli.ts وتقبل الأعلام نفسها:
| العلم | الافتراضي | الوصف |
|---|---|---|
--scenario <id> | - | شغّل هذا السيناريو فقط. قابل للتكرار. |
--output-dir <path> | <repo>/.artifacts/qa-e2e/<transport>-<timestamp> | المكان الذي تُكتب فيه التقارير والملخصات والأدلة والآثار الخاصة بوسيلة النقل وسجل الإخراج. تُحل المسارات النسبية مقابل --repo-root. |
--repo-root <path> | process.cwd() | جذر المستودع عند الاستدعاء من cwd محايد. |
--sut-account <id> | sut | معرّف حساب مؤقت داخل إعدادات Gateway لضمان الجودة. |
--provider-mode <mode> | live-frontier | mock-openai أو live-frontier (ما زال live-openai القديم يعمل). |
--model <ref> / --alt-model <ref> | افتراضي المزوّد | مراجع النموذج الأساسي/البديل. |
--fast | متوقف | وضع المزوّد السريع عند دعمه. |
--credential-source <env|convex> | env | راجع مجموعة بيانات اعتماد Convex. |
--credential-role <maintainer|ci> | ci في CI، وmaintainer خلاف ذلك | الدور المستخدم عند --credential-source convex. |
--allow-failures الآثار من دون تعيين رمز خروج فاشل.
ضمان جودة Telegram
@BotFather.
متغيرات البيئة المطلوبة عند --credential-source env:
OPENCLAW_QA_TELEGRAM_GROUP_ID- معرّف محادثة رقمي (سلسلة).OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKENOPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN
extensions/qa-lab/src/live-transports/telegram/telegram-live.runtime.ts):
telegram-canarytelegram-mention-gatingtelegram-mentioned-message-replytelegram-help-commandtelegram-commands-commandtelegram-tools-compact-commandtelegram-whoami-commandtelegram-status-commandtelegram-repeated-command-authorizationtelegram-other-bot-command-gatingtelegram-context-commandtelegram-current-session-status-tooltelegram-reply-chain-exact-markertelegram-stream-final-single-messagetelegram-long-final-reuses-previewtelegram-long-final-three-chunks
mock-openai أيضًا فحوصات حتمية لسلسلة الردود وبث الرسالة النهائية. يبقى telegram-current-session-status-tool اختياريًا لأنه مستقر فقط عند تشغيله في سلسلة مباشرة بعد canary، وليس بعد ردود أوامر أصلية عشوائية. استخدم pnpm openclaw qa telegram --list-scenarios --provider-mode mock-openai لطباعة التقسيم الحالي بين الافتراضي والاختياري مع مراجع الانحدار.
آثار الإخراج:
telegram-qa-report.mdqa-evidence.json- إدخالات أدلة لفحوصات النقل الحية، بما في ذلك حقول الملف الشخصي والتغطية والمزوّد والقناة والآثار والنتيجة وRTT.
qa-evidence.json ضمن result.timing لفحص RTT
المحدد.
OPENCLAW_QA_CREDENTIAL_SOURCE=convex، يستأجر مغلّف الحزمة الحية
بيان اعتماد kind: "telegram"، ويصدّر متغيرات بيئة المجموعة/السائق/بوت SUT
المستأجرة إلى تشغيل الحزمة المثبتة، ويرسل Heartbeat للتأجير، ويحرره عند
الإيقاف. يضبط مغلّف الحزمة افتراضيًا 20 فحص RTT لـ
telegram-mentioned-message-reply، ومهلة RTT قدرها 30s، ودور Convex
maintainer خارج CI عند اختيار Convex. تجاوز
OPENCLAW_NPM_TELEGRAM_RTT_SAMPLES أو OPENCLAW_NPM_TELEGRAM_RTT_TIMEOUT_MS
أو OPENCLAW_NPM_TELEGRAM_RTT_MAX_FAILURES لضبط قياس RTT من دون
إنشاء أمر RTT منفصل أو تنسيق ملخص خاص بـ Telegram.
ضمان جودة Discord
/help الأصلي لدى Discord، ومن سيناريوهات أدلة Mantis الاختيارية.
متغيرات البيئة المطلوبة عند --credential-source env:
OPENCLAW_QA_DISCORD_GUILD_IDOPENCLAW_QA_DISCORD_CHANNEL_IDOPENCLAW_QA_DISCORD_DRIVER_BOT_TOKENOPENCLAW_QA_DISCORD_SUT_BOT_TOKENOPENCLAW_QA_DISCORD_SUT_APPLICATION_ID- يجب أن يطابق معرّف مستخدم بوت SUT المُعاد من Discord (وإلا يفشل المسار سريعًا).
OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1يبقي نصوص الرسائل في آثار الرسائل المرصودة.OPENCLAW_QA_DISCORD_VOICE_CHANNEL_IDيحدد قناة الصوت/المنصة لـdiscord-voice-autojoin؛ وبدونه يختار السيناريو أول قناة صوت/منصة مرئية لبوت SUT.
extensions/qa-lab/src/live-transports/discord/discord-live.runtime.ts:36):
discord-canarydiscord-mention-gatingdiscord-native-help-command-registrationdiscord-voice-autojoin- سيناريو صوت اختياري. يعمل بمفرده، ويفعّلchannels.discord.voice.autoJoin، ويتحقق من أن حالة الصوت الحالية لبوت SUT في Discord هي قناة الصوت/المنصة الهدف. قد تتضمن بيانات اعتماد Discord في Convex قيمةvoiceChannelIdاختيارية؛ وإلا يكتشف المشغّل أول قناة صوت/منصة مرئية في Guild.discord-status-reactions-tool-only- سيناريو Mantis اختياري. يعمل بمفرده لأنه يبدّل SUT إلى ردود Guild دائمة التشغيل ومعتمدة على الأدوات فقط معmessages.statusReactions.enabled=true، ثم يلتقط خطًا زمنيًا للتفاعلات عبر REST إضافة إلى آثار مرئية HTML/PNG. كما تحفظ تقارير Mantis قبل/بعد آثار MP4 المقدمة من السيناريو باسمbaseline.mp4وcandidate.mp4.
discord-qa-report.mdqa-evidence.json- إدخالات أدلة لفحوصات النقل الحية.discord-qa-observed-messages.json- تُنقّح النصوص ما لم يكنOPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1.discord-qa-reaction-timelines.jsonوdiscord-status-reactions-tool-only-timeline.pngعند تشغيل سيناريو تفاعلات الحالة.
ضمان جودة Slack
--credential-source env:
OPENCLAW_QA_SLACK_CHANNEL_IDOPENCLAW_QA_SLACK_DRIVER_BOT_TOKENOPENCLAW_QA_SLACK_SUT_BOT_TOKENOPENCLAW_QA_SLACK_SUT_APP_TOKEN
OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1يبقي نصوص الرسائل في آثار الرسائل المرصودة.OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIRيفعّل نقاط تحقق الموافقة المرئية لـ Mantis. يكتب المشغّل<scenario>.pending.jsonو<scenario>.resolved.json، ثم ينتظر ملفات.ack.jsonالمطابقة.OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_TIMEOUT_MSيتجاوز مهلة إقرار نقطة التحقق. الافتراضي هو120000.
extensions/qa-lab/src/live-transports/slack/slack-live.runtime.ts):
slack-canaryslack-mention-gatingslack-allowlist-blockslack-top-level-reply-shapeslack-restart-resumeslack-thread-follow-upslack-thread-isolationslack-approval-exec-native- سيناريو موافقة exec أصلية اختياري في Slack. يطلب موافقة exec عبر Gateway، ويتحقق من أن رسالة Slack تحتوي على أزرار موافقة أصلية، ويحلّها، ثم يتحقق من تحديث Slack المحلول.slack-approval-plugin-native- سيناريو موافقة Plugin أصلية اختياري في Slack. يفعّل تمرير موافقات exec وPlugin معًا حتى لا تُكبت أحداث Plugin بواسطة توجيه موافقة exec، ثم يتحقق من مسار واجهة Slack الأصلية نفسه في حالتي الانتظار والحل.
slack-qa-report.mdqa-evidence.json- إدخالات أدلة لفحوصات النقل الحية.slack-qa-observed-messages.json- تُنقّح النصوص ما لم يكنOPENCLAW_QA_SLACK_CAPTURE_CONTENT=1.approval-checkpoints/- فقط عندما يعيّن MantisOPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR؛ يحتوي على JSON لنقطة التحقق، وJSON للإقرار، ولقطات شاشة للحالتين المعلقة/المحلولة.
إعداد مساحة عمل Slack
يحتاج المسار إلى تطبيقين مميزين في Slack داخل مساحة عمل واحدة، إضافة إلى قناة يكون كلا البوتين عضوين فيها:channelId- معرّفCxxxxxxxxxxلقناة دُعي إليها كلا البوتين. استخدم قناة مخصصة؛ ينشر المسار في كل تشغيل.driverBotToken- رمز بوت (xoxb-...) لتطبيق Driver.sutBotToken- رمز بوت (xoxb-...) لتطبيق SUT، ويجب أن يكون تطبيق Slack منفصلًا عن السائق حتى يكون معرّف مستخدم البوت الخاص به مميزًا.sutAppToken- رمز على مستوى التطبيق (xapp-...) لتطبيق SUT معconnections:write، يستخدمه Socket Mode كي يتمكن تطبيق SUT من تلقي الأحداث.
extensions/slack/src/setup-shared.ts:10) إلى الأذونات والأحداث التي تغطيها مجموعة ضمان جودة Slack الحية. لإعداد قناة الإنتاج كما يراه المستخدمون، راجع الإعداد السريع لقناة Slack؛ زوج QA Driver/SUT منفصل عمدًا لأن المسار يحتاج إلى معرّفي مستخدم بوت مميزين داخل مساحة عمل واحدة.
1. أنشئ تطبيق Driver
انتقل إلى api.slack.com/apps → إنشاء تطبيق جديد → من بيان → اختر مساحة عمل QA، والصق البيان الآتي، ثم التثبيت في مساحة العمل:
xoxb-...) - وسيصبح ذلك driverBotToken. لا يحتاج المشغّل إلا إلى نشر الرسائل والتعرّف إلى نفسه؛ لا أحداث، ولا Socket Mode.
2. أنشئ تطبيق SUT
كرّر إنشاء تطبيق جديد → من بيان في مساحة العمل نفسها. يستخدم تطبيق QA هذا عمدًا نسخة أضيق من بيان الإنتاج الخاص بـ Slack plugin المضمّن (extensions/slack/src/setup-shared.ts:10): تم حذف نطاقات التفاعلات والأحداث لأن مجموعة اختبارات Slack QA الحية لا تغطي معالجة التفاعلات بعد.
- التثبيت في مساحة العمل → انسخ Bot User OAuth Token → وسيصبح ذلك
sutBotToken. - المعلومات الأساسية → رموز مستوى التطبيق → توليد الرمز والنطاقات → أضف النطاق
connections:write→ احفظ → انسخ قيمةxapp-...→ وسيصبح ذلكsutAppToken.
auth.test على كل رمز. يميّز وقت التشغيل بين المشغّل وSUT بواسطة معرّف المستخدم؛ ستفشل إعادة استخدام تطبيق واحد لكليهما في بوابة الإشارات فورًا.
3. أنشئ القناة
في مساحة عمل QA، أنشئ قناة (مثلًا #openclaw-qa) وادعُ الروبوتين كليهما من داخل القناة:
Cxxxxxxxxxx من معلومات القناة → حول → معرّف القناة - وسيصبح ذلك channelId. تعمل القناة العامة؛ وإذا استخدمت قناة خاصة، فكلا التطبيقين لديهما groups:history بالفعل، لذلك ستظل قراءات السجل في الحزمة تنجح.
4. سجّل بيانات الاعتماد
يوجد خياران. استخدم متغيرات البيئة لتصحيح الأخطاء على جهاز واحد (اضبط متغيرات OPENCLAW_QA_SLACK_* الأربعة ومرّر --credential-source env)، أو ازرع مجمع Convex المشترك حتى يتمكن CI والمشرفون الآخرون من استئجارها.
بالنسبة إلى مجمع Convex، اكتب الحقول الأربعة إلى ملف JSON:
OPENCLAW_QA_CONVEX_SITE_URL وOPENCLAW_QA_CONVEX_SECRET_MAINTAINER في الصدفة لديك، سجّل وتحقّق:
count: 1، وstatus: "active"، من دون حقل lease.
5. تحقّق من البداية إلى النهاية
شغّل المسار محليًا للتأكد من أن كلا الروبوتين يستطيعان التحدث إلى بعضهما عبر الوسيط:
slack-qa-report.md كلًا من slack-canary وslack-mention-gating بالحالة pass. إذا علِق المسار لنحو 90 ثانية وخرج بالرسالة Convex credential pool exhausted for kind "slack"، فإما أن المجمع فارغ أو أن كل صف مستأجر - سيخبرك qa credentials list --kind slack --status all --json أيهما.
WhatsApp QA
--credential-source env:
OPENCLAW_QA_WHATSAPP_DRIVER_PHONE_E164OPENCLAW_QA_WHATSAPP_SUT_PHONE_E164OPENCLAW_QA_WHATSAPP_DRIVER_AUTH_ARCHIVE_BASE64OPENCLAW_QA_WHATSAPP_SUT_AUTH_ARCHIVE_BASE64
- يفعّل
OPENCLAW_QA_WHATSAPP_GROUP_JIDسيناريوهات المجموعات مثلwhatsapp-mention-gating، وwhatsapp-group-pending-history-context، وwhatsapp-broadcast-group-fanout، وwhatsapp-group-activation-always، وwhatsapp-group-reply-to-bot-triggers، وسيناريوهات إجراءات/وسائط/استطلاعات المجموعة، وwhatsapp-group-allowlist-block. - يحافظ
OPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1على نصوص الرسائل في عناصر الرسائل المرصودة.
extensions/qa-lab/src/live-transports/whatsapp/whatsapp-live.runtime.ts):
- الأساس وبوابة المجموعات:
whatsapp-canary، وwhatsapp-pairing-block، وwhatsapp-mention-gating، وwhatsapp-group-pending-history-context، وwhatsapp-group-activation-always، وwhatsapp-group-reply-to-bot-triggers، وwhatsapp-top-level-reply-shape، وwhatsapp-restart-resume، وwhatsapp-group-allowlist-block. - الأوامر الأصلية:
whatsapp-help-command، وwhatsapp-status-command، وwhatsapp-commands-command، وwhatsapp-tools-compact-command، وwhatsapp-whoami-command، وwhatsapp-context-command، وwhatsapp-native-new-command. - سلوك الرد والمخرجات النهائية:
whatsapp-tool-only-usage-footer، وwhatsapp-reply-to-message، وwhatsapp-group-reply-to-message، وwhatsapp-reply-to-mode-batched، وwhatsapp-reply-context-isolation، وwhatsapp-reply-delivery-shape، وwhatsapp-stream-final-message-accounting. - إجراءات الرسائل لمسار المستخدم: يبدأ
whatsapp-agent-message-action-reactمن رسالة DM حقيقية من المشغّل، ويسمح للنموذج باستدعاء أداةmessage، ويرصد تفاعل WhatsApp الأصلي. يستخدمwhatsapp-agent-message-action-upload-fileالوضعية نفسها لـmessage(action=upload-file)ويرصد وسائط WhatsApp الأصلية. يثبتwhatsapp-group-agent-message-action-reactوwhatsapp-group-agent-message-action-upload-fileالإجراءات المرئية للمستخدم نفسها في مجموعة WhatsApp حقيقية. - توزيع المجموعة: يبدأ
whatsapp-broadcast-group-fanoutمن رسالة مجموعة WhatsApp واحدة تمت الإشارة فيها، ويتحقق من ردود مرئية مميزة منmainوqa-second. - تفعيل المجموعة: يغيّر
whatsapp-group-activation-alwaysجلسة مجموعة حقيقية إلى/activation always، ويثبت أن رسالة مجموعة من دون إشارة توقظ الوكيل، ثم يستعيد/activation mention. يزرعwhatsapp-group-reply-to-bot-triggersرد روبوت، ويرسل ردًا مقتبسًا أصليًا عليه من دون إشارة صريحة، ويتحقق من أن الوكيل يستيقظ من سياق ذلك الرد. - الوسائط الواردة والرسائل المنظمة:
whatsapp-inbound-image-caption، وwhatsapp-audio-preflight، وwhatsapp-inbound-structured-messages، وwhatsapp-group-audio-gating، وwhatsapp-inbound-reaction-no-trigger. ترسل هذه أحداث صورة وصوت ومستند وموقع وجهة اتصال وملصق وتفاعل WhatsApp حقيقية عبر المشغّل. - فحوصات عقد Gateway المباشرة:
whatsapp-outbound-media-matrix، وwhatsapp-outbound-document-preserves-filename، وwhatsapp-outbound-poll، وwhatsapp-group-outbound-media، وwhatsapp-group-outbound-poll، وwhatsapp-message-actions، وwhatsapp-reply-context-isolation، وwhatsapp-reply-delivery-shape. تتجاوز هذه توجيه النموذج عمدًا وتثبت عقود Gateway/القناة الحتمية لـsend، وpoll، وmessage.action. - تغطية التحكم في الوصول:
whatsapp-access-control-dm-open، وwhatsapp-access-control-dm-disabled، وwhatsapp-access-control-group-open، وwhatsapp-access-control-group-disabled، وwhatsapp-group-allowlist-block. - الموافقات الأصلية:
whatsapp-approval-exec-deny-native، وwhatsapp-approval-exec-native، وwhatsapp-approval-exec-reaction-native، وwhatsapp-approval-exec-group-reaction-native، وwhatsapp-approval-plugin-native. - تفاعلات الحالة:
whatsapp-status-reactions، وwhatsapp-status-reaction-lifecycle.
live-frontier الافتراضي
صغيرًا عند 10 سيناريوهات لتغطية دخان سريعة. يشغّل مسار mock-openai الافتراضي
44 سيناريو حتميًا عبر نقل WhatsApp الحقيقي مع
محاكاة مخرجات النموذج فقط. تبقى سيناريوهات الموافقة وبعض الفحوصات الأثقل/الحاجبة
صريحة بواسطة معرّف السيناريو.
يرصد مشغّل WhatsApp QA أحداثًا حية منظمة (text، وmedia،
وlocation، وreaction، وpoll) ويمكنه إرسال الوسائط والاستطلاعات
وجهات الاتصال والمواقع والملصقات بنشاط. يستورد QA Lab ذلك المشغّل عبر
سطح حزمة @openclaw/whatsapp/api.js بدلًا من الوصول إلى ملفات
وقت تشغيل WhatsApp الخاصة. بالنسبة إلى ملاحظات المجموعات، يكون fromJid هو JID المجموعة بينما
يحدد participantJid وfromPhoneE164 مرسل المشارك. يتم تنقيح
محتوى الرسائل افتراضيًا. فحوصات Gateway المباشرة
للاستطلاع، وupload-file، والوسائط، واستطلاع المجموعة، ووسائط المجموعة، وشكل الرد هي
فحوصات لعقد النقل/API؛ ولا تُعامل كدليل على أن مطالبة مستخدم جعلت الوكيل يختار
الإجراء نفسه. يأتي دليل إجراءات مسار المستخدم من سيناريوهات مثل
whatsapp-agent-message-action-react و
whatsapp-group-agent-message-action-react، حيث يرسل المشغّل رسالة
WhatsApp عادية ويرصد QA Lab أثر WhatsApp الأصلي الناتج.
تتضمن تقارير WhatsApp وضعية كل سيناريو (user-path، وdirect-gateway،
أو native-approval) حتى لا يُساء فهم الدليل على أنه يثبت عقدًا أقوى
مما يثبته فعلًا.
عناصر المخرجات:
whatsapp-qa-report.mdqa-evidence.json- إدخالات أدلة لفحوصات النقل الحي.whatsapp-qa-observed-messages.json- يتم تنقيح النصوص ما لم يكنOPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1.
مجمع بيانات اعتماد Convex
يمكن لمسارات Telegram وDiscord وSlack وWhatsApp استئجار بيانات الاعتماد من مجمع Convex مشترك بدلًا من قراءة متغيرات البيئة أعلاه. مرّر--credential-source convex (أو اضبط OPENCLAW_QA_CREDENTIAL_SOURCE=convex)؛ يحصل QA Lab على استئجار حصري، ويرسل Heartbeat طوال مدة التشغيل، ويحرره عند الإيقاف. أنواع المجمع هي "telegram"، و"discord"، و"slack"، و"whatsapp".
أشكال الحمولة التي يتحقق منها الوسيط عند admin/add:
- Telegram (
kind: "telegram"):{ groupId: string, driverToken: string, sutToken: string }- يجب أن يكونgroupIdسلسلة رقمية لمعرّف الدردشة. - مستخدم Telegram حقيقي (
kind: "telegram-user"):{ groupId: string, sutToken: string, testerUserId: string, testerUsername: string, telegramApiId: string, telegramApiHash: string, tdlibDatabaseEncryptionKey: string, tdlibArchiveBase64: string, tdlibArchiveSha256: string, desktopTdataArchiveBase64: string, desktopTdataArchiveSha256: string }- لإثبات Mantis Telegram Desktop فقط. يجب ألا تحصل مسارات QA Lab العامة على هذا النوع. - Discord (
kind: "discord"):{ guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string }. - WhatsApp (
kind: "whatsapp"):{ driverPhoneE164: string, sutPhoneE164: string, driverAuthArchiveBase64: string, sutAuthArchiveBase64: string, groupJid?: string }- يجب أن تكون أرقام الهواتف سلاسل E.164 مميزة.
telegram-user حصري واحد لكل من مشغّل TDLib CLI وشاهد Telegram Desktop،
ثم يحرره بعد نشر الإثبات.
عندما يحتاج PR إلى فرق مرئي حتمي، يمكن لـ Mantis استخدام رد النموذج الوهمي
نفسه على main وعلى رأس PR أثناء تغيير منسّق Telegram أو طبقة التسليم.
إعدادات الالتقاط الافتراضية مضبوطة لتعليقات PR: فئة Crabbox القياسية،
وتسجيل سطح مكتب بمعدل 24fps، وملف GIF للحركة بمعدل 24fps، وعرض معاينة 1920px.
يجب أن تنشر تعليقات قبل/بعد حزمة نظيفة تحتوي فقط على ملفات GIF
المقصودة.
يمكن لمسارات Slack استخدام المجموعة أيضًا. تعيش فحوصات شكل حمولة Slack حاليًا في مشغّل Slack QA بدلًا من الوسيط؛ استخدم { channelId: string, driverBotToken: string, sutBotToken: string, sutAppToken: string }، مع معرّف قناة Slack مثل Cxxxxxxxxxx. راجع إعداد مساحة عمل Slack لتوفير التطبيق والنطاقات.
تعيش متغيرات البيئة التشغيلية وعقدة نهاية وسيط Convex في الاختبار ← بيانات اعتماد Telegram المشتركة عبر Convex (اسم القسم يسبق مجموعة القنوات المتعددة؛ دلالات الحجز مشتركة بين الأنواع).
البذور المدعومة بالمستودع
تعيش أصول البذور فيqa/:
qa/scenarios/index.yamlqa/scenarios/<theme>/*.yaml
qa-lab مشغّل سيناريوهات YAML عامًا. كل ملف YAML للسيناريو
هو مصدر الحقيقة لتشغيل اختبار واحد ويجب أن يعرّف:
titleفي المستوى الأعلى- بيانات
scenarioالوصفية - بيانات وصفية اختيارية للفئة والإمكانات والمسار والمخاطر في
scenario - مراجع المستندات والكود في
scenario - متطلبات Plugin اختيارية في
scenario - تصحيح إعداد Gateway اختياري في
scenario flowقابل للتنفيذ في المستوى الأعلى لسيناريوهات التدفق، أوscenario.execution.kind/scenario.execution.pathلسيناريوهات Vitest وPlaywright
flow بأن يبقى عامًا
وعابرًا للقطاعات. على سبيل المثال، يمكن لسيناريوهات YAML دمج مساعدين من جانب
النقل مع مساعدين من جانب المتصفح يقودون Control UI المضمّن عبر وصلة
Gateway browser.request من دون إضافة مشغّل لحالة خاصة.
يجب تجميع ملفات السيناريو حسب إمكانات المنتج بدلًا من مجلد شجرة المصدر.
أبقِ معرّفات السيناريوهات مستقرة عند نقل الملفات؛ استخدم docsRefs وcodeRefs
لتتبع التنفيذ.
يجب أن تبقى قائمة الأساس عريضة بما يكفي لتغطية:
- دردشة DM والقناة
- سلوك السلاسل
- دورة حياة إجراء الرسالة
- استدعاءات Cron
- استدعاء الذاكرة
- تبديل النماذج
- تسليم الوكيل الفرعي
- قراءة المستودع وقراءة المستندات
- مهمة بناء صغيرة واحدة مثل Lobster Invaders
مسارات المزوّد الوهمية
يمتلكqa suite مسارين محليين وهميين للمزوّد:
mock-openaiهو محاكاة OpenClaw الواعية بالسيناريو. يبقى مسار المحاكاة الحتمي الافتراضي لـ QA المدعوم بالمستودع وبوابات التكافؤ.aimockيبدأ خادم مزوّد مدعومًا بـ AIMock لتغطية البروتوكول التجريبي، والتجهيزات، والتسجيل/الإعادة، والفوضى. إنه إضافي ولا يستبدل موزّع سيناريوهاتmock-openai.
extensions/qa-lab/src/providers/.
يمتلك كل مزوّد إعداداته الافتراضية، وبدء تشغيل الخادم المحلي، وإعداد نموذج Gateway،
واحتياجات تجهيز ملف تعريف المصادقة، وأعلام إمكانات الحي/الوهمي. يجب أن يمر كود
الحزمة وGateway المشتركان عبر سجل المزوّدين بدلًا من التفريع على
أسماء المزوّدين.
محوّلات النقل
يمتلكqa-lab وصلة نقل عامة لسيناريوهات YAML QA. qa-channel هو
الافتراضي الاصطناعي. يبدأ crabline خوادم محلية بشكل مزوّد ويشغّل
Plugins القنوات العادية في OpenClaw ضدها. live محجوز لبيانات اعتماد
المزوّدين الحقيقية والقنوات الخارجية.
على مستوى البنية، يكون التقسيم كالتالي:
- يمتلك
qa-labتنفيذ السيناريوهات العام، وتزامن العمال، وكتابة الأدلة، والتقارير. - يمتلك محوّل النقل إعداد Gateway، والجاهزية، ومراقبة الوارد والصادر، وإجراءات النقل، وحالة النقل المطبّعة.
- تعرّف ملفات سيناريوهات YAML تحت
qa/scenarios/تشغيل الاختبار؛ ويوفرqa-labسطح التشغيل القابل لإعادة الاستخدام الذي ينفذها.
إضافة قناة
تتطلب إضافة قناة إلى نظام YAML QA تنفيذ القناة إضافة إلى حزمة سيناريوهات تمرّن عقد القناة. لتغطية smoke في CI، أضف خادم مزوّد Crabline المحلي المطابق واعرضه عبر مشغّلcrabline.
لا تضف جذر أمر QA جديدًا في المستوى الأعلى عندما يستطيع مضيف qa-lab المشترك امتلاك التدفق.
يمتلك qa-lab آليات المضيف المشترك:
- جذر الأمر
openclaw qa - بدء الحزمة وإيقافها
- تزامن العمال
- كتابة الأدلة
- توليد التقارير
- تنفيذ السيناريوهات
- أسماء توافق بديلة لسيناريوهات
qa-channelالأقدم
- كيف يُركّب
openclaw qa <runner>أسفل جذرqaالمشترك - كيف يُعدّ Gateway لذلك النقل
- كيف تُفحص الجاهزية
- كيف تُحقن الأحداث الواردة
- كيف تُراقب الرسائل الصادرة
- كيف تُعرض النصوص وحالة النقل المطبّعة
- كيف تُنفذ الإجراءات المدعومة بالنقل
- كيف يُعالج إعادة الضبط أو التنظيف الخاص بالنقل
- أبقِ
qa-labمالكًا لجذرqaالمشترك. - نفّذ مشغّل النقل على وصلة مضيف
qa-labالمشتركة. - أبقِ الآليات الخاصة بالنقل داخل Plugin المشغّل أو حاضنة القناة.
- ركّب المشغّل كـ
openclaw qa <runner>بدلًا من تسجيل أمر جذري منافس. يجب أن تعلن Plugins المشغّل عنqaRunnersفيopenclaw.plugin.jsonوأن تصدّر مصفوفةqaRunnerCliRegistrationsمطابقة منruntime-api.ts. أبقِruntime-api.tsخفيفًا؛ يجب أن يبقى تنفيذ CLI والمشغّل الكسول خلف نقاط دخول منفصلة. - ألّف أو كيّف سيناريوهات YAML تحت أدلة
qa/scenarios/ذات السمات. - استخدم مساعدي السيناريو العامين للسيناريوهات الجديدة.
- أبقِ أسماء التوافق البديلة الحالية عاملة ما لم يكن المستودع ينفذ ترحيلًا مقصودًا.
- إذا كان يمكن التعبير عن السلوك مرة واحدة في
qa-lab، فضعه فيqa-lab. - إذا كان السلوك يعتمد على نقل قناة واحد، فأبقِه في Plugin ذلك المشغّل أو حاضنة Plugin.
- إذا كان السيناريو يحتاج إلى إمكانية جديدة يمكن لأكثر من قناة استخدامها، فأضف مساعدًا عامًا بدلًا من فرع خاص بقناة في
suite.ts. - إذا كان السلوك ذا معنى لنقل واحد فقط، فأبقِ السيناريو خاصًا بالنقل واجعل ذلك صريحًا في عقد السيناريو.
أسماء مساعدي السيناريو
المساعدون العامون المفضلون للسيناريوهات الجديدة:waitForTransportReadywaitForChannelReadyinjectInboundMessageinjectOutboundMessagewaitForTransportOutboundMessagewaitForChannelOutboundMessagewaitForNoTransportOutboundgetTransportSnapshotreadTransportMessagereadTransportTranscriptformatTransportTranscriptresetTransport
waitForQaChannelReady، وwaitForOutboundMessage، وwaitForNoOutbound، وformatConversationTranscript، وresetBus - لكن يجب أن يستخدم تأليف السيناريوهات الجديدة الأسماء العامة. توجد الأسماء البديلة لتجنب ترحيل في يوم واحد، لا كنموذج للمضي قدمًا.
التقارير
يصدّرqa-lab تقرير بروتوكول Markdown من الخط الزمني المرصود للحافلة.
يجب أن يجيب التقرير عن:
- ما الذي نجح
- ما الذي فشل
- ما الذي بقي محظورًا
- ما سيناريوهات المتابعة التي تستحق الإضافة
pnpm openclaw qa coverage (أضف --json للإخراج القابل للقراءة آليًا).
عند اختيار إثبات مركّز لسلوك متأثر أو مسار ملف، شغّل pnpm openclaw qa coverage --match <query>.
يبحث تقرير المطابقة في بيانات السيناريو الوصفية، ومراجع المستندات، ومراجع الكود، ومعرّفات التغطية، وPlugins، ومتطلبات المزوّدين، ثم يطبع أهداف qa suite --scenario ... المطابقة.
يكتب كل تشغيل qa suite أدلة المستوى الأعلى qa-evidence.json،
وqa-suite-summary.json، وqa-suite-report.md لمجموعة
السيناريوهات المحددة. السيناريوهات التي تعلن execution.kind: vitest أو
execution.kind: playwright تشغّل مسار الاختبار المطابق وتكتب أيضًا
سجلات لكل سيناريو. السيناريوهات التي تعلن execution.kind: script تشغّل
منتج الأدلة عند execution.path عبر node --import tsx (مع
توسيع ${outputDir} و${scenarioId} في execution.args)؛ يكتب المنتج
ملف qa-evidence.json الخاص به، وتُستورد إدخالاته إلى مخرجات الحزمة
وتُحل مسارات أدلته نسبةً إلى ملف qa-evidence.json لذلك المنتج.
عند الوصول إلى qa suite عبر
qa run --qa-profile، يتضمن ملف qa-evidence.json نفسه أيضًا ملخص
بطاقة تقييم الملف الشخصي لفئات التصنيف المحددة.
عامله كوسيلة اكتشاف، لا كبديل عن البوابة؛ لا يزال السيناريو المحدد يحتاج إلى وضع المزوّد الصحيح، أو النقل الحي، أو Multipass، أو Testbox، أو مسار الإصدار للسلوك قيد الاختبار.
لسياق بطاقة التقييم، راجع بطاقة تقييم النضج.
لفحوصات الشخصية والأسلوب، شغّل السيناريو نفسه عبر مراجع نماذج حية متعددة
واكتب تقرير Markdown محكّمًا:
SOUL.md، ثم تشغيل تفاعلات مستخدم عادية
مثل الدردشة، والمساعدة في مساحة العمل، ومهام الملفات الصغيرة. يجب ألا يُبلَّغ
النموذج المرشح بأنه قيد التقييم. يحافظ الأمر على كل نسخة نصية كاملة،
ويسجل إحصاءات تشغيل أساسية، ثم يطلب من نماذج التحكيم في الوضع السريع مع
استدلال xhigh حيث يكون مدعوما لترتيب عمليات التشغيل بحسب الطبيعية، والأجواء، والفكاهة.
استخدم --blind-judge-models عند مقارنة المزوّدين: لا تزال مطالبة التحكيم تحصل على
كل نسخة نصية وحالة تشغيل، لكن تُستبدل مراجع المرشحين بتسميات محايدة
مثل candidate-01؛ ويربط التقرير الترتيبات بالمراجع الحقيقية بعد
التحليل.
تستخدم عمليات تشغيل المرشحين افتراضيا تفكير high، مع medium لـ GPT-5.5 و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.5، وopenai/gpt-5.2، وopenai/gpt-5، وanthropic/claude-opus-4-8،
و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.5,thinking=xhigh,fast و
anthropic/claude-opus-4-8,thinking=high.