--- read_when: - यह समझना कि QA स्टैक आपस में कैसे जुड़ता है - qa-lab, qa-channel, या ट्रांसपोर्ट अडैप्टर का विस्तार करना - रेपो-समर्थित QA परिदृश्य जोड़ना - Gateway डैशबोर्ड के आसपास अधिक यथार्थवादी QA स्वचालन बनाना summary: 'QA स्टैक अवलोकन: qa-lab, qa-channel, repo-backed scenarios, लाइव ट्रांसपोर्ट लेन, ट्रांसपोर्ट अडैप्टर, और रिपोर्टिंग।' title: QA अवलोकन x-i18n: generated_at: "2026-07-01T08:03:04Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: 33dc2c7ac1751c8728dda332476cd41cf39c3e9d1582f8c652c2670c2549b34c source_path: concepts/qa-e2e-automation.md workflow: 16 --- निजी QA स्टैक का उद्देश्य OpenClaw को एकल यूनिट टेस्ट की तुलना में अधिक यथार्थवादी, चैनल-सदृश तरीके से परखना है। मौजूदा घटक: - `extensions/qa-channel`: DM, चैनल, थ्रेड, रिएक्शन, एडिट और डिलीट सतहों वाला सिंथेटिक संदेश चैनल। - `extensions/qa-lab`: ट्रांसक्रिप्ट देखने, इनबाउंड संदेश इंजेक्ट करने और Markdown रिपोर्ट निर्यात करने के लिए डिबगर UI और QA बस। - `extensions/qa-matrix`, भविष्य के रनर plugins: लाइव-ट्रांसपोर्ट अडैप्टर जो चाइल्ड QA gateway के अंदर वास्तविक चैनल चलाते हैं। - `qa/`: किकऑफ कार्य और बेसलाइन QA परिदृश्यों के लिए रिपॉजिटरी-समर्थित सीड एसेट। - [Mantis](/hi/concepts/mantis): उन बग के लिए लाइव सत्यापन से पहले और बाद की जांच जिन्हें वास्तविक ट्रांसपोर्ट, ब्राउज़र स्क्रीनशॉट, VM स्थिति और PR साक्ष्य चाहिए। ## कमांड सतह हर QA फ्लो `pnpm openclaw qa ` के अंतर्गत चलता है। कई के पास `pnpm qa:*` स्क्रिप्ट उपनाम हैं; दोनों रूप समर्थित हैं। | कमांड | उद्देश्य | | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `qa run` | `--qa-profile` के बिना बंडल किया गया QA स्व-जांच; `--qa-profile smoke-ci`, `--qa-profile release`, या `--qa-profile all` के साथ taxonomy-समर्थित maturity profile runner। | | `qa suite` | QA gateway lane के विरुद्ध रिपॉजिटरी-समर्थित परिदृश्य चलाएं। उपनाम: disposable Linux VM के लिए `pnpm openclaw qa suite --runner multipass`। | | `qa coverage` | YAML scenario-coverage इन्वेंटरी प्रिंट करें (मशीन आउटपुट के लिए `--json`)। | | `qa parity-report` | दो `qa-suite-summary.json` फाइलों की तुलना करें और agentic parity report लिखें, या एक runtime-pair summary से Codex-vs-OpenClaw runtime parity और token-efficiency रिपोर्ट लिखने के लिए `--runtime-axis --token-efficiency` उपयोग करें। | | `qa character-eval` | judged report के साथ कई लाइव मॉडलों में character QA scenario चलाएं। [रिपोर्टिंग](#reporting) देखें। | | `qa manual` | चुने गए provider/model lane के विरुद्ध one-off prompt चलाएं। | | `qa ui` | QA debugger UI और local QA bus शुरू करें (उपनाम: `pnpm qa:lab:ui`)। | | `qa docker-build-image` | पहले से तैयार QA Docker image बनाएं। | | `qa docker-scaffold` | QA dashboard + gateway lane के लिए docker-compose scaffold लिखें। | | `qa up` | QA site बनाएं, Docker-समर्थित stack शुरू करें, URL प्रिंट करें (उपनाम: `pnpm qa:lab:up`; `:fast` variant `--use-prebuilt-image --bind-ui-dist --skip-ui-build` जोड़ता है)। | | `qa aimock` | केवल AIMock provider server शुरू करें। | | `qa mock-openai` | केवल scenario-aware `mock-openai` provider server शुरू करें। | | `qa credentials doctor` / `add` / `list` / `remove` | साझा Convex credential pool प्रबंधित करें। | | `qa matrix` | disposable Tuwunel homeserver के विरुद्ध लाइव transport lane। [Matrix QA](/hi/concepts/qa-matrix) देखें। | | `qa telegram` | वास्तविक निजी Telegram group के विरुद्ध लाइव transport lane। | | `qa discord` | वास्तविक निजी Discord guild channel के विरुद्ध लाइव transport lane। | | `qa slack` | वास्तविक निजी Slack channel के विरुद्ध लाइव transport lane। | | `qa whatsapp` | वास्तविक WhatsApp Web खातों के विरुद्ध लाइव transport lane। | | `qa mantis` | लाइव transport bugs के लिए before and after verification runner, जिसमें Discord status-reactions evidence, Crabbox desktop/browser smoke, और Slack-in-VNC smoke शामिल हैं। [Mantis](/hi/concepts/mantis) और [Mantis Slack Desktop Runbook](/hi/concepts/mantis-slack-desktop-runbook) देखें। | 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 बहाल करता है: ```bash 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 से पहले रखें: ```bash 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 दिखता है। इसे चलाएं: ```bash 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 शुरू करें: ```bash pnpm openclaw qa docker-build-image pnpm qa:lab:build pnpm qa:lab:up:fast pnpm 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 के लिए, चलाएं: ```bash 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 के लिए, चलाएं: ```bash 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 के लिए, चलाएं: ```bash 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 को लगातार चलाने के लिए, उपयोग करें: ```bash pnpm qa:observability:smoke ``` collector-backed OpenTelemetry लेन और protected Prometheus scrape smoke के लिए, उपयोग करें: ```bash 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 चलाएँ: ```bash 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 स्पष्ट रूप से दें: ```bash 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](/hi/concepts/qa-matrix) में हैं। संक्षेप में: यह 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-/` के अंतर्गत 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 के लिए: ```bash pnpm openclaw qa telegram pnpm openclaw qa discord pnpm openclaw qa slack pnpm 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](#telegram-discord-slack-and-whatsapp-qa-reference) में documented हैं। VNC rescue के साथ full Slack desktop VM run के लिए, चलाएँ: ```bash 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 ` 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 चलाएँ: ```bash 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/-pending.png` और `approval-checkpoints/-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](/hi/concepts/mantis-slack-desktop-runbook) में हैं। agent/CV style desktop task के लिए, चलाएँ: ```bash 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 उपयोग करने से पहले, चलाएँ: ```bash 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 करना चाहिए। | लेन | कैनरी | Mention gating | Bot-to-bot | Allowlist block | Top-level reply | Quote reply | Restart resume | Thread follow-up | Thread isolation | Reaction observation | Help command | Native command registration | | -------- | ------ | -------------- | ---------- | --------------- | --------------- | ----------- | -------------- | ---------------- | ---------------- | -------------------- | ------------ | --------------------------- | | Matrix | x | x | x | x | x | | x | x | x | x | | | | Telegram | x | x | x | | | | | | | | x | | | Discord | x | x | x | | | | | | | | | x | | Slack | x | x | x | x | x | | x | x | x | | | | | WhatsApp | x | x | | x | x | x | x | | | x | x | | यह `qa-channel` को broad product-behavior suite के रूप में बनाए रखता है, जबकि Matrix, Telegram, और अन्य live transports एक explicit transport-contract checklist share करते हैं। QA path में Docker लाए बिना disposable Linux VM lane के लिए, चलाएँ: ```bash 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 ` का उपयोग करें, या 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 का एक [समर्पित पेज](/hi/concepts/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 स्वीकार करती हैं: | Flag | Default | विवरण | | ------------------------------------- | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--scenario ` | - | केवल यह scenario चलाएं। दोहराने योग्य। | | `--output-dir ` | `/.artifacts/qa-e2e/-` | जहां reports, summaries, evidence, transport-specific artifacts, और output log लिखे जाते हैं। Relative paths `--repo-root` के विरुद्ध resolve होते हैं। | | `--repo-root ` | `process.cwd()` | किसी neutral cwd से invoke करते समय repository root। | | `--sut-account ` | `sut` | QA gateway config के अंदर temporary account id। | | `--provider-mode ` | `live-frontier` | `mock-openai` या `live-frontier` (legacy `live-openai` अभी भी काम करता है)। | | `--model ` / `--alt-model ` | provider default | Primary/alternate model refs। | | `--fast` | off | जहां supported हो वहां provider fast mode। | | `--credential-source ` | `env` | [Convex credential pool](#convex-credential-pool) देखें। | | `--credential-role ` | CI में `ci`, अन्यथा `maintainer` | `--credential-source convex` होने पर उपयोग की गई role। | किसी भी failed scenario पर प्रत्येक lane non-zero exit करती है। `--allow-failures` failing exit code set किए बिना artifacts लिखता है। ### Telegram QA ```bash 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 की जाती है। ```bash 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 ```bash 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 को स्पष्ट रूप से चलाएं: ```bash pnpm openclaw qa discord \ --scenario discord-voice-autojoin \ --provider-mode mock-openai ``` Mantis status-reaction scenario को स्पष्ट रूप से चलाएं: ```bash 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 ```bash 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 `.pending.json` और `.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](/hi/channels/slack#quick-setup) देखें; QA Driver/SUT pair जानबूझकर अलग है क्योंकि lane को एक workspace में दो distinct bot user ids चाहिए। **1. Driver app बनाएं** [api.slack.com/apps](https://api.slack.com/apps) पर जाएं → _Create New App_ → _From a manifest_ → QA workspace चुनें, निम्न manifest पेस्ट करें, फिर _Install to Workspace_ करें: ```json { "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 नहीं करता। ```json { "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 में लिखें: ```json { "channelId": "Cxxxxxxxxxx", "driverBotToken": "xoxb-...", "sutBotToken": "xoxb-...", "sutAppToken": "xapp-..." } ``` अपने shell में `OPENCLAW_QA_CONVEX_SITE_URL` और `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` export करके, register और verify करें: ```bash 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 के माध्यम से एक-दूसरे से बात कर सकते हैं: ```bash 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 ```bash 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 सेट अप करना](#setting-up-the-slack-workspace) देखें. Operational env vars और Convex broker endpoint contract [Testing → Convex के माध्यम से साझा Telegram credentials](/hi/help/testing#shared-telegram-credentials-via-convex-v1) में रहते हैं (section name multi-channel pool से पहले का है; lease semantics सभी kinds में shared हैं). ## Repo-backed seeds Seed assets `qa/` में रहते हैं: - `qa/scenarios/index.yaml` - `qa/scenarios//*.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 ` कैसे 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 ` के रूप में 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 ` चलाएँ. 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](/hi/maturity/scorecard) देखें. Character और style checks के लिए, same scenario को कई live model refs पर चलाएँ और judged Markdown report लिखें: ```bash 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=` के साथ। `--thinking ` अभी भी global fallback सेट करता है, और पुराना `--model-thinking ` रूप 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](/hi/concepts/qa-matrix) - [Maturity scorecard](/hi/maturity/scorecard) - [Personal agent benchmark pack](/hi/concepts/personal-agent-benchmark-pack) - [QA Channel](/hi/channels/qa-channel) - [Testing](/hi/help/testing) - [Dashboard](/hi/web/dashboard)