release

# 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](../../../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/`).