Files
fusion/packages/engine
gsxdsm 9a2a033b9e fix(test): two engine reds from fleet churn — and stop the shellout guard breaking on line drift (#2757)
Both failures are fleet-churn fallout on `main`, not defects in the
conversions. Engine goes **5 failed / 3 files → 3 failed / 1 file**; the
remaining 3 are `executor-prompt`'s pause-guard question, documented in
#2747.

## 1. The shellout guard was coupled to line numbers — third time

Its match key was `file:LINE:primitive:signature`, so **any edit above
an audited call site** broke it while the call itself was untouched.
Recent fleet conversions shifted `executor.ts` and `self-healing.ts`,
and 5 sites drifted at once.

**This is the third time it has gone red this way, and the third hand
re-pin.** A guard that fails on edits it does not care about trains
people to re-pin it without reading it — which is exactly how a real new
shellout slips through in the same commit as a drift fix.

So this removes the coupling rather than updating the numbers again.
Identity is now **file + primitive + signature**, with a **per-key
count**; `line` stays as documentation.

The count preserves what `line` was actually buying: a *second
identical* shellout in the same file is still unmatched, because the
allowlist declares how many of that exact call it audits. What is
deliberately given up is distinguishing "the audited call moved" from
"it stayed put" — which this guard has no reason to care about.

**Measured, all three directions:**

| mutation | result |
|---|---|
| add a NEW, different shellout | **2 failed** / 1 passed |
| **duplicate** an already-audited shellout | **2 failed** / 1 passed —
what `line` used to catch |
| pure line drift above an audited call | **3 passed** — previously the
false failure |

## 2. A test that predicted its own flip

`executor-execution-policy-renamed-columns` asserted `moveTask` was
never called. It now rehomes the card to `inbox`.

That is not a surprise — **the test's own comment called it**:

> *"the resume router's log says 'moved back to todo' and its
already-there check is another `"todo"` literal — one of the 20 sites in
this method left to U5's executor slice. It is why the card stays put
here rather than being rehomed to `inbox`."*

A fleet PR converted that literal, and the router now rehomes to `inbox`
— the declared intake column of `noHoldIr`, the workflow under test.
**The prediction landing is the evidence the conversion is right**, so
the case asserts the rehome instead of the absence of a move, and
additionally pins that the card is never moved to the `todo` this
workflow does not declare.

What the case owns is unchanged: the dispatch-loop gate did not claim
the card (no *"executor recovery preserved"* log), and the run reached a
real classifier rather than falling off the end.

## Verification

`pnpm test:gate` **726**, `pnpm lint` clean, engine `tsc --noEmit`
clean.

## Note on PR count

This is my fourth open PR against the one-per-worker rule, opened
because it clears **red on main** — the stated priority-one exception.
My other three (#2753, #2747, #2743) are rebased onto current main,
green, with zero unresolved threads, waiting only on CI. I am opening
nothing further until they land.
2026-07-30 06:54:44 -07:00
..
2026-07-26 18:11:47 -07:00