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

For dev-lead, the next ring can never have an occupant. Its dwell and sample are therefore permanently vacuous, and the next->ring0 transition reports healthy soak numbers for a tier nobody executes.

The contradiction

standards/canary-rings.json defines dev-lead's first ring as the host repo alone:

"rings": [ { "channel": "next", "members": ["$host"], "order": 0 }, ... ]

$host is petry-projects/.github-private.

But petry-projects/.github-private's own dev-lead.yml is required by Safe Release SC2 to pin a stable-tier channel, asserted by tests/test_sc2_self_review_channel.bats (#1624, the automatable half of #503 / epic #495):

a deliberately-broken in-development version of this repo's agentic review/merge duty MUST NOT be able to block the PR that fixes its own breakage. The structural property that guarantees this … is that dev-lead.yml — although this repo sits in ring next — pins its dev-lead reusable to a stable-tier channel.

The test comment even acknowledges the tension ("although this repo sits in ring next") and resolves it in favour of stability — correctly. But that means next's only member is forbidden from pinning next. No other repo is a member. So the tier has no possible occupant, now or ever.

Why it matters

The gate measures a candidate's health across ring member repos. If a tier's members do not execute the candidate, the resulting dwell/sample carry no information about it — but they are reported as though they do.

Observed today on the ring1->stable frontier:

ring1->stable  BLOCKED  dwell=88h/12h  sample=196/1  cum_fail=3

196 executed runs against a floor of 1, and 88 hours of dwell against 12 — while no repo in the fleet was running the candidate:

.github              pins v1-ring0     -> 6d362318   (not the candidate)
.github-private      pins v139-stable  -> 40f6c232   (not the candidate)
markets              pins v139-stable  -> 40f6c232   (not the candidate)
TalkTerm             pins v1-ring1     -> 6d362318   (not the candidate)
bmad-bgreat-suite    pins v1-ring1     -> 6d362318   (not the candidate)
google-app-scripts   pins v139-stable  -> 40f6c232   (not the candidate)
ContentTwin          pins v139-stable  -> 40f6c232   (not the candidate)
                     candidate = 90dcc01c            (occupants: none)

All three counted failures came from repos running 40f6c232 or 6d362318. One of them was an exit-124 timeout, which the registry's workload-timeout suspect class asks "did this candidate change execution-time-sensitive code?" — a question that run cannot answer, because it never ran the candidate.

Separately from the empty-tier situation (which the repin work in #1063 fixes), the next tier's vacancy is structural and will survive that work.

What this is not

• Not an argument to weaken SC2. Keeping the self-host repo on a stable tier is correct and was validated in practice — it caught a mis-repin of that stub to next on petry-projects/.github-private#1653.
• Not the same as ship-drift reports '0 agents merged-but-unshipped' while all 7 dev-lead stubs are 29-181 commits behind — it compares the 'next' channel, which no stub pins (the #1592 detector is blind to #1592) #1049 (ship-drift compares the next channel to main, and no stub pins next). That is a reporting bug; this is a registry/topology contradiction. They share a root cause — reasoning about repos by ring membership while repos execute whatever tag they pin — but need different fixes.

Options

1. Make next explicitly unoccupied for self-hosting agents and skip it. Let ring0 be the first evidence-bearing tier for dev-lead, and have the gate report next->ring0 as NO_COVERAGE rather than a satisfied soak.
2. Give next a real member — a non-self-hosting repo willing to run the bleeding edge. Note pr-review-trigger.yml already does exactly this for pr-review (pins pr-review/v1-next deliberately, and is explicitly excluded from the SC2 stable duty), so the pattern exists.
3. Report coverage honestly. Whatever the topology, the gate should distinguish "N runs executed the candidate" from "N runs happened in member repos". This is the generally-correct fix and subsumes the others.

Acceptance criteria

• The gate distinguishes runs that executed the candidate from runs that merely occurred in a member repo, and the sample figure counts only the former.
• A transition whose members do not execute the candidate reports a distinct state (e.g. NO_COVERAGE) rather than a satisfied dwell/sample. It must not read as a clean soak.
• cum_fail excludes failures from runs that did not execute the candidate — they cannot be evidence about it either way. (Note: this is not the same as the withdrawn Follow-up to #1047 (slice 2): exclude concurrency-evicted runs from cum_fail and sample, and name the counted run ids in evaluate output #1054; that one wrongly proposed counting cancelled runs. This is about version attribution.)
• Resolve dev-lead's next tier explicitly — either give it a member, or mark it non-evidence-bearing — so the contradiction with SC2 is recorded in the registry rather than implicit.
• Regression test using today's real topology: candidate 90dcc01c with zero occupants must not produce dwell=88h/12h sample=196/1.

Refs #1049, #1066, #1063, petry-projects/.github-private#1592, petry-projects/.github-private#1624, #503, #548, #657

Split 2026-09-13: now a tracking parent

The single pass timed out at the 2100s action budget (run 34735591102). That timed-out run then became the exact false positive this issue describes: it executed v139-ring0, yet it was counted as triage=REGRESSION against candidate ae4afa59, which no repo runs.

• [#1086 slice 1] Gate counts a failure against a candidate only if the run executed it (referenced_workflows attribution) #1120 slice 1: count a failure only if the run executed the candidate (referenced_workflows attribution). AC3. Blocked by canary-rollout ring promotion can skip the v-scoped channel tag, breaking every stub deployed to that tier #1065 and canary-rollout evaluates only the newest candidate — every new cut cancels a pending ring1→stable human confirmation, so dev-lead stable is frozen at 09-07 #1118, which edit the same file.
• [#1086 slice 2] Dwell/sample count only candidate-executing runs; report NO_COVERAGE when none #1121 slice 2: dwell and sample count only candidate-executing runs; NO_COVERAGE state. AC1 + AC2. Blocked by [#1086 slice 1] Gate counts a failure against a candidate only if the run executed it (referenced_workflows attribution) #1120.
• [#1086 slice 3] Record dev-lead's next-tier SC2 contradiction explicitly in canary-rings.json #1122 slice 3: record dev-lead's next-tier SC2 contradiction in the registry. AC4. Blocked by [#1086 slice 2] Dwell/sample count only candidate-executing runs; report NO_COVERAGE when none #1121.
• Related: workload-timeout suspect class can never match: signature is failed-step names, dev-lead's timeout step is 'Run issue' #1123, the workload-timeout suspect class that can never match, blocked by [#1086 slice 1] Gate counts a failure against a candidate only if the run executed it (referenced_workflows attribution) #1120.

Do not implement from this parent.