---
read_when:
    - การเปลี่ยนแปลงลักษณะการทำงานของการอัปเดต OpenClaw, doctor, การตรวจรับแพ็กเกจ หรือการติดตั้ง Plugin
    - การเตรียมหรืออนุมัติเวอร์ชันตัวเลือกสำหรับเผยแพร่
    - การดีบักการอัปเดตแพ็กเกจ การล้างข้อมูลการขึ้นต่อกันของ Plugin หรือการถดถอยของการติดตั้ง Plugin
sidebarTitle: Update and plugin tests
summary: วิธีที่ OpenClaw ตรวจสอบเส้นทางการอัปเดต การย้ายแพ็กเกจ และพฤติกรรมการติดตั้ง/อัปเดต Plugin
title: 'การทดสอบ: การอัปเดตและ Plugin'
x-i18n:
    generated_at: "2026-07-12T16:17:06Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 4e930960b5819d2144467476cb473e62f236eca63e1d9941a6bc793b484e731c
    source_path: help/testing-updates-plugins.md
    workflow: 16
---

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

สำหรับภาพรวมชุดรันทดสอบที่กว้างขึ้น โปรดดู [การทดสอบ](/th/help/testing) สำหรับคีย์ของผู้ให้บริการแบบใช้งานจริง
และชุดทดสอบที่เชื่อมต่อเครือข่าย โปรดดู [การทดสอบแบบใช้งานจริง](/th/help/testing-live)

## สิ่งที่เราปกป้อง

- tarball ของแพ็กเกจมีเนื้อหาครบถ้วน มี `dist/postinstall-inventory.json` ที่ถูกต้อง
  และไม่พึ่งพาไฟล์ในรีโพที่ไม่ได้บรรจุมา
- ผู้ใช้สามารถย้ายจากแพ็กเกจรุ่นเก่าที่เผยแพร่แล้วไปยังแพ็กเกจตัวเลือก
  โดยไม่สูญเสียการกำหนดค่า เอเจนต์ เซสชัน เวิร์กสเปซ รายการอนุญาตของ Plugin หรือ
  การกำหนดค่าช่องทาง
- `openclaw doctor --fix --non-interactive` เป็นเจ้าของเส้นทางการล้างและซ่อมแซม
  ข้อมูลเก่า การเริ่มต้นระบบไม่ควรเพิ่มการย้ายข้อมูลเพื่อความเข้ากันได้แบบซ่อนสำหรับสถานะ
  Plugin ที่ค้างอยู่
- การติดตั้ง Plugin ทำงานได้จากไดเรกทอรีภายในเครื่อง รีโพ git แพ็กเกจ npm และ
  เส้นทางรีจิสทรี ClawHub
- การติดตั้งการขึ้นต่อกันของ npm สำหรับ Plugin แต่ละรายการเกิดขึ้นในโปรเจกต์ npm ที่มีการจัดการหนึ่งโปรเจกต์ต่อ Plugin
  ถูกสแกนก่อนให้ความเชื่อถือ และถูกนำออกผ่าน `npm uninstall` ระหว่าง
  การถอนการติดตั้ง Plugin เพื่อไม่ให้การขึ้นต่อกันที่ถูกยกระดับขึ้นไปยังระดับบนค้างอยู่
- การอัปเดต Plugin จะไม่ดำเนินการใดเมื่อไม่มีสิ่งเปลี่ยนแปลง: ระเบียนการติดตั้ง แหล่งที่มา
  ที่แก้ไขแล้ว โครงสร้างการขึ้นต่อกันที่ติดตั้ง และสถานะการเปิดใช้งานยังคงเดิม

## การพิสูจน์ภายในเครื่องระหว่างการพัฒนา

เริ่มจากขอบเขตแคบ:

```bash
pnpm changed:lanes --json
pnpm check:changed
pnpm test:changed
```

สำหรับการเปลี่ยนแปลงที่เกี่ยวกับการติดตั้ง การถอนการติดตั้ง การขึ้นต่อกันของ Plugin หรือคลังรายการแพ็กเกจ ให้
รันการทดสอบเฉพาะจุดที่ครอบคลุมรอยต่อที่แก้ไขด้วย:

```bash
pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts
```

ก่อนที่เลน Docker ของแพ็กเกจใดจะใช้ tarball ให้พิสูจน์อาร์ติแฟกต์แพ็กเกจก่อน:

```bash
pnpm release:check
```

`release:check` รันการตรวจสอบความคลาดเคลื่อนของการกำหนดค่า/เอกสาร/API (สคีมาการกำหนดค่า เส้นฐานเอกสาร
การกำหนดค่า เส้นฐานและการส่งออก API ของ Plugin SDK รุ่น/คลังรายการ Plugin)
เขียนคลังรายการ dist ของแพ็กเกจ รัน `npm pack --dry-run` ปฏิเสธไฟล์ต้องห้าม
ที่ถูกบรรจุ ติดตั้ง tarball ลงในคำนำหน้าชั่วคราว รัน postinstall และ
ทดสอบเบื้องต้นกับจุดเข้าของช่องทางที่รวมมา

## เลน Docker

เลน Docker คือหลักฐานระดับผลิตภัณฑ์ โดยติดตั้งหรืออัปเดตแพ็กเกจจริง
ภายในคอนเทนเนอร์ Linux และยืนยันพฤติกรรมผ่านคำสั่ง CLI
การเริ่มต้น Gateway การตรวจสอบ HTTP สถานะ RPC และสถานะระบบไฟล์

ใช้เลนเฉพาะจุดระหว่างการปรับแก้:

```bash
pnpm test:docker:plugins
pnpm test:docker:plugin-lifecycle-matrix
pnpm test:docker:plugin-update
pnpm test:docker:upgrade-survivor
pnpm test:docker:published-upgrade-survivor
pnpm test:docker:update-restart-auth
pnpm test:docker:update-migration
```

เลนสำคัญ:

- `test:docker:plugins` ครอบคลุมการทดสอบเบื้องต้นของการติดตั้ง Plugin การติดตั้งจากโฟลเดอร์ภายในเครื่อง
  พฤติกรรมข้ามการอัปเดตโฟลเดอร์ภายในเครื่อง โฟลเดอร์ภายในเครื่องที่มี
  การขึ้นต่อกันติดตั้งไว้ล่วงหน้า การติดตั้งแพ็กเกจ `file:` การติดตั้งจาก git พร้อมการเรียกใช้ CLI การอัปเดต
  ref ของ git ที่เคลื่อนที่ได้ การติดตั้งจากรีจิสทรี npm ที่มีการขึ้นต่อกันทางอ้อม
  ซึ่งถูกยกระดับขึ้นไปยังระดับบน การไม่ดำเนินการเมื่ออัปเดต npm การปฏิเสธเมทาดาทาของแพ็กเกจ npm ที่ผิดรูปแบบ
  การติดตั้งจากฟิกซ์เจอร์ ClawHub ภายในเครื่องและการไม่ดำเนินการเมื่ออัปเดต พฤติกรรมการอัปเดตมาร์เก็ตเพลส
  และการเปิดใช้งาน/ตรวจสอบบันเดิล Claude ตั้งค่า `OPENCLAW_PLUGINS_E2E_CLAWHUB=0` เพื่อ
  ให้บล็อก ClawHub ทำงานแบบปิดและออฟไลน์
- `test:docker:plugin-lifecycle-matrix` ติดตั้งแพ็กเกจตัวเลือกในคอนเทนเนอร์เปล่า
  รัน Plugin npm ผ่านการติดตั้ง ตรวจสอบ ปิดใช้งาน เปิดใช้งาน
  อัปเกรดแบบระบุชัด ดาวน์เกรดแบบระบุชัด และถอนการติดตั้งหลังจากลบโค้ด Plugin
  โดยบันทึกเมตริก RSS และ CPU ในแต่ละระยะ
- `test:docker:plugin-update` ตรวจสอบว่า Plugin ที่ติดตั้งแล้วและไม่มีการเปลี่ยนแปลง
  จะไม่ถูกติดตั้งซ้ำหรือสูญเสียเมทาดาทาการติดตั้งระหว่าง `openclaw plugins update`
- `test:docker:upgrade-survivor` ติดตั้ง tarball ตัวเลือกทับฟิกซ์เจอร์ผู้ใช้เก่า
  ที่มีข้อมูลค้าง รันการอัปเดตแพ็กเกจพร้อม doctor แบบไม่โต้ตอบ จากนั้นเริ่ม
  Gateway แบบ local loopback และตรวจสอบการรักษาสถานะ
- `test:docker:published-upgrade-survivor` ติดตั้งเส้นฐานที่เผยแพร่แล้วก่อน
  กำหนดค่าผ่านสูตร `openclaw config set` ที่ฝังไว้ อัปเดตเป็น
  tarball ตัวเลือก รัน doctor ตรวจสอบการล้างข้อมูลเก่า เริ่ม Gateway และ
  ตรวจสอบ `/healthz`, `/readyz` และสถานะ RPC
- `test:docker:update-restart-auth` ติดตั้งแพ็กเกจตัวเลือก เริ่ม
  Gateway ที่จัดการด้วยการตรวจสอบสิทธิ์แบบโทเค็น ยกเลิกการตั้งค่า env การตรวจสอบสิทธิ์ Gateway ของผู้เรียกสำหรับ
  `openclaw update --yes --json` และกำหนดให้คำสั่งอัปเดตตัวเลือก
  รีสตาร์ต Gateway ก่อนการตรวจสอบตามปกติ
- `test:docker:update-migration` คือเลนอัปเดตจากรุ่นเผยแพร่ที่เน้นการล้างข้อมูล
  โดยเริ่มจากสถานะผู้ใช้ที่กำหนดค่าในรูปแบบ Discord/Telegram รัน
  doctor เส้นฐานเพื่อให้การขึ้นต่อกันของ Plugin ที่กำหนดค่ามีโอกาสถูกสร้างขึ้น เติม
  เศษการขึ้นต่อกันเก่าของ Plugin สำหรับ Plugin แบบแพ็กเกจที่กำหนดค่าไว้ อัปเดตเป็น
  tarball ตัวเลือก และกำหนดให้ doctor หลังอัปเดตนำรากการขึ้นต่อกันเก่าออก

รูปแบบทางเลือกที่มีประโยชน์ของการทดสอบการอัปเกรดจากรุ่นเผยแพร่:

```bash
OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@2026.4.23 \
OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=versioned-runtime-deps \
pnpm test:docker:published-upgrade-survivor

OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@latest \
OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=bootstrap-persona \
pnpm test:docker:published-upgrade-survivor
```

สถานการณ์ที่ใช้ได้: `base`, `acpx-openclaw-tools-bridge`, `feishu-channel`,
`bootstrap-persona`, `channel-post-core-restore`, `plugin-deps-cleanup`,
`configured-plugin-installs`, `stale-source-plugin-shadow`, `tilde-log-path`
และ `versioned-runtime-deps` ในการรันแบบรวม `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues`
(นามแฝง `far-reaching`) จะขยายเป็นทุกสถานการณ์ รวมถึง
การย้ายข้อมูลการติดตั้ง Plugin ที่กำหนดค่าไว้

การย้ายข้อมูลการอัปเดตแบบเต็มถูกแยกออกจาก CI การเผยแพร่แบบเต็มโดยตั้งใจ ใช้
เวิร์กโฟลว์ `Update Migration` แบบเรียกเองเมื่อคำถามสำหรับการเผยแพร่คือ "รุ่นเสถียร
ที่เผยแพร่ทุกรุ่นตั้งแต่ 2026.4.23 เป็นต้นมาสามารถอัปเดตเป็นตัวเลือกนี้และ
ล้างเศษการขึ้นต่อกันของ Plugin ได้หรือไม่":

```bash
gh workflow run update-migration.yml \
  --ref main \
  -f workflow_ref=main \
  -f package_ref=main \
  -f baselines=all-since-2026.4.23 \
  -f scenarios=plugin-deps-cleanup
```

## การยอมรับแพ็กเกจ

การยอมรับแพ็กเกจคือเกตแพ็กเกจที่ทำงานบน GitHub โดยจะแก้ไขแพ็กเกจตัวเลือกหนึ่งรายการ
เป็น tarball `package-under-test` บันทึกรุ่นและ SHA-256 จากนั้น
รันเลน Docker E2E ที่ใช้ซ้ำได้กับ tarball เดียวกันนั้น ref ของชุดควบคุมเวิร์กโฟลว์
แยกจาก ref แหล่งที่มาของแพ็กเกจ เพื่อให้ตรรกะการทดสอบปัจจุบันสามารถตรวจสอบ
รุ่นที่เชื่อถือได้ซึ่งเก่ากว่า

แหล่งที่มาของตัวเลือก:

- `source=npm`: ตรวจสอบ `openclaw@extended-stable`, `openclaw@beta`,
  `openclaw@latest` หรือรุ่นที่เผยแพร่แบบระบุชัด
- `source=ref`: บรรจุสาขา แท็ก หรือคอมมิตที่เชื่อถือได้ด้วยชุดควบคุมปัจจุบัน
  ที่เลือก
- `source=url`: ตรวจสอบ tarball HTTPS สาธารณะที่ต้องมี `package_sha256`
  เส้นทางนี้ปฏิเสธข้อมูลรับรองใน URL พอร์ต HTTPS ที่ไม่ใช่ค่าเริ่มต้น ชื่อโฮสต์หรือ
  ผลลัพธ์ DNS/IP แบบส่วนตัว/ภายใน พื้นที่ IP สำหรับการใช้งานพิเศษ และการเปลี่ยนเส้นทางที่ไม่ปลอดภัย
- `source=trusted-url`: ตรวจสอบ tarball HTTPS ที่ต้องมี
  `package_sha256` และ `trusted_source_id` ตามนโยบายที่ผู้ดูแลเป็นเจ้าของ
  ใน `.github/package-trusted-sources.json` ใช้ตัวเลือกนี้สำหรับมิเรอร์ระดับองค์กร/ส่วนตัว
  แทนการทำให้ `source=url` อ่อนแอลงด้วยสวิตช์อนุญาตเครือข่ายส่วนตัวระดับอินพุต
  การตรวจสอบสิทธิ์แบบ Bearer เมื่อกำหนดค่าโดยนโยบาย จะใช้ซีเคร็ต
  `OPENCLAW_TRUSTED_PACKAGE_TOKEN` แบบคงที่
- `source=artifact`: ใช้ tarball ที่อัปโหลดโดยการรัน Actions อื่นซ้ำ

การตรวจสอบความถูกต้องของการเผยแพร่แบบเต็มใช้ `source=artifact` เป็นค่าเริ่มต้น โดยสร้างจาก
SHA ของรุ่นเผยแพร่ที่แก้ไขแล้ว สำหรับการพิสูจน์หลังเผยแพร่ ให้ส่ง
`package_acceptance_package_spec=openclaw@YYYY.M.PATCH` เพื่อให้เมทริกซ์การอัปเกรดเดียวกัน
มุ่งไปที่แพ็กเกจ npm ที่เผยแพร่แล้วแทน

การตรวจสอบรุ่นเผยแพร่เรียกการยอมรับแพ็กเกจด้วยชุดแพ็กเกจ/อัปเดต/รีสตาร์ต/Plugin:

```text
doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape
```

เมื่อเปิดใช้การแช่ทดสอบรุ่นเผยแพร่ (บังคับเปิดสำหรับ `release_profile=stable` และ
`full`) ระบบจะส่งค่าเหล่านี้เพิ่มเติม:

```text
published_upgrade_survivor_baselines=last-stable-4 2026.4.23 2026.5.2 2026.4.15
published_upgrade_survivor_scenarios=reported-issues
telegram_mode=mock-openai
```

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

`last-stable-4` จะแก้ไขเป็น OpenClaw รุ่นเสถียรสี่รุ่นล่าสุด
ที่เผยแพร่บน npm การยอมรับแพ็กเกจรุ่นเผยแพร่ปักหมุด `2026.4.23` เป็นขอบเขตความเข้ากันได้
แรกสำหรับการอัปเดต Plugin, `2026.5.2` เป็นขอบเขตที่สถาปัตยกรรม Plugin เปลี่ยนแปลงมาก และ
`2026.4.15` เป็นเส้นฐานการอัปเดตจากรุ่นเผยแพร่ 2026.4.1x ที่เก่ากว่า ตัวแก้ไข
จะตัดหมุดที่มีอยู่แล้วในสี่รุ่นล่าสุดออก สำหรับความครอบคลุมการย้ายข้อมูล
การอัปเดตจากรุ่นเผยแพร่แบบครบถ้วน ให้ใช้ `all-since-2026.4.23` ในเวิร์กโฟลว์ Update
Migration ที่แยกต่างหากแทน CI การเผยแพร่แบบเต็ม `release-history` ยังคง
ใช้ได้สำหรับการสุ่มตัวอย่างที่กว้างขึ้นแบบเรียกเอง เมื่อคุณต้องการจุดยึดเก่าก่อนวันที่กำหนดด้วย

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

รันโปรไฟล์แพ็กเกจด้วยตนเองเมื่อตรวจสอบตัวเลือกก่อนเผยแพร่:

```bash
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=package \
  -f published_upgrade_survivor_baselines="last-stable-4 2026.4.23 2026.5.2 2026.4.15" \
  -f published_upgrade_survivor_scenarios=reported-issues \
  -f telegram_mode=mock-openai
```

สำหรับคานารี extended-stable ที่เผยแพร่แล้ว ให้ตั้งค่า
`package_spec=openclaw@extended-stable` การยอมรับแพ็กเกจจะแก้ไข
ตัวเลือกนั้นเป็น tarball ที่ระบุชัดก่อนที่เลน Docker จะรัน

ใช้ `suite_profile=product` เมื่อคำถามสำหรับการเผยแพร่ครอบคลุมช่องทาง MCP
การล้าง Cron/เอเจนต์ย่อย การค้นหาเว็บของ OpenAI หรือ OpenWebUI ใช้ `suite_profile=full`
เฉพาะเมื่อต้องการความครอบคลุมเส้นทางการเผยแพร่ Docker แบบเต็ม

## ค่าเริ่มต้นสำหรับการเผยแพร่

สำหรับตัวเลือกรุ่นเผยแพร่ สแต็กการพิสูจน์เริ่มต้นคือ:

1. `pnpm check:changed` และ `pnpm test:changed` สำหรับการถดถอยระดับซอร์ส
2. `pnpm release:check` สำหรับความสมบูรณ์ของอาร์ติแฟกต์แพ็กเกจ
3. โปรไฟล์ `package` ของการยอมรับแพ็กเกจ หรือเลนแพ็กเกจแบบกำหนดเองของการตรวจสอบ
   รุ่นเผยแพร่ สำหรับสัญญาการติดตั้ง/อัปเดต/รีสตาร์ต/Plugin
4. การตรวจสอบรุ่นเผยแพร่ข้ามระบบปฏิบัติการสำหรับตัวติดตั้ง การเริ่มต้นใช้งาน และพฤติกรรม
   เฉพาะแพลตฟอร์ม
5. ชุดทดสอบแบบใช้งานจริงเฉพาะเมื่อพื้นผิวที่เปลี่ยนแปลงเกี่ยวข้องกับพฤติกรรมของผู้ให้บริการหรือ
   บริการที่โฮสต์

บนเครื่องของผู้ดูแล เกตกว้างและการพิสูจน์ผลิตภัณฑ์ Docker/แพ็กเกจควรรัน
ใน Testbox เว้นแต่กำลังทำการพิสูจน์ภายในเครื่องอย่างชัดเจน

## ความเข้ากันได้กับรุ่นเก่า

การผ่อนปรนด้านความเข้ากันได้มีขอบเขตแคบและจำกัดเวลา:

- แพ็กเกจจนถึง `2026.4.25` รวมถึง `2026.4.25-beta.*` อาจยอมรับ
  ช่องว่างของเมทาดาทาแพ็กเกจที่เผยแพร่ไปแล้วในการยอมรับแพ็กเกจ
- แพ็กเกจ `2026.4.26` ที่เผยแพร่แล้วอาจแสดงคำเตือนสำหรับไฟล์ตราประทับเมทาดาทา
  การบิลด์ภายในเครื่องที่เผยแพร่ไปแล้ว
- แพ็กเกจที่ใหม่กว่าต้องเป็นไปตามสัญญาสมัยใหม่ ช่องว่างเดียวกันจะทำให้ล้มเหลวแทนที่จะ
  เตือนหรือข้าม

อย่าเพิ่มการย้ายข้อมูลใหม่ระหว่างการเริ่มต้นสำหรับรูปแบบเก่าเหล่านี้ ให้เพิ่มหรือขยายการซ่อมแซมของ doctor
จากนั้นพิสูจน์ด้วย `upgrade-survivor`, `published-upgrade-survivor` หรือ
`update-restart-auth` เมื่อคำสั่งอัปเดตเป็นเจ้าของการรีสตาร์ต

## การเพิ่มความครอบคลุม

เมื่อเปลี่ยนพฤติกรรมการอัปเดตหรือ Plugin ให้เพิ่มความครอบคลุมที่ชั้นต่ำที่สุดซึ่ง
สามารถล้มเหลวด้วยเหตุผลที่ถูกต้อง:

- ตรรกะเกี่ยวกับพาธหรือเมทาดาทาล้วน ๆ: ทดสอบหน่วยไว้ข้างซอร์ส
- พฤติกรรมของรายการไฟล์ในแพ็กเกจหรือไฟล์ที่ถูกแพ็ก: การทดสอบ `package-dist-inventory` หรือตัวตรวจสอบ tarball
- พฤติกรรมการติดตั้ง/อัปเดตผ่าน CLI: การยืนยันผลในเลน Docker หรือฟิกซ์เจอร์
- พฤติกรรมการย้ายข้อมูลของรุ่นที่เผยแพร่แล้ว: สถานการณ์ `published-upgrade-survivor`
- พฤติกรรมการรีสตาร์ตที่การอัปเดตเป็นผู้รับผิดชอบ: `update-restart-auth`
- พฤติกรรมของรีจิสทรี/แหล่งแพ็กเกจ: ฟิกซ์เจอร์ `test:docker:plugins` หรือเซิร์ฟเวอร์ฟิกซ์เจอร์ ClawHub
- พฤติกรรมของโครงสร้างการจัดวางหรือการล้างข้อมูลของการขึ้นต่อกัน: ยืนยันทั้งการทำงานขณะรันไทม์และขอบเขตระบบไฟล์ การขึ้นต่อกันของ npm อาจถูกยกระดับไว้ภายในโปรเจกต์ npm ที่ Plugin จัดการ ดังนั้นการทดสอบควรพิสูจน์ว่าโปรเจกต์ดังกล่าวได้รับการสแกน/ล้างข้อมูล แทนที่จะสมมติว่ามีเพียงโครงสร้าง `node_modules` ภายในแพ็กเกจของ Plugin

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

## การคัดแยกความล้มเหลว

เริ่มจากข้อมูลระบุอาร์ติแฟกต์:

- สรุป `resolve_package` ของการตรวจรับแพ็กเกจ: แหล่งที่มา เวอร์ชัน SHA-256 และชื่ออาร์ติแฟกต์
- อาร์ติแฟกต์ Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, บันทึกของเลน และคำสั่งสำหรับรันซ้ำ
- สรุปการคงอยู่หลังอัปเกรด: `.artifacts/upgrade-survivor/summary.json` ซึ่งรวมถึงเวอร์ชันฐาน เวอร์ชันที่เสนอ สถานการณ์ ระยะเวลาของแต่ละเฟส และความครอบคลุมของสูตรการกำหนดค่า

ควรรันซ้ำเฉพาะเลนที่ล้มเหลวโดยใช้อาร์ติแฟกต์แพ็กเกจเดิม แทนการรันชุดการทดสอบรุ่นทั้งหมดซ้ำ