#2966 shipped a gate that **cannot detect the defect named first in its
own header.**
`findLaneAcceptingFunctions` matched a lane parameter only when
`param.type` was a `TypeLiteralNode` — an inline `{ reviewColumns?: …
}`. But the real code declares these as interfaces:
```ts
export function getInReviewStallReason(
task: Pick<Task, …>,
context: InReviewStallContext = {}, // TypeReference — invisible
): InReviewStallSignal | undefined
```
so the function never entered `accepting` and none of its call sites
were examined.
### Measured, both directions
| | before | after |
|---|---|---|
| lane-accepting functions detected | 20 | **30** |
| `getInReviewStallReason` detected | no | **yes** |
| re-introduce #2956 (drop `reviewColumns` from one call site) | `none
added` — **passes** | **fails**: `reads.ts: 7 unwired now, baseline
allows 6` |
The gate now catches the thing it was built for.
### The baseline moves 10 → 24, and that number needs context
`10 unwired call site(s) across 8 files` → `24 across 15`. **No entry
was removed** — every previously-recorded file kept its count and 14
sites became visible for the first time:
```
core/task-store/reads.ts 0 -> 6
engine/self-healing.ts 2 -> 4
core/task-store/branch-and-pr-entities.ts 0 -> 1
core/task-store/task-update.ts 0 -> 1
engine/scheduler.ts 0 -> 1
dashboard/routes/register-task-workflow-routes 0 -> 1
cli/commands/dashboard-tui/bucket-mapping.ts 0 -> 1
cli/extension.ts 0 -> 1
```
**These are newly VISIBLE, not newly broken** — they have been unwired
all along. I have **not** audited them, and recording them in the
baseline is not a claim that they are fine; it is the ratchet doing what
its header describes, since the census's own note says roughly half of
the original hits were legitimately unwired (identity proven by a
stronger means, sentinel columns, dead exports). Someone should walk the
14. Two stand out as worth a look first: **`reads.ts` at 6** is the file
#2956 was about, and **`scheduler.ts`** is a dispatch path.
Flagging rather than fixing, because wiring a call site that should not
be wired is its own defect and each needs the judgement call the census
header describes.
### Regression test
`packages/engine/src/__tests__/lane-wiring-census-named-types.test.ts`
pins the detector's shape — named interface, type alias, inline literal,
positional — against fixtures rather than live counts, so it does not
churn when someone legitimately wires a call site. Plus one anti-vacuity
case asserting the named-type arm is still load-bearing on real source
(`getInReviewStallReason` resolves in the live tree), so the fixtures
cannot pass while the tool has quietly stopped applying here.
**Mutation:** removing the `TypeReference` arm fails **4 of 5**.
### Also worth knowing
`findLaneAcceptingFunctions` still only visits
`ts.isFunctionDeclaration` at top level, so `export const fn = (ctx) =>
…` remains invisible. I checked — no exported arrow function currently
takes a lane argument, so nothing is missed today, and I left it rather
than widen the surface in the same change.
Resolved by **name across the corpus** instead of a type-checker
`Program`: these are plain source scans and a checker would cost a full
type-resolution pass for one lookup. Two same-named types merge, which
only ever widens what counts as wired — safe for a ratchet.
**Verified:** 5/5 new tests, `check-lane-wiring` clean at the new
baseline, lint clean, FNXC gate exit 0. Core suite on main is green
(4923 passed / 0 failed) — unrelated, but I had it running.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Improved lane-wiring analysis to recognize named interfaces and type
aliases.
* Added support for wrapped configuration expressions and positional
parameters when detecting lane information.
* **Tests**
* Added comprehensive coverage for lane-wiring detection, including
named contexts and live-tree validation.
* **Chores**
* Updated baseline counts to reflect newly recognized application areas
and improved self-healing detection.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
41af5e5dbd