fix(types): resolve the automations export from source like every other subpath

[reachjalil]

Fixes the two workflows that have failed on every dev push since 4d50c7f5: Alpha Channel (macOS arm64) and Dev Daytona Snapshot.

error: Could not resolve: "@openwork/types/automations". Maybe you need to "bun install"?

Root cause

apps/server's build script bundles the OpenCode plugins with --target node:

bun build src/opencode-plugins/openwork-extensions-preview.ts … --target node --format esm

--target node selects the node export condition, and ./automations was the only one of the package's seventeen subpaths that pointed at a build artifact:

"./automations": {
  "bun":     "./src/automations.ts",
  "node":    "./dist/automations.js",   ← requires a prior build
  "default": "./dist/automations.js"
}

Neither the Daytona Dockerfile nor the alpha Electron build guarantees packages/types is built before the server bundle runs, so dist/automations.js was missing and resolution failed.

The trigger was #3552, which added the first runtime-value import from @openwork/types into that bundle (automationProposalSchema). Every earlier import — openwork-affordance, openwork-context, openwork-provider — is type-only and maps to ./src/*.ts in every condition, so nothing had ever exercised the node condition on a dist-backed subpath. #3554 and #3556 inherited the breakage; they did not cause it.

The fix

Point ./automations at source, matching its sixteen neighbours:

"./automations": {
  "types": "./src/automations.ts",
  "development": "./src/automations.ts",
  "default": "./src/automations.ts"
}

Why this is safe for Den, which runs node dist/main.js on node:22-bookworm-slim and resolves @openwork/types at runtime rather than bundling it: five sibling subpaths already resolve from source in that exact path today — including @openwork/types/den/inference, which exports runtime values (INFERENCE_MODEL_ALIASES) and appears in Den's compiled dist/. This change makes automations behave like the imports Den already depends on in production, rather than introducing a new pattern. I also confirmed both subpaths import cleanly under default conditions (locally on Node 26; the production image is Node 22, where the same five siblings already prove it), and that pnpm --filter @openwork-ee/den-api build still succeeds.

Why CI missed it, and what now catches it

Two independent gaps:

1. Both workflows are push-only — they run on push to dev, never on pull_request. feat(automations): propose an Automation from chat #3552 went green on all 23 PR checks without either one running.
2. No PR check took that resolution path. Typechecks resolve through TypeScript; bun tests pick the bun condition and read source. My own pre-merge verification hit the same blind spot — I built with --target bun-darwin-arm64, which resolves fine even with dist deleted.

So the fix ships with two guards:

• CI: the PR lane now deletes packages/types/dist and runs pnpm --filter openwork-server build, exercising the exact --target node resolution the packaged builds use.
• Unit test: types-package-exports.test.ts fails if any subpath goes back to resolving through dist/, so the next runtime module added to this package cannot reintroduce the trap.

Verification

Reproduced the failure locally first (clean tree, no packages/types/dist, --target node) — identical error. After the fix, from the same clean tree:

• pnpm --filter openwork-server build — passes with no packages/types/dist present
• pnpm --filter @openwork-ee/den-api build — passes
• pnpm --dir apps/server typecheck, pnpm --filter @openwork/app typecheck, pnpm --filter @openwork-ee/den-api typecheck:automations — pass
• Node import check of @openwork/types/automations and @openwork/types/den/inference under default conditions — both resolve
• Server suite — 622 passed, 1 failed; the failure is the pre-existing node:sqlite resolution error that reproduces identically on unmodified dev. Not introduced here, not claimed as passing.
• Den automations suites — 15 passed

No dependency changes, so pnpm-lock.yaml is untouched.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-app	Ready	Preview	Aug 5, 2026 10:16am
openwork-den	Ready	Preview	Aug 5, 2026 10:16am
openwork-den-worker-proxy	Ready	Preview	Aug 5, 2026 10:16am
openwork-diagnostics	Ready	Preview	Aug 5, 2026 10:16am
openwork-landing	Ready	Preview, v0	Aug 5, 2026 10:16am