Surfaced completing the #657 major-scoped-channel migration: pr-review (the core review engine, release v1.8.0) has live channel tags pr-review/{next,ring0,ring1,stable} (next=ded84ce4 ≠ stable=8e00cde6, i.e. a soaking candidate) and caller stubs across the fleet (pr-review.yml in .github-private/TalkTerm/bmad/markets/…), but it is not registered in standards/canary-rings.json.
Consequence: the canary engine (which only gates/promotes registered agents) does NOT manage pr-review's channel promotion, yet its tags move (next≠stable) — so promotion is happening via some other/manual path. It was therefore out of scope for #657 (all 14 REGISTERED agents were migrated to <agent>/v<M>-<tier> + bare-tag retired; pr-review's bare tags were correctly left untouched since retiring them would strand consumers on v-tags nothing promotes).
Decision needed: either (a) register pr-review in canary-rings.json so it's engine-gated + can be major-scoped like the rest, or (b) document why it's managed separately (e.g. the engine reusable is disabled_manually and pinned differently). If (a), then run the #657 migration for it too (create pr-review/v1-tiers, re-pin the pr-review.yml consumers, retire bare).
Surfaced completing the #657 major-scoped-channel migration:
pr-review(the core review engine, release v1.8.0) has live channel tagspr-review/{next,ring0,ring1,stable}(next=ded84ce4 ≠ stable=8e00cde6, i.e. a soaking candidate) and caller stubs across the fleet (pr-review.ymlin .github-private/TalkTerm/bmad/markets/…), but it is not registered instandards/canary-rings.json.Consequence: the canary engine (which only gates/promotes registered agents) does NOT manage pr-review's channel promotion, yet its tags move (next≠stable) — so promotion is happening via some other/manual path. It was therefore out of scope for #657 (all 14 REGISTERED agents were migrated to
<agent>/v<M>-<tier>+ bare-tag retired; pr-review's bare tags were correctly left untouched since retiring them would strand consumers on v-tags nothing promotes).Decision needed: either (a) register pr-review in canary-rings.json so it's engine-gated + can be major-scoped like the rest, or (b) document why it's managed separately (e.g. the engine reusable is
disabled_manuallyand pinned differently). If (a), then run the #657 migration for it too (create pr-review/v1-tiers, re-pin the pr-review.yml consumers, retire bare).