ภาพรวม QA

สแตก QA ส่วนตัวทดสอบ OpenClaw ในรูปแบบที่สมจริงและมีโครงสร้างเหมือนช่องทาง ซึ่ง การทดสอบหน่วยไม่สามารถทำได้

องค์ประกอบ:

• extensions/qa-channel: ช่องทางข้อความจำลองที่มีพื้นผิวสำหรับ DM, ช่องทาง, เธรด, รีแอ็กชัน, การแก้ไข และการลบ
• extensions/qa-lab: UI ดีบักเกอร์, บัส QA, โปรไฟล์สถานการณ์ และอะแดปเตอร์ การขนส่งแบบไลฟ์สำหรับสังเกตทรานสคริปต์ แทรกข้อความขาเข้า และส่งออกรายงาน Markdown
• 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

ใช้ smoke-ci สำหรับหลักฐานโปรไฟล์แบบกำหนดผลลัพธ์ได้ด้วยผู้ให้บริการโมเดลจำลองและ เซิร์ฟเวอร์ผู้ให้บริการภายในเครื่อง Crabline ใช้ release สำหรับหลักฐาน Stable/LTS กับ ช่องทางแบบไลฟ์ ใช้ all เฉพาะสำหรับการรันหลักฐานเต็มอนุกรมวิธานอย่างชัดเจนเท่านั้น; คำสั่งนี้จะเลือกทุกหมวดหมู่วุฒิภาวะที่ใช้งานอยู่ และสามารถส่งผ่านเวิร์กโฟลว์ GitHub Actions QA Profile Evidence ด้วย qa_profile=all เมื่อคำสั่ง ต้องใช้โปรไฟล์รากของ OpenClaw ด้วย ให้วางโปรไฟล์รากไว้ก่อนคำสั่ง QA:

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

โฟลว์ผู้ปฏิบัติงาน

โฟลว์ผู้ปฏิบัติงาน QA ปัจจุบันเป็นไซต์ QA แบบสองบานหน้าต่าง:

• ซ้าย: แดชบอร์ด Gateway (Control UI) พร้อมเอเจนต์
• ขวา: QA Lab ซึ่งแสดงทรานสคริปต์แบบ Slack และแผนสถานการณ์

เรียกใช้ด้วย:

pnpm qa:lab:up

คำสั่งนี้จะสร้างไซต์ QA เริ่มเลน Gateway ที่อิง Docker และเปิดให้เข้าถึง หน้า QA Lab ซึ่งผู้ปฏิบัติงานหรือลูปอัตโนมัติสามารถมอบภารกิจ QA ให้เอเจนต์ สังเกตพฤติกรรมของช่องทางจริง และบันทึกว่าสิ่งใดทำงาน ล้มเหลว หรือ ยังคงถูกบล็อก

หากต้องการวนปรับ UI ของ QA Lab ให้เร็วขึ้นโดยไม่ต้องสร้างอิมเมจ Docker ใหม่ทุกครั้ง ให้เริ่มสแตกด้วยบันเดิล QA Lab ที่เมานต์แบบ bind:

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 แบบ bind เข้าในคอนเทนเนอร์ 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 ครบทั้งหมด การทดสอบ smoke บังคับใช้ OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental ดังนั้นช่วงการเรียกโมเดล ต้องใช้ชื่อ {gen_ai.operation.name} {gen_ai.request.model}; การเรียกโมเดล ต้องไม่ส่งออก StreamAbandoned เมื่อรอบการทำงานสำเร็จ; รหัสการวินิจฉัยดิบ และแอตทริบิวต์ openclaw.content.* ต้องไม่ปรากฏในเทรซ พรอมต์ของสถานการณ์ ขอให้โมเดลตอบกลับด้วยเครื่องหมายคงที่และไม่เปิดเผยสตริงข้อมูลลับคงที่; เพย์โหลด OTLP ดิบต้องไม่มีทั้งสองรายการดังกล่าวหรือคีย์เซสชัน QA ที่ได้จากรหัสสถานการณ์ โดยจะเขียน otel-smoke-summary.json ไว้ข้างอาร์ติแฟกต์ของชุด QA

qa:prometheus:smoke ตรวจสอบว่าการดึงข้อมูลโดยไม่ยืนยันตัวตนถูกปฏิเสธ จากนั้น ตรวจสอบว่าการดึงข้อมูลที่ยืนยันตัวตนแล้วมีตระกูลเมตริกที่สำคัญต่อการเผยแพร่ โดยไม่มีเนื้อหาพรอมต์ เนื้อหาคำตอบ ตัวระบุการวินิจฉัยดิบ โทเค็นยืนยันตัวตน หรือพาธภายในเครื่อง

เลนทดสอบ smoke ของ Matrix

สำหรับเลนทดสอบ smoke ของ Matrix ที่ใช้การรับส่งจริงและไม่ต้องใช้ ข้อมูลประจำตัวของผู้ให้บริการโมเดล ให้เรียกใช้โปรไฟล์การเผยแพร่กับผู้ให้บริการ OpenAI จำลองแบบกำหนดผลลัพธ์ได้:

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

สำหรับเลนผู้ให้บริการ live-frontier ให้ระบุข้อมูลประจำตัวที่เข้ากันได้กับ 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

การเป็นสมาชิกโปรไฟล์และข้อกำหนดของช่องทางอยู่กับสถานการณ์ Matrix แบบประกาศภายใต้ qa/scenarios/channels/ การเรียกใช้จะเลือกไดรเวอร์ช่องทาง ส่วนการใช้งานจริงอยู่ภายใต้ extensions/qa-lab/src/live-transports/matrix/scenarios/

อะแดปเตอร์จัดเตรียมโฮมเซิร์ฟเวอร์ Tuwunel แบบใช้แล้วทิ้งใน Docker (อิมเมจเริ่มต้น ghcr.io/matrix-construct/tuwunel:v1.5.1, ชื่อเซิร์ฟเวอร์ matrix-qa.test, พอร์ต 28008) ลงทะเบียนผู้ใช้ชั่วคราวสำหรับไดรเวอร์ SUT และผู้สังเกตการณ์ เตรียมห้องที่จำเป็น และบันทึกขอบเขตคำขอ/คำตอบที่ปกปิดข้อมูลแล้ว จากนั้น เรียกใช้ Plugin Matrix จริงภายใน Gateway QA ลูกที่จำกัดขอบเขตไว้เฉพาะการรับส่งนั้น (ไม่มี qa-channel) และรื้อถอนสภาพแวดล้อม

ตัวเลือกทั่วไป:

QA ของ Matrix ไม่เช่าข้อมูลประจำตัว 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 การจัดการรีแอ็กชัน การระงับการแก้ไขขาเข้า การขจัดรายการซ้ำในการเล่นซ้ำหลังเริ่มใหม่ การกู้คืนจากการหยุดชะงักของโฮมเซิร์ฟเวอร์ การส่งข้อมูลเมตาของการอนุมัติ การจัดการสื่อ และโฟลว์การเริ่มต้นระบบ/การกู้คืน/การยืนยัน E2EE ของ Matrix โปรไฟล์ CLI สำหรับ E2EE ยังดำเนินการ openclaw matrix encryption setup และ คำสั่งยืนยันผ่านโฮมเซิร์ฟเวอร์แบบใช้แล้วทิ้งเดียวกันก่อนตรวจสอบ คำตอบของ Gateway

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 ในงานเดียว

สถานการณ์ Mantis สำหรับ Discord

Discord ยังมีสถานการณ์เฉพาะ Mantis แบบเลือกใช้สำหรับจำลองบั๊ก ใช้ --scenario discord-status-reactions-tool-only สำหรับไทม์ไลน์รีแอ็กชันสถานะ ที่ระบุชัดเจน หรือ --scenario discord-thread-reply-filepath-attachment เพื่อสร้างเธรด Discord จริงและตรวจสอบว่า message.thread-reply คงไฟล์แนบ filePath ไว้ สถานการณ์เหล่านี้ไม่รวมอยู่ในเลน Discord แบบสดเริ่มต้น เนื่องจากเป็นโพรบจำลองก่อน/หลังแทนที่จะเป็นความครอบคลุม smoke แบบกว้าง เวิร์กโฟลว์ Mantis สำหรับไฟล์แนบในเธรดยังสามารถเพิ่มวิดีโอพยานจาก Discord Web ที่เข้าสู่ระบบแล้ว เมื่อกำหนดค่า MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR หรือ MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64 ในสภาพแวดล้อม QA โปรไฟล์ผู้ดูนั้นมีไว้สำหรับการบันทึกภาพเท่านั้น; การตัดสินผ่าน/ไม่ผ่าน ยังคงมาจากออราเคิล REST ของ Discord

สำหรับเลนทดสอบ smoke อื่นที่ใช้การรับส่งจริง:

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

เลนเหล่านี้มุ่งเป้าไปยังช่องทางจริงที่มีอยู่แล้วซึ่งใช้บอตหรือบัญชีสองรายการ (ไดรเวอร์ + SUT) ตัวแปรสภาพแวดล้อมที่จำเป็น รายการสถานการณ์ อาร์ติแฟกต์เอาต์พุต และพูลข้อมูลประจำตัว Convex สำหรับการรับส่งทั้งสี่ประเภทมีเอกสารอยู่ใน ข้อมูลอ้างอิง QA สำหรับ Discord, Slack, Telegram และ WhatsApp ด้านล่าง

รันเนอร์เดสก์ท็อป Slack และงานภาพของ Mantis

สำหรับการเรียกใช้ VM เดสก์ท็อป Slack แบบเต็มพร้อม VNC สำหรับกู้คืน ให้เรียกใช้:

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

คำสั่งนั้นจะเช่าเครื่องเดสก์ท็อป/เบราว์เซอร์ Crabbox เรียกใช้เลน Slack แบบสด ภายใน VM เปิด Slack Web ในเบราว์เซอร์ VNC จับภาพเดสก์ท็อป และคัดลอก slack-qa/, slack-desktop-smoke.png และ slack-desktop-smoke.mp4 (เมื่อสามารถบันทึกวิดีโอได้) กลับไปยัง ไดเรกทอรีอาร์ติแฟกต์ของ Mantis การเช่าเดสก์ท็อป/เบราว์เซอร์ Crabbox จะจัดเตรียมเครื่องมือ จับภาพและแพ็กเกจตัวช่วยสำหรับเบราว์เซอร์/การบิลด์แบบเนทีฟไว้ล่วงหน้า ดังนั้นสถานการณ์นี้ ควรติดตั้งเฉพาะตัวสำรองบนการเช่ารุ่นเก่า Mantis รายงานระยะเวลารวมและ ระยะเวลาของแต่ละเฟสใน mantis-slack-desktop-smoke-report.md เพื่อให้การรันที่ช้าแสดงว่า เวลาเสียไปกับการเตรียมการเช่า การรับข้อมูลรับรอง การตั้งค่าระยะไกล หรือ การคัดลอกอาร์ติแฟกต์ ใช้ --lease-id <cbx_...> ซ้ำหลังจากเข้าสู่ระบบ Slack Web ด้วยตนเองผ่าน VNC แล้ว การเช่าที่นำกลับมาใช้ซ้ำยังคงทำให้แคช pnpm store ของ Crabbox พร้อมใช้งานอยู่เสมอ ค่าเริ่มต้น --hydrate-mode source จะตรวจสอบจากซอร์สเช็กเอาต์และ เรียกใช้การติดตั้ง/บิลด์ภายใน VM ใช้ --hydrate-mode prehydrated เฉพาะเมื่อ เวิร์กสเปซระยะไกลที่นำกลับมาใช้ซ้ำมี node_modules และ dist/ ที่บิลด์แล้ว โหมดนั้นจะข้ามขั้นตอนติดตั้ง/บิลด์ที่ใช้ทรัพยากรมากและหยุดอย่างปลอดภัยเมื่อ เวิร์กสเปซยังไม่พร้อม เมื่อใช้ --gateway-setup Mantis จะปล่อยให้ Gateway Slack ของ OpenClaw แบบถาวรทำงานอยู่ภายใน VM บนพอร์ต 38973 หากไม่ใช้ คำสั่งจะเรียกใช้เลน QA Slack แบบบอตถึงบอตตามปกติและออกหลังจาก จับภาพอาร์ติแฟกต์แล้ว

หากต้องการพิสูจน์ UI การอนุมัติแบบเนทีฟของ Slack ด้วยหลักฐานจากเดสก์ท็อป ให้เรียกใช้โหมด จุดตรวจการอนุมัติของ 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 ใน slack-desktop-smoke.png ภาพจุดตรวจการอนุมัติคือหลักฐาน เชิงภาพสำหรับเลนนี้

การรันจุดตรวจเริ่มต้นจะคงสถานการณ์การอนุมัติ Slack มาตรฐานสองรายการไว้ หากต้องการจับภาพเส้นทางการอนุมัติ Codex แบบเลือกรับรายการใดรายการหนึ่ง ให้เลือกอย่างชัดเจนด้วย --scenario slack-codex-approval-exec-native หรือ --scenario slack-codex-approval-plugin-native Mantis รองรับทั้งสองรายการและสร้าง คู่ภาพหน้าจอสถานะรอดำเนินการ/แก้ไขแล้วแบบเดียวกัน ตัวรันจะขยายกำหนดเวลา ของจุดตรวจและคำสั่งระยะไกลสำหรับแต่ละเส้นทาง Codex ที่เลือก เพื่อให้ลำดับทั้งหมด ของการอนุมัติ การทำงานของเอเจนต์จนเสร็จสิ้น และการอัปเดตสถานะที่แก้ไขแล้วดำเนินการได้สำเร็จ

รายการตรวจสอบสำหรับผู้ปฏิบัติงาน คำสั่งส่งเวิร์กโฟลว์ GitHub สัญญาสำหรับความคิดเห็น หลักฐาน ตารางตัดสินใจโหมด hydrate การตีความระยะเวลา และขั้นตอน จัดการความล้มเหลวอยู่ใน คู่มือการรัน Mantis Slack Desktop

สำหรับงานเดสก์ท็อปในรูปแบบเอเจนต์/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 เรียกใช้ openclaw infer image describe กับภาพหน้าจอเมื่อเลือก --vision-mode 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

คำสั่ง doctor จะตรวจสอบสภาพแวดล้อมของโบรกเกอร์ Convex (OPENCLAW_QA_CONVEX_SITE_URL, OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX) ตรวจสอบการตั้งค่าปลายทาง รายงาน เฉพาะสถานะตั้งค่าแล้ว/ขาดหายสำหรับ OPENCLAW_QA_CONVEX_SECRET_CI และ OPENCLAW_QA_CONVEX_SECRET_MAINTAINER และตรวจสอบว่าสามารถเข้าถึงการดูแลระบบ/รายการได้ เมื่อมีซีเคร็ตของผู้ดูแล

ความครอบคลุมของสถานการณ์มาตรฐาน

ไฟล์ราก taxonomy.yaml กำหนดรหัสความครอบคลุมเชิงความหมาย ไฟล์ YAML ของสถานการณ์ ภายใต้ qa/scenarios/ จะแมปแต่ละสถานการณ์กับรหัสเหล่านั้นและเป็นเจ้าของข้อมูลเมตา การดำเนินการ โดย channel เป็นข้อกำหนดของช่องทางเพียงรายการเดียว และ profiles ประกาศ การเป็นสมาชิกของการรันที่มีชื่อ ไดรเวอร์ช่องทางเป็นตัวเลือกการใช้งานระดับการรัน ที่สับเปลี่ยนได้ ตัวรัน TypeScript จะค้นหาแค็ตตาล็อกดังกล่าว โดยไม่ดูแลคลังสถานการณ์หรือความครอบคลุม คู่ขนาน

เอาต์พุตแบบคงที่ของ qa coverage จะรายงานการแมปอนุกรมวิธานกับสถานการณ์ หลักฐาน จริงมาจาก qa-evidence.json ซึ่งบันทึกสถานการณ์ที่ดำเนินการ รหัสความครอบคลุม ช่องทาง ไดรเวอร์ที่ใช้จริง และผลลัพธ์ ช่องทางและไดรเวอร์เป็น มิติของรายงาน ไม่ใช่ชุดคำศัพท์รหัสความครอบคลุมเพิ่มเติมหรือแกน คุณสมบัติของสถานการณ์

สำหรับเลน VM Linux แบบใช้แล้วทิ้งโดยไม่ต้องนำ Docker เข้ามาในเส้นทาง QA ให้เรียกใช้:

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 สำหรับการดำเนินการแบบลำดับ ใช้ --pack personal-agent เพื่อเรียกใช้แพ็กเบนช์มาร์กผู้ช่วยส่วนบุคคล (10 สถานการณ์) ตัวเลือกแพ็กสามารถใช้ร่วมกับแฟล็ก --scenario ที่ระบุซ้ำได้: สถานการณ์ที่ระบุชัดเจนจะทำงานก่อน จากนั้นสถานการณ์ในแพ็กจะทำงานตามลำดับของแพ็กโดย ลบรายการซ้ำออก ใช้ --pack observability เพื่อเลือกสถานการณ์ otel-trace-smoke และ docker-prometheus-smoke พร้อมกัน เมื่อ ตัวรัน QA แบบกำหนดเองจัดเตรียมการตั้งค่าตัวรวบรวม OpenTelemetry ไว้แล้ว

คำสั่งจะออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อสถานการณ์ใดล้มเหลว ใช้ --allow-failures เมื่อต้องการอาร์ติแฟกต์โดยไม่ให้ออกด้วยรหัสความล้มเหลว

การรันแบบสดจะส่งต่ออินพุตการยืนยันตัวตน QA ที่รองรับและเหมาะสม สำหรับเกสต์ ได้แก่ คีย์ผู้ให้บริการจากสภาพแวดล้อม พาธการกำหนดค่าผู้ให้บริการ QA แบบสด และ CODEX_HOME เมื่อมีอยู่ เก็บ --output-dir ไว้ภายใต้รากของรีโพ เพื่อให้เกสต์เขียนกลับผ่านเวิร์กสเปซที่เมานต์ไว้ได้

ข้อมูลอ้างอิง QA สำหรับ Discord, Slack, Telegram และ WhatsApp

อะแดปเตอร์ Matrix ใช้เลนที่รองรับด้วย Docker แบบใช้แล้วทิ้งซึ่งอธิบายไว้ข้างต้น Discord, Slack, Telegram และ WhatsApp ทำงานกับ ระบบขนส่งจริงที่มีอยู่แล้ว ดังนั้นข้อมูลอ้างอิงจึงอยู่ที่นี่

แฟล็ก CLI ที่ใช้ร่วมกัน

เลนเหล่านี้ลงทะเบียนผ่าน extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts และ รองรับแฟล็กเดียวกัน:

แต่ละเลนจะออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อสถานการณ์ใดล้มเหลว --allow-failures จะเขียน อาร์ติแฟกต์โดยไม่ตั้งรหัสออกเป็นความล้มเหลว Telegram ยังรองรับ --list-scenarios เพื่อพิมพ์รหัสสถานการณ์ที่ใช้ได้และออก ส่วนเลนอื่น ไม่มีแฟล็กนี้

QA สำหรับ Telegram

pnpm openclaw qa telegram

กำหนดเป้าหมายไปยังกลุ่ม Telegram ส่วนตัวจริงหนึ่งกลุ่มที่มีบอตแยกกันสองตัว (ไดรเวอร์ + SUT) บอต SUT ต้องมีชื่อผู้ใช้ Telegram การสังเกตการณ์แบบบอตถึงบอตจะทำงาน ได้ดีที่สุดเมื่อบอตทั้งสองเปิดใช้งาน Bot-to-Bot Communication Mode ใน @BotFather

สภาพแวดล้อมที่จำเป็นเมื่อ --credential-source env:

• OPENCLAW_QA_TELEGRAM_GROUP_ID - รหัสแชตแบบตัวเลข (สตริง)
• OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN
• OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN

โปรไฟล์ release จะเลือกสถานการณ์ YAML ของ Telegram ที่ได้รับการดูแล ส่วน 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 ครอบคลุม canary, การควบคุมด้วยการกล่าวถึง, การตอบกลับคำสั่งแบบเนทีฟ, การระบุปลายทางคำสั่ง และการตอบกลับแบบกลุ่มระหว่างบอตเสมอ mock-openai ยังรวมการตรวจสอบตัวอย่างผลลัพธ์สุดท้ายแบบยาวที่กำหนดผลได้แน่นอนด้วย telegram-current-session-status-tool และ telegram-tool-only-usage-footer ยังคงเป็นแบบเลือกใช้: รายการแรกจะเสถียรเฉพาะ เมื่อรันต่อจาก canary โดยตรง ส่วนรายการหลังเป็นหลักฐานจาก Telegram จริง สำหรับส่วนท้าย /usage ในการตอบกลับที่มีเฉพาะเครื่องมือ ใช้ pnpm openclaw qa telegram --list-scenarios --provider-mode mock-openai เพื่อพิมพ์การแบ่ง ค่าเริ่มต้น/ตัวเลือกปัจจุบันพร้อมข้อมูลอ้างอิงการถดถอย ใช้ --profile all สำหรับทุก สถานการณ์ live adapter ของ Telegram

อาร์ติแฟกต์เอาต์พุต:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json - รายการหลักฐานสำหรับการตรวจสอบทรานสปอร์ตแบบสด รวมถึงฟิลด์โปรไฟล์, ความครอบคลุม, ผู้ให้บริการ, ช่องทาง, อาร์ติแฟกต์, ผลลัพธ์ และ RTT

การรัน Telegram ของแพ็กเกจใช้สัญญาข้อมูลประจำตัว Telegram เดียวกัน การวัด RTT ซ้ำเป็นส่วนหนึ่งของเลน Telegram แบบสดตามปกติของแพ็กเกจ โดยการกระจาย RTT จะถูกรวมไว้ใน qa-evidence.json ภายใต้ result.timing สำหรับ การตรวจสอบ RTT ที่เลือก

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

เมื่อตั้งค่า OPENCLAW_QA_CREDENTIAL_SOURCE=convex ตัวห่อหุ้มการรันแพ็กเกจแบบสด จะเช่าข้อมูลประจำตัว kind: "telegram", ส่งออก env ของกลุ่ม/ไดรเวอร์/บอต SUT ที่เช่าไปยังการรันแพ็กเกจที่ติดตั้งแล้ว, ส่ง Heartbeat ให้สัญญาเช่า และปล่อยสัญญาเช่า เมื่อปิดการทำงาน ตัวห่อหุ้มแพ็กเกจใช้ค่าเริ่มต้นเป็นการตรวจสอบ RTT 20 ครั้งด้วย channel-canary, การหมดเวลา RTT 30s และบทบาท Convex maintainer ภายนอก CI เมื่อเลือก Convex เขียนทับ OPENCLAW_NPM_TELEGRAM_RTT_SAMPLES, OPENCLAW_NPM_TELEGRAM_RTT_TIMEOUT_MS หรือ OPENCLAW_NPM_TELEGRAM_RTT_MAX_FAILURES เพื่อปรับการวัด RTT โดยไม่ต้อง สร้างคำสั่ง RTT แยกต่างหากหรือรูปแบบสรุปเฉพาะ Telegram

QA สำหรับ Discord

pnpm openclaw qa discord

กำหนดเป้าหมายไปยังช่อง guild ส่วนตัวจริงหนึ่งช่องของ Discord พร้อมบอตสองตัว: บอตไดรเวอร์ ที่ควบคุมโดยชุดทดสอบ และบอต SUT ที่เริ่มโดย Gateway ลูกของ OpenClaw ผ่าน Plugin Discord ที่รวมมาให้ ตรวจสอบการจัดการการกล่าวถึงในช่องทาง, ตรวจสอบว่า บอต SUT ได้ลงทะเบียนคำสั่ง /help แบบเนทีฟกับ Discord แล้ว และ ตรวจสอบสถานการณ์หลักฐาน Mantis แบบเลือกใช้

env ที่จำเป็นเมื่อ --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 - ต้องตรงกับ ID ผู้ใช้ของบอต SUT ที่ Discord ส่งคืน (มิฉะนั้นเลนจะล้มเหลวทันที)

ตัวเลือก:

• OPENCLAW_QA_DISCORD_VOICE_CHANNEL_ID เลือกช่องเสียง/เวทีสำหรับ discord-voice-autojoin; หากไม่มีค่านี้ สถานการณ์จะเลือกช่องเสียง/เวทีแรก ที่บอต SUT มองเห็นได้

สถานการณ์โมดูล YAML ของ Discord (qa/scenarios/channels/discord-*.yaml):

• discord-canary
• discord-mention-gating
• discord-native-help-command-registration
• discord-voice-autojoin - สถานการณ์เสียงแบบเลือกใช้ รันแยกเดี่ยว, เปิดใช้ channels.discord.voice.autoJoin และตรวจสอบว่าสถานะเสียงปัจจุบัน ของบอต SUT ใน Discord คือช่องเสียง/เวทีเป้าหมาย ข้อมูลประจำตัว Discord ของ Convex อาจมี voiceChannelId ซึ่งเป็นตัวเลือก; มิฉะนั้น adapter ของตัวรัน จะค้นหาช่องเสียง/เวทีแรกที่มองเห็นได้ใน guild
• discord-status-reactions-tool-only - สถานการณ์ Mantis แบบเลือกใช้ รัน แยกเดี่ยวเนื่องจากจะเปลี่ยน SUT ให้ตอบกลับใน guild แบบเปิดตลอดเวลาและมีเฉพาะเครื่องมือ ด้วย messages.statusReactions.enabled=true จากนั้นบันทึกไทม์ไลน์ รีแอ็กชัน REST พร้อมอาร์ติแฟกต์ภาพ HTML/PNG รายงานก่อน/หลังของ Mantis ยังเก็บรักษาอาร์ติแฟกต์ MP4 ที่สถานการณ์ระบุไว้เป็น baseline.mp4 และ candidate.mp4
• discord-thread-reply-filepath-attachment - สถานการณ์ Mantis แบบเลือกใช้; ดู สถานการณ์ Mantis ของ Discord

รันสถานการณ์เข้าร่วมเสียงอัตโนมัติของ 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 เมื่อรันสถานการณ์ รีแอ็กชันสถานะ

QA สำหรับ Slack

pnpm openclaw qa slack

กำหนดเป้าหมายไปยังช่องส่วนตัวจริงหนึ่งช่องของ Slack พร้อมบอตสองตัวที่แตกต่างกัน: บอตไดรเวอร์ ที่ควบคุมโดยชุดทดสอบ และบอต SUT ที่เริ่มโดย Gateway ลูกของ OpenClaw ผ่าน Plugin Slack ที่รวมมาให้

env ที่จำเป็นเมื่อ --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 adapter จะเขียน <scenario>.pending.json และ <scenario>.resolved.json จากนั้นรอไฟล์ .ack.json ที่ตรงกัน
• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_TIMEOUT_MS เขียนทับระยะหมดเวลาการ รับทราบจุดตรวจสอบ ค่าเริ่มต้นคือ 120000

สถานการณ์ YAML มาตรฐานที่เปิดให้ใช้ผ่าน live adapter ของ Slack:

• thread-follow-up
• thread-isolation

สถานการณ์โมดูล YAML ของ Slack (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 จัดเก็บ white_check_mark สำหรับบอต SUT บนข้อความเป้าหมาย
• slack-chart-presentation-native - สถานการณ์แผนภูมิแบบพกพาที่เลือกใช้ ซึ่ง ตรวจสอบบล็อก data_visualization แบบเนทีฟและข้อความเพื่อการเข้าถึงที่ตรงกันทุกประการ
• slack-table-presentation-native - สถานการณ์ตารางแบบพกพาที่เลือกใช้ ซึ่ง ตรวจสอบบล็อก data_table แบบเนทีฟ, แถวที่ตรงกันทุกประการ และข้อความเพื่อการเข้าถึง
• slack-table-invalid-blocks-fallback - สถานการณ์ทรานสปอร์ตโดยตรงแบบเลือกใช้ ซึ่งส่งตารางดิบที่เกินขีดจำกัดแต่ยังอ่านโครงสร้างได้ โดยมีแถวข้อมูล 101 แถว พร้อมส่วนหัว ผ่านเส้นทางการส่งของ Slack ในระบบใช้งานจริง, พิสูจน์ว่า Slack ส่งคืน invalid_blocks ด้วยตัวเอง และตรวจสอบว่า fallback ที่ปิดใช้งานการจัดรูปแบบซึ่งจัดเก็บไว้นั้นครบถ้วนและไม่มี บล็อกข้อมูลแบบเนทีฟ รายละเอียดสถานการณ์เก็บเฉพาะหลักฐานรหัสข้อผิดพลาด, จำนวน และ ค่าบูลีนที่ปลอดภัย
• slack-approval-exec-native - สถานการณ์อนุมัติ exec แบบเนทีฟของ Slack ที่เลือกใช้ ขอการอนุมัติ exec ผ่าน Gateway, ตรวจสอบว่าข้อความ Slack มีปุ่มอนุมัติแบบเนทีฟ, ดำเนินการให้เสร็จสิ้น และตรวจสอบการอัปเดต Slack หลังดำเนินการเสร็จ
• slack-approval-plugin-native - สถานการณ์อนุมัติ Plugin แบบเนทีฟของ Slack ที่เลือกใช้ เปิดใช้การส่งต่อการอนุมัติ exec และ Plugin พร้อมกันเพื่อไม่ให้เหตุการณ์ ของ Plugin ถูกระงับโดยการกำหนดเส้นทางการอนุมัติ exec จากนั้นตรวจสอบเส้นทาง UI แบบเนทีฟ ของ Slack สำหรับสถานะรอดำเนินการ/ดำเนินการเสร็จแบบเดียวกัน
• slack-codex-approval-exec-native - สถานการณ์อนุมัติคำสั่ง Codex Guardian แบบเลือกใช้ เปิดใช้ Plugin Codex ในโหมด Guardian, กำหนดเส้นทางเทิร์นของเอเจนต์ Gateway ที่มาจาก Slack ผ่านชุดทดสอบ app-server ของ Codex, รอพรอมต์อนุมัติ Plugin Slack แบบเนทีฟสำหรับ openclaw-codex-app-server, ดำเนินการให้เสร็จสิ้น และตรวจสอบว่าเทิร์นของ Codex สิ้นสุดพร้อมเครื่องหมายเอาต์พุตคำสั่งและผู้ช่วยตามที่คาดไว้
• slack-codex-approval-plugin-native - สถานการณ์อนุมัติไฟล์ Codex Guardian แบบเลือกใช้ ใช้คำสั่ง apply_patch ที่อยู่นอกพื้นที่ทำงานเพื่อให้ Codex ส่ง เส้นทางอนุมัติการเปลี่ยนแปลงไฟล์ของ app-server จากนั้นตรวจสอบเส้นทางอนุมัติแบบเนทีฟ ของ Slack สำหรับสถานะรอดำเนินการ/ดำเนินการเสร็จแบบเดียวกัน, เครื่องหมายผู้ช่วยสุดท้าย และเนื้อหาไฟล์ ที่ตรงกันทุกประการก่อนล้างข้อมูล

สถานการณ์อนุมัติ Codex ต้องมี openai/* หรือ codex/* --model, ข้อมูลประจำตัวโมเดลแบบสดตามปกติ และการยืนยันตัวตน Codex หรือการยืนยันตัวตนด้วยคีย์ API ที่ Plugin Codex ยอมรับ รายละเอียดสถานการณ์ประกอบด้วยเมธอด app-server ของ Codex, คีย์โมเดล Codex ที่เลือก, สถานะสุดท้ายของเทิร์น Codex และการตรวจสอบเครื่องหมายการดำเนินการ ควบคู่กับ ข้อมูลเมตาการอนุมัติ Slack ที่ปกปิดข้อมูลแล้ว

อาร์ติแฟกต์เอาต์พุต:

• 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 - ID Cxxxxxxxxxx ของช่องที่เชิญบอตทั้งสองแล้ว ใช้ช่องเฉพาะสำหรับงานนี้; เลนจะโพสต์ทุกครั้งที่รัน
• driverBotToken - โทเค็นบอต (xoxb-...) ของแอป ไดรเวอร์
• sutBotToken - โทเค็นบอต (xoxb-...) ของแอป SUT ซึ่งต้องเป็น แอป Slack คนละแอปกับไดรเวอร์ เพื่อให้ ID ผู้ใช้บอตแตกต่างกัน
• sutAppToken - โทเค็นระดับแอป (xapp-...) ของแอป SUT พร้อม connections:write ซึ่ง Socket Mode ใช้เพื่อให้แอป SUT รับเหตุการณ์ได้

ควรใช้พื้นที่ทำงาน Slack ที่จัดไว้สำหรับ QA โดยเฉพาะ แทนการใช้พื้นที่ทำงาน ระบบใช้งานจริงซ้ำ

ไฟล์ manifest ของ SUT ด้านล่างจงใจจำกัดการติดตั้ง Plugin Slack ที่รวมมาให้ ในระบบใช้งานจริง (extensions/slack/src/setup-shared.ts:12) ให้เหลือเฉพาะ สิทธิ์และเหตุการณ์ที่ชุด QA แบบสดของ Slack ครอบคลุม สำหรับการตั้งค่าช่องใน ระบบใช้งานจริงตามที่ผู้ใช้เห็น โปรดดู การตั้งค่าช่อง Slack แบบรวดเร็ว; คู่ QA ไดรเวอร์/SUT แยกจากกันโดยตั้งใจ เนื่องจากเลนต้องใช้ ID ผู้ใช้บอตที่แตกต่างกันสองรายการ ในพื้นที่ทำงานเดียว

1. สร้างแอปไดรเวอร์

ไปที่ api.slack.com/apps → Create New App → From a manifest → เลือกพื้นที่ทำงาน QA, วาง manifest ต่อไปนี้ จากนั้นเลือก Install to Workspace:

{  "display_information": {    "name": "ไดรเวอร์ QA ของ OpenClaw",    "description": "บอตไดรเวอร์ทดสอบสำหรับเลน QA แบบสดของ OpenClaw บน Slack"  },  "features": {    "bot_user": {      "display_name": "ไดรเวอร์ QA ของ OpenClaw",      "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 นี้ จงใจใช้ manifest สำหรับระบบใช้งานจริงของ Plugin Slack ที่รวมมาให้ ในเวอร์ชันที่จำกัดกว่า (extensions/slack/src/setup-shared.ts:12): ละเว้นขอบเขต และเหตุการณ์ของรีแอ็กชัน เนื่องจากชุด QA แบบสดของ Slack ยังไม่ครอบคลุม การจัดการรีแอ็กชัน

{  "display_information": {    "name": "OpenClaw QA SUT",    "description": "ตัวเชื่อมต่อ OpenClaw QA SUT สำหรับ 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

ตรวจสอบว่าบอตทั้งสองมี ID ผู้ใช้ที่แตกต่างกันโดยเรียก auth.test กับโทเค็นแต่ละรายการ รันไทม์แยกแยะไดรเวอร์และ SUT ด้วย ID ผู้ใช้ การใช้แอปเดียวกัน สำหรับทั้งสองบทบาทจะทำให้การตรวจสอบการกล่าวถึงล้มเหลวทันที

3. สร้างช่อง

ในเวิร์กสเปซ QA ให้สร้างช่อง (เช่น #openclaw-qa) และเชิญบอตทั้งสอง จากภายในช่อง:

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

คัดลอก ID Cxxxxxxxxxx จาก channel info → About → Channel ID ซึ่งค่านี้ จะกลายเป็น channelId ช่องสาธารณะใช้งานได้ หากใช้ช่องส่วนตัว ทั้งสองแอปมี groups:history อยู่แล้ว ดังนั้นการอ่านประวัติของชุดทดสอบ จะยังคงสำเร็จ

4. ลงทะเบียนข้อมูลประจำตัว

มีสองตัวเลือก ใช้ตัวแปรสภาพแวดล้อมสำหรับการดีบักบนเครื่องเดียว (ตั้งค่าตัวแปร 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 จะระบุว่าเป็นกรณีใด

QA สำหรับ WhatsApp

pnpm openclaw qa whatsapp

กำหนดเป้าหมายไปยังบัญชี WhatsApp Web เฉพาะสองบัญชี ได้แก่ บัญชีไดรเวอร์ที่ควบคุมโดย ชุดทดสอบ และบัญชี SUT ที่เริ่มทำงานโดย Gateway ลูกของ OpenClaw ผ่าน Plugin WhatsApp ที่มาพร้อมกัน

ตัวแปรสภาพแวดล้อมที่จำเป็นเมื่อ --credential-source 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

สถานการณ์ YAML ของ WhatsApp (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 รายการเหล่านี้จงใจข้ามการพรอมป์โมเดล และพิสูจน์สัญญา send, poll และ message.action ของ Gateway/ช่องแบบกำหนดผลได้แน่นอน
• ความครอบคลุมของการควบคุมการเข้าถึง: 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 เรียกใช้ 39 สถานการณ์แบบกำหนดผลได้แน่นอนผ่านการรับส่งข้อมูล WhatsApp จริง โดยจำลองเฉพาะเอาต์พุตของโมเดล สถานการณ์การอนุมัติและการตรวจสอบที่หนักกว่า/ทำให้บล็อกบางรายการ ยังต้องระบุอย่างชัดแจ้งด้วย ID สถานการณ์

ไดรเวอร์ QA ของ WhatsApp สังเกตเหตุการณ์สดที่มีโครงสร้าง (text, media, location, reaction และ poll) และสามารถส่งสื่อ โพล รายชื่อติดต่อ ตำแหน่งที่ตั้ง และสติกเกอร์ได้โดยตรง QA Lab นำเข้าไดรเวอร์ดังกล่าวผ่าน พื้นผิวแพ็กเกจ @openclaw/whatsapp/api.js แทนการเข้าถึงไฟล์รันไทม์ส่วนตัว ของ WhatsApp สำหรับการสังเกตการณ์ในกลุ่ม 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 สามารถเช่าข้อมูลประจำตัวจาก พูล 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 ต้องเป็นสตริง ID แชตที่เป็นตัวเลข
• ผู้ใช้ Telegram จริง (kind: "telegram-user"): { groupId: string, sutToken: string, testerUserId: string, testerUsername: string, telegramApiId: string, telegramApiHash: string, tdlibDatabaseEncryptionKey: string, tdlibArchiveBase64: string, tdlibArchiveSha256: string, desktopTdataArchiveBase64: string, desktopTdataArchiveSha256: string } - สำหรับหลักฐาน Telegram Desktop ของ Mantis เท่านั้น เลนทั่วไปของ QA Lab ต้องไม่รับ ชนิดนี้
• WhatsApp (kind: "whatsapp"): { driverPhoneE164: string, sutPhoneE164: string, driverAuthArchiveBase64: string, sutAuthArchiveBase64: string, groupJid?: string } โดยหมายเลขโทรศัพท์ต้องเป็นสตริง E.164 ที่แตกต่างกัน

เวิร์กโฟลว์หลักฐาน Telegram Desktop ของ Mantis ถือสิทธิ์เช่า Convex telegram-user แบบเอกสิทธิ์หนึ่งรายการสำหรับทั้งไดรเวอร์ CLI ของ TDLib และพยาน Telegram Desktop จากนั้นจึงปล่อยสิทธิ์หลังเผยแพร่หลักฐาน

เมื่อ PR ต้องการความแตกต่างเชิงภาพแบบกำหนดผลได้แน่นอน Mantis สามารถใช้คำตอบจำลอง ของโมเดลเดียวกันบน main และบนส่วนหัวของ PR ขณะที่ตัวจัดรูปแบบหรือ ชั้นการส่งของ Telegram เปลี่ยนแปลง ค่าเริ่มต้นในการบันทึกได้รับการปรับสำหรับความคิดเห็น PR ได้แก่ คลาส Crabbox มาตรฐาน การบันทึกเดสก์ท็อป 24fps, GIF แบบเคลื่อนไหว 24fps และความกว้างภาพตัวอย่าง 1920px ความคิดเห็นก่อน/หลังควรเผยแพร่ชุดที่สะอาดซึ่งมี เฉพาะ GIF ที่ต้องการ

เลน Slack สามารถใช้พูลได้เช่นกัน ปัจจุบันการตรวจสอบรูปแบบเพย์โหลด Slack อยู่ ในตัวรัน QA ของ Slack แทนที่จะอยู่ในโบรกเกอร์ ให้ใช้ { channelId: string, driverBotToken: string, sutBotToken: string, sutAppToken: string } พร้อม ID ช่อง Slack เช่น Cxxxxxxxxxx ดู การตั้งค่าเวิร์กสเปซ Slack สำหรับการจัดเตรียมแอป และขอบเขต

ตัวแปรสภาพแวดล้อมสำหรับการดำเนินงานและสัญญาปลายทางของโบรกเกอร์ Convex อยู่ใน การทดสอบ → ข้อมูลประจำตัว Telegram ที่ใช้ร่วมกันผ่าน Convex (ชื่อส่วนมีมาก่อนพูลแบบหลายช่อง โดยความหมายเชิงสัญญาของการเช่าจะ ใช้ร่วมกันระหว่างชนิดต่าง ๆ)

ข้อมูลเริ่มต้นที่อิงกับรีโพ

แอสเซ็ตข้อมูลเริ่มต้นอยู่ใน qa/:

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

รายการเหล่านี้อยู่ใน git โดยเจตนา เพื่อให้ทั้งมนุษย์และ เอเจนต์มองเห็นแผน QA

qa-lab ยังคงเป็นตัวรันสถานการณ์ YAML อเนกประสงค์ ไฟล์ YAML ของแต่ละสถานการณ์เป็น แหล่งข้อมูลจริงสำหรับการทดสอบหนึ่งครั้ง และควรกำหนด:

• title ระดับบนสุด
• ข้อมูลเมตา scenario
• ข้อมูลเมตาหมวดหมู่ ความสามารถ เลน และความเสี่ยงที่ไม่บังคับใน scenario
• เอกสารและการอ้างอิงโค้ดใน scenario
• ข้อกำหนด Plugin ที่ไม่บังคับใน scenario
• แพตช์การกำหนดค่า Gateway ที่ไม่บังคับใน scenario
• flow ระดับบนสุดที่เรียกใช้งานได้สำหรับสถานการณ์โฟลว์ หรือ scenario.execution.kind / scenario.execution.path สำหรับสถานการณ์ Vitest และ Playwright

พื้นผิวรันไทม์ที่นำกลับมาใช้ซ้ำได้ซึ่งรองรับ flow ยังคงเป็นแบบทั่วไปและ ครอบคลุมหลายส่วน ตัวอย่างเช่น สถานการณ์ YAML สามารถรวมตัวช่วยฝั่งการขนส่ง เข้ากับตัวช่วยฝั่งเบราว์เซอร์ที่ควบคุม Control UI แบบฝังผ่าน รอยต่อ Gateway browser.request โดยไม่ต้องเพิ่มตัวรันกรณีพิเศษ

ควรจัดกลุ่มไฟล์สถานการณ์ตามความสามารถของผลิตภัณฑ์แทนโฟลเดอร์ในโครงสร้าง ซอร์ส รักษา 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 เป็นเจ้าของรอยต่อการขนส่งทั่วไปสำหรับสถานการณ์ QA แบบ YAML โดย qa-channel เป็น ค่าเริ่มต้นสังเคราะห์ crabline เริ่มเซิร์ฟเวอร์ภายในเครื่องที่มีรูปแบบตามผู้ให้บริการและ เรียกใช้ Plugin ช่องตามปกติของ OpenClaw กับเซิร์ฟเวอร์เหล่านั้น ส่วน live สงวนไว้สำหรับ ข้อมูลประจำตัวของผู้ให้บริการจริงและช่องภายนอก

ในระดับสถาปัตยกรรม การแบ่งส่วนมีดังนี้:

• qa-lab เป็นเจ้าของการดำเนินสถานการณ์ทั่วไป ภาวะพร้อมกันของเวิร์กเกอร์ การเขียน อาร์ติแฟกต์ และการรายงาน
• อะแดปเตอร์การขนส่งเป็นเจ้าของการกำหนดค่า Gateway ความพร้อม การสังเกตขาเข้าและขาออก การดำเนินการของการขนส่ง และสถานะการขนส่งที่ทำให้เป็นมาตรฐานแล้ว
• ไฟล์สถานการณ์ YAML ภายใต้ qa/scenarios/ กำหนดการรันทดสอบ ส่วน qa-lab มอบพื้นผิวรันไทม์ที่นำกลับมาใช้ซ้ำได้เพื่อดำเนินสถานการณ์เหล่านั้น

การเพิ่มช่อง

การเพิ่มช่องไปยังระบบ QA แบบ YAML ต้องมีการนำช่องไปใช้ พร้อมชุดสถานการณ์ที่ทดสอบสัญญาของช่อง สำหรับการครอบคลุม CI แบบควัน ให้เพิ่มเซิร์ฟเวอร์ผู้ให้บริการภายในเครื่อง Crabline ที่ตรงกันและเปิดให้ใช้งาน ผ่านไดรเวอร์ crabline

อย่าเพิ่มรูทคำสั่ง QA ระดับบนสุดใหม่เมื่อโฮสต์ qa-lab ที่ใช้ร่วมกันสามารถ เป็นเจ้าของโฟลว์ได้

qa-lab เป็นเจ้าของกลไกโฮสต์ที่ใช้ร่วมกัน:

• รูทคำสั่ง openclaw qa
• การเริ่มและยุติชุดทดสอบ
• ภาวะพร้อมกันของเวิร์กเกอร์
• การเขียนอาร์ติแฟกต์
• การสร้างรายงาน
• การดำเนินสถานการณ์
• ชื่อแฝงเพื่อความเข้ากันได้สำหรับสถานการณ์ qa-channel รุ่นเก่า

Plugin ตัวรันเป็นเจ้าของสัญญาการขนส่ง:

• วิธีติดตั้ง openclaw qa <runner> ภายใต้รูท qa ที่ใช้ร่วมกัน
• วิธีกำหนดค่า Gateway สำหรับการขนส่งนั้น
• วิธีตรวจสอบความพร้อม
• วิธีฉีดเหตุการณ์ขาเข้า
• วิธีสังเกตข้อความขาออก
• วิธีเปิดให้เข้าถึงทรานสคริปต์และสถานะการขนส่งที่ทำให้เป็นมาตรฐานแล้ว
• วิธีดำเนินการที่รองรับโดยการขนส่ง
• วิธีจัดการการรีเซ็ตหรือการล้างข้อมูลเฉพาะการขนส่ง

เกณฑ์ขั้นต่ำสำหรับการนำช่องใหม่มาใช้:

1. คงให้ qa-lab เป็นเจ้าของรูท qa ที่ใช้ร่วมกัน
2. นำตัวรันการขนส่งไปใช้บนรอยต่อโฮสต์ qa-lab ที่ใช้ร่วมกัน
3. เก็บกลไกเฉพาะการขนส่งไว้ภายใน Plugin ตัวรันหรือ ฮาร์เนสของช่อง
4. ติดตั้งตัวรันเป็น openclaw qa <runner> แทนการลงทะเบียน รูทคำสั่งที่แข่งขันกัน Plugin ตัวรันควรประกาศ qaRunners ใน openclaw.plugin.json และส่งออกอาร์เรย์ qaRunnerCliRegistrations ที่ตรงกันจาก runtime-api.ts รักษา runtime-api.ts ให้เบา โดย CLI แบบโหลดเมื่อใช้และ การดำเนินตัวรันควรอยู่หลังจุดเข้าแยกกัน adapterFactory ที่เป็นตัวเลือก เปิดให้สถานการณ์ที่ใช้ร่วมกันเข้าถึงการขนส่งได้โดยไม่เปลี่ยน แค็ตตาล็อกสถานการณ์ที่มีอยู่ของคำสั่ง
5. เขียนหรือปรับสถานการณ์ YAML ภายใต้ไดเรกทอรี qa/scenarios/ ที่จัดตามธีม
6. ใช้ตัวช่วยสถานการณ์ทั่วไปสำหรับสถานการณ์ใหม่
7. รักษาชื่อแฝงเพื่อความเข้ากันได้ที่มีอยู่ให้ทำงานต่อไป เว้นแต่รีโพกำลังดำเนิน การย้ายโดยตั้งใจ

กฎการตัดสินใจเข้มงวด:

• หากพฤติกรรมสามารถแสดงได้ครั้งเดียวใน qa-lab ให้ใส่ไว้ใน qa-lab
• หากพฤติกรรมขึ้นอยู่กับการขนส่งของช่องใดช่องหนึ่ง ให้เก็บไว้ใน Plugin ตัวรัน หรือฮาร์เนส Plugin นั้น
• หากสถานการณ์ต้องการความสามารถใหม่ที่ใช้ได้กับมากกว่าหนึ่งช่อง ให้เพิ่มตัวช่วยทั่วไปแทนการแตกแขนงเฉพาะช่องใน suite.ts
• หากพฤติกรรมมีความหมายสำหรับการขนส่งเพียงแบบเดียว ให้รักษาสถานการณ์ ให้เฉพาะการขนส่งและระบุเรื่องนี้อย่างชัดเจนในสัญญาสถานการณ์

ชื่อตัวช่วยสถานการณ์

ตัวช่วยทั่วไปที่แนะนำสำหรับสถานการณ์ใหม่:

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

ชื่อแฝงเพื่อความเข้ากันได้ยังคงพร้อมใช้งานสำหรับสถานการณ์ที่มีอยู่ - waitForQaChannelReady, waitForOutboundMessage, waitForNoOutbound, formatConversationTranscript, resetBus - แต่การเขียนสถานการณ์ใหม่ ควรใช้ชื่อทั่วไป ชื่อแฝงมีไว้เพื่อหลีกเลี่ยงการย้ายทั้งหมดพร้อมกัน ไม่ใช่แบบจำลองสำหรับใช้ต่อไป

การรายงาน

qa-lab ส่งออกรายงานโปรโตคอล Markdown จากไทม์ไลน์บัสที่สังเกตได้ รายงานควรตอบว่า:

• สิ่งใดทำงานได้
• สิ่งใดล้มเหลว
• สิ่งใดยังคงถูกบล็อก
• สถานการณ์ติดตามผลใดควรเพิ่ม

สำหรับรายการสถานการณ์ที่พร้อมใช้งาน ซึ่งมีประโยชน์เมื่อประเมินขนาดงานติดตามผล หรือเชื่อมต่อการขนส่งใหม่ ให้เรียกใช้ pnpm openclaw qa coverage (เพิ่ม --json สำหรับเอาต์พุตที่เครื่องอ่านได้) เมื่อเลือกหลักฐานเฉพาะจุดสำหรับ พฤติกรรมหรือพาธไฟล์ที่แก้ไข ให้เรียกใช้ pnpm openclaw qa coverage --match <query> รายงานการจับคู่จะค้นหาข้อมูลเมตาของสถานการณ์ การอ้างอิงเอกสาร การอ้างอิงโค้ด ID ความครอบคลุม Plugin และข้อกำหนดของผู้ให้บริการ จากนั้นพิมพ์เป้าหมาย qa suite --scenario ... ที่ตรงกัน

การรัน qa suite ทุกครั้งจะเขียนอาร์ติแฟกต์ระดับบนสุด qa-evidence.json, qa-suite-summary.json และ qa-suite-report.md สำหรับชุดสถานการณ์ที่เลือก สถานการณ์ที่ประกาศ execution.kind: vitest หรือ execution.kind: playwright จะเรียกใช้พาธทดสอบที่ตรงกันและเขียน ล็อกแยกตามสถานการณ์ด้วย สถานการณ์ที่ประกาศ execution.kind: script จะเรียกใช้ ตัวสร้างหลักฐานที่ execution.path ผ่าน node --import tsx (โดยขยาย ${outputDir} และ ${scenarioId} ใน execution.args) โดย ตัวสร้างจะเขียน qa-evidence.json ของตนเอง ซึ่งรายการภายในจะถูกนำเข้าไปยัง เอาต์พุตของชุดทดสอบ และพาธอาร์ติแฟกต์จะถูกแก้ไขโดยอิงจาก qa-evidence.json ของตัวสร้างนั้น เมื่อเข้าถึง qa suite ผ่าน qa run --qa-profile 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

คำสั่งจะเรียกใช้กระบวนการลูกของ Gateway สำหรับ QA ภายในเครื่อง ไม่ใช่ Docker สถานการณ์ ประเมินบุคลิกควรกำหนดเพอร์โซนาผ่าน SOUL.md จากนั้นเรียกใช้ เทิร์นผู้ใช้ทั่วไป เช่น แชท ความช่วยเหลือเกี่ยวกับเวิร์กสเปซ และงานไฟล์ขนาดเล็ก ไม่ควรบอก โมเดลผู้สมัครว่ากำลังถูกประเมิน คำสั่งจะเก็บ ทรานสคริปต์ฉบับเต็มแต่ละรายการ บันทึกสถิติการรันพื้นฐาน จากนั้นให้โมเดลผู้ตัดสินใน โหมดเร็วที่ใช้การให้เหตุผล xhigh เมื่อรองรับ จัดอันดับการรันตาม ความเป็นธรรมชาติ บรรยากาศ และอารมณ์ขัน ใช้ --blind-judge-models เมื่อเปรียบเทียบ ผู้ให้บริการ โดยพรอมต์ผู้ตัดสินยังคงได้รับทรานสคริปต์และสถานะการรันทั้งหมด แต่ การอ้างอิงผู้สมัครจะถูกแทนด้วยป้ายกำกับกลาง เช่น candidate-01 และ รายงานจะแมปอันดับกลับไปยังการอ้างอิงจริงหลังการแยกวิเคราะห์

การรันผู้สมัครใช้การคิดแบบ high เป็นค่าเริ่มต้น โดยใช้ medium สำหรับ GPT-5.6 Luna และ xhigh สำหรับการอ้างอิงการประเมิน OpenAI รุ่นเก่าที่รองรับ สามารถแทนที่ผู้สมัครเฉพาะราย แบบอินไลน์ด้วย --model provider/model,thinking=<level> ตัวเลือกอินไลน์ ยังรองรับ fast, no-fast และ fast=<bool> ด้วย --thinking <level> ยังคงกำหนดค่าทดแทนส่วนกลาง และรูปแบบ --model-thinking <provider/model=level> รุ่นเก่า ยังคงไว้เพื่อความเข้ากันได้ การอ้างอิงผู้สมัคร OpenAI ใช้โหมดเร็วเป็นค่าเริ่มต้นเพื่อให้ใช้ การประมวลผลแบบลำดับความสำคัญในจุดที่ผู้ให้บริการรองรับ ส่ง --fast เฉพาะเมื่อต้องการ บังคับเปิดโหมดเร็วสำหรับโมเดลผู้สมัครทุกโมเดล ระยะเวลาการรันของผู้สมัครและผู้ตัดสินจะถูกบันทึกใน รายงานเพื่อการวิเคราะห์เบนช์มาร์ก แต่พรอมต์ผู้ตัดสินจะระบุอย่างชัดเจนว่าอย่าจัดอันดับ ตามความเร็ว การรันโมเดลผู้สมัครและผู้ตัดสินใช้ภาวะพร้อมกัน 16 เป็นค่าเริ่มต้น ลด --concurrency หรือ --judge-concurrency เมื่อขีดจำกัดของผู้ให้บริการหรือแรงกดดันต่อ Gateway ภายในเครื่องทำให้การรันมีสัญญาณรบกวนมากเกินไป

เมื่อไม่ได้ส่ง --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
• การทดสอบ
• แดชบอร์ด