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 2, 2026, 11:26 AM ET / 15:26 UTC.

ClawSweeper review

What this changes

This PR converts the Unreleased changelog into a dated v0.41.0 section, bumps the Worker package metadata, and adds a blocked release-source authorization record pending a signed tag.

Merge readiness

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

Keep this PR open. Its release changelog hunk is behind current main and produces a three-way conflict; resolving it without retaining the two newer Unreleased entries would make the v0.41.0 notes incomplete. The PR also still lacks after-change terminal or live output proving the deliberately blocked release record stops candidate production before any release action.

Priority: P2
Reviewed head: 132b02ee27db382bd3d08c2489191dbbb6b72b86
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The release metadata shape is focused, but the unresolved current-main conflict and missing real preflight proof keep the PR from merge readiness.
Proof confidence	🧂 unranked krab (1/6)	Needs real behavior proof before merge: The PR body reports CI and test results, but it has no redacted after-change terminal or live output showing the exact blocked v0.41.0 record refusing candidate production before any producer action. 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 test results, but it has no redacted after-change terminal or live output showing the exact blocked v0.41.0 record refusing candidate production before any producer action. 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 drift: Current main still has an Unreleased section with two entries added after this PR's base: the broker soak workflow and coordinator-token rotation. The PR instead replaces the section header with a dated v0.41.0 heading. Merge conflict reproduced from source: A three-way merge of the PR head into current main conflicts in CHANGELOG.md because both sides rewrite the Unreleased release section. Repository release policy: The checked-in checklist requires release preparation to rebase on current main and restore the full changelog before creating or reusing a signed tag.
Findings	1 actionable finding	[P2] Rebase and retain current Unreleased entries
Security	None	None.

How this fits together

Release preparation turns the current Unreleased changelog and Worker package version into a tag-ready release commit. A later signed-tag authorization record binds that release commit to immutable Git identities before the credential-free candidate producer may proceed.

flowchart LR
  A[Current main changes] --> B[Release preparation branch]
  B --> C[Versioned changelog]
  B --> D[Worker package metadata]
  B --> E[Blocked source record]
  C --> F[Signed release tag]
  D --> F
  E --> G[Authorized candidate producer]
  F --> G

Loading

Decision needed

Question	Recommendation
Should v0.41.0 include the broker-soak and coordinator-token-rotation work that landed on main after this branch was created?	Rebase and include current main: Refresh this branch onto current main and fold both newer Unreleased entries into the v0.41.0 section before approving the release preparation.

Why: Tagging this release is an irreversible, gated operation; the release owner must explicitly confirm whether those current-main changes ship in v0.41.0 or are deferred to a later release.

Before merge

• Add real behavior proof - Needs real behavior proof before merge: The PR body reports CI and test results, but it has no redacted after-change terminal or live output showing the exact blocked v0.41.0 record refusing candidate production before any producer action. 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 and retain current Unreleased entries (P2) - This heading replaces the Unreleased section from base f793138a, but current main later added the broker-soak and coordinator-token-rotation entries. The current three-way merge conflicts here; resolve it by rebasing and building v0.41.0 from the complete current Unreleased section so those release notes are not lost.
• Resolve merge risk (P1) - Merging after a conflict resolution that favors the stale branch would omit the broker-soak and coordinator-token-rotation work from the v0.41.0 release notes.
• Resolve merge risk (P1) - The release still needs a redacted after-change preflight showing that the blocked record prevents candidate production before a maintainer advances any irreversible gate.
• Complete next step (P2) - A release owner must confirm the current-main inclusion scope and require fresh blocked-preflight proof after the contributor resolves the changelog conflict.

Findings

• [P2] Rebase and retain current Unreleased entries — CHANGELOG.md:3

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Release metadata surface	4 files affected; 23 added, 11 removed	The patch changes the release notes, Worker version metadata, and the protected source-record input together.
Main-branch drift	2 newer Unreleased entries	Both additions conflict with the branch's dated release heading and must be deliberately included or deferred.

Merge-risk options

Maintainer options:

1. Refresh the release preparation (recommended)
   Rebase onto current main, resolve the changelog conflict by retaining every current Unreleased entry, then rerun the release preflight and attach redacted output.
2. Pause this release cut
   Do not merge the stale preparation branch if the release owner intends to defer the current-main workflow changes to a later version.

Technical review

Best possible solution:

Rebase the preparation branch onto current main, make v0.41.0 contain the complete current Unreleased section, preserve the package-version and blocked-record changes, and attach redacted terminal proof of the blocked preflight before release approval.

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

Yes. A current three-way merge reproduces a conflict in CHANGELOG.md, and current main visibly contains the two Unreleased entries absent from the PR branch.

Is this the best way to solve the issue?

No. The branch must first be rebased onto current main and preserve the complete Unreleased section; its blocked-record behavior also needs direct preflight evidence before merge.

Full review comments:

• [P2] Rebase and retain current Unreleased entries — CHANGELOG.md:3
  This heading replaces the Unreleased section from base f793138a, but current main later added the broker-soak and coordinator-token-rotation entries. The current three-way merge conflicts here; resolve it by rebasing and building v0.41.0 from the complete current Unreleased section so those release notes are not lost.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.99

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 defect that can produce incomplete release notes but does not affect already-released users.
• merge-risk: 🚨 compatibility: A stale conflict resolution could ship v0.41.0 with release notes that omit current-main user-visible changes.
• 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 test results, but it has no redacted after-change terminal or live output showing the exact blocked v0.41.0 record refusing candidate production before any producer action. 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 drift: Current main still has an Unreleased section with two entries added after this PR's base: the broker soak workflow and coordinator-token rotation. The PR instead replaces the section header with a dated v0.41.0 heading. (CHANGELOG.md:3, 0171ae2ee19f)
• Merge conflict reproduced from source: A three-way merge of the PR head into current main conflicts in CHANGELOG.md because both sides rewrite the Unreleased release section. (CHANGELOG.md:3, 132b02ee27db)
• Repository release policy: The checked-in checklist requires release preparation to rebase on current main and restore the full changelog before creating or reusing a signed tag. (docs/operations.md:757, 0171ae2ee19f)
• Blocked record remains a sound guard: The release verifier requires matching tag-object and peeled source-commit identities and rejects blocked records when publication is requested, so the added pending record does not itself authorize release production. (scripts/verify-release-source.sh:40, 0171ae2ee19f)
• Feature-history routing: Current changelog entries after the PR base were added by Vincent Koc; the prior v0.40.1 release-preparation commit and the present release-guard lines trace to Peter Steinberger history. (CHANGELOG.md:7, 64a7f8f50e00)

Likely related people:

• steipete: Prior history includes the v0.40.1 release-preparation commit, and blame attributes the current release-record validation path to Peter Steinberger. (role: release workflow contributor; confidence: high; commits: 54a2ae3de064, 797f20736844; files: CHANGELOG.md, scripts/verify-release-source.sh)
• vincentkoc: Recent main commits added the broker-soak and coordinator-token-rotation entries this release branch must preserve. (role: recent changelog contributor; confidence: high; commits: 0171ae2ee19f, 64a7f8f50e00; files: CHANGELOG.md, .github/workflows)

Rank-up moves

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

• Rebase onto current main and retain every current Unreleased entry in v0.41.0.
• Add redacted terminal or live output showing the blocked release record stops the candidate path before release production.

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 (10 earlier review cycles; latest 8 shown)

• 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
• reviewed 2026-08-01T18:45:31.149Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Rebase the release changelog onto current main
• reviewed 2026-08-02T01:42:22.422Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Rebase and refresh the v0.41.0 changelog
• reviewed 2026-08-02T05:08:24.059Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Rebase the release preparation and refresh its changelog
• reviewed 2026-08-02T08:53:48.365Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Rebase and retain current unreleased entries
• reviewed 2026-08-02T11:54:04.096Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Rebase and retain current unreleased entries
• reviewed 2026-08-02T13:56:25.103Z sha 132b02e :: needs real behavior proof before merge. :: [P2] Rebase and retain current Unreleased entries