OpenClaw 사전 릴리스 플러그인 테스팅은(는) 무엇을 하나요?
사용자가 플러그인 릴리스 확신, 플러그인 라이프사이클 정밀 검사, 패키지-아티팩트 플러그인 증명, 또는 "릴리스 전에 무엇을 더 테스트해야 할까?"와 같은 질문을 할 때 이 스킬을 사용하세요. 이 스킬은 openclaw-testing을 보완합니다. 가장 저렴한 안전한 러너를 선택하거나 실패한 레인을 디버깅할 때는 해당 스킬도 함께 사용하세요.
목표
플러그인 시스템을 소스 테스트가 아닌 제품 표면으로 입증합니다:
- 번들 플러그인 라이프사이클: 설치, 검사, 활성화, 비활성화, 제거
- 깨끗한
HOME에서의 패키지 아티팩트 동작 - doctor/fix/config 검증 및 멱등성
- 구성 검색 및 구성 라운드트립
- 상태/로그 가시성 및 진단
- 플러그인 메타데이터 스냅샷을 포함한 게이트웨이 시작/부트스트랩
- 실제 외부 플러그인을 위한 공개 SDK 호환성
- 안전한 자격 증명이 존재하는 경우에만 라이브-유사 공급자/채널 프로브
첫 번째 확인
OpenClaw 저장소 루트에서:
pnpm docs:list
git status --short --branch
readlink node_modules
pnpm changed:lanes --json
Codex 워크트리(.codex/worktrees)에서 node_modules는 메인 OpenClaw 체크아웃에 대한 심볼릭 링크여야 합니다. 거기서 pnpm install을 실행하지 마세요. 광범위하거나 패키지가 많은 증명에는 Blacksmith Testbox 또는 GitHub Actions를 사용하세요.
러너 선택
다음 순서를 선호합니다:
- GitHub Package Acceptance: 설치 가능한 패키지 제품 증명용
ci-build-artifacts-testbox.ymlTestbox: Docker/패키지 레인에 시드된dist,dist-runtime및 패키지 캐시가 필요할 때ci-check-testbox.ymlTestbox: 소스 검사, 대상 Vitest, 패키지 경계 검사 또는 집중 Docker 레인용- 로컬 대상 명령어만: 작은 형식/정적/단위 프로브용
오래된 스파스 워크트리에서 긴 패키지 Docker 실행을 피하세요. Testbox 동기화가 수백 개의 변경된 파일을 보고하거나 패키지 입력을 삭제하기 시작하면 중지하고 현재 main에서 새 상자를 준비하거나 Package Acceptance로 전환하세요.
기존 기준선
새 커버리지를 발명하기 전에 다음을 실행하거나 확인하세요:
OPENCLAW_TESTBOX=1 pnpm check:changed
pnpm run test:extensions:package-boundary:canary
pnpm run test:extensions:package-boundary:compile
pnpm test:docker:plugins
OPENCLAW_PLUGINS_E2E_CLAWHUB=0 pnpm test:docker:plugins
pnpm test:docker:plugin-update
pnpm test:docker:bundled-channel-deps:fast
전체 번들 설치/제거 증명을 위해 패키지된 검사를 샤딩하세요:
OPENCLAW_BUNDLED_PLUGIN_SWEEP_TOTAL=8 \
OPENCLAW_BUNDLED_PLUGIN_SWEEP_INDEX=<0-7> \
pnpm test:docker:bundled-plugin-install-uninstall
예상 현재 패키지 범위: 샤드 0-7에 걸친 116개의 공개 번들 플러그인. 비공개 QA 플러그인은 패키지에 명시적으로 포함되지 않는 한 소스 모드 전용입니다.
확신 매트릭스
사전 릴리스 서명을 위해 이 매트릭스를 사용하세요. 통과/실패, 실행 URL/Testbox ID, 패키지 SHA/버전, 건너뛴 라이브 이유를 기록하세요.
| 표면 | 증명 | 선호 러너 |
|---|---|---|
| 패키지 아티팩트 | Package Acceptance suite_profile=package 또는 사용자 정의 레인 | GitHub Actions |
| 번들 라이프사이클 | 8-샤드 test:docker:bundled-plugin-install-uninstall | Testbox 또는 릴리스 Docker |
| 외부 플러그인 | test:docker:plugins 및 plugins-offline | Testbox/package acceptance |
| 업데이트 무효 | test:docker:plugin-update | Testbox/package acceptance |
| 채널 런타임 종속성 | test:docker:bundled-channel-deps:fast 및 주요 채널 | Testbox/package acceptance |
| Doctor/fix | 시드된 잘못된 구성 + doctor --fix --non-interactive | 새 Docker/Testbox 하네스 |
| 구성 라운드트립 | config set/get, inspect, doctor, reload, diff hash | 새 Docker/Testbox 하네스 |
| 게이트웨이 부트스트랩 | 깨끗한 HOME, 플러그인 그룹 활성화/비활성화, 상태 JSON | 새 Docker/Testbox 하네스 |
| SDK 호환성 | SDK 하위 경로를 사용하는 디렉토리, tgz 및 file: 외부 플러그인 | test:docker:plugins 및 새 스모크 |
| 라이브-유사 | 현재 환경에 대해서만 수정된 공급자/채널 프로브 | Testbox 라이브 레인 |
Package Acceptance 계획
릴리스 브랜치, 베타 또는 후보 패키지를 검증할 때 사용하세요:
gh workflow run package-acceptance.yml \
--repo openclaw/openclaw \
--ref main \
-f workflow_ref=main \
-f source=ref \
-f package_ref=<branch-or-sha> \
-f suite_profile=custom \
-f docker_lanes='plugins-offline plugin-update bundled-channel-deps-compat doctor-switch update-channel-switch config-reload mcp-channels npm-onboard-channel-agent' \
-f telegram_mode=mock-openai
게시된 베타 증명에는 source=npm -f package_spec=openclaw@beta를 사용하세요. 릴리스 프로세스에서 달리 명시하지 않는 한 workflow_ref를 신뢰할 수 있는 현재 하네스 코드로 유지하세요.
새 Testbox 하네스 계획
더 많은 확신이 필요하면 하나의 패키지 tarball과 샤딩된 플러그인 목록을 사용하는 plugin-lifecycle-matrix Docker 레인을 추가하거나 실행하세요. 플러그인당:
- 깨끗한
HOME으로 시작합니다. plugins list --json을 캡처합니다.plugins install <id>를 실행합니다.plugins inspect <id> --json을 실행합니다.plugins disable <id>를 실행한 후 비활성화된 가시성을 확인합니다.plugins enable <id>를 실행합니다(구성이 필요한 플러그인은 구성 없이 제외).plugins registry --refresh를 실행합니다.doctor --non-interactive를 실행합니다.plugins uninstall <id> --force를 실행합니다.- 구성 항목, 허용/거부 잔류물, 설치 레코드, 관리 디렉토리 또는 번들된
dist/extensions/...로드 경로가 남아 있지 않은지 확인합니다. - 진단에
level: "error"가 포함되지 않고 출력에서 비밀처럼 보이는 값을 가리는지 확인합니다.
memory-lancedb는 특별히 취급합니다: 구성이 필요합니다. 먼저 구성 없이 설치가 활성화되지 않는지 확인한 다음 두 번째 구성된 케이스를 실행합니다.
Doctor/Fix 매트릭스
잘못된 상태를 시드하고 doctor --fix --non-interactive가 이를 복구하도록 요구한 후 doctor를 다시 실행하여 멱등성을 요구합니다:
- 오래된
plugins.allow - 오래된
plugins.entries - 누락된 채널 플러그인에 대한 오래된 채널 구성
- 유효하지 않은
plugins.entries.<id>.config plugins.load.paths에 패키지된 번들 경로- 레거시
plugins.installs - 런타임 종속성을 스테이징하지 않아야 하는 비활성화된 채널/플러그인 구성
- 수정되지 않은 상태로 유지되어야 하는 루트 소유 글로벌 패키지 트리
게이트웨이 부트스트랩 매트릭스
Docker에서 깨끗한 상태로 패키지된 OpenClaw를 시작합니다:
- 공급자 플러그인 활성화, 자격 증명 없음: 준비 상태, 경고 있음, 충돌 없음
- 채널 플러그인이 비활성화되도록 구성됨: 런타임 종속성 스테이징되지 않음
- 시작 활성화 플러그인 활성화: 준비 상태 및 상태에 반영됨
- 유효하지 않은 단일 플러그인 구성: 잘못된 플러그인 건너뜀/격리, 나머지는 유지
다음을 확인합니다:
- 게이트웨이가 준비 상태에 도달함
openclaw status --json에 플러그인 진단 정보 포함openclaw plugins inspect --all --json이 구문 분석 가능함- 패키지 트리가 변경되지 않음
- 로그에 원시 토큰 없음
구성 라운드트립 대표 플러그인
심층 구성 라운드트립에는 모든 플러그인 대신 대표 플러그인 패밀리를 사용하세요:
- 공급자:
openai,anthropic,mistral,openrouter - 채널:
telegram,discord,slack,whatsapp - 메모리:
memory-lancedb - 기능/런타임:
browser,acpx,tokenjuice
각 대표 플러그인에 대해:
- 가능하면 CLI를 통해 구성을 작성합니다.
config get또는 JSON을 통해 다시 읽습니다.plugins inspect를 실행합니다.doctor --non-interactive를 실행합니다.- 해당되는 경우 게이트웨이 구성 리로드를 트리거합니다.
- 무효 명령어 전후의 구성 해시를 비교합니다.
외부 SDK 스모크
패키지 Docker 레인에서 작은 외부 플러그인을 만들고 다음에서 설치합니다:
- 로컬 디렉토리
.tgzfile:npm 스펙
CJS 및 ESM 형태를 다루고, 최소한 하나의 플러그인은 집중된 openclaw/plugin-sdk/* 하위 경로를 가져와야 합니다. plugins inspect가 해당 도구, 게이트웨이 메서드, CLI 명령어 또는 서비스를 볼 수 있는지 확인합니다.
라이브-유사 프로브 규칙
라이브-유사 작업 전에 Testbox에서 허용된 환경을 소싱하고 수정된 가용성 매트릭스를 생성합니다: 값이 아닌 있음/없음만.
존재하는 자격 증명에 대해서만 프로브를 실행하세요. 사용자에게 표시되는 메시지를 보내는 것보다 인증/카탈로그/상태 프로브를 선호하세요. 프로브가 외부 사용자, 채널 또는 작업 공간에 연락할 수 있는 경우 중지하고 사용자에게 물어보세요.
보고
다음 형식으로 보고하세요:
package/ref:
tbx ids / run urls:
matrix:
bundled lifecycle:
package acceptance:
doctor/fix:
gateway bootstrap:
config round-trip:
sdk external:
live-ish:
failures:
skips:
next highest-value gap:
실패가 제품 동작이 아닌 Testbox 동기화/환경 손상인 경우 명확히 말하고, 깨끗한 재실행 또는 현재-main 비교로 이를 입증하세요.