P2 The RC-tag check couples this deploy logic to a tagging convention that is being retired ("no RC branches moving forward"). Going forward, the git tag -l branch on line 62 is effectively dead code that never triggers — but a future reader has to understand a defunct workflow to reason about correctness.

Consider an approach that doesn't depend on RC tags at all: find the latest released branch (has .0 tag), then check whether the next branch in version order exists:

for branch in $(echo "$release_branches" | sort -Vr); do
	version=${branch#release/}
	if git rev-parse "refs/tags/v${version}.0" >/dev/null 2>&1; then
		latest_released=$branch
		break
	fi
done

if [[ -n "${latest_released:-}" ]]; then
	frozen=$(echo "$release_branches" | grep -A1 "^${latest_released}$" | tail -n1)
	if [[ "$frozen" != "$latest_released" ]]; then
		deploy_branch=$frozen
	fi
fi

This expresses the real invariant directly ("frozen = the branch after the latest released one") rather than inferring it by elimination. No coupling to RC conventions, fewer git calls in the loop, and the logic stays correct whether RC tags exist or not.

Also a nit on this line: $release_branches is already sort -V'd on line 38. tac would be clearer — "same list, reversed" rather than re-sorting.

Nit Log says "only has RC tags" but the check verifies RC tags exist, not that they're the only tags. Minor wording mismatch — maybe "has RC tags but no final release, skipping" to match the actual condition.

P3 When the loop exhausts without finding a frozen branch (every candidate was either released or RC-only), deploy_branch stays main silently. The log on the next line shows the result but not the reason. Adding a message here would help operators triage unexpected main deploys:

done
if [[ "$deploy_branch" == "main" ]]; then
	log "No frozen release branch found, falling back to main"
fi