[OrcaWin]

ELI5

Running ten agents should not give every build and test runner the whole machine. Add pnpm lean <script> to limit each invocation, and remove unnecessary work from normal development builds. Stacked on #29345.

What Changed

• pnpm lean dev --watch, pnpm lean test <file>, pnpm lean tc, and pnpm lean build:electron-vite use two native threads, two test workers, and one typecheck project at a time. Explicit environment and CLI limits remain usable. Vitest limits apply to its child projects too; the isolated measurement suite stays at one worker.
• Skip main-process minification during development, retaining source maps and production minification. Stop calculating gzip sizes just for build logs.
• Keep desktop and web dependency caches separate inside each worktree, preventing shared node_modules installs from repeatedly invalidating other worktrees' caches. Exclude these caches from packaging.
• Honor explicit Node heap limits instead of overwriting them with the build default. Document targeted commands and the existing escape hatch for unnecessary pairing-client preparation.

Why

Normal commands retain their existing concurrency. A portable opt-in command lets busy machines trade a little individual build latency for lower contention without reducing test coverage or changing production bundling. Reuse the existing process host, compiler scheduler, Vite behavior, and test configuration rather than adding another build system or cache-validity mechanism.

Three alternating desktop bundle runs on this 24-thread Linux host, Node 24.22.0 and pnpm 12.8.1 (medians; warm filesystem):

	Before	Lean
Elapsed time	8.63 s	9.61 s
CPU time	35.68 s	30.52 s
Peak process RSS	5.18 GiB	4.69 GiB

That is about 14% less CPU time and 10% less peak memory for a roughly one-second latency cost. This is a local resource measurement, not a universal speedup claim. Development-main measurements did not show a reliable elapsed-time improvement. The benchmark used Python wait4 resource accounting; the before configuration enabled the previous gzip reporting, and lean used the final command.

Linked Issue

Maintainer-requested development performance work; builds on #29345.

Visual Proof

N/A — development tooling and build reporting changes, with no intended application UI change.

Testing

With ORCA_BACKGROUND_LAUNCH=1, Node 24.22.0, pnpm 12.8.1, and Bun 1.4.3 on Linux:

• Full pnpm lean tc passes.

• 112 focused tests pass, three existing skips: resolved development/production configuration, public entry exports, packaging exclusions, command forwarding, resource limits, compiler scheduling, and fake dev-launcher teardown.

• 34 focused tests also pass under Node through pnpm lean test:node.

• Desktop and standalone web bundles pass their output checks. Desktop production builds exercised both normal and lean modes.

• Changed-code quality, formatting, whitespace checks, and precommit hooks pass.

• macOS and Windows execution, the full test suite, and complete native/mobile packaging remain for CI. No visible Electron app was launched.

• I manually tested these changes locally

• Automated tests added/updated, or explained why not below

Review

The command uses the existing cross-platform process host and forwards cancellation. No application RPC, SSH execution, agent status, provider, credential, or integration behavior changes. Caches are worktree-local and packaging-excluded. Limits are per invocation rather than a machine-wide reservation; descendant programs inherit the selected environment limits. UI review is not applicable.

Agent skill upstream boundary

• Not applicable, or this change copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

TypeScript already uses its native compiler, and React already uses Oxc in the parent PR. No compiler replacement or persistent Vitest transform cache is introduced. Full native and mobile builds were not run locally.

Checklist

• This PR is small and focused
• I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
• Before/after screenshots or videos attached for UI changes, or N/A with reason
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
• pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)