Cubeplex release workflow

Use this skill for a production or self-hosted cubeplex release. The exact version, image, tag, docs, and deployment contracts live in docs/releasing.md, read that file before acting. Do not invent a shorter checklist.

Required sequence

1. Inspect the current branch, worktree, origin/main, and existing release tags.
2. Prepare a release PR that bumps every version source in docs/releasing.md (packages, chart, hardcoded code refs, uv.lock, compose .env.example, and the English + Chinese deploy-doc snippets). Add the version's English and Chinese changelog pages and sidebar entry; put upgrade notes after features and fixes.
3. Run the version-consistency check, changelog renderer/tests, docs checks, and repository CI-equivalent checks. Review the rendered GitHub Release body.
4. Merge the release PR into main.
5. Create v<semver> on that exact merged commit and push the tag.
6. The tag push triggers two concurrent workflows: images.yml builds and pushes version-tagged images; release.yml verifies versions, waits for those images, renders the changelog with a generated PR appendix, writes the release manifest, and creates or updates the GitHub Release.
7. Deploy using the manifest's release tags or digests. Do not edit chart defaults or use latest for production.

Guardrails

• Never overwrite an existing application or sandbox version tag.
• Do not run sandbox runtime compatibility tests from the image release workflow; existing sandbox E2E/nightly workflows remain separate.
• Keep registry credentials and runtime secrets out of release manifests.
• If the image build fails, fix the build; do not manually push a replacement image under the same tag.
• Do not put this process on the user-facing docs site (docs/site/).