--- doc-schema-version: 1 read_when: - QA स्टैक किस तरह एक साथ काम करता है, इसे समझना - qa-lab, qa-channel, या किसी ट्रांसपोर्ट अडैप्टर का विस्तार करना - रिपॉज़िटरी-समर्थित QA परिदृश्य जोड़ना - Gateway डैशबोर्ड के लिए अधिक यथार्थपरक QA स्वचालन तैयार करना summary: 'QA स्टैक का अवलोकन: qa-lab, qa-channel, रिपॉज़िटरी-समर्थित परिदृश्य, लाइव ट्रांसपोर्ट लेन, ट्रांसपोर्ट अडैप्टर और रिपोर्टिंग।' title: QA अवलोकन x-i18n: generated_at: "2026-07-27T19:35:28Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 91c34a50e6197195d57228d92b19caff1785ceaa5d82d7c88a1ec0ed76abd635 source_path: concepts/qa-e2e-automation.md workflow: 16 --- निजी QA स्टैक OpenClaw को यथार्थपरक, चैनल-सदृश तरीके से परखता है, जिसे यूनिट परीक्षण नहीं परख सकता। घटक: - `extensions/qa-channel`: DM, चैनल, थ्रेड, प्रतिक्रिया, संपादन और हटाने की सतहों वाला सिंथेटिक संदेश चैनल। - `extensions/qa-lab`: ट्रांसक्रिप्ट देखने, इनबाउंड संदेश प्रविष्ट करने और Markdown रिपोर्ट निर्यात करने के लिए डीबगर UI, QA बस, परिदृश्य प्रोफ़ाइल और लाइव ट्रांसपोर्ट अडैप्टर। - `qa/`: आरंभिक कार्य और आधारभूत QA परिदृश्यों के लिए रिपॉज़िटरी-समर्थित सीड एसेट। - [Mantis](/hi/concepts/mantis): उन बग के लिए पहले/बाद का लाइव सत्यापन, जिन्हें वास्तविक ट्रांसपोर्ट, ब्राउज़र स्क्रीनशॉट, VM स्थिति और PR साक्ष्य की आवश्यकता होती है। ## कमांड सतह प्रत्येक QA प्रवाह `pnpm openclaw qa ` के अंतर्गत चलता है। कई के पास `pnpm qa:*` स्क्रिप्ट उपनाम हैं; दोनों रूप काम करते हैं। | कमांड | उद्देश्य | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `qa run` | `--qa-profile` के बिना बंडल किया गया QA स्व-जाँच; `--qa-profile smoke-ci`, `--qa-profile release`, या `--qa-profile all` वाला टैक्सोनॉमी-समर्थित परिपक्वता प्रोफ़ाइल रनर। | | `qa suite` | QA Gateway लेन के विरुद्ध रिपॉज़िटरी-समर्थित परिदृश्य चलाएँ। `--runner multipass` होस्ट के बजाय एक अस्थायी Linux VM का उपयोग करता है। | | `qa coverage` | YAML परिदृश्य-कवरेज इन्वेंट्री प्रिंट करें (मशीन आउटपुट के लिए `--json`; प्रभावित व्यवहार के परिदृश्य खोजने के लिए `--match `; रनटाइम टूल फ़िक्सचर कवरेज के लिए `--tools`)। | | `qa parity-report` | मॉडल-अक्ष समानता गेट के लिए दो `qa-suite-summary.json` फ़ाइलों की तुलना करें, या Codex-बनाम-OpenClaw रनटाइम समानता और टोकन-दक्षता रिपोर्ट लिखने के लिए `--runtime-axis --token-efficiency` का उपयोग करें। | | `qa confidence-report` | शून्य-अज्ञात विश्वसनीयता रिपोर्ट में मेनिफ़ेस्ट के आधार पर QA प्रमाण एसेट का वर्गीकरण करें। | | `qa confidence-self-test` | सीड किए गए नकारात्मक-नियंत्रण कैनरी लिखें, जो सिद्ध करें कि विश्वसनीयता गेट विचलन का पता लगाता है। | | `qa jsonl-replay` | रनटाइम समानता रीप्ले हार्नेस के माध्यम से क्यूरेट किए गए JSONL ट्रांसक्रिप्ट पुनः चलाएँ। | | `qa character-eval` | मूल्यांकित रिपोर्ट के साथ कई लाइव मॉडल पर कैरेक्टर QA परिदृश्य चलाएँ। [रिपोर्टिंग](#reporting) देखें। | | `qa manual` | चुने गए प्रदाता/मॉडल लेन के विरुद्ध एकबारगी प्रॉम्प्ट चलाएँ। | | `qa ui` | QA डीबगर UI और स्थानीय QA बस शुरू करें (उपनाम: `pnpm qa:lab:ui`)। | | `qa docker-build-image` | पहले से तैयार QA Docker इमेज बनाएँ। | | `qa docker-scaffold` | QA डैशबोर्ड + Gateway लेन के लिए docker-compose स्कैफ़ोल्ड लिखें। | | `qa up` | QA साइट बनाएँ, Docker-समर्थित स्टैक शुरू करें और URL प्रिंट करें (उपनाम: `pnpm qa:lab:up`; `:fast` प्रकार `--use-prebuilt-image --bind-ui-dist --skip-ui-build` जोड़ता है)। | | `qa aimock` | केवल AIMock प्रदाता सर्वर शुरू करें। | | `qa mock-openai` | केवल परिदृश्य-सचेत `mock-openai` प्रदाता सर्वर शुरू करें। | | `qa credentials doctor` / `add` / `list` / `remove` | साझा Convex क्रेडेंशियल पूल प्रबंधित करें। | | `qa discord` | वास्तविक निजी Discord गिल्ड चैनल के विरुद्ध लाइव ट्रांसपोर्ट लेन। | | `qa matrix` | अस्थायी Tuwunel होमसर्वर के विरुद्ध QA Lab Matrix प्रोफ़ाइल। [Matrix स्मोक लेन](#matrix-smoke-lanes) देखें। | | `qa slack` | वास्तविक निजी Slack चैनल के विरुद्ध लाइव ट्रांसपोर्ट लेन। | | `qa telegram` | वास्तविक निजी Telegram समूह के विरुद्ध लाइव ट्रांसपोर्ट लेन। | | `qa whatsapp` | वास्तविक WhatsApp Web खातों के विरुद्ध लाइव ट्रांसपोर्ट लेन। | | `qa mantis` | Discord स्थिति-प्रतिक्रिया साक्ष्य, Crabbox डेस्कटॉप/ब्राउज़र स्मोक और Slack-इन-VNC स्मोक के साथ लाइव ट्रांसपोर्ट बग के लिए पहले/बाद का सत्यापन रनर। [Mantis](/hi/concepts/mantis) और [Mantis Slack डेस्कटॉप रनबुक](/hi/concepts/mantis-slack-desktop-runbook) देखें। | ### प्रोफ़ाइल-समर्थित `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` पूर्ण प्रविष्टियाँ पुनर्स्थापित करता है: ```bash 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 कमांड से पहले रखें: ```bash pnpm openclaw --profile work qa run --qa-profile smoke-ci ``` ## ऑपरेटर प्रवाह वर्तमान QA ऑपरेटर प्रवाह दो-पेन वाली QA साइट है: - बायाँ: एजेंट वाला Gateway डैशबोर्ड (Control UI)। - दायाँ: QA Lab, जो Slack-जैसा ट्रांसक्रिप्ट और परिदृश्य योजना दिखाता है। इसे इससे चलाएँ: ```bash pnpm qa:lab:up ``` यह QA साइट बनाता है, Docker-समर्थित Gateway लेन शुरू करता है और QA Lab पेज उपलब्ध कराता है, जहाँ कोई ऑपरेटर या ऑटोमेशन लूप एजेंट को QA मिशन दे सकता है, वास्तविक चैनल व्यवहार देख सकता है और यह दर्ज कर सकता है कि क्या सफल हुआ, विफल हुआ या अवरुद्ध रहा। हर बार Docker इमेज दोबारा बनाए बिना तेज़ QA Lab UI पुनरावृत्ति के लिए, बाइंड-माउंट किए गए QA Lab बंडल के साथ स्टैक शुरू करें: ```bash pnpm openclaw qa docker-build-image pnpm qa:lab:build pnpm qa:lab:up:fast pnpm qa:lab:watch ``` `qa:lab:up:fast` Docker सेवाओं को पहले से बनी इमेज पर रखता है और `extensions/qa-lab/web/dist` को `qa-lab` कंटेनर में बाइंड-माउंट करता है। `qa:lab:watch` बदलाव होने पर उस बंडल को दोबारा बनाता है और QA Lab एसेट हैश बदलने पर ब्राउज़र स्वतः पुनः लोड होता है। ### प्रेक्षणीयता स्मोक प्रेक्षणीयता QA केवल स्रोत चेकआउट तक सीमित रहता है। npm tarball जानबूझकर QA Lab (और `qa-channel`) को शामिल नहीं करता, इसलिए पैकेज Docker रिलीज़ लेन `qa` कमांड नहीं चलाते। डायग्नोस्टिक्स इंस्ट्रूमेंटेशन बदलते समय इन्हें बनाए गए स्रोत चेकआउट से चलाएँ। | उपनाम | यह क्या चलाता है | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | `pnpm qa:otel:smoke` | स्थानीय OpenTelemetry रिसीवर तथा `diagnostics-otel` सक्षम वाला `otel-trace-smoke` परिदृश्य। | | `pnpm qa:otel:collector-smoke` | वास्तविक OpenTelemetry Collector Docker कंटेनर के पीछे वही लेन। एंडपॉइंट वायरिंग या collector/OTLP संगतता बदलते समय इसका उपयोग करें। | | `pnpm qa:prometheus:smoke` | `diagnostics-prometheus` सक्षम वाला `docker-prometheus-smoke` परिदृश्य। | | `pnpm qa:observability:smoke` | `qa:otel:smoke`, जिसके बाद `qa:prometheus:smoke` चलता है। | | `pnpm qa:observability:collector-smoke` | `qa:otel:collector-smoke`, जिसके बाद `qa:prometheus:smoke` चलता है। | `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 प्रदाता के साथ रिलीज़ प्रोफ़ाइल चलाएँ: ```bash pnpm openclaw qa matrix --provider-mode mock-openai --profile release ``` लाइव-फ्रंटियर प्रदाता लेन के लिए, OpenAI-संगत क्रेडेंशियल स्पष्ट रूप से दें: ```bash 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 ` दोहराएँ; स्पष्ट परिदृश्य आईडी को `--profile` पर वरीयता मिलती है। | प्रोफ़ाइल | परिदृश्य | उद्देश्य | | ------------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `all` | 93 | पूर्ण कैटलॉग (डिफ़ॉल्ट)। | | `release` | 2 | रिलीज़-महत्वपूर्ण चैनल बेसलाइन और लाइव अनुमति-सूची पुनः लोड करना। | | `fast` | 12 | थ्रेडिंग, प्रतिक्रियाओं, अनुमोदनों, नीति, बॉट-गेटिंग और एन्क्रिप्टेड-उत्तर का केंद्रित कवरेज। | | `transport` | 50 | थ्रेडिंग, DM/रूम रूटिंग, स्वतः शामिल होना, अनुमोदन, प्रतिक्रियाएँ, पुनः आरंभ, उल्लेख/अनुमति-सूची नीति, संपादन और बहु-अभिनेता क्रम। | | `media` | 7 | चित्र, जनरेट किया गया चित्र, वॉइस, अटैचमेंट, असमर्थित मीडिया और एन्क्रिप्टेड मीडिया कवरेज। | | `e2ee-smoke` | 8 | न्यूनतम एन्क्रिप्टेड उत्तर, थ्रेडिंग, बूटस्ट्रैप, पुनर्प्राप्ति, पुनः आरंभ, संपादन और विफलता कवरेज। | | `e2ee-deep` | 18 | स्थिति हानि, बैकअप, कुंजी पुनर्प्राप्ति, डिवाइस स्वच्छता और SAS/QR/DM सत्यापन। | | `e2ee-cli` | 9 | हार्नेस के माध्यम से `openclaw matrix encryption setup`, पुनर्प्राप्ति-कुंजी, बहु-अकाउंट, Gateway राउंड-ट्रिप और स्व-सत्यापन कमांड। | प्रोफ़ाइल सदस्यता और चैनल आवश्यकताएँ `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` नहीं) और परिवेश को समाप्त कर देता है। सामान्य विकल्प: | फ़्लैग | डिफ़ॉल्ट | उद्देश्य | | ------------------------ | ----------------- | ------------------------------------------------------------------------------------ | | `--profile ` | `all` | ऊपर दिए गए प्रोफ़ाइलों में से एक चुनें। | | `--scenario ` | - | एक परिदृश्य चुनें; दोहराया जा सकता है। | | `--fail-fast` | बंद | पहली विफल जाँच या परिदृश्य के बाद रुकें। | | `--allow-failures` | बंद | परिदृश्य विफलताओं के लिए विफलता निकास कोड लौटाए बिना आर्टिफ़ैक्ट लिखें। | | `--provider-mode ` | `live-frontier` | नियतात्मक डिस्पैच के लिए `mock-openai` या लाइव प्रदाता के लिए `live-frontier` का उपयोग करें। | | `--model ` | प्रदाता डिफ़ॉल्ट | प्राथमिक `provider/model` संदर्भ सेट करें। | | `--alt-model ` | प्रदाता डिफ़ॉल्ट | मॉडल बदलने वाले परिदृश्यों द्वारा उपयोग किया जाने वाला वैकल्पिक मॉडल सेट करें। | | `--fast` | बंद | समर्थित होने पर प्रदाता तेज़ मोड सक्षम करें। | | `--output-dir ` | जनरेट किया गया | रिपोर्ट डायरेक्टरी चुनें; सापेक्ष पथ `--repo-root` के सापेक्ष हल होते हैं। | | `--repo-root ` | वर्तमान डायरेक्टरी | किसी तटस्थ कार्यशील डायरेक्टरी से चलाएँ। | | `--sut-account ` | `sut` | चाइल्ड Gateway कॉन्फ़िगरेशन में Matrix अकाउंट आईडी चुनें। | 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 ऑरेकल से आता है। अन्य ट्रांसपोर्ट-वास्तविक स्मोक लेन के लिए: ```bash pnpm openclaw qa discord pnpm openclaw qa slack pnpm openclaw qa telegram pnpm openclaw qa whatsapp ``` वे दो बॉट या अकाउंट (ड्राइवर + SUT) वाले पहले से मौजूद वास्तविक चैनल को लक्षित करते हैं। उन चार ट्रांसपोर्ट के लिए आवश्यक एनवायरनमेंट वैरिएबल, परिदृश्य सूचियाँ, आउटपुट आर्टिफ़ैक्ट और Convex क्रेडेंशियल पूल नीचे [Discord, Slack, Telegram और WhatsApp QA संदर्भ](#discord-slack-telegram-and-whatsapp-qa-reference) में प्रलेखित हैं। ### Mantis Slack डेस्कटॉप और दृश्य-कार्य रनर VNC बचाव सहित पूर्ण Slack डेस्कटॉप VM रन के लिए, चलाएँ: ```bash 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 ` का पुनः उपयोग करें; पुनः उपयोग की गई लीज़ 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 अनुमोदन चेकपॉइंट मोड चलाएँ: ```bash pnpm openclaw qa mantis slack-desktop-smoke \ --approval-checkpoints \ --credential-source convex \ --credential-role maintainer ``` यह मोड `--gateway-setup` के साथ परस्पर अनन्य है। यह Slack अनुमोदन परिदृश्य चलाता है, गैर-अनुमोदन परिदृश्य आईडी अस्वीकार करता है, प्रत्येक लंबित और समाधान किए गए अनुमोदन की स्थिति पर प्रतीक्षा करता है, देखे गए Slack API संदेश को `approval-checkpoints/-pending.png` और `approval-checkpoints/-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 डेस्कटॉप रनबुक](/hi/concepts/mantis-slack-desktop-runbook) में उपलब्ध हैं। एजेंट/CV शैली के डेस्कटॉप कार्य के लिए, चलाएँ: ```bash 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` सेट न हो। ### क्रेडेंशियल पूल स्वास्थ्य जाँच पूल किए गए लाइव क्रेडेंशियल का उपयोग करने से पहले, चलाएँ: ```bash 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 लेन के लिए, चलाएँ: ```bash 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 `, या क्रमिक निष्पादन के लिए `--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` के माध्यम से पंजीकृत होती हैं और समान फ़्लैग स्वीकार करती हैं: | फ़्लैग | डिफ़ॉल्ट | विवरण | | ------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `--scenario ` | - | केवल यह परिदृश्य चलाएँ। दोहराया जा सकता है। | | `--output-dir ` | `/.artifacts/qa-e2e/-` | जहाँ रिपोर्ट, सारांश, साक्ष्य, ट्रांसपोर्ट-विशिष्ट आर्टिफ़ैक्ट और आउटपुट लॉग लिखे जाते हैं। सापेक्ष पथ `--repo-root` के सापेक्ष रिज़ॉल्व होते हैं। | | `--repo-root ` | `process.cwd()` | न्यूट्रल cwd से आह्वान करते समय रिपॉज़िटरी रूट। | | `--sut-account ` | `sut` | QA Gateway कॉन्फ़िग के भीतर अस्थायी खाता आईडी। | | `--provider-mode ` | `live-frontier` | `mock-openai`, `aimock` या `live-frontier`। | | `--model ` / `--alt-model ` | प्रदाता डिफ़ॉल्ट | प्राथमिक/वैकल्पिक मॉडल रेफ़। | | `--fast` | बंद | समर्थित होने पर प्रदाता फ़ास्ट मोड। | | `--credential-source ` | `env` | [Convex क्रेडेंशियल पूल](#convex-credential-pool) देखें। | | `--credential-role ` | CI में `ci`, अन्यथा `maintainer` | `--credential-source convex` होने पर उपयोग की जाने वाली भूमिका। | | `--allow-failures` | बंद | परिदृश्यों के विफल होने पर विफल निकास कोड लौटाए बिना आर्टिफ़ैक्ट लिखें। | किसी भी विफल परिदृश्य पर प्रत्येक लेन गैर-शून्य स्थिति के साथ बाहर निकलती है। `--allow-failures` विफल निकास कोड सेट किए बिना आर्टिफ़ैक्ट लिखता है। Telegram उपलब्ध परिदृश्य आईडी प्रिंट करके बाहर निकलने के लिए `--list-scenarios` भी स्वीकार करता है; अन्य लेन वह फ़्लैग उपलब्ध नहीं करातीं। ### Telegram QA ```bash 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` में समाहित किया जाता है। ```bash 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 ```bash 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-mantis-scenarios)। Discord वॉइस ऑटो-जॉइन परिदृश्य स्पष्ट रूप से चलाएँ: ```bash pnpm openclaw qa discord \ --scenario discord-voice-autojoin \ --provider-mode mock-openai ``` Mantis स्थिति-प्रतिक्रिया परिदृश्य स्पष्ट रूप से चलाएँ: ```bash 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 ```bash 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 के लिए विज़ुअल अनुमोदन चेकपॉइंट सक्षम करता है। अडैप्टर `.pending.json` और `.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 चैनल त्वरित सेटअप](/hi/channels/slack#quick-setup) देखें; QA Driver/SUT जोड़ी जानबूझकर अलग रखी गई है, क्योंकि लेन को एक कार्यस्थान में दो अलग-अलग बॉट उपयोगकर्ता आईडी चाहिए। **1. Driver ऐप बनाएँ** [api.slack.com/apps](https://api.slack.com/apps) पर जाएँ → _Create New App_ → _From a manifest_ → QA कार्यस्थान चुनें, निम्न मैनिफ़ेस्ट चिपकाएँ, फिर _Install to Workspace_ चुनें: ```json { "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 सुइट अभी प्रतिक्रिया प्रबंधन को कवर नहीं करता। ```json { "display_information": { "name": "OpenClaw QA SUT", "description": "OpenClaw QA SUT connector for OpenClaw" }, "features": { "bot_user": { "display_name": "OpenClaw QA SUT", "always_online": true }, "app_home": { "home_tab_enabled": true, "messages_tab_enabled": true, "messages_tab_read_only_enabled": false } }, "oauth_config": { "scopes": { "bot": [ "app_mentions:read", "assistant:write", "channels:history", "channels:read", "chat:write", "commands", "emoji:read", "files:read", "files:write", "groups:history", "groups:read", "im:history", "im:read", "im:write", "mpim:history", "mpim:read", "mpim:write", "pins:read", "pins:write", "usergroups:read", "users:read" ] } }, "settings": { "socket_mode_enabled": true, "event_subscriptions": { "bot_events": [ "app_home_opened", "app_mention", "channel_rename", "member_joined_channel", "member_left_channel", "message.channels", "message.groups", "message.im", "message.mpim", "pin_added", "pin_removed" ] } } } ``` Slack द्वारा ऐप बनाए जाने के बाद, उसके सेटिंग पृष्ठ पर दो कार्य करें: - _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`) और चैनल के भीतर से दोनों बॉट को आमंत्रित करें: ```text /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 फ़ाइल में लिखें: ```json { "channelId": "Cxxxxxxxxxx", "driverBotToken": "xoxb-...", "sutBotToken": "xoxb-...", "sutAppToken": "xapp-..." } ``` अपने शेल में `OPENCLAW_QA_CONVEX_SITE_URL` और `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` एक्सपोर्ट करके, पंजीकरण और सत्यापन करें: ```bash pnpm openclaw qa credentials add \ --kind slack \ --payload-file slack-creds.json \ --note "QA Slack pool seed" pnpm openclaw qa credentials list --kind slack --status all --json ``` `count: 1`, `status: "active"` अपेक्षित हैं और कोई `lease` फ़ील्ड नहीं होना चाहिए। **5. शुरू से अंत तक सत्यापित करें** यह पुष्टि करने के लिए लेन को स्थानीय रूप से चलाएँ कि दोनों बॉट ब्रोकर के माध्यम से एक-दूसरे से संवाद कर सकते हैं: ```bash 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 ```bash 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 कार्यक्षेत्र सेट अप करना](#setting-up-the-slack-workspace) देखें। परिचालन env vars और Convex ब्रोकर एंडपॉइंट अनुबंध [परीक्षण → Convex के माध्यम से साझा Telegram क्रेडेंशियल](/hi/help/testing#shared-telegram-credentials-via-convex-v1) में दिए गए हैं (अनुभाग का नाम बहु-चैनल पूल से पहले का है; लीज़ शब्दार्थ सभी प्रकारों में साझा हैं)। ## रेपो-समर्थित सीड सीड एसेट `qa/` में रहते हैं: - `qa/scenarios/index.yaml` - `qa/scenarios//*.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 ` को कैसे माउंट किया जाता है - उस ट्रांसपोर्ट के लिए Gateway को कैसे कॉन्फ़िगर किया जाता है - तत्परता की जाँच कैसे की जाती है - इनबाउंड इवेंट कैसे अंतःक्षेपित किए जाते हैं - आउटबाउंड संदेशों का अवलोकन कैसे किया जाता है - ट्रांसक्रिप्ट और सामान्यीकृत ट्रांसपोर्ट स्थिति कैसे उपलब्ध कराई जाती है - ट्रांसपोर्ट-समर्थित क्रियाएँ कैसे निष्पादित की जाती हैं - ट्रांसपोर्ट-विशिष्ट रीसेट या क्लीनअप कैसे संभाला जाता है नए चैनल के लिए न्यूनतम अपनाने का मानदंड: 1. साझा `qa` रूट के स्वामी के रूप में `qa-lab` को बनाए रखें। 2. साझा `qa-lab` होस्ट सीम पर ट्रांसपोर्ट रनर लागू करें। 3. ट्रांसपोर्ट-विशिष्ट तंत्र को रनर Plugin या चैनल हार्नेस के अंदर रखें। 4. प्रतिस्पर्धी रूट कमांड पंजीकृत करने के बजाय रनर को `openclaw qa ` के रूप में माउंट करें। रनर 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 ` चलाएँ। मिलान रिपोर्ट परिदृश्य मेटाडेटा, दस्तावेज़ संदर्भ, कोड संदर्भ, कवरेज 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 या रिलीज़ लेन की आवश्यकता होती है। स्कोरकार्ड संदर्भ के लिए, [परिपक्वता स्कोरकार्ड](/hi/maturity/scorecard) देखें। चरित्र और शैली जाँच के लिए, एक ही परिदृश्य को कई लाइव मॉडल संदर्भों में चलाएँ और निर्णयित Markdown रिपोर्ट लिखें: ```bash 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=` से ओवरराइड करें; इनलाइन विकल्प `fast`, `no-fast` और `fast=` का भी समर्थन करते हैं। `--thinking ` अब भी वैश्विक फ़ॉलबैक सेट करता है, और पुराना `--model-thinking ` रूप संगतता के लिए रखा गया है। 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` होते हैं। ## संबंधित दस्तावेज़ - [परिपक्वता स्कोरकार्ड](/hi/maturity/scorecard) - [व्यक्तिगत एजेंट बेंचमार्क पैक](/hi/concepts/personal-agent-benchmark-pack) - [QA चैनल](/hi/channels/qa-channel) - [परीक्षण](/hi/help/testing) - [डैशबोर्ड](/hi/web/dashboard)