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 July 31, 2026, 7:19 PM ET / 23:19 UTC.

ClawSweeper review

What this changes

The PR dates the v0.41.0 changelog, updates the Worker package and lockfile versions, and adds a blocked record to authorize the later signed tag source.

Merge readiness

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

Keep this PR open: its release-preparation shape matches the repository’s signed-tag and blocked-record flow, but it still leaves two entries under untagged 0.40.1 even though the latest release is v0.40.0; the upcoming v0.41.0 release notes would therefore omit those merged changes. The PR also has CI and static validation but no required coordinator-backed live smoke before the release gate.

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-preparation structure is focused, but incomplete release-note scope and missing real release smoke evidence prevent a merge-ready rating.
Proof confidence	🧂 unranked krab (1/6)	Needs real behavior proof before merge: The PR body provides CI and static checks but confirms that no coordinator-backed live smoke ran; before merge, attach redacted evidence for a real run, attach, events, logs, and cleanup, then update the PR body for 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 provides CI and static checks but confirms that no coordinator-backed live smoke ran; before merge, attach redacted evidence for a real run, attach, events, logs, and cleanup, then update the PR body for re-review.
Evidence reviewed	5 items	Latest release versus untagged release notes: Current main records v0.40.0 as the latest available release tag, while 0.40.1 is still a separate dated changelog section without a containing release tag. The PR creates 0.41.0 at the top but leaves the two 0.40.1 entries outside that section. Release notes are sourced from the tagged changelog section: The release checklist requires restoring the full changelog from the latest tag and retaining every published version; the release workflow uses the tagged version’s changelog section as the immutable draft-release notes. Leaving merged but untagged 0.40.1 work separate would omit it from the v0.41.0 notes. Blocked authorization record matches the release security boundary: The added record intentionally uses pending tag and source identities with publicationStatus: blocked; the verifier rejects mismatched identities and rejects blocked records when publishability is required. This is consistent with the documented release gate.
Findings	1 actionable finding	[P2] Fold untagged 0.40.1 notes into v0.41.0
Security	None	None.

How this fits together

Crabbox release preparation turns the changelog section for a signed version into release notes, updates Worker package metadata, and then binds the signed tag to a protected source record. That record is consumed by the credential-free candidate producer only after tag identities are verified and publication is explicitly authorized.

flowchart LR
  A[Changes since latest signed release] --> B[v0.41.0 changelog section]
  B --> C[Signed annotated tag]
  C --> D[Captured tag and source identities]
  D --> E[Protected source authorization record]
  G[Worker package version] --> F[Credential-free candidate producer]
  E --> F

Loading

Decision needed

Question	Recommendation
Should v0.41.0 absorb the two changes currently stranded under the untagged 0.40.1 section, or should maintainers first complete a separate v0.40.1 release?	Fold 0.40.1 into v0.41.0: Move the Tensorlake documentation and Apple Container architecture entries into the v0.41.0 section so the next signed release contains all changes since v0.40.0.

Why: The latest release is v0.40.0, so maintaining a separate dated 0.40.1 section has release-note consequences that cannot be inferred safely from the PR alone.

Before merge

• Add real behavior proof - Needs real behavior proof before merge: The PR body provides CI and static checks but confirms that no coordinator-backed live smoke ran; before merge, attach redacted evidence for a real run, attach, events, logs, and cleanup, then update the PR body for re-review.
• Fold untagged 0.40.1 notes into v0.41.0 (P2) - The latest signed release is v0.40.0, but this change starts 0.41.0 while leaving the two 0.40.1 entries under an untagged version. The release flow uses the tagged version’s changelog section as draft notes, so the Tensorlake and Apple Container changes will be absent from v0.41.0 unless they are moved here or v0.40.1 is intentionally released first.
• Resolve merge risk (P1) - If v0.40.1 is not intentionally signed and published first, merging this branch leaves its two merged changes outside the v0.41.0 release-note section that feeds the draft release.
• Resolve merge risk (P1) - The release checklist requires a coordinator-backed smoke covering run, attach, events, logs, and cleanup; the PR has not supplied that real behavior evidence before the release gate.
• Complete next step (P2) - A maintainer must choose whether the untagged 0.40.1 work rolls into v0.41.0 or is released separately; the missing live smoke must also be supplied by an authorized coordinator setup.

Findings

• [P2] Fold untagged 0.40.1 notes into v0.41.0 — CHANGELOG.md:3

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Release surface	4 files affected; 23 added, 11 removed	The branch is narrowly limited to changelog, Worker version metadata, and one release authorization record.
Authorization state	1 blocked release record added	The candidate producer cannot proceed until a later protected record binds the actual signed tag object and source commit.

Merge-risk options

Maintainer options:

1. Fold the untagged release notes forward (recommended)
   Move the two 0.40.1 entries into 0.41.0 and add the required redacted live smoke evidence before merging this release-preparation branch.
2. Complete 0.40.1 as its own release
   Keep the separate section only if maintainers intentionally sign, authorize, and publish v0.40.1 before continuing with v0.41.0.

Technical review

Best possible solution:

Move the untagged 0.40.1 entries into the v0.41.0 section, then attach redacted coordinator-backed smoke evidence for the prepared commit before signing the exact release tag and authorizing its immutable source record.

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

Yes. Comparing the latest tag set with the PR changelog shows that v0.40.1 has no release tag while its two entries remain outside the new v0.41.0 section, which the release process uses for draft notes.

Is this the best way to solve the issue?

No. The release-record and version-bump approach is correct, but the changelog must either fold all post-v0.40.0 work into v0.41.0 or complete a separate v0.40.1 release first.

Full review comments:

• [P2] Fold untagged 0.40.1 notes into v0.41.0 — CHANGELOG.md:3
  The latest signed release is v0.40.0, but this change starts 0.41.0 while leaving the two 0.40.1 entries under an untagged version. The release flow uses the tagged version’s changelog section as draft notes, so the Tensorlake and Apple Container changes will be absent from v0.41.0 unless they are moved here or v0.40.1 is intentionally released first.
  Confidence: 0.98

Overall correctness: patch is incorrect
Overall confidence: 0.96

AGENTS.md: found and applied where relevant.

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

Labels

Label justifications:

• P2: This is a bounded release-preparation defect that can make the next release notes incomplete but does not alter running workloads.
• merge-risk: 🚨 other: A signed v0.41.0 release would omit two merged changes from its generated release notes unless maintainers resolve the untagged v0.40.1 section.
• 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 provides CI and static checks but confirms that no coordinator-backed live smoke ran; before merge, attach redacted evidence for a real run, attach, events, logs, and cleanup, then update the PR body for re-review.

Evidence

What I checked:

• Latest release versus untagged release notes: Current main records v0.40.0 as the latest available release tag, while 0.40.1 is still a separate dated changelog section without a containing release tag. The PR creates 0.41.0 at the top but leaves the two 0.40.1 entries outside that section. (CHANGELOG.md:3, 132b02ee27db)
• Release notes are sourced from the tagged changelog section: The release checklist requires restoring the full changelog from the latest tag and retaining every published version; the release workflow uses the tagged version’s changelog section as the immutable draft-release notes. Leaving merged but untagged 0.40.1 work separate would omit it from the v0.41.0 notes. (docs/operations.md:754, f793138a161e)
• Blocked authorization record matches the release security boundary: The added record intentionally uses pending tag and source identities with publicationStatus: blocked; the verifier rejects mismatched identities and rejects blocked records when publishability is required. This is consistent with the documented release gate. (release/records/v0.41.0.json:1, 132b02ee27db)
• Prior release preparation and release-contract provenance: The existing 0.40.1 preparation dates to commit 54a2ae3de0646c14ad0c47539d8573dff257bd76; release-checklist and verifier lines are attributed to Peter Steinberger, tying the current concern to the same maintained release process. (docs/operations.md:769, 54a2ae3de064)
• Real release behavior proof remains absent: The PR body explicitly says the coordinator-backed live smoke was not run. Repository policy requires a coordinator-backed run plus attach, events, logs, and cleanup verification before the release gate; CI and static checks are supplemental evidence. (docs/operations.md:769, f793138a161e)

Likely related people:

• steipete: Peter Steinberger authored the release checklist and source-verifier lines, prepared the prior 0.40.1 release commit, and authored this release-preparation branch. (role: release-contract author and recent release preparer; confidence: high; commits: 4775e3bbc61d, 54a2ae3de064, 132b02ee27db; files: docs/operations.md, scripts/verify-release-source.sh, CHANGELOG.md)

Rank-up moves

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

• Fold the untagged 0.40.1 entries into the v0.41.0 section or complete a separate v0.40.1 release.
• Post redacted coordinator-backed evidence for run, attach, events, logs, and lease cleanup; avoid exposing credentials, IP addresses, or private endpoints.

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 (1 earlier review cycle)

• 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