Fix release version staging

[i386]

Summary

• keep scripts/release-version.sh as the single owner of the complete version surface
• stage every tracked release-preparation change in both workflow-dispatched and local releases
• add repository-consistency guards that prevent a partial staging list from returning

Root cause

The v0.73.1 release workflow ran scripts/release-version.sh, which correctly updated Cargo, npm, Kotlin, docs, and version allowlists in the checkout. The tag-creation step then staged a hard-coded subset containing Cargo manifests, Cargo.lock, Kotlin metadata, and Package.swift.

That omitted crates/mesh-llm-ui/package.json, its lockfile, sdk/node/package.json, and other tracked version-bearing files. The resulting tag contained Cargo version 0.73.1 but npm package version 0.72.1. The crates.io preflight reran the shared updater and failed on that mismatch.

Impact

Future release tags commit the complete tracked output from the shared version updater. Generated SDK console assets remain explicitly force-added.

This PR does not rewrite the already-published v0.73.1 tag. That tag needs deliberate recreation or replacement with a patch release after this change merges.

Validation

• bash -n scripts/release.sh scripts/release-version.sh
• actionlint .github/workflows/release.yml
• cargo fmt --all --check
• cargo check -p xtask
• cargo test -p xtask
• cargo clippy -p xtask --all-targets -- -D warnings
• cargo run -p xtask -- repo-consistency publish-crates
• isolated scripts/release-version.sh 0.72.2 integration test confirming Cargo, both npm manifests, the UI lockfile, and Kotlin metadata all update, all 46 tracked changes stage, and a second run is idempotent

Summary by CodeRabbit

• Bug Fixes

  • Improved release preparation to reliably include all tracked changes.
  • Added safeguards that detect incomplete staging and stop the release process with a clear error.

• Chores

  • Updated release automation to handle release-source changes more consistently.
  • Added validation checks to ensure release workflows maintain the required staging safeguards.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 1e345021-7b98-40df-bd11-c13a43a2a975

📥 Commits

Reviewing files that changed from the base of the PR and between f8e15e7 and 37f698a.

📒 Files selected for processing (3)

• .github/workflows/release.yml
• scripts/release.sh
• tools/xtask/src/main.rs

---

📝 Walkthrough

Walkthrough

Release staging now uses git add --update, validates that tracked changes are fully staged, and bases commit detection on the index. xtask adds invariant checks for these safeguards in the workflow and release script.

Changes

Release staging safeguards

Layer / File(s)	Summary
Release staging behavior .github/workflows/release.yml, scripts/release.sh	Release preparation stages tracked changes generically, force-adds console resources where required, fails on remaining unstaged tracked changes, and checks the staged index before committing.
Release staging invariants tools/xtask/src/main.rs	Invariant checks load scripts/release.sh and verify the workflow and script contain the required staging and unstaged-change guards.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Suggested reviewers: ndizazzo, michaelneale

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jd/fix-release-version-staging

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

This pull request is currently a draft. Reviews will not take place until the PR is marked as ready for review.