Files
fusion/packages/engine
gsxdsm 3146a745bf test(engine): cover two reporter resolvers that no test could tell from the literal (#3217)
## 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>
2026-07-31 11:50:25 -07:00
..
2026-07-26 18:11:47 -07:00