| name | release |
| description | Prepare, verify, and publish Homebox releases through the repository's tag-driven GitHub Actions workflow. Use whenever the user says “发版”, “发布版本”, “release”, “打 tag”, “推 tag”, or invokes /release or $release, including dry-run requests. Always present and obtain explicit confirmation of the version, target commit, changelog, validation plan, and remote publishing effects before changing version files, creating a tag, or pushing anything.
|
Homebox Release
Treat a bare “发版” or /release as a request to prepare a release proposal, not as permission
to publish. Keep all work read-only until the confirmation gate passes.
1. Inspect the release candidate
Run read-only checks and summarize the result:
- Confirm the repository root, current branch, upstream,
HEAD, and worktree status.
- Fetch no refs unless needed; use
git ls-remote to check the remote tag without mutating refs.
- Find the latest stable
vMAJOR.MINOR.PATCH tag and list commits from it through HEAD.
- Read the package versions from
server/Cargo.toml and the homebox package entry in
server/Cargo.lock.
- Verify that the proposed tag is absent locally and remotely.
- Inspect
.github/workflows/build.yml, .github/workflows/docker.yml, Makefile, and
script/pack-arch.sh if they changed since the previous release.
- Stop and explain any unrelated dirty worktree changes; never overwrite or include them by
assumption.
Suggest the next patch version after the latest stable tag unless the user supplied a version.
If the commits could justify a minor or major bump, show that as an alternative with a short
reason, but keep the patch version as the default until the user chooses otherwise. Tags include
the prefix; Cargo versions do not. Do not update , whose historical version
is independent.
