Avoid failed Release runs for non-release pushes

[shiny-code-bot]

Objective

Make the Release workflow distinguish intentional release metadata pushes from ordinary post-release merges. After v0.6.109 shipped successfully, PR #246 merged to main and triggered Release run 26697626840, which failed in Require local release metadata because the commit was not a release metadata update. The failure did not break the published release, but it leaves main with expected-noisy red release runs.

Finish Line

Ordinary non-release pushes to main do not produce failed Release runs when no local release metadata is present.

Current Status

State: Active
Next action: Change Release so it first detects explicit release intent from committed local release metadata, then exits successfully as "no release intended" on ordinary main pushes.
Blocked by: None
Waiting for: Nothing
Last verified: 2026-05-30 after Release runs 26697626840 and 26698159254 both failed at Require local release metadata on ordinary non-release merges after v0.6.109 was already published.

Design direction:

• Keep the useful invariant: a real release must have locally prepared metadata from just local-release-notes.
• Stop treating "latest tag already equals package version" as an instruction to invent and fail a future release.
• Prefer validating and publishing the package version committed by a release metadata PR; CI should not compute a new release version for unrelated merges.
• Ordinary non-release pushes should either not trigger Release or should produce a green no-op. The preferred shape is an explicit no-op because it makes the Actions history self-explanatory while preserving workflow-edit testability.

Scope

• In: Release workflow trigger/skip behavior, status semantics for non-release pushes, and docs/metadata updates if workflow behavior changes.
• Out: npm/Homebrew credential work, release artifact contents, updater behavior, or the v0.6.109 published release.

Acceptance Criteria

• A non-release main push after an existing tag exits successfully or is skipped rather than failing for missing release metadata.
• Release metadata PRs still publish the next GitHub Release when codex-cli/package.json, CHANGELOG.md, and docs/release-notes/RELEASE_NOTES.md are prepared.
• Edits to .github/workflows/release.yml remain testable through the workflow.
• The chosen behavior is documented in .github/github.json or release docs only if the release workflow contract changes.
• Validation includes the relevant GitHub Actions evidence after merge.

Relationships

Related to #85 because clean release identity and branch policy are part of Every Code productization.
Related to #122 and #121, but this plan does not address Homebrew or npm credentials.

Validation

• Inspect Release workflow logic locally.
• Run targeted static checks for workflow shell snippets where practical.
• After merge, verify the Release workflow behavior on the next relevant main push or a controlled workflow change.

Decisions

• 2026-05-30: The metadata guard is doing its safety job, but the workflow shape is wrong: "no release intended" should not be represented as a failed Release run.
• 2026-05-30: The release workflow should separate release intent detection from next-version calculation. just local-release-notes owns preparing the next version and metadata; GitHub Actions should validate and publish that committed intent.
• 2026-05-30: Agents reviewed the design and converged on either path filtering or a successful no-op. Prefer successful no-op unless implementation shows path filtering is substantially simpler, because no-op preserves visible post-merge signal and workflow-edit testability.

Open Questions

• Should Release trigger only on release metadata paths, or run on every relevant main push and emit a successful "no release intended" summary?
• What exact file set defines release intent: codex-cli/package.json only, or the full trio of codex-cli/package.json, CHANGELOG.md, and docs/release-notes/RELEASE_NOTES.md?
• Should edits to .github/workflows/release.yml force a validation path without publishing, or require a manual dispatch/test path?

[shiny-code-bot]

Completed by #251.

Evidence:

• PR: fix(release): no-op when no release is intended #251
• Merge commit: 657687d
• Post-merge Release run: https://github.com/cbusillo/code/actions/runs/26700990827

Outcome:

• Release now treats the committed codex-cli/package.json version as release intent.
• If the version already has a v<version> tag, Release exits successfully as a no-op instead of inventing and failing a future release.
• If the version is untagged, Release validates committed metadata before the expensive preflight/build matrix and publishes exactly that committed version.
• The release policy docs now describe the no-op/publish split.