[Phase 2] Define concentric rings (0 self-host → 1 low-traffic → 2 rest) + keep production duty on stable

Parent: #495 · Phase 2 · Work type: Feature · Targets SC2, SC3, SC5.

Define rings: Ring 0 = .github-private self-host tracks next (canary); Ring 1 = one low-traffic consumer; Ring 2 = remaining consumers. Production self-review/dev duty stays pinned to stable even in ring 0 — the agent validating fixes is never the broken candidate. This is the core fix for the circular dependency.

Done when: ring membership defined; next exercised in ring 0 while stable serves production duty.

Ring membership exercised for the dev-lead v1.4.0 canary (2026-06-21)

Concrete ring assignment now standing for dev-lead:

Ring 0 / self-host: petry-projects/.github-private → @dev-lead/next
Ring 1 / low-traffic: petry-projects/TalkTerm → @dev-lead/ring1 (petry-projects/.github → @dev-lead/ring0)
Ring 2 / rest: remaining consumers stay on @dev-lead/stable

The canary validated v1.4.0 on the rings (17 failures, all pre-existing classes, zero regressions — see #781 follow-ups #864/#865), then stable was promoted to v1.4.0.

⚠️ Caveat for full closure: the steady-state 'production self-review/dev duty stays on stable even in ring 0' safeguard wasn't maintained as an ongoing state — this was a one-shot canary→promote done via manual tag moves. Enforcing that separation continuously is a property of the ring-staged promotion workflow (#501), which is still manual. The standing ring assignment is now in place for future releases; recommend keeping this open until #501 lands.

Decisions / clarifications (from design discussion combsmith/.github#516)

Concrete ring membership for the abstract "Ring 0 → 1 → 2" in this issue. Four channels, host-relative next:

Ring	Channel	Members	Role
next	`<name>/next`	the repo that hosts the reusable	canary / dogfood at the source
ring0	`<name>/ring0`	`.github` and `.github-private` (the host already sits in `next`)	org-infra self-host
ring1	`<name>/ring1`	`TalkTerm`, `bmad-bgreat-suite`	named low-traffic consumers
stable	`<name>/stable`	everything else	full-fleet production

next is host-relative: for a reusable hosted in .github, next = .github and ring0 resolves to {.github-private}; for one hosted in .github-private, next = .github-private and ring0 = {.github}. next + ring0 always cover the two org-infra repos, partitioned by which one is the host. Production self-review/dev duty stays pinned to stable even within ring0 (the circular-dependency fix this issue targets).

Proposed machine-readable home: standards/canary-rings.json (single source of truth, consumed by the promotion automation in #501).

docs(release): align ring membership to canonical #500 (host-relative…

docs(release): document live dev-lead next/ring channels + staged-rol…

feat(release): codify release-channel-tags ruleset + apply-rulesets.sh (

fix(dev-lead): never SHA-pin first-party channel refs when applying f…