Summary
This repo fetches tags from both origin (AltimateAI/altimate-code) and upstream (the fork source, anomalyco/opencode) into one local clone. Stale, unrelated v0.11.0–v0.11.8-shaped tags already exist from upstream's own release history (e.g. v0.11.0 dated ~2025-09-21, authored by opencode <opencode@sst.dev>), structurally disjoint from this repo's own main (git merge-base --is-ancestor returns false both ways).
This already caused a real block during the v0.11.0 stable release preflight: bun script/release-preflight.ts failed on a "tag collision" against the locally-cached upstream/v0.11.0 tag, even though origin had no such tag. It was resolved by deleting the local tag ref (safe — it's a cached copy of upstream's own tag, refetchable via git fetch upstream --tags, and doesn't touch upstream's actual repo).
Any release tooling that pattern-matches v{X}.{Y}.{Z}* for "does this version already exist" or "what's the next beta number" needs to explicitly scope its git tag/git ls-remote checks to origin only, or this same collision will recur — including against upstream tags that share a version number by coincidence, not by any relationship to our own release history.
Proposed fix
Audit script/release-preflight.ts and .claude/commands/release.md / release-beta.md's tag-collision checks to confirm they already scope to origin (some do — git ls-remote origin refs/tags/... — but local git tag/git rev-parse checks don't distinguish which remote a locally-fetched tag came from). Consider excluding upstream/*-sourced tags from local collision checks, or fetching upstream tags into a separate refs namespace (e.g. refs/upstream-tags/* instead of refs/tags/*) so they never collide with our own tag namespace at all.
Provenance
Found and hit live during the v0.11.0 stable release's Step 2 preflight; flagged again independently by the CTO persona review as a risk for future release tooling.
Summary
This repo fetches tags from both
origin(AltimateAI/altimate-code) andupstream(the fork source,anomalyco/opencode) into one local clone. Stale, unrelatedv0.11.0–v0.11.8-shaped tags already exist fromupstream's own release history (e.g.v0.11.0dated ~2025-09-21, authored byopencode <opencode@sst.dev>), structurally disjoint from this repo's ownmain(git merge-base --is-ancestorreturns false both ways).This already caused a real block during the v0.11.0 stable release preflight:
bun script/release-preflight.tsfailed on a "tag collision" against the locally-cachedupstream/v0.11.0tag, even thoughoriginhad no such tag. It was resolved by deleting the local tag ref (safe — it's a cached copy ofupstream's own tag, refetchable viagit fetch upstream --tags, and doesn't touchupstream's actual repo).Any release tooling that pattern-matches
v{X}.{Y}.{Z}*for "does this version already exist" or "what's the next beta number" needs to explicitly scope itsgit tag/git ls-remotechecks tooriginonly, or this same collision will recur — including against upstream tags that share a version number by coincidence, not by any relationship to our own release history.Proposed fix
Audit
script/release-preflight.tsand.claude/commands/release.md/release-beta.md's tag-collision checks to confirm they already scope toorigin(some do —git ls-remote origin refs/tags/...— but localgit tag/git rev-parsechecks don't distinguish which remote a locally-fetched tag came from). Consider excludingupstream/*-sourced tags from local collision checks, or fetchingupstreamtags into a separate refs namespace (e.g.refs/upstream-tags/*instead ofrefs/tags/*) so they never collide with our own tag namespace at all.Provenance
Found and hit live during the v0.11.0 stable release's Step 2 preflight; flagged again independently by the CTO persona review as a risk for future release tooling.