7d75633daa
## 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.
9 lines
162 B
JSON
9 lines
162 B
JSON
{
|
|
"total": 29,
|
|
"byFile": {
|
|
"packages/engine/src/executor.ts": 4,
|
|
"packages/engine/src/scheduler.ts": 18,
|
|
"packages/engine/src/triage.ts": 7
|
|
}
|
|
}
|