Reviewer: a moving v0 release tag so callers track releases without pinning to main #494

Need

Repos that use the advisory reviewer have two bad options today:

• Pin a release (advisory-review-agent.yml@v0.3.0, reviewer_ref: v0.3.0), as examples/review.yml recommends. Outerloop ships a release or rc every few days (v0.3.0rc1 on 10-03, rc2 on 10-04, v0.3.0 on 10-05), so a pin goes stale within days, and every caller has to be bumped by hand. Those bumps also have to keep uses: and reviewer_ref in step: per the input's description, a reviewer_ref older than the workflow can silently stop posting.
• Track main, which examples/review.yml says never to do ("this job hands your reviewer key to the workflow, so never point it at a moving branch"). Anyone who can push to main then runs code that holds every caller's reviewer key.

Current callers (agentic-learning-ai-lab, 2026-10-08)

So 8 of 10 run on the moving branch the docs warn against, one is pinned to a SHA that never updates, and one was broken.

Proposal: a moving major tag, v0

The usual GitHub Actions convention: callers use advisory-review-agent.yml@v0 with reviewer_ref: v0, and each release moves v0.

1. release.yml: on a final-release tag push (v0.X.Y, not rc), move v0 to that commit (git tag -f v0 && git push -f origin v0). Release candidates never move it.
2. Protect the tags: a tag ruleset on v* so only the release process (or admins) can create, move or delete them. That keeps the main property of a pin: the code that receives callers' keys changes only when a release is cut, not on any push to main.
3. Create v0 at v0.3.0 now.
4. Docs: examples/review.yml, docs/install.md and docs/reviewer.md recommend @v0 + reviewer_ref: v0, and say why: they track releases automatically, the workflow and reviewer always move together, and the ref is never a branch. Pinning an exact release or SHA stays documented for callers who want to bump by hand.
5. Change the default: consider making reviewer_ref default to the workflow's own release rather than main, so a caller that leaves it unset is not silently on the moving branch.
6. Callers: switch the ten repos above to @v0 / reviewer_ref: v0 (separate PRs in each repo, after v0 exists).

Trade-off: a broken release reaches every caller at once. Recovery is to move v0 back to the previous release. Release candidates are where a bad change should be caught.

Not covered

Major-version bumps: at 1.0, callers move to @v1 deliberately, since a major release may break them.