From d4add985fe8ec9ebe8a3c2018784997f5367b1ca Mon Sep 17 00:00:00 2001 From: gsxdsm Date: Fri, 31 Jul 2026 01:44:11 -0700 Subject: [PATCH] =?UTF-8?q?test(engine):=20the=20unwired-parameter=20guard?= =?UTF-8?q?=20has=20been=20red=20on=20main=20=E2=80=94=20its=20list=20is?= =?UTF-8?q?=20stale=20by=20one=20(#3033)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## 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 }; 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. --- .../__tests__/unwired-lane-parameter-guard.test.ts | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/packages/engine/src/__tests__/unwired-lane-parameter-guard.test.ts b/packages/engine/src/__tests__/unwired-lane-parameter-guard.test.ts index 643d957730..b91babea2b 100644 --- a/packages/engine/src/__tests__/unwired-lane-parameter-guard.test.ts +++ b/packages/engine/src/__tests__/unwired-lane-parameter-guard.test.ts @@ -80,6 +80,18 @@ file + parameter rather than line so an unrelated edit above them does not manuf Wiring them is not this change's job — they span core, engine and dashboard, i.e. three other batches — and pretending they did not exist for another week is worse than listing them. */ +/* +FNXC:WorkflowLifecycleColumns 2026-07-31-17:05: +`scheduler.ts isWipColumn` LEFT this list, which is the direction it is supposed to move. + +It 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 assertion has been RED on `main` +since: 16 found against 17 allowed. + +Removed rather than re-recorded wholesale, per this file's own instruction two paragraphs down — +"update the list only to shorten it". Nothing arrived; the delta is exactly this one departure. +*/ const KNOWN_UNWIRED = [ "packages/core/src/blocker-fanout.ts escalationColumns", "packages/core/src/blocker-fanout.ts holdColumn", @@ -96,7 +108,6 @@ const KNOWN_UNWIRED = [ "packages/dashboard/app/utils/taskActivity.ts columnFlags", "packages/dashboard/app/utils/taskTiming.ts columnFlags", "packages/engine/src/runtimes/in-process-runtime.ts terminalColumns", - "packages/engine/src/scheduler.ts isWipColumn", "packages/engine/src/scheduler.ts satisfactionColumnsByTaskId", ].sort();