Reconcile legacy Binary Release workflow with main Release path

[cbusillo]

Objective

Decide whether .github/workflows/binary-release.yml is still an intentional legacy/manual release path, and either align it with the current Release workflow or retire it.

Current Status

State: Waiting
Next action: Audit Release vs Binary Release ownership after the Every Code main cutover.
Blocked by: maintainer decision on whether tag-driven binary releases are still needed.
Last verified: 2026-05-24 after PR #125; Release run 26366906093 completed 9/9 jobs successfully and created/updated the current GitHub Release path.

Evidence

A post-merge auto-review flagged two apparent release inconsistencies:

• Release has path ignores including *.md, which can skip markdown-only metadata merges.
• Release emits plain v* tags, while Binary Release still listens for every-code-v* and overlay-v*.

The active release path is currently green: .github/workflows/release.yml runs on main, builds all release assets, and publishes/updates GitHub Release v0.6.100 directly. The recent successful runs include 26360477400, 26361374176, and 26366906093.

The remaining ambiguity is the older .github/workflows/binary-release.yml tag-driven path, whose trigger names no longer match the current plain v* GitHub Release source of truth.

Acceptance Criteria

• Document whether Binary Release is still needed after Release became the main release path.
• If still needed, align its tag triggers and docs with the current tag naming policy.
• If obsolete, disable/remove it and update .github/github.json important workflows if needed.
• Re-check release path ignores so metadata-only release PR merges either intentionally trigger or intentionally do not trigger Release.
• Validate with ./build-fast.sh for code changes and a main-branch Actions run for workflow changes.

Relationships

Related to #85, #87, #121, and #122.

Notes

Do not change the currently green Release path just to satisfy the legacy Binary Release trigger without first deciding whether that workflow remains part of the product release model.

[cbusillo]

Decision update from 2026-05-24 planning:

We should reframe this from public distribution cleanup to internal dogfood/update-feed cleanup.

Current direction:

• GitHub Releases are the canonical release and update source.
• npm and Homebrew are not required for auto updates and should not drive the release model right now.
• The legacy Binary Release path should be retired or explicitly disabled unless the audit finds a real remaining use.
• The active Release workflow should produce dependable GitHub Release assets first; package-manager publishing should not create partial-release failure modes.
• Follow-up issues now track the narrower pieces:
  • Generate GitHub Release update manifest #127: generate a GitHub Release update manifest.
  • Add guarded CLI update check and self-update #128: add guarded CLI update-check/self-update behavior.
  • Audit and remove obsolete legacy release/distribution surface #129: audit/remove obsolete legacy release and distribution surface.

Suggested acceptance-criteria addition: document this as an internal fork/dogfood release path, not a public takeover/rebrand of upstream Every Code.