new-tag

# New Tag

## Workflow

### Inspect the release convention

- Check `git status --short`, the current branch, and recent tags before changing versions.
- Inspect `.github/workflows/` for tag patterns such as `v*`, package filters, build jobs, and publish jobs.
- Inspect package manifests and release scripts to determine which package version should drive the new tag.

### Choose the version plan

- Follow the repository's existing tag pattern unless the user explicitly wants to change it.
- Bump only the packages affected by the release.
- Bump shared packages when their changed code is consumed by a package that will be published from this tag.
- Keep compatibility gates unchanged unless the new release actually requires a higher minimum version.
- If the worktree contains unrelated changes, stop and ask before including them in the release.

### Apply the version changes

- Update package versions in manifest files.
- Update release workflows, workspace filters, and package references when package names or published artifacts have changed.
- Fix any packaging or TypeScript resolution issues discovered while preparing the release.

### Validate before tagging

- Run the builds required by the release workflow, not just a subset that happens to pass locally.
- At minimum, build every package that the tag-triggered workflow will build or publish.
- Do not create or push a tag while any required build is failing.

### Commit and push the release prep

- Stage only the files that belong in the release prep.
- Use a clear release-oriented commit message such as `Prepare vX.Y.Z release`.
- Push the branch before creating the tag so the tag points at a commit already on the remote.

### Create and push the tag

- Create an annotated tag that matches the workflow trigger, usually `vX.Y.Z`.
- Push the tag explicitly.
- Report the commit SHA, tag name, and any workflows that should now trigger.

## Command Pattern

Use this sequence as the default pattern and adapt it to the...