Evidence to keep

Evidence to keep

Keep the Full Release Validation summary as the release-level index. It links child run ids and includes slowest-job tables. Classify failures as product, harness/tooling/provenance, infrastructure/credential, or wrapper. Only a confirmed product failure changes the Code SHA. Use one diagnosis, one fix when needed, and one narrow retry, then reassess; do not automatically rerun all. Narrow evidence is not publish authorization by itself.

Decide blocker or flake for every failed test. Every selected failure blocks publication.

Linux, Windows, and macOS Gateway cross-OS install and upgrade lanes are required for beta, stable, and full validation. The manifest records their actual conclusions, and failures block the release decision. Keep diagnostic artifacts; never report a failed, omitted, or deferred lane as passed.

For a regular release, record Code SHA and Release SHA even when they are the same commit. In that case, retain the successful full validation parent and its exact prepared publication artifacts for both roles. For a later changelog-only Release SHA using evidence reuse, also record the reuse policy, complete changed-path set, green Code SHA parent run, and Release SHA parent run. For extended-stable, record the canonical branch, exact release SHA, accepted producer identity, parent run id and attempt, workflow ref, every child run, and any frozen-target compatibility repair or intentional omission.

Useful artifacts:

• The attempt-one full-release-execution-plan-<parent-run-id> and current full-release-validation-<parent-run-id>-<attempt> manifest retain source facts and registry admission, including observations, exact selection, immutable upload identity, and admission-time freshness. Reuse retains distinct original and current records without restamping either. Authentication requires the original successful admission and guarded upload, not an overall successful sealer job: an interrupted sealer can still write and upload a complete plan. Later attempts never replace that original artifact.
• release-package-under-test from OpenClaw Release Checks
• Docker release-path artifacts under .artifacts/docker-tests/
• Package Acceptance package-under-test and Docker acceptance artifacts
• Cross-OS release-check artifacts for each OS and suite
• QA parity, runtime parity, and selected Matrix, Buzz, Telegram, Discord, WhatsApp, or Slack artifacts

Readers authenticate retained evidence; they do not refresh registry observations or expire it by the current clock. Registry admission is not publication authority or a promise that registry state is unchanged. Final writers keep their own trust, approval, content, and readback checks. Known enclosing evidence is budgeted before fanout, but later job/attempt growth can still exceed the unchanged final artifact limit and fail sealing; evidence is not truncated to fit.

Workflow files

• .github/workflows/full-release-validation.yml
• .github/workflows/full-release-candidate.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-live-and-e2e-checks-reusable.yml
• .github/workflows/plugin-prerelease.yml
• .github/workflows/install-smoke.yml
• .github/workflows/install-smoke-reusable.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-performance.yml
• .github/workflows/npm-telegram-beta-e2e.yml