chore: promote next to main

[ss-o]

Promotion readiness record

Candidate identity

• Prior main SHA: 86758198344052d60b25f454cd3b64269a8ef2ea

• Candidate next SHA: 8104e93f651812fc3f6bcb03284b921bbd178e1a

• Candidate tree SHA: 9bac22bf2c03ec5f82feef8ba13e28ce573a65fa

• Complete compare:
  main...next

• git diff --name-only 8104e93...8675819 produces no output.

• git rev-parse '8104e93^{tree}' equals 9bac22bf2c03ec5f82feef8ba13e28ce573a65fa.

git log --oneline 8104e93..8675819 is not empty this time: it contains exactly one commit, 8675819 chore: promote next to main (#494), which is the previous promotion merge and exists only on main by design. The template calls this out. No stable-only content commit is stranded, and the empty three-dot diff is the precondition that matters.

Required validation

Validation	Stable job name	Result
Zsh syntax and compile	Zsh syntax and compile	Pass
ZD ZUnit integration	ZD integration	Pass
Trunk	Trunk	Pass
CodeQL	CodeQL	Pass
Exact-candidate clean install and startup	Clean install and startup	Pass
Aggregate	Promotion gate	Pass

• The candidate SHA has not changed since every required check completed. Re-fetched at merge time: base 8675819, head 8104e93.
• The Guard main branch source and Promotion gate required contexts pass. 24 checks green, none failing or skipped.
• The complete file and commit compare contains only reviewed work: one commit, fix(release): install Zsh before verifying the release tag #497.

Readiness review

Why now

main cannot publish a release. The publish job in release.yml runs zsh -f scripts/verify-release-tag.zsh on ubuntu-latest, which ships no Zsh, so it exits 127 before verifying anything. Tagging v2.0.1 was that workflow's first ever execution, since it reached main only with #494, and it failed on that run. v2.0.1 was published manually after running the verifier locally against the exact tag.

Until this promotion lands, any new tag on main fails the same way. That is the whole reason for promoting a single CI commit rather than waiting to batch it.

Contents

One commit, #497, adding a Zsh install step to the publish job before the verification step. No change to zi.zsh, any library, or any consumer-visible surface.

Unresolved issues

None blocking. Open zi issues are unchanged from the previous promotion and none is a regression from this candidate.

User-facing and migration notes

None. This candidate touches only .github/workflows/release.yml. Runtime behaviour is identical to v2.0.1.

Public-contract follow-ups

None. The candidate contains no shell source change.

• If the candidate introduces monitoring for a contract surface absent from the base, manually inventory that surface across the complete compare.

Merge contract

Promotion uses Create a merge commit. Never squash or rebase.

• The resulting commit message has no bot, AI-agent, or automation Co-authored-by trailer.
• delete_branch_on_merge is false; remote next will survive the merge.
• The main ruleset allows only merge commits and does not require linear history.
• The next ruleset does not require linear history.

Rollback readiness

• Rollback owner: @ss-o
• Observable rollback criteria:
  • The Release workflow fails on a subsequent tag, or the publish job behaves differently from a local run of scripts/verify-release-tag.zsh.
• The owner can open a same-repository hotfix-* pull request that reverts the promotion merge through protected main.
• The revert pull request will run Guard main branch source and Promotion gate.
• After a revert, clean install and startup will be confirmed at the new main head, then the hotfix will be merged forward into next.

Stable consumption boundary

This updates the Git-consumed stable main ref. It creates no semantic tag or GitHub release. v2.0.1 remains the newest tag and its content is unchanged by this promotion, which adds only a workflow step.