## What
Extends
`docs/solutions/workflow-learnings/blind-the-resolver-to-find-uncovered-conversions.md`
with what this session's audit work paid for. Docs only — no code, no
changeset (internal doc).
## The main addition: the audit's own failure modes
**Every wrong reading this method has produced came from test
*selection*, not from the blind.** Three in one session, each of which
reads exactly like coverage:
| what I ran | why it lied |
|---|---|
| `vitest run src/__tests__ -t "executor"` | `-t` filters test
**names**, not files. Reported two `executor.ts` resolvers uncovered;
**both are covered.** |
| `blind3.py <file> <var>` with an unmapped role | exited non-zero
**silently**; `&&` skipped the check and `;` let vitest run against
**unmodified source**. Reported "375/375 green under blinding" with
nothing blinded. |
| `vitest run src/__tests__/notification` | missed
`src/notification/__tests__/` — a nested `__tests__` the glob never
reached. Reported covered code as uncovered. |
The rule that follows: an UNCOVERED verdict is a claim about the whole
tree and needs the whole tree's tests. Confirm the blind actually
modified the file with `git diff --stat` — *not* the tool's exit code —
and that the run included every file importing the module.
I am documenting my own instrument failing the standard I have been
applying to product guards all phase: *a guard that reports success
without checking anything is worse than no guard.* Mine reported success
without checking anything. It now echoes what it substituted and where,
and fails loudly on an unmapped role or missing variable; I self-tested
both directions before trusting any number in #3219 and #3221.
## Rule 5: the resolver must be able to answer differently in the
harness
`resolveProjectColumnsForRoles` returns **legacy ids and nothing else**
when the store has no `listWorkflowDefinitions` — an intentional degrade
so an unreadable workflow list cannot fail a sweep. A harness omitting
it makes the resolved set and the literal set **equal by construction**,
so the conversion is unobservable however good the assertion is.
This is not a test bug. It is correct production behaviour that erases
the difference the test is trying to measure — and it alone left both
the `scheduler.ts` and `triage.ts` conversions unpinnable.
## A correction to my own earlier rule
I had "seed-then-union sites hide defects" too broad. Such a site hides
a defect **only while every lane you assert on is already in the seed**.
On a renamed board the resolver is the sole contributor of the renamed
lane, so the legacy blind is *not* a no-op — I predicted it would be and
it failed. Also: expand roles to legacy ids **per role** from
`LEGACY_COLUMN_IDS_BY_ROLE`; `intake` is `["todo","triage"]`, not
`["triage"]`, and a stricter-than-real blind manufactures failures that
read as coverage.
## Inventory, so the gap is legible
**116 non-test call sites across 30 files** — core 17, engine 10,
dashboard 2, cli 1. Audited so far, all in engine: `self-healing.ts` (64
mapped / 21 pinned / 1 inert by construction), `executor.ts` (2,
covered), `scheduler.ts` (uncovered → pinned in #3219), `triage.ts`
(uncovered → pinned in #3221), `restart-recovery-coordinator.ts`
(covered), `notification-service.ts` (covered).
**`packages/core`'s 17 files are entirely unaudited.** Stated as a gap
rather than left implied, so nobody reads engine's coverage as a
repo-wide clean bill.
## Flagged, not guessed
- `evaluator.ts`'s archived read is uncovered — **no test file imports
that module at all.** Left unpinned deliberately: it is a thin
pass-through into `collectDeterministicSignals`, which is testable
directly, and it affects eval signal quality rather than task lifecycle.
Recorded in the doc rather than silently skipped.
- I did not audit core; it is outside my package and I am not claiming
anything about it either way.
206ff11874