release: 0.5.1

[steipete]

Summary

• set the root npm package and private native workspace to 0.5.1
• set the Rust crate and locked package version to 0.5.1
• date the accumulated patch changelog for 2026-08-01

Proof

• node scripts/release-notes.mjs 0.5.1
• pnpm check: 607 tests passed, 25 skipped; packed consumer check passed
• node scripts/check-pack.mjs: passed
• autoreview: clean, no accepted/actionable findings

After this lands, the protected annotated v0.5.1 tag will invoke the repository-owned trusted publishing workflow.

[clawsweeper]

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

ClawSweeper review

What this changes

Updates the root package, private native workspace, Rust crate, lockfile package entry, and changelog from 0.5.0/Unreleased to the 0.5.1 release state dated August 1, 2026.

Merge readiness

⛔ Blocked until real behavior proof from a real setup is added - 3 items remain

The 0.5.1 version bump is internally consistent and follows the established protected-tag release model, but it should remain open until the remaining platform/audit checks finish and contributor-visible after-fix proof is supplied.

Priority: P2
Reviewed head: f5d458038e3871c7e1f219266aa26b50cc232636

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The narrowly scoped, internally consistent release patch is strong, but real after-fix proof is not yet inspectable and the remaining release checks are unfinished.
Proof confidence	🧂 unranked krab (1/6)	Needs real behavior proof before merge: The body lists checks and a packed consumer check, but supplies no inspectable after-fix terminal output, live artifact, or redacted log showing the final 0.5.1 package behavior; add that evidence and redact private paths, hosts, keys, and tokens. 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	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs real behavior proof before merge: The body lists checks and a packed consumer check, but supplies no inspectable after-fix terminal output, live artifact, or redacted log showing the final 0.5.1 package behavior; add that evidence and redact private paths, hosts, keys, and tokens. 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	4 items	Coordinated metadata diff: The proposed branch changes exactly five release files, and each version-bearing package surface moves from 0.5.0 to 0.5.1 while the changelog section receives the release date. Release workflow contract: The protected-tag workflow requires the root package, private native workspace, and native Cargo crate to match the vX.Y.Z tag, then runs release notes and package checks before assembly and publishing. Established release convention: Current main uses an Unreleased changelog section above v0.5.0, and prior release metadata was committed as “release: date 0.5.0 changelog”; the proposed commit follows that same workflow-oriented release shape.
Findings	None	None.
Security	None	None.

How this fits together

This release preparation synchronizes JavaScript and Rust native-binding version metadata with the changelog. A protected annotated tag from main then drives validation, assembly of seven native binaries, package smoke testing, and npm publishing.

flowchart LR
  A[Main source changes] --> B[Release version metadata]
  B --> C[Protected annotated tag]
  C --> D[Validate tag and versions]
  D --> E[Build seven native bindings]
  E --> F[Pack and smoke test]
  F --> G[Publish validated npm artifact]

Loading

Before merge

• Add real behavior proof - Needs real behavior proof before merge: The body lists checks and a packed consumer check, but supplies no inspectable after-fix terminal output, live artifact, or redacted log showing the final 0.5.1 package behavior; add that evidence and redact private paths, hosts, keys, and tokens. 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.
• Resolve merge risk (P1) - Three release-relevant checks are still in progress: Windows bundled-package smoke, Windows native validation, and Cargo clippy/audit. Publishing before they complete could ship a version whose cross-platform native package was not fully validated.
• Resolve merge risk (P1) - The PR body reports checks but does not include inspectable after-fix terminal output or another artifact demonstrating the final 0.5.1 release metadata in a real packed consumer flow.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Release surfaces	5 files changed; 5 additions, 5 deletions	Every touched file is release metadata, so version agreement across the JavaScript, Rust, lockfile, and changelog surfaces is the main merge concern.
Completed validation	19 successful checks, 3 in progress	The completed matrix covers most validation, but the remaining Windows and Cargo checks gate safe publication.

Merge-risk options

Maintainer options:

1. Finish cross-platform release validation (recommended)
   Wait for the Windows smoke/native and Cargo audit checks, then add a redacted packed-consumer validation transcript for the final 0.5.1 metadata before merging.
2. Pause the release
   Do not merge this release branch if any remaining platform or audit check fails; resolve the failing release artifact path first.

Technical review

Best possible solution:

Merge only after all required checks are green and the PR includes redacted terminal or artifact evidence that the 0.5.1 package was packed and consumed successfully; then create the protected annotated v0.5.1 tag from main.

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

Not applicable: this is release preparation, not a user-reported runtime defect. The relevant verification is the tag workflow’s version validation and packed-consumer smoke path.

Is this the best way to solve the issue?

Yes, subject to final proof: synchronizing all release version surfaces and dating the accumulated changelog matches the protected-tag workflow and the repository’s previous release convention.

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

• add P2: This is a normal release-preparation change with package-wide impact but no demonstrated active outage.
• add merge-risk: 🚨 compatibility: A mismatched root, native workspace, Rust crate, or lockfile version would produce an inconsistent published package or fail the protected-tag validation.
• add merge-risk: 🚨 availability: The release includes native binaries, and Windows smoke/native checks remain incomplete, leaving platform availability unconfirmed.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The body lists checks and a packed consumer check, but supplies no inspectable after-fix terminal output, live artifact, or redacted log showing the final 0.5.1 package behavior; add that evidence and redact private paths, hosts, keys, and tokens. 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.

Label justifications:

• P2: This is a normal release-preparation change with package-wide impact but no demonstrated active outage.
• merge-risk: 🚨 compatibility: A mismatched root, native workspace, Rust crate, or lockfile version would produce an inconsistent published package or fail the protected-tag validation.
• merge-risk: 🚨 availability: The release includes native binaries, and Windows smoke/native checks remain incomplete, leaving platform availability unconfirmed.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The body lists checks and a packed consumer check, but supplies no inspectable after-fix terminal output, live artifact, or redacted log showing the final 0.5.1 package behavior; add that evidence and redact private paths, hosts, keys, and tokens. 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:

• Coordinated metadata diff: The proposed branch changes exactly five release files, and each version-bearing package surface moves from 0.5.0 to 0.5.1 while the changelog section receives the release date. (package.json:3, f5d458038e38)
• Release workflow contract: The protected-tag workflow requires the root package, private native workspace, and native Cargo crate to match the vX.Y.Z tag, then runs release notes and package checks before assembly and publishing. (.github/workflows/release.yml:1, 0b34d830b10a)
• Established release convention: Current main uses an Unreleased changelog section above v0.5.0, and prior release metadata was committed as “release: date 0.5.0 changelog”; the proposed commit follows that same workflow-oriented release shape. (CHANGELOG.md:1, 66201c1f347a)
• Current validation state: The supplied pull-request checks show successful JavaScript, CodeQL, native Linux/macOS, and smoke coverage, while Windows bundled smoke, Windows native check, and Cargo clippy/audit are still in progress. (f5d458038e38)

Likely related people:

• steipete: Authored this release commit and the immediately preceding v0.5.0 changelog-release commit, with repeated historical release preparation commits in the central metadata paths. (role: release-process contributor; confidence: high; commits: f5d458038e38, 66201c1f347a, 0206c4b567b4; files: package.json, native/package.json, native/Cargo.toml)
• Vincent Koc: Recent history attributes release-pipeline hardening and prior release preparation to this contributor, making them a useful adjacent routing contact for publishing workflow questions. (role: recent release-automation contributor; confidence: medium; commits: 60c355932e35, 4ef483ef0868, 9b52f71190bf; files: .github/workflows/release.yml, CHANGELOG.md)

Rank-up moves

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

• Post redacted terminal output or a linked artifact showing the 0.5.1 packed package passes a consumer smoke test.
• Wait for the Windows bundled-package/native and Cargo clippy/audit checks to complete successfully.
• After adding proof, update the PR body for a fresh review or ask a maintainer to comment @clawsweeper re-review if it does not trigger automatically.

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.