## What
Pins the CLI board glyph's terminal-lane resolve — **the last flagged
site in the repo-wide resolver audit.**
Two commits: a behaviour-preserving extraction, then the test.
## I was wrong to flag this as unpinnable
In #3236 I recorded this site as not pinnable, reasoning that
*"extracting a pure helper and testing it would look like coverage and
would not be."*
That is true of a helper that **receives** the lane set — such a test
passes with the resolve blinded, which is exactly the `reads.ts` trap
the audit note records. It is **not** true of one that **resolves** it.
Building `resolveReliabilityLanes` in #3237 made the distinction
obvious: the seam has to contain the resolve, and then blinding fails a
test of it.
So the flag was too broad, and correcting it closes the site rather than
leaving a permanent excuse. That is the same failure mode I corrected in
someone else's note earlier today — a caution that hardens into a reason
not to look.
## Measured
```
converted: Tests 5 passed (5)
blinded: Tests 2 failed | 3 passed (5)
```
The two failures are the **renamed complete** and **renamed archive**
lanes. The three survivors are the default-vocabulary control, the
active-lane negative, and the degrade path — all of which should
survive.
```
task-list-board-columns + bin: 82 passed
typecheck clean; lint clean; fnxc-future-dates: none added
```
## Why the sibling file did not cover it
`task-list-board-columns.test.ts` pins `boardColumnsForDisplay`, which
decides **which** lanes print. That function takes no lane set, so it
cannot fail when this resolve is blinded — and its own header says so
honestly. Two tests about the same command, one of which cannot see the
other's bug.
## What breaks without the conversion
On a board whose complete lane is `shipped`, a finished lane renders `●`
— the same glyph as active work. The board says work is in flight when
it shipped. Cosmetic next to the blank-board bug this area already
fixed, but wrong in the direction an operator reads at a glance.
## Also pinned
Two contracts the surrounding comments assert but nothing tested:
- **Cards come from the TASKS, not a resolved IR** — a card must never
depend on resolution succeeding to be *visible*. Asserted with an
unreadable workflow list.
- **A failed resolve degrades to the legacy pair**, with an unresolved
custom lane rendering as active — the documented fail-open direction.
Plus the paired negative: an ACTIVE lane keeps the active glyph under
both vocabularies, so widening the terminal set cannot mark the whole
board finished.
## Audit complete
Every `resolveProjectColumnsForRoles` call site in the repository —
`engine`, `core`, `dashboard`, `cli` — has now been blinded
individually, and every uncovered one is either pinned or has a recorded
reason it cannot be. Nothing is left flagged.
56e16d9dea