QA अवलोकन

निजी QA स्टैक OpenClaw को यथार्थपरक, चैनल-सदृश तरीके से परखता है, जिसे यूनिट परीक्षण नहीं परख सकता।

घटक:

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

कमांड सतह

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

प्रोफ़ाइल-समर्थित qa run

प्रोफ़ाइल-समर्थित qa run, taxonomy.yaml से सदस्यता पढ़ता है, फिर समाधान किए गए परिदृश्यों को qa suite के माध्यम से डिस्पैच करता है। --surface और --category अलग लेन निर्धारित करने के बजाय चुनी गई प्रोफ़ाइल को फ़िल्टर करते हैं। परिणामी qa-evidence.json में चुनी गई श्रेणियों की गिनती और अनुपलब्ध कवरेज ID वाली प्रोफ़ाइल स्कोरकार्ड समरी शामिल होती है; अलग-अलग साक्ष्य प्रविष्टियाँ परीक्षणों, कवरेज भूमिकाओं और परिणामों के लिए सत्य का स्रोत बनी रहती हैं। टैक्सोनॉमी फ़ीचर कवरेज ID सटीक प्रमाण लक्ष्य हैं, उपनाम नहीं: प्राथमिक परिदृश्य कवरेज मिलती हुई ID को पूरा करता है, जबकि द्वितीयक कवरेज परामर्शात्मक रहता है। प्रत्येक कवरेज ID बिल्कुल taxonomy-surface.feature है, जिसमें taxonomy.yaml की संक्षिप्त सतह ID का उपयोग होता है। किसी परिदृश्य का अलग surface फ़ील्ड निष्पादन/रिपोर्टिंग लेबल है (उदाहरण के लिए, channel या runtime-tool); यह टैक्सोनॉमी स्वामित्व निर्धारित नहीं करता।

संक्षिप्त साक्ष्य प्रत्येक प्रविष्टि के execution को छोड़ देता है और evidenceMode: "slim" सेट करता है; smoke-ci का डिफ़ॉल्ट संक्षिप्त है, और --evidence-mode full पूर्ण प्रविष्टियाँ पुनर्स्थापित करता है:

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

मॉक मॉडल प्रदाताओं और Crabline स्थानीय प्रदाता सर्वरों के साथ नियतात्मक प्रोफ़ाइल प्रमाण के लिए smoke-ci का उपयोग करें। लाइव चैनलों के विरुद्ध Stable/LTS प्रमाण के लिए release का उपयोग करें। केवल स्पष्ट पूर्ण-टैक्सोनॉमी साक्ष्य रन के लिए all का उपयोग करें; यह प्रत्येक सक्रिय परिपक्वता श्रेणी को चुनता है और इसे QA Profile Evidence GitHub Actions वर्कफ़्लो के माध्यम से qa_profile=all के साथ डिस्पैच किया जा सकता है। जब किसी कमांड को OpenClaw रूट प्रोफ़ाइल की भी आवश्यकता हो, तो रूट प्रोफ़ाइल को QA कमांड से पहले रखें:

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

ऑपरेटर प्रवाह

वर्तमान QA ऑपरेटर प्रवाह दो-पेन वाली QA साइट है:

• बायाँ: एजेंट वाला Gateway डैशबोर्ड (Control UI)।
• दायाँ: QA Lab, जो Slack-जैसा ट्रांसक्रिप्ट और परिदृश्य योजना दिखाता है।

इसे इससे चलाएँ:

pnpm qa:lab:up

यह QA साइट बनाता है, Docker-समर्थित Gateway लेन शुरू करता है और QA Lab पेज उपलब्ध कराता है, जहाँ कोई ऑपरेटर या ऑटोमेशन लूप एजेंट को QA मिशन दे सकता है, वास्तविक चैनल व्यवहार देख सकता है और यह दर्ज कर सकता है कि क्या सफल हुआ, विफल हुआ या अवरुद्ध रहा।

हर बार Docker इमेज दोबारा बनाए बिना तेज़ QA Lab UI पुनरावृत्ति के लिए, बाइंड-माउंट किए गए QA Lab बंडल के साथ स्टैक शुरू करें:

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

qa:lab:up:fast Docker सेवाओं को पहले से बनी इमेज पर रखता है और extensions/qa-lab/web/dist को qa-lab कंटेनर में बाइंड-माउंट करता है। qa:lab:watch बदलाव होने पर उस बंडल को दोबारा बनाता है और QA Lab एसेट हैश बदलने पर ब्राउज़र स्वतः पुनः लोड होता है।

प्रेक्षणीयता स्मोक

qa:otel:smoke एक स्थानीय OTLP/HTTP रिसीवर शुरू करता है, न्यूनतम QA-channel एजेंट टर्न चलाता है, फिर पुष्टि करता है कि ट्रेस, मेट्रिक्स और लॉग निर्यात किए गए हैं। यह निर्यात किए गए protobuf ट्रेस स्पैन को डिकोड करता है और रिलीज़-महत्वपूर्ण संरचना की जाँच करता है: openclaw.run, openclaw.harness.run, नवीनतम GenAI सिमैंटिक-कन्वेंशन मॉडल-कॉल स्पैन, openclaw.context.assembled, और openclaw.message.delivery सभी मौजूद होने चाहिए। स्मोक OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental को बाध्य करता है, इसलिए मॉडल-कॉल स्पैन को {gen_ai.operation.name} {gen_ai.request.model} नाम का उपयोग करना चाहिए; सफल टर्न पर मॉडल कॉल को StreamAbandoned निर्यात नहीं करना चाहिए; अपरिष्कृत डायग्नोस्टिक आईडी और openclaw.content.* एट्रिब्यूट ट्रेस से बाहर रहने चाहिए। परिदृश्य प्रॉम्प्ट मॉडल से एक निश्चित मार्कर के साथ उत्तर देने और एक निश्चित गोपनीय स्ट्रिंग रोकने के लिए कहता है; अपरिष्कृत OTLP पेलोड में इनमें से कोई भी या परिदृश्य आईडी से व्युत्पन्न QA सेशन कुंजी नहीं होनी चाहिए। यह QA सुइट आर्टिफ़ैक्ट के पास otel-smoke-summary.json लिखता है।

qa:prometheus:smoke सत्यापित करता है कि अप्रमाणित स्क्रेप अस्वीकार किए जाते हैं, फिर जाँचता है कि प्रमाणित स्क्रेप में प्रॉम्प्ट सामग्री, प्रतिक्रिया सामग्री, अपरिष्कृत डायग्नोस्टिक पहचानकर्ता, प्रमाणीकरण टोकन या स्थानीय पथों के बिना रिलीज़-महत्वपूर्ण मेट्रिक फ़ैमिली शामिल हैं।

Matrix स्मोक लेन

ऐसी ट्रांसपोर्ट-वास्तविक Matrix स्मोक लेन के लिए, जिसे मॉडल-प्रदाता क्रेडेंशियल की आवश्यकता नहीं है, नियतात्मक मॉक OpenAI प्रदाता के साथ रिलीज़ प्रोफ़ाइल चलाएँ:

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

लाइव-फ्रंटियर प्रदाता लेन के लिए, OpenAI-संगत क्रेडेंशियल स्पष्ट रूप से दें:

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

सादा pnpm openclaw qa matrix पूरा all प्रोफ़ाइल चलाता है और परिदृश्य विफलताओं के बाद भी जारी रहता है। छोटे फ़ीडबैक लूप के लिए --fail-fast का उपयोग करें या अलग-अलग परिदृश्य चुनने के लिए --scenario <id> दोहराएँ; स्पष्ट परिदृश्य आईडी को --profile पर वरीयता मिलती है।

प्रोफ़ाइल सदस्यता और चैनल आवश्यकताएँ qa/scenarios/channels/ के अंतर्गत घोषणात्मक Matrix परिदृश्यों के साथ रहती हैं। रन चैनल ड्राइवर चुनता है। उनके लाइव कार्यान्वयन extensions/qa-lab/src/live-transports/matrix/scenarios/ के अंतर्गत रहते हैं।

एडेप्टर Docker में एक अस्थायी Tuwunel होमसर्वर प्रावधान करता है (डिफ़ॉल्ट इमेज ghcr.io/matrix-construct/tuwunel:v1.5.1, सर्वर नाम matrix-qa.test, पोर्ट 28008), अस्थायी ड्राइवर, SUT और ऑब्ज़र्वर उपयोगकर्ताओं को पंजीकृत करता है, आवश्यक रूम तैयार करता है और संशोधित अनुरोध/प्रतिक्रिया सीमा रिकॉर्ड करता है। फिर यह उस ट्रांसपोर्ट तक सीमित चाइल्ड QA Gateway के भीतर वास्तविक Matrix Plugin चलाता है (qa-channel नहीं) और परिवेश को समाप्त कर देता है।

सामान्य विकल्प:

Matrix QA साझा Matrix क्रेडेंशियल लीज़ पर नहीं लेता: एडेप्टर स्थानीय रूप से अस्थायी उपयोगकर्ता बनाता है, इसलिए यह --credential-source या --credential-role स्वीकार नहीं करता। होमसर्वर इमेज को OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE से ओवरराइड करें; नकारात्मक उत्तर-न-मिलने संबंधी अभिकथनों को OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS से समायोजित करें (डिफ़ॉल्ट 8000, सक्रिय परिदृश्य टाइमआउट तक सीमित)। एकल-प्रयोग कमांड सामान्यतः आर्टिफ़ैक्ट फ़्लश होने के बाद स्वच्छ निकास को बाध्य करता है, क्योंकि Matrix क्रिप्टो नेटिव हैंडल सफ़ाई के बाद भी बने रह सकते हैं; OPENCLAW_QA_MATRIX_DISABLE_FORCE_EXIT=1 केवल ऐसे सीधे टेस्ट हार्नेस के लिए सेट करें जिसे इसके बजाय कमांड के वापस लौटने की आवश्यकता हो।

प्रत्येक रन चुनी गई आउटपुट डायरेक्टरी के अंतर्गत सामान्य QA Lab आर्टिफ़ैक्ट लिखता है: qa-suite-report.md, qa-suite-summary.json, और qa-evidence.json। यदि सफ़ाई विफल हो, तो मुद्रित docker compose ... down --remove-orphans पुनर्प्राप्ति कमांड चलाएँ। धीमे रनर पर, उत्तर-न-मिलने की अवधि बढ़ाएँ; तेज़ CI पर, छोटी अवधि नकारात्मक अभिकथनों को छोटा कर सकती है।

परिदृश्य ऐसे ट्रांसपोर्ट व्यवहार को कवर करते हैं जिन्हें यूनिट टेस्ट एंड-टू-एंड सिद्ध नहीं कर सकते: उल्लेख गेटिंग, बॉट-अनुमति नीतियाँ, अनुमति-सूचियाँ, शीर्ष-स्तरीय और थ्रेड वाले उत्तर, DM रूटिंग, प्रतिक्रिया प्रबंधन, इनबाउंड संपादन दमन, पुनः आरंभ रीप्ले डीडुप्लिकेशन, होमसर्वर व्यवधान पुनर्प्राप्ति, अनुमोदन मेटाडेटा वितरण, मीडिया प्रबंधन और Matrix E2EE बूटस्ट्रैप/पुनर्प्राप्ति/सत्यापन प्रवाह। E2EE CLI प्रोफ़ाइल Gateway उत्तरों की जाँच करने से पहले उसी अस्थायी होमसर्वर के माध्यम से openclaw matrix encryption setup और सत्यापन कमांड भी चलाता है।

matrix-room-block-streaming और subagent-thread-spawn स्पष्ट --scenario चयन द्वारा उपलब्ध रहते हैं, लेकिन डिफ़ॉल्ट all प्रोफ़ाइल से बाहर रहते हैं।

CI इसी कमांड सतह का उपयोग .github/workflows/qa-live-transports-convex.yml में करता है। निर्धारित और रिलीज़ रन रिलीज़ परिदृश्य निष्पादित करते हैं। मैन्युअल matrix_profile=all डिस्पैच transport, media, e2ee-smoke, e2ee-deep, और e2ee-cli प्रोफ़ाइलों में विभाजित होते हैं; केंद्रित डिस्पैच एक जॉब में fast, release, या transport चुनते हैं।

Discord Mantis परिदृश्य

Discord में बग पुनरुत्पादन के लिए केवल Mantis के वैकल्पिक परिदृश्य भी हैं। स्पष्ट स्थिति प्रतिक्रिया टाइमलाइन के लिए --scenario discord-status-reactions-tool-only का उपयोग करें, या एक वास्तविक Discord थ्रेड बनाने और सत्यापित करने के लिए --scenario discord-thread-reply-filepath-attachment का उपयोग करें कि message.thread-reply एक filePath अटैचमेंट को सुरक्षित रखता है। ये परिदृश्य डिफ़ॉल्ट लाइव Discord लेन से बाहर रहते हैं, क्योंकि ये व्यापक स्मोक कवरेज के बजाय पहले/बाद के पुनरुत्पादन प्रोब हैं। थ्रेड-अटैचमेंट Mantis कार्यप्रवाह QA परिवेश में MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR या MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64 कॉन्फ़िगर होने पर लॉग-इन किए गए Discord Web साक्षी का वीडियो भी जोड़ सकता है। वह व्यूअर प्रोफ़ाइल केवल दृश्य कैप्चर के लिए है; पास/विफलता निर्णय अभी भी Discord REST ऑरेकल से आता है।

अन्य ट्रांसपोर्ट-वास्तविक स्मोक लेन के लिए:

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

वे दो बॉट या अकाउंट (ड्राइवर + SUT) वाले पहले से मौजूद वास्तविक चैनल को लक्षित करते हैं। उन चार ट्रांसपोर्ट के लिए आवश्यक एनवायरनमेंट वैरिएबल, परिदृश्य सूचियाँ, आउटपुट आर्टिफ़ैक्ट और Convex क्रेडेंशियल पूल नीचे Discord, Slack, Telegram और WhatsApp QA संदर्भ में प्रलेखित हैं।

Mantis Slack डेस्कटॉप और दृश्य-कार्य रनर

VNC बचाव सहित पूर्ण Slack डेस्कटॉप VM रन के लिए, चलाएँ:

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

वह कमांड एक Crabbox डेस्कटॉप/ब्राउज़र मशीन लीज़ करती है, VM के भीतर Slack लाइव लेन चलाती है, VNC ब्राउज़र में Slack Web खोलती है, डेस्कटॉप कैप्चर करती है, और slack-qa/, slack-desktop-smoke.png, तथा slack-desktop-smoke.mp4 (जब वीडियो कैप्चर उपलब्ध हो) को वापस Mantis आर्टिफ़ैक्ट डायरेक्टरी में कॉपी करती है। Crabbox डेस्कटॉप/ब्राउज़र लीज़ कैप्चर टूल और ब्राउज़र/नेटिव-बिल्ड सहायक पैकेज पहले से उपलब्ध कराती हैं, इसलिए परिदृश्य को केवल पुरानी लीज़ पर फ़ॉलबैक इंस्टॉल करने चाहिए। Mantis कुल और हर चरण की टाइमिंग mantis-slack-desktop-smoke-report.md में रिपोर्ट करता है, ताकि धीमे रन दिखा सकें कि समय लीज़ वार्मअप, क्रेडेंशियल प्राप्ति, रिमोट सेटअप या आर्टिफ़ैक्ट कॉपी में गया। VNC के माध्यम से Slack Web में मैन्युअल रूप से लॉग इन करने के बाद --lease-id <cbx_...> का पुनः उपयोग करें; पुनः उपयोग की गई लीज़ Crabbox के pnpm स्टोर कैश को भी वार्म रखती हैं। डिफ़ॉल्ट --hydrate-mode source सोर्स चेकआउट से सत्यापन करता है और VM के भीतर इंस्टॉल/बिल्ड चलाता है। --hydrate-mode prehydrated का उपयोग केवल तब करें जब पुनः उपयोग किए गए रिमोट वर्कस्पेस में पहले से node_modules और बिल्ड किया हुआ dist/ हो; यह मोड महँगे इंस्टॉल/बिल्ड चरण को छोड़ देता है और वर्कस्पेस तैयार न होने पर फ़ेल-क्लोज़ हो जाता है। --gateway-setup के साथ, Mantis VM के भीतर पोर्ट 38973 पर एक स्थायी OpenClaw Slack Gateway चालू छोड़ता है; इसके बिना, कमांड सामान्य बॉट-टू-बॉट Slack QA लेन चलाती है और आर्टिफ़ैक्ट कैप्चर के बाद बाहर निकल जाती है।

डेस्कटॉप साक्ष्य के साथ नेटिव Slack अनुमोदन UI सिद्ध करने के लिए, Mantis अनुमोदन चेकपॉइंट मोड चलाएँ:

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

यह मोड --gateway-setup के साथ परस्पर अनन्य है। यह Slack अनुमोदन परिदृश्य चलाता है, गैर-अनुमोदन परिदृश्य आईडी अस्वीकार करता है, प्रत्येक लंबित और समाधान किए गए अनुमोदन की स्थिति पर प्रतीक्षा करता है, देखे गए Slack API संदेश को approval-checkpoints/<scenario>-pending.png और approval-checkpoints/<scenario>-resolved.png में रेंडर करता है, फिर किसी भी चेकपॉइंट, संदेश साक्ष्य, अभिस्वीकृति या रेंडर किए गए स्क्रीनशॉट के अनुपलब्ध या खाली होने पर विफल हो जाता है। कोल्ड CI लीज़ में अभी भी slack-desktop-smoke.png में Slack साइन-इन दिखाई दे सकता है; अनुमोदन चेकपॉइंट इमेज इस लेन का दृश्य प्रमाण हैं।

डिफ़ॉल्ट चेकपॉइंट रन दो मानक Slack अनुमोदन परिदृश्यों को बनाए रखता है। किसी भी ऑप्ट-इन Codex अनुमोदन रूट को कैप्चर करने के लिए, उसे --scenario slack-codex-approval-exec-native या --scenario slack-codex-approval-plugin-native के साथ स्पष्ट रूप से चुनें; Mantis दोनों को स्वीकार करता है और वही लंबित/समाधान किया गया स्क्रीनशॉट युग्म उत्सर्जित करता है। रनर प्रत्येक चुने गए Codex रूट के लिए अपने चेकपॉइंट और रिमोट-कमांड की समय-सीमाएँ बढ़ाता है, ताकि संपूर्ण अनुमोदन, एजेंट पूर्णता और समाधान किए गए अपडेट का क्रम पूरा हो सके।

ऑपरेटर चेकलिस्ट, GitHub वर्कफ़्लो डिस्पैच कमांड, साक्ष्य-टिप्पणी अनुबंध, हाइड्रेट-मोड निर्णय तालिका, टाइमिंग की व्याख्या और विफलता प्रबंधन चरण Mantis Slack डेस्कटॉप रनबुक में उपलब्ध हैं।

एजेंट/CV शैली के डेस्कटॉप कार्य के लिए, चलाएँ:

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

visual-task एक Crabbox डेस्कटॉप/ब्राउज़र मशीन लीज़ करता है या पुनः उपयोग करता है, crabbox record --while शुरू करता है, नेस्टेड visual-driver के माध्यम से दृश्यमान ब्राउज़र संचालित करता है, visual-task.png कैप्चर करता है, --vision-mode image-describe चुने जाने पर स्क्रीनशॉट के विरुद्ध openclaw infer image describe चलाता है और visual-task.mp4, mantis-visual-task-summary.json, mantis-visual-task-driver-result.json तथा mantis-visual-task-report.md लिखता है। जब --expect-text सेट हो, तब विज़न प्रॉम्प्ट एक संरचित JSON निर्णय (visible, evidence, reason) माँगता है और केवल तभी पास होता है जब मॉडल अपेक्षित टेक्स्ट का उल्लेख करने वाले साक्ष्य के साथ visible: true रिपोर्ट करता है; केवल लक्षित टेक्स्ट उद्धृत करने वाली visible: false प्रतिक्रिया तब भी अभिकथन में विफल होती है। ऐसे नो-मॉडल स्मोक के लिए --vision-mode metadata का उपयोग करें, जो इमेज-अंडरस्टैंडिंग प्रदाता को कॉल किए बिना डेस्कटॉप, ब्राउज़र, स्क्रीनशॉट और वीडियो प्लंबिंग को सिद्ध करता है। रिकॉर्डिंग visual-task के लिए एक आवश्यक आर्टिफ़ैक्ट है; यदि Crabbox कोई गैर-खाली visual-task.mp4 रिकॉर्ड नहीं करता, तो विज़ुअल ड्राइवर के पास होने पर भी कार्य विफल हो जाता है। विफलता पर, Mantis VNC के लिए लीज़ बनाए रखता है, जब तक कि कार्य पहले ही पास न हो गया हो और --keep-lease सेट न हो।

क्रेडेंशियल पूल स्वास्थ्य जाँच

पूल किए गए लाइव क्रेडेंशियल का उपयोग करने से पहले, चलाएँ:

pnpm openclaw qa credentials doctor

डॉक्टर Convex ब्रोकर एन्व (OPENCLAW_QA_CONVEX_SITE_URL, OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX) की जाँच करता है, एंडपॉइंट सेटिंग सत्यापित करता है, OPENCLAW_QA_CONVEX_SECRET_CI और OPENCLAW_QA_CONVEX_SECRET_MAINTAINER के लिए केवल सेट/अनुपलब्ध स्थिति रिपोर्ट करता है और मेंटेनर सीक्रेट मौजूद होने पर एडमिन/सूची की पहुँच सत्यापित करता है।

कैनोनिकल परिदृश्य कवरेज

रूट taxonomy.yaml सिमैंटिक कवरेज आईडी परिभाषित करता है। qa/scenarios/ के अंतर्गत परिदृश्य YAML फ़ाइलें प्रत्येक परिदृश्य को उन आईडी से मैप करती हैं और निष्पादन मेटाडेटा की स्वामी होती हैं: channel ही एकमात्र चैनल आवश्यकता है, और profiles नामित रन सदस्यता घोषित करते हैं। चैनल ड्राइवर रन-स्तर का एक विनिमेय कार्यान्वयन विकल्प है। TypeScript रनर उस कैटलॉग को क्वेरी करते हैं; वे समानांतर परिदृश्य या कवरेज इन्वेंटरी का रखरखाव नहीं करते।

स्थिर qa coverage आउटपुट वर्गीकरण-से-परिदृश्य मैपिंग रिपोर्ट करता है। वास्तविक प्रमाण qa-evidence.json से आता है, जो निष्पादित परिदृश्य, कवरेज आईडी, चैनल, वास्तव में उपयोग किया गया ड्राइवर और परिणाम रिकॉर्ड करता है। चैनल और ड्राइवर रिपोर्ट आयाम हैं, अतिरिक्त कवरेज-आईडी शब्दावलियाँ या परिदृश्य पात्रता अक्ष नहीं।

Docker को QA पथ में लाए बिना डिस्पोज़ेबल Linux VM लेन के लिए, चलाएँ:

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

यह नया Multipass गेस्ट बूट करता है, डिपेंडेंसी इंस्टॉल करता है, गेस्ट के भीतर OpenClaw बिल्ड करता है, qa suite चलाता है, फिर सामान्य QA रिपोर्ट और सारांश को होस्ट पर .artifacts/qa-e2e/... में वापस कॉपी करता है। यह होस्ट पर qa suite के समान परिदृश्य-चयन व्यवहार का पुनः उपयोग करता है।

होस्ट और Multipass सुइट रन डिफ़ॉल्ट रूप से पृथक Gateway वर्कर के साथ कई चुने गए परिदृश्यों को समानांतर में निष्पादित करते हैं। qa-channel की डिफ़ॉल्ट कनकरेंसी 4 है, जिसे चुने गए परिदृश्यों की संख्या सीमित करती है। वर्कर संख्या समायोजित करने के लिए --concurrency <count>, या क्रमिक निष्पादन के लिए --concurrency 1 का उपयोग करें। व्यक्तिगत सहायक बेंचमार्क पैक (10 परिदृश्य) चलाने के लिए --pack personal-agent का उपयोग करें। पैक चयनकर्ता दोहराए गए --scenario फ़्लैग के साथ योज्य है: स्पष्ट परिदृश्य पहले चलते हैं, फिर पैक परिदृश्य पैक क्रम में चलते हैं और डुप्लिकेट हटा दिए जाते हैं। जब कोई कस्टम QA रनर पहले से OpenTelemetry कलेक्टर सेटअप उपलब्ध कराता हो, तब otel-trace-smoke और docker-prometheus-smoke परिदृश्यों को साथ चुनने के लिए --pack observability का उपयोग करें।

कोई भी परिदृश्य विफल होने पर कमांड गैर-शून्य स्थिति के साथ बाहर निकलती है। यदि विफल निकास कोड के बिना आर्टिफ़ैक्ट चाहिए, तो --allow-failures का उपयोग करें।

लाइव रन गेस्ट के लिए व्यावहारिक समर्थित QA प्रमाणीकरण इनपुट फ़ॉरवर्ड करते हैं: एन्व-आधारित प्रदाता कुंजियाँ, QA लाइव प्रदाता कॉन्फ़िग पथ और उपलब्ध होने पर CODEX_HOME। --output-dir को रिपॉज़िटरी रूट के अंतर्गत रखें, ताकि गेस्ट माउंट किए गए वर्कस्पेस के माध्यम से वापस लिख सके।

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

Matrix एडाप्टर ऊपर दस्तावेज़ीकृत डिस्पोज़ेबल Docker-समर्थित लेन का उपयोग करता है। Discord, Slack, Telegram और WhatsApp पहले से मौजूद वास्तविक ट्रांसपोर्ट के विरुद्ध चलते हैं, इसलिए उनका संदर्भ यहाँ दिया गया है।

साझा CLI फ़्लैग

ये लेन extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts के माध्यम से पंजीकृत होती हैं और समान फ़्लैग स्वीकार करती हैं:

किसी भी विफल परिदृश्य पर प्रत्येक लेन गैर-शून्य स्थिति के साथ बाहर निकलती है। --allow-failures विफल निकास कोड सेट किए बिना आर्टिफ़ैक्ट लिखता है। Telegram उपलब्ध परिदृश्य आईडी प्रिंट करके बाहर निकलने के लिए --list-scenarios भी स्वीकार करता है; अन्य लेन वह फ़्लैग उपलब्ध नहीं करातीं।

Telegram QA

pnpm openclaw qa telegram

यह दो अलग-अलग बॉट (ड्राइवर + SUT) वाले एक वास्तविक निजी Telegram समूह को लक्षित करता है। SUT बॉट का Telegram उपयोगकर्ता नाम होना आवश्यक है; बॉट-टू-बॉट अवलोकन तब सबसे अच्छा काम करता है जब दोनों बॉट में @BotFather में Bot-to-Bot Communication Mode सक्षम हो।

--credential-source env होने पर आवश्यक एन्व:

• OPENCLAW_QA_TELEGRAM_GROUP_ID - संख्यात्मक चैट आईडी (स्ट्रिंग)।
• OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN
• OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN

release प्रोफ़ाइल अनुरक्षित Telegram YAML परिदृश्य चुनती है; all ऑप्ट-इन सत्र, उपयोग, प्रत्युत्तर-श्रृंखला और स्ट्रीमिंग स्ट्रेस जाँच जोड़ता है। स्पष्ट --scenario मान प्रोफ़ाइल को ओवरराइड करते हैं।

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

release प्रोफ़ाइल हमेशा कैनरी, उल्लेख गेटिंग, नेटिव कमांड उत्तर, कमांड संबोधन और बॉट-से-बॉट समूह उत्तरों को कवर करती है। mock-openai में नियतात्मक लंबे-अंतिम पूर्वावलोकन की जाँच भी शामिल है। telegram-current-session-status-tool और telegram-tool-only-usage-footer वैकल्पिक बने रहते हैं: पहला केवल तभी स्थिर होता है जब उसे कैनरी के ठीक बाद थ्रेड किया जाए, और दूसरा केवल-टूल उत्तरों पर /usage फ़ुटर का वास्तविक-Telegram प्रमाण है। रिग्रेशन संदर्भों के साथ वर्तमान डिफ़ॉल्ट/वैकल्पिक विभाजन प्रिंट करने के लिए pnpm openclaw qa telegram --list-scenarios --provider-mode mock-openai का उपयोग करें। प्रत्येक Telegram लाइव-अडैप्टर परिदृश्य के लिए --profile all का उपयोग करें।

आउटपुट आर्टिफ़ैक्ट:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json - लाइव ट्रांसपोर्ट जाँचों की साक्ष्य प्रविष्टियाँ, जिनमें प्रोफ़ाइल, कवरेज, प्रदाता, चैनल, आर्टिफ़ैक्ट, परिणाम और RTT फ़ील्ड शामिल हैं।

पैकेज Telegram रन समान Telegram क्रेडेंशियल अनुबंध का उपयोग करते हैं। बार-बार RTT मापन सामान्य पैकेज Telegram लाइव लेन का हिस्सा है; चयनित RTT जाँच के लिए RTT वितरण को result.timing के अंतर्गत qa-evidence.json में समाहित किया जाता है।

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

जब OPENCLAW_QA_CREDENTIAL_SOURCE=convex सेट होता है, तो पैकेज लाइव रैपर एक kind: "telegram" क्रेडेंशियल लीज़ करता है, लीज़ किए गए समूह/ड्राइवर/SUT बॉट परिवेश को इंस्टॉल किए गए पैकेज रन में निर्यात करता है, लीज़ को Heartbeat भेजता है और शटडाउन पर उसे रिलीज़ करता है। पैकेज रैपर डिफ़ॉल्ट रूप से channel-canary की 20 RTT जाँचें, 30s RTT टाइमआउट और Convex चुने जाने पर CI के बाहर Convex भूमिका maintainer का उपयोग करता है। अलग RTT कमांड या Telegram-विशिष्ट सारांश प्रारूप बनाए बिना RTT मापन समायोजित करने के लिए OPENCLAW_NPM_TELEGRAM_RTT_SAMPLES, OPENCLAW_NPM_TELEGRAM_RTT_TIMEOUT_MS या OPENCLAW_NPM_TELEGRAM_RTT_MAX_FAILURES को ओवरराइड करें।

Discord QA

pnpm openclaw qa discord

दो बॉट वाले एक वास्तविक निजी Discord गिल्ड चैनल को लक्षित करता है: हार्नेस द्वारा नियंत्रित ड्राइवर बॉट और बंडल किए गए Discord plugin के माध्यम से चाइल्ड OpenClaw Gateway द्वारा शुरू किया गया SUT बॉट। चैनल उल्लेख प्रबंधन, SUT बॉट द्वारा Discord के साथ नेटिव /help कमांड पंजीकृत किए जाने और वैकल्पिक Mantis साक्ष्य परिदृश्यों की पुष्टि करता है।

--credential-source env होने पर आवश्यक परिवेश:

• OPENCLAW_QA_DISCORD_GUILD_ID
• OPENCLAW_QA_DISCORD_CHANNEL_ID
• OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN
• OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN
• OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID - Discord द्वारा लौटाई गई SUT बॉट उपयोगकर्ता आईडी से मेल खाना आवश्यक है (अन्यथा लेन तुरंत विफल हो जाती है)।

वैकल्पिक:

• OPENCLAW_QA_DISCORD_VOICE_CHANNEL_ID, discord-voice-autojoin के लिए वॉइस/स्टेज चैनल चुनता है; इसके बिना, परिदृश्य SUT बॉट को दिखाई देने वाला पहला वॉइस/स्टेज चैनल चुनता है।

Discord YAML मॉड्यूल परिदृश्य (qa/scenarios/channels/discord-*.yaml):

• discord-canary
• discord-mention-gating
• discord-native-help-command-registration
• discord-voice-autojoin - वैकल्पिक वॉइस परिदृश्य। अपने आप चलता है, channels.discord.voice.autoJoin सक्षम करता है और पुष्टि करता है कि SUT बॉट की वर्तमान Discord वॉइस स्थिति लक्षित वॉइस/स्टेज चैनल है। Convex Discord क्रेडेंशियल में वैकल्पिक voiceChannelId शामिल हो सकता है; अन्यथा रनर अडैप्टर गिल्ड में दिखाई देने वाला पहला वॉइस/स्टेज चैनल खोजता है।
• discord-status-reactions-tool-only - वैकल्पिक Mantis परिदृश्य। यह अपने आप चलता है क्योंकि यह messages.statusReactions.enabled=true के साथ SUT को हमेशा-चालू, केवल-टूल गिल्ड उत्तरों पर स्विच करता है, फिर REST प्रतिक्रिया टाइमलाइन के साथ HTML/PNG विज़ुअल आर्टिफ़ैक्ट कैप्चर करता है। Mantis के पहले/बाद की रिपोर्टें परिदृश्य-प्रदत्त MP4 आर्टिफ़ैक्ट को baseline.mp4 और candidate.mp4 के रूप में भी सुरक्षित रखती हैं।
• discord-thread-reply-filepath-attachment - वैकल्पिक Mantis परिदृश्य; देखें Discord Mantis परिदृश्य।

Discord वॉइस ऑटो-जॉइन परिदृश्य स्पष्ट रूप से चलाएँ:

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

Mantis स्थिति-प्रतिक्रिया परिदृश्य स्पष्ट रूप से चलाएँ:

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

आउटपुट आर्टिफ़ैक्ट:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json - लाइव ट्रांसपोर्ट जाँचों की साक्ष्य प्रविष्टियाँ।
• discord-qa-reaction-timelines.json और स्थिति-प्रतिक्रिया परिदृश्य चलने पर discord-status-reactions-tool-only-timeline.png।

Slack QA

pnpm openclaw qa slack

दो अलग-अलग बॉट वाले एक वास्तविक निजी Slack चैनल को लक्षित करता है: हार्नेस द्वारा नियंत्रित ड्राइवर बॉट और बंडल किए गए Slack plugin के माध्यम से चाइल्ड OpenClaw Gateway द्वारा शुरू किया गया SUT बॉट।

--credential-source env होने पर आवश्यक परिवेश:

• OPENCLAW_QA_SLACK_CHANNEL_ID
• OPENCLAW_QA_SLACK_DRIVER_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_APP_TOKEN

वैकल्पिक:

• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR, Mantis के लिए विज़ुअल अनुमोदन चेकपॉइंट सक्षम करता है। अडैप्टर <scenario>.pending.json और <scenario>.resolved.json लिखता है, फिर मेल खाने वाली .ack.json फ़ाइलों की प्रतीक्षा करता है।
• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_TIMEOUT_MS, चेकपॉइंट अभिस्वीकृति टाइमआउट को ओवरराइड करता है। डिफ़ॉल्ट 120000 है।

Slack लाइव अडैप्टर के माध्यम से उपलब्ध कैनोनिकल YAML परिदृश्य:

• thread-follow-up
• thread-isolation

Slack YAML मॉड्यूल परिदृश्य (qa/scenarios/channels/slack-*.yaml):

• slack-canary
• slack-mention-gating
• slack-allowlist-block
• slack-channel-disabled-warning - वैकल्पिक वास्तविक-Slack जाँच, जो पुष्टि करती है कि कॉन्फ़िगर किया गया अक्षम चैनल उत्तर दिए बिना संरचित चेतावनी उत्सर्जित करता है।
• slack-top-level-reply-shape
• slack-restart-resume
• slack-progress-commentary-true, slack-progress-commentary-false, slack-progress-commentary-omitted और slack-progress-commentary-verbose-dedupe - स्वतंत्र टिप्पणी/टूल-प्रगति नियंत्रणों, छोड़ी गई-कुंजी के पुराने डिफ़ॉल्ट और टिकाऊ विस्तृत प्रगति चालू होने पर एकल-वितरण व्यवहार के लिए वैकल्पिक वास्तविक-Slack जाँचें।
• slack-reaction-glyph-native - वैकल्पिक लाइव संदेश-टूल प्रतिक्रिया परिदृश्य। एजेंट को सटीक ✅ ग्लिफ़ पास करने का निर्देश देता है और पुष्टि करता है कि Slack ने लक्षित संदेश पर SUT बॉट के लिए white_check_mark संग्रहीत किया।
• slack-chart-presentation-native - वैकल्पिक पोर्टेबल चार्ट परिदृश्य, जो नेटिव data_visualization ब्लॉक और सटीक सुलभ टेक्स्ट की पुष्टि करता है।
• slack-table-presentation-native - वैकल्पिक पोर्टेबल तालिका परिदृश्य, जो नेटिव data_table ब्लॉक, सटीक पंक्तियों और सुलभ टेक्स्ट की पुष्टि करता है।
• slack-table-invalid-blocks-fallback - वैकल्पिक प्रत्यक्ष-ट्रांसपोर्ट परिदृश्य, जो उत्पादन Slack प्रेषण पथ के माध्यम से 101 डेटा पंक्तियों और उनके हेडर वाली संरचनात्मक रूप से पठनीय, सीमा से अधिक बड़ी कच्ची तालिका भेजता है, प्रमाणित करता है कि Slack स्वयं invalid_blocks लौटाता है और पुष्टि करता है कि संग्रहीत फ़ॉर्मैटिंग-अक्षम फ़ॉलबैक पूर्ण है तथा उसमें कोई नेटिव डेटा ब्लॉक नहीं है। परिदृश्य विवरणों में केवल सुरक्षित त्रुटि-कोड, संख्या और बूलियन साक्ष्य रखे जाते हैं।
• slack-approval-exec-native - वैकल्पिक नेटिव Slack exec अनुमोदन परिदृश्य। Gateway के माध्यम से exec अनुमोदन का अनुरोध करता है, पुष्टि करता है कि Slack संदेश में नेटिव अनुमोदन बटन हैं, उसका समाधान करता है और समाधान किए गए Slack अपडेट की पुष्टि करता है।
• slack-approval-plugin-native - वैकल्पिक नेटिव Slack plugin अनुमोदन परिदृश्य। exec और plugin अनुमोदन अग्रेषण को साथ में सक्षम करता है, ताकि plugin ईवेंट exec अनुमोदन रूटिंग द्वारा दबाए न जाएँ, फिर उसी लंबित/समाधान किए गए नेटिव Slack UI पथ की पुष्टि करता है।
• slack-codex-approval-exec-native - वैकल्पिक Codex Guardian कमांड अनुमोदन परिदृश्य। Codex plugin को Guardian मोड में सक्षम करता है, Slack से शुरू हुए Gateway एजेंट टर्न को Codex ऐप-सर्वर हार्नेस से रूट करता है, openclaw-codex-app-server के लिए नेटिव Slack plugin अनुमोदन प्रॉम्प्ट की प्रतीक्षा करता है, उसका समाधान करता है और पुष्टि करता है कि Codex टर्न अपेक्षित कमांड-आउटपुट और सहायक मार्करों के साथ पूरा होता है।
• slack-codex-approval-plugin-native - वैकल्पिक Codex Guardian फ़ाइल अनुमोदन परिदृश्य। कार्यस्थान-बाहरी apply_patch निर्देश का उपयोग करता है, ताकि Codex ऐप-सर्वर फ़ाइल-परिवर्तन अनुमोदन रूट उत्सर्जित करे, फिर सफ़ाई से पहले उसी नेटिव Slack लंबित/समाधान किए गए अनुमोदन पथ, अंतिम सहायक मार्कर और सटीक फ़ाइल सामग्री की पुष्टि करता है।

Codex अनुमोदन परिदृश्यों के लिए openai/* या codex/* --model, सामान्य लाइव मॉडल क्रेडेंशियल और Codex plugin द्वारा स्वीकार किया गया Codex प्रमाणीकरण या API-कुंजी प्रमाणीकरण आवश्यक है। परिदृश्य विवरणों में संशोधित Slack अनुमोदन मेटाडेटा के साथ Codex ऐप-सर्वर विधि, चयनित Codex मॉडल कुंजी, अंतिम Codex टर्न स्थिति और ऑपरेशन-मार्कर सत्यापन शामिल हैं।

आउटपुट आर्टिफ़ैक्ट:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json - लाइव ट्रांसपोर्ट जाँचों की साक्ष्य प्रविष्टियाँ।
• approval-checkpoints/ - केवल तब, जब Mantis OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR सेट करता है; इसमें चेकपॉइंट JSON, अभिस्वीकृति JSON और लंबित/समाधान किए गए स्क्रीनशॉट होते हैं।

Slack कार्यस्थान सेट अप करना

लेन को एक कार्यस्थान में दो अलग-अलग Slack ऐप और एक ऐसा चैनल चाहिए, जिसके दोनों बॉट सदस्य हों:

• channelId - उस चैनल की Cxxxxxxxxxx आईडी, जिसमें दोनों बॉट आमंत्रित किए गए हैं। समर्पित चैनल का उपयोग करें; लेन प्रत्येक रन पर पोस्ट करती है।
• driverBotToken - Driver ऐप का बॉट टोकन (xoxb-...)।
• sutBotToken - SUT ऐप का बॉट टोकन (xoxb-...), जो ड्राइवर से अलग Slack ऐप होना आवश्यक है, ताकि उसकी बॉट उपयोगकर्ता आईडी अलग हो।
• sutAppToken - connections:write वाला SUT ऐप का ऐप-स्तरीय टोकन (xapp-...), जिसे Socket Mode उपयोग करता है, ताकि SUT ऐप ईवेंट प्राप्त कर सके।

उत्पादन कार्यस्थान का पुनः उपयोग करने के बजाय QA को समर्पित Slack कार्यस्थान को प्राथमिकता दें।

नीचे दिया गया SUT मैनिफ़ेस्ट जानबूझकर बंडल किए गए Slack plugin की उत्पादन स्थापना (extensions/slack/src/setup-shared.ts:12) को लाइव Slack QA सुइट द्वारा कवर की गई अनुमतियों और ईवेंट तक सीमित करता है। उपयोगकर्ताओं को दिखाई देने वाले उत्पादन-चैनल सेटअप के लिए Slack चैनल त्वरित सेटअप देखें; QA Driver/SUT जोड़ी जानबूझकर अलग रखी गई है, क्योंकि लेन को एक कार्यस्थान में दो अलग-अलग बॉट उपयोगकर्ता आईडी चाहिए।

1. Driver ऐप बनाएँ

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

{  "display_information": {    "name": "OpenClaw QA Driver",    "description": "OpenClaw QA Slack लाइव लेन के लिए परीक्षण ड्राइवर बॉट"  },  "features": {    "bot_user": {      "display_name": "OpenClaw QA Driver",      "always_online": true    }  },  "oauth_config": {    "scopes": {      "bot": ["chat:write", "channels:history", "groups:history", "users:read"]    }  },  "settings": {    "socket_mode_enabled": false  }}

Bot User OAuth Token (xoxb-...) कॉपी करें - यह driverBotToken बनता है। ड्राइवर को केवल संदेश पोस्ट करने और अपनी पहचान करने की आवश्यकता है; कोई ईवेंट नहीं, कोई Socket Mode नहीं।

2. SUT ऐप बनाएँ

उसी कार्यस्थान में Create New App → From a manifest दोहराएँ। यह QA ऐप जानबूझकर बंडल किए गए Slack plugin के उत्पादन मैनिफ़ेस्ट (extensions/slack/src/setup-shared.ts:12) का अधिक सीमित संस्करण उपयोग करता है: प्रतिक्रिया स्कोप और ईवेंट छोड़े गए हैं, क्योंकि लाइव Slack QA सुइट अभी प्रतिक्रिया प्रबंधन को कवर नहीं करता।

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

Slack द्वारा ऐप बनाए जाने के बाद, उसके सेटिंग पृष्ठ पर दो कार्य करें:

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

प्रत्येक टोकन पर auth.test कॉल करके सत्यापित करें कि दोनों बॉट की उपयोगकर्ता आईडी अलग-अलग हैं। रनटाइम ड्राइवर और SUT में उपयोगकर्ता आईडी के आधार पर अंतर करता है; दोनों के लिए एक ही ऐप का पुनः उपयोग करने पर उल्लेख-गेटिंग तुरंत विफल हो जाएगी।

3. चैनल बनाएँ

QA कार्यक्षेत्र में एक चैनल बनाएँ (उदा. #openclaw-qa) और चैनल के भीतर से दोनों बॉट को आमंत्रित करें:

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

channel info → About → Channel ID से Cxxxxxxxxxx आईडी कॉपी करें—वह channelId बन जाती है। सार्वजनिक चैनल काम करता है; यदि आप निजी चैनल का उपयोग करते हैं, तो दोनों ऐप के पास पहले से groups:history है, इसलिए हार्नेस द्वारा इतिहास पढ़ना फिर भी सफल रहेगा।

4. क्रेडेंशियल पंजीकृत करें

दो विकल्प हैं। एकल-मशीन डीबगिंग के लिए env vars का उपयोग करें (चार OPENCLAW_QA_SLACK_* वेरिएबल सेट करें और --credential-source env पास करें), या साझा Convex पूल को सीड करें ताकि CI और अन्य मेंटेनर उन्हें लीज़ पर ले सकें।

Convex पूल के लिए, चार फ़ील्ड एक JSON फ़ाइल में लिखें:

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

अपने शेल में OPENCLAW_QA_CONVEX_SITE_URL और OPENCLAW_QA_CONVEX_SECRET_MAINTAINER एक्सपोर्ट करके, पंजीकरण और सत्यापन करें:

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

count: 1, status: "active" अपेक्षित हैं और कोई lease फ़ील्ड नहीं होना चाहिए।

5. शुरू से अंत तक सत्यापित करें

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

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

सफल रन 30 सेकंड से बहुत कम समय में पूरा हो जाता है और qa-suite-report.md में slack-canary तथा slack-mention-gating, दोनों की स्थिति pass दिखाई देती है। यदि लेन ~90 सेकंड तक अटकी रहती है और Convex credential pool exhausted for kind "slack" के साथ बंद होती है, तो या तो पूल खाली है या प्रत्येक पंक्ति लीज़ पर है—qa credentials list --kind slack --status all --json बताएगा कि इनमें से कौन-सी स्थिति है।

WhatsApp QA

pnpm openclaw qa whatsapp

यह दो समर्पित WhatsApp Web खातों को लक्षित करता है: हार्नेस द्वारा नियंत्रित एक ड्राइवर खाता और बंडल किए गए WhatsApp Plugin के माध्यम से चाइल्ड OpenClaw Gateway द्वारा आरंभ किया गया एक SUT खाता।

--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, whatsapp-mention-gating, whatsapp-group-pending-history-context, whatsapp-broadcast-group-fanout, whatsapp-group-activation-always, whatsapp-group-reply-to-bot-triggers, समूह कार्रवाई/मीडिया/पोल परिदृश्यों और whatsapp-group-allowlist-block जैसे समूह परिदृश्यों को सक्षम करता है।

WhatsApp YAML परिदृश्य (qa/scenarios/channels/whatsapp-*.yaml):

• बेसलाइन और समूह गेटिंग: whatsapp-canary, whatsapp-pairing-block, whatsapp-mention-gating, whatsapp-group-pending-history-context, whatsapp-group-activation-always, whatsapp-group-reply-to-bot-triggers, whatsapp-top-level-reply-shape, whatsapp-restart-resume, whatsapp-group-allowlist-block।
• नेटिव कमांड: whatsapp-help-command, whatsapp-status-command, whatsapp-commands-command, whatsapp-tools-compact-command, whatsapp-whoami-command, whatsapp-context-command, whatsapp-native-new-command।
• उत्तर और अंतिम-आउटपुट व्यवहार: whatsapp-tool-only-usage-footer, whatsapp-reply-to-message, whatsapp-group-reply-to-message, whatsapp-reply-to-mode-batched, whatsapp-reply-context-isolation, whatsapp-reply-delivery-shape, whatsapp-stream-final-message-accounting।
• उपयोगकर्ता-पथ संदेश कार्रवाइयाँ: whatsapp-agent-message-action-react एक वास्तविक ड्राइवर DM से शुरू होता है, मॉडल को message टूल कॉल करने देता है और नेटिव WhatsApp प्रतिक्रिया का अवलोकन करता है। whatsapp-agent-message-action-upload-file message(action=upload-file) के लिए इसी दृष्टिकोण का उपयोग करता है और नेटिव WhatsApp मीडिया का अवलोकन करता है। whatsapp-group-agent-message-action-react और whatsapp-group-agent-message-action-upload-file एक वास्तविक WhatsApp समूह में इन्हीं उपयोगकर्ता-दृश्य कार्रवाइयों को सिद्ध करते हैं।
• समूह फ़ैनआउट: whatsapp-broadcast-group-fanout एक उल्लेख वाले WhatsApp समूह संदेश से शुरू होता है और main तथा qa-second से अलग-अलग दृश्य उत्तरों का सत्यापन करता है।
• समूह सक्रियण: whatsapp-group-activation-always एक वास्तविक समूह सत्र को /activation always में बदलता है, सिद्ध करता है कि बिना उल्लेख वाला समूह संदेश एजेंट को सक्रिय करता है, फिर /activation mention पुनर्स्थापित करता है। whatsapp-group-reply-to-bot-triggers एक बॉट उत्तर सीड करता है, बिना स्पष्ट उल्लेख के उस पर एक नेटिव उद्धृत उत्तर भेजता है और सत्यापित करता है कि एजेंट उस उत्तर संदर्भ से सक्रिय होता है।
• इनबाउंड मीडिया और संरचित संदेश: whatsapp-inbound-image-caption, whatsapp-audio-preflight, whatsapp-inbound-structured-messages, whatsapp-group-audio-gating, whatsapp-inbound-reaction-no-trigger। ये ड्राइवर के माध्यम से वास्तविक WhatsApp चित्र, ऑडियो, दस्तावेज़, स्थान, संपर्क, स्टिकर और प्रतिक्रिया इवेंट भेजते हैं।
• प्रत्यक्ष Gateway अनुबंध जाँच: whatsapp-outbound-media-matrix, whatsapp-outbound-document-preserves-filename, whatsapp-outbound-poll, whatsapp-outbound-send-serialization, whatsapp-group-outbound-media, whatsapp-group-outbound-poll, whatsapp-message-actions, whatsapp-reply-context-isolation, whatsapp-reply-delivery-shape। ये जानबूझकर मॉडल प्रॉम्प्टिंग को बायपास करते हैं और निर्धारक Gateway/चैनल send, poll तथा message.action अनुबंधों को सिद्ध करते हैं।
• अभिगम-नियंत्रण कवरेज: whatsapp-access-control-dm-open, whatsapp-access-control-dm-disabled, whatsapp-access-control-group-open, whatsapp-access-control-group-disabled, whatsapp-group-allowlist-block।
• नेटिव अनुमोदन: whatsapp-approval-exec-deny-native, whatsapp-approval-exec-native, whatsapp-approval-exec-reaction-native, whatsapp-approval-exec-group-reaction-native, whatsapp-approval-plugin-native।
• स्थिति प्रतिक्रियाएँ: whatsapp-status-reactions, whatsapp-status-reaction-lifecycle।

कैटलॉग में वर्तमान में 52 परिदृश्य हैं। तेज़ स्मोक कवरेज के लिए live-frontier डिफ़ॉल्ट लेन को 8 परिदृश्यों तक छोटा रखा गया है। mock-openai डिफ़ॉल्ट लेन केवल मॉडल आउटपुट को मॉक करते हुए वास्तविक WhatsApp ट्रांसपोर्ट के माध्यम से 39 परिदृश्य निर्धारक रूप से चलाती है; अनुमोदन परिदृश्य और कुछ अधिक भारी/अवरोधक जाँच परिदृश्य आईडी द्वारा स्पष्ट रूप से चयनित रहती हैं।

WhatsApp QA ड्राइवर संरचित लाइव इवेंट (text, media, location, reaction और poll) का अवलोकन करता है और सक्रिय रूप से मीडिया, पोल, संपर्क, स्थान तथा स्टिकर भेज सकता है। QA Lab निजी WhatsApp रनटाइम फ़ाइलों में पहुँचने के बजाय उस ड्राइवर को @openclaw/whatsapp/api.js पैकेज सतह के माध्यम से इंपोर्ट करता है। समूह अवलोकनों के लिए, fromJid समूह JID है, जबकि participantJid और fromPhoneE164 प्रतिभागी प्रेषक की पहचान करते हैं। संदेश सामग्री डिफ़ॉल्ट रूप से संपादित कर छिपाई जाती है। प्रत्यक्ष Gateway पोल, फ़ाइल-अपलोड, मीडिया, समूह पोल, समूह मीडिया और उत्तर-आकार जाँच ट्रांसपोर्ट/API अनुबंध जाँच हैं; इन्हें इस बात का प्रमाण नहीं माना जाता कि किसी उपयोगकर्ता प्रॉम्प्ट ने एजेंट से वही कार्रवाई चुनवाई। उपयोगकर्ता-पथ कार्रवाई का प्रमाण whatsapp-agent-message-action-react और whatsapp-group-agent-message-action-react जैसे परिदृश्यों से आता है, जहाँ ड्राइवर एक सामान्य WhatsApp संदेश भेजता है और QA Lab उससे बनने वाली नेटिव WhatsApp कलाकृति का अवलोकन करता है। WhatsApp परिदृश्य विवरण में प्रत्येक परिदृश्य का दृष्टिकोण (user-path, direct-gateway या native-approval) शामिल होता है, ताकि साक्ष्य को उससे अधिक मजबूत अनुबंध का प्रमाण न समझ लिया जाए जितना वह वास्तव में सिद्ध करता है।

आउटपुट कलाकृतियाँ:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json—लाइव ट्रांसपोर्ट जाँचों के लिए साक्ष्य प्रविष्टियाँ।

Convex क्रेडेंशियल पूल

Discord, Slack, Telegram और WhatsApp लेन ऊपर दिए गए env vars पढ़ने के बजाय साझा Convex पूल से क्रेडेंशियल लीज़ पर ले सकती हैं। --credential-source convex पास करें (या OPENCLAW_QA_CREDENTIAL_SOURCE=convex सेट करें); QA Lab एक विशिष्ट लीज़ प्राप्त करता है, रन की अवधि तक उसके लिए Heartbeat भेजता है और शटडाउन पर उसे रिलीज़ करता है। पूल प्रकार "discord", "slack", "telegram" और "whatsapp" हैं।

admin/add पर ब्रोकर द्वारा सत्यापित पेलोड आकार:

• Discord (kind: "discord"): { guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string }।
• Telegram (kind: "telegram"): { groupId: string, driverToken: string, sutToken: string }—groupId एक संख्यात्मक चैट-आईडी स्ट्रिंग होनी चाहिए।
• Telegram वास्तविक उपयोगकर्ता (kind: "telegram-user"): { groupId: string, sutToken: string, testerUserId: string, testerUsername: string, telegramApiId: string, telegramApiHash: string, tdlibDatabaseEncryptionKey: string, tdlibArchiveBase64: string, tdlibArchiveSha256: string, desktopTdataArchiveBase64: string, desktopTdataArchiveSha256: string }— केवल Mantis Telegram Desktop प्रमाण। सामान्य QA Lab लेन को यह प्रकार प्राप्त नहीं करना चाहिए।
• 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 को निर्धारक दृश्य अंतर की आवश्यकता होती है, तो Mantis main और PR हेड पर समान मॉक मॉडल उत्तर का उपयोग कर सकता है, जबकि Telegram फ़ॉर्मैटर या डिलीवरी परत बदलती है। कैप्चर डिफ़ॉल्ट PR टिप्पणियों के लिए अनुकूलित हैं: मानक Crabbox श्रेणी, 24fps डेस्कटॉप रिकॉर्डिंग, 24fps मोशन GIF और 1920px पूर्वावलोकन चौड़ाई। पहले/बाद की टिप्पणियों को ऐसा साफ़ बंडल प्रकाशित करना चाहिए जिसमें केवल इच्छित GIF हों।

Slack लेन भी पूल का उपयोग कर सकती हैं। Slack पेलोड आकार जाँच वर्तमान में ब्रोकर के बजाय Slack QA रनर में रहती हैं; { channelId: string, driverBotToken: string, sutBotToken: string, sutAppToken: string } का उपयोग करें, जिसमें Cxxxxxxxxxx जैसी Slack चैनल आईडी हो। ऐप और स्कोप प्रावधान के लिए Slack कार्यक्षेत्र सेट अप करना देखें।

परिचालन env vars और Convex ब्रोकर एंडपॉइंट अनुबंध परीक्षण → Convex के माध्यम से साझा Telegram क्रेडेंशियल में दिए गए हैं (अनुभाग का नाम बहु-चैनल पूल से पहले का है; लीज़ शब्दार्थ सभी प्रकारों में साझा हैं)।

रेपो-समर्थित सीड

सीड एसेट qa/ में रहते हैं:

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

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

qa-lab एक सामान्य YAML परिदृश्य रनर बना रहता है। प्रत्येक परिदृश्य YAML फ़ाइल एक परीक्षण रन के लिए सत्य का स्रोत है और उसमें यह परिभाषित होना चाहिए:

• शीर्ष-स्तरीय title
• scenario मेटाडेटा
• scenario में वैकल्पिक श्रेणी, क्षमता, लेन और जोखिम मेटाडेटा
• scenario में दस्तावेज़ और कोड संदर्भ
• scenario में वैकल्पिक Plugin आवश्यकताएँ
• scenario में वैकल्पिक Gateway कॉन्फ़िगरेशन पैच
• प्रवाह परिदृश्यों के लिए निष्पादन योग्य शीर्ष-स्तरीय flow, या Vitest और Playwright परिदृश्यों के लिए scenario.execution.kind / scenario.execution.path

flow को आधार देने वाली पुन: प्रयोज्य रनटाइम सतह सामान्य और सभी क्षेत्रों में लागू रहती है। उदाहरण के लिए, YAML परिदृश्य ट्रांसपोर्ट-पक्ष के सहायकों को ब्राउज़र-पक्ष के उन सहायकों के साथ जोड़ सकते हैं, जो किसी विशेष-स्थिति रनर को जोड़े बिना Gateway browser.request सीम के माध्यम से एम्बेडेड Control UI को संचालित करते हैं।

परिदृश्य फ़ाइलों को स्रोत ट्री फ़ोल्डर के बजाय उत्पाद क्षमता के अनुसार समूहीकृत किया जाना चाहिए। फ़ाइलें स्थानांतरित होने पर परिदृश्य ID स्थिर रखें; कार्यान्वयन की अनुरेखणीयता के लिए docsRefs और codeRefs का उपयोग करें।

आधारभूत सूची इतनी व्यापक रहनी चाहिए कि इसमें ये शामिल हों:

• DM और चैनल चैट
• थ्रेड व्यवहार
• संदेश क्रिया जीवनचक्र
• Cron कॉलबैक
• मेमोरी पुनःस्मरण
• मॉडल स्विचिंग
• उप-एजेंट हस्तांतरण
• रेपो पढ़ना और दस्तावेज़ पढ़ना
• Lobster Invaders जैसा एक छोटा बिल्ड कार्य

प्रदाता मॉक लेन

qa suite में दो स्थानीय प्रदाता मॉक लेन हैं:

• mock-openai परिदृश्य-जागरूक OpenClaw मॉक है। यह रेपो-समर्थित QA और समानता गेट के लिए डिफ़ॉल्ट निर्धारक मॉक लेन बना रहता है।
• aimock प्रयोगात्मक प्रोटोकॉल, फ़िक्स्चर, रिकॉर्ड/रीप्ले और कैओस कवरेज के लिए AIMock-समर्थित प्रदाता सर्वर शुरू करता है। यह अतिरिक्त है और mock-openai परिदृश्य डिस्पैचर को प्रतिस्थापित नहीं करता।

प्रदाता-लेन कार्यान्वयन extensions/qa-lab/src/providers/ के अंतर्गत रहता है। प्रत्येक प्रदाता अपने डिफ़ॉल्ट, स्थानीय सर्वर स्टार्टअप, Gateway मॉडल कॉन्फ़िगरेशन, ऑथ-प्रोफ़ाइल स्टेजिंग आवश्यकताओं और लाइव/मॉक क्षमता फ़्लैग का स्वामी होता है। साझा सुइट और Gateway कोड प्रदाता नामों पर शाखा बनाने के बजाय प्रदाता रजिस्ट्री के माध्यम से रूट करता है।

ट्रांसपोर्ट अडैप्टर

qa-lab YAML QA परिदृश्यों के लिए एक सामान्य ट्रांसपोर्ट सीम का स्वामी है। qa-channel सिंथेटिक डिफ़ॉल्ट है। crabline स्थानीय प्रदाता-आकार के सर्वर शुरू करता है और उनके विरुद्ध OpenClaw के सामान्य चैनल Plugin चलाता है। live वास्तविक प्रदाता क्रेडेंशियल और बाहरी चैनलों के लिए आरक्षित है।

आर्किटेक्चर स्तर पर विभाजन यह है:

• qa-lab सामान्य परिदृश्य निष्पादन, वर्कर समवर्तीता, आर्टिफ़ैक्ट लेखन और रिपोर्टिंग का स्वामी है।
• ट्रांसपोर्ट अडैप्टर Gateway कॉन्फ़िगरेशन, तत्परता, इनबाउंड और आउटबाउंड अवलोकन, ट्रांसपोर्ट क्रियाओं और सामान्यीकृत ट्रांसपोर्ट स्थिति का स्वामी है।
• qa/scenarios/ के अंतर्गत YAML परिदृश्य फ़ाइलें परीक्षण रन को परिभाषित करती हैं; qa-lab उन्हें निष्पादित करने वाली पुन: प्रयोज्य रनटाइम सतह प्रदान करता है।

चैनल जोड़ना

YAML QA प्रणाली में चैनल जोड़ने के लिए चैनल कार्यान्वयन के साथ चैनल अनुबंध का अभ्यास करने वाला परिदृश्य पैक आवश्यक है। स्मोक CI कवरेज के लिए, मेल खाता Crabline स्थानीय प्रदाता सर्वर जोड़ें और उसे crabline ड्राइवर के माध्यम से उपलब्ध कराएँ।

जब साझा qa-lab होस्ट प्रवाह का स्वामी हो सकता है, तब नया शीर्ष-स्तरीय QA कमांड रूट न जोड़ें।

qa-lab साझा होस्ट तंत्र का स्वामी है:

• openclaw qa कमांड रूट
• सुइट स्टार्टअप और टियरडाउन
• वर्कर समवर्तीता
• आर्टिफ़ैक्ट लेखन
• रिपोर्ट निर्माण
• परिदृश्य निष्पादन
• पुराने qa-channel परिदृश्यों के लिए संगतता उपनाम

रनर Plugin ट्रांसपोर्ट अनुबंध के स्वामी होते हैं:

• साझा qa रूट के नीचे openclaw qa <runner> को कैसे माउंट किया जाता है
• उस ट्रांसपोर्ट के लिए Gateway को कैसे कॉन्फ़िगर किया जाता है
• तत्परता की जाँच कैसे की जाती है
• इनबाउंड इवेंट कैसे अंतःक्षेपित किए जाते हैं
• आउटबाउंड संदेशों का अवलोकन कैसे किया जाता है
• ट्रांसक्रिप्ट और सामान्यीकृत ट्रांसपोर्ट स्थिति कैसे उपलब्ध कराई जाती है
• ट्रांसपोर्ट-समर्थित क्रियाएँ कैसे निष्पादित की जाती हैं
• ट्रांसपोर्ट-विशिष्ट रीसेट या क्लीनअप कैसे संभाला जाता है

नए चैनल के लिए न्यूनतम अपनाने का मानदंड:

1. साझा qa रूट के स्वामी के रूप में qa-lab को बनाए रखें।
2. साझा qa-lab होस्ट सीम पर ट्रांसपोर्ट रनर लागू करें।
3. ट्रांसपोर्ट-विशिष्ट तंत्र को रनर Plugin या चैनल हार्नेस के अंदर रखें।
4. प्रतिस्पर्धी रूट कमांड पंजीकृत करने के बजाय रनर को openclaw qa <runner> के रूप में माउंट करें। रनर Plugin को openclaw.plugin.json में qaRunners घोषित करना चाहिए और runtime-api.ts से मेल खाती qaRunnerCliRegistrations सरणी निर्यात करनी चाहिए। runtime-api.ts को हल्का रखें; लेज़ी CLI और रनर निष्पादन अलग-अलग एंट्रीपॉइंट के पीछे रहने चाहिए। वैकल्पिक adapterFactory कमांड की मौजूदा परिदृश्य सूची बदले बिना ट्रांसपोर्ट को साझा परिदृश्यों के लिए उपलब्ध कराता है। समान-चैनल विभाजन क्रमिक होते हैं, जब तक फ़ैक्टरी यह घोषित न करे कि प्रत्येक इंस्टेंस पृथक क्रेडेंशियल या डिस्पोज़ेबल सर्वर, Gateway स्थिति और आर्टिफ़ैक्ट पथों का स्वामी है।
5. विषयगत qa/scenarios/ डायरेक्टरी के अंतर्गत YAML परिदृश्य लिखें या अनुकूलित करें।
6. नए परिदृश्यों के लिए सामान्य परिदृश्य सहायकों का उपयोग करें।
7. जब तक रेपो जानबूझकर माइग्रेशन नहीं कर रहा हो, मौजूदा संगतता उपनामों को कार्यशील रखें।

निर्णय नियम सख्त है:

• यदि व्यवहार को qa-lab में एक बार व्यक्त किया जा सकता है, तो उसे qa-lab में रखें।
• यदि व्यवहार एक चैनल ट्रांसपोर्ट पर निर्भर है, तो उसे उस रनर Plugin या Plugin हार्नेस में रखें।
• यदि किसी परिदृश्य को ऐसी नई क्षमता चाहिए जिसका उपयोग एक से अधिक चैनल कर सकते हैं, तो suite.ts में चैनल-विशिष्ट शाखा के बजाय एक सामान्य सहायक जोड़ें।
• यदि कोई व्यवहार केवल एक ट्रांसपोर्ट के लिए सार्थक है, तो परिदृश्य को ट्रांसपोर्ट-विशिष्ट रखें और परिदृश्य अनुबंध में इसे स्पष्ट करें।

परिदृश्य सहायक नाम

नए परिदृश्यों के लिए पसंदीदा सामान्य सहायक:

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

मौजूदा परिदृश्यों के लिए संगतता उपनाम उपलब्ध रहते हैं - waitForQaChannelReady, waitForOutboundMessage, waitForNoOutbound, formatConversationTranscript, resetBus - लेकिन नए परिदृश्य लेखन में सामान्य नामों का उपयोग किया जाना चाहिए। ये उपनाम एक साथ व्यापक माइग्रेशन से बचने के लिए हैं, भविष्य के मॉडल के रूप में नहीं।

रिपोर्टिंग

qa-lab अवलोकित बस टाइमलाइन से एक Markdown प्रोटोकॉल रिपोर्ट निर्यात करता है। रिपोर्ट को इन प्रश्नों के उत्तर देने चाहिए:

• क्या काम किया
• क्या विफल हुआ
• क्या अवरुद्ध रहा
• कौन-से अनुवर्ती परिदृश्य जोड़ना उपयोगी है

उपलब्ध परिदृश्यों की सूची के लिए - जो अनुवर्ती कार्य का आकार निर्धारित करते समय या नया ट्रांसपोर्ट वायर करते समय उपयोगी है - pnpm openclaw qa coverage चलाएँ (मशीन-पठनीय आउटपुट के लिए --json जोड़ें)। प्रभावित व्यवहार या फ़ाइल पथ के लिए केंद्रित प्रमाण चुनते समय, pnpm openclaw qa coverage --match <query> चलाएँ। मिलान रिपोर्ट परिदृश्य मेटाडेटा, दस्तावेज़ संदर्भ, कोड संदर्भ, कवरेज ID, Plugin और प्रदाता आवश्यकताओं में खोज करती है, फिर मेल खाते qa suite --scenario ... लक्ष्य प्रिंट करती है।

हर qa suite रन चयनित परिदृश्य सेट के लिए शीर्ष-स्तरीय qa-evidence.json, qa-suite-summary.json और qa-suite-report.md आर्टिफ़ैक्ट लिखता है। execution.kind: vitest या execution.kind: playwright घोषित करने वाले परिदृश्य मेल खाता परीक्षण पथ चलाते हैं और प्रति-परिदृश्य लॉग भी लिखते हैं। execution.kind: script घोषित करने वाले परिदृश्य node --import tsx के माध्यम से execution.path पर एविडेंस प्रोड्यूसर चलाते हैं (execution.args में ${outputDir} और ${scenarioId} विस्तारित होते हैं); प्रोड्यूसर अपना qa-evidence.json लिखता है, जिसकी प्रविष्टियाँ सुइट आउटपुट में आयात की जाती हैं और जिसके आर्टिफ़ैक्ट पथ उस प्रोड्यूसर qa-evidence.json के सापेक्ष रिज़ॉल्व किए जाते हैं। जब qa run --qa-profile के माध्यम से qa suite तक पहुँचा जाता है, तो उसी qa-evidence.json में चयनित टैक्सोनॉमी श्रेणियों के लिए प्रोफ़ाइल स्कोरकार्ड सारांश भी शामिल होता है।

कवरेज आउटपुट को खोज सहायक मानें, गेट का प्रतिस्थापन नहीं; चयनित परिदृश्य को परीक्षणाधीन व्यवहार के लिए अब भी सही प्रदाता मोड, लाइव ट्रांसपोर्ट, Multipass, Testbox या रिलीज़ लेन की आवश्यकता होती है। स्कोरकार्ड संदर्भ के लिए, परिपक्वता स्कोरकार्ड देखें।

चरित्र और शैली जाँच के लिए, एक ही परिदृश्य को कई लाइव मॉडल संदर्भों में चलाएँ और निर्णयित Markdown रिपोर्ट लिखें:

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

यह कमांड Docker नहीं, बल्कि स्थानीय QA Gateway चाइल्ड प्रोसेस चलाता है। चरित्र मूल्यांकन परिदृश्यों को SOUL.md के माध्यम से व्यक्तित्व सेट करना चाहिए, फिर चैट, वर्कस्पेस सहायता और छोटे फ़ाइल कार्य जैसे सामान्य उपयोगकर्ता टर्न चलाने चाहिए। उम्मीदवार मॉडल को यह नहीं बताया जाना चाहिए कि उसका मूल्यांकन किया जा रहा है। कमांड प्रत्येक पूर्ण ट्रांसक्रिप्ट सुरक्षित रखता है, बुनियादी रन आँकड़े दर्ज करता है, फिर जहाँ समर्थित हो वहाँ xhigh रीजनिंग के साथ फ़ास्ट मोड में जज मॉडल से स्वाभाविकता, अंदाज़ और हास्य के आधार पर रन को रैंक करने को कहता है। प्रदाताओं की तुलना करते समय --blind-judge-models का उपयोग करें: जज प्रॉम्प्ट को फिर भी हर ट्रांसक्रिप्ट और रन स्थिति मिलती है, लेकिन उम्मीदवार संदर्भों को candidate-01 जैसे तटस्थ लेबल से बदल दिया जाता है; पार्सिंग के बाद रिपोर्ट रैंकिंग को वास्तविक संदर्भों से फिर मैप करती है।

उम्मीदवार रन डिफ़ॉल्ट रूप से high थिंकिंग का उपयोग करते हैं, GPT-5.6 Luna के लिए medium और इसका समर्थन करने वाले पुराने OpenAI मूल्यांकन संदर्भों के लिए xhigh होता है। किसी विशिष्ट उम्मीदवार को इनलाइन --model provider/model,thinking=<level> से ओवरराइड करें; इनलाइन विकल्प fast, no-fast और fast=<bool> का भी समर्थन करते हैं। --thinking <level> अब भी वैश्विक फ़ॉलबैक सेट करता है, और पुराना --model-thinking <provider/model=level> रूप संगतता के लिए रखा गया है। OpenAI उम्मीदवार संदर्भ डिफ़ॉल्ट रूप से फ़ास्ट मोड का उपयोग करते हैं, ताकि जहाँ प्रदाता इसका समर्थन करता है वहाँ प्राथमिकता प्रोसेसिंग का उपयोग हो। हर उम्मीदवार मॉडल के लिए फ़ास्ट मोड को बाध्यतः चालू करने के लिए ही --fast पास करें। बेंचमार्क विश्लेषण के लिए उम्मीदवार और जज अवधि रिपोर्ट में दर्ज की जाती हैं, लेकिन जज प्रॉम्प्ट स्पष्ट रूप से गति के आधार पर रैंक न करने को कहते हैं। उम्मीदवार और जज मॉडल रन, दोनों की डिफ़ॉल्ट समवर्तीता 16 है। जब प्रदाता सीमाएँ या स्थानीय Gateway दबाव किसी रन को अत्यधिक शोरयुक्त बना दें, तो --concurrency या --judge-concurrency कम करें।

जब कोई उम्मीदवार --model पास नहीं किया जाता, तो चरित्र मूल्यांकन डिफ़ॉल्ट रूप से openai/gpt-5.6-luna, openai/gpt-5.2, openai/gpt-5, anthropic/claude-opus-4-8, anthropic/claude-sonnet-4-6, zai/glm-5.1, moonshot/kimi-k2.5 और google/gemini-3.1-pro-preview का उपयोग करता है। जब कोई --judge-model पास नहीं किया जाता, तो जज डिफ़ॉल्ट रूप से openai/gpt-5.6-sol,thinking=xhigh,fast और anthropic/claude-opus-4-8,thinking=high होते हैं।

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

• परिपक्वता स्कोरकार्ड
• व्यक्तिगत एजेंट बेंचमार्क पैक
• QA चैनल
• परीक्षण
• डैशबोर्ड