Cosmo Release
Use this workflow for release requests such as /cosmo:release v0.1.0-rc1.
Workflow
Normalize the target version.
- Accept
v0.1.0-rc1or0.1.0-rc1. - Use the normalized version without
vfor source files. - Use the tag form with
vfor changelog and release commands.
- Accept
Inspect release readiness first.
node scripts/release-preflight.mjs <version> --jsonReport pending version-string updates, current branch, changelog status, and the generated follow-up commands before making edits.
Local preparation is allowed.
Update version strings with:
node scripts/release-preflight.mjs <version> --writeGenerate or refresh the root changelog with:
node scripts/generate-changelog.mjs <version> --writeRe-run preflight after edits.
Build and validate locally when feasible.
Fast checks:
node scripts/release-preflight.mjs <version> --json node --test cmd/cosmo/*.test.mjs parse-changelog ./CHANGELOG.mdFull release build:
COSMO_OUTPUT=target/dist/cosmoc ./scripts/build.sh target/dist/cosmoc --version
Generate release notes from the changelog and artifact directory.
node scripts/draft-release.mjs <version> --artifacts target/release --output target/release-notes.mdStop before external side effects.
- Do not run
git tag,git push,gh release create,gh release edit, or any publishing command unless the maintainer explicitly approves that exact action. - When asking for approval, show the exact command that would run.
- Do not run
Guardrails
- Do not update samples, fixtures, or docs examples that intentionally use
0.0.0. - Keep
cosmoc --versionaligned with the release version. - CI release builds produce
cosmoc-linux-x64,cosmoc-linux-arm64,cosmoc-macosx-x64,cosmoc-macosx-arm64,cosmoc-windows-x64, andcosmoc-windows-arm64. - Keep root
CHANGELOG.mdin tinymist-style sections:## vX.Y.Z - [YYYY-MM-DD],### Topic,* item, and a**Full Changelog**line. - Use
gh api repos/<owner>/<repo>/releases/generate-notesfor changelog candidates. - Use
parse-changelog ./CHANGELOG.mdfor release notes so CI and local output agree.