chore(release): prepare v0.41.0

[steipete]

Summary

• prepare the dated v0.41.0 changelog from every user-visible merge after v0.40.1, including the just-landed RunPod SSH-key fix and contributor thanks
• bump the Worker package version and both root lockfile entries to 0.41.0
• add a deliberately blocked authorize-source record whose immutable tag object and source commit remain pending until the maintainer signs the release tag

Release scope includes work tracked in #1208. The late merge #1203 is included and credited to @morluto.

Verification

$ gofmt -w <all tracked Go files>
$ go vet ./...
# exit 0

$ go test -race ./...
# all packages passed; internal/cli 234.426s

$ scripts/test-go-modules.sh
# root module and worker/cloudflare-container-runner passed

$ npm run format:check --prefix worker
# All matched files use the correct format.
$ npm run lint --prefix worker
$ npm run check --prefix worker
$ npm run check:node --prefix worker
$ npm test --prefix worker
# 37 files passed, 2 skipped; 1158 tests passed, 3 skipped
$ npm run build --prefix worker
$ npm run build:cloudflare-dynamic-workers --prefix worker
$ npm run build:node --prefix worker
# all dry-run/runtime builds passed

$ go build -trimpath -o bin/crabbox ./cmd/crabbox
$ bin/crabbox --version
0.15.0

$ .agents/skills/autoreview/scripts/autoreview --mode local --parallel-tests "go test -race ./internal/providers/runpod" --stream-engine-output
# autoreview clean: no accepted/actionable findings reported
# runpod race test passed

Fresh local npm ci --prefix worker was attempted repeatedly but registry tarball requests timed out. The local Worker proof used a lockfile-identical dependency tree from the adjacent exact-origin-main validation checkout, verified with npm ls --prefix worker --all. Hosted CI run https://github.com/openclaw/crabbox/actions/runs/30671525807 passed all eight jobs on exact head 132b02ee27db382bd3d08c2489191dbbb6b72b86, including its fresh Worker install, Go race/all-modules/coverage gate, scripts, docs, Apple VM, Windows cancellation, connector lifecycles, and GoReleaser snapshot. Dependency freshness was inspected with go list -m -u -json all and npm outdated --prefix worker --json; a broad dependency refresh already landed in #1194, and newer post-refresh upstream patch/minor releases were not mixed into this frozen release-preparation diff.

The coordinator-backed live smoke was not run because it requires coordinator credentials, which this preparation lane is explicitly forbidden to touch. No tag, producer, signing, draft, publication, npm publish, or Homebrew action was run.

Maintainer handoff

The release contract says:

“A release begins with an annotated signed vMAJOR.MINOR.PATCH tag and two captured immutable Git identities: the tag-object ID; the peeled source-commit ID.”

“Run from a clean Crabbox repository. Replace vX.Y.Z only with a new signed tag whose protected record says ready; v0.37.0 deliberately fails the first publishability check. Preserve the captured values for every later command.”

“The credential-free producer may run without the signing wrapper.”

“Building a candidate, uploading a private draft, verifying it, publishing it, and updating Homebrew are distinct gates. Approval for one gate does not authorize the next.”

After this PR merges, run these gates in order from a clean main checkout.

1. Sign and push the immutable tag

Required credential: the repository-approved SSH signing key must be available through the maintainer's configured Git signing agent. No GitHub Release, Homebrew, Actions, codesign, or notary environment variable is required for tag creation; repository push authentication is required only for the final push.

git switch main
git pull --ff-only origin main
test -z "$(git status --porcelain --untracked-files=all)"

TAG=v0.41.0
git tag -s "$TAG" -m "$TAG"
test "$(git for-each-ref --format='%(contents:subject)' "refs/tags/$TAG")" = "$TAG"
git tag -v "$TAG"
TAG_OBJECT=$(git rev-parse "refs/tags/$TAG")
TAG_COMMIT=$(git rev-parse "refs/tags/$TAG^{commit}")
test "${#TAG_OBJECT}" -eq 40
test "${#TAG_COMMIT}" -eq 40
git push origin "refs/tags/$TAG"

The annotation subject is deliberately the bare v0.41.0; never replace it with descriptive text.

2. Authorize the exact signed source in a protected PR

Required credential: normal GitHub branch/PR authentication only. No release, Homebrew, Actions, codesign, or notary credential is required. Recompute the IDs from the immutable tag, replace both pending sentinels, set the record to ready, and remove the blocker:

git switch main
git pull --ff-only origin main
git switch -c release/v0.41.0-authorize-source

TAG=v0.41.0
TAG_OBJECT=$(git rev-parse "refs/tags/$TAG")
TAG_COMMIT=$(git rev-parse "refs/tags/$TAG^{commit}")
node - "$TAG_OBJECT" "$TAG_COMMIT" <<'NODE'
const fs = require('node:fs');
const [tagObject, sourceCommit] = process.argv.slice(2);
const file = 'release/records/v0.41.0.json';
const record = JSON.parse(fs.readFileSync(file, 'utf8'));
record.tagObject = tagObject;
record.sourceCommit = sourceCommit;
record.publicationStatus = 'ready';
delete record.blocker;
fs.writeFileSync(file, `${JSON.stringify(record, null, 2)}\n`);
NODE

git diff --check
git diff -- release/records/v0.41.0.json
git add release/records/v0.41.0.json
git commit -m "chore(release): authorize v0.41.0 source"
git push -u origin release/v0.41.0-authorize-source
printf '%s\n' 'Authorize the exact signed v0.41.0 tag object and peeled source commit for the credential-free producer.' >/tmp/v0.41.0-record-pr.md
gh pr create --repo openclaw/crabbox --base main --head release/v0.41.0-authorize-source --title "chore(release): authorize v0.41.0 source" --body-file /tmp/v0.41.0-record-pr.md

Stop until that record-only PR has required review, green CI, and is merged. Then return to clean main.

3. Run only the credential-free producer

Required platform/tools: Apple Silicon macOS and the exact repository-pinned Go, GoReleaser, Swift, Xcode, macOS, and architecture requirements checked by the producer. Every variable below must be absent, not merely empty: GH_TOKEN, GITHUB_TOKEN, HOMEBREW_TAP_GITHUB_TOKEN, HOMEBREW_GITHUB_API_TOKEN, ACTIONS_RUNTIME_TOKEN, ACTIONS_ID_TOKEN_REQUEST_TOKEN, CODESIGN_IDENTITY, MAC_RELEASE_CODESIGN_IDENTITY, and NOTARYTOOL_KEYCHAIN_PROFILE.

git switch main
git pull --ff-only origin main
test -z "$(git status --porcelain --untracked-files=all)"

TAG=v0.41.0
TAG_OBJECT=$(git rev-parse "refs/tags/$TAG")
TAG_COMMIT=$(git rev-parse "refs/tags/$TAG^{commit}")
VERIFIER_COMMIT=$(git rev-parse HEAD)

unset GH_TOKEN GITHUB_TOKEN HOMEBREW_TAP_GITHUB_TOKEN HOMEBREW_GITHUB_API_TOKEN
unset ACTIONS_RUNTIME_TOKEN ACTIONS_ID_TOKEN_REQUEST_TOKEN
unset CODESIGN_IDENTITY MAC_RELEASE_CODESIGN_IDENTITY NOTARYTOOL_KEYCHAIN_PROFILE

DEFAULT_BRANCH=main \
RELEASE_TAG="$TAG" \
EXPECTED_TAG_OBJECT="$TAG_OBJECT" \
EXPECTED_TAG_COMMIT="$TAG_COMMIT" \
TRUSTED_HEAD="$VERIFIER_COMMIT" \
REQUIRE_PUBLISHABLE=1 \
  scripts/verify-release-source.sh

BUILD_OUTPUT=$(scripts/build-release-candidate.sh \
  "$TAG" "$TAG_OBJECT" "$TAG_COMMIT" "$PWD/dist-release-unsigned")
printf '%s\n' "$BUILD_OUTPUT"
CANDIDATE_MANIFEST_SHA256=$(printf '%s\n' "$BUILD_OUTPUT" | sed -n 's/^Candidate manifest SHA-256: //p')
test "${#CANDIDATE_MANIFEST_SHA256}" -eq 64

Stop there. Signing/packaging, draft creation, native verification, publication, and Homebrew each require their own later authorization under docs/RELEASING.md.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 1, 2026, 2:45 PM ET / 18:45 UTC.

ClawSweeper review

What this changes

The branch turns the Unreleased changelog into a dated v0.41.0 section, bumps the Worker package version metadata, and adds a blocked source-authorization record for the later signed-tag release gate.

Merge readiness

⛔ Blocked until real behavior proof is added - 6 items remain

This PR is still necessary for the planned v0.41.0 release, but it cannot merge as-is: its changelog edit conflicts with newer current-main release notes, and the body does not contain after-change evidence that the pending authorization record fails closed before tag authorization.

Priority: P2
Reviewed head: 132b02ee27db382bd3d08c2489191dbbb6b72b86

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The patch follows the existing release-record design, but it is conflicted with current main and lacks real release-gate proof.
Proof confidence	🧂 unranked krab (1/6)	Needs real behavior proof before merge: The PR body reports CI and static validation but does not show redacted after-change terminal output demonstrating that the pending v0.41.0 record rejects the producer or publishability verification before signed-tag authorization. Add that proof without private paths, credentials, or tokens; updating the PR body should trigger re-review, or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs real behavior proof before merge: The PR body reports CI and static validation but does not show redacted after-change terminal output demonstrating that the pending v0.41.0 record rejects the producer or publishability verification before signed-tag authorization. Add that proof without private paths, credentials, or tokens; updating the PR body should trigger re-review, or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	5 items	Current-main changelog conflict: Current main still has an Unreleased section and added two entries after this PR's base: protected coordinator-token rotation and a protected broker soak canary. The branch changes the same heading and surrounding list, so those entries must be incorporated into the dated release notes. Three-way merge is conflicted: A merge preview produces conflict markers in the Added changelog section between the PR’s dated release text and current main’s newer Unreleased entries; this matches GitHub’s dirty merge state. Fail-closed release boundary exists: The verifier requires the record to match the exact tag object and source commit, and rejects a blocked record when publishability is required. The proposed pending record is therefore directionally consistent, but the PR body lacks an observed terminal result for that path.
Findings	1 actionable finding	[P2] Rebase the release changelog onto current main
Security	None	None.

How this fits together

Crabbox’s controlled release path combines the changelog and Worker version metadata with a protected record that binds a signed tag object and source commit. That record is checked before the credential-free release producer can create a candidate, followed by separately authorized publication steps.

flowchart LR
  A[User-visible merged changes] --> B[Changelog and Worker version]
  B --> C[Signed v0.41.0 tag]
  C --> D[Protected source record]
  D --> E[Release-source verification]
  E --> F[Credential-free candidate producer]
  F --> G[Later authorized publication]

Loading

Before merge

• Add real behavior proof - Needs real behavior proof before merge: The PR body reports CI and static validation but does not show redacted after-change terminal output demonstrating that the pending v0.41.0 record rejects the producer or publishability verification before signed-tag authorization. Add that proof without private paths, credentials, or tokens; updating the PR body should trigger re-review, or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Rebase the release changelog onto current main (P2) - This heading change conflicts with the newer current-main Unreleased entries for coordinator-token rotation and the broker soak canary. The merge preview contains conflict markers; resolving it with the branch side would leave those current changes out of the v0.41.0 notes. Rebase and retain them in the dated section before merge.
• Resolve merge risk (P1) - Merging without a rebase would require resolving a real changelog conflict; choosing the branch side could omit current-main coordinator-token rotation and broker soak-canary notes from v0.41.0.
• Resolve merge risk (P1) - The authorization record governs a controlled release path, and the claimed fail-closed pending state has not been demonstrated with redacted after-change terminal output.
• Resolve merge risk (P1) - The PR must remain blocked until a release owner completes the signed-tag and protected authorization-record gates; it must not be treated as publication authorization.
• Complete next step (P2) - The concrete rebase is straightforward, but the missing proof must come from a release owner or contributor’s real controlled setup; ClawSweeper cannot supply that evidence on their behalf.

Findings

• [P2] Rebase the release changelog onto current main — CHANGELOG.md:3

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Release preparation surface	4 files changed: 23 additions, 11 deletions	The patch is focused on release metadata and the authorization record, so the main merge concern is correctness of the release boundary and notes rather than broad code churn.
Mainline drift	2 newer changelog commits after the PR base	Both entries touch the Unreleased section that this PR converts into the v0.41.0 release section.

Merge-risk options

Maintainer options:

1. Refresh and prove the release gate (recommended)
   Rebase onto current main, resolve the changelog by retaining the new release notes, and add redacted output showing the blocked record rejects release production before authorization.
2. Pause the release preparation
   Keep the PR open but defer it if the release scope or timing is no longer intended, rather than merging metadata that does not reflect current main.

Technical review

Best possible solution:

Rebase onto current main, include every current Unreleased entry in the v0.41.0 notes, retain the record’s blocked state, and attach a redacted terminal transcript showing verify-release-source.sh or the producer rejects the pending record before the signed-tag authorization PR exists.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is release-preparation work, so the meaningful validation is a controlled release-gate check rather than an end-user bug reproduction. The current merge conflict is directly reproducible from the three-way merge preview.

Is this the best way to solve the issue?

No, not in its current form: the blocked-record design matches the existing verifier, but the branch must be rebased and its release notes refreshed against current main before it is a safe release-preparation change.

Full review comments:

• [P2] Rebase the release changelog onto current main — CHANGELOG.md:3
  This heading change conflicts with the newer current-main Unreleased entries for coordinator-token rotation and the broker soak canary. The merge preview contains conflict markers; resolving it with the branch side would leave those current changes out of the v0.41.0 notes. Rebase and retain them in the dated section before merge.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.98

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 0171ae2ee19f.

Labels

Label justifications:

• P2: This is a bounded release-preparation problem that needs correction before a planned release but is not a live user-facing outage.
• merge-risk: 🚨 other: The PR changes the controlled release metadata and source-authorization path, where an incorrect merge can produce incomplete release notes or an invalid release gate.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body reports CI and static validation but does not show redacted after-change terminal output demonstrating that the pending v0.41.0 record rejects the producer or publishability verification before signed-tag authorization. Add that proof without private paths, credentials, or tokens; updating the PR body should trigger re-review, or a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

What I checked:

• Current-main changelog conflict: Current main still has an Unreleased section and added two entries after this PR's base: protected coordinator-token rotation and a protected broker soak canary. The branch changes the same heading and surrounding list, so those entries must be incorporated into the dated release notes. (CHANGELOG.md:3, 0171ae2ee19f)
• Three-way merge is conflicted: A merge preview produces conflict markers in the Added changelog section between the PR’s dated release text and current main’s newer Unreleased entries; this matches GitHub’s dirty merge state. (CHANGELOG.md:3, 132b02ee27db)
• Fail-closed release boundary exists: The verifier requires the record to match the exact tag object and source commit, and rejects a blocked record when publishability is required. The proposed pending record is therefore directionally consistent, but the PR body lacks an observed terminal result for that path. (scripts/verify-release-source.sh:43, 797f20736844)
• Release policy requires all version-carrying files: Repository policy explicitly requires the changelog heading, Worker package manifest, and both root lockfile version entries to be bumped together; the PR changes that expected set. (AGENTS.md:34, 132b02ee27db)
• No v0.41.0 release exists yet: Local tags show v0.40.0 as the latest v0.4 release tag and no v0.41.0 tag, so this branch has not been superseded by a shipped release. (0171ae2ee19f)

Likely related people:

• steipete: The proposed release preparation is authored by steipete, and the corresponding release-source verifier history is attributed to Peter Steinberger; steipete also authored the related merged dependency-refresh preparation. (role: release workflow contributor; confidence: high; commits: 797f20736844, 132b02ee27db, d649ddf50cf9; files: docs/RELEASING.md, scripts/verify-release-source.sh, release/records/v0.41.0.json)
• vincentkoc: Vincent Koc authored the current-main changelog entries that now conflict with this branch’s release-section conversion. (role: recent changelog contributor; confidence: high; commits: 64a7f8f50e00, 0171ae2ee19f; files: CHANGELOG.md)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Rebase and include current-main Unreleased entries in the v0.41.0 notes.
• Attach a redacted terminal transcript showing the blocked record fails closed before authorization.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (4 earlier review cycles)

• reviewed 2026-07-31T23:02:19.768Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Fold unshipped 0.40.1 notes into 0.41.0
• reviewed 2026-07-31T23:19:08.524Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Fold untagged 0.40.1 notes into v0.41.0
• reviewed 2026-08-01T09:35:21.623Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Preserve the coordinator-token rotation in v0.41.0 notes
• reviewed 2026-08-01T16:18:38.363Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Rebase the release changelog onto current main