QA अवलोकन

निजी QA स्टैक का उद्देश्य OpenClaw को एकल यूनिट टेस्ट की तुलना में अधिक यथार्थवादी, चैनल-सदृश तरीके से परखना है।

मौजूदा घटक:

• extensions/qa-channel: DM, चैनल, थ्रेड, रिएक्शन, एडिट और डिलीट सतहों वाला सिंथेटिक संदेश चैनल।
• extensions/qa-lab: ट्रांसक्रिप्ट देखने, इनबाउंड संदेश इंजेक्ट करने और Markdown रिपोर्ट निर्यात करने के लिए डिबगर UI और QA बस।
• extensions/qa-matrix, भविष्य के रनर plugins: लाइव-ट्रांसपोर्ट अडैप्टर जो चाइल्ड QA gateway के अंदर वास्तविक चैनल चलाते हैं।
• qa/: किकऑफ कार्य और बेसलाइन QA परिदृश्यों के लिए रिपॉजिटरी-समर्थित सीड एसेट।
• Mantis: उन बग के लिए लाइव सत्यापन से पहले और बाद की जांच जिन्हें वास्तविक ट्रांसपोर्ट, ब्राउज़र स्क्रीनशॉट, VM स्थिति और PR साक्ष्य चाहिए।

कमांड सतह

हर QA फ्लो pnpm openclaw qa <subcommand> के अंतर्गत चलता है। कई के पास pnpm qa:* स्क्रिप्ट उपनाम हैं; दोनों रूप समर्थित हैं।

Profile-backed qa run taxonomy.yaml से सदस्यता पढ़ता है, फिर resolved scenarios को qa suite के माध्यम से dispatch करता है। --surface और --category अलग lanes परिभाषित करने के बजाय चयनित profile को filter करते हैं। परिणामी qa-evidence.json में selected-category counts और missing coverage IDs के साथ profile scorecard summary शामिल होती है; individual evidence entries tests, coverage roles, और results के लिए सत्य का स्रोत बनी रहती हैं। Taxonomy feature coverage IDs exact proof targets हैं, aliases नहीं। Primary scenario coverage matching IDs पूरा करता है; secondary coverage advisory रहता है। Coverage IDs lowercase alphanumeric/dash segments के साथ dotted namespace.behavior form उपयोग करते हैं; profile, surface, और category IDs अब भी मौजूदा dashed या dotted taxonomy IDs उपयोग कर सकते हैं। Slim evidence प्रति-entry execution हटाता है और evidenceMode: "slim" सेट करता है; smoke-ci default रूप से slim है, और --evidence-mode full full entries बहाल करता है:

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

Mock model providers और Crabline local provider servers के साथ deterministic profile proof के लिए smoke-ci उपयोग करें। लाइव channels के विरुद्ध Stable/LTS proof के लिए release उपयोग करें। all केवल explicit full-taxonomy evidence runs के लिए उपयोग करें; यह हर active maturity category चुनता है और QA Profile Evidence workflow के माध्यम से qa_profile=all के साथ dispatch किया जा सकता है। जब किसी command को OpenClaw root profile की भी जरूरत हो, root profile को QA command से पहले रखें:

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

ऑपरेटर फ्लो

मौजूदा QA operator flow दो-pane QA site है:

• बाएं: agent के साथ Gateway dashboard (Control UI)।
• दाएं: QA Lab, जिसमें Slack-जैसा transcript और scenario plan दिखता है।

इसे चलाएं:

pnpm qa:lab:up

यह QA site बनाता है, Docker-समर्थित gateway lane शुरू करता है, और QA Lab page उपलब्ध कराता है जहां operator या automation loop agent को QA mission दे सकता है, वास्तविक channel behavior देख सकता है, और दर्ज कर सकता है कि क्या काम किया, विफल हुआ, या blocked रहा।

हर बार Docker image फिर से बनाए बिना तेज QA Lab UI iteration के लिए, bind-mounted QA Lab bundle के साथ stack शुरू करें:

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

qa:lab:up:fast Docker services को prebuilt image पर रखता है और extensions/qa-lab/web/dist को qa-lab container में bind-mount करता है। qa:lab:watch बदलाव पर उस bundle को फिर से बनाता है, और QA Lab asset hash बदलने पर browser auto-reload होता है।

स्थानीय OpenTelemetry signal smoke के लिए, चलाएं:

pnpm qa:otel:smoke

यह script स्थानीय OTLP/HTTP receiver शुरू करता है, diagnostics-otel plugin enabled के साथ otel-trace-smoke QA scenario चलाता है, फिर traces, metrics, और logs export होने का assertion करता है। यह exported protobuf trace spans decode करता है और release-critical shape जांचता है: openclaw.run, openclaw.harness.run, latest GenAI semantic-convention model-call span, openclaw.context.assembled, और openclaw.message.delivery मौजूद होने चाहिए। Smoke OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental force करता है, इसलिए model-call span को {gen_ai.operation.name} {gen_ai.request.model} name उपयोग करना चाहिए; सफल turns पर model calls को StreamAbandoned export नहीं करना चाहिए; raw diagnostic IDs और openclaw.content.* attributes trace से बाहर रहने चाहिए। Raw OTLP payloads में prompt sentinel, response sentinel, या QA session key नहीं होना चाहिए। यह QA suite artifacts के पास otel-smoke-summary.json लिखता है।

Collector-backed OpenTelemetry smoke के लिए, चलाएं:

pnpm qa:otel:collector-smoke

यह lane उसी local receiver के सामने वास्तविक OpenTelemetry Collector Docker container रखता है। इसे endpoint wiring, collector compatibility, या OTLP export behavior बदलते समय उपयोग करें जिसे in-process receiver mask कर सकता है।

Protected Prometheus scrape smoke के लिए, चलाएं:

pnpm qa:prometheus:smoke

वह alias diagnostics-prometheus सक्षम करके docker-prometheus-smoke QA परिदृश्य चलाता है, सत्यापित करता है कि अनऑथेंटिकेटेड scrapes अस्वीकार किए जाते हैं, फिर जांचता है कि ऑथेंटिकेटेड scrape में prompt सामग्री, response सामग्री, raw diagnostic identifiers, auth tokens, या local paths के बिना release-critical metric families शामिल हैं।

दोनों observability smokes को लगातार चलाने के लिए, उपयोग करें:

pnpm qa:observability:smoke

collector-backed OpenTelemetry लेन और protected Prometheus scrape smoke के लिए, उपयोग करें:

pnpm qa:observability:collector-smoke

Observability QA केवल source-checkout रहता है। npm tarball जानबूझकर QA Lab को छोड़ता है, इसलिए package Docker release lanes qa commands नहीं चलातीं। diagnostics instrumentation बदलते समय built source checkout से pnpm qa:otel:smoke, pnpm qa:prometheus:smoke, या pnpm qa:observability:smoke का उपयोग करें।

ऐसी transport-real Matrix smoke लेन के लिए जिसे model-provider credentials की आवश्यकता नहीं है, deterministic mock OpenAI provider के साथ fast profile चलाएँ:

OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000 \  pnpm openclaw qa matrix --provider-mode mock-openai --profile fast --fail-fast

live-frontier provider लेन के लिए, OpenAI-compatible credentials स्पष्ट रूप से दें:

OPENCLAW_LIVE_OPENAI_KEY="${OPENAI_API_KEY}" \OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000 \  pnpm openclaw qa matrix --provider-mode live-frontier --profile fast --fail-fast

इस लेन के लिए पूरा CLI reference, profile/scenario catalog, env vars, और artifact layout Matrix QA में हैं। संक्षेप में: यह Docker में एक disposable Tuwunel homeserver provision करता है, temporary driver/SUT/observer users register करता है, real Matrix plugin को उस transport तक scoped child QA gateway के भीतर चलाता है (कोई qa-channel नहीं), फिर .artifacts/qa-e2e/matrix-<timestamp>/ के अंतर्गत Markdown report, JSON summary, observed-events artifact, और combined output log लिखता है।

परिदृश्य transport व्यवहार को cover करते हैं जिसे unit tests end to end साबित नहीं कर सकते: mention gating, allow-bot policies, allowlists, top-level और threaded replies, DM routing, reaction handling, inbound edit suppression, restart replay dedupe, homeserver interruption recovery, approval metadata delivery, media handling, और Matrix E2EE bootstrap/recovery/verification flows। E2EE CLI profile gateway replies जांचने से पहले उसी disposable homeserver के माध्यम से openclaw matrix encryption setup और verification commands भी चलाता है।

Discord में bug reproduction के लिए Mantis-only opt-in scenarios भी हैं। explicit status reaction timeline के लिए --scenario discord-status-reactions-tool-only का उपयोग करें, या real Discord thread बनाने और यह सत्यापित करने के लिए --scenario discord-thread-reply-filepath-attachment का उपयोग करें कि message.thread-reply एक filePath attachment preserve करता है। ये scenarios default live Discord लेन से बाहर रहते हैं क्योंकि वे broad smoke coverage के बजाय before/after repro probes हैं। QA environment में MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR या MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64 configured होने पर thread-attachment Mantis workflow logged-in Discord Web witness video भी जोड़ सकता है। वह viewer profile केवल visual capture के लिए है; pass/fail निर्णय अभी भी Discord REST oracle से आता है।

CI .github/workflows/qa-live-transports-convex.yml में वही command surface उपयोग करता है। Scheduled और default manual runs QA-provided live-frontier credentials, --fast, और OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000 के साथ fast Matrix profile execute करते हैं। Manual matrix_profile=all पांच profile shards में fan out करता है।

transport-real Telegram, Discord, Slack, और WhatsApp smoke lanes के लिए:

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

वे दो bots या accounts (driver + SUT) वाले pre-existing real channel को target करते हैं। Required env vars, scenario lists, output artifacts, और Convex credential pool नीचे Telegram, Discord, Slack, and WhatsApp QA reference में documented हैं।

VNC rescue के साथ full Slack desktop VM run के लिए, चलाएँ:

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

वह command Crabbox desktop/browser machine lease करता है, VM के भीतर Slack live lane चलाता है, VNC browser में Slack Web खोलता है, desktop capture करता है, और video capture उपलब्ध होने पर slack-qa/, slack-desktop-smoke.png, और slack-desktop-smoke.mp4 को Mantis artifact directory में वापस copy करता है। Crabbox desktop/browser leases capture tools और browser/native-build helper packages पहले से provide करते हैं, इसलिए scenario को केवल पुराने leases पर fallbacks install करने चाहिए। Mantis mantis-slack-desktop-smoke-report.md में total और per-phase timings report करता है ताकि slow runs दिखाएँ कि समय lease warmup, credential acquisition, remote setup, या artifact copy में गया। VNC के माध्यम से Slack Web में manually logging in करने के बाद --lease-id <cbx_...> reuse करें; reused leases Crabbox का pnpm store cache भी warm रखते हैं। Default --hydrate-mode source source checkout से verify करता है और VM के भीतर install/build चलाता है। --hydrate-mode prehydrated केवल तब उपयोग करें जब reused remote workspace में पहले से node_modules और built dist/ हों; वह mode महंगा install/build step skip करता है और workspace ready न होने पर fail closed करता है। --gateway-setup के साथ, Mantis VM के भीतर port 38973 पर एक persistent OpenClaw Slack gateway running छोड़ता है; इसके बिना, command normal bot-to-bot Slack QA lane चलाता है और artifact capture के बाद exit करता है।

desktop evidence के साथ native Slack approval UI साबित करने के लिए, Mantis approval checkpoint mode चलाएँ:

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

यह mode --gateway-setup के साथ mutually exclusive है। यह Slack approval scenarios चलाता है, non-approval scenario ids reject करता है, प्रत्येक pending और resolved approval state पर wait करता है, observed Slack API message को approval-checkpoints/<scenario>-pending.png और approval-checkpoints/<scenario>-resolved.png में render करता है, फिर किसी भी checkpoint, message evidence, acknowledgement, या rendered screenshot के missing या empty होने पर fail करता है। Cold CI leases अभी भी slack-desktop-smoke.png में Slack sign-in दिखा सकते हैं; approval checkpoint images इस lane के लिए visual proof हैं।

operator checklist, GitHub workflow dispatch command, evidence-comment contract, hydrate-mode decision table, timing interpretation, और failure handling steps Mantis Slack Desktop Runbook में हैं।

agent/CV style desktop task के लिए, चलाएँ:

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

visual-task Crabbox desktop/browser machine lease या reuse करता है, crabbox record --while शुरू करता है, nested visual-driver के माध्यम से visible browser drive करता है, visual-task.png capture करता है, --vision-mode image-describe selected होने पर screenshot के against 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 set होने पर, vision prompt structured JSON verdict मांगता है और केवल तब pass करता है जब model positive visible evidence report करता है; target text को केवल quote करने वाला negative response assertion fail करता है। image-understanding provider call किए बिना desktop, browser, screenshot, और video plumbing साबित करने वाले no-model smoke के लिए --vision-mode metadata उपयोग करें। Recording visual-task के लिए required artifact है; यदि Crabbox कोई non-empty visual-task.mp4 record नहीं करता, तो visual driver pass होने पर भी task fail होता है। Failure पर, Mantis VNC के लिए lease बनाए रखता है जब तक task पहले ही pass न हो चुका हो और --keep-lease set न हो।

pooled live credentials उपयोग करने से पहले, चलाएँ:

pnpm openclaw qa credentials doctor

doctor Convex broker env check करता है, endpoint settings validate करता है, और maintainer secret present होने पर admin/list reachability verify करता है। यह secrets के लिए केवल set/missing status report करता है।

Live transport coverage

Live transport lanes अपने-अपने scenario list shape invent करने के बजाय एक contract share करती हैं। qa-channel broad synthetic product-behavior suite है और live transport coverage matrix का हिस्सा नहीं है।

Live transport runners को shared scenario ids, baseline coverage helpers, और scenario-selection helper को openclaw/plugin-sdk/qa-live-transport-scenarios से import करना चाहिए।

यह qa-channel को broad product-behavior suite के रूप में बनाए रखता है, जबकि Matrix, Telegram, और अन्य live transports एक explicit transport-contract checklist share करते हैं।

QA path में Docker लाए बिना disposable Linux VM lane के लिए, चलाएँ:

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

यह fresh Multipass guest boot करता है, dependencies install करता है, guest के भीतर OpenClaw build करता है, qa suite चलाता है, फिर normal QA report और summary को host पर .artifacts/qa-e2e/... में वापस copy करता है। यह host पर qa suite जैसी ही scenario-selection behavior reuse करता है। Host और Multipass suite runs default रूप से isolated gateway workers के साथ कई selected scenarios parallel में execute करते हैं। qa-channel concurrency 4 पर default करता है, selected scenario count से capped। worker count tune करने के लिए --concurrency <count> का उपयोग करें, या serial execution के लिए --concurrency 1। personal assistant benchmark pack चलाने के लिए --pack personal-agent का उपयोग करें। pack selector repeated --scenario flags के साथ additive है: explicit scenarios पहले चलते हैं, फिर pack scenarios pack order में duplicates हटाकर चलते हैं। जब custom QA runner पहले से OpenTelemetry collector setup provide करता है और OpenTelemetry तथा Prometheus diagnostics smoke scenarios को साथ selected करना चाहता है, तो --pack observability का उपयोग करें। किसी भी scenario के fail होने पर command non-zero exit करता है। जब आप failing exit code के बिना artifacts चाहते हैं, तो --allow-failures उपयोग करें। Live runs guest के लिए practical supported QA auth inputs forward करते हैं: env-based provider keys, QA live provider config path, और present होने पर CODEX_HOME। --output-dir को repo root के अंतर्गत रखें ताकि guest mounted workspace के माध्यम से वापस write कर सके।

Telegram, Discord, Slack, और WhatsApp QA संदर्भ

Matrix का एक समर्पित पेज है, क्योंकि इसकी scenario संख्या और Docker-समर्थित homeserver provisioning अलग है। Telegram, Discord, Slack, और WhatsApp पहले से मौजूद वास्तविक transports के विरुद्ध चलते हैं, इसलिए उनका संदर्भ यहां रहता है।

साझा CLI flags

ये lanes extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts के माध्यम से register होती हैं और समान flags स्वीकार करती हैं:

किसी भी failed scenario पर प्रत्येक lane non-zero exit करती है। --allow-failures failing exit code set किए बिना artifacts लिखता है।

Telegram QA

pnpm openclaw qa telegram

दो अलग-अलग bots (driver + SUT) वाले एक वास्तविक private Telegram group को target करता है। SUT bot का Telegram username होना चाहिए; bot-to-bot observation सबसे अच्छा तब काम करता है जब दोनों bots में @BotFather में Bot-to-Bot Communication Mode enabled हो।

--credential-source env होने पर required env:

• OPENCLAW_QA_TELEGRAM_GROUP_ID - numeric chat id (string)।
• OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN
• OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN

Scenarios (extensions/qa-lab/src/live-transports/telegram/telegram-live.runtime.ts):

• telegram-canary
• telegram-mention-gating
• telegram-mentioned-message-reply
• 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-reply-chain-exact-marker
• telegram-stream-final-single-message
• telegram-long-final-reuses-preview
• telegram-long-final-three-chunks

Implicit default set हमेशा canary, mention gating, native command replies, command addressing, और bot-to-bot group replies को cover करता है। mock-openai defaults में deterministic reply-chain और final-message streaming checks भी शामिल हैं। telegram-current-session-status-tool opt-in रहता है क्योंकि यह केवल canary के तुरंत बाद threaded होने पर stable है, arbitrary native command replies के बाद नहीं। Regression refs के साथ current default/optional split print करने के लिए pnpm openclaw qa telegram --list-scenarios --provider-mode mock-openai का उपयोग करें।

Output artifacts:

• telegram-qa-report.md
• qa-evidence.json - live transport checks के लिए evidence entries, जिनमें profile, coverage, provider, channel, artifacts, result, और RTT fields शामिल हैं।

Package Telegram runs समान Telegram credential contract का उपयोग करते हैं। Repeated RTT measurement normal package Telegram live lane का हिस्सा है; RTT distribution selected RTT check के लिए result.timing के अंतर्गत qa-evidence.json में fold की जाती है।

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

जब OPENCLAW_QA_CREDENTIAL_SOURCE=convex set होता है, package live wrapper एक kind: "telegram" credential lease करता है, leased group/driver/SUT bot env को installed-package run में export करता है, lease को Heartbeat करता है, और shutdown पर इसे release करता है। Package wrapper default रूप से telegram-mentioned-message-reply के 20 RTT checks, 30s RTT timeout, और Convex चुने जाने पर CI के बाहर Convex role maintainer का उपयोग करता है। अलग RTT command या Telegram-specific summary format बनाए बिना RTT measurement tune करने के लिए OPENCLAW_NPM_TELEGRAM_RTT_SAMPLES, OPENCLAW_NPM_TELEGRAM_RTT_TIMEOUT_MS, या OPENCLAW_NPM_TELEGRAM_RTT_MAX_FAILURES override करें।

Discord QA

pnpm openclaw qa discord

दो bots वाले एक वास्तविक private Discord guild channel को target करता है: harness द्वारा controlled driver bot और bundled Discord Plugin के माध्यम से child OpenClaw gateway द्वारा started SUT bot। Channel mention handling, यह कि SUT bot ने Discord के साथ native /help command register किया है, और opt-in Mantis evidence scenarios verify करता है।

--credential-source env होने पर required 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 - Discord द्वारा returned SUT bot user id से match होना चाहिए (अन्यथा lane fast fail होती है)।

Optional:

• OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1 observed-message artifacts में message bodies रखता है।
• OPENCLAW_QA_DISCORD_VOICE_CHANNEL_ID discord-voice-autojoin के लिए voice/stage channel select करता है; इसके बिना, scenario SUT bot के लिए पहला visible voice/stage channel चुनता है।

Scenarios (extensions/qa-lab/src/live-transports/discord/discord-live.runtime.ts:36):

• discord-canary
• discord-mention-gating
• discord-native-help-command-registration
• discord-voice-autojoin - opt-in voice scenario। अपने आप चलता है, channels.discord.voice.autoJoin enable करता है, और verify करता है कि SUT bot की current Discord voice state target voice/stage channel है। Convex Discord credentials में optional voiceChannelId शामिल हो सकता है; अन्यथा runner guild में पहला visible voice/stage channel discover करता है।
• discord-status-reactions-tool-only - opt-in Mantis scenario। अपने आप चलता है क्योंकि यह SUT को messages.statusReactions.enabled=true के साथ always-on, tool-only guild replies पर switch करता है, फिर REST reaction timeline और HTML/PNG visual artifacts capture करता है। Mantis before/after reports scenario-provided MP4 artifacts को baseline.mp4 और candidate.mp4 के रूप में भी preserve करते हैं।

Discord voice auto-join scenario को स्पष्ट रूप से चलाएं:

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

Mantis status-reaction scenario को स्पष्ट रूप से चलाएं:

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

Output artifacts:

• discord-qa-report.md
• qa-evidence.json - live transport checks के लिए evidence entries।
• discord-qa-observed-messages.json - bodies redacted रहते हैं जब तक OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1 न हो।
• Status-reaction scenario चलने पर discord-qa-reaction-timelines.json और discord-status-reactions-tool-only-timeline.png।

Slack QA

pnpm openclaw qa slack

दो distinct bots वाले एक वास्तविक private Slack channel को target करता है: harness द्वारा controlled driver bot और bundled Slack Plugin के माध्यम से child OpenClaw gateway द्वारा started SUT bot।

--credential-source env होने पर required env:

• OPENCLAW_QA_SLACK_CHANNEL_ID
• OPENCLAW_QA_SLACK_DRIVER_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_APP_TOKEN

Optional:

• OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1 observed-message artifacts में message bodies रखता है।
• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR Mantis के लिए visual approval checkpoints enable करता है। Runner <scenario>.pending.json और <scenario>.resolved.json लिखता है, फिर matching .ack.json files की प्रतीक्षा करता है।
• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_TIMEOUT_MS checkpoint acknowledgement timeout override करता है। Default 120000 है।

Scenarios (extensions/qa-lab/src/live-transports/slack/slack-live.runtime.ts):

• slack-canary
• slack-mention-gating
• slack-allowlist-block
• slack-top-level-reply-shape
• slack-restart-resume
• slack-thread-follow-up
• slack-thread-isolation
• slack-approval-exec-native - opt-in native Slack exec approval scenario। Gateway के माध्यम से exec approval request करता है, verify करता है कि Slack message में native approval buttons हैं, इसे resolve करता है, और resolved Slack update verify करता है।
• slack-approval-plugin-native - opt-in native Slack Plugin approval scenario। Exec और Plugin approval forwarding को साथ में enable करता है ताकि Plugin events exec approval routing द्वारा suppressed न हों, फिर उसी pending/resolved native Slack UI path को verify करता है।

Output artifacts:

• slack-qa-report.md
• qa-evidence.json - live transport checks के लिए evidence entries।
• slack-qa-observed-messages.json - bodies redacted रहते हैं जब तक OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1 न हो।
• approval-checkpoints/ - केवल जब Mantis OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR set करता है; इसमें checkpoint JSON, acknowledgement JSON, और pending/resolved screenshots शामिल हैं।

Slack workspace set up करना

Lane को एक workspace में दो distinct Slack apps, साथ ही एक ऐसा channel चाहिए जिसका दोनों bots हिस्सा हों:

• channelId - उस channel का Cxxxxxxxxxx id जिसमें दोनों bots को invite किया गया है। Dedicated channel का उपयोग करें; lane हर run पर post करती है।
• driverBotToken - Driver app का bot token (xoxb-...)।
• sutBotToken - SUT app का bot token (xoxb-...), जो driver से अलग Slack app होना चाहिए ताकि उसका bot user id distinct हो।
• sutAppToken - SUT app का app-level token (xapp-...) जिसमें connections:write हो, जिसका उपयोग Socket Mode द्वारा किया जाता है ताकि SUT app events receive कर सके।

Production workspace reuse करने के बजाय QA के लिए dedicated Slack workspace को प्राथमिकता दें।

नीचे दिया गया SUT manifest जानबूझकर bundled Slack Plugin के production install (extensions/slack/src/setup-shared.ts:10) को live Slack QA suite द्वारा covered permissions और events तक सीमित करता है। Users को दिखने वाले production-channel setup के लिए, Slack channel quick setup देखें; QA Driver/SUT pair जानबूझकर अलग है क्योंकि lane को एक workspace में दो distinct bot user ids चाहिए।

1. Driver app बनाएं

api.slack.com/apps पर जाएं → Create New App → From a manifest → QA workspace चुनें, निम्न manifest पेस्ट करें, फिर Install to Workspace करें:

{  "display_information": {    "name": "OpenClaw QA Driver",    "description": "Test driver bot for OpenClaw QA Slack live lane"  },  "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 बनता है। driver को केवल संदेश पोस्ट करने और खुद की पहचान करने की जरूरत है; कोई events नहीं, कोई Socket Mode नहीं।

2. SUT app बनाएं

उसी workspace में Create New App → From a manifest दोहराएं। यह QA app जानबूझकर bundled Slack plugin के production manifest (extensions/slack/src/setup-shared.ts:10) के संकरे संस्करण का उपयोग करता है: reaction scopes और events छोड़े गए हैं क्योंकि live Slack QA suite अभी reaction handling को cover नहीं करता।

{  "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 द्वारा app बनाने के बाद, उसके settings page पर दो काम करें:

• Install to Workspace → Bot User OAuth Token कॉपी करें → वह sutBotToken बनता है।
• Basic Information → App-Level Tokens → Generate Token and Scopes → scope connections:write जोड़ें → save करें → xapp-... value कॉपी करें → वह sutAppToken बनता है।

प्रत्येक token पर auth.test call करके सत्यापित करें कि दोनों bots के user ids अलग हैं। runtime driver और SUT में अंतर user id से करता है; दोनों के लिए एक ही app reuse करने पर mention-gating तुरंत fail हो जाएगी।

3. channel बनाएं

QA workspace में एक channel बनाएं (जैसे #openclaw-qa) और channel के अंदर से दोनों bots को invite करें:

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

channel info → About → Channel ID से Cxxxxxxxxxx id कॉपी करें - वह channelId बनता है। public channel काम करता है; यदि आप private channel का उपयोग करते हैं तो दोनों apps के पास पहले से groups:history है, इसलिए harness की history reads फिर भी सफल होंगी।

4. credentials register करें

दो options। single-machine debugging के लिए env vars का उपयोग करें (चारों OPENCLAW_QA_SLACK_* variables set करें और --credential-source env pass करें), या shared Convex pool seed करें ताकि CI और अन्य maintainers उन्हें lease कर सकें।

Convex pool के लिए, चार fields को JSON file में लिखें:

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

अपने shell में OPENCLAW_QA_CONVEX_SITE_URL और OPENCLAW_QA_CONVEX_SECRET_MAINTAINER export करके, register और verify करें:

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 field नहीं अपेक्षित है।

5. end to end सत्यापित करें

स्थानीय रूप से lane चलाएं ताकि पुष्टि हो सके कि दोनों bots broker के माध्यम से एक-दूसरे से बात कर सकते हैं:

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

Green run 30 seconds से काफी कम समय में पूरा होता है और slack-qa-report.md में slack-canary और slack-mention-gating दोनों की status pass दिखती है। यदि lane ~90 seconds तक hang होती है और Convex credential pool exhausted for kind "slack" के साथ exit करती है, तो या तो pool खाली है या हर row leased है - qa credentials list --kind slack --status all --json आपको बताएगा कि कौन सा मामला है।

WhatsApp QA

pnpm openclaw qa whatsapp

दो dedicated WhatsApp Web accounts को target करता है: harness द्वारा नियंत्रित driver account और child OpenClaw Gateway द्वारा bundled WhatsApp plugin के माध्यम से शुरू किया गया SUT account।

--credential-source env होने पर आवश्यक 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 group scenarios जैसे whatsapp-mention-gating, whatsapp-group-pending-history-context, whatsapp-broadcast-group-fanout, whatsapp-group-activation-always, whatsapp-group-reply-to-bot-triggers, group action/media/poll scenarios, और whatsapp-group-allowlist-block enable करता है।
• OPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1 observed-message artifacts में message bodies रखता है।

Scenario catalog (extensions/qa-lab/src/live-transports/whatsapp/whatsapp-live.runtime.ts):

• Baseline और group gating: 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.
• Native commands: whatsapp-help-command, whatsapp-status-command, whatsapp-commands-command, whatsapp-tools-compact-command, whatsapp-whoami-command, whatsapp-context-command, whatsapp-native-new-command.
• Reply और final-output behavior: 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.
• User-path message actions: whatsapp-agent-message-action-react एक real driver DM से शुरू होता है, model को message tool call करने देता है, और native WhatsApp reaction observe करता है। whatsapp-agent-message-action-upload-file message(action=upload-file) के लिए वही posture उपयोग करता है और native WhatsApp media observe करता है। whatsapp-group-agent-message-action-react और whatsapp-group-agent-message-action-upload-file real WhatsApp group में वही user-visible actions prove करते हैं।
• Group fanout: whatsapp-broadcast-group-fanout एक mentioned WhatsApp group message से शुरू होता है और main और qa-second से distinct visible replies verify करता है।
• Group activation: whatsapp-group-activation-always real group session को /activation always में बदलता है, prove करता है कि unmentioned group message agent को wake करता है, फिर /activation mention restore करता है। whatsapp-group-reply-to-bot-triggers एक bot reply seed करता है, explicit mention के बिना उस पर native quoted reply भेजता है, और verify करता है कि agent उस reply context से wake करता है।
• Inbound media और structured messages: whatsapp-inbound-image-caption, whatsapp-audio-preflight, whatsapp-inbound-structured-messages, whatsapp-group-audio-gating, whatsapp-inbound-reaction-no-trigger. ये driver के माध्यम से real WhatsApp image, audio, document, location, contact, sticker, और reaction events भेजते हैं।
• Direct Gateway contract probes: 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. ये जानबूझकर model prompting को bypass करते हैं और deterministic Gateway/channel send, poll, और message.action contracts prove करते हैं।
• Access-control coverage: whatsapp-access-control-dm-open, whatsapp-access-control-dm-disabled, whatsapp-access-control-group-open, whatsapp-access-control-group-disabled, whatsapp-group-allowlist-block.
• Native approvals: whatsapp-approval-exec-deny-native, whatsapp-approval-exec-native, whatsapp-approval-exec-reaction-native, whatsapp-approval-exec-group-reaction-native, whatsapp-approval-plugin-native.
• Status reactions: whatsapp-status-reactions, whatsapp-status-reaction-lifecycle.

catalog में फिलहाल 50 scenarios हैं। live-frontier default lane fast smoke coverage के लिए 10 scenarios पर छोटा रखा गया है। mock-openai default lane real WhatsApp transport के माध्यम से 44 deterministic scenarios चलाता है जबकि केवल model output को mock करता है। Approval scenarios और कुछ भारी/blocking checks scenario id से explicit रहते हैं।

WhatsApp QA driver structured live events (text, media, location, reaction, और poll) observe करता है और सक्रिय रूप से media, polls, contacts, locations, और stickers भेज सकता है। QA Lab उस driver को private WhatsApp runtime files में पहुंचने के बजाय @openclaw/whatsapp/api.js package surface के माध्यम से import करता है। group observations के लिए, fromJid group JID है जबकि participantJid और fromPhoneE164 participant sender की पहचान करते हैं। Message content default रूप से redacted होता है। Direct Gateway poll, upload-file, media, group poll, group media, और reply-shape probes transport/API contract checks हैं; इन्हें इस बात के proof के रूप में नहीं माना जाता कि user prompt ने agent से वही action चुनवाया। User-path action proof scenarios जैसे whatsapp-agent-message-action-react और whatsapp-group-agent-message-action-react से आता है, जहां driver एक सामान्य WhatsApp message भेजता है और QA Lab resulting native WhatsApp artifact observe करता है। WhatsApp reports में प्रत्येक scenario का posture (user-path, direct-gateway, या native-approval) शामिल होता है ताकि evidence को उससे मजबूत contract समझने की गलती न हो जो वह वास्तव में prove करता है।

Output artifacts:

• whatsapp-qa-report.md
• qa-evidence.json - live transport checks के लिए evidence entries।
• whatsapp-qa-observed-messages.json - bodies redacted रहती हैं जब तक OPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1 न हो।

Convex credential pool

Telegram, Discord, Slack, और WhatsApp lanes ऊपर दिए env vars पढ़ने के बजाय shared Convex pool से credentials lease कर सकती हैं। --credential-source convex pass करें (या OPENCLAW_QA_CREDENTIAL_SOURCE=convex set करें); QA Lab exclusive lease acquire करता है, run की अवधि तक उसका heartbeat करता है, और shutdown पर उसे release करता है। Pool kinds "telegram", "discord", "slack", और "whatsapp" हैं।

Broker द्वारा admin/add पर validate किए जाने वाले payload shapes:

• Telegram (kind: "telegram"): { groupId: string, driverToken: string, sutToken: string } - groupId एक सांख्यिक chat-id स्ट्रिंग होनी चाहिए.
• 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 स्ट्रिंग होने चाहिए.

Mantis Telegram Desktop प्रमाण वर्कफ़्लो TDLib CLI ड्राइवर और Telegram Desktop साक्षी, दोनों के लिए एक एक्सक्लूसिव Convex telegram-user लीज़ रखता है, फिर प्रमाण प्रकाशित करने के बाद उसे रिलीज़ करता है.

जब किसी PR को निर्धार्य विज़ुअल diff की आवश्यकता होती है, तो Mantis main और PR head पर वही mock model जवाब इस्तेमाल कर सकता है, जबकि Telegram formatter या delivery layer बदलती है. कैप्चर डिफ़ॉल्ट PR टिप्पणियों के लिए ट्यून किए गए हैं: मानक Crabbox class, 24fps desktop recording, 24fps motion GIF, और 1920px preview width. पहले/बाद की टिप्पणियों को एक साफ़ bundle प्रकाशित करना चाहिए जिसमें केवल अपेक्षित GIF हों.

Slack लेन pool का भी उपयोग कर सकती हैं. Slack payload shape checks वर्तमान में broker के बजाय Slack QA runner में रहते हैं; { channelId: string, driverBotToken: string, sutBotToken: string, sutAppToken: string } का उपयोग करें, Slack channel id जैसे Cxxxxxxxxxx के साथ. app और scope provisioning के लिए Slack workspace सेट अप करना देखें.

Operational env vars और Convex broker endpoint contract Testing → Convex के माध्यम से साझा Telegram credentials में रहते हैं (section name multi-channel pool से पहले का है; lease semantics सभी kinds में shared हैं).

Repo-backed seeds

Seed assets qa/ में रहते हैं:

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

इन्हें जानबूझकर git में रखा गया है ताकि QA plan मनुष्यों और agent दोनों को दिखाई दे.

qa-lab को generic YAML scenario runner बने रहना चाहिए. हर scenario YAML file एक test run के लिए source of truth है और इसे परिभाषित करना चाहिए:

• top-level title
• scenario metadata
• scenario में optional category, capability, lane, और risk metadata
• scenario में docs और code refs
• scenario में optional plugin requirements
• scenario में optional gateway config patch
• flow scenarios के लिए executable top-level flow, या Vitest और Playwright scenarios के लिए scenario.execution.kind / scenario.execution.path

flow को support करने वाला reusable runtime surface generic और cross-cutting रह सकता है. उदाहरण के लिए, YAML scenarios transport-side helpers को browser-side helpers के साथ जोड़ सकते हैं, जो embedded Control UI को Gateway browser.request seam के माध्यम से चलाते हैं, बिना special-case runner जोड़े.

Scenario files को source tree folder के बजाय product capability के अनुसार group करना चाहिए. Files move होने पर scenario IDs stable रखें; implementation traceability के लिए docsRefs और codeRefs का उपयोग करें.

Baseline list इतनी व्यापक रहनी चाहिए कि वह cover करे:

• DM और channel chat
• thread behavior
• message action lifecycle
• cron callbacks
• memory recall
• model switching
• subagent handoff
• repo-reading और docs-reading
• Lobster Invaders जैसा एक छोटा build task

Provider mock lanes

qa suite में दो local provider mock lanes हैं:

• mock-openai scenario-aware OpenClaw mock है. यह repo-backed QA और parity gates के लिए default deterministic mock lane बना रहता है.
• aimock experimental protocol, fixture, record/replay, और chaos coverage के लिए AIMock-backed provider server शुरू करता है. यह additive है और mock-openai scenario dispatcher को replace नहीं करता.

Provider-lane implementation extensions/qa-lab/src/providers/ के अंतर्गत रहती है. हर provider अपने defaults, local server startup, gateway model config, auth-profile staging needs, और live/mock capability flags का owner है. Shared suite और gateway code को provider names पर branching करने के बजाय provider registry के माध्यम से route करना चाहिए.

Transport adapters

qa-lab YAML QA scenarios के लिए generic transport seam own करता है. qa-channel synthetic default है. crabline local provider-shaped servers शुरू करता है और OpenClaw के normal channel plugins को उनके विरुद्ध चलाता है. live real provider credentials और external channels के लिए reserved है.

Architecture level पर split यह है:

• qa-lab generic scenario execution, worker concurrency, artifact writing, और reporting own करता है.
• Transport adapter gateway config, readiness, inbound और outbound observation, transport actions, और normalized transport state own करता है.
• qa/scenarios/ के अंतर्गत YAML scenario files test run define करती हैं; qa-lab उन्हें execute करने वाला reusable runtime surface प्रदान करता है.

Channel जोड़ना

YAML QA system में channel जोड़ने के लिए channel implementation और एक scenario pack चाहिए जो channel contract को exercise करे. Smoke CI coverage के लिए, matching Crabline local provider server जोड़ें और उसे crabline driver के माध्यम से expose करें.

जब shared qa-lab host flow own कर सकता है, तब नया top-level QA command root न जोड़ें.

qa-lab shared host mechanics own करता है:

• openclaw qa command root
• suite startup और teardown
• worker concurrency
• artifact writing
• report generation
• scenario execution
• पुराने qa-channel scenarios के लिए compatibility aliases

Runner plugins transport contract own करते हैं:

• shared qa root के नीचे openclaw qa <runner> कैसे mount होता है
• उस transport के लिए gateway कैसे configure होता है
• readiness कैसे check की जाती है
• inbound events कैसे inject किए जाते हैं
• outbound messages कैसे observe किए जाते हैं
• transcripts और normalized transport state कैसे expose किए जाते हैं
• transport-backed actions कैसे execute होते हैं
• transport-specific reset या cleanup कैसे handle होता है

नए channel के लिए न्यूनतम adoption bar:

1. Shared qa root का owner qa-lab रखें.
2. Shared qa-lab host seam पर transport runner implement करें.
3. Transport-specific mechanics को runner plugin या channel harness के अंदर रखें.
4. Competing root command register करने के बजाय runner को openclaw qa <runner> के रूप में mount करें. Runner plugins को openclaw.plugin.json में qaRunners declare करना चाहिए और runtime-api.ts से matching qaRunnerCliRegistrations array export करना चाहिए. runtime-api.ts हल्का रखें; lazy CLI और runner execution अलग entrypoints के पीछे रहना चाहिए.
5. Themed qa/scenarios/ directories के अंतर्गत YAML scenarios author या adapt करें.
6. नए scenarios के लिए generic scenario helpers का उपयोग करें.
7. Existing compatibility aliases को working रखें, जब तक repo intentional migration नहीं कर रहा हो.

Decision rule strict है:

• अगर behavior को qa-lab में एक बार express किया जा सकता है, तो उसे qa-lab में रखें.
• अगर behavior एक channel transport पर निर्भर करता है, तो उसे उस runner plugin या plugin harness में रखें.
• अगर किसी scenario को नई capability चाहिए जिसे एक से अधिक channel use कर सकते हैं, तो suite.ts में channel-specific branch के बजाय generic helper जोड़ें.
• अगर behavior केवल एक transport के लिए meaningful है, तो scenario को transport-specific रखें और scenario contract में इसे explicit बनाएं.

Scenario helper names

नए scenarios के लिए preferred generic helpers:

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

Compatibility aliases existing scenarios के लिए उपलब्ध रहते हैं - waitForQaChannelReady, waitForOutboundMessage, waitForNoOutbound, formatConversationTranscript, resetBus - लेकिन नए scenario authoring में generic names का उपयोग करना चाहिए. Aliases flag-day migration से बचने के लिए मौजूद हैं, आगे का model बनने के लिए नहीं.

Reporting

qa-lab observed bus timeline से Markdown protocol report export करता है. Report को जवाब देना चाहिए:

• क्या काम किया
• क्या fail हुआ
• क्या blocked रहा
• कौन-से follow-up scenarios जोड़ने लायक हैं

Available scenarios की inventory के लिए - जो follow-up work size करने या नया transport wire करने में उपयोगी है - pnpm openclaw qa coverage चलाएँ (machine-readable output के लिए --json जोड़ें). Touched behavior या file path के लिए focused proof चुनते समय, pnpm openclaw qa coverage --match <query> चलाएँ. Match report scenario metadata, docs refs, code refs, coverage IDs, plugins, और provider requirements search करता है, फिर matching qa suite --scenario ... targets print करता है. हर qa suite run selected scenario set के लिए top-level qa-evidence.json, qa-suite-summary.json, और qa-suite-report.md artifacts लिखता है. जो scenarios execution.kind: vitest या execution.kind: playwright declare करते हैं, वे matching test path चलाते हैं और per-scenario logs भी लिखते हैं. जो scenarios execution.kind: script declare करते हैं, वे execution.path पर evidence producer को node --import tsx के माध्यम से चलाते हैं (execution.args में ${outputDir} और ${scenarioId} expanded होते हैं); producer अपना qa-evidence.json लिखता है, जिसकी entries suite output में import की जाती हैं और जिनके artifact paths उस producer qa-evidence.json के relative resolve होते हैं. जब qa suite qa run --qa-profile के माध्यम से पहुँचा जाता है, तो वही qa-evidence.json selected taxonomy categories के लिए profile scorecard summary भी include करता है. इसे discovery aid मानें, gate replacement नहीं; selected scenario को behavior under test के लिए अभी भी सही provider mode, live transport, Multipass, Testbox, या release lane चाहिए. Scorecard context के लिए, Maturity scorecard देखें.

Character और style checks के लिए, same scenario को कई live model refs पर चलाएँ और judged Markdown report लिखें:

pnpm openclaw qa character-eval \  --model openai/gpt-5.5,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.5,thinking=xhigh,fast \  --judge-model anthropic/claude-opus-4-8,thinking=high \  --blind-judge-models \  --concurrency 16 \  --judge-concurrency 16

कमांड Docker नहीं, बल्कि स्थानीय QA gateway चाइल्ड प्रक्रियाएं चलाता है। कैरेक्टर मूल्यांकन परिदृश्यों को SOUL.md के माध्यम से persona सेट करना चाहिए, फिर chat, workspace help, और small file tasks जैसे सामान्य उपयोगकर्ता turns चलाने चाहिए। उम्मीदवार मॉडल को यह नहीं बताया जाना चाहिए कि उसका मूल्यांकन किया जा रहा है। कमांड प्रत्येक पूर्ण transcript को सुरक्षित रखता है, बुनियादी run stats रिकॉर्ड करता है, फिर जहाँ समर्थित हो वहाँ xhigh reasoning के साथ fast mode में judge मॉडल से runs को naturalness, vibe, और humor के आधार पर रैंक कराने के लिए कहता है। providers की तुलना करते समय --blind-judge-models का उपयोग करें: judge prompt को अभी भी हर transcript और run status मिलता है, लेकिन candidate refs को candidate-01 जैसे neutral labels से बदल दिया जाता है; report parsing के बाद rankings को वापस वास्तविक refs से map करती है। Candidate runs डिफ़ॉल्ट रूप से high thinking का उपयोग करते हैं, GPT-5.5 के लिए medium और पुराने OpenAI eval refs के लिए xhigh, जहाँ यह समर्थित हो। किसी specific candidate को inline override करें --model provider/model,thinking=<level> के साथ। --thinking <level> अभी भी global fallback सेट करता है, और पुराना --model-thinking <provider/model=level> रूप compatibility के लिए रखा गया है। OpenAI candidate refs डिफ़ॉल्ट रूप से fast mode का उपयोग करते हैं ताकि जहाँ provider समर्थन करता है वहाँ priority processing का उपयोग हो। जब किसी एक candidate या judge को override चाहिए, तो inline ,fast, ,no-fast, या ,fast=false जोड़ें। --fast केवल तब pass करें जब आप हर candidate model के लिए fast mode को force करना चाहते हों। Candidate और judge durations benchmark analysis के लिए report में रिकॉर्ड किए जाते हैं, लेकिन judge prompts स्पष्ट रूप से कहते हैं कि speed के आधार पर rank न करें। Candidate और judge model runs दोनों में डिफ़ॉल्ट concurrency 16 है। जब provider limits या local gateway pressure किसी run को बहुत noisy बना दें, तो --concurrency या --judge-concurrency कम करें। जब कोई candidate --model pass नहीं किया जाता, तो character eval डिफ़ॉल्ट रूप से 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 pass नहीं किया जाता। जब कोई --judge-model pass नहीं किया जाता, तो judges डिफ़ॉल्ट रूप से openai/gpt-5.5,thinking=xhigh,fast और anthropic/claude-opus-4-8,thinking=high होते हैं।

संबंधित दस्तावेज़

• Matrix QA
• Maturity scorecard
• Personal agent benchmark pack
• QA Channel
• Testing
• Dashboard