ci-failure-analyst can never reach stable: its ring1 members pin v1-stable, so the ring1->stable gate has no sample to count (stable frozen on v1.0.0 since 2026-07-10) #1270

Problem

ci-failure-analyst/v1-stable has pointed at v1.0.0 (cc0bc61f, 2026-07-10) since the channel was created. next, ring0 and ring1 advance normally, and next is now at v1.46.2. The ring1->stable gate can never pass, because the repos registered as ring1 members do not run the ring1 channel.

Evidence (2026-10-09)

A read-only gate evaluation, Canary Rollout run 37984012105:

* v1-next   -> f6f2e384d6bf
  v1-ring0  -> f34a76500759
  v1-ring1  -> f34a76500759
  v1-stable -> cc0bc61f70dc
next->ring0    SOAKING   dwell=3h/4h    sample=2/3  cum_fail=0
ring1->stable  SOAKING   dwell=61h/12h  sample=0/1  cum_fail=0

The dwell is met five times over. The sample is 0 of 1.

standards/canary-rings.json lists petry-projects/TalkTerm and petry-projects/bmad-bgreat-suite as the ring1 members for ci-failure-analyst. Their caller stubs pin stable, not ring1:

The same TalkTerm repo pins -ring1 for dev-lead, agent-shield, auto-rebase, dependency-audit and most other agents, so this looks like a stub that was never moved rather than a deliberate choice.

Why nothing flagged it

• The gate reports SOAKING, not BLOCKED, so sync-issues never opens a blocker issue. A soak that cannot finish looks the same as one that is in progress.
• Every promote-all log line for this agent reads as normal.

Impact

Every consumer on the stable channel runs the three-month-old v1.0.0 analyst. 46 minor releases have not reached them.

Acceptance criteria

1. TalkTerm and bmad-bgreat-suite pin ci-failure-analyst/v1-ring1, matching the registry.
2. The gate has a defined answer for an agent whose runs are mostly skipped. I did not check whether a skipped run counts toward sample. If it does not, sample_min: 1 on ring1->stable may still take a long time to meet for a failure-triggered agent; decide whether to waive it, as ring0->ring1 already does with waive_sample.
3. sync-issues flags a stalled soak: dwell met several times over while the sample stays at zero.
4. A check compares each ring member's actual pin with its registered ring, for every agent. On TalkTerm, add-to-project and pr-auto-review also pin stable; confirm whether those repos are registered as ring1 members for those agents.
5. google-app-scripts moves off the legacy ci-failure-analyst/stable tag, and markets moves off the raw SHA pin, or each is recorded as intentional.

Related

• "Gate soak is vacuous: dwell/sample count runs from repos that are not executing the candidate" (Gate soak is vacuous: dwell/sample count runs from repos that are not executing the candidate — and dev-lead's 'next' tier is structurally unoccupiable (SC2 forbids its only member) #1086) is the earlier form of this. Now that runs are attributed to the candidate, the same pin mismatch produces a deadlock instead of a vacuous pass.
• "Canary Rollout times out: 6 of the last 7 scheduled runs hit timeout-minutes: 30" (Canary Rollout times out: 6 of the last 7 scheduled runs hit timeout-minutes: 30 and were cancelled — rings stop advancing silently #1175) and "canary-rollout: gate evaluation ~40% slower since feat: implement issue #1224 — canary-rollout health gate goes blind on an ADR-0007 collapsed repo: it resolves runs by per-role workflow NAME, which the ingress replaces with jobs #1238" (canary-rollout: gate evaluation ~40% slower since #1238 — 5 of 9 complete scheduled runs now hit the 30-minute timeout #1259) are separate. 23 of the last 30 scheduled sweeps were cancelled at the timeout, which delays every agent, but fixing that would not unblock this one.

Found while closing out the Opus 5.5 canary in combsmith/.github-private#1899. ci-failure-analyst does not use the engine's deep tier, so it is outside that story.