extension-retirement asserts apps/streamdeck is absent from disk, so a stale node_modules blocks every gate in the workspace

[pseudoseed]

Blocking two gate approvals on 2026-08-31 (#272's dev-approval and #273's pr gate).

The failure

FAIL src/__tests__/extension-retirement.test.ts > extension retirement >
 deletes the Stream Deck source tree rather than merely excluding its package
AssertionError: expected true to be false
 ❯ src/__tests__/extension-retirement.test.ts:46:64

Tests 1 failed | 7461 passed | 58 skipped. It is the only failure in the suite.

Cause

apps/streamdeck/ exists in the working tree. The test asserts it does not.

It is not tracked (git ls-files apps/streamdeck returns nothing) and it is not gitignored. What it contains is one stale directory:

apps/streamdeck/node_modules

6 files, all under node_modules, 0 files outside it. It is left over from before the Stream Deck source was deleted: the source went, the installed dependencies did not.

So the assertion is true of the repository and false of this machine, and the test reads the machine.

Why it matters beyond one directory

This is the same shape as #278. A test that reads a live working tree cannot distinguish "the repository still ships this" from "someone's checkout has a stale directory". Both spell themselves as one red test with the same message, and the message names neither possibility.

The cost is concrete: it fails the shared porch tests check, which gates every project in the workspace, so a leftover node_modules on one machine blocks gate approvals for unrelated work. Two are held on it right now.

It is also invisible to CI, where a fresh checkout has no stale directory, so nothing catches it until someone runs the suite locally.

What would close this

• The assertion should be about what the repository tracks, not about what is on disk. git ls-files apps/streamdeck returning empty is the claim the test is actually trying to make, and it is true regardless of what is left in a working tree.
• If the on-disk check is wanted as well, it must distinguish "tracked source is present" from "untracked build output is present" and say which in the message, rather than reporting one boolean.

Immediate unblock

Removing the stale directory clears it. Nothing tracked is in it and nothing outside node_modules is in it.

[pseudoseed]

Two additions, both verified.

The failure direction is inverted, which is why it went unnoticed. git worktree add does not copy untracked files, so apps/streamdeck/ exists only in the main checkout and in no builder worktree. extension-retirement.test.ts:46 is a bare existsSync on the live working tree, so the test is green for every builder and red only at the workspace root. Builder pir-272 confirmed the directory is absent from its worktree, which is why its own porch done passed while every gate approval I ran from the root failed.

Nothing hits this until an approval runs from the workspace root, which is exactly where gate approvals run.

Unblocked without deleting. I moved the directory to a session scratchpad rather than removing it, so nothing is destroyed and it can be restored. git ls-files apps/streamdeck was empty and there were 0 files outside node_modules, so nothing tracked was involved either way.

That does not change the fix this issue asks for. The next stale directory in any main checkout will block gates the same way, and the message will again name neither the directory nor the possibility that it is untracked build output.