نمای کلی تضمین کیفیت

پشتهٔ خصوصی QA، OpenClaw را به‌شکلی واقع‌گرایانه و مشابه کانال می‌آزماید که با آزمون واحد امکان‌پذیر نیست.

اجزا:

• extensions/qa-channel: کانال پیام مصنوعی با سطوح پیام مستقیم، کانال، رشته، واکنش، ویرایش و حذف.
• extensions/qa-lab: رابط کاربری اشکال‌زدا، گذرگاه QA، پروفایل‌های سناریو و آداپتورهای زندهٔ انتقال برای مشاهدهٔ رونوشت، تزریق پیام‌های ورودی و برون‌بری گزارش Markdown.
• qa/: دارایی‌های بذرِ مبتنی بر مخزن برای وظیفهٔ آغازین و سناریوهای پایهٔ QA.
• Mantis: راستی‌آزمایی زندهٔ قبل/بعد برای باگ‌هایی که به انتقال‌های واقعی، نماگرفت‌های مرورگر، وضعیت ماشین مجازی و شواهد PR نیاز دارند.

سطح فرمان

همهٔ جریان‌های QA زیرمجموعهٔ pnpm openclaw qa <subcommand> اجرا می‌شوند. بسیاری از آن‌ها نام‌های مستعار اسکریپتی pnpm qa:* دارند؛ هر دو شکل کار می‌کنند.

qa run مبتنی بر پروفایل

qa run مبتنی بر پروفایل، عضویت را از taxonomy.yaml می‌خواند و سپس سناریوهای تفکیک‌شده را از طریق qa suite ارسال می‌کند. --surface و --category به‌جای تعریف مسیرهای جداگانه، پروفایل انتخاب‌شده را فیلتر می‌کنند. خروجی qa-evidence.json شامل خلاصهٔ کارت امتیاز پروفایل با تعداد دسته‌های انتخاب‌شده و شناسه‌های پوشش مفقود است؛ مدخل‌های شواهد منفرد همچنان منبع حقیقت برای آزمون‌ها، نقش‌های پوشش و نتایج هستند. شناسه‌های پوشش قابلیت رده‌بندی، اهداف اثبات دقیق‌اند نه نام مستعار: پوشش سناریوی اصلی شناسه‌های منطبق را برآورده می‌کند، درحالی‌که پوشش ثانویه صرفاً راهنما باقی می‌ماند. هر شناسهٔ پوشش دقیقاً taxonomy-surface.feature است و از شناسهٔ کوتاه سطح در taxonomy.yaml استفاده می‌کند. فیلد جداگانهٔ surface یک سناریو، برچسب اجرا/گزارش‌دهی است (برای مثال، channel یا runtime-tool)؛ این فیلد مالکیت رده‌بندی را تعیین نمی‌کند.

شواهد کم‌حجم، execution هر مدخل را حذف می‌کنند و evidenceMode: "slim" را تنظیم می‌کنند؛ smoke-ci به‌طور پیش‌فرض کم‌حجم است و --evidence-mode full مدخل‌های کامل را بازمی‌گرداند:

pnpm openclaw qa run \  --qa-profile smoke-ci \  --category channels.conversation-routing-and-delivery \  --provider-mode mock-openai \  --output-dir .artifacts/qa-e2e/smoke-ci-profile-dispatch

برای اثبات قطعی پروفایل با ارائه‌دهندگان مدل ساختگی و سرورهای ارائه‌دهندهٔ محلی Crabline از smoke-ci استفاده کنید. برای اثبات Stable/LTS در برابر کانال‌های زنده از release استفاده کنید. از all فقط برای اجراهای صریح شواهد تمام رده‌بندی استفاده کنید؛ این گزینه همهٔ دسته‌های بلوغ فعال را انتخاب می‌کند و می‌توان آن را از طریق گردش‌کار GitHub Actions با نام QA Profile Evidence و با qa_profile=all ارسال کرد. وقتی یک فرمان به پروفایل ریشهٔ OpenClaw نیز نیاز دارد، پروفایل ریشه را پیش از فرمان QA قرار دهید:

pnpm openclaw --profile work qa run --qa-profile smoke-ci

جریان اپراتور

جریان فعلی اپراتور QA یک سایت QA دوپنجره‌ای است:

• چپ: داشبورد Gateway (رابط کاربری کنترل) همراه با عامل.
• راست: QA Lab که رونوشت شبیه Slack و برنامهٔ سناریو را نمایش می‌دهد.

آن را با این فرمان اجرا کنید:

pnpm qa:lab:up

این فرمان سایت QA را می‌سازد، مسیر Gateway مبتنی بر Docker را راه‌اندازی می‌کند و صفحهٔ QA Lab را در دسترس قرار می‌دهد؛ جایی که اپراتور یا حلقهٔ خودکارسازی می‌تواند مأموریتی برای QA به عامل بدهد، رفتار واقعی کانال را مشاهده کند و موارد موفق، ناموفق یا مسدودمانده را ثبت کند.

برای تکرار سریع‌تر تغییرات رابط کاربری QA Lab بدون بازسازی ایمیج Docker در هر نوبت، پشته را با بستهٔ QA Lab متصل‌شده از طریق bind mount راه‌اندازی کنید:

pnpm openclaw qa docker-build-imagepnpm qa:lab:buildpnpm qa:lab:up:fastpnpm qa:lab:watch

qa:lab:up:fast سرویس‌های Docker را روی یک ایمیج ازپیش‌ساخته نگه می‌دارد و extensions/qa-lab/web/dist را با bind mount در کانتینر qa-lab متصل می‌کند. qa:lab:watch آن بسته را هنگام تغییر بازسازی می‌کند و مرورگر با تغییر هش دارایی QA Lab به‌طور خودکار بارگذاری مجدد می‌شود.

آزمون‌های دود مشاهده‌پذیری

qa:otel:smoke یک گیرنده محلی OTLP/HTTP را راه‌اندازی می‌کند، یک نوبت حداقلی عامل QA-channel را اجرا می‌کند و سپس بررسی می‌کند که ردیابی‌ها، معیارها و گزارش‌ها صادر شده‌اند. این سناریو بازه‌های ردیابی 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 می‌نویسد.

qa:prometheus:smoke تأیید می‌کند که برداشت‌های بدون احراز هویت رد می‌شوند و سپس بررسی می‌کند که برداشت احرازشده شامل خانواده‌های معیار حیاتی برای انتشار باشد، بدون محتوای اعلان، محتوای پاسخ، شناسه‌های تشخیصی خام، توکن‌های احراز هویت یا مسیرهای محلی.

مسیرهای آزمون دود Matrix

برای یک مسیر آزمون دود واقعی از نظر انتقال Matrix که به اعتبارنامه‌های ارائه‌دهنده مدل نیاز ندارد، نمایه انتشار را با ارائه‌دهنده قطعی و شبیه‌سازی‌شده OpenAI اجرا کنید:

pnpm openclaw qa matrix --provider-mode mock-openai --profile release

برای مسیر ارائه‌دهنده زنده و پیشرو، اعتبارنامه‌های سازگار با OpenAI را صریحاً ارائه کنید:

OPENCLAW_LIVE_OPENAI_KEY="${OPENAI_API_KEY}" \  pnpm openclaw qa matrix --provider-mode live-frontier --profile release

اجرای ساده pnpm openclaw qa matrix نمایه کامل all را اجرا می‌کند و پس از شکست سناریوها ادامه می‌دهد. برای چرخه بازخورد کوتاه‌تر از --fail-fast استفاده کنید یا --scenario <id> را برای انتخاب سناریوهای منفرد تکرار کنید؛ شناسه‌های صریح سناریو بر --profile اولویت دارند.

عضویت نمایه و الزامات کانال همراه با سناریوهای اعلانی Matrix در qa/scenarios/channels/ قرار دارند. اجرا، درایور کانال را انتخاب می‌کند. پیاده‌سازی‌های زنده آن‌ها در extensions/qa-lab/src/live-transports/matrix/scenarios/ قرار دارند.

آداپتور یک homeserver یک‌بارمصرف Tuwunel را در Docker فراهم می‌کند (تصویر پیش‌فرض ghcr.io/matrix-construct/tuwunel:v1.5.1، نام سرور matrix-qa.test، درگاه 28008)؛ کاربران موقت درایور، SUT و ناظر را ثبت می‌کند؛ اتاق‌های موردنیاز را مقداردهی اولیه می‌کند؛ و مرز درخواست/پاسخ ویرایش‌شده را ثبت می‌کند. سپس Plugin واقعی Matrix را درون یک Gateway فرزند QA محدود به همان انتقال (بدون qa-channel) اجرا می‌کند و محیط را برمی‌چیند.

گزینه‌های رایج:

QA مربوط به Matrix اعتبارنامه‌های مشترک Matrix را اجاره نمی‌کند: آداپتور کاربران یک‌بارمصرف را به‌صورت محلی ایجاد می‌کند، بنابراین --credential-source یا --credential-role را نمی‌پذیرد. تصویر homeserver را با OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE جایگزین کنید؛ بررسی‌های منفی نبود پاسخ را با OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS تنظیم کنید (پیش‌فرض 8000، محدودشده به مهلت زمانی سناریوی فعال). فرمان تک‌اجرا معمولاً پس از تخلیه مصنوعات، خروج پاک را اجباری می‌کند، زیرا هندل‌های بومی رمزنگاری Matrix ممکن است پس از پاک‌سازی نیز زنده بمانند؛ OPENCLAW_QA_MATRIX_DISABLE_FORCE_EXIT=1 را فقط برای مهار آزمون مستقیمی تنظیم کنید که نیاز دارد فرمان به‌جای آن بازگردد.

هر اجرا مصنوعات معمول QA Lab را در پوشه خروجی انتخاب‌شده می‌نویسد: qa-suite-report.md، qa-suite-summary.json و qa-evidence.json. اگر پاک‌سازی ناموفق بود، فرمان بازیابی docker compose ... down --remove-orphans چاپ‌شده را اجرا کنید. در اجراکننده‌های کند، بازه نبود پاسخ را افزایش دهید؛ در CI سریع، بازه کوچک‌تر می‌تواند بررسی‌های منفی را کوتاه‌تر کند.

سناریوها رفتار انتقالی را پوشش می‌دهند که آزمون‌های واحد نمی‌توانند آن را به‌صورت سرتاسری اثبات کنند: دروازه‌بندی اشاره، سیاست‌های مجازبودن ربات، فهرست‌های مجاز، پاسخ‌های سطح‌بالا و رشته‌ای، مسیریابی پیام خصوصی، مدیریت واکنش، جلوگیری از ویرایش ورودی، حذف تکرار بازپخش پس از راه‌اندازی مجدد، بازیابی از وقفه homeserver، تحویل فراداده تأیید، مدیریت رسانه و جریان‌های راه‌اندازی اولیه/بازیابی/تأیید E2EE در Matrix. نمایه CLI مربوط به E2EE همچنین openclaw matrix encryption setup و فرمان‌های تأیید را از طریق همان homeserver یک‌بارمصرف اجرا می‌کند و سپس پاسخ‌های Gateway را بررسی می‌کند.

matrix-room-block-streaming و subagent-thread-spawn با انتخاب صریح --scenario همچنان در دسترس‌اند، اما خارج از نمایه پیش‌فرض all باقی می‌مانند.

CI از همان سطح فرمان در .github/workflows/qa-live-transports-convex.yml استفاده می‌کند. اجراهای زمان‌بندی‌شده و انتشار، سناریوهای انتشار را اجرا می‌کنند. ارسال‌های دستی matrix_profile=all نمایه‌های transport، media، e2ee-smoke، e2ee-deep و e2ee-cli را منشعب می‌کنند؛ ارسال‌های متمرکز در یک کار، fast، release یا transport را انتخاب می‌کنند.

سناریوهای Mantis در Discord

Discord همچنین سناریوهای اختیاری ویژه Mantis برای بازتولید اشکال دارد. برای خط زمانی صریح واکنش وضعیت از --scenario discord-status-reactions-tool-only استفاده کنید، یا برای ایجاد یک رشته واقعی Discord و تأیید اینکه message.thread-reply یک پیوست filePath را حفظ می‌کند، از --scenario discord-thread-reply-filepath-attachment استفاده کنید. این سناریوها خارج از مسیر زنده پیش‌فرض Discord باقی می‌مانند، زیرا بررسی‌های بازتولید قبل/بعد هستند، نه پوشش گسترده آزمون دود. گردش‌کار Mantis مربوط به پیوست رشته همچنین می‌تواند هنگامی که MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR یا MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64 در محیط QA پیکربندی شده باشد، ویدیوی شاهد Discord Web با کاربر واردشده اضافه کند. آن نمایه مشاهده‌گر فقط برای ثبت بصری است؛ تصمیم موفقیت/شکست همچنان از اوراکل REST مربوط به Discord می‌آید.

برای دیگر مسیرهای آزمون دود واقعی از نظر انتقال:

pnpm openclaw qa discordpnpm openclaw qa slackpnpm openclaw qa telegrampnpm openclaw qa whatsapp

آن‌ها یک کانال واقعی ازپیش‌موجود را با دو ربات یا حساب (درایور + SUT) هدف قرار می‌دهند. متغیرهای محیطی لازم، فهرست سناریوها، مصنوعات خروجی و مخزن اعتبارنامه Convex برای آن چهار انتقال در مرجع QA برای Discord، Slack، Telegram و WhatsApp در ادامه مستند شده‌اند.

اجراکننده‌های دسکتاپ Slack و وظایف بصری Mantis

برای اجرای کامل ماشین مجازی دسکتاپ Slack با امکان نجات VNC، اجرا کنید:

pnpm openclaw qa mantis slack-desktop-smoke \  --gateway-setup \  --scenario slack-canary \  --keep-lease

آن فرمان یک ماشین دسکتاپ/مرورگر Crabbox را اجاره می‌کند، مسیر زنده Slack را درون VM اجرا می‌کند، Slack Web را در مرورگر VNC باز می‌کند، از دسکتاپ تصویربرداری می‌کند و slack-qa/، slack-desktop-smoke.png و slack-desktop-smoke.mp4 (در صورت در دسترس بودن ضبط ویدئو) را به دایرکتوری مصنوعات Mantis کپی می‌کند. اجاره‌های دسکتاپ/مرورگر Crabbox ابزارهای ضبط و بسته‌های کمکی مرورگر/ساخت بومی را از ابتدا فراهم می‌کنند، بنابراین سناریو فقط باید در اجاره‌های قدیمی‌تر گزینه‌های جایگزین را نصب کند. Mantis زمان‌بندی کل و هر مرحله را در mantis-slack-desktop-smoke-report.md گزارش می‌کند تا اجراهای کند نشان دهند که زمان صرف آماده‌سازی اجاره، دریافت اطلاعات احراز هویت، راه‌اندازی راه دور یا کپی مصنوعات شده است. پس از ورود دستی به Slack Web از طریق VNC، از --lease-id <cbx_...> مجدداً استفاده کنید؛ اجاره‌های استفاده‌شده همچنین کش فروشگاه pnpm متعلق به Crabbox را گرم نگه می‌دارند. مقدار پیش‌فرض --hydrate-mode source از یک checkout منبع اعتبارسنجی می‌کند و نصب/ساخت را درون VM اجرا می‌کند. فقط زمانی از --hydrate-mode prehydrated استفاده کنید که فضای کاری راه دورِ استفاده‌شده از قبل دارای node_modules و یک dist/ ساخته‌شده باشد؛ این حالت مرحله پرهزینه نصب/ساخت را رد می‌کند و اگر فضای کاری آماده نباشد، با حالت بسته شکست می‌خورد. با --gateway-setup، Mantis یک Gateway پایدار Slack متعلق به OpenClaw را روی پورت 38973 درون VM در حال اجرا نگه می‌دارد؛ بدون آن، فرمان مسیر عادی QA ربات‌به‌ربات Slack را اجرا می‌کند و پس از ضبط مصنوعات خارج می‌شود.

برای اثبات رابط کاربری بومی تأیید Slack با شواهد دسکتاپ، حالت نقطه بازرسی تأیید Mantis را اجرا کنید:

pnpm openclaw qa mantis slack-desktop-smoke \  --approval-checkpoints \  --credential-source convex \  --credential-role maintainer

این حالت با --gateway-setup ناسازگار است. سناریوهای تأیید Slack را اجرا می‌کند، شناسه‌های سناریوی غیرتأییدی را رد می‌کند، در هر وضعیت تأیید در انتظار و حل‌شده منتظر می‌ماند، پیام مشاهده‌شده API مربوط به Slack را در approval-checkpoints/<scenario>-pending.png و approval-checkpoints/<scenario>-resolved.png رندر می‌کند و سپس اگر هر نقطه بازرسی، شواهد پیام، تأیید دریافت یا اسکرین‌شات رندرشده وجود نداشته یا خالی باشد، شکست می‌خورد. اجاره‌های سرد CI ممکن است همچنان ورود به Slack را در slack-desktop-smoke.png نشان دهند؛ تصاویر نقاط بازرسی تأیید، مدرک بصری این مسیر هستند.

اجرای پیش‌فرض نقطه بازرسی، دو سناریوی استاندارد تأیید Slack را نگه می‌دارد. برای ضبط هر یک از مسیرهای تأیید اختیاری Codex، آن را صراحتاً با --scenario slack-codex-approval-exec-native یا --scenario slack-codex-approval-plugin-native انتخاب کنید؛ Mantis هر دو را می‌پذیرد و همان جفت اسکرین‌شات در انتظار/حل‌شده را تولید می‌کند. اجراکننده مهلت‌های نقاط بازرسی و فرمان راه دور را برای هر مسیر انتخاب‌شده Codex افزایش می‌دهد تا توالی کامل تأیید، تکمیل عامل و به‌روزرسانی حل‌شده بتواند پایان یابد.

چک‌لیست اپراتور، فرمان dispatch گردش‌کار GitHub، قرارداد نظرِ شواهد، جدول تصمیم‌گیری حالت hydrate، تفسیر زمان‌بندی و مراحل رسیدگی به شکست در راهنمای اجرای دسکتاپ Slack در Mantis قرار دارند.

برای یک وظیفه دسکتاپ به سبک عامل/CV، اجرا کنید:

pnpm openclaw qa mantis visual-task \  --browser-url https://example.net \  --expect-text "Example Domain" \  --vision-model openai/gpt-5.6-luna

visual-task یک ماشین دسکتاپ/مرورگر Crabbox را اجاره می‌کند یا مجدداً به کار می‌گیرد، crabbox record --while را راه‌اندازی می‌کند، مرورگر قابل‌مشاهده را از طریق یک visual-driver تو‌در‌تو هدایت می‌کند، visual-task.png را ضبط می‌کند، هنگام انتخاب --vision-mode image-describe، openclaw infer image describe را روی اسکرین‌شات اجرا می‌کند و visual-task.mp4، mantis-visual-task-summary.json، mantis-visual-task-driver-result.json و mantis-visual-task-report.md را می‌نویسد. وقتی --expect-text تنظیم شده باشد، اعلان بینایی یک حکم JSON ساخت‌یافته (visible، evidence، reason) درخواست می‌کند و فقط وقتی موفق می‌شود که مدل visible: true را همراه با شواهدی گزارش کند که به متن مورد انتظار استناد می‌کنند؛ پاسخ visible: false که صرفاً متن هدف را نقل می‌کند، همچنان در ارزیابی شکست می‌خورد. برای یک آزمون دودِ بدون مدل که زیرساخت دسکتاپ، مرورگر، اسکرین‌شات و ویدئو را بدون فراخوانی ارائه‌دهنده درک تصویر اثبات می‌کند، از --vision-mode metadata استفاده کنید. ضبط یک مصنوع الزامی برای visual-task است؛ اگر Crabbox هیچ visual-task.mp4 غیرخالی ضبط نکند، وظیفه حتی اگر هدایتگر بصری موفق شده باشد، شکست می‌خورد. هنگام شکست، Mantis اجاره را برای VNC نگه می‌دارد، مگر اینکه وظیفه از قبل موفق شده و --keep-lease تنظیم نشده باشد.

بررسی سلامت مخزن اطلاعات احراز هویت

پیش از استفاده از اطلاعات احراز هویت زنده تجمیع‌شده، اجرا کنید:

pnpm openclaw qa credentials doctor

doctor متغیرهای محیطی کارگزار Convex (OPENCLAW_QA_CONVEX_SITE_URL، OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX) را بررسی می‌کند، تنظیمات نقطه پایانی را اعتبارسنجی می‌کند، برای OPENCLAW_QA_CONVEX_SECRET_CI و OPENCLAW_QA_CONVEX_SECRET_MAINTAINER فقط وضعیت تنظیم‌شده/مفقود را گزارش می‌کند و هنگام وجود راز نگه‌دارنده، دسترسی‌پذیری مدیریت/فهرست را تأیید می‌کند.

پوشش سناریوی مرجع

فایل ریشه taxonomy.yaml شناسه‌های پوشش معنایی را تعریف می‌کند. فایل‌های YAML سناریو در qa/scenarios/ هر سناریو را به آن شناسه‌ها نگاشت می‌کنند و مالک فراداده اجرا هستند: channel تنها نیازمندی کانال است و profiles عضویت نام‌گذاری‌شده در اجرا را اعلام می‌کنند. درایور کانال یک انتخاب پیاده‌سازی قابل‌تعویض در سطح اجرا است. اجراکننده‌های TypeScript آن کاتالوگ را پرس‌وجو می‌کنند؛ آن‌ها فهرست‌های موازی سناریو یا پوشش را نگه‌داری نمی‌کنند.

خروجی ایستای qa coverage نگاشت رده‌بندی به سناریو را گزارش می‌کند. اثبات واقعی از qa-evidence.json می‌آید که سناریوی اجراشده، شناسه‌های پوشش، کانال، درایور واقعاً استفاده‌شده و نتیجه را ثبت می‌کند. کانال و درایور ابعاد گزارش هستند، نه واژگان اضافی شناسه پوشش یا محورهای صلاحیت سناریو.

برای یک مسیر VM یک‌بارمصرف Linux بدون وارد کردن Docker به مسیر QA، اجرا کنید:

pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline

این فرمان یک مهمان تازه Multipass را راه‌اندازی می‌کند، وابستگی‌ها را نصب می‌کند، OpenClaw را درون مهمان می‌سازد، qa suite را اجرا می‌کند و سپس گزارش و خلاصه عادی QA را به .artifacts/qa-e2e/... روی میزبان کپی می‌کند. این مسیر همان رفتار انتخاب سناریوی qa suite روی میزبان را مجدداً استفاده می‌کند.

اجراهای مجموعه روی میزبان و Multipass چند سناریوی انتخاب‌شده را به‌طور موازی با workerهای مجزای Gateway اجرا می‌کنند. هم‌روندی پیش‌فرض qa-channel برابر 4 است و به تعداد سناریوهای انتخاب‌شده محدود می‌شود. برای تنظیم تعداد workerها از --concurrency <count> یا برای اجرای سریالی از --concurrency 1 استفاده کنید. برای اجرای بسته معیار دستیار شخصی (10 سناریو) از --pack personal-agent استفاده کنید. انتخاب‌گر بسته با پرچم‌های تکراری --scenario جمع‌پذیر است: ابتدا سناریوهای صریح اجرا می‌شوند، سپس سناریوهای بسته به ترتیب بسته و با حذف موارد تکراری اجرا می‌شوند. برای انتخاب هم‌زمان سناریوهای otel-trace-smoke و docker-prometheus-smoke، وقتی یک اجراکننده سفارشی QA از قبل راه‌اندازی گردآورنده OpenTelemetry را فراهم می‌کند، از --pack observability استفاده کنید.

اگر هر سناریویی شکست بخورد، فرمان با کد غیرصفر خارج می‌شود. وقتی می‌خواهید مصنوعات را بدون کد خروج شکست دریافت کنید، از --allow-failures استفاده کنید.

اجراهای زنده ورودی‌های پشتیبانی‌شده احراز هویت QA را که برای مهمان عملی هستند، ارسال می‌کنند: کلیدهای ارائه‌دهنده مبتنی بر محیط، مسیر پیکربندی ارائه‌دهنده زنده QA و CODEX_HOME در صورت وجود. --output-dir را زیر ریشه مخزن نگه دارید تا مهمان بتواند از طریق فضای کاری mountشده در آن بنویسد.

مرجع QA برای Discord، Slack، Telegram و WhatsApp

آداپتور Matrix از مسیر یک‌بارمصرف مبتنی بر Docker که در بالا مستند شده است استفاده می‌کند. Discord، Slack، Telegram و WhatsApp روی انتقال‌های واقعی از پیش موجود اجرا می‌شوند، بنابراین مرجع آن‌ها در اینجا قرار دارد.

پرچم‌های مشترک CLI

این مسیرها از طریق extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts ثبت می‌شوند و پرچم‌های یکسانی را می‌پذیرند:

هر مسیر در صورت شکست هر سناریو با کد غیرصفر خارج می‌شود. --allow-failures مصنوعات را بدون تنظیم کد خروج شکست می‌نویسد. Telegram همچنین --list-scenarios را برای چاپ شناسه‌های سناریوی موجود و خروج می‌پذیرد؛ مسیرهای دیگر این پرچم را ارائه نمی‌کنند.

QA برای Telegram

pnpm openclaw qa telegram

یک گروه خصوصی واقعی Telegram را با دو ربات متمایز (درایور + SUT) هدف قرار می‌دهد. ربات SUT باید یک نام کاربری Telegram داشته باشد؛ مشاهده ربات‌به‌ربات زمانی بهترین عملکرد را دارد که هر دو ربات، Bot-to-Bot Communication Mode را در @BotFather فعال کرده باشند.

متغیرهای محیطی الزامی هنگام --credential-source env:

• OPENCLAW_QA_TELEGRAM_GROUP_ID - شناسه عددی چت (رشته).
• OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN
• OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN

پروفایل release سناریوهای نگه‌داری‌شده YAML مربوط به Telegram را انتخاب می‌کند؛ all بررسی‌های اختیاری فشار برای نشست، مصرف، زنجیره پاسخ و استریم را اضافه می‌کند. مقادیر صریح --scenario پروفایل را لغو می‌کنند.

• channel-canary
• channel-mention-gating
• telegram-help-command
• telegram-commands-command
• telegram-tools-compact-command
• telegram-whoami-command
• telegram-status-command
• telegram-repeated-command-authorization
• telegram-other-bot-command-gating
• telegram-context-command
• telegram-current-session-status-tool
• telegram-tool-only-usage-footer
• telegram-reply-chain-exact-marker
• telegram-stream-final-single-message
• telegram-long-final-reuses-preview
• telegram-long-final-three-chunks

پروفایل release همیشه canary، محدودسازی بر اساس اشاره، پاسخ‌های فرمان بومی، آدرس‌دهی فرمان و پاسخ‌های گروهی بات‌به‌بات را پوشش می‌دهد. mock-openai بررسی قطعی پیش‌نمایش پاسخ نهایی طولانی را نیز شامل می‌شود. telegram-current-session-status-tool و telegram-tool-only-usage-footer همچنان اختیاری هستند: اولی فقط زمانی پایدار است که مستقیماً پس از canary اجرا شود و دومی اثباتی در Telegram واقعی برای پاورقی /usage در پاسخ‌های صرفاً ابزاری است. برای چاپ تفکیک فعلی پیش‌فرض/اختیاری همراه با ارجاعات رگرسیون، از pnpm openclaw qa telegram --list-scenarios --provider-mode mock-openai استفاده کنید. برای هر سناریوی آداپتور زنده Telegram از --profile all استفاده کنید.

مصنوعات خروجی:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json - ورودی‌های شواهد برای بررسی‌های انتقال زنده، شامل فیلدهای پروفایل، پوشش، ارائه‌دهنده، کانال، مصنوعات، نتیجه و RTT.

اجرای بسته Telegram از همان قرارداد اعتبارنامه Telegram استفاده می‌کند. اندازه‌گیری تکرارشونده RTT بخشی از مسیر زنده معمول بسته Telegram است؛ توزیع RTT برای بررسی RTT انتخاب‌شده، در qa-evidence.json و زیر result.timing ادغام می‌شود.

OPENCLAW_QA_CREDENTIAL_SOURCE=convex \pnpm test:docker:npm-telegram-live

وقتی OPENCLAW_QA_CREDENTIAL_SOURCE=convex تنظیم شده باشد، پوشش‌دهنده زنده بسته یک اعتبارنامه kind: "telegram" اجاره می‌کند، متغیرهای محیطی بات گروه/درایور/SUT اجاره‌شده را به اجرای بسته نصب‌شده صادر می‌کند، برای اجاره Heartbeat می‌فرستد و هنگام خاموش‌شدن آن را آزاد می‌کند. پوشش‌دهنده بسته به‌طور پیش‌فرض 20 بررسی RTT با channel-canary، مهلت 30s برای RTT و در صورت انتخاب Convex، نقش Convex با مقدار maintainer را خارج از CI استفاده می‌کند. برای تنظیم اندازه‌گیری RTT بدون ایجاد فرمان جداگانه RTT یا قالب خلاصه مخصوص Telegram، OPENCLAW_NPM_TELEGRAM_RTT_SAMPLES، OPENCLAW_NPM_TELEGRAM_RTT_TIMEOUT_MS یا OPENCLAW_NPM_TELEGRAM_RTT_MAX_FAILURES را بازنویسی کنید.

QA در Discord

pnpm openclaw qa discord

یک کانال خصوصی واقعی در یک سرور Discord را با دو بات هدف می‌گیرد: بات درایور که توسط چارچوب کنترل می‌شود و بات SUT که Gateway فرزند OpenClaw آن را از طریق Plugin همراه Discord راه‌اندازی می‌کند. مدیریت اشاره در کانال، ثبت فرمان بومی /help توسط بات SUT در Discord و سناریوهای شواهد اختیاری Mantis را بررسی می‌کند.

متغیرهای محیطی الزامی هنگام --credential-source env:

• OPENCLAW_QA_DISCORD_GUILD_ID
• OPENCLAW_QA_DISCORD_CHANNEL_ID
• OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN
• OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN
• OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID - باید با شناسه کاربر بات SUT که Discord برمی‌گرداند مطابقت داشته باشد (در غیر این صورت مسیر فوراً شکست می‌خورد).

اختیاری:

• OPENCLAW_QA_DISCORD_VOICE_CHANNEL_ID کانال صوتی/استیج را برای discord-voice-autojoin انتخاب می‌کند؛ بدون آن، سناریو نخستین کانال صوتی/استیج قابل‌مشاهده برای بات SUT را انتخاب می‌کند.

سناریوهای ماژول YAML مربوط به Discord (qa/scenarios/channels/discord-*.yaml):

• discord-canary
• discord-mention-gating
• discord-native-help-command-registration
• discord-voice-autojoin - سناریوی صوتی اختیاری. به‌تنهایی اجرا می‌شود، channels.discord.voice.autoJoin را فعال می‌کند و بررسی می‌کند که وضعیت صوتی فعلی بات SUT در Discord، کانال صوتی/استیج هدف باشد. اعتبارنامه‌های Discord در Convex ممکن است شامل voiceChannelId اختیاری باشند؛ در غیر این صورت، آداپتور اجراکننده نخستین کانال صوتی/استیج قابل‌مشاهده در سرور را کشف می‌کند.
• discord-status-reactions-tool-only - سناریوی اختیاری Mantis. به‌تنهایی اجرا می‌شود، زیرا با messages.statusReactions.enabled=true پاسخ‌های سرور SUT را به حالت همیشه‌فعال و صرفاً ابزاری تغییر می‌دهد و سپس یک خط زمانی واکنش REST به‌همراه مصنوعات بصری HTML/PNG ثبت می‌کند. گزارش‌های پیش/پس از Mantis مصنوعات MP4 ارائه‌شده توسط سناریو را نیز با نام‌های baseline.mp4 و candidate.mp4 حفظ می‌کنند.
• discord-thread-reply-filepath-attachment - سناریوی اختیاری Mantis؛ سناریوهای Mantis در Discord را ببینید.

سناریوی پیوستن خودکار به صدای Discord را صریحاً اجرا کنید:

pnpm openclaw qa discord \  --scenario discord-voice-autojoin \  --provider-mode mock-openai

سناریوی واکنش وضعیت Mantis را صریحاً اجرا کنید:

pnpm openclaw qa discord \  --scenario discord-status-reactions-tool-only \  --provider-mode live-frontier \  --model openai/gpt-5.6-luna \  --alt-model openai/gpt-5.6-luna \  --fast

مصنوعات خروجی:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json - ورودی‌های شواهد برای بررسی‌های انتقال زنده.
• discord-qa-reaction-timelines.json و discord-status-reactions-tool-only-timeline.png هنگام اجرای سناریوی واکنش وضعیت.

QA در Slack

pnpm openclaw qa slack

یک کانال خصوصی واقعی Slack را با دو بات مجزا هدف می‌گیرد: بات درایور که توسط چارچوب کنترل می‌شود و بات SUT که Gateway فرزند OpenClaw آن را از طریق Plugin همراه Slack راه‌اندازی می‌کند.

متغیرهای محیطی الزامی هنگام --credential-source env:

• OPENCLAW_QA_SLACK_CHANNEL_ID
• OPENCLAW_QA_SLACK_DRIVER_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_APP_TOKEN

اختیاری:

• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR نقاط بررسی تأیید بصری را برای Mantis فعال می‌کند. آداپتور <scenario>.pending.json و <scenario>.resolved.json را می‌نویسد و سپس منتظر فایل‌های منطبق .ack.json می‌ماند.
• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_TIMEOUT_MS مهلت تأیید نقطه بررسی را بازنویسی می‌کند. مقدار پیش‌فرض 120000 است.

سناریوهای متعارف YAML که از طریق آداپتور زنده Slack ارائه می‌شوند:

• thread-follow-up
• thread-isolation

سناریوهای ماژول YAML مربوط به Slack (qa/scenarios/channels/slack-*.yaml):

• slack-canary
• slack-mention-gating
• slack-allowlist-block
• slack-channel-disabled-warning - کاوش اختیاری در Slack واقعی که تأیید می‌کند یک کانال پیکربندی‌شده و غیرفعال، بدون پاسخ‌دادن یک هشدار ساخت‌یافته صادر می‌کند.
• slack-top-level-reply-shape
• slack-restart-resume
• slack-progress-commentary-true، slack-progress-commentary-false، slack-progress-commentary-omitted و slack-progress-commentary-verbose-dedupe - کاوش‌های اختیاری در Slack واقعی برای کنترل‌های مستقل توضیحات/پیشرفت ابزار، پیش‌فرض قدیمی در صورت حذف کلید و رفتار تحویل یک‌باره هنگامی که پیشرفت تفصیلی ماندگار فعال است.
• slack-reaction-glyph-native - سناریوی اختیاری واکنش ابزار پیام به‌صورت زنده. به عامل دستور می‌دهد نویسه دقیق ✅ را ارسال کند و تأیید می‌کند Slack مقدار white_check_mark را برای بات SUT روی پیام هدف ذخیره کرده است.
• slack-chart-presentation-native - سناریوی اختیاری نمودار قابل‌انتقال که بلوک بومی data_visualization و متن دسترس‌پذیر دقیق را بررسی می‌کند.
• slack-table-presentation-native - سناریوی اختیاری جدول قابل‌انتقال که بلوک بومی data_table، ردیف‌های دقیق و متن دسترس‌پذیر را بررسی می‌کند.
• slack-table-invalid-blocks-fallback - سناریوی اختیاری انتقال مستقیم که یک جدول خام، از نظر ساختاری خوانا و فراتر از محدودیت را با 101 ردیف داده به‌علاوه سرآیند آن از مسیر ارسال تولیدی Slack می‌فرستد، ثابت می‌کند خود Slack مقدار invalid_blocks را برمی‌گرداند و بررسی می‌کند که جایگزین ذخیره‌شده با قالب‌بندی غیرفعال کامل است و هیچ بلوک داده بومی ندارد. جزئیات سناریو فقط شواهد امن مربوط به کد خطا، تعداد و مقادیر بولی را نگه می‌دارند.
• slack-approval-exec-native - سناریوی اختیاری تأیید اجرای بومی Slack. از طریق Gateway یک تأیید اجرا درخواست می‌کند، وجود دکمه‌های بومی تأیید در پیام Slack را بررسی می‌کند، آن را تعیین‌تکلیف می‌کند و به‌روزرسانی تعیین‌تکلیف‌شده Slack را بررسی می‌کند.
• slack-approval-plugin-native - سناریوی اختیاری تأیید بومی Plugin در Slack. ارسال تأیید اجرا و Plugin را هم‌زمان فعال می‌کند تا رویدادهای Plugin توسط مسیریابی تأیید اجرا سرکوب نشوند، سپس همان مسیر رابط کاربری بومی در انتظار/تعیین‌تکلیف‌شده Slack را بررسی می‌کند.
• slack-codex-approval-exec-native - سناریوی اختیاری تأیید فرمان Codex Guardian. Plugin مربوط به Codex را در حالت Guardian فعال می‌کند، یک نوبت عامل Gateway با مبدأ Slack را از طریق چارچوب app-server مربوط به Codex مسیریابی می‌کند، منتظر اعلان بومی تأیید Plugin در Slack برای openclaw-codex-app-server می‌ماند، آن را تعیین‌تکلیف می‌کند و بررسی می‌کند نوبت Codex با نشانگرهای مورد انتظار خروجی فرمان و دستیار پایان یابد.
• slack-codex-approval-plugin-native - سناریوی اختیاری تأیید فایل Codex Guardian. از دستور apply_patch خارج از فضای کاری استفاده می‌کند تا Codex مسیر تأیید تغییر فایل در app-server را صادر کند، سپس همان مسیر بومی تأیید در انتظار/تعیین‌تکلیف‌شده Slack، نشانگر نهایی دستیار و محتوای دقیق فایل را پیش از پاک‌سازی بررسی می‌کند.

سناریوهای تأیید Codex به یک openai/* یا codex/* --model، اعتبارنامه‌های معمول مدل زنده و احراز هویت Codex یا احراز هویت با کلید API مورد پذیرش Plugin مربوط به Codex نیاز دارند. جزئیات سناریو شامل متد app-server مربوط به Codex، کلید مدل انتخاب‌شده Codex، وضعیت نهایی نوبت Codex و بررسی نشانگر عملیات در کنار فراداده ویرایش‌شده تأیید Slack است.

مصنوعات خروجی:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json - ورودی‌های شواهد برای بررسی‌های انتقال زنده.
• approval-checkpoints/ - فقط هنگامی که Mantis مقدار OPENCLAW_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 بتواند رویدادها را دریافت کند.

استفاده از یک فضای کاری Slack اختصاص‌یافته به QA را بر استفاده مجدد از فضای کاری تولیدی ترجیح دهید.

مانیفست SUT در ادامه، نصب تولیدی Plugin همراه Slack (extensions/slack/src/setup-shared.ts:12) را عمداً به مجوزها و رویدادهای تحت پوشش مجموعه QA زنده Slack محدود می‌کند. برای راه‌اندازی کانال تولیدی به همان شکلی که کاربران می‌بینند، راه‌اندازی سریع کانال Slack را ببینید؛ جفت Driver/SUT در QA عمداً جداست، زیرا مسیر به دو شناسه کاربر بات مجزا در یک فضای کاری نیاز دارد.

1. برنامه Driver را ایجاد کنید

به api.slack.com/apps بروید ← Create New App ← From a manifest ← فضای کاری QA را انتخاب کنید، مانیفست زیر را جای‌گذاری کنید، سپس Install to Workspace را انتخاب کنید:

{  "display_information": {    "name": "OpenClaw QA Driver",    "description": "بات درایور آزمایش برای مسیر زنده QA در Slack متعلق به OpenClaw"  },  "features": {    "bot_user": {      "display_name": "OpenClaw QA Driver",      "always_online": true    }  },  "oauth_config": {    "scopes": {      "bot": ["chat:write", "channels:history", "groups:history", "users:read"]    }  },  "settings": {    "socket_mode_enabled": false  }}

Bot User OAuth Token (xoxb-...) را کپی کنید؛ این مقدار به driverBotToken تبدیل می‌شود. درایور فقط باید پیام ارسال کند و خود را شناسایی کند؛ بدون رویداد و بدون Socket Mode.

2. برنامه SUT را ایجاد کنید

در همان فضای کاری، Create New App → From a manifest را تکرار کنید. این برنامه QA عمداً از نسخه محدودتری از مانیفست تولیدی Plugin همراه Slack (extensions/slack/src/setup-shared.ts:12) استفاده می‌کند: دامنه‌ها و رویدادهای واکنش حذف شده‌اند، زیرا مجموعه QA زنده Slack هنوز مدیریت واکنش را پوشش نمی‌دهد.

{  "display_information": {    "name": "OpenClaw QA SUT",    "description": "OpenClaw QA SUT connector for OpenClaw"  },  "features": {    "bot_user": {      "display_name": "OpenClaw QA SUT",      "always_online": true    },    "app_home": {      "home_tab_enabled": true,      "messages_tab_enabled": true,      "messages_tab_read_only_enabled": false    }  },  "oauth_config": {    "scopes": {      "bot": [        "app_mentions:read",        "assistant:write",        "channels:history",        "channels:read",        "chat:write",        "commands",        "emoji:read",        "files:read",        "files:write",        "groups:history",        "groups:read",        "im:history",        "im:read",        "im:write",        "mpim:history",        "mpim:read",        "mpim:write",        "pins:read",        "pins:write",        "usergroups:read",        "users:read"      ]    }  },  "settings": {    "socket_mode_enabled": true,    "event_subscriptions": {      "bot_events": [        "app_home_opened",        "app_mention",        "channel_rename",        "member_joined_channel",        "member_left_channel",        "message.channels",        "message.groups",        "message.im",        "message.mpim",        "pin_added",        "pin_removed"      ]    }  }}

پس از اینکه Slack برنامه را ایجاد کرد، در صفحهٔ تنظیمات آن دو کار انجام دهید:

• Install to Workspace → مقدار Bot User OAuth Token را کپی کنید → این مقدار به sutBotToken تبدیل می‌شود.
• Basic Information → App-Level Tokens → Generate Token and Scopes → محدودهٔ connections:write را اضافه کنید → ذخیره کنید → مقدار xapp-... را کپی کنید → این مقدار به sutAppToken تبدیل می‌شود.

با فراخوانی auth.test روی هر توکن، بررسی کنید که دو بات شناسه‌های کاربری متمایزی دارند. محیط اجرا، راه‌انداز و SUT را با شناسهٔ کاربری از هم تشخیص می‌دهد؛ استفادهٔ مجدد از یک برنامه برای هر دو، بلافاصله در دروازه‌گذاری اشاره شکست می‌خورد.

3. ایجاد کانال

در فضای کاری QA یک کانال ایجاد کنید (برای مثال #openclaw-qa) و هر دو بات را از داخل کانال دعوت کنید:

/invite @OpenClaw QA Driver/invite @OpenClaw QA SUT

شناسهٔ Cxxxxxxxxxx را از channel info → About → Channel ID کپی کنید؛ این مقدار به channelId تبدیل می‌شود. کانال عمومی قابل استفاده است؛ اگر از کانال خصوصی استفاده کنید، هر دو برنامه از قبل groups:history را دارند، بنابراین خواندن تاریخچه توسط هارنس همچنان موفق خواهد بود.

4. ثبت اطلاعات احراز هویت

دو گزینه وجود دارد. برای اشکال‌زدایی روی یک دستگاه از متغیرهای محیطی استفاده کنید (چهار متغیر OPENCLAW_QA_SLACK_* را تنظیم کنید و --credential-source env را بگذرانید)، یا مخزن اشتراکی Convex را مقداردهی اولیه کنید تا CI و دیگر نگه‌دارندگان بتوانند آن‌ها را اجاره کنند.

برای مخزن Convex، چهار فیلد را در یک فایل JSON بنویسید:

{  "channelId": "Cxxxxxxxxxx",  "driverBotToken": "xoxb-...",  "sutBotToken": "xoxb-...",  "sutAppToken": "xapp-..."}

درحالی‌که OPENCLAW_QA_CONVEX_SITE_URL و OPENCLAW_QA_CONVEX_SECRET_MAINTAINER در پوستهٔ شما صادر شده‌اند، ثبت و تأیید را انجام دهید:

pnpm openclaw qa credentials add \  --kind slack \  --payload-file slack-creds.json \  --note "QA Slack pool seed" pnpm openclaw qa credentials list --kind slack --status all --json

انتظار می‌رود count: 1 و status: "active" وجود داشته باشند و فیلد lease وجود نداشته باشد.

5. تأیید سرتاسری

مسیر را به‌صورت محلی اجرا کنید تا تأیید شود هر دو بات می‌توانند از طریق کارگزار با یکدیگر ارتباط برقرار کنند:

pnpm openclaw qa slack \  --credential-source convex \  --credential-role maintainer \  --output-dir .artifacts/qa-e2e/slack-local

اجرای سبز در زمانی بسیار کمتر از 30 ثانیه تکمیل می‌شود و qa-suite-report.md هر دو slack-canary و slack-mention-gating را با وضعیت pass نشان می‌دهد. اگر مسیر حدود 90 ثانیه معطل بماند و با Convex credential pool exhausted for kind "slack" خارج شود، یا مخزن خالی است یا همهٔ ردیف‌ها اجاره شده‌اند؛ qa credentials list --kind slack --status all --json مشخص می‌کند کدام مورد رخ داده است.

QA ‏WhatsApp

pnpm openclaw qa whatsapp

دو حساب اختصاصی WhatsApp Web را هدف می‌گیرد: یک حساب راه‌انداز که توسط هارنس کنترل می‌شود و یک حساب SUT که Gateway فرزند OpenClaw آن را از طریق Plugin همراه WhatsApp راه‌اندازی می‌کند.

متغیرهای محیطی لازم هنگام --credential-source env:

• OPENCLAW_QA_WHATSAPP_DRIVER_PHONE_E164
• OPENCLAW_QA_WHATSAPP_SUT_PHONE_E164
• OPENCLAW_QA_WHATSAPP_DRIVER_AUTH_ARCHIVE_BASE64
• OPENCLAW_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 را فعال می‌کند.

سناریوهای YAML ‏WhatsApp ‏(qa/scenarios/channels/whatsapp-*.yaml):

• خط مبنا و دروازه‌گذاری گروه: 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 از یک پیام مستقیم واقعی راه‌انداز آغاز می‌شود، به مدل اجازه می‌دهد ابزار 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-outbound-send-serialization، whatsapp-group-outbound-media، whatsapp-group-outbound-poll، whatsapp-message-actions، whatsapp-reply-context-isolation، whatsapp-reply-delivery-shape. این موارد عمداً اعلان مدل را دور می‌زنند و قراردادهای قطعی send، poll و message.action در Gateway/کانال را اثبات می‌کنند.
• پوشش کنترل دسترسی: 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.

کاتالوگ درحال‌حاضر شامل 52 سناریو است. مسیر پیش‌فرض live-frontier برای پوشش سریع دود در اندازهٔ کوچک 8 سناریویی نگه داشته شده است. مسیر پیش‌فرض mock-openai تعداد 39 سناریو را به‌صورت قطعی از طریق انتقال واقعی WhatsApp اجرا می‌کند و فقط خروجی مدل را شبیه‌سازی می‌کند؛ سناریوهای تأیید و چند بررسی سنگین‌تر/مسدودکننده همچنان باید با شناسهٔ سناریو به‌صراحت مشخص شوند.

راه‌انداز QA ‏WhatsApp رویدادهای زندهٔ ساخت‌یافته (text، media، location، reaction و poll) را مشاهده می‌کند و می‌تواند رسانه، نظرسنجی، مخاطب، موقعیت مکانی و برچسب را به‌طور فعال ارسال کند. QA Lab آن راه‌انداز را از طریق سطح بستهٔ @openclaw/whatsapp/api.js وارد می‌کند و به فایل‌های خصوصی محیط اجرای WhatsApp دسترسی مستقیم ندارد. برای مشاهدات گروهی، fromJid شناسهٔ JID گروه است، درحالی‌که participantJid و fromPhoneE164 فرستندهٔ شرکت‌کننده را مشخص می‌کنند. محتوای پیام به‌طور پیش‌فرض حذف محرمانه می‌شود. کاوش‌های مستقیم Gateway برای نظرسنجی، بارگذاری فایل، رسانه، نظرسنجی گروهی، رسانهٔ گروهی و شکل پاسخ، بررسی‌های قرارداد انتقال/API هستند؛ این موارد به‌عنوان اثبات اینکه یک درخواست کاربر باعث شده عامل همان کنش را انتخاب کند، در نظر گرفته نمی‌شوند. اثبات کنش در مسیر کاربر از سناریوهایی مانند whatsapp-agent-message-action-react و whatsapp-group-agent-message-action-react به دست می‌آید که در آن‌ها راه‌انداز یک پیام عادی WhatsApp می‌فرستد و QA Lab مصنوع بومی حاصل در WhatsApp را مشاهده می‌کند. جزئیات سناریوهای WhatsApp شامل رویکرد هر سناریو (user-path، direct-gateway یا native-approval) است تا شواهد با قراردادی قوی‌تر از آنچه واقعاً اثبات می‌کنند اشتباه گرفته نشوند.

مصنوعات خروجی:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json - ورودی‌های شواهد برای بررسی‌های انتقال زنده.

مخزن اطلاعات احراز هویت Convex

مسیرهای Discord، Slack، Telegram و WhatsApp می‌توانند به‌جای خواندن متغیرهای محیطی بالا، اطلاعات احراز هویت را از یک مخزن اشتراکی Convex اجاره کنند. --credential-source convex را بگذرانید (یا OPENCLAW_QA_CREDENTIAL_SOURCE=convex را تنظیم کنید)؛ QA Lab یک اجارهٔ انحصاری دریافت می‌کند، در طول اجرا Heartbeat آن را حفظ می‌کند و هنگام خاموش‌شدن آن را آزاد می‌کند. انواع مخزن عبارت‌اند از "discord"، "slack"، "telegram" و "whatsapp".

شکل‌های بار داده که کارگزار در admin/add اعتبارسنجی می‌کند:

• Discord ‏(kind: "discord"): { guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string }.
• 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 } - فقط برای اثبات Telegram Desktop در Mantis. مسیرهای عمومی QA Lab نباید این نوع را دریافت کنند.
• WhatsApp ‏(kind: "whatsapp"): { driverPhoneE164: string, sutPhoneE164: string, driverAuthArchiveBase64: string, sutAuthArchiveBase64: string, groupJid?: string } - شماره‌تلفن‌ها باید رشته‌های متمایز E.164 باشند.

گردش‌کار اثبات Telegram Desktop در Mantis یک اجارهٔ انحصاری Convex از نوع telegram-user را هم‌زمان برای راه‌انداز CLI ‏TDLib و شاهد Telegram Desktop نگه می‌دارد و پس از انتشار اثبات آن را آزاد می‌کند.

هنگامی که یک PR به تفاوت تصویری قطعی نیاز دارد، Mantis می‌تواند از همان پاسخ مدل شبیه‌سازی‌شده در main و سر PR استفاده کند، درحالی‌که قالب‌بند Telegram یا لایهٔ تحویل تغییر می‌کند. پیش‌فرض‌های ضبط برای دیدگاه‌های PR تنظیم شده‌اند: کلاس استاندارد Crabbox، ضبط دسکتاپ با 24fps، فایل GIF حرکتی با 24fps و عرض پیش‌نمایش 1920px. دیدگاه‌های قبل/بعد باید یک بستهٔ تمیز منتشر کنند که فقط شامل فایل‌های GIF موردنظر باشد.

مسیرهای Slack نیز می‌توانند از مخزن استفاده کنند. بررسی شکل بار دادهٔ Slack درحال‌حاضر به‌جای کارگزار در اجراکنندهٔ QA ‏Slack قرار دارد؛ از { channelId: string, driverBotToken: string, sutBotToken: string, sutAppToken: string } همراه با شناسهٔ کانال Slack مانند Cxxxxxxxxxx استفاده کنید. برای تأمین برنامه و محدوده‌ها به راه‌اندازی فضای کاری Slack مراجعه کنید.

متغیرهای محیطی عملیاتی و قرارداد نقطهٔ پایانی کارگزار Convex در آزمایش → اطلاعات احراز هویت اشتراکی Telegram از طریق Convex قرار دارند (نام این بخش به پیش از ایجاد مخزن چندکاناله مربوط است؛ معناشناسی اجاره بین انواع مختلف مشترک است).

بذرهای مبتنی بر مخزن

دارایی‌های بذر در qa/ قرار دارند:

• qa/scenarios/index.yaml
• qa/scenarios/<theme>/*.yaml

این موارد عمداً در git قرار دارند تا طرح QA هم برای انسان‌ها و هم برای عامل قابل‌مشاهده باشد.

qa-lab یک اجراکنندهٔ عمومی سناریوی YAML باقی می‌ماند. هر فایل YAML سناریو منبع حقیقت یک اجرای آزمایش است و باید موارد زیر را تعریف کند:

• title سطح بالا
• فرادادهٔ scenario
• فرادادهٔ اختیاری دسته‌بندی، قابلیت، مسیر و ریسک در scenario
• ارجاعات مستندات و کد در scenario
• نیازمندی‌های اختیاری Plugin در scenario
• وصلهٔ اختیاری پیکربندی Gateway در scenario
• flow اجرایی سطح بالا برای سناریوهای جریان، یا scenario.execution.kind / scenario.execution.path برای سناریوهای Vitest و Playwright

سطح زمان‌اجرای قابل‌استفاده‌مجدد که زیربنای flow است، عمومی و سراسری باقی می‌ماند. برای مثال، سناریوهای YAML می‌توانند کمک‌ابزارهای سمت انتقال را با کمک‌ابزارهای سمت مرورگر ترکیب کنند که رابط کاربری کنترل تعبیه‌شده را از طریق درز Gateway browser.request هدایت می‌کنند، بدون اینکه اجراکننده‌ای ویژه اضافه شود.

فایل‌های سناریو باید بر اساس قابلیت محصول گروه‌بندی شوند، نه پوشهٔ درخت منبع. هنگام جابه‌جایی فایل‌ها، شناسه‌های سناریو را ثابت نگه دارید؛ برای قابلیت ردیابی پیاده‌سازی از docsRefs و codeRefs استفاده کنید.

فهرست پایه باید به‌اندازه‌ای گسترده بماند که موارد زیر را پوشش دهد:

• پیام خصوصی و گفت‌وگوی کانال
• رفتار رشته
• چرخهٔ عمر کنش پیام
• فراخوان‌های برگشتی Cron
• بازیابی حافظه
• تعویض مدل
• تحویل به زیرعامل
• خواندن مخزن و مستندات
• یک وظیفهٔ ساخت کوچک مانند Lobster Invaders

مسیرهای شبیه‌سازی ارائه‌دهنده

qa suite دو مسیر شبیه‌سازی محلی ارائه‌دهنده دارد:

• mock-openai شبیه‌ساز آگاه از سناریوی OpenClaw است. این مسیر همچنان مسیر شبیه‌سازی قطعی پیش‌فرض برای QA مبتنی بر مخزن و دروازه‌های برابری است.
• aimock یک سرور ارائه‌دهنده مبتنی بر AIMock را برای پوشش آزمایشی پروتکل، فیکسچر، ضبط/بازپخش و آشوب راه‌اندازی می‌کند. این مسیر افزایشی است و جایگزین توزیع‌کنندهٔ سناریوی mock-openai نمی‌شود.

پیاده‌سازی مسیر ارائه‌دهنده در extensions/qa-lab/src/providers/ قرار دارد. هر ارائه‌دهنده مالک پیش‌فرض‌های خود، راه‌اندازی سرور محلی، پیکربندی مدل Gateway، نیازهای آماده‌سازی نمایهٔ احراز هویت و پرچم‌های قابلیت زنده/شبیه‌سازی است. کد مشترک مجموعه و Gateway به‌جای شاخه‌بندی بر اساس نام ارائه‌دهندگان، از طریق رجیستری ارائه‌دهنده مسیریابی می‌شود.

تطبیق‌دهنده‌های انتقال

qa-lab مالک یک درز انتقال عمومی برای سناریوهای QA مبتنی بر YAML است. qa-channel پیش‌فرض مصنوعی است. crabline سرورهای محلی هم‌شکل با ارائه‌دهنده را راه‌اندازی می‌کند و Pluginهای عادی کانال OpenClaw را در برابر آن‌ها اجرا می‌کند. live برای اعتبارنامه‌های واقعی ارائه‌دهنده و کانال‌های خارجی رزرو شده است.

در سطح معماری، تفکیک به این صورت است:

• qa-lab مالک اجرای عمومی سناریو، هم‌زمانی کارگرها، نوشتن مصنوعات و گزارش‌دهی است.
• تطبیق‌دهندهٔ انتقال مالک پیکربندی Gateway، آمادگی، مشاهدهٔ ورودی و خروجی، کنش‌های انتقال و وضعیت نرمال‌شدهٔ انتقال است.
• فایل‌های سناریوی YAML در qa/scenarios/ اجرای آزمون را تعریف می‌کنند؛ qa-lab سطح زمان‌اجرای قابل‌استفاده‌مجدد برای اجرای آن‌ها را فراهم می‌کند.

افزودن یک کانال

افزودن یک کانال به سامانهٔ QA مبتنی بر YAML نیازمند پیاده‌سازی کانال به‌همراه بسته‌ای از سناریوهاست که قرارداد کانال را تمرین کند. برای پوشش CI دود، سرور محلی ارائه‌دهندهٔ Crabline متناظر را اضافه کنید و آن را از طریق درایور crabline در دسترس قرار دهید.

وقتی میزبان مشترک qa-lab می‌تواند مالک جریان باشد، ریشهٔ فرمان QA سطح‌بالای جدیدی اضافه نکنید.

qa-lab مالک سازوکارهای میزبان مشترک است:

• ریشهٔ فرمان openclaw qa
• راه‌اندازی و جمع‌آوری مجموعه
• هم‌زمانی کارگرها
• نوشتن مصنوعات
• تولید گزارش
• اجرای سناریو
• نام‌های مستعار سازگاری برای سناریوهای قدیمی‌تر qa-channel

Pluginهای اجراکننده مالک قرارداد انتقال هستند:

• نحوهٔ سوارشدن openclaw qa <runner> زیر ریشهٔ مشترک qa
• نحوهٔ پیکربندی Gateway برای آن انتقال
• نحوهٔ بررسی آمادگی
• نحوهٔ تزریق رویدادهای ورودی
• نحوهٔ مشاهدهٔ پیام‌های خروجی
• نحوهٔ ارائهٔ رونوشت‌ها و وضعیت نرمال‌شدهٔ انتقال
• نحوهٔ اجرای کنش‌های مبتنی بر انتقال
• نحوهٔ انجام بازنشانی یا پاک‌سازی ویژهٔ انتقال

حداقل معیار پذیرش برای یک کانال جدید:

1. qa-lab را به‌عنوان مالک ریشهٔ مشترک qa نگه دارید.
2. اجراکنندهٔ انتقال را روی درز میزبان مشترک qa-lab پیاده‌سازی کنید.
3. سازوکارهای ویژهٔ انتقال را داخل Plugin اجراکننده یا مهار کانال نگه دارید.
4. اجراکننده را به‌صورت openclaw qa <runner> سوار کنید، نه اینکه یک فرمان ریشهٔ رقیب ثبت کنید. Pluginهای اجراکننده باید qaRunners را در openclaw.plugin.json اعلام کنند و آرایهٔ متناظر qaRunnerCliRegistrations را از runtime-api.ts صادر کنند. runtime-api.ts را سبک نگه دارید؛ CLI تنبل و اجرای اجراکننده باید پشت نقاط ورود جداگانه باقی بمانند. یک adapterFactory اختیاری، انتقال را بدون تغییر فهرست سناریوهای موجود فرمان در اختیار سناریوهای مشترک قرار می‌دهد. پارتیشن‌های هم‌کانال به‌صورت ترتیبی اجرا می‌شوند، مگر اینکه کارخانه اعلام کند هر نمونه مالک اعتبارنامه‌های ایزوله یا سرورهای یک‌بارمصرف، وضعیت Gateway و مسیرهای مصنوعات است.
5. سناریوهای YAML را در پوشه‌های موضوعی qa/scenarios/ بنویسید یا تطبیق دهید.
6. برای سناریوهای جدید از کمک‌ابزارهای عمومی سناریو استفاده کنید.
7. نام‌های مستعار سازگاری موجود را فعال نگه دارید، مگر اینکه مخزن در حال انجام مهاجرتی عمدی باشد.

قاعدهٔ تصمیم‌گیری سخت‌گیرانه است:

• اگر رفتاری را بتوان یک‌بار در qa-lab بیان کرد، آن را در qa-lab قرار دهید.
• اگر رفتار به انتقال یک کانال وابسته است، آن را در Plugin اجراکننده یا مهار Plugin همان کانال نگه دارید.
• اگر سناریویی به قابلیت جدیدی نیاز دارد که بیش از یک کانال می‌تواند از آن استفاده کند، به‌جای شاخه‌ای ویژهٔ کانال در suite.ts، یک کمک‌ابزار عمومی اضافه کنید.
• اگر رفتاری فقط برای یک انتقال معنا دارد، سناریو را ویژهٔ انتقال نگه دارید و این موضوع را در قرارداد سناریو صریح کنید.

نام کمک‌ابزارهای سناریو

کمک‌ابزارهای عمومی ترجیحی برای سناریوهای جدید:

• waitForTransportReady
• waitForChannelReady
• injectInboundMessage
• injectOutboundMessage
• waitForTransportOutboundMessage
• waitForChannelOutboundMessage
• waitForNoTransportOutbound
• getTransportSnapshot
• readTransportMessage
• readTransportTranscript
• formatTransportTranscript
• resetTransport

نام‌های مستعار سازگاری برای سناریوهای موجود همچنان در دسترس‌اند - waitForQaChannelReady، waitForOutboundMessage، waitForNoOutbound، formatConversationTranscript، resetBus - اما سناریوهای جدید باید از نام‌های عمومی استفاده کنند. نام‌های مستعار برای جلوگیری از مهاجرت یک‌باره وجود دارند، نه به‌عنوان الگوی آینده.

گزارش‌دهی

qa-lab یک گزارش پروتکل Markdown از خط زمانی گذرگاه مشاهده‌شده صادر می‌کند. گزارش باید به این پرسش‌ها پاسخ دهد:

• چه چیزهایی کار کردند
• چه چیزهایی شکست خوردند
• چه چیزهایی مسدود باقی ماندند
• افزودن چه سناریوهای پیگیری‌ای ارزشمند است

برای فهرست سناریوهای موجود - که هنگام برآورد اندازهٔ کار پیگیری یا متصل‌کردن یک انتقال جدید مفید است - pnpm openclaw qa coverage را اجرا کنید (برای خروجی ماشین‌خوان، --json را اضافه کنید). هنگام انتخاب اثبات متمرکز برای یک رفتار یا مسیر فایل تغییریافته، pnpm openclaw qa coverage --match <query> را اجرا کنید. گزارش تطبیق در فرادادهٔ سناریو، ارجاع‌های مستندات، ارجاع‌های کد، شناسه‌های پوشش، Pluginها و نیازمندی‌های ارائه‌دهنده جست‌وجو می‌کند و سپس هدف‌های منطبق 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 داوری‌شده بنویسید:

pnpm openclaw qa character-eval \  --model openai/gpt-5.6-luna,thinking=medium,fast \  --model openai/gpt-5.2,thinking=xhigh \  --model openai/gpt-5,thinking=xhigh \  --model anthropic/claude-opus-4-8,thinking=high \  --model anthropic/claude-sonnet-4-6,thinking=high \  --model zai/glm-5.1,thinking=high \  --model moonshot/kimi-k2.5,thinking=high \  --model google/gemini-3.1-pro-preview,thinking=high \  --judge-model openai/gpt-5.6-sol,thinking=xhigh,fast \  --judge-model anthropic/claude-opus-4-8,thinking=high \  --blind-judge-models \  --concurrency 16 \  --judge-concurrency 16

این فرمان فرایندهای فرزند Gateway محلی QA را اجرا می‌کند، نه Docker. سناریوهای ارزیابی شخصیت باید پرسونا را از طریق SOUL.md تنظیم کنند و سپس نوبت‌های عادی کاربر مانند گفت‌وگو، کمک دربارهٔ فضای کاری و وظایف کوچک فایل را اجرا کنند. نباید به مدل نامزد گفته شود که در حال ارزیابی است. فرمان هر رونوشت کامل را حفظ می‌کند، آمار پایهٔ اجرا را ثبت می‌کند و سپس از مدل‌های داور در حالت سریع با استدلال xhigh، در صورت پشتیبانی، می‌خواهد اجراها را بر اساس طبیعی‌بودن، حال‌وهوا و طنز رتبه‌بندی کنند. هنگام مقایسهٔ ارائه‌دهندگان از --blind-judge-models استفاده کنید: اعلان داور همچنان همهٔ رونوشت‌ها و وضعیت اجرا را دریافت می‌کند، اما ارجاع‌های نامزد با برچسب‌های خنثی مانند candidate-01 جایگزین می‌شوند؛ گزارش پس از تجزیه، رتبه‌بندی‌ها را دوباره به ارجاع‌های واقعی نگاشت می‌کند.

اجرای نامزدها به‌طور پیش‌فرض از تفکر high استفاده می‌کند، با medium برای GPT-5.6 Luna و xhigh برای ارجاع‌های قدیمی‌تر ارزیابی OpenAI که از آن پشتیبانی می‌کنند. یک نامزد مشخص را به‌صورت درون‌خطی با --model provider/model,thinking=<level> بازنویسی کنید؛ گزینه‌های درون‌خطی همچنین از fast، no-fast و fast=<bool> پشتیبانی می‌کنند. --thinking <level> همچنان یک مقدار پشتیبان سراسری تنظیم می‌کند و شکل قدیمی‌تر --model-thinking <provider/model=level> برای سازگاری نگه داشته شده است. ارجاع‌های نامزد OpenAI به‌طور پیش‌فرض در حالت سریع اجرا می‌شوند تا در صورت پشتیبانی ارائه‌دهنده، پردازش اولویت‌دار استفاده شود. تنها زمانی --fast را ارسال کنید که می‌خواهید حالت سریع را برای همهٔ مدل‌های نامزد اجباری کنید. مدت اجرای نامزدها و داورها برای تحلیل معیار در گزارش ثبت می‌شود، اما اعلان‌های داور صراحتاً می‌گویند بر اساس سرعت رتبه‌بندی نکنند. اجرای مدل‌های نامزد و داور هر دو به‌طور پیش‌فرض هم‌زمانی 16 دارند. وقتی محدودیت‌های ارائه‌دهنده یا فشار Gateway محلی اجرا را بیش‌ازحد پُرنویز می‌کند، --concurrency یا --judge-concurrency را کاهش دهید.

وقتی هیچ --model نامزدی ارسال نشود، ارزیابی شخصیت به‌طور پیش‌فرض از openai/gpt-5.6-luna، 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 استفاده می‌کند. وقتی هیچ --judge-model ارسال نشود، داورها به‌طور پیش‌فرض openai/gpt-5.6-sol,thinking=xhigh,fast و anthropic/claude-opus-4-8,thinking=high هستند.

مستندات مرتبط

• کارت امتیاز بلوغ
• بستهٔ معیار عامل شخصی
• کانال QA
• آزمون
• داشبورد