## What
Applied #3214's blinding procedure **outside `self-healing.ts`**, where
that measurement has never been run. Two of the five resolvers across
the two reporters were uncovered; this covers both.
## The measurement
One resolver at a time, blinded back to its legacy ids, against each
file's existing suite:
| site | blinded to | result |
|---|---|---|
| `backlog-pressure-reporter.ts:87` hold | `["todo"]` | 2 failed —
covered |
| **`backlog-pressure-reporter.ts:88` wip** | `["in-progress"]` | **0
failed of 11 — UNCOVERED** |
| `backlog-pressure-reporter.ts:89` terminal | `["done","archived"]` | 1
failed — covered |
| `stale-task-reporter.ts:59` wip | `["in-progress"]` | 1 failed —
covered |
| **`stale-task-reporter.ts:60` review** | `["in-review"]` | **0 failed
of 7 — UNCOVERED** |
Both uncovered resolvers sit in a `Promise.all` **beside one that is
covered**, so each sweep reads as converted while half of it was held by
nothing. That is rule 1 in the doc — coverage is per-resolver, not
per-sweep — and it is why the census cannot answer this: a syntactic
scan sees five resolved sites and five is what it counts.
`stale-task-reporter.ts` is the sharper case. Its describe block
**already declared `signoff` in the fixture IR** and no case ever put a
card there, so the review resolver was decorative.
## What they cost on a renamed board
- **wip** feeds `inProgressCount`, the *denominator* of `ratio =
todoCount / max(inProgressCount, 1)`. Against the literal, busy work in
a renamed lane counts as **zero**, the ratio inflates, and the
backlog-pressure alert fires on a queue that is draining normally — the
operator is paged that the board is jammed while agents work through it.
- **review** decides which rows the staleness read *fetches at all*. A
review stalled for days in a renamed lane is never queried and never
surfaced — precisely the condition this reporter exists to report.
## Following the four rules
**Rule 2 — the fixture reaches the guarded branch.** 12 hold cards over
2 wip cards is a ratio of 6, *under* the default threshold of 10, so the
correct answer is "no alert"; blinding collapses the denominator to 1,
the ratio becomes 12, and it alerts. A fixture whose ratio cleared the
threshold either way would exercise the sweep and never touch the line
under test.
**Rule 3 — assert the path-specific side effect.** `upsertInsight` not
called, and `logEntry` called with `column=signoff`. Asserting `alerted
=== false` alone would also pass if the run bailed for an unrelated
reason — missing insight store, cooldown, too few candidates — none of
which involve the wip lane.
**Rule 4 — the store fake honours `options.column`.** Both harnesses
already did; reused rather than replaced.
Each new case is paired with a negative so it cannot pass vacuously: the
"does not alert" case is backed by a *same renamed board still alerts
when in-progress work really is thin* case, so a reporter broken into
never firing fails.
## Census
**Unchanged — `CONVERSION QUEUE EMPTY`, `AVAILABLE: 0` before and
after.** This converts nothing. It closes coverage on conversions the
census already counts as done, which is the gap #3214 names: *"the
census counts comparisons; it cannot tell a working conversion from one
a later merge silently reverted."*
## Verification
Blind-verified in both directions — blinding each resolver fails
**exactly** the new case and nothing else:
```
backlog-pressure BLIND wip -> 1 failed | 12 passed (13) restored: 13 passed
stale-task BLIND review -> 1 failed | 7 passed (8) restored: 8 passed
combined 21 passed (2 files)
```
No changeset: test-only, behavior-preserving, no published-package
surface.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>