## Eleven inert guards were invisible to the check that exists to find
them
#3062 shipped this check collecting sync-lane sources **per file**, and
recorded the module-boundary gap as a known limit. That limit has
stopped being theoretical.
`resolvePlannerLanes` is defined in `replan-target.ts` and consumed in
`triage.ts` and `executor.ts`. `triage.ts:723` already reads:
```ts
if (task.column === disposeLanes.hold || task.column === disposeLanes.intake || task.column === "in-progress") return;
```
A sync-resolved pair sitting directly beside a literal. That is
precisely the site a fleet worker reaches for next — the "conversion" is
a one-word edit, it drops the census by one, and it changes nothing,
because `resolvePlannerLanes` resolves through
`store.resolveTaskWorkflowIrSync` and always describes the default
board. **The shipped check could not have seen it.**
## What changed
Sources are collected in a **first pass over the whole tree**;
consumption is counted in a **second pass** against that repo-wide set.
| file | guards now visible |
|---|---|
| `packages/engine/src/scheduler.ts` | 18 |
| `packages/engine/src/triage.ts` | **7 — previously invisible** |
| `packages/engine/src/executor.ts` | **4 — previously invisible** |
**Baseline 20 → 29. The rise is detection, not regression.** Those
eleven guards were already inert; nothing in the tree got worse and no
production file is touched by this PR. Flagging that explicitly because
the check's own failure text says *"do NOT re-record the baseline to
clear this"* — that rule is about a code change, and this is a detector
widening. The distinction matters and I would rather state it than have
it inferred.
## Mutation evidence, on the motivating site
Converting `triage.ts`'s literal to `disposeLanes.wip` — the exact inert
edit this widening exists to prevent:
| | result |
|---|---|
| check as shipped on main | **exit 0** — missed entirely |
| this PR | **exit 1**, `triage.ts: 7 → 8` |
`scheduler.ts` restored clean after every run.
## Third widening — and the honest read on that
This is the third hole found in this check, each discovered the same
way:
1. **#3062**: matched only the local-variable spelling; the inline
`resolveX(...).review` walked past.
2. **#3068**: matched only comparisons; `parked.terminal.has(to)` walked
past — and worse, made the count *fall*, inviting a re-record that would
have retired live sites.
3. **here**: matched only same-file sources; a cross-module helper
walked past.
Every time, the check was correct about the shape in front of it and
blind to a trivially different spelling of the same defect. I said in
#3068 that the durable fix is to key on **the source** rather than
enumerate consuming syntax; this closes the module-boundary half of
that. The remaining half is value-level dataflow (a sync-resolved id
assigned through an intermediate, passed as an argument, or returned),
which needs a type-aware pass and is a larger change than a gate script
should carry casually.
I am not claiming this version is complete. It is measurably better than
the shipped one on a site that exists in the tree today.
## Census before / after
```
before: COLUMN guards (the backlog): 84
after: COLUMN guards (the backlog): 84
```
Unchanged — this converts nothing. It makes eleven already-inert guards
countable so the next conversion of them fails loudly instead of reading
as progress.
## Verification
`test:gate` exit 0 · `pnpm check:inert-sync-lanes` exit 0 ·
lifecycle-column census exit 0 · `pnpm lint` clean. Gate script +
baseline only.
Still open and unrelated: **#3073** re-greens the archived-gate parity
ratchet, which is red on `main` right now and sits outside the merge
gate.
7d75633daa