[Phase 2] Promote the generalized review agent through the Safe Release rings

[github-actions]

Story

As a org-lead responsible for the production reviewer,
I want the generalized review agent promoted through the Safe Release rings/channels rather than shipped straight to stable,
so that the behavior-preserving refactor reaches stable only after ring-staged validation.

Acceptance Criteria

1. The refactored review agent is cut as a versioned release and promoted via the ring/channel pipeline (ring 0 self-host -> 1 low-traffic -> 2 rest), not pushed straight to the stable channel.
2. The pr-review/stable channel tag is moved only after ring validation, per the Safe Release Strategy.
3. The new artifact-type registrations (plan_json, skill_candidate) ride the same channel promotion.

Tasks / Subtasks

• Cut a versioned release of the refactored agent and start at ring 0 (self-host) using the existing release tooling (scripts/cut-release.sh / channel tags). (AC: test issue from agent #1)
• Validate at each ring, then move the pr-review/stable channel tag. (AC: test issue from agent #1, Go-live improvements for PR review agent #2)
• Confirm consumer trigger stubs (pr-review-trigger.yml @ pr-review/stable) pick up the promoted version. (AC: Go-live improvements for PR review agent #2, Add @claude delegation, auto-merge, and rebase handling #3)

Dev Notes

• Safe Release Strategy is Epic Initiative: Safe Release Strategy for Agentic Workflows (versioning · rings · canary) #495; relevant pieces are [Phase 1] Pin all callers off @main to the stable tag (consumer repos + self-review/dev duty) #497 (pin callers off @main to stable), [Phase 2] Add next + per-ring channel tags (blue/green green channel) #499 (next + per-ring channel tags), [Phase 2] Define concentric rings (0 self-host → 1 low-traffic → 2 rest) + keep production duty on stable #500 (concentric rings 0->1->2), [Phase 2] Replace PUT-contents clobber deploy with versioned, ring-staged, health-gated promotion #501 (versioned ring-staged health-gated promotion). Use that pipeline; do not invent a new release path.
• pr-review-trigger.yml is a thin caller pinned to pr-review/stable; promotion reaches consumers via the channel-tag mechanism (scripts/cut-release.sh; AGENTS.md documents the first-party mutable-channel exception to the SHA-pin rule).
• hands_off: ring promotion to stable is a human release decision and must never be auto-released to dev-lead.
• Sequenced after the pr_diff regression guard (Story 3) so only proven behavior-preserving code is promoted; new-type registrations follow the same channel.

Project Structure Notes

No new source; this is a release/operations story touching release channel tags and verifying pr-review-trigger.yml. cut-release.sh is exercised by tests/test_cut_release.bats.

References

• .github/workflows/pr-review-trigger.yml
• .github/workflows/pr-review.yml
• scripts/cut-release.sh
• AGENTS.md#workflow-files
• tests/test_cut_release.bats

Likely target surface

• .github/workflows/pr-review-trigger.yml
• scripts/cut-release.sh

Story prepared by the BMAD Scrum Master (Bob) for epic #610. Status: ready-for-dev.

[don-petry]

Dev-Lead: Ring-Staged Promotion Hand-Off (Issue #616)

This is a release/operations story whose acceptance criteria are human-gated and cannot be executed by the dev-lead agent. Reporting a verified hand-off rather than a code change, per the issue's own hands_off note.

Why no code change / no autonomous promotion

• hands_off (issue Dev Notes): "ring promotion to stable is a human release decision and must never be auto-released to dev-lead."
• Ruleset: the release-channel-tags ruleset (AGENTS.md → "Release channel tags & the mutable-ref exception"; docs/release/runbook.md §Roles) restricts pr-review/** tag update/deletion to OrganizationAdmin + the automation Integration app. The dev-lead agent runs as GITHUB_TOKEN and cannot cut or move any release/channel tag.
• No source gap: the behavior-preserving refactor is already on main (faf7ec2); plan_json and skill_candidate are already registered in scripts/lib/review-registry.tsv; and scripts/cut-release.sh already accepts arbitrary --channel names, so it already supports ring-staged pr-review promotion. Nothing to implement.

Pipeline verified (dry-run, no tags touched)

$ scripts/cut-release.sh pr-review 1.6.0 --ref origin/main --dry-run
agent=pr-review version=1.6.0 ref=origin/main (faf7ec2...) target=petry-projects/.github-private
release tag: pr-review/v1.6.0
(dry-run) no tags created or pushed.

$ scripts/cut-release.sh pr-review 1.6.0 --ref origin/main --channel next --dry-run
channel tag: pr-review/next -> pr-review/v1.6.0
(dry-run) no tags created or pushed.

The tooling resolves and targets the correct host repo (petry-projects/.github-private) at the refactored HEAD.

Two premise corrections for the release manager

1. Trigger pin. pr-review-trigger.yml is pinned to pr-review/next (this repo is the ring-0 self-host canary), not pr-review/stable as the Dev Notes state. The stable-pinned consumers are the fleet trigger stubs in other repos.
2. pr-review ring channels. Per docs/release/versioning.md and runbook.md §2c, pr-review currently has only next + stable — its ring0/ring1 channels are pending under [Phase 2] Add next + per-ring channel tags (blue/green green channel) #499. A literal ring 0 → 1 → 2 staging for pr-review needs [Phase 2] Add next + per-ring channel tags (blue/green green channel) #499 to land the intermediate ring channels first; today's available staging is next (self-host) → stable (fleet).

Human release-manager checklist (AC #1, #2, #3)

Run once #499's ring channels exist for the full 0→1→2 path; the next → stable path is available today. plan_json + skill_candidate ride along automatically (same repo commit the tag points at).

# 1. Cut the immutable release at the reviewed main HEAD (ungated, rolls out nothing):
scripts/cut-release.sh pr-review 1.6.0 --ref origin/main --push

# 2. Stage outward one ring at a time — verify + soak (runbook §4) between each:
#    (dogfood is already on next; advance rings as they become available under #499)
#    ring1 (low-traffic named consumers) -> ... -> stable (fleet)

# 3. Move pr-review/stable ONLY after ring validation (runbook §2c). Human-authorized.

# 4. Confirm fleet consumers (@pr-review/stable) picked up the promoted SHA (runbook §4).

Status

• Verified cut-release.sh ring-staged pipeline (dry-run) for the refactored pr-review agent
• Confirmed plan_json / skill_candidate ride the same channel promotion (registry rows on the tagged commit)
• Confirmed this repo's consumer trigger stub is correctly pinned (ring-0 pr-review/next)
• Human release manager: cut pr-review/vX.Y.Z, stage through rings, move pr-review/stable after ring validation (hands_off)

No source files changed — this story's actionable work is a human-gated release operation.