git:20261001.dfaaf36 to git:20261001.5844b50

---

name: tmt-release

description: Maintain and promote tmux-team release lines, versions, and prerelease readiness without assuming publish authorization.

---

# tmux-team release management

Use this skill for release-line maintenance, v4 compatibility fixes, v5 promotion, version synchronization, or prerelease readiness in this repository.

## Long-lived branch policy

- `main` is the active v5 line after promotion.

- `v4` is the maintenance line rooted at commit `7056679dfa816a1acef8e7c978cf1733a578115b`.

- If remote `v4` does not exist, create it at that exact anchor only when the user has explicitly requested the maintenance line, then verify the remote ref before continuing.

- Before any branch mutation, verify the relevant remote refs and ancestry. Never force-push or repoint a long-lived line.

- A v4 maintenance fix requires a tracked issue, a dedicated branch and worktree, and a reviewable pull request. Keep the fix on the v4 line unless an explicitly scoped backport is requested.

- Use the checks available on the v4 line for maintenance pull requests; do not require contexts that the target branch cannot produce. Record any coverage gap in the issue.

- The native version is owned by `rust/Cargo.toml` and exposed through Cargo's package version; there is no TypeScript fallback. Keep any retained developer package version and public release instructions consistent when changing versions. The native skill ships with the CLI; there is no separately versioned plugin or marketplace.

- Follow `AGENTS.md` for GitHub issue state, branch and pull-request links, verification evidence, and safe worktree cleanup.

## Promotion and prerelease checks

Read the complete [native release verification guide](../../../docs/native-release-verification.md)

before archive, installer, upgrade, bootstrap or publication work. It owns the

procedures referenced below; DEVELOPMENT owns ordinary native checks.

- For Rust archives, follow the guide's native Rust release archive procedure.

Keep cargo-dist's manifest as the artifact metadata owner; independently verify

bounded extraction, notices, linkage, skill installation and persisted state.

Raw PR runtime checks do not establish release archive correctness. Do not enable a

generated installer or publication workflow merely to obtain local archives.

- Follow DEVELOPMENT's native runtime checks and the guide's archive verification for artifact changes.

Reuse the shared runtime proof for linkage, exact embedded skills and SQLite

reopen behavior. Keep the independent archive inventory/checksum/notices and

installer failure/cleanup evidence; raw binaries are not release artifacts.

- For native binary publication changes, also follow the guide's offline

installer lifecycle procedure using actual separately versioned archives.

Keep ownership anchored in the installation prefix, not application-state

selectors; verify old executable preservation, pin policy, partial command-link

finalization and unchanged data. The internal preview entrypoint is not a

public bootstrap or permission to replace a user/package-manager installation.

- Promotion requires passing Code quality, Unit tests, and Docker E2E checks.

- For a public native alpha, follow the guide's explicit multi-platform

release preparation procedure. A `prepare` run of the manual artifact workflow never

publishes;

all four final native verifiers must pass on the recorded reviewed commit.

Keep cargo-dist as the merged manifest owner. Authorized publication uses an

immutable draft-to-published GitHub release and verifies its attestation and

public installer before promoting README instructions. Publish with the

bundle's `release-publication.json` flags: the CLI release is a normal release

marked latest (the README's `releases/latest/download/install.sh` depends on

it); Office and Squad releases stay prereleases with `--latest=false`. After

a manual publication, run the guide's `--check-latest` check (the pipeline checks

its own publications). Do not equate a

downloadable CI bundle with a published or accepted release.

- Every CLI or extension release also passes the guide's upgrade from the last

published release (its public installer, then the candidate's installer and

`tmt upgrade`), not only a fresh install. Old receipts must stay readable.

- For curl bootstrap, follow the guide's native curl bootstrap verification.

Generate from final verified cargo-dist artifacts and invoke the existing

native publisher; do not enable a competing stock installer. Test an actual

matching-host archive without Node/Rust on runtime PATH, and distinguish

controlled-download evidence from an authorized public release smoke test.

npm/pnpm replacement is a fresh installation without data-transfer machinery,

not permission to delete old state or silently uninstall another manager.

- Tags, GitHub Releases, npm publishing, and npm dist-tags are separate operations that require explicit authorization; this skill never assumes permission for them. The one standing authorization is the release pipeline's alpha publication below.

- Update user-facing installation or channel documentation whenever a version change would make it inaccurate.

- The v5 root npm package is private developer tooling, not a product distribution.

Do not restore npm publishing or a download wrapper without a separately scoped

distribution decision. Historical v4 publishing uses that branch's own rules.

## Automated alpha publication

The owner chose a trunk-based alpha channel: there is no separate edge channel, and a merge to

`main` publishes an alpha release through the release pipeline once its publication gates pass

(the owner's decisions on #497). That choice is the owner's standing authorization for **the

pipeline** to publish alpha releases from `main`; it is recorded here so that the written rule

matches practice. The

[native release verification guide](../../../docs/native-release-verification.md) owns the

gates, the markers and the procedures; this section owns who may publish what.

- Covered: an alpha draft of the CLI, Office or Squad (a version `X.Y.Z-alpha.N`, enforced by

the `channel` gate and again by the publish command) that the pipeline built from `main`,

verified and attached, of a component that is released (`release: false` in the component map

parks one), and that passes every publication gate. A new SQLite migration does not hold an

alpha: migrations are forward-only, and the `migration` gate only reports the new entries in

its summary. The CLI alpha is published as a

normal release marked latest; Office and Squad alphas as prereleases with `--latest=false`,

as the bundle's `release-publication.json` says.

- Still the owner's explicit authorization: stable releases and anything outside the alpha

channel; a release from a branch line; a draft that any gate holds, and in particular a

breaking change (a `!` or `BREAKING CHANGE:` commit), which always pauses for the owner's

explicit OK;

README installer promotion; creating or rotating the release App credentials and the

`release` Environment (the owner's setup is in the guide's release-please section);

enabling or changing release immutability; and this authorization itself.

- The authorization belongs to the pipeline, not to an agent. An agent still never tags,

creates, edits or publishes a release by hand, and never dispatches a run that publishes,

without the owner's explicit authorization for that release. A run of `native-release.yml`

with `prepare` off publishes every draft of the product that passes its gates, and so does

its `hold` input for the released draft; `prepare` on (one bundle, no draft), `release.yml`

with `dry_run` on and the upgrade proof are not publication.

- A held draft carries `publication-held.json` with the gate, the reason and the run. Read it,

then follow the guide: the owner publishes by hand, or releases the hold by dispatch, which

skips only the gate the marker names.

- After it publishes, the pipeline reads the release back (public, immutable, the policy's

flags, the tag on the release commit, GitHub's attestation for the release and every asset).

A failed check opens an issue and fails the run; nothing is rolled back, and a repair is a new