การทดสอบ

OpenClaw มีชุดทดสอบ Vitest สามชุด (ยูนิต/การผสานรวม, e2e, ไลฟ์) รวมถึงตัวรัน Docker หน้านี้อธิบายขอบเขตของแต่ละชุด คำสั่งที่ต้องรันสำหรับเวิร์กโฟลว์แต่ละแบบ วิธีที่การทดสอบไลฟ์ค้นหาข้อมูลรับรอง และวิธีเพิ่มการทดสอบการถดถอย สำหรับข้อบกพร่องของผู้ให้บริการ/โมเดลที่พบในการใช้งานจริง

เริ่มต้นอย่างรวดเร็ว

สำหรับการใช้งานส่วนใหญ่ในแต่ละวัน:

• เกตเต็มรูปแบบ (ควรรันก่อนพุช): pnpm build && pnpm check && pnpm check:test-types && pnpm test
• รันชุดทดสอบทั้งหมดภายในเครื่องได้เร็วขึ้นบนเครื่องที่มีทรัพยากรเพียงพอ: pnpm test:max
• ลูปเฝ้าดู Vitest โดยตรง: pnpm test:watch
• การระบุไฟล์โดยตรงรองรับพาธของ Plugin/ช่องทางด้วย: pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts
• เมื่อตรวจแก้ความล้มเหลวรายการเดียว ให้เริ่มจากการรันเฉพาะส่วนที่เกี่ยวข้องก่อน
• ไซต์ QA ที่ใช้ Docker: pnpm qa:lab:up
• เลน QA ที่ใช้ VM Linux: pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline

เมื่อคุณแก้ไขการทดสอบหรือต้องการความมั่นใจเพิ่มขึ้น:

• รายงานความครอบคลุม V8 เพื่อให้ข้อมูล: pnpm test:coverage
• ชุดทดสอบ E2E: pnpm test:e2e

ไดเรกทอรีชั่วคราวสำหรับการทดสอบ

ใช้ตัวช่วยร่วมใน test/helpers/temp-dir.ts สำหรับไดเรกทอรีชั่วคราว ที่การทดสอบเป็นเจ้าของ เพื่อให้ระบุความเป็นเจ้าของอย่างชัดเจนและให้การล้างข้อมูล อยู่ภายในวงจรชีวิตของการทดสอบ:

  const tempDirs = useAutoCleanupTempDirTracker(afterEach); it("uses a temp workspace", () => {  const workspace = tempDirs.make("openclaw-example-");  // use workspace});

useAutoCleanupTempDirTracker(afterEach) ตั้งใจไม่เปิดเผยเมธอด ล้างข้อมูลด้วยตนเอง เนื่องจาก Vitest เป็นผู้จัดการการล้างข้อมูลหลังการทดสอบแต่ละรายการ ตัวช่วยระดับล่างแบบเก่า (makeTempDir, cleanupTempDirs, createTempDirTracker) ยังคงมีอยู่สำหรับการทดสอบที่ยังไม่ได้ย้ายระบบ หลีกเลี่ยงการใช้งานใหม่และหลีกเลี่ยง การเรียก fs.mkdtemp* โดยตรงแบบใหม่ เว้นแต่การทดสอบนั้นกำลังตรวจสอบพฤติกรรม ดิบของไดเรกทอรีชั่วคราวโดยเฉพาะ เมื่อจำเป็นต้องใช้ไดเรกทอรีชั่วคราวโดยตรงจริง ๆ ให้เพิ่มความคิดเห็นอนุญาตที่ตรวจสอบย้อนหลังได้พร้อมเหตุผล:

// openclaw-temp-dir: allow verifies raw fs cleanup behaviorconst workspace = fs.mkdtempSync(prefix);

node scripts/report-test-temp-creations.mjs รายงานการสร้างไดเรกทอรีชั่วคราว โดยตรงรายการใหม่และการใช้งานตัวช่วยร่วมแบบสั่งด้วยตนเองรายการใหม่ในบรรทัดที่เพิ่ม ใน diff โดยไม่ขัดขวางรูปแบบการล้างข้อมูลเดิม โดยใช้การจำแนกพาธการทดสอบแบบเดียวกับ scripts/changed-lanes.mjs และข้ามตัวการทำงานของตัวช่วยร่วมเอง check:changed รันรายงานนี้สำหรับพาธการทดสอบที่เปลี่ยนแปลงเป็นสัญญาณ CI แบบเตือนเท่านั้น (คำอธิบายประกอบคำเตือนของ GitHub ไม่ใช่ความล้มเหลว)

เวิร์กโฟลว์ไลฟ์และ Docker/Parallels

เมื่อตรวจแก้ผู้ให้บริการ/โมเดลจริง (ต้องใช้ข้อมูลรับรองจริง):

• ชุดทดสอบไลฟ์ (โมเดล + การตรวจสอบเครื่องมือ/รูปภาพของ Gateway): pnpm test:live
• ระบุไฟล์ไลฟ์หนึ่งไฟล์แบบลดข้อความรบกวน: pnpm test:live -- src/agents/models.profiles.live.test.ts
• รายงานประสิทธิภาพขณะรันไทม์: เรียกใช้ OpenClaw Performance โดยตั้ง live_openai_candidate=true สำหรับหนึ่งรอบการทำงานจริงของเอเจนต์ openai/gpt-5.6-luna หรือ deep_profile=true สำหรับอาร์ติแฟกต์ CPU/ฮีป/เทรซ ของ Kova การรันตามกำหนดการรายวันเผยแพร่รายงานเลนผู้ให้บริการจำลอง โปรไฟล์เชิงลึก และ GPT-5.6 Luna ไปยัง openclaw/clawgrit-reports จากงานผู้เผยแพร่แยกต่างหากที่ใช้อาร์ติแฟกต์ หากการยืนยันตัวตนของผู้เผยแพร่ ขาดหายหรือไม่ถูกต้อง การรันตามกำหนดการและการรัน profile=release จะล้มเหลว การเรียกใช้ด้วยตนเองที่ไม่ใช่รุ่นเผยแพร่จะเก็บอาร์ติแฟกต์ GitHub ไว้ และถือว่าการเผยแพร่รายงานเป็นเพียงคำแนะนำ รายงานผู้ให้บริการจำลองยังรวม ตัวเลขการบูต Gateway ระดับซอร์ส หน่วยความจำ แรงกดดันจาก Plugin ลูปทักทายซ้ำของโมเดลจำลอง และการเริ่มต้น CLI
• การกวาดทดสอบโมเดลไลฟ์ด้วย Docker: pnpm test:docker:live-models
  • โมเดลที่เลือกแต่ละรายการจะรันหนึ่งรอบข้อความพร้อมการตรวจสอบขนาดเล็ก ในลักษณะการอ่านไฟล์ โมเดลที่ข้อมูลเมตาระบุว่ารองรับอินพุต image จะรันรูปภาพขนาดเล็กหนึ่งรอบด้วย ปิดการตรวจสอบเพิ่มเติมด้วย OPENCLAW_LIVE_MODEL_FILE_PROBE=0 หรือ OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0 เมื่อต้องการแยกตรวจความล้มเหลวของผู้ให้บริการ
  • ความครอบคลุมของ CI: ทั้ง OpenClaw Scheduled Live And E2E Checks รายวันและ OpenClaw Release Checks ที่เรียกใช้ด้วยตนเองจะเรียกเวิร์กโฟลว์ ไลฟ์/E2E ที่นำกลับมาใช้ซ้ำได้โดยตั้ง include_live_suites: true ซึ่งรวมงานเมทริกซ์โมเดลไลฟ์ของ Docker ที่แบ่งชาร์ดตามผู้ให้บริการ
  • สำหรับการรัน CI ซ้ำเฉพาะจุด ให้เรียกใช้ OpenClaw Live And E2E Checks (Reusable) โดยตั้ง include_live_suites: true และ live_models_only: true
  • เพิ่มซีเคร็ตของผู้ให้บริการใหม่ที่ให้สัญญาณสูงลงใน scripts/ci-hydrate-live-auth.sh รวมถึง .github/workflows/openclaw-live-and-e2e-checks-reusable.yml และตัวเรียกตามกำหนดการ/รุ่นเผยแพร่ของไฟล์นั้น
• การตรวจสอบเบื้องต้นของแชตที่ผูกกับ Codex แบบเนทีฟ: pnpm test:docker:live-codex-bind
  • รันเลนไลฟ์ Docker กับพาธเซิร์ฟเวอร์แอป Codex ผูก DM Slack จำลอง ด้วย /codex bind ทดสอบ /codex fast และ /codex permissions จากนั้นตรวจสอบว่าการตอบกลับแบบข้อความธรรมดาและไฟล์แนบรูปภาพ ถูกกำหนดเส้นทางผ่านการผูก Plugin แบบเนทีฟแทน ACP
• การตรวจสอบเบื้องต้นของชุดทดสอบเซิร์ฟเวอร์แอป Codex: pnpm test:docker:live-codex-harness
  • รันรอบการทำงานของเอเจนต์ Gateway ผ่านชุดทดสอบเซิร์ฟเวอร์แอป Codex ที่ Plugin เป็นเจ้าของ ตรวจสอบ /codex status และ /codex models และตามค่าเริ่มต้นจะทดสอบรูปภาพ, cron MCP, เอเจนต์ย่อย และ Guardian ปิดการตรวจสอบเอเจนต์ย่อยด้วย OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0 เมื่อต้องการแยกตรวจความล้มเหลวอื่น สำหรับการตรวจสอบเอเจนต์ย่อยเฉพาะจุด ให้ปิดการตรวจสอบอื่น: OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness การทำงานนี้จะออกหลังการตรวจสอบเอเจนต์ย่อย เว้นแต่ตั้งค่า OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0
• การตรวจสอบเบื้องต้นของการติดตั้ง Codex ตามต้องการ: pnpm test:docker:codex-on-demand
  • ติดตั้ง tarball OpenClaw ที่จัดแพ็กเกจแล้วใน Docker รันการเริ่มต้นใช้งาน ด้วยคีย์ API ของ OpenAI และตรวจสอบว่า Plugin Codex พร้อมการขึ้นต่อกัน @openai/codex ถูกดาวน์โหลดลงในรูทโปรเจกต์ npm ที่มีการจัดการตามต้องการ
• การตรวจสอบเบื้องต้นของการขึ้นต่อกันของเครื่องมือ Plugin แบบไลฟ์: pnpm test:docker:live-plugin-tool
  • จัดแพ็กเกจ Plugin ฟิกซ์เจอร์ที่มีการขึ้นต่อกันจริงกับ slugify ติดตั้งผ่าน npm-pack: ตรวจสอบการขึ้นต่อกันภายใต้รูทโปรเจกต์ npm ที่มีการจัดการ จากนั้นขอให้โมเดล OpenAI แบบไลฟ์เรียกเครื่องมือของ Plugin และส่งคืนสลักที่ซ่อนไว้
• การตรวจสอบเบื้องต้นของคำสั่งกู้คืน Crestodian: pnpm test:live:crestodian-rescue-channel
  • การตรวจสอบเสริมแบบหลายชั้นที่เลือกเปิดใช้ได้สำหรับชุดคำสั่งกู้คืน ของช่องทางข้อความ ทดสอบ /crestodian status จัดคิวการเปลี่ยนโมเดล แบบถาวร ตอบกลับ /crestodian yes และตรวจสอบพาธการเขียนบันทึกตรวจสอบ/การกำหนดค่า
• การตรวจสอบเบื้องต้นของการรัน Crestodian ครั้งแรกด้วย Docker: pnpm test:docker:crestodian-first-run
  • เริ่มจากไดเรกทอรีสถานะ OpenClaw ที่ว่างเปล่า และพิสูจน์ก่อนว่า CLI openclaw crestodian ที่จัดแพ็กเกจแล้วจะหยุดทำงานอย่างปลอดภัยเมื่อไม่มี การอนุมาน จากนั้นทดสอบและเปิดใช้งาน Claude จำลองผ่านโมดูลเปิดใช้งาน ที่จัดแพ็กเกจแล้ว หลังจากนั้นเท่านั้น คำขอ CLI แบบคลุมเครือที่จัดแพ็กเกจแล้ว จึงจะเข้าถึงตัววางแผนและแปลงเป็นการตั้งค่าแบบมีชนิด ตามด้วยการดำเนินการ แบบครั้งเดียวสำหรับโมเดล เอเจนต์ Plugin Discord และ SecretRef โดยจะตรวจสอบรายการการกำหนดค่าและบันทึกตรวจสอบ นี่เป็นหลักฐานประกอบ สำหรับเกต/การดำเนินการ ไม่ใช่หลักฐานของการเริ่มต้นใช้งานแบบโต้ตอบ หรือเอเจนต์/เครื่องมือ/การอนุมัติของ Crestodian เลนเดียวกันนี้เปิดให้ใช้ ใน QA Lab ผ่าน pnpm openclaw qa suite --scenario crestodian-ring-zero-setup
• การตรวจสอบเบื้องต้นของค่าใช้จ่าย Moonshot/Kimi: เมื่อตั้งค่า MOONSHOT_API_KEY ให้รัน openclaw models list --provider moonshot --json จากนั้นรัน openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json แบบแยกส่วนกับ moonshot/kimi-k2.6 ตรวจสอบว่า JSON รายงาน Moonshot/K2.6 และทรานสคริปต์ของผู้ช่วยจัดเก็บ usage.cost ที่ปรับให้อยู่ในรูปแบบมาตรฐาน

ตัวรันเฉพาะสำหรับ QA

ใช้คำสั่งเหล่านี้ควบคู่กับชุดทดสอบหลักเมื่อต้องการความสมจริงระดับ QA Lab

CI รัน QA Lab ในเวิร์กโฟลว์เฉพาะ ความสอดคล้องแบบเอเจนต์อยู่ภายใต้ QA-Lab - All Lanes และการตรวจสอบรุ่นเผยแพร่ ไม่ใช่เวิร์กโฟลว์ PR แบบแยกเดี่ยว การตรวจสอบแบบกว้างควรใช้ Full Release Validation โดยตั้ง rerun_group=qa-parity หรือใช้กลุ่ม QA ของการตรวจสอบรุ่นเผยแพร่ การตรวจสอบรุ่นเผยแพร่แบบเสถียร/ค่าเริ่มต้นจะเก็บการทดสอบแช่ไลฟ์/Docker แบบครอบคลุมไว้หลัง run_release_soak=true ส่วนโปรไฟล์ full จะบังคับเปิดการทดสอบแช่ QA-Lab - All Lanes รันทุกคืนบน main และจากการเรียกใช้ด้วยตนเอง โดยรันเลนความสอดคล้องจำลอง เลน Matrix แบบไลฟ์ เลน Telegram แบบไลฟ์ที่ Convex จัดการ และเลน Discord แบบไลฟ์ที่ Convex จัดการเป็นงานคู่ขนาน QA ตามกำหนดการและการตรวจสอบรุ่นเผยแพร่จะส่ง --profile fast ให้ Matrix อย่างชัดเจน ขณะที่ CLI ของ Matrix และอินพุตเวิร์กโฟลว์แบบสั่งด้วยตนเองยังคงมีค่าเริ่มต้นเป็น all การเรียกใช้ด้วยตนเองสามารถแบ่งชาร์ด all เป็นงาน transport, media, e2ee-smoke, e2ee-deep และ e2ee-cli ได้ OpenClaw Release Checks รันความสอดคล้อง รวมถึงเลน Matrix แบบเร็วและเลน Telegram ก่อนอนุมัติรุ่นเผยแพร่ โดยใช้ mock-openai/gpt-5.6-luna สำหรับการตรวจสอบการขนส่งของรุ่นเผยแพร่ เพื่อให้ผลลัพธ์คงที่ และหลีกเลี่ยงการเริ่มต้น Plugin ของผู้ให้บริการตามปกติ Gateway การขนส่งไลฟ์เหล่านี้ปิดการค้นหาหน่วยความจำ ส่วนพฤติกรรมหน่วยความจำ ยังคงครอบคลุมโดยชุดทดสอบความสอดคล้องของ QA

ชาร์ดสื่อไลฟ์สำหรับรุ่นเผยแพร่เต็มรูปแบบใช้ ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04 ซึ่งมี ffmpeg และ ffprobe อยู่แล้ว ชาร์ดโมเดล/แบ็กเอนด์ไลฟ์ของ Docker ใช้อิมเมจร่วม ghcr.io/openclaw/openclaw-live-test:<sha> ที่สร้าง หนึ่งครั้งต่อคอมมิตที่เลือก จากนั้นดึงอิมเมจด้วย OPENCLAW_SKIP_DOCKER_BUILD=1 แทนการสร้างใหม่ภายในทุกชาร์ด

• pnpm openclaw qa suite
  • เรียกใช้สถานการณ์จำลอง QA ที่อ้างอิงจากรีโพซิทอรีโดยตรงบนโฮสต์
  • เขียนอาร์ติแฟกต์ระดับบนสุด qa-evidence.json, qa-suite-summary.json และ qa-suite-report.md สำหรับชุดสถานการณ์จำลองที่เลือก รวมถึงการเลือกสถานการณ์จำลอง แบบโฟว์ผสม, Vitest และ Playwright
  • เมื่อเรียกผ่าน pnpm openclaw qa run --qa-profile <profile> จะฝัง ตารางสรุปคะแนนโปรไฟล์อนุกรมวิธานที่เลือกไว้ใน qa-evidence.json เดียวกัน smoke-ci เขียนหลักฐานแบบย่อ (evidenceMode: "slim" โดยไม่มี execution แยกตามรายการ) release ครอบคลุมส่วนที่คัดสรรสำหรับความพร้อมในการเผยแพร่ ส่วน all เลือกทุกหมวดหมู่วุฒิภาวะที่ใช้งานอยู่ และมุ่งเป้าไปที่การสั่งเรียกเวิร์กโฟลว์ QA Profile Evidence อย่างชัดเจนเมื่อต้องใช้อาร์ติแฟกต์ตารางสรุปคะแนนฉบับเต็ม
  • เรียกใช้สถานการณ์จำลองที่เลือกหลายรายการแบบขนานโดยค่าเริ่มต้น ด้วย เวิร์กเกอร์ Gateway ที่แยกจากกัน qa-channel ใช้ค่าการทำงานพร้อมกันเริ่มต้นเป็น 4 (จำกัดตาม จำนวนสถานการณ์จำลองที่เลือก) ใช้ --concurrency <count> เพื่อปรับจำนวนเวิร์กเกอร์ หรือใช้ --concurrency 1 สำหรับเลนแบบลำดับรุ่นเก่า
  • จบการทำงานด้วยรหัสที่ไม่ใช่ศูนย์เมื่อสถานการณ์จำลองใดล้มเหลว ใช้ --allow-failures เพื่อสร้าง อาร์ติแฟกต์โดยไม่มีรหัสจบการทำงานที่บ่งชี้ความล้มเหลว
  • รองรับโหมดผู้ให้บริการ live-frontier, mock-openai และ aimock aimock เริ่มเซิร์ฟเวอร์ผู้ให้บริการภายในเครื่องที่ทำงานด้วย AIMock สำหรับ ความครอบคลุมของฟิกซ์เจอร์เชิงทดลองและม็อกโปรโตคอล โดยไม่แทนที่เลน mock-openai ที่รับรู้สถานการณ์จำลอง
• pnpm openclaw qa coverage --match <query>
  • ค้นหา ID สถานการณ์จำลอง ชื่อ พื้นผิว ID ความครอบคลุม การอ้างอิงเอกสาร การอ้างอิง โค้ด Plugin และข้อกำหนดของผู้ให้บริการ จากนั้นพิมพ์เป้าหมายชุดทดสอบที่ตรงกัน
  • ใช้คำสั่งนี้ก่อนเรียกใช้ QA Lab เมื่อคุณทราบพฤติกรรมหรือพาธไฟล์ที่ถูกแก้ไข แต่ไม่ทราบสถานการณ์จำลองที่เล็กที่สุด เป็นเพียงคำแนะนำเท่านั้น — ยังคงต้องเลือกหลักฐานแบบม็อก แบบสด, Multipass, Matrix หรือการขนส่งตามพฤติกรรมที่กำลังเปลี่ยนแปลง
• pnpm test:plugins:kitchen-sink-live
  • เรียกใช้ด่านทดสอบ Plugin Kitchen Sink ของ OpenAI แบบสดผ่าน QA Lab ติดตั้งแพ็กเกจ Kitchen Sink ภายนอก ตรวจสอบรายการพื้นผิวของ plugin SDK ตรวจสอบ /healthz และ /readyz บันทึกหลักฐาน CPU/RSS ของ Gateway เรียกใช้รอบโต้ตอบ OpenAI แบบสด และตรวจสอบการวินิจฉัยเชิงปฏิปักษ์ ต้องมีการยืนยันตัวตน OpenAI แบบสด เช่น OPENAI_API_KEY ใน เซสชัน Testbox ที่เติมข้อมูลไว้ ระบบจะโหลดโปรไฟล์การยืนยันตัวตนแบบสดของ Testbox โดยอัตโนมัติ เมื่อมีตัวช่วย openclaw-testbox-env
• pnpm test:gateway:cpu-scenarios
  • เรียกใช้เบนช์มาร์กการเริ่มต้น Gateway พร้อมชุดสถานการณ์จำลอง QA Lab แบบม็อกขนาดเล็ก (channel-chat-baseline, memory-failure-fallback, gateway-restart-inflight-run) และเขียนสรุปการสังเกต CPU แบบรวม ไว้ภายใต้ .artifacts/gateway-cpu-scenarios/
  • โดยค่าเริ่มต้นจะแจ้งเฉพาะการสังเกต CPU ร้อนที่เกิดขึ้นต่อเนื่อง (--cpu-core-warn ค่าเริ่มต้น 0.9; --hot-wall-warn-ms ค่าเริ่มต้น 30000) ดังนั้นช่วงพุ่งสูงสั้น ๆ ระหว่างเริ่มต้นจะถูกบันทึกเป็นเมตริก โดยไม่ดูเหมือนการถดถอยที่ทำให้ Gateway ใช้ CPU เต็มต่อเนื่องหลายนาที
  • ทำงานกับอาร์ติแฟกต์ dist ที่สร้างแล้ว ให้เรียกใช้การสร้างก่อนเมื่อเช็กเอาต์ ยังไม่มีเอาต์พุตรันไทม์ที่เป็นปัจจุบัน
• pnpm openclaw qa suite --runner multipass
  • เรียกใช้ชุด QA เดียวกันภายใน VM Linux ของ Multipass แบบใช้แล้วทิ้ง โดยคง แฟล็กการเลือกสถานการณ์จำลองและผู้ให้บริการ/โมเดลแบบเดียวกับ qa suite
  • การเรียกใช้แบบสดจะส่งต่ออินพุตการยืนยันตัวตน QA ที่ใช้ได้จริงสำหรับเกสต์: คีย์ผู้ให้บริการจากสภาพแวดล้อม พาธการกำหนดค่าผู้ให้บริการแบบสดของ QA และ CODEX_HOME เมื่อมีอยู่
  • ไดเรกทอรีเอาต์พุตต้องอยู่ภายใต้รูทของรีโพซิทอรี เพื่อให้เกสต์เขียนกลับ ผ่านเวิร์กสเปซที่เมานต์ไว้ได้
  • เขียนรายงานและสรุป QA ตามปกติ พร้อมบันทึก Multipass ภายใต้ .artifacts/qa-e2e/...
• pnpm qa:lab:up
  • เริ่มไซต์ QA ที่ทำงานบน Docker สำหรับงาน QA ในรูปแบบผู้ปฏิบัติงาน
• pnpm test:docker:npm-onboard-channel-agent
  • สร้างทาร์บอล npm จากเช็กเอาต์ปัจจุบัน ติดตั้งแบบส่วนกลางใน Docker เรียกใช้การเริ่มต้นใช้งานด้วยคีย์ API ของ OpenAI แบบไม่โต้ตอบ กำหนดค่า Telegram โดยค่าเริ่มต้น ตรวจสอบว่ารันไทม์ Plugin ที่บรรจุในแพ็กเกจโหลดได้โดยไม่ต้อง ซ่อมแซมการขึ้นต่อกันระหว่างเริ่มต้น เรียกใช้ doctor และเรียกใช้รอบการทำงานของเอเจนต์ภายในเครื่องหนึ่งรอบ กับปลายทาง OpenAI แบบม็อก
  • ใช้ OPENCLAW_NPM_ONBOARD_CHANNEL=discord เพื่อเรียกใช้เลนการติดตั้งจากแพ็กเกจ เดียวกันกับ Discord
• pnpm test:docker:session-runtime-context
  • เรียกใช้การทดสอบเบื้องต้นด้วย Docker ของแอปที่สร้างแล้วแบบกำหนดผลลัพธ์ได้ สำหรับทรานสคริปต์บริบทรันไทม์ ที่ฝังไว้ ตรวจสอบว่าบริบทรันไทม์ OpenClaw ที่ซ่อนอยู่คงอยู่ในรูป ข้อความกำหนดเองที่ไม่แสดงผล แทนที่จะรั่วไหลไปยังรอบโต้ตอบที่ผู้ใช้มองเห็น จากนั้นเตรียม JSONL ของเซสชันที่เสียหายและได้รับผลกระทบ แล้วตรวจสอบว่า openclaw doctor --fix เขียนใหม่ไปยังกิ่งที่ใช้งานอยู่พร้อมข้อมูลสำรอง
• pnpm test:docker:npm-telegram-live
  • ติดตั้งแพ็กเกจ OpenClaw รุ่นผู้สมัครใน Docker เรียกใช้การเริ่มต้นใช้งาน ของแพ็กเกจที่ติดตั้ง กำหนดค่า Telegram ผ่าน CLI ที่ติดตั้ง จากนั้นนำ เลน QA ของ Telegram แบบสดกลับมาใช้กับแพ็กเกจที่ติดตั้งนั้นในฐานะ Gateway ของระบบภายใต้การทดสอบ
  • ตัวห่อหุ้มเมานต์เฉพาะซอร์สฮาร์เนส qa-lab จากเช็กเอาต์ แพ็กเกจที่ติดตั้งเป็นเจ้าของ dist, openclaw/plugin-sdk และรันไทม์ Plugin ที่รวมมา ดังนั้นเลนนี้จะไม่ผสม Plugin จากเช็กเอาต์ปัจจุบันเข้าไป ในแพ็กเกจที่กำลังทดสอบ
  • ค่าเริ่มต้นคือ OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta; ตั้งค่า OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz หรือ OPENCLAW_CURRENT_PACKAGE_TGZ เพื่อทดสอบทาร์บอลภายในเครื่องที่ได้รับการแก้ไขแล้ว แทนการติดตั้งจากรีจิสทรี
  • โดยค่าเริ่มต้นจะส่งออกการจับเวลา RTT ซ้ำใน qa-evidence.json ด้วย OPENCLAW_NPM_TELEGRAM_RTT_SAMPLES=20 กำหนดค่าแทน OPENCLAW_NPM_TELEGRAM_RTT_SAMPLES, OPENCLAW_NPM_TELEGRAM_RTT_TIMEOUT_MS หรือ OPENCLAW_NPM_TELEGRAM_RTT_MAX_FAILURES เพื่อปรับการเรียกใช้ OPENCLAW_NPM_TELEGRAM_RTT_CHECKS รับรายการ ID การตรวจสอบ QA ของ Telegram ที่คั่นด้วยจุลภาคเพื่อสุ่มตัวอย่าง เมื่อไม่ได้ตั้งค่า การตรวจสอบเริ่มต้น ที่รองรับ RTT คือ telegram-mentioned-message-reply
  • ใช้ข้อมูลประจำตัวจากสภาพแวดล้อมของ Telegram หรือแหล่งข้อมูลประจำตัว Convex เดียวกับ pnpm openclaw qa telegram สำหรับระบบอัตโนมัติ CI/การเผยแพร่ ให้ตั้งค่า OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex พร้อม OPENCLAW_QA_CONVEX_SITE_URL และข้อมูลลับของบทบาท หากมี OPENCLAW_QA_CONVEX_SITE_URL และข้อมูลลับของบทบาท Convex ใน CI ตัวห่อหุ้ม Docker จะเลือก Convex โดยอัตโนมัติ
  • ตัวห่อหุ้มจะตรวจสอบสภาพแวดล้อมข้อมูลประจำตัวของ Telegram หรือ Convex บนโฮสต์ ก่อนงานสร้าง/ติดตั้ง Docker ตั้งค่า OPENCLAW_NPM_TELEGRAM_SKIP_CREDENTIAL_PREFLIGHT=1 เฉพาะเมื่อ ตั้งใจดีบักการตั้งค่าก่อนมีข้อมูลประจำตัว
  • OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer กำหนดค่าแทน OPENCLAW_QA_CREDENTIAL_ROLE ที่ใช้ร่วมกันสำหรับเลนนี้เท่านั้น เมื่อเลือกข้อมูลประจำตัว Convex และไม่ได้ตั้งค่าบทบาท ตัวห่อหุ้มจะใช้ ci ใน CI และ maintainer ภายนอก CI
  • GitHub Actions เปิดให้ใช้เลนนี้ในชื่อเวิร์กโฟลว์สำหรับผู้ดูแลแบบสั่งเอง NPM Telegram Beta E2E โดยจะไม่ทำงานเมื่อผสาน เวิร์กโฟลว์ใช้ สภาพแวดล้อม qa-live-shared และสัญญาเช่าข้อมูลประจำตัว CI ของ Convex
• GitHub Actions ยังเปิดให้ใช้ Package Acceptance สำหรับหลักฐานผลิตภัณฑ์แบบเรียกใช้แยก กับแพ็กเกจผู้สมัครหนึ่งรายการ โดยรับ Git ref, ข้อกำหนด npm ที่เผยแพร่แล้ว, URL ทาร์บอล HTTPS พร้อม SHA-256, นโยบาย URL ที่เชื่อถือได้ หรืออาร์ติแฟกต์ทาร์บอล จากการเรียกใช้อื่น (source=ref|npm|url|trusted-url|artifact) อัปโหลด openclaw-current.tgz ที่ปรับให้เป็นมาตรฐานเป็น package-under-test จากนั้นเรียกใช้ ตัวจัดกำหนดการ E2E ของ Docker ที่มีอยู่ด้วยโปรไฟล์เลน smoke, package, product, full หรือ custom ตั้งค่า telegram_mode=mock-openai หรือ live-frontier เพื่อเรียกใช้เวิร์กโฟลว์ QA ของ Telegram กับอาร์ติแฟกต์ package-under-test เดียวกัน
  • หลักฐานผลิตภัณฑ์เบต้าล่าสุด:

gh workflow run package-acceptance.yml --ref main \  -f source=npm \  -f package_spec=openclaw@beta \  -f suite_profile=product \  -f telegram_mode=mock-openai

• หลักฐาน URL ทาร์บอลแบบตรงต้องมีไดเจสต์ และใช้นโยบายความปลอดภัยของ URL สาธารณะ:

gh workflow run package-acceptance.yml --ref main \  -f source=url \  -f package_url=https://registry.npmjs.org/openclaw/-/openclaw-VERSION.tgz \  -f package_sha256=<sha256> \  -f suite_profile=package

• มิเรอร์ทาร์บอลระดับองค์กร/ส่วนตัวใช้นโยบายแหล่งที่เชื่อถือได้อย่างชัดเจน:

gh workflow run package-acceptance.yml --ref main \  -f source=trusted-url \  -f trusted_source_id=enterprise-artifactory \  -f package_url=https://packages.example.internal:8443/artifactory/openclaw/openclaw-VERSION.tgz \  -f package_sha256=<sha256> \  -f suite_profile=package

source=trusted-url อ่าน .github/package-trusted-sources.json จาก ref เวิร์กโฟลว์ที่เชื่อถือได้ และไม่ยอมรับข้อมูลประจำตัวใน URL หรือการข้ามข้อจำกัดเครือข่ายส่วนตัวผ่านอินพุตเวิร์กโฟลว์ หากนโยบายที่ระบุประกาศใช้การยืนยันตัวตนแบบ bearer ให้กำหนดค่าข้อมูลลับ OPENCLAW_TRUSTED_PACKAGE_TOKEN แบบคงที่

• หลักฐานอาร์ติแฟกต์ดาวน์โหลดอาร์ติแฟกต์ทาร์บอลจากการเรียกใช้ Actions อื่น:

gh workflow run package-acceptance.yml --ref main \  -f source=artifact \  -f artifact_run_id=<run-id> \  -f artifact_name=<artifact-name> \  -f suite_profile=smoke

• pnpm test:docker:plugins

  • แพ็กและติดตั้งบิลด์ OpenClaw ปัจจุบันใน Docker เริ่ม Gateway โดยกำหนดค่า OpenAI แล้วเปิดใช้ช่องทาง/Plugin ที่รวมมาผ่าน การแก้ไขการกำหนดค่า
  • ตรวจสอบว่าการค้นพบระหว่างตั้งค่าปล่อยให้ Plugin ที่ดาวน์โหลดได้แต่ยังไม่ได้กำหนดค่า ไม่มีอยู่ การซ่อมแซมด้วย doctor ครั้งแรกหลังการกำหนดค่าจะติดตั้ง Plugin ที่ดาวน์โหลดได้ แต่ละรายการที่ขาดหายอย่างชัดเจน และการเริ่มใหม่ครั้งที่สองจะไม่เรียกใช้ การซ่อมแซมการขึ้นต่อกันแบบซ่อน
  • นอกจากนี้ยังติดตั้งค่าอ้างอิง npm รุ่นเก่าที่ทราบ เปิดใช้ Telegram ก่อน เรียกใช้ openclaw update --tag <candidate> และตรวจสอบว่า doctor หลังการอัปเดตของรุ่นผู้สมัครล้างเศษซากการขึ้นต่อกันของ Plugin แบบเดิม โดยไม่ต้องใช้การซ่อมแซมหลังติดตั้งจากฝั่งฮาร์เนส

• pnpm test:parallels:npm-update

  • เรียกใช้การทดสอบเบื้องต้นการอัปเดตการติดตั้งจากแพ็กเกจแบบเนทีฟกับเกสต์ Parallels แต่ละแพลตฟอร์มที่เลือกจะติดตั้งแพ็กเกจค่าอ้างอิงที่ร้องขอก่อน จากนั้นเรียกใช้คำสั่ง openclaw update ที่ติดตั้งแล้วในเกสต์เดียวกัน และ ตรวจสอบเวอร์ชันที่ติดตั้ง สถานะการอัปเดต ความพร้อมของ Gateway และ รอบการทำงานของเอเจนต์ภายในเครื่องหนึ่งรอบ

  • ใช้ --platform macos, --platform windows หรือ --platform linux ขณะทำซ้ำกับเกสต์เดียว ใช้ --json สำหรับพาธอาร์ติแฟกต์สรุป และสถานะแต่ละเลน

  • เลน OpenAI ใช้ openai/gpt-5.6-luna สำหรับหลักฐานรอบการทำงานของเอเจนต์แบบสดโดย ค่าเริ่มต้น ส่ง --model <provider/model> หรือตั้งค่า OPENCLAW_PARALLELS_OPENAI_MODEL เพื่อตรวจสอบโมเดล OpenAI อื่น

  • ครอบการเรียกใช้ภายในเครื่องที่ใช้เวลานานด้วยการหมดเวลาของโฮสต์ เพื่อไม่ให้การค้างของการขนส่ง Parallels ใช้เวลาที่เหลือทั้งหมดของช่วงทดสอบ:

    timeout --foreground 150m pnpm test:parallels:npm-update -- --jsontimeout --foreground 90m pnpm test:parallels:npm-update -- --platform windows --json

  • สคริปต์เขียนบันทึกเลนแบบซ้อนภายใต้ /tmp/openclaw-parallels-npm-update.* ตรวจสอบ windows-update.log, macos-update.log หรือ linux-update.log ก่อนสรุปว่าตัวห่อหุ้ม ชั้นนอกค้าง

  • การอัปเดต Windows อาจใช้เวลา 10 ถึง 15 นาทีใน doctor หลังการอัปเดตและ งานอัปเดตแพ็กเกจบนเกสต์ที่ยังไม่อุ่น ซึ่งยังถือว่าปกติเมื่อ บันทึกดีบัก npm แบบซ้อนยังคงมีความคืบหน้า

  • อย่าเรียกใช้ตัวห่อหุ้มแบบรวมนี้พร้อมกันกับเลนทดสอบเบื้องต้น Parallels สำหรับ macOS, Windows หรือ Linux แยกกัน เนื่องจากใช้สถานะ VM ร่วมกันและอาจ ชนกันระหว่างการคืนค่าสแนปช็อต การให้บริการแพ็กเกจ หรือสถานะ Gateway ของเกสต์

  • หลักฐานหลังการอัปเดตเรียกใช้พื้นผิว Plugin ที่รวมมาตามปกติ เนื่องจาก ฟาซาดความสามารถ เช่น เสียงพูด การสร้างภาพ และการทำความเข้าใจสื่อ โหลดผ่าน API รันไทม์ที่รวมมา แม้ว่ารอบการทำงานของเอเจนต์ จะตรวจสอบเพียงการตอบกลับข้อความอย่างง่ายก็ตาม

• pnpm openclaw qa aimock

  • เริ่มเฉพาะเซิร์ฟเวอร์ผู้ให้บริการ AIMock ภายในเครื่องสำหรับการทดสอบควันของโปรโตคอลโดยตรง

• pnpm openclaw qa matrix

  • เรียกใช้เลน QA แบบสดของ Matrix กับโฮมเซิร์ฟเวอร์ Tuwunel แบบใช้แล้วทิ้งที่ทำงานบน Docker ใช้ได้เฉพาะจากการเช็กเอาต์ซอร์สเท่านั้น—การติดตั้งจากแพ็กเกจไม่มี qa-lab
  • รายละเอียด CLI ทั้งหมด แค็ตตาล็อกโปรไฟล์/สถานการณ์ ตัวแปรสภาพแวดล้อม และโครงสร้างอาร์ติแฟกต์: QA ของ Matrix

• pnpm openclaw qa telegram

  • เรียกใช้เลน QA แบบสดของ Telegram กับกลุ่มส่วนตัวจริง โดยใช้โทเค็นบอตไดรเวอร์และบอต SUT จากตัวแปรสภาพแวดล้อม
  • ต้องมี OPENCLAW_QA_TELEGRAM_GROUP_ID, OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN และ OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN รหัสกลุ่มต้องเป็นรหัสแชต Telegram แบบตัวเลข
  • รองรับ --credential-source convex สำหรับข้อมูลรับรองแบบพูลที่ใช้ร่วมกัน ใช้โหมดตัวแปรสภาพแวดล้อมเป็นค่าเริ่มต้น หรือตั้ง OPENCLAW_QA_CREDENTIAL_SOURCE=convex เพื่อเลือกใช้สัญญาเช่าจากพูล
  • ค่าเริ่มต้นครอบคลุมการทดสอบคานารี การควบคุมด้วยการกล่าวถึง การระบุปลายทางคำสั่ง /status การตอบกลับระหว่างบอตที่มีการกล่าวถึง และการตอบกลับคำสั่งเนทีฟหลัก ค่าเริ่มต้นของ mock-openai ยังครอบคลุมการถดถอยของสายโซ่การตอบกลับแบบกำหนดผลลัพธ์ได้ และการสตรีมข้อความสุดท้ายของ Telegram ใช้ --list-scenarios สำหรับโพรบเสริม เช่น session_status
  • จบการทำงานด้วยรหัสที่ไม่ใช่ศูนย์เมื่อสถานการณ์ใดก็ตามล้มเหลว ใช้ --allow-failures เพื่อสร้างอาร์ติแฟกต์โดยไม่ให้รหัสจบการทำงานบ่งชี้ความล้มเหลว
  • ต้องใช้บอตที่แตกต่างกันสองตัวในกลุ่มส่วนตัวเดียวกัน โดยบอต SUT ต้องมีชื่อผู้ใช้ Telegram
  • เพื่อให้การสังเกตการสื่อสารระหว่างบอตมีเสถียรภาพ ให้เปิดใช้งาน Bot-to-Bot Communication Mode ใน @BotFather สำหรับบอตทั้งสอง และตรวจสอบว่าบอตไดรเวอร์สามารถสังเกตทราฟฟิกของบอตในกลุ่มได้
  • เขียนรายงาน QA ของ Telegram สรุป และ qa-evidence.json ไว้ภายใต้ .artifacts/qa-e2e/... สถานการณ์ที่มีการตอบกลับจะรวม RTT ตั้งแต่คำขอส่งของไดรเวอร์ จนถึงการสังเกตพบการตอบกลับจาก SUT

Mantis Telegram Live เป็นตัวห่อหุ้มสำหรับหลักฐาน PR ของเลนนี้ โดยเรียกใช้ รีเฟอเรนซ์ผู้สมัครด้วยข้อมูลรับรอง Telegram ที่เช่าผ่าน Convex แสดงผลชุดรายงาน/หลักฐาน QA ที่ปกปิดข้อมูลสำคัญในเบราว์เซอร์เดสก์ท็อป Crabbox บันทึกหลักฐานเป็น MP4 สร้าง GIF ที่ตัดช่วงไร้การเคลื่อนไหว อัปโหลดชุดอาร์ติแฟกต์ และโพสต์หลักฐานแบบอินไลน์ใน PR ผ่าน Mantis GitHub App เมื่อตั้งค่า pr_number ผู้ดูแลสามารถเริ่มงานจาก Actions UI ผ่าน Mantis Scenario (scenario_id: telegram-live) หรือโดยตรงจากความคิดเห็นในคำขอดึง:

@openclaw-mantis telegram@openclaw-mantis telegram scenario=telegram-status-command@openclaw-mantis telegram scenarios=telegram-status-command,telegram-mentioned-message-reply

Mantis Telegram Desktop Proof เป็นตัวห่อหุ้ม Telegram Desktop แบบเนทีฟที่ทำงานด้วยเอเจนต์ สำหรับหลักฐานภาพก่อน/หลังของ PR เริ่มได้จาก Actions UI ด้วย instructions แบบข้อความอิสระ ผ่าน Mantis Scenario (scenario_id: telegram-desktop-proof) หรือจากความคิดเห็นใน PR:

@openclaw-mantis telegram desktop proof

เอเจนต์ Mantis อ่าน PR ตัดสินว่าพฤติกรรมใดที่มองเห็นได้ใน Telegram สามารถพิสูจน์ การเปลี่ยนแปลง เรียกใช้เลนพิสูจน์ Telegram Desktop ของผู้ใช้จริงผ่าน Crabbox กับรีเฟอเรนซ์พื้นฐานและรีเฟอเรนซ์ผู้สมัคร ปรับซ้ำจน GIF แบบเนทีฟใช้งานได้ดี เขียนแมนิเฟสต์ motionPreview แบบจับคู่ และโพสต์ตาราง GIF แบบ 2 คอลัมน์เดียวกัน ผ่าน Mantis GitHub App เมื่อตั้งค่า pr_number

• pnpm openclaw qa mantis telegram-desktop-builder
  • เช่าหรือนำเดสก์ท็อป Linux ของ Crabbox กลับมาใช้ใหม่ ติดตั้ง Telegram Desktop แบบเนทีฟ กำหนดค่า OpenClaw ด้วยโทเค็นบอต Telegram SUT ที่เช่ามา เริ่ม Gateway และบันทึกหลักฐานภาพหน้าจอ/MP4 จากเดสก์ท็อป VNC ที่มองเห็นได้
  • ใช้ --credential-source convex เป็นค่าเริ่มต้น เพื่อให้เวิร์กโฟลว์ต้องใช้เพียง ข้อมูลลับของนายหน้า Convex ใช้ --credential-source env ร่วมกับตัวแปร OPENCLAW_QA_TELEGRAM_* ชุดเดียวกับ pnpm openclaw qa telegram
  • Telegram Desktop ยังคงต้องมีการเข้าสู่ระบบ/โปรไฟล์ของผู้ใช้ โทเค็นบอต ใช้กำหนดค่า OpenClaw เท่านั้น ใช้ --telegram-profile-archive-env <name> สำหรับอาร์ไคฟ์โปรไฟล์ .tgz แบบ base64 หรือใช้ --keep-lease แล้วเข้าสู่ระบบ ด้วยตนเองผ่าน VNC หนึ่งครั้ง
  • เขียน mantis-telegram-desktop-builder-report.md, mantis-telegram-desktop-builder-summary.json, telegram-desktop-builder.png และ telegram-desktop-builder.mp4 ไว้ภายใต้ไดเรกทอรีเอาต์พุต

เลนการขนส่งแบบสดใช้สัญญามาตรฐานเดียวกันร่วมกัน เพื่อป้องกันไม่ให้การขนส่งใหม่ เบี่ยงเบนออกจากกัน เมทริกซ์ความครอบคลุมของแต่ละเลนอยู่ใน ภาพรวม QA—ความครอบคลุมการขนส่งแบบสด qa-channel เป็นชุดทดสอบสังเคราะห์แบบกว้างและไม่ได้เป็นส่วนหนึ่งของเมทริกซ์ดังกล่าว

ข้อมูลรับรอง Telegram ที่ใช้ร่วมกันผ่าน Convex (v1)

เมื่อเปิดใช้ --credential-source convex (หรือ OPENCLAW_QA_CREDENTIAL_SOURCE=convex) สำหรับ QA การขนส่งแบบสด ห้องปฏิบัติการ QA จะขอสัญญาเช่าแบบเอกสิทธิ์จากพูลที่ใช้ Convex ส่ง Heartbeat ให้สัญญาเช่านั้นระหว่างที่เลนกำลังทำงาน และคืนสัญญาเช่าเมื่อปิดระบบ ชื่อส่วนนี้มีมาก่อนการรองรับ Discord, Slack และ WhatsApp แต่สัญญาการเช่าใช้ร่วมกัน สำหรับทุกชนิด

โครงร่างโปรเจกต์ Convex สำหรับใช้อ้างอิง: qa/convex-credential-broker/

ตัวแปรสภาพแวดล้อมที่จำเป็น:

• OPENCLAW_QA_CONVEX_SITE_URL (ตัวอย่างเช่น https://your-deployment.convex.site)
• ข้อมูลลับหนึ่งรายการสำหรับบทบาทที่เลือก:
  • OPENCLAW_QA_CONVEX_SECRET_MAINTAINER สำหรับ maintainer
  • OPENCLAW_QA_CONVEX_SECRET_CI สำหรับ ci
• การเลือกบทบาทข้อมูลรับรอง:
  • CLI: --credential-role maintainer|ci
  • ค่าเริ่มต้นจากตัวแปรสภาพแวดล้อม: OPENCLAW_QA_CREDENTIAL_ROLE (ค่าเริ่มต้นเป็น ci ใน CI และเป็น maintainer ในกรณีอื่น)

ตัวแปรสภาพแวดล้อมเสริม:

• OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS (ค่าเริ่มต้น 1200000)
• OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS (ค่าเริ่มต้น 30000)
• OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS (ค่าเริ่มต้น 90000)
• OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS (ค่าเริ่มต้น 15000)
• OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX (ค่าเริ่มต้น /qa-credentials/v1)
• OPENCLAW_QA_CREDENTIAL_OWNER_ID (รหัสการติดตามเสริม)
• OPENCLAW_QA_ALLOW_INSECURE_HTTP=1 อนุญาต URL ของ Convex แบบ local loopback http:// สำหรับการพัฒนาภายในเครื่องเท่านั้น

ในการทำงานตามปกติ OPENCLAW_QA_CONVEX_SITE_URL ควรใช้ https://

คำสั่งผู้ดูแลระบบสำหรับผู้ดูแล (เพิ่ม/ลบ/แสดงรายการพูล) ต้องใช้ OPENCLAW_QA_CONVEX_SECRET_MAINTAINER โดยเฉพาะ

ตัวช่วย CLI สำหรับผู้ดูแล:

pnpm openclaw qa credentials doctorpnpm openclaw qa credentials add --kind telegram --payload-file qa/telegram-credential.jsonpnpm openclaw qa credentials list --kind telegrampnpm openclaw qa credentials remove --credential-id <credential-id>

ใช้ doctor ก่อนการเรียกใช้แบบสด เพื่อตรวจสอบ URL ไซต์ Convex ข้อมูลลับของนายหน้า คำนำหน้าเอนด์พอยต์ การหมดเวลา HTTP และความสามารถในการเข้าถึงการดูแลระบบ/รายการ โดยไม่พิมพ์ค่าข้อมูลลับ ใช้ --json สำหรับเอาต์พุตที่เครื่องอ่านได้ในสคริปต์และยูทิลิตี CI

สัญญาเอนด์พอยต์เริ่มต้น (OPENCLAW_QA_CONVEX_SITE_URL + /qa-credentials/v1) คำขอยืนยันตัวตนด้วยส่วนหัว Authorization: Bearer <role secret>; เนื้อหาคำขอด้านล่างละส่วนหัวดังกล่าวไว้:

• POST /acquire
  • คำขอ: { kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }
  • สำเร็จ: { status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }
  • พูลหมด/ลองใหม่ได้: { status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }
• POST /payload-chunk
  • คำขอ: { kind, ownerId, actorRole, credentialId, leaseToken, index }
  • สำเร็จ: { status: "ok", index, data }
• POST /heartbeat
  • คำขอ: { kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }
  • สำเร็จ: { status: "ok" } (หรือ 2xx ว่าง)
• POST /release
  • คำขอ: { kind, ownerId, actorRole, credentialId, leaseToken }
  • สำเร็จ: { status: "ok" } (หรือ 2xx ว่าง)
• POST /admin/add (เฉพาะข้อมูลลับของผู้ดูแล)
  • คำขอ: { kind, actorId, payload, note?, status? }
  • สำเร็จ: { status: "ok", credential }
• POST /admin/remove (เฉพาะข้อมูลลับของผู้ดูแล)
  • คำขอ: { credentialId, actorId }
  • สำเร็จ: { status: "ok", changed, credential }
  • ตัวป้องกันสัญญาเช่าที่ใช้งานอยู่: { status: "error", code: "LEASE_ACTIVE", ... }
• POST /admin/list (เฉพาะข้อมูลลับของผู้ดูแล)
  • คำขอ: { kind?, status?, includePayload?, limit? }
  • สำเร็จ: { status: "ok", credentials, count }

รูปแบบเพย์โหลดสำหรับชนิด Telegram:

• { groupId: string, driverToken: string, sutToken: string }
• groupId ต้องเป็นสตริงรหัสแชต Telegram แบบตัวเลข
• admin/add ตรวจสอบรูปแบบนี้สำหรับ kind: "telegram" และปฏิเสธเพย์โหลดที่มีรูปแบบไม่ถูกต้อง

รูปแบบเพย์โหลดสำหรับชนิดผู้ใช้จริงของ Telegram:

• { groupId: string, sutToken: string, testerUserId: string, testerUsername: string, telegramApiId: string, telegramApiHash: string, tdlibDatabaseEncryptionKey: string, tdlibArchiveBase64: string, tdlibArchiveSha256: string, desktopTdataArchiveBase64: string, desktopTdataArchiveSha256: string }
• groupId, testerUserId และ telegramApiId ต้องเป็นสตริงตัวเลข
• tdlibArchiveSha256 และ desktopTdataArchiveSha256 ต้องเป็นสตริงเลขฐานสิบหก SHA-256
• kind: "telegram-user" สงวนไว้สำหรับเวิร์กโฟลว์พิสูจน์ Mantis Telegram Desktop เลน QA Lab ทั่วไปต้องไม่ขอรับชนิดนี้

เพย์โหลดหลายช่องทางที่นายหน้าตรวจสอบ:

• Discord: { guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string, voiceChannelId?: string }
• WhatsApp: { driverPhoneE164: string, sutPhoneE164: string, driverAuthArchiveBase64: string, sutAuthArchiveBase64: string, groupJid?: string }

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

การเพิ่มช่องทางใน QA

สถาปัตยกรรมและชื่อของตัวช่วยสถานการณ์สำหรับอะแดปเตอร์ช่องทางใหม่อยู่ใน ภาพรวม QA—การเพิ่มช่องทาง ข้อกำหนดขั้นต่ำ: ใช้งานตัวเรียกใช้การขนส่งบนรอยต่อโฮสต์ qa-lab ที่ใช้ร่วมกัน เพิ่ม adapterFactory สำหรับสถานการณ์ที่ใช้ร่วมกัน ประกาศ qaRunners ในแมนิเฟสต์ ของ Plugin เมานต์เป็น openclaw qa <runner> และเขียนสถานการณ์ภายใต้ qa/scenarios/

ชุดการทดสอบ (สิ่งใดทำงานที่ใด)

ให้มองชุดทดสอบเหล่านี้ว่าเป็น “ระดับความสมจริงที่เพิ่มขึ้น” (พร้อมความไม่เสถียร/ต้นทุนที่เพิ่มขึ้น)

ยูนิต / การผสานรวม (ค่าเริ่มต้น)

• คำสั่ง: pnpm test
• การกำหนดค่า: การเรียกใช้ที่ไม่ระบุเป้าหมายจะใช้ชุดชาร์ด vitest.full-*.config.ts และอาจขยายชาร์ดแบบหลายโปรเจกต์เป็นการกำหนดค่ารายโปรเจกต์ เพื่อจัดกำหนดการแบบขนาน
• ไฟล์: รายการทดสอบหลัก/ยูนิตภายใต้ src/**/*.test.ts, packages/**/*.test.ts และ test/**/*.test.ts; การทดสอบยูนิต UI ทำงานใน ชาร์ด unit-ui โดยเฉพาะ
• ขอบเขต:
  • การทดสอบยูนิตล้วน
  • การทดสอบการผสานรวมภายในโปรเซส (การยืนยันตัวตนของ Gateway การกำหนดเส้นทาง เครื่องมือ การแยกวิเคราะห์ การกำหนดค่า)
  • การทดสอบการถดถอยแบบกำหนดผลลัพธ์ได้สำหรับข้อบกพร่องที่ทราบ
• ความคาดหวัง:
  • ทำงานใน CI
  • ไม่ต้องใช้คีย์จริง
  • ควรรวดเร็วและเสถียร
  • การทดสอบตัวแก้ไขพาธและตัวโหลดพื้นผิวสาธารณะต้องพิสูจน์พฤติกรรมสำรองแบบกว้างของ api.js และ runtime-api.js ด้วยฟิกซ์เจอร์ Plugin ขนาดเล็กที่สร้างขึ้น ไม่ใช่ API จากซอร์ส Plugin ที่รวมมาให้จริง การโหลด API ของ Plugin จริงควรอยู่ใน ชุดสัญญา/การผสานรวมที่ Plugin นั้นเป็นเจ้าของ

นโยบายการพึ่งพาแบบเนทีฟ:

• การติดตั้งเพื่อทดสอบตามค่าเริ่มต้นจะข้ามการบิลด์ opus แบบเนทีฟซึ่งเป็นทางเลือกของ Discord เสียงของ Discord ใช้ libopus-wasm ที่รวมมาให้ และปิดใช้งาน @discordjs/opus ใน allowBuilds เพื่อไม่ให้การทดสอบภายในเครื่องและเลน Testbox คอมไพล์ ส่วนเสริมแบบเนทีฟ
• เปรียบเทียบประสิทธิภาพ opus แบบเนทีฟในรีโพซิทอรีเบนช์มาร์ก libopus-wasm ไม่ใช่ในวงจรติดตั้ง/ทดสอบเริ่มต้นของ OpenClaw อย่าตั้ง @discordjs/opus เป็น true ใน allowBuilds เริ่มต้น เพราะจะทำให้วงจรติดตั้ง/ทดสอบที่ไม่เกี่ยวข้อง ต้องคอมไพล์โค้ดเนทีฟ

ความเสถียร (Gateway)

• คำสั่ง: pnpm test:stability:gateway
• การกำหนดค่า: test/vitest/vitest.gateway.config.ts, test/vitest/vitest.logging.config.ts และ test/vitest/vitest.infra.config.ts โดยแต่ละรายการถูกบังคับให้ใช้หนึ่งเวิร์กเกอร์
• ขอบเขต:
  • เริ่ม Gateway แบบ local loopback จริง โดยเปิดใช้การวินิจฉัยเป็นค่าเริ่มต้น
  • ขับเคลื่อนการหมุนเวียนของข้อความ Gateway หน่วยความจำ และเพย์โหลดขนาดใหญ่แบบสังเคราะห์ผ่านพาธเหตุการณ์วินิจฉัย
  • สอบถาม diagnostics.stability ผ่าน Gateway WS RPC
  • ครอบคลุมตัวช่วยคงข้อมูลบันเดิลความเสถียรของการวินิจฉัย
  • ยืนยันว่าตัวบันทึกยังคงมีขอบเขตจำกัด ตัวอย่าง RSS สังเคราะห์อยู่ต่ำกว่างบประมาณแรงกดดัน และความลึกของคิวต่อเซสชันลดกลับเป็นศูนย์
• ความคาดหวัง:
  • ปลอดภัยสำหรับ CI และไม่ต้องใช้คีย์
  • เป็นเลนขอบเขตแคบสำหรับติดตามการถดถอยด้านความเสถียร ไม่ใช่สิ่งทดแทนชุดทดสอบ Gateway ฉบับเต็ม

E2E (การรวมทั้งที่เก็บ)

• คำสั่ง: pnpm test:e2e
• ขอบเขต:
  • เรียกใช้เลน E2E สำหรับการทดสอบควันของ Gateway
  • เรียกใช้เลน E2E ของเบราว์เซอร์ Control UI แบบจำลอง
• ความคาดหวัง:
  • ปลอดภัยสำหรับ CI และไม่ต้องใช้คีย์
  • ต้องติดตั้ง Playwright Chromium

E2E (การทดสอบควันของ Gateway)

• คำสั่ง: pnpm test:e2e:gateway
• การกำหนดค่า: test/vitest/vitest.e2e.config.ts
• ไฟล์: src/**/*.e2e.test.ts, test/**/*.e2e.test.ts และการทดสอบ E2E ของ Plugin ที่รวมมาให้ภายใต้ extensions/
• ค่าเริ่มต้นของรันไทม์:
  • ใช้ threads ของ Vitest พร้อม isolate: false ให้ตรงกับส่วนอื่นของที่เก็บ
  • ใช้จำนวนเวิร์กเกอร์แบบปรับตัว (CI: สูงสุด 2, ภายในเครื่อง: ค่าเริ่มต้น 1)
  • ทำงานในโหมดเงียบโดยค่าเริ่มต้น เพื่อลดค่าใช้จ่ายส่วนเกินของ I/O คอนโซล
• การแทนค่าที่มีประโยชน์:
  • OPENCLAW_E2E_WORKERS=<n> เพื่อบังคับจำนวนเวิร์กเกอร์ (จำกัดสูงสุดที่ 16)
  • OPENCLAW_E2E_VERBOSE=1 เพื่อเปิดใช้เอาต์พุตคอนโซลแบบละเอียดอีกครั้ง
• ขอบเขต:
  • พฤติกรรมแบบครบวงจรของ Gateway หลายอินสแตนซ์
  • พื้นผิว WebSocket/HTTP การจับคู่ Node และเครือข่ายที่หนักขึ้น
• ความคาดหวัง:
  • ทำงานใน CI (เมื่อเปิดใช้ในไปป์ไลน์)
  • ไม่ต้องใช้คีย์จริง
  • มีองค์ประกอบที่เคลื่อนไหวมากกว่าการทดสอบหน่วย (อาจช้ากว่า)

E2E (เบราว์เซอร์ Control UI แบบจำลอง)

• คำสั่ง: pnpm test:ui:e2e
• การกำหนดค่า: test/vitest/vitest.ui-e2e.config.ts
• ไฟล์: ui/src/**/*.e2e.test.ts
• ขอบเขต:
  • เริ่ม Vite Control UI
  • ขับเคลื่อนหน้า Chromium จริงผ่าน Playwright
  • แทนที่ WebSocket ของ Gateway ด้วยวัตถุจำลองในเบราว์เซอร์ที่ให้ผลลัพธ์แน่นอน
• ความคาดหวัง:
  • ทำงานใน CI เป็นส่วนหนึ่งของ pnpm test:e2e
  • ไม่ต้องใช้ Gateway จริง เอเจนต์ หรือคีย์ผู้ให้บริการ
  • ต้องมีการขึ้นต่อกันของเบราว์เซอร์ (pnpm --dir ui exec playwright install chromium)

E2E: การทดสอบควันของแบ็กเอนด์ OpenShell

• คำสั่ง: pnpm test:e2e:openshell
• ไฟล์: extensions/openshell/src/backend.e2e.test.ts
• ขอบเขต:
  • ใช้ OpenShell Gateway ภายในเครื่องที่กำลังทำงานอยู่ซ้ำ
  • สร้างแซนด์บ็อกซ์จาก Dockerfile ชั่วคราวภายในเครื่อง
  • ทดสอบแบ็กเอนด์ OpenShell ของ OpenClaw ผ่าน sandbox ssh-config จริง + การเรียกใช้ SSH
  • ตรวจสอบพฤติกรรมระบบไฟล์ที่ยึดฝั่งรีโมตเป็นมาตรฐานผ่านบริดจ์ fs ของแซนด์บ็อกซ์
• ความคาดหวัง:
  • ต้องเลือกเข้าร่วมเท่านั้น ไม่เป็นส่วนหนึ่งของการรัน pnpm test:e2e เริ่มต้น
  • ต้องมี CLI openshell ภายในเครื่องและดีมอน Docker ที่ทำงานได้
  • ต้องมี OpenShell Gateway ภายในเครื่องที่กำลังทำงานอยู่และแหล่งการกำหนดค่าของมัน
  • ใช้ HOME / XDG_CONFIG_HOME แบบแยก จากนั้นทำลายแซนด์บ็อกซ์ทดสอบ
• การแทนค่าที่มีประโยชน์:
  • OPENCLAW_E2E_OPENSHELL=1 เพื่อเปิดใช้การทดสอบเมื่อเรียกใช้ชุด e2e ที่กว้างขึ้นด้วยตนเอง
  • OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell เพื่อชี้ไปยังไบนารี CLI หรือสคริปต์ตัวห่อหุ้มที่ไม่ใช่ค่าเริ่มต้น
  • OPENCLAW_E2E_OPENSHELL_CONFIG_HOME=/path/to/config เพื่อเปิดเผยการกำหนดค่า Gateway ที่ลงทะเบียนไว้ให้แก่การทดสอบแบบแยก
  • OPENCLAW_E2E_OPENSHELL_HOST_IP=172.18.0.1 เพื่อแทนที่ IP ของ Gateway Docker ที่ฟิกซ์เจอร์นโยบายโฮสต์ใช้

แบบใช้งานจริง (ผู้ให้บริการจริง + โมเดลจริง)

• คำสั่ง: pnpm test:live
• การกำหนดค่า: test/vitest/vitest.live.config.ts
• ไฟล์: src/**/*.live.test.ts, test/**/*.live.test.ts และการทดสอบจริงของ Plugin ที่รวมมาให้ภายใต้ extensions/
• ค่าเริ่มต้น: เปิดใช้งาน โดย pnpm test:live (ตั้งค่า OPENCLAW_LIVE_TEST=1)
• ขอบเขต:
  • "ผู้ให้บริการ/โมเดลนี้ใช้งานได้จริง ในวันนี้ ด้วยข้อมูลรับรองจริงหรือไม่?"
  • ตรวจจับการเปลี่ยนแปลงรูปแบบของผู้ให้บริการ ลักษณะเฉพาะของการเรียกใช้เครื่องมือ ปัญหาการยืนยันตัวตน และพฤติกรรมการจำกัดอัตรา
• สิ่งที่คาดหมาย:
  • ออกแบบมาให้ไม่มีเสถียรภาพระดับ CI (เครือข่ายจริง นโยบายจริงของผู้ให้บริการ โควตา และเหตุขัดข้อง)
  • มีค่าใช้จ่าย / ใช้โควตาการจำกัดอัตรา
  • ควรรันเฉพาะชุดย่อยที่จำกัดขอบเขต แทนการรัน "ทุกอย่าง"
• การรันจริงใช้คีย์ API ที่ส่งออกไว้แล้วและโปรไฟล์การยืนยันตัวตนที่จัดเตรียมไว้
• ตามค่าเริ่มต้น การรันจริงยังคงแยก HOME และคัดลอกข้อมูลการกำหนดค่า/การยืนยันตัวตนไปยังโฮมทดสอบชั่วคราว เพื่อไม่ให้ฟิกซ์เจอร์ของการทดสอบหน่วยแก้ไข ~/.openclaw จริงของคุณ
• ตั้งค่า OPENCLAW_LIVE_USE_REAL_HOME=1 เฉพาะเมื่อคุณต้องการให้การทดสอบจริงใช้ไดเรกทอรีโฮมจริงของคุณโดยเจตนา
• pnpm test:live ใช้โหมดที่เงียบกว่าเป็นค่าเริ่มต้น โดยยังคงแสดงผลความคืบหน้า [live] ... และปิดเสียงบันทึกการเริ่มต้น Gateway/ข้อความจาก Bonjour ตั้งค่า OPENCLAW_LIVE_TEST_QUIET=0 หากต้องการให้แสดงบันทึกการเริ่มต้นทั้งหมดอีกครั้ง
• การหมุนเวียนคีย์ API (เฉพาะผู้ให้บริการ): ตั้งค่า *_API_KEYS ในรูปแบบคั่นด้วยจุลภาค/อัฒภาค หรือ *_API_KEY_1, *_API_KEY_2 (ตัวอย่างเช่น OPENAI_API_KEYS, ANTHROPIC_API_KEYS, GEMINI_API_KEYS) หรือแทนที่เฉพาะการทดสอบจริงผ่าน OPENCLAW_LIVE_*_KEY; การทดสอบจะลองใหม่เมื่อได้รับการตอบกลับว่าถูกจำกัดอัตรา
• ผลลัพธ์ความคืบหน้า/Heartbeat:
  • ชุดการทดสอบจริงส่งบรรทัดความคืบหน้าไปยัง stderr เพื่อให้เห็นว่ายังทำงานอยู่ระหว่างการเรียกผู้ให้บริการที่ใช้เวลานาน แม้การดักจับคอนโซลของ Vitest จะอยู่ในโหมดเงียบ
  • test/vitest/vitest.live.config.ts ปิดการดักจับคอนโซลของ Vitest เพื่อให้บรรทัดความคืบหน้าของผู้ให้บริการ/Gateway แสดงแบบสตรีมทันทีระหว่างการรันจริง
  • ปรับ Heartbeat ของโมเดลโดยตรงด้วย OPENCLAW_LIVE_HEARTBEAT_MS
  • ปรับ Heartbeat ของ Gateway/โพรบด้วย OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS

ฉันควรรันชุดการทดสอบใด?

ใช้ตารางการตัดสินใจนี้:

• แก้ไขตรรกะ/การทดสอบ: รัน pnpm test (และ pnpm test:coverage หากคุณเปลี่ยนแปลงหลายส่วน)
• แก้ไขเครือข่ายของ Gateway / โปรโตคอล WS / การจับคู่: เพิ่ม pnpm test:e2e
• ดีบัก "บอตของฉันใช้งานไม่ได้" / ความล้มเหลวเฉพาะผู้ให้บริการ / การเรียกใช้เครื่องมือ: รัน pnpm test:live โดยจำกัดขอบเขต

การทดสอบจริง (ที่ติดต่อเครือข่าย)

สำหรับเมทริกซ์โมเดลจริง การตรวจสอบเบื้องต้นของแบ็กเอนด์ CLI การตรวจสอบเบื้องต้นของ ACP ชุดควบคุมเซิร์ฟเวอร์แอป Codex และการทดสอบจริงของผู้ให้บริการสื่อทั้งหมด (Deepgram, BytePlus, ComfyUI รูปภาพ เพลง วิดีโอ และชุดควบคุมสื่อ) รวมถึงการจัดการข้อมูลรับรองสำหรับการรันจริง

• ดู การทดสอบชุดการทดสอบจริง สำหรับรายการตรวจสอบเฉพาะด้านการอัปเดตและการตรวจสอบ Plugin โปรดดู การทดสอบการอัปเดตและ Plugin

ตัวรัน Docker (การตรวจสอบ "ทำงานได้บน Linux" ซึ่งเป็นทางเลือก)

ตัวรัน Docker เหล่านี้แบ่งเป็นสองกลุ่ม:

• ตัวรันโมเดลจริง: test:docker:live-models และ test:docker:live-gateway จะรันเฉพาะไฟล์จริงที่ใช้คีย์โปรไฟล์ซึ่งตรงกันภายในอิมเมจ Docker ของรีโพ (src/agents/models.profiles.live.test.ts และ src/gateway/gateway-models.profiles.live.test.ts) โดยเมานต์ไดเรกทอรีการกำหนดค่าภายในเครื่อง พื้นที่ทำงาน และไฟล์สภาพแวดล้อมของโปรไฟล์ที่เป็นทางเลือก จุดเริ่มต้นภายในเครื่องที่ตรงกันคือ test:live:models-profiles และ test:live:gateway-profiles
• ตัวรันจริงของ Docker ยังคงใช้ขีดจำกัดเชิงปฏิบัติของตนเองในจุดที่จำเป็น: test:docker:live-models ใช้ชุดโมเดลที่รองรับและคัดสรรมาให้สัญญาณสูงเป็นค่าเริ่มต้น และ test:docker:live-gateway ใช้ค่าเริ่มต้นเป็น OPENCLAW_LIVE_GATEWAY_SMOKE=1, OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8, OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000 และ OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000 ตั้งค่า OPENCLAW_LIVE_MAX_MODELS หรือตัวแปรสภาพแวดล้อมของ Gateway เมื่อคุณต้องการขีดจำกัดที่เล็กลงหรือการสแกนที่กว้างขึ้นโดยชัดเจน
• test:docker:all สร้างอิมเมจ Docker สำหรับการทดสอบจริงหนึ่งครั้งผ่าน test:docker:live-build แพ็ก OpenClaw หนึ่งครั้งเป็น tarball ของ npm ผ่าน scripts/package-openclaw-for-docker.mjs จากนั้นสร้าง/นำอิมเมจ scripts/e2e/Dockerfile สองอิมเมจกลับมาใช้ใหม่ อิมเมจพื้นฐานเป็นเพียงตัวรัน Node/Git สำหรับช่องทางการติดตั้ง/อัปเดต/การขึ้นต่อกันของ Plugin โดยช่องทางเหล่านั้นจะเมานต์ tarball ที่สร้างไว้ล่วงหน้า อิมเมจเชิงฟังก์ชันจะติดตั้ง tarball เดียวกันลงใน /app สำหรับช่องทางการทำงานของแอปที่สร้างแล้ว คำจำกัดความช่องทาง Docker อยู่ใน scripts/lib/docker-e2e-scenarios.mjs; ตรรกะตัววางแผนอยู่ใน scripts/lib/docker-e2e-plan.mjs; scripts/test-docker-all.mjs เรียกใช้แผนที่เลือก ตัวรวมใช้ตัวจัดตารางภายในเครื่องแบบถ่วงน้ำหนัก: OPENCLAW_DOCKER_ALL_PARALLELISM ควบคุมช่องกระบวนการ ขณะที่ขีดจำกัดทรัพยากรป้องกันไม่ให้ช่องทางการทดสอบจริงที่หนัก การติดตั้ง npm และบริการหลายตัวเริ่มพร้อมกันทั้งหมด หากช่องทางใดช่องทางหนึ่งหนักกว่าขีดจำกัดที่ใช้งานอยู่ ตัวจัดตารางยังคงสามารถเริ่มช่องทางนั้นได้เมื่อพูลว่าง แล้วปล่อยให้ทำงานเพียงลำพังจนกว่าจะมีความจุอีกครั้ง ค่าเริ่มต้นคือ 10 ช่อง, OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9, OPENCLAW_DOCKER_ALL_NPM_LIMIT=5 และ OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7; ปรับ OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT หรือ OPENCLAW_DOCKER_ALL_DOCKER_LIMIT (รวมถึงการแทนที่ OPENCLAW_DOCKER_ALL_<RESOURCE>_LIMIT อื่น ๆ) เฉพาะเมื่อโฮสต์ Docker มีทรัพยากรสำรองมากขึ้น ตัวรันดำเนินการตรวจสอบ Docker ล่วงหน้าตามค่าเริ่มต้น ลบคอนเทนเนอร์ E2E ของ OpenClaw ที่ค้างอยู่ แสดงสถานะทุก 30 วินาที จัดเก็บเวลาของช่องทางที่สำเร็จไว้ใน .artifacts/docker-tests/lane-timings.json และใช้เวลาเหล่านั้นเพื่อเริ่มช่องทางที่ใช้เวลานานกว่าก่อนในการรันครั้งต่อไป ใช้ OPENCLAW_DOCKER_ALL_DRY_RUN=1 เพื่อแสดงรายการช่องทางแบบถ่วงน้ำหนักโดยไม่สร้างหรือรัน Docker หรือใช้ node scripts/test-docker-all.mjs --plan-json เพื่อแสดงแผน CI สำหรับช่องทางที่เลือก ความต้องการแพ็กเกจ/อิมเมจ และข้อมูลรับรอง
• Package Acceptance เป็นเกตแพ็กเกจที่ทำงานโดยตรงบน GitHub สำหรับตรวจสอบว่า "tarball ที่ติดตั้งได้นี้ทำงานเป็นผลิตภัณฑ์หรือไม่?" โดยจะเลือกแพ็กเกจ候选หนึ่งรายการจาก source=npm, source=ref, source=url, source=trusted-url หรือ source=artifact อัปโหลดเป็น package-under-test จากนั้นรันช่องทาง Docker E2E ที่นำกลับมาใช้ใหม่ได้กับ tarball นั้นโดยตรง แทนการแพ็ก ref ที่เลือกใหม่ โปรไฟล์เรียงตามความครอบคลุม ได้แก่ smoke, package, product และ full (รวมถึง custom สำหรับรายการช่องทางที่ระบุอย่างชัดเจน) ดู การทดสอบการอัปเดตและ Plugin สำหรับสัญญาของแพ็กเกจ/การอัปเดต/Plugin เมทริกซ์การอยู่รอดหลังอัปเกรดเวอร์ชันที่เผยแพร่ ค่าเริ่มต้นของรีลีส และการคัดแยกความล้มเหลว
• การตรวจสอบการสร้างและรีลีสจะรัน scripts/check-cli-bootstrap-imports.mjs หลังจาก tsdown ตัวป้องกันจะไล่กราฟบิลด์แบบสแตติกจาก dist/entry.js และ dist/cli/run-main.js และล้มเหลวหากกราฟเริ่มต้นก่อนส่งต่อคำสั่งนั้นนำเข้าแพ็กเกจภายนอกแบบสแตติก (Commander, UI พร้อมท์, undici, การบันทึก และการขึ้นต่อกันอื่นที่ทำให้การเริ่มต้นหนักล้วนถูกนับ) ก่อนส่งต่อคำสั่ง นอกจากนี้ยังจำกัดส่วนบันเดิลสำหรับรัน Gateway ไว้ที่ 70 KB และปฏิเสธการนำเข้าแบบสแตติกของเส้นทาง Gateway ที่ทราบว่าใช้งานภายหลัง (control-ui-assets, diagnostic-stability-bundle, onboard-helpers, process-respawn, restart-sentinel, server-close, server-reload-handlers) จากส่วนนั้น scripts/release-check.ts จะแยกตรวจสอบเบื้องต้นของ CLI ที่แพ็กแล้วด้วย --help, onboard --help, doctor --help, status --json --timeout 1, config schema และ models list --provider openai
• ความเข้ากันได้กับระบบเดิมของ Package Acceptance จำกัดไว้ที่ 2026.4.25 (รวม 2026.4.25-beta.*) จนถึงจุดตัดดังกล่าว ชุดควบคุมจะยอมรับเฉพาะช่องว่างของเมทาดาทาในแพ็กเกจที่เผยแพร่แล้ว ได้แก่ รายการคลัง QA ส่วนตัวที่ถูกละไว้, ไม่มี gateway install --wrapper, ไม่มีไฟล์แพตช์ในฟิกซ์เจอร์ Git ที่สร้างจาก tarball, ไม่มี update.channel ที่คงอยู่, ตำแหน่งบันทึกการติดตั้ง Plugin แบบเดิม, ไม่มีการคงอยู่ของบันทึกการติดตั้งจากมาร์เก็ตเพลส และการย้ายเมทาดาทาการกำหนดค่าระหว่าง plugins update สำหรับแพ็กเกจหลัง 2026.4.25 เส้นทางเหล่านี้จะถือเป็นความล้มเหลวอย่างเคร่งครัด
• ตัวรันตรวจสอบเบื้องต้นของคอนเทนเนอร์: test:docker:openwebui, test:docker:onboard, test:docker:npm-onboard-channel-agent, test:docker:release-user-journey, test:docker:release-typed-onboarding, test:docker:release-media-memory, test:docker:release-upgrade-user-journey, test:docker:release-plugin-marketplace, test:docker:skill-install, test:docker:update-channel-switch, test:docker:upgrade-survivor, test:docker:published-upgrade-survivor, test:docker:session-runtime-context, test:docker:agents-delete-shared-workspace, test:docker:gateway-network, test:docker:browser-cdp-snapshot, test:docker:mcp-channels, test:docker:agent-bundle-mcp-tools, test:docker:cron-mcp-cleanup, test:docker:plugins, test:docker:plugin-update, test:docker:plugin-lifecycle-matrix และ test:docker:config-reload จะบูตคอนเทนเนอร์จริงอย่างน้อยหนึ่งตัวและตรวจสอบเส้นทางการผสานรวมระดับสูง
• ช่องทาง Docker/Bash E2E ที่ติดตั้ง tarball ของ OpenClaw ที่แพ็กแล้วผ่าน scripts/lib/openclaw-e2e-instance.sh จำกัดเวลา npm install ด้วย OPENCLAW_E2E_NPM_INSTALL_TIMEOUT (ค่าเริ่มต้น 600s; ตั้งเป็น 0 เพื่อปิดตัวครอบสำหรับการดีบัก)

ตัวรัน Docker สำหรับโมเดลจริงยัง bind-mount เฉพาะโฮมการยืนยันตัวตนของ CLI ที่จำเป็น (หรือทั้งหมดที่รองรับเมื่อไม่ได้จำกัดขอบเขตการรัน) จากนั้นคัดลอกไปยังโฮมของ คอนเทนเนอร์ก่อนรัน เพื่อให้ OAuth ของ CLI ภายนอกรีเฟรชโทเค็นได้ โดยไม่แก้ไขที่เก็บการยืนยันตัวตนบนโฮสต์:

• โมเดลโดยตรง: pnpm test:docker:live-models (สคริปต์: scripts/test-live-models-docker.sh)

• การตรวจสอบการผูก ACP เบื้องต้น: pnpm test:docker:live-acp-bind (สคริปต์: scripts/test-live-acp-bind-docker.sh; ครอบคลุม Claude, Codex และ Gemini เป็นค่าเริ่มต้น พร้อมความครอบคลุม Droid/OpenCode แบบเข้มงวดผ่าน pnpm test:docker:live-acp-bind:droid และ pnpm test:docker:live-acp-bind:opencode)

• การตรวจสอบแบ็กเอนด์ CLI เบื้องต้น: pnpm test:docker:live-cli-backend (สคริปต์: scripts/test-live-cli-backend-docker.sh)

• การตรวจสอบชุดควบคุมเซิร์ฟเวอร์แอป Codex เบื้องต้น: pnpm test:docker:live-codex-harness (สคริปต์: scripts/test-live-codex-harness-docker.sh)

• Gateway + เอเจนต์สำหรับการพัฒนา: pnpm test:docker:live-gateway (สคริปต์: scripts/test-live-gateway-models-docker.sh)

• การตรวจสอบความสามารถในการสังเกตการณ์เบื้องต้น: pnpm qa:otel:smoke, pnpm qa:prometheus:smoke และ pnpm qa:observability:smoke เป็นช่องทาง QA ส่วนตัวสำหรับเช็กเอาต์ซอร์ส โดยตั้งใจไม่รวมไว้ในช่องทางรีลีส Docker ของแพ็กเกจ เนื่องจาก tarball ของ npm ไม่รวม QA Lab

• การตรวจสอบจริงของ Open WebUI เบื้องต้น: pnpm test:docker:openwebui (สคริปต์: scripts/e2e/openwebui-docker.sh)

• ตัวช่วยเริ่มต้นใช้งาน (TTY, การจัดโครงสร้างครบถ้วน): pnpm test:docker:onboard (สคริปต์: scripts/e2e/onboard-docker.sh)

• การตรวจสอบการเริ่มต้นใช้งาน/ช่องทาง/เอเจนต์ของ tarball npm เบื้องต้น: pnpm test:docker:npm-onboard-channel-agent ติดตั้ง tarball ของ OpenClaw ที่แพ็กแล้วแบบส่วนกลางใน Docker กำหนดค่า OpenAI ผ่านการเริ่มต้นใช้งานที่อ้างอิงตัวแปรสภาพแวดล้อมพร้อม Telegram เป็นค่าเริ่มต้น รัน doctor และรันเอเจนต์ OpenAI จำลองหนึ่งรอบ ใช้ tarball ที่สร้างไว้ล่วงหน้าซ้ำด้วย OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz ข้ามการสร้างใหม่บนโฮสต์ด้วย OPENCLAW_NPM_ONBOARD_HOST_BUILD=0 หรือเปลี่ยนช่องทางด้วย OPENCLAW_NPM_ONBOARD_CHANNEL=discord หรือ OPENCLAW_NPM_ONBOARD_CHANNEL=slack

• การทดสอบควันเส้นทางผู้ใช้รุ่นเผยแพร่: pnpm test:docker:release-user-journey ติดตั้ง tarball ของ OpenClaw ที่แพ็กแล้วแบบส่วนกลางในโฮม Docker ที่สะอาด เรียกใช้การเริ่มต้นใช้งาน กำหนดค่าผู้ให้บริการ OpenAI จำลอง เรียกใช้หนึ่งรอบของเอเจนต์ ติดตั้ง/ถอนการติดตั้ง Plugin ภายนอก กำหนดค่า ClickClack กับฟิกซ์เจอร์ภายในเครื่อง ตรวจสอบการส่งข้อความขาออก/ขาเข้า รีสตาร์ต Gateway และเรียกใช้ doctor

• การทดสอบควันการเริ่มต้นใช้งานแบบมีชนิดสำหรับรุ่นเผยแพร่: pnpm test:docker:release-typed-onboarding ติดตั้ง tarball ที่แพ็กแล้ว ควบคุม openclaw onboard ผ่าน TTY จริง กำหนดค่า OpenAI เป็นผู้ให้บริการแบบอ้างอิงตัวแปรสภาพแวดล้อม ตรวจสอบว่าไม่มีการเก็บคีย์ดิบอย่างถาวร และเรียกใช้หนึ่งรอบของเอเจนต์จำลอง

• การทดสอบควันสื่อ/หน่วยความจำสำหรับรุ่นเผยแพร่: pnpm test:docker:release-media-memory ติดตั้ง tarball ที่แพ็กแล้ว ตรวจสอบความเข้าใจรูปภาพจากไฟล์แนบ PNG ผลลัพธ์การสร้างรูปภาพที่เข้ากันได้กับ OpenAI การเรียกคืนจากการค้นหาหน่วยความจำ และการคงอยู่ของความสามารถในการเรียกคืนหลังรีสตาร์ต Gateway

• การทดสอบควันเส้นทางผู้ใช้อัปเกรดรุ่นเผยแพร่: pnpm test:docker:release-upgrade-user-journey โดยค่าเริ่มต้นจะติดตั้งรุ่นฐานที่เผยแพร่ล่าสุดซึ่งเก่ากว่า tarball รุ่นทดสอบ กำหนดค่าสถานะผู้ให้บริการ/Plugin/ClickClack บนแพ็กเกจที่เผยแพร่ อัปเกรดเป็น tarball รุ่นทดสอบ แล้วเรียกใช้เส้นทางหลักของเอเจนต์/Plugin/ช่องทางซ้ำ หากไม่มีรุ่นฐานที่เผยแพร่ซึ่งเก่ากว่า จะใช้เวอร์ชันรุ่นทดสอบซ้ำ กำหนดรุ่นฐานเองด้วย OPENCLAW_RELEASE_UPGRADE_BASELINE_SPEC=openclaw@<version>

• การทดสอบควันมาร์เก็ตเพลส Plugin สำหรับรุ่นเผยแพร่: pnpm test:docker:release-plugin-marketplace ติดตั้งจากฟิกซ์เจอร์มาร์เก็ตเพลสภายในเครื่อง อัปเดต Plugin ที่ติดตั้ง ถอนการติดตั้ง และตรวจสอบว่า CLI ของ Plugin หายไปพร้อมกับข้อมูลเมตาการติดตั้งที่ถูกตัดออก

• การทดสอบควันการติดตั้ง Skill: pnpm test:docker:skill-install ติดตั้ง tarball ของ OpenClaw ที่แพ็กแล้วแบบส่วนกลางใน Docker ปิดใช้งานการติดตั้งอาร์ไคฟ์ที่อัปโหลดในการกำหนดค่า แก้ค่า slug ของ skill สดปัจจุบันจากการค้นหาใน ClawHub ติดตั้งด้วย openclaw skills install และตรวจสอบ skill ที่ติดตั้งพร้อมข้อมูลเมตาต้นทาง/ล็อก .clawhub

• การทดสอบควันการสลับช่องทางอัปเดต: pnpm test:docker:update-channel-switch ติดตั้ง tarball ของ OpenClaw ที่แพ็กแล้วแบบส่วนกลางใน Docker สลับจากแพ็กเกจ stable ไปเป็น git dev ตรวจสอบช่องทางที่เก็บไว้อย่างถาวรและการทำงานของ Plugin หลังอัปเดต จากนั้นสลับกลับไปเป็นแพ็กเกจ stable และตรวจสอบสถานะการอัปเดต

• การทดสอบควันความอยู่รอดหลังอัปเกรด: pnpm test:docker:upgrade-survivor ติดตั้ง tarball ของ OpenClaw ที่แพ็กแล้วทับฟิกซ์เจอร์ผู้ใช้เก่าที่มีสถานะไม่สะอาด ซึ่งมีเอเจนต์ การกำหนดค่าช่องทาง รายการอนุญาตของ Plugin สถานะการพึ่งพาของ Plugin ที่ล้าสมัย และไฟล์เวิร์กสเปซ/เซสชันที่มีอยู่ การทดสอบจะเรียกใช้การอัปเดตแพ็กเกจพร้อม doctor แบบไม่โต้ตอบโดยไม่มีคีย์ผู้ให้บริการหรือช่องทางจริง จากนั้นเริ่ม Gateway บน local loopback และตรวจสอบการคงอยู่ของการกำหนดค่า/สถานะ รวมถึงงบเวลาการเริ่มทำงาน/สถานะ

• การทดสอบควันความอยู่รอดหลังอัปเกรดจากรุ่นที่เผยแพร่: pnpm test:docker:published-upgrade-survivor โดยค่าเริ่มต้นจะติดตั้ง openclaw@latest เติมไฟล์ผู้ใช้เดิมที่สมจริง กำหนดค่ารุ่นฐานนั้นด้วยชุดคำสั่งที่ฝังไว้ ตรวจสอบความถูกต้องของการกำหนดค่าที่ได้ อัปเดตการติดตั้งรุ่นที่เผยแพร่นั้นเป็น tarball รุ่นทดสอบ เรียกใช้ doctor แบบไม่โต้ตอบ เขียน .artifacts/upgrade-survivor/summary.json จากนั้นเริ่ม Gateway บน local loopback และตรวจสอบเจตนาที่กำหนดค่าไว้ การคงอยู่ของสถานะ การเริ่มทำงาน /healthz, /readyz และงบเวลาสถานะ RPC กำหนดรุ่นฐานหนึ่งรายการเองด้วย OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC สั่งให้ตัวจัดตารางแบบรวมขยายรุ่นฐานภายในเครื่องที่ระบุแน่นอนด้วย OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS เช่น openclaw@2026.5.2 openclaw@2026.4.23 openclaw@2026.4.15 และขยายฟิกซ์เจอร์ที่จำลองรูปแบบปัญหาด้วย OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS เช่น reported-issues; ชุดปัญหาที่รายงานมี configured-plugin-installs สำหรับการซ่อมแซมการติดตั้ง Plugin ภายนอกของ OpenClaw โดยอัตโนมัติ การยอมรับแพ็กเกจเปิดเผยค่าเหล่านี้เป็น published_upgrade_survivor_baseline, published_upgrade_survivor_baselines และ published_upgrade_survivor_scenarios แก้ค่าโทเค็นรุ่นฐานเชิงเมตา เช่น last-stable-4 หรือ all-since-2026.4.23 และการตรวจสอบความถูกต้องของรุ่นเผยแพร่เต็มรูปแบบจะขยายเกตแพ็กเกจทดสอบความทนทานของรุ่นเผยแพร่เป็น last-stable-4 2026.4.23 2026.5.2 2026.4.15 พร้อม reported-issues

• การทดสอบควันบริบทรันไทม์ของเซสชัน: pnpm test:docker:session-runtime-context ตรวจสอบการเก็บทรานสคริปต์บริบทรันไทม์ที่ซ่อนไว้อย่างถาวร พร้อมการซ่อมแซมด้วย doctor สำหรับแขนงการเขียนพรอมป์ใหม่ที่ซ้ำกันและได้รับผลกระทบ

• การทดสอบควันการติดตั้งส่วนกลางด้วย Bun: bash scripts/e2e/bun-global-install-smoke.sh แพ็กโครงสร้างปัจจุบัน ติดตั้งด้วย bun install -g ในโฮมที่แยกออกมา และตรวจสอบว่า openclaw infer image providers --json คืนค่าผู้ให้บริการรูปภาพที่รวมมาให้แทนที่จะค้าง ใช้ tarball ที่สร้างไว้ล่วงหน้าซ้ำด้วย OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz ข้ามการสร้างบนโฮสต์ด้วย OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0 หรือคัดลอก dist/ จากอิมเมจ Docker ที่สร้างแล้วด้วย OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local

• การทดสอบควันตัวติดตั้งใน Docker: bash scripts/test-install-sh-docker.sh ใช้แคช npm หนึ่งชุดร่วมกันระหว่างคอนเทนเนอร์ root, update และ direct-npm โดยค่าเริ่มต้น การทดสอบควันการอัปเดตจะใช้ npm latest เป็นรุ่นฐานเสถียรก่อนอัปเกรดเป็น tarball รุ่นทดสอบ กำหนดเองภายในเครื่องด้วย OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22 หรือใช้ข้อมูลนำเข้า update_baseline_version ของเวิร์กโฟลว์ Install Smoke บน GitHub การตรวจสอบตัวติดตั้งที่ไม่ใช่ root จะใช้แคช npm ที่แยกออกมา เพื่อไม่ให้รายการแคชที่ root เป็นเจ้าของบดบังพฤติกรรมการติดตั้งภายในของผู้ใช้ ตั้งค่า OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache เพื่อใช้แคช root/update/direct-npm ซ้ำในการเรียกใช้ภายในเครื่องครั้งต่อไป

• CI ของ Install Smoke ข้ามการอัปเดตส่วนกลางผ่าน direct-npm ที่ซ้ำกันด้วย OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1; เรียกใช้สคริปต์ภายในเครื่องโดยไม่มีตัวแปรสภาพแวดล้อมนี้เมื่อต้องการความครอบคลุมของ npm install -g โดยตรง

• การทดสอบควัน CLI สำหรับเอเจนต์ที่ลบเวิร์กสเปซร่วม: pnpm test:docker:agents-delete-shared-workspace (สคริปต์: scripts/e2e/agents-delete-shared-workspace-docker.sh) โดยค่าเริ่มต้นจะสร้างอิมเมจจาก Dockerfile ราก เติมเอเจนต์สองตัวที่ใช้เวิร์กสเปซเดียวกันในโฮมคอนเทนเนอร์ที่แยกออกมา เรียกใช้ agents delete --json และตรวจสอบ JSON ที่ถูกต้องพร้อมพฤติกรรมการเก็บเวิร์กสเปซไว้ ใช้อิมเมจ install-smoke ซ้ำด้วย OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1

• เครือข่าย Gateway และวงจรชีวิตโฮสต์: pnpm test:docker:gateway-network (สคริปต์: scripts/e2e/gateway-network-docker.sh) คงการทดสอบควันการตรวจสอบสิทธิ์/สุขภาพ WebSocket ผ่าน LAN แบบสองคอนเทนเนอร์ไว้ จากนั้นใช้ Admin HTTP ผ่าน local loopback เพื่อพิสูจน์การกั้นระหว่างการเตรียม การเข้าถึงการควบคุมที่คงไว้ การกู้คืนด้วยการทำงานต่อ และการหยุด/เริ่มที่เตรียมไว้ภายในคอนเทนเนอร์เดียวกัน การตรวจสอบการรีสตาร์ตต้องเสร็จก่อนสัญญาเช่าเดิมหมดอายุ ตรวจสอบว่าสถานะการระงับเป็นสถานะภายในกระบวนการ ขณะที่การกำหนดค่า Gateway ที่เก็บถาวรและอัตลักษณ์คอนเทนเนอร์ยังคงอยู่ และส่งออก JSON เวลาของแต่ละระยะที่เครื่องอ่านได้

• การทดสอบควันสแนปช็อต CDP ของเบราว์เซอร์: pnpm test:docker:browser-cdp-snapshot (สคริปต์: scripts/e2e/browser-cdp-snapshot-docker.sh) สร้างอิมเมจ E2E จากซอร์สพร้อมเลเยอร์ Chromium เริ่ม Chromium ด้วย CDP ดิบ เรียกใช้ browser doctor --deep และตรวจสอบว่าสแนปช็อตบทบาท CDP ครอบคลุม URL ของลิงก์ องค์ประกอบที่คลิกได้ซึ่งเลื่อนระดับจากเคอร์เซอร์ การอ้างอิง iframe และข้อมูลเมตาเฟรม

• การทดสอบการถดถอยของ OpenAI Responses web_search ด้วยการใช้เหตุผลขั้นต่ำ: pnpm test:docker:openai-web-search-minimal (สคริปต์: scripts/e2e/openai-web-search-minimal-docker.sh) เรียกใช้เซิร์ฟเวอร์ OpenAI จำลองผ่าน Gateway ตรวจสอบว่า web_search ยกระดับ reasoning.effort จาก minimal เป็น low จากนั้นบังคับให้สคีมาของผู้ให้บริการปฏิเสธและตรวจสอบว่ารายละเอียดดิบปรากฏในบันทึก Gateway

• บริดจ์ช่องทาง MCP (Gateway ที่เติมข้อมูลแล้ว + บริดจ์ stdio + การทดสอบควันเฟรมการแจ้งเตือน Claude ดิบ): pnpm test:docker:mcp-channels (สคริปต์: scripts/e2e/mcp-channels-docker.sh)

• เครื่องมือ MCP ของบันเดิล OpenClaw (เซิร์ฟเวอร์ MCP แบบ stdio จริง + การทดสอบควันรายการอนุญาต/ปฏิเสธของโปรไฟล์ OpenClaw แบบฝัง): pnpm test:docker:agent-bundle-mcp-tools (สคริปต์: scripts/e2e/agent-bundle-mcp-tools-docker.sh)

• การล้าง MCP ของ Cron/เอเจนต์ย่อย (Gateway จริง + การยุติโพรเซสลูก MCP แบบ stdio หลังการเรียกใช้ Cron ที่แยกออกมาและเอเจนต์ย่อยแบบครั้งเดียว): pnpm test:docker:cron-mcp-cleanup (สคริปต์: scripts/e2e/cron-mcp-cleanup-docker.sh)

• Plugin (การทดสอบควันการติดตั้ง/อัปเดตสำหรับพาธภายในเครื่อง, file:, รีจิสทรี npm ที่มีการยกระดับการพึ่งพา ข้อมูลเมตาแพ็กเกจ npm ที่ผิดรูป การอ้างอิง git ที่เคลื่อนที่ได้ ชุดทดสอบครอบคลุมของ ClawHub การอัปเดตมาร์เก็ตเพลส และการเปิดใช้/ตรวจสอบบันเดิล Claude): pnpm test:docker:plugins (สคริปต์: scripts/e2e/plugins-docker.sh) ตั้งค่า OPENCLAW_PLUGINS_E2E_CLAWHUB=0 เพื่อข้ามบล็อก ClawHub หรือกำหนดคู่แพ็กเกจ/รันไทม์ชุดทดสอบครอบคลุมเริ่มต้นเองด้วย OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC และ OPENCLAW_PLUGINS_E2E_CLAWHUB_ID หากไม่มี OPENCLAW_CLAWHUB_URL/CLAWHUB_URL การทดสอบจะใช้เซิร์ฟเวอร์ฟิกซ์เจอร์ ClawHub ภายในเครื่องแบบปิดล้อม

• การทดสอบควันการอัปเดต Plugin ที่ไม่มีการเปลี่ยนแปลง: pnpm test:docker:plugin-update (สคริปต์: scripts/e2e/plugin-update-unchanged-docker.sh)

• การทดสอบควันเมทริกซ์วงจรชีวิต Plugin: pnpm test:docker:plugin-lifecycle-matrix ติดตั้ง tarball ของ OpenClaw ที่แพ็กแล้วในคอนเทนเนอร์เปล่า ติดตั้ง Plugin จาก npm สลับเปิด/ปิดใช้งาน อัปเกรดและดาวน์เกรดผ่านรีจิสทรี npm ภายในเครื่อง ลบโค้ดที่ติดตั้ง จากนั้นตรวจสอบว่าการถอนการติดตั้งยังคงลบสถานะเก่า พร้อมบันทึกเมตริก RSS/CPU สำหรับแต่ละระยะของวงจรชีวิต

• การทดสอบควันข้อมูลเมตาการโหลดการกำหนดค่าใหม่: pnpm test:docker:config-reload (สคริปต์: scripts/e2e/config-reload-source-docker.sh)

• Plugin: pnpm test:docker:plugins ครอบคลุมการทดสอบควันการติดตั้ง/อัปเดตสำหรับพาธภายในเครื่อง, file:, รีจิสทรี npm ที่มีการยกระดับการพึ่งพา การอ้างอิง git ที่เคลื่อนที่ได้ ฟิกซ์เจอร์ ClawHub การอัปเดตมาร์เก็ตเพลส และการเปิดใช้/ตรวจสอบบันเดิล Claude pnpm test:docker:plugin-update ครอบคลุมพฤติกรรมการอัปเดตที่ไม่มีการเปลี่ยนแปลงสำหรับ Plugin ที่ติดตั้งแล้ว pnpm test:docker:plugin-lifecycle-matrix ครอบคลุมการติดตั้ง เปิดใช้ ปิดใช้งาน อัปเกรด ดาวน์เกรด และถอนการติดตั้งเมื่อโค้ดหายไปของ Plugin จาก npm พร้อมติดตามทรัพยากร

หากต้องการสร้างล่วงหน้าและใช้อิมเมจฟังก์ชันร่วมซ้ำด้วยตนเอง:

OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker:e2e-buildOPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels

ค่ากำหนดอิมเมจเฉพาะชุดทดสอบ เช่น OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE ยังคงมีลำดับความสำคัญสูงกว่าเมื่อตั้งค่าไว้ เมื่อ OPENCLAW_SKIP_DOCKER_BUILD=1 ชี้ไปยังอิมเมจร่วมระยะไกล สคริปต์จะดึงอิมเมจนั้นหากยังไม่มีอยู่ภายในเครื่อง การทดสอบ QR และตัวติดตั้งใน Docker ยังคงใช้ Dockerfile ของตนเอง เพราะตรวจสอบพฤติกรรมแพ็กเกจ/การติดตั้ง ไม่ใช่รันไทม์แอปที่สร้างแล้วร่วมกัน

ตัวเรียกใช้ Docker สำหรับโมเดลจริงยังเมานต์ไดเรกทอรีทำงานปัจจุบันแบบอ่านอย่างเดียว และจัดเตรียมไว้ในไดเรกทอรีทำงานชั่วคราวภายในคอนเทนเนอร์ วิธีนี้ช่วยให้อิมเมจ รันไทม์มีขนาดเล็ก ขณะที่ยังเรียกใช้ Vitest กับซอร์ส/การกำหนดค่าภายในเครื่อง ที่ตรงกันทุกประการ ขั้นตอนการจัดเตรียมจะข้ามแคชขนาดใหญ่ที่มีเฉพาะในเครื่องและผลลัพธ์ การสร้างแอป เช่น .pnpm-store, .worktrees, __openclaw_vitest__ และ ไดเรกทอรีผลลัพธ์ .build หรือ Gradle ภายในแอป เพื่อให้การเรียกใช้ Docker แบบสดไม่ เสียเวลาหลายนาทีคัดลอกอาร์ติแฟกต์เฉพาะเครื่อง นอกจากนี้ยังตั้งค่า OPENCLAW_SKIP_CHANNELS=1 เพื่อให้โพรบ Gateway แบบสดไม่เริ่มเวิร์กเกอร์ช่องทางจริงของ Telegram/Discord/ฯลฯ ภายในคอนเทนเนอร์ test:docker:live-models ยังคงเรียกใช้ pnpm test:live ดังนั้นให้ส่งต่อ OPENCLAW_LIVE_GATEWAY_* ด้วยเมื่อต้องการจำกัดหรือยกเว้นความครอบคลุมแบบสดของ Gateway จากเลน Docker นั้น

test:docker:openwebui เป็นการทดสอบความเข้ากันได้แบบ smoke test ระดับสูงกว่า โดยจะเริ่มคอนเทนเนอร์ Gateway ของ OpenClaw ที่เปิดใช้งานปลายทาง HTTP ซึ่งเข้ากันได้กับ OpenAI จากนั้นเริ่มคอนเทนเนอร์ Open WebUI เวอร์ชันที่ตรึงไว้ให้เชื่อมต่อกับ Gateway ดังกล่าว ลงชื่อเข้าใช้ผ่าน Open WebUI ตรวจสอบว่า /api/models แสดง openclaw/default แล้วจึงส่งคำขอแชตจริงผ่านพร็อกซี /api/chat/completions ของ Open WebUI ตั้งค่า OPENWEBUI_SMOKE_MODE=models สำหรับการตรวจสอบ CI บนเส้นทางการเผยแพร่ที่ควรหยุดหลังจากลงชื่อเข้าใช้ Open WebUI และค้นพบโมเดลแล้ว โดยไม่รอให้โมเดลจริงสร้างผลลัพธ์ให้เสร็จ การรันครั้งแรกอาจช้ากว่าอย่างเห็นได้ชัด เนื่องจาก Docker อาจต้องดึงอิมเมจ Open WebUI และ Open WebUI อาจต้องดำเนินการตั้งค่าเริ่มต้นแบบ cold start ของตนให้เสร็จ เลนนี้คาดว่าจะมีคีย์ของโมเดลจริงที่ใช้งานได้ ซึ่งส่งผ่านสภาพแวดล้อมของโพรเซส โปรไฟล์การยืนยันตัวตนที่จัดเตรียมไว้ หรือ OPENCLAW_PROFILE_FILE ที่ระบุอย่างชัดเจน การรันที่สำเร็จจะแสดงเพย์โหลด JSON ขนาดเล็ก เช่น { "ok": true, "model": "openclaw/default", ... }

test:docker:mcp-channels ถูกออกแบบให้ให้ผลลัพธ์แบบกำหนดแน่นอน และไม่จำเป็นต้องมีบัญชี Telegram, Discord หรือ iMessage จริง โดยจะบูตคอนเทนเนอร์ Gateway ที่มีข้อมูลตั้งต้น เริ่มคอนเทนเนอร์ที่สองซึ่งสร้างโพรเซส openclaw mcp serve จากนั้นตรวจสอบการค้นหาบทสนทนาที่กำหนดเส้นทางแล้ว การอ่านทรานสคริปต์ เมทาดาทาของไฟล์แนบ พฤติกรรมของคิวเหตุการณ์แบบสด การกำหนดเส้นทางการส่งขาออก และการแจ้งเตือนช่องทางพร้อมสิทธิ์แบบ Claude ผ่านบริดจ์ MCP แบบ stdio จริง การตรวจสอบการแจ้งเตือนจะตรวจเฟรม MCP แบบ stdio ดิบโดยตรง เพื่อให้ smoke test ตรวจสอบสิ่งที่บริดจ์ส่งออกจริง ไม่ใช่เพียงสิ่งที่ SDK ของไคลเอนต์รายใดรายหนึ่งแสดงให้เห็น

test:docker:agent-bundle-mcp-tools ให้ผลลัพธ์แบบกำหนดแน่นอนและไม่จำเป็นต้องมีคีย์ของโมเดลจริง โดยจะสร้างอิมเมจ Docker ของรีโพซิทอรี เริ่มเซิร์ฟเวอร์ตรวจสอบ MCP แบบ stdio จริงภายในคอนเทนเนอร์ ทำให้เซิร์ฟเวอร์ดังกล่าวพร้อมใช้งานผ่านรันไทม์ MCP ของบันเดิล OpenClaw ที่ฝังอยู่ เรียกใช้เครื่องมือ แล้วตรวจสอบว่า coding และ messaging ยังคงมีเครื่องมือ bundle-mcp ขณะที่ minimal และ tools.deny: ["bundle-mcp"] กรองเครื่องมือเหล่านั้นออก

test:docker:cron-mcp-cleanup ให้ผลลัพธ์แบบกำหนดแน่นอนและไม่จำเป็นต้องมีคีย์ของโมเดลจริง โดยจะเริ่ม Gateway ที่มีข้อมูลตั้งต้นพร้อมเซิร์ฟเวอร์ตรวจสอบ MCP แบบ stdio จริง รันรอบการทำงาน Cron แบบแยกเดี่ยวและรอบการทำงานลูกแบบครั้งเดียวของ sessions_spawn จากนั้นตรวจสอบว่าโพรเซสลูก MCP สิ้นสุดหลังการรันแต่ละครั้ง

การทดสอบ smoke test ของเธรด ACP ด้วยภาษาธรรมดาแบบดำเนินการด้วยตนเอง (ไม่ใช่ CI):

• bun scripts/dev/discord-acp-plain-language-smoke.ts --channel <discord-channel-id> ...
• เก็บสคริปต์นี้ไว้สำหรับเวิร์กโฟลว์การทดสอบการถดถอย/ดีบัก อาจต้องใช้อีกครั้งในการตรวจสอบความถูกต้องของการกำหนดเส้นทางเธรด ACP ดังนั้นอย่าลบสคริปต์นี้

ตัวแปรสภาพแวดล้อมที่มีประโยชน์:

• OPENCLAW_CONFIG_DIR=... (ค่าเริ่มต้น: ~/.openclaw) เมานต์ไปยัง /home/node/.openclaw
• OPENCLAW_WORKSPACE_DIR=... (ค่าเริ่มต้น: ~/.openclaw/workspace) เมานต์ไปยัง /home/node/.openclaw/workspace
• OPENCLAW_PROFILE_FILE=... เมานต์และโหลดเป็นแหล่งข้อมูลก่อนรันการทดสอบ
• OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1 เพื่อยืนยันเฉพาะตัวแปรสภาพแวดล้อมที่โหลดมาจาก OPENCLAW_PROFILE_FILE โดยใช้ไดเรกทอรีการกำหนดค่า/พื้นที่ทำงานชั่วคราว และไม่เมานต์การยืนยันตัวตนของ CLI ภายนอก
• OPENCLAW_DOCKER_CLI_TOOLS_DIR=... (ค่าเริ่มต้น: ~/.cache/openclaw/docker-cli-tools เว้นแต่การรันนั้นใช้ไดเรกทอรี bind ของ CI/ที่มีการจัดการอยู่แล้ว) เมานต์ไปยัง /home/node/.npm-global สำหรับแคชการติดตั้งเครื่องมือ CLI ภายใน Docker
• ไดเรกทอรี/ไฟล์การยืนยันตัวตนของ CLI ภายนอกภายใต้ $HOME จะถูกเมานต์เป็นแบบอ่านอย่างเดียวภายใต้ /host-auth... แล้วคัดลอกไปยัง /home/node/... ก่อนเริ่มการทดสอบ
  • ไดเรกทอรีเริ่มต้น (ใช้เมื่อการรันไม่ได้จำกัดไว้เฉพาะผู้ให้บริการบางราย): .factory, .gemini, .minimax
  • ไฟล์เริ่มต้น: ~/.codex/auth.json, ~/.codex/config.toml, .claude.json, ~/.claude/.credentials.json, ~/.claude/settings.json, ~/.claude/settings.local.json
  • การรันที่จำกัดผู้ให้บริการจะเมานต์เฉพาะไดเรกทอรี/ไฟล์ที่จำเป็นซึ่งอนุมานจาก OPENCLAW_LIVE_PROVIDERS / OPENCLAW_LIVE_GATEWAY_PROVIDERS
  • เขียนทับด้วยตนเองโดยใช้ OPENCLAW_DOCKER_AUTH_DIRS=all, OPENCLAW_DOCKER_AUTH_DIRS=none หรือรายการที่คั่นด้วยจุลภาค เช่น OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex
• OPENCLAW_LIVE_GATEWAY_MODELS=... / OPENCLAW_LIVE_MODELS=... เพื่อจำกัดขอบเขตการรัน
• OPENCLAW_LIVE_GATEWAY_PROVIDERS=... / OPENCLAW_LIVE_PROVIDERS=... เพื่อกรองผู้ให้บริการภายในคอนเทนเนอร์
• OPENCLAW_SKIP_DOCKER_BUILD=1 เพื่อนำอิมเมจ openclaw:local-live ที่มีอยู่กลับมาใช้สำหรับการรันซ้ำที่ไม่จำเป็นต้องสร้างใหม่
• OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 เพื่อให้แน่ใจว่าข้อมูลรับรองมาจากที่เก็บโปรไฟล์ (ไม่ใช่ตัวแปรสภาพแวดล้อม)
• OPENCLAW_OPENWEBUI_MODEL=... เพื่อเลือกโมเดลที่ Gateway เปิดให้ใช้สำหรับ smoke test ของ Open WebUI
• OPENCLAW_OPENWEBUI_PROMPT=... เพื่อเขียนทับพรอมต์ตรวจสอบ nonce ที่ smoke test ของ Open WebUI ใช้
• OPENWEBUI_IMAGE=... เพื่อเขียนทับแท็กอิมเมจ Open WebUI ที่ตรึงไว้

การตรวจสอบความสมเหตุสมผลของเอกสาร

รันการตรวจสอบเอกสารหลังแก้ไขเอกสาร: pnpm check:docs รันการตรวจสอบ anchor แบบเต็มของ Mintlify เมื่อต้องการตรวจสอบหัวข้อภายในหน้าด้วย: pnpm docs:check-links:anchors

การทดสอบการถดถอยแบบออฟไลน์ (ปลอดภัยสำหรับ CI)

รายการเหล่านี้เป็นการทดสอบการถดถอยของ “ไปป์ไลน์จริง” โดยไม่ใช้ผู้ให้บริการจริง:

• การเรียกใช้เครื่องมือของ Gateway (OpenAI จำลอง, Gateway จริง + ลูปเอเจนต์): src/gateway/gateway.test.ts (กรณี: "รันการเรียกใช้เครื่องมือ OpenAI จำลองแบบต้นทางถึงปลายทางผ่านลูปเอเจนต์ของ Gateway")
• วิซาร์ดของ Gateway (wizard.start/wizard.next ผ่าน WS, เขียนการกำหนดค่า + บังคับใช้การยืนยันตัวตน): src/gateway/gateway.test.ts (กรณี: "รันวิซาร์ดผ่าน ws และเขียนการกำหนดค่าโทเค็นการยืนยันตัวตน")

การประเมินความน่าเชื่อถือของเอเจนต์ (Skills)

เรามีการทดสอบที่ปลอดภัยสำหรับ CI บางส่วนซึ่งทำงานคล้าย “การประเมินความน่าเชื่อถือของเอเจนต์” อยู่แล้ว:

• การเรียกใช้เครื่องมือจำลองผ่าน Gateway จริง + ลูปเอเจนต์ (src/gateway/gateway.test.ts)
• โฟลว์วิซาร์ดแบบต้นทางถึงปลายทางที่ตรวจสอบการเชื่อมโยงเซสชันและผลกระทบต่อการกำหนดค่า (src/gateway/gateway.test.ts)

สิ่งที่ยังขาดสำหรับ Skills (ดู Skills):

• การตัดสินใจ: เมื่อพรอมต์แสดงรายการ Skills เอเจนต์เลือก Skills ที่ถูกต้อง (หรือหลีกเลี่ยง Skills ที่ไม่เกี่ยวข้อง) หรือไม่
• การปฏิบัติตามข้อกำหนด: เอเจนต์อ่าน SKILL.md ก่อนใช้งานและทำตามขั้นตอน/อาร์กิวเมนต์ที่กำหนดหรือไม่
• สัญญาเวิร์กโฟลว์: สถานการณ์แบบหลายรอบที่ยืนยันลำดับเครื่องมือ การสืบทอดประวัติเซสชัน และขอบเขตของแซนด์บ็อกซ์

การประเมินในอนาคตควรเริ่มจากการให้ผลลัพธ์แบบกำหนดแน่นอน:

• ตัวรันสถานการณ์ที่ใช้ผู้ให้บริการจำลองเพื่อยืนยันการเรียกใช้เครื่องมือพร้อมลำดับ การอ่านไฟล์ Skills และการเชื่อมโยงเซสชัน
• ชุดสถานการณ์ขนาดเล็กที่มุ่งเน้น Skills (ใช้เทียบกับหลีกเลี่ยง การควบคุมเงื่อนไข และการแทรกคำสั่งในพรอมต์)
• การประเมินแบบสดเพิ่มเติม (เลือกเข้าร่วมและควบคุมด้วยตัวแปรสภาพแวดล้อม) หลังจากมีชุดที่ปลอดภัยสำหรับ CI แล้วเท่านั้น

การทดสอบสัญญา (รูปแบบ Plugin และช่องทาง)

การทดสอบสัญญาจะตรวจสอบว่า Plugin และช่องทางที่ลงทะเบียนทุกรายการเป็นไปตามสัญญาอินเทอร์เฟซของตน โดยจะวนผ่าน Plugin ที่ค้นพบทั้งหมดและรันชุดการยืนยันรูปแบบและพฤติกรรม เลนยูนิต pnpm test เริ่มต้นจะข้ามไฟล์จุดเชื่อมร่วมและ smoke test เหล่านี้โดยตั้งใจ ให้รันคำสั่งสัญญาอย่างชัดเจนเมื่อแก้ไขพื้นผิวช่องทางหรือผู้ให้บริการที่ใช้ร่วมกัน

คำสั่ง

• สัญญาทั้งหมด: pnpm test:contracts
• เฉพาะสัญญาช่องทาง: pnpm test:contracts:channels
• เฉพาะสัญญาผู้ให้บริการ: pnpm test:contracts:plugins

สัญญาช่องทาง

อยู่ใน src/channels/plugins/contracts/*.contract.test.ts หมวดหมู่ระดับบนสุดในปัจจุบัน:

• แค็ตตาล็อกช่องทาง - เมทาดาทารายการแค็ตตาล็อกช่องทางแบบรวมมาให้/รีจิสทรี
• Plugin (รองรับด้วยรีจิสทรี, แบ่งชาร์ด) - รูปแบบพื้นฐานของการลงทะเบียน Plugin
• เฉพาะพื้นผิว (รองรับด้วยรีจิสทรี, แบ่งชาร์ด) - การตรวจสอบรูปแบบแยกตามพื้นผิวสำหรับ actions, setup, status, outbound, messaging, threading, directory และ gateway
• การเชื่อมโยงเซสชัน (รองรับด้วยรีจิสทรี) - พฤติกรรมการเชื่อมโยงเซสชัน
• เพย์โหลดขาออก - โครงสร้างและการปรับให้เป็นมาตรฐานของเพย์โหลดข้อความ
• นโยบายกลุ่ม (ทางเลือกสำรอง) - การบังคับใช้นโยบายกลุ่มเริ่มต้นแยกตามช่องทาง
• การจัดเธรด (รองรับด้วยรีจิสทรี, แบ่งชาร์ด) - การจัดการรหัสเธรด
• ไดเรกทอรี (รองรับด้วยรีจิสทรี, แบ่งชาร์ด) - API ไดเรกทอรี/รายชื่อสมาชิก
• รีจิสทรี และ แกนหลักของ Plugin.* - รีจิสทรี Plugin ช่องทาง ตัวโหลด และรายละเอียดภายในของการอนุญาตให้เขียนการกำหนดค่า

ตัวช่วยฮาร์เนสสำหรับจับการส่งต่อขาเข้าและเพย์โหลดขาออกที่ชุดเหล่านี้ใช้ จะเปิดให้ใช้ภายในผ่าน src/plugin-sdk/channel-contract-testing.ts (ไม่รวมใน npm และไม่ใช่พาธย่อยของ SDK สาธารณะ) ไม่มีไฟล์ inbound.contract.test.ts แยกต่างหากในไดเรกทอรีนี้

สัญญาผู้ให้บริการ

อยู่ใน src/plugins/contracts/*.contract.test.ts หมวดหมู่ปัจจุบันประกอบด้วย:

• รูปแบบ - รูปแบบของแมนิเฟสต์ Plugin, API และการส่งออกของรันไทม์
• การลงทะเบียน Plugin (+ แบบขนาน) - กรณีการลงทะเบียนแมนิเฟสต์
• แมนิเฟสต์แพ็กเกจ - ข้อกำหนดของแมนิเฟสต์แพ็กเกจ
• ตัวโหลด - พฤติกรรมการตั้งค่า/รื้อถอนตัวโหลด Plugin
• รีจิสทรี - เนื้อหาและการค้นหาในรีจิสทรีสัญญาของ Plugin
• ผู้ให้บริการ - พฤติกรรมของผู้ให้บริการที่ใช้ร่วมกันในผู้ให้บริการแบบรวมมาให้ รวมถึงผู้ให้บริการค้นหาเว็บ
• ตัวเลือกการยืนยันตัวตน - เมทาดาทาตัวเลือกการยืนยันตัวตนและพฤติกรรมการตั้งค่า
• การเลิกใช้งานแค็ตตาล็อกผู้ให้บริการ - เมทาดาทาแค็ตตาล็อกผู้ให้บริการที่เลิกใช้งานแล้ว
• การแก้ไขตัวเลือกของวิซาร์ด, ตัวเลือกโมเดลของวิซาร์ด, ตัวเลือกการตั้งค่าของวิซาร์ด - สัญญาวิซาร์ดการตั้งค่าผู้ให้บริการ
• ผู้ให้บริการเวกเตอร์ฝัง, ผู้ให้บริการเวกเตอร์ฝังของหน่วยความจำ, ผู้ให้บริการดึงข้อมูลเว็บ, การแปลงข้อความเป็นเสียงพูด - สัญญาผู้ให้บริการเฉพาะความสามารถ
• การดำเนินการเซสชัน, ไฟล์แนบเซสชัน, การฉายภาพรายการเซสชัน - สัญญาสถานะเซสชันที่ Plugin เป็นเจ้าของ
• รอบการทำงานตามกำหนดเวลา - เมทาดาทารอบการทำงานตามกำหนดเวลาของ Plugin และขอบเขตเวลาประทับ
• ฮุกของโฮสต์, วงจรชีวิตบริบทการรัน, ผลข้างเคียงจากการนำเข้ารันไทม์, จุดเชื่อมรันไทม์ - สัญญาวงจรชีวิตของโฮสต์/รันไทม์ Plugin และขอบเขตการนำเข้า
• การขึ้นต่อกันของรันไทม์ส่วนขยาย - ตำแหน่งของการขึ้นต่อกันของรันไทม์สำหรับส่วนขยาย

ควรรันเมื่อใด

• หลังจากเปลี่ยนการส่งออกหรือพาธย่อยของ plugin-sdk
• หลังจากเพิ่มหรือแก้ไข Plugin ช่องทางหรือผู้ให้บริการ
• หลังจากปรับโครงสร้างการลงทะเบียนหรือการค้นพบ Plugin

การทดสอบสัญญาจะรันใน CI และไม่จำเป็นต้องใช้คีย์ API จริง

การเพิ่มการทดสอบการถดถอย (แนวทาง)

เมื่อแก้ไขปัญหาของผู้ให้บริการ/โมเดลที่ค้นพบในการทดสอบแบบสด:

• เพิ่มการทดสอบการถดถอยที่ปลอดภัยสำหรับ CI หากเป็นไปได้ (ผู้ให้บริการจำลอง/สตับ หรือจับการแปลงรูปแบบคำขอที่แน่นอน)
• หากปัญหานั้นเกิดได้เฉพาะแบบสดโดยธรรมชาติ (ขีดจำกัดอัตรา นโยบายการยืนยันตัวตน) ให้จำกัดขอบเขตการทดสอบแบบสดและกำหนดให้เลือกเข้าร่วมผ่านตัวแปรสภาพแวดล้อม
• ควรมุ่งเป้าไปยังเลเยอร์ที่เล็กที่สุดซึ่งตรวจพบข้อบกพร่องได้:
  • ข้อบกพร่องในการแปลง/เล่นซ้ำคำขอของผู้ให้บริการ -> การทดสอบโมเดลโดยตรง
  • ข้อบกพร่องของไปป์ไลน์เซสชัน/ประวัติ/เครื่องมือของ Gateway -> smoke test แบบสดของ Gateway หรือการทดสอบจำลอง Gateway ที่ปลอดภัยสำหรับ CI
• กลไกป้องกันการสืบค้น SecretRef:
  • src/secrets/exec-secret-ref-id-parity.test.ts จะสร้างเป้าหมายตัวอย่างหนึ่งรายการต่อคลาส SecretRef จากเมทาดาทารีจิสทรี (listSecretTargetRegistryEntries()) แล้วจึงยืนยันว่ารหัส exec ที่มีส่วนเส้นทางแบบไล่ระดับถูกปฏิเสธ
  • หากเพิ่มตระกูลเป้าหมาย SecretRef ใหม่ที่มี includeInPlan ใน src/secrets/target-registry-data.ts ให้อัปเดต classifyTargetClass ในการทดสอบดังกล่าว การทดสอบนี้ตั้งใจให้ล้มเหลวเมื่อพบรหัสเป้าหมายที่ยังไม่ได้จำแนกประเภท เพื่อไม่ให้คลาสใหม่ถูกข้ามโดยไม่มีการแจ้งเตือน

เนื้อหาที่เกี่ยวข้อง

• การทดสอบแบบสด
• การทดสอบการอัปเดตและ Plugin
• CI