main is red at 9b324cda4. It was already red on the branch at ffbeb123d and 33c00dc94 before the merge, and nobody noticed because the builder's local suite was green.
The failure
FAIL src/agent-farm/__tests__/spec-146-phase-9-live-harness.test.ts
FAIL src/agent-farm/__tests__/spec-146-phase-9-porch-engine.test.ts
Error: Cannot find module '../../../../../porch-driver/dist/thread.js'
imported from packages/codev/src/agent-farm/__tests__/helpers/porch-thread-engine.ts
{ code: 'ERR_MODULE_NOT_FOUND' }
Root cause
.github/workflows/test.yml builds packages/types and packages/artifact-canvas before the unit tests. It never builds packages/porch-driver. porch-driver/dist/ is gitignored, so in a fresh CI checkout the directory does not exist and any import of it fails.
Locally it passed because developer worktrees already have a built dist/ from earlier work. That is the whole gap: a stale build artifact made the local run green and the clean run red.
Why it slipped through
PR #177 moved createPorchThreadEngine out of production source into __tests__/helpers/ precisely so the shipped dist/ would carry no cross-package import. That worked — the new pack guard proves every relative import in the packed dist/ resolves inside the tarball. The dependency simply moved into a test helper, where the pack guard does not look and where CI had no build step for it.
Fix
Add a build step for porch-driver before the unit tests, alongside the existing ones:
- name: Build porch-driver packageworking-directory: packages/porch-driverrun: pnpm build
Place it before "Copy skeleton for unit tests" so anything importing its dist/ finds it.
Verification that actually proves it
Do not verify by running the suite in a worktree that already has packages/porch-driver/dist/. That is the condition that hid this. Delete the directory first, then run:
rm -rf packages/porch-driver/dist
pnpm --filter @cluesmith/porch-driver build
npx vitest run src/agent-farm/__tests__/spec-146-phase-9-porch-engine.test.ts
and separately confirm the two named test files fail without the build and pass with it. A green run on a tree that was never cleaned proves nothing here.
Worth considering in the same PR
The two failing tests are the only consumers. If a porch-driver build step in CI feels heavier than the dependency deserves, the alternative is for the helper to import from the package's source rather than its build output, or to vendor the narrow surface it needs. Either removes the ordering requirement entirely. Use judgement; the CI step is the smaller change and is fine.
mainis red at9b324cda4. It was already red on the branch atffbeb123dand33c00dc94before the merge, and nobody noticed because the builder's local suite was green.The failure
Root cause
.github/workflows/test.ymlbuildspackages/typesandpackages/artifact-canvasbefore the unit tests. It never buildspackages/porch-driver.porch-driver/dist/is gitignored, so in a fresh CI checkout the directory does not exist and any import of it fails.Locally it passed because developer worktrees already have a built
dist/from earlier work. That is the whole gap: a stale build artifact made the local run green and the clean run red.Why it slipped through
PR #177 moved
createPorchThreadEngineout of production source into__tests__/helpers/precisely so the shippeddist/would carry no cross-package import. That worked — the new pack guard proves every relative import in the packeddist/resolves inside the tarball. The dependency simply moved into a test helper, where the pack guard does not look and where CI had no build step for it.Fix
Add a build step for
porch-driverbefore the unit tests, alongside the existing ones:Place it before "Copy skeleton for unit tests" so anything importing its
dist/finds it.Verification that actually proves it
Do not verify by running the suite in a worktree that already has
packages/porch-driver/dist/. That is the condition that hid this. Delete the directory first, then run:and separately confirm the two named test files fail without the build and pass with it. A green run on a tree that was never cleaned proves nothing here.
Worth considering in the same PR
The two failing tests are the only consumers. If a
porch-driverbuild step in CI feels heavier than the dependency deserves, the alternative is for the helper to import from the package's source rather than its build output, or to vendor the narrow surface it needs. Either removes the ordering requirement entirely. Use judgement; the CI step is the smaller change and is fine.