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 लोअरकेस अल्फ़ान्यूमेरिक/डैश खंडों वाले डॉटयुक्त namespace.behavior रूप का उपयोग करती हैं; प्रोफ़ाइल, सतह और श्रेणी ID अभी भी मौजूदा डैशयुक्त या डॉटयुक्त वर्गीकरण ID का उपयोग कर सकती हैं।

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

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

मॉक मॉडल प्रदाताओं और Crabline स्थानीय प्रदाता सर्वरों के साथ नियतात्मक प्रोफ़ाइल प्रमाण के लिए smoke-ci का उपयोग करें। लाइव चैनलों के विरुद्ध Stable/LTS प्रमाण के लिए release का उपयोग करें। all का उपयोग केवल स्पष्ट पूर्ण-वर्गीकरण साक्ष्य रन के लिए करें; यह प्रत्येक सक्रिय परिपक्वता श्रेणी का चयन करता है और इसे qa_profile=all के साथ QA Profile Evidence GitHub Actions वर्कफ़्लो के माध्यम से डिस्पैच किया जा सकता है। जब किसी कमांड को 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-चैनल एजेंट टर्न चलाता है, फिर पुष्टि करता है कि ट्रेस, मेट्रिक और लॉग निर्यात किए गए हैं। यह निर्यात किए गए 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, और रिडैक्ट किया गया matrix-harness-*/matrix-qa-harness.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) वाले पहले से मौजूद वास्तविक चैनल को लक्षित करते हैं। इन चार परिवहनों के लिए आवश्यक env var, परिदृश्य सूचियाँ, आउटपुट आर्टिफ़ैक्ट और 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 पोर्ट 38973 पर VM के भीतर एक स्थायी 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 से आता है, जो निष्पादित परिदृश्य, कवरेज आईडी, चैनल, वास्तव में उपयोग किए गए ड्राइवर और परिणाम को रिकॉर्ड करता है। चैनल और ड्राइवर रिपोर्ट के आयाम हैं, अतिरिक्त कवरेज-आईडी शब्दावलियाँ या परिदृश्य पात्रता अक्ष नहीं।

QA पथ में Docker लाए बिना एक डिस्पोज़ेबल 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 बॉट उपयोगकर्ता id से मेल खाना चाहिए (अन्यथा लेन तुरंत विफल हो जाती है)।

वैकल्पिक:

• 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 कमांड अनुमोदन परिदृश्य। Guardian मोड में Codex Plugin सक्षम करता है, 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 id जिसमें दोनों बॉट आमंत्रित किए गए हैं। समर्पित चैनल का उपयोग करें; लेन प्रत्येक रन में पोस्ट करती है।
• driverBotToken - Driver ऐप का बॉट टोकन (xoxb-...)।
• sutBotToken - SUT ऐप का बॉट टोकन (xoxb-...), जो ड्राइवर से अलग Slack ऐप होना चाहिए ताकि उसकी बॉट उपयोगकर्ता id अलग हो।
• 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 जोड़ी जानबूझकर अलग है क्योंकि लेन को एक कार्यस्थान में दो अलग-अलग बॉट उपयोगकर्ता id चाहिए।

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 के लिए OpenClaw QA SUT कनेक्टर"  },  "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 पूल सीड" 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 खातों को लक्षित करता है: हार्नेस द्वारा नियंत्रित एक ड्राइवर खाता और चाइल्ड OpenClaw gateway द्वारा बंडल किए गए WhatsApp plugin के माध्यम से शुरू किया गया एक 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 को नियतात्मक दृश्य अंतर की आवश्यकता होती है, तो Telegram फ़ॉर्मैटर या डिलीवरी परत बदलते समय Mantis main और PR हेड पर समान मॉक मॉडल उत्तर का उपयोग कर सकता है। कैप्चर डिफ़ॉल्ट PR टिप्पणियों के लिए अनुकूलित हैं: मानक Crabbox श्रेणी, 24fps डेस्कटॉप रिकॉर्डिंग, 24fps मोशन GIF और 1920px पूर्वावलोकन चौड़ाई। पहले/बाद की टिप्पणियों में एक साफ़ बंडल प्रकाशित होना चाहिए, जिसमें केवल अपेक्षित GIF हों।

Slack लेन भी पूल का उपयोग कर सकती हैं। Slack पेलोड आकार जाँचें वर्तमान में ब्रोकर के बजाय Slack QA रनर में स्थित हैं; { channelId: string, driverBotToken: string, sutBotToken: string, sutAppToken: string } का उपयोग करें, और Slack चैनल आईडी के रूप में Cxxxxxxxxxx जैसा मान दें। ऐप और स्कोप प्रावधान के लिए 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 के सामान्य चैनल plugins को उनके विरुद्ध चलाता है। live वास्तविक प्रदाता क्रेडेंशियल और बाहरी चैनलों के लिए आरक्षित है।

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

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

चैनल जोड़ना

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

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

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

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

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

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

नए चैनल के लिए न्यूनतम अंगीकरण मानदंड:

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

प्रत्येक qa suite रन चयनित परिदृश्य सेट के लिए शीर्ष-स्तरीय qa-evidence.json, qa-suite-summary.json और qa-suite-report.md आर्टिफ़ैक्ट लिखता है। execution.kind: vitest या execution.kind: playwright घोषित करने वाले परिदृश्य संगत परीक्षण पथ चलाते हैं और प्रति-परिदृश्य लॉग भी लिखते हैं। execution.kind: script घोषित करने वाले परिदृश्य 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 चैनल
• परीक्षण
• डैशबोर्ड