docs: expand beta release validation roster

.agents/skills/openclaw-release-maintainer/SKILL.md

@@ -22,9 +22,18 @@ Use this skill for release and publish-time workflow. Keep ordinary development
 - Before release branching, pull latest `main` and confirm current `main` CI is
   green. Then branch from that commit so regular development can continue on
   `main` while release validation runs.
+- Before release branching, commit any dirty files in coherent groups, push,
+  pull/rebase, then run `/changelog` on `main` and commit/push/pull that
+  changelog rewrite immediately before creating the release branch.
 - Do not delete or rewrite beta tags after they leave the machine. If a
   published or pushed beta needs a fix, commit the fix on the release branch and
   increment to the next `-beta.N`.
+- For a beta release train, run the full pre-npm test roster before publishing
+  each beta. After a beta is published, run the smaller published-install roster
+  focused on install/update/Docker/Parallels. If anything fails, fix it on the
+  release branch, commit/push/pull, increment beta number, and repeat. Operators
+  may authorize up to 4 autonomous beta attempts; after 4 failed beta attempts,
+  stop and report.
 - Use `/changelog` before version/tag preparation so the top changelog section
   is deduped and ordered by user impact.
 - When any beta or stable release is live, make a best-effort Discord
@@ -84,7 +93,7 @@ Use this skill for release and publish-time workflow. Keep ordinary development
 Use the OpenClaw account's existing release-post style:
 
 - Format: `OpenClaw YYYY.M.D 🦞` or `🦞 OpenClaw YYYY.M.D is live`, blank line,
-  then 4-6 emoji-led bullets, blank line, one short punchline, then the release
+  then 3-4 emoji-led bullets, blank line, one short punchline, then the release
   link.
 - For beta: say `OpenClaw YYYY.M.D-beta.N 🦞` or `OpenClaw YYYY.M.D beta N is
 live`; keep it clearly beta and avoid implying stable promotion.
@@ -185,17 +194,46 @@ node --import tsx scripts/openclaw-npm-postpublish-verify.ts <published-version>
 ## Check all relevant release builds
 
 - Always validate the OpenClaw npm release path before creating the tag.
+- Source Peter's profile before live release validation so OpenAI and Anthropic
+  credentials are available without printing secrets:
+  `set -a; source "$HOME/.profile"; set +a`.
+- Release QA and Parallels validation for this train must use both
+  `OPENAI_API_KEY` and `ANTHROPIC_API_KEY`. If either is missing after sourcing
+  `.profile`, stop before starting the long lanes and report the missing key.
 - Default release checks:
   - `pnpm check`
+  - `pnpm check:test-types`
   - `pnpm check:architecture`
   - `pnpm build`
   - `pnpm ui:build`
   - `pnpm release:check`
   - `OPENCLAW_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke`
+- Full pre-npm beta test roster:
+  - default release checks above
+  - all Docker tests: `pnpm test:docker:all`, plus standalone Docker live lanes
+    not covered by the aggregate when operator says "all docker tests":
+    `pnpm test:docker:live-acp-bind`, `pnpm test:docker:live-cli-backend`, and
+    `pnpm test:docker:live-codex-harness`
+  - all Parallels install/update tests:
+    `pnpm test:parallels:npm-update -- --json` plus any needed individual
+    rerun lanes from `openclaw-parallels-smoke`
+  - all QA release validation:
+    OpenAI live suite with `openai/gpt-5.4` in fast mode, Anthropic live suite
+    with `anthropic/claude-opus-4-6`, and the repo-backed character evals
+- Post-published beta verification roster:
+  - `node --import tsx scripts/openclaw-npm-postpublish-verify.ts <beta-version>`
+  - install/update smoke against the published beta channel
+  - Docker install/update coverage that exercises the published beta package
+  - Parallels published beta install/update coverage with both OpenAI and
+    Anthropic provider keys available
+  - targeted QA reruns only for areas touched by fixes after the full pre-npm
+    roster, unless the operator requests the full QA roster again
 - Check all release-related build surfaces touched by the release, not only the npm package.
 - For beta-style full e2e batteries, hard-cap top-level long lanes instead of letting them run indefinitely. Use host `timeout --foreground`/`gtimeout --foreground` caps such as:
   - `45m` for `OPENCLAW_INSTALL_SMOKE_SKIP_NONROOT=1 pnpm test:install:smoke`
   - `90m` for `pnpm test:docker:all`
+  - `60m` each for standalone Docker live lanes
+  - `180m` for the full QA live OpenAI + Anthropic roster
   - Parallels caps from the `openclaw-parallels-smoke` skill
     If a lane hits its cap, stop and inspect/fix the affected lane before continuing; do not continue to wait on the same process.
 - Actual npm install/update phases are capped at 5 minutes. If `npm install -g`, installer package install, or `openclaw update` takes longer than 300s in release e2e, stop treating the run as healthy progress and debug the installer/updater or harness.
@@ -332,73 +370,81 @@ node --import tsx scripts/openclaw-npm-postpublish-verify.ts <published-version>
 
 1. Confirm the operator explicitly wants to cut a release.
 2. Choose the exact target version and git tag.
-3. Pull latest `main`, confirm `main` CI is green, and create
-   `release/YYYY.M.D` from that commit.
-4. Run `/changelog` for the target version, then make every repo version
-   location match that tag before creating it.
-5. Commit release preparation changes on the release branch and push the branch.
-6. Run the full preflight for all relevant release builds from the release
-   branch, including release checks, Docker install/update, and Parallels
-   install/update.
-7. For beta releases, skip mac app build/sign/notarize unless beta scope or a
-   release blocker specifically requires it. For stable releases, include the
-   mac app, signing, notarization, and appcast path.
-8. Confirm the target npm version is not already published.
-9. Create and push the git tag from the release branch.
-10. Create or refresh the matching GitHub release.
-11. Start `.github/workflows/openclaw-npm-release.yml` from the release branch
+3. Commit any dirty files in coherent groups, push, pull/rebase, and verify the
+   worktree is clean.
+4. Pull latest `main` and confirm current `main` CI is green.
+5. Run `/changelog` for the target version on `main`, commit the changelog
+   rewrite immediately, push, and pull/rebase.
+6. Create `release/YYYY.M.D` from that post-changelog `main` commit.
+7. Make every repo version location match the beta tag before creating it.
+8. Commit release preparation changes on the release branch and push the branch.
+9. Run the full pre-npm beta test roster from the release branch before any npm
+   preflight or publish.
+10. For beta releases, skip mac app build/sign/notarize unless beta scope or a
+    release blocker specifically requires it. For stable releases, include the
+    mac app, signing, notarization, and appcast path.
+11. Confirm the target npm version is not already published.
+12. Create and push the git tag from the release branch.
+13. Create or refresh the matching GitHub release.
+14. Start `.github/workflows/openclaw-npm-release.yml` from the release branch
     with `preflight_only=true`
     and choose the intended `npm_dist_tag` (`beta` default; `latest` only for
     an intentional direct stable publish). Wait for it to pass. Save that run id
     because the real publish requires it to reuse the prepared npm tarball.
-12. For stable releases, start `.github/workflows/macos-release.yml` in
+15. For stable releases, start `.github/workflows/macos-release.yml` in
     `openclaw/openclaw` and wait for the public validation-only run to pass.
-13. For stable releases, start
+16. For stable releases, start
     `openclaw/releases-private/.github/workflows/openclaw-macos-validate.yml`
     with the same tag and wait for the private mac validation lane to pass.
-14. For stable releases, start
+17. For stable releases, start
     `openclaw/releases-private/.github/workflows/openclaw-macos-publish.yml`
     with `preflight_only=true` and wait for it to pass. Save that run id because
     the real publish requires it to reuse the notarized mac artifacts.
-15. If any preflight or validation run fails, fix the issue on a new commit,
+18. If any preflight or validation run fails, fix the issue on a new commit,
     delete the tag and matching GitHub release, recreate them from the fixed
     commit, and rerun all relevant preflights from scratch before continuing.
     Never reuse old preflight results after the commit changes. For pushed or
     published beta tags, do not delete/recreate; increment to the next beta tag.
-16. Start `.github/workflows/openclaw-npm-release.yml` from the same branch with
+19. Start `.github/workflows/openclaw-npm-release.yml` from the same branch with
     the same tag for the real publish, choose `npm_dist_tag` (`beta` default,
     `latest` only when you intentionally want direct stable publish), keep it
     the same as the preflight run, and pass the successful npm
     `preflight_run_id`.
-17. Wait for `npm-release` approval from `@openclaw/openclaw-release-managers`.
-18. Run postpublish verification:
+20. Wait for `npm-release` approval from `@openclaw/openclaw-release-managers`.
+21. Run postpublish verification:
     `node --import tsx scripts/openclaw-npm-postpublish-verify.ts <published-version>`.
-19. Announce the beta/stable release on Discord best-effort using Peter's bot
+22. Run the post-published beta verification roster. If any lane fails after
+    the beta tag/package is pushed or published, fix, commit/push/pull,
+    increment to the next beta tag, and restart at the full pre-npm beta test
+    roster for the new beta. If a pre-npm lane fails before any tag/package
+    leaves the machine, fix and rerun the same intended beta attempt. Repeat up
+    to the operator's authorized beta-attempt limit, normally 4.
+23. Announce the beta/stable release on Discord best-effort using Peter's bot
     token from `.profile`.
-20. If the operator requested beta only, stop after beta verification and the
+24. If the operator requested beta only, stop after beta verification and the
     announcement.
-21. If the stable release was published to `beta`, start the private
+25. If the stable release was published to `beta`, start the private
     `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
     workflow after beta validation passes to promote that stable version from
     `beta` to `latest`, then verify `latest` now points at that version.
-22. If the stable release was published directly to `latest` and `beta` should
+26. If the stable release was published directly to `latest` and `beta` should
     follow it, start that same private dist-tag workflow to point `beta` at the
     stable version, then verify both `latest` and `beta` point at that version.
-23. For stable releases, start
+27. For stable releases, start
     `openclaw/releases-private/.github/workflows/openclaw-macos-publish.yml`
     for the real publish with the successful private mac `preflight_run_id` and
     wait for success.
-24. Verify the successful real private mac run uploaded the `.zip`, `.dmg`,
+28. Verify the successful real private mac run uploaded the `.zip`, `.dmg`,
     and `.dSYM.zip` artifacts to the existing GitHub release in
     `openclaw/openclaw`.
-25. For stable releases, download `macos-appcast-<tag>` from the successful
+29. For stable releases, download `macos-appcast-<tag>` from the successful
     private mac run, update `appcast.xml` on `main`, and verify the feed. Merge
     or cherry-pick release branch changes back to `main` after stable succeeds.
-26. For beta releases, publish the mac assets only when intentionally requested;
+30. For beta releases, publish the mac assets only when intentionally requested;
     expect no shared production
     `appcast.xml` artifact and do not update the shared production feed unless a
     separate beta feed exists.
-27. After publish, verify npm and the attached release artifacts.
+31. After publish, verify npm and the attached release artifacts.
 
 ## GHSA advisory work