main is red: extension-retirement pack hook exceeds its 10s timeout after #215's build step

[pseudoseed]

Summary

main is red at 4ebaf36b6. One suite fails: packages/codev/src/__tests__/extension-retirement.test.ts,
whose beforeAll hook timed out at 10000ms after taking 10544ms. Everything else passed —
341 files, 6779 tests. The other five CI jobs are green.

FAIL src/__tests__/extension-retirement.test.ts
Error: Hook timed out in 10000ms.
 ❯ src/__tests__/extension-retirement.test.ts:12:1

Cause — verified from the diff, not inferred

PR #215 added a Build codev package step to the unit job (.github/workflows/test.yml), so
dist/, dashboard-dist/ and v2-dist/ now exist when the unit suite runs. They did not before.

The root package.json is:

{ "name": "cluesmith-codev", "private": true, "files": ["*", "!apps/streamdeck", "!apps/vscode"] }

files: ["*"] means the root pack sweeps everything except two directories. The test packs
the workspace root:

execFileSync('npm', ['pack', '--pack-destination', packDirectory], { cwd: workspaceRoot })

So the build step made the root tarball substantially larger, and a hook that was already close
to its 10s ceiling went over it. The build step is correct and should stay — without it the
publish-scrub guard silently narrows to committed files and passes vacuously, which is stated in
its own comment. The test is what needs to change.

Three defects here, not one

1. The pack is far more work than the assertion needs. The test writes a real tarball and
then shells out to tar -tzf purely to read a file list. npm pack --dry-run --json returns the
file list with no tarball written and no tar process. #214's own publish-scrub guard already
uses exactly that idiom. Note the path shape differs: --dry-run --json yields paths without
the package/ prefix, so the one assertion that uses them adjusts accordingly.

2. The expensive fixture is in beforeAll, but only one of five tests uses it. Four tests
(deletes the Stream Deck source tree, removes both extensions from active release automation,
keeps supported apps in the pnpm workspace, marks the retained VS Code source unsupported)
read files and pnpm list. They need nothing from the pack. When the hook timed out, all five
were reported skipped and the suite failed. One slow fixture took down four tests that never
depended on it.

3. There is no explicit timeout. It runs on the 10s default. A pack of a built monorepo will
keep growing; whatever number is chosen should be a deliberate one with a reason next to it.

Fix

All three, in that order. The first alone probably clears the red; the second is what stops the
next slow fixture from failing unrelated tests; the third makes the budget explicit.

Related

Same class as #208, which raised a timeout on a different pack test earlier today, and #200,
which recorded that pack tests do not belong in the unit suite. Three instances now of a pack
against real I/O sitting inside the unit suite on a default timeout. Worth deciding whether the
pattern gets a shared helper or an e2e split rather than a third individual patch — but not in
this fix. Get main green first.

[pseudoseed]

Fixed by PR #218, merged as 18f9eb2bb. main is green, verified per-job: Unit Tests, Package
Install Verification, Tower Integration, CLI Integration, Artifact-Canvas Browser and v2
Playwright all success, plus the standalone CLI Integration Tests workflow.

All three defects were fixed, not just the one that would have gone green.

1. The pack was far more work than the assertion needed. The test wrote a real 27.4 MB
tarball and shelled out to tar -tzf purely to read a list of filenames. It now uses npm pack --dry-run --json — no tarball, no tar process — which is the same idiom #214's publish-scrub
guard already used. The regression was measured with that flag before it was used to fix it:
#215's build step added 805 files and 12.4 MB to a root tarball now at 4,395 files.

2. The expensive fixture was in beforeAll but only 1 of 5 tests used it. When the hook died,
all five were reported skipped — one slow fixture took down four tests that read files and ran
pnpm list and never touched the pack. The pack is now a lazy call inside the single test that
needs it.

3. There was no explicit timeout. Now 60s, carrying what it was measured against and why 12x,
so whoever raises it next knows what they are trading rather than picking another round number.

The helper also throws on an empty file list, since an empty list satisfies both not.toContain
assertions without proving anything. That was not in the three items above; it is what keeps the
test from passing vacuously, which is the same property as the #214 guard it borrows from.

The build step stayed

Worth being explicit, because reverting it was the cheap green available all evening. #215 added
pnpm build to the unit job so the publish-scrub guard scans real build output instead of
silently narrowing to committed files. Dropping it would have made main green and made the
guard meaningless. The test was what was wrong.

Accounting, confirmed by CI rather than by arithmetic

The red run was 6,779 passed / 68 skipped. Green main is 6,784 / 63 — the 5 extension-retirement
tests moved from skipped to passing, and 63 is exactly the 51 unconditional skips plus the 12
CI-gated session-manager tests derived from the source by brace-matching before any of this
ran. Prediction and observation agree. Nothing in the remainder is unexplained.

Not fixed here

The spec-1280 determinism failure hit during this work was a moved HEAD, not a real red: a
porch command committed state mid-suite. Filed as #217, where the defect is that the test
reports "not deterministic" for a case in which it could not measure determinism at all.

This is the third pack-against-real-I/O test in the unit suite to bite in one day, after #208 and
#200. Whether that pattern gets a shared helper or an e2e split is still open and is not decided
by this fix.