## The unwired-parameter guard has been red on `main`
```
A parameter LEAVING this list is the goal; one arriving is a regression — update the list only to shorten it.
expected [ …(16) ] to deeply equal [ …(17) ]
```
Reproduced on clean `origin/main`, so it is not a branch artifact.
`packages/engine/src/scheduler.ts isWipColumn` is **supplied at both
production call sites now** — `self-healing.ts:4754` and `:5825` pass
`isWipColumn: completedWipColumns.has(blocker.column)` and the
blocked-lane equivalent, wired by #2975/#2987. The list was not
shortened in the same change.
So this is the good direction: a parameter got wired. The assertion just
was not told.
## Shortened, not re-recorded
I diffed the computed set against the recorded one rather than
regenerating:
```
DEPARTED (wired since): packages/engine/src/scheduler.ts isWipColumn
ARRIVED (new): (none)
```
Exactly one departure, nothing arrived — so removing that single line is
the whole fix, and it follows the file's own instruction (*"update the
list only to shorten it"*). Re-recording wholesale would have silently
absorbed any arrival too, which is the one thing this ratchet must not
do.
## How it was found
While measuring an unrelated change to the sibling census. **This suite
is outside the merge gate**, which is why a red assertion sat unnoticed
— the same reason #2969's 15 red agent-action tests survived, and worth
noting as a pattern rather than a one-off.
## What I abandoned to get here, and why it belongs in this PR's story
I was trying to remove two false positives from the sibling
`check-lane-wiring` census — `bucketForTask(task: TaskItem)` and
`otherBucketSecondaryLabel(task: TaskItem)`, both flagged only because
`TaskItem` declares `columnFlags?`, both reading it off the entity
internally.
The rule I tried was the sibling guard's own documented one: a
**required** parameter is enforced by the compiler, so it is not this
census's question. It measured perfectly — 15 sites → 13, removing
exactly those two and retaining every genuine entry.
Then it failed `lane-wiring-census-named-types.test.ts`:
```ts
export type MergeContext = { completeColumns?: ReadonlySet<string> };
export function canMerge(task: string, context: MergeContext): string { … }
```
A **required** parameter with a named options type is a shape that
census deliberately covers — `canMerge(task, {})` really can omit the
lane member. My "exact" rule was exact only against the current tree,
and it broke a tested contract. I dropped it rather than edit their test
to match my change.
The two false positives therefore stay baselined, and the cost stands as
previously recorded: a genuinely new unwired call in those two TUI files
would be masked. I do not have a rule I can prove safe, and three
attempts at this class have now traded false positives for worse false
negatives.
## Verification (measured)
- both guard suites — **18 passed / 0 failed** (was 1 failed)
- `check-lane-wiring`, `lifecycle-column-census --strict`,
`check-fnxc-future-dates` — green
- `eslint` — clean (one pre-existing warning, no errors)
Test-only; no product file touched. No changeset.
d4add985fe