Skip to main content

openclaw-release-validation

Validate OpenClaw release candidates through OCM using the built OpenClaw artifact, a broad reusable scenario matrix, copied existing-user state, clean new-user state, concise pass/fail reporting, and focused failure notes. Use when asked to test OpenClaw origin/main, release readiness, upgrade behavior, plugins, services, channels, doctor recovery, packaging, or broad release risk.

소스 정보

저장소
openclaw/ocm
최근 소스 활동
2026년 7월 12일 18:53
감지된 SKILL.md 언어
영어
스타
21
포크
20

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
3 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
openclaw-release-validation
description
Validate OpenClaw release candidates through OCM using the built OpenClaw artifact, a broad reusable scenario matrix, copied existing-user state, clean new-user state, concise pass/fail reporting, and focused failure notes. Use when asked to test OpenClaw origin/main, release readiness, upgrade behavior, plugins, services, channels, doctor recovery, packaging, or broad release risk.
# OpenClaw Release Validation ## Overview Run deep release validation for OpenClaw through OCM. Use the repo scenario matrix as the source of truth, test built software instead of dev wrappers, and produce a quiet report: quick pass/fail per scenario, with detail only for failures, blocked cases, or release-risk notes. ## Required Reading Before running tests, read: - `../../README.md` - `../../docs/USAGE.md` - `references/release-validation-paths.md` - `../../docs/OPENCLAW_RELEASE_SCENARIO_MATRIX.md` - the current validation report if one exists under `/path/to/release-validation/` If repo-level AGENTS instructions are present, read and follow them first. ## Workflow 1. Confirm paths, permissions, OpenClaw source repo, and report root. Set `OCM_BIN=<ocm-repo>/target/debug/ocm`, verify it is executable, and invoke that absolute binary for every OCM command in the run. 2. Create a unique run id. Derive the worktree, runtime, env, report, and cleanup names from that id so concurrent validations cannot share mutable resources. 3. Read the OpenClaw source repo's `origin` URL without fetching or changing that shared checkout. Create per-run Git metadata from that remote, using the source repo only as a clone-time read-only object cache and dissociating the clone from it. Then resolve `origin/main` to an immutable commit and create a clean detached worktree for it. Record the commit before building. 4. In the detached worktree, run `pnpm install --frozen-lockfile`, `pnpm check`, and `pnpm build`, then require `git status --porcelain` to remain empty. Build the primary validation target with `"$OCM_BIN" runtime build-local <run-runtime> --repo <run-worktree> --force`, then run `"$OCM_BIN" runtime verify <run-runtime>` and recheck worktree cleanliness. This package-shaped runtime is the target for the matrix. Direct `<run-worktree>/openclaw.mjs` execution is limited to the S02 source-artifact boot smoke check. 5. Review OCM command usage for the touched scenario using `README.md`, `docs/USAGE.md`, and targeted help from the same `"$OCM_BIN"`: `help start`, `help service`, `help logs`, `help upgrade`, and `help env`. 6. Review changelogs and commits since the last release to identify changed surfaces and extra tests. 7. Prepare existing-user fixtures before mutation: - use `"$OCM_BIN" env clone` only when clearing sessions, logs, and backups is intended; - for S20, copy the source env's `.openclaw` directory into the run root, import that copy with `"$OCM_BIN" adopt import`, and assert the expected session fixture exists before the upgrade. 8. Treat every copied or cloned user fixture as secret-bearing. Keep its service stopped and make no provider, channel, webhook, browser, or other external connection by default. Use a credential-free fresh env, mocks, or dedicated test accounts for networked checks. Real external access requires explicit authorization for the run. 9. Run the broad scenario matrix from `docs/OPENCLAW_RELEASE_SCENARIO_MATRIX.md`. 10. For each scenario, test both clean new-user state and copied existing-user state when applicable. 11. Run OpenClaw commands through `"$OCM_BIN" @<env> -- ...` unless the scenario explicitly requires direct execution. Verify OCM env runs expose `OPENCLAW_SERVICE_REPAIR_POLICY=external` as part of normal env execution; do not run broad LaunchAgent/service mutation tests unless the release changed service behavior. 12. Add extra checks for changed release surfaces, but keep them attached to the closest scenario. 13. Record a concise scenario table while testing; add detailed notes only for failures, blocked scenarios, or explicit gaps. 14. Before reporting, verify the detached worktree still points at the recorded commit and the runtime identity matches the run. Redact credentials, private endpoints, user identifiers, and secret-bearing command output. 15. Destroy run-owned envs, then run `"$OCM_BIN" runtime remove <run-runtime>`. Clean up only resources carrying the current run id. Inspect worktree status before removal and do not force-remove an unclean or unowned worktree. ## Non-Negotiables - Do not use the active `../openclaw` repo. - Do not substitute `pnpm openclaw` or the source-tree executable for validation of the package-shaped runtime. - Do not mutate the real existing-user env; copy it into the run root first. - Do not assume `"$OCM_BIN" env clone` preserves sessions, logs, or backups. - Do not start a copied user's gateway or make external requests with retained credentials unless the run explicitly authorizes the destination and account. - Do not include credentials or raw secret-bearing config in the report. - Do not leave temporary services or LaunchAgents running. - Do not leave the per-run package runtime installed after its envs are destroyed. - Do not clean up resources that are not owned by the current run id. - Do not mark a scenario passed unless postconditions were checked. - Do not rely on reasoning alone for release readiness; run real command flows. ## Reporting Use these statuses: - `pass`: command path completed and postconditions were checked - `fail`: reproducible breakage with exact command and output recorded - `blocked`: could not run, with blocker and next action recorded - `needs coverage`: important case not yet exercised in this run - `n/a`: scenario does not apply to that user type Report shape: - Start with OCM/OpenClaw commits, package runtime identity, baseline reviewed, run id, temp paths, and fixture modes used. - Include one summary row per scenario with New User, Existing User, Result, and Notes. - For each failure, include impact, repro commands, expected, actual, and a short "Paste to fixer" summary. - Avoid noisy successful command logs; keep command evidence in the report only where it proves a result or explains a failure. When a user asks for release validation, run the matrix and update the report; do not stop at a plan unless they explicitly ask for planning only.
GitHub에서 보기