* perf(rpc): compile Zod request schemas lazily
* chore(deps): pin zod 4.5.4 and except it from the release-age gate
4.5.4 is the first release fixing isRecursiveSchema (upstream 84e416f, #6500),
which compile() calls on every schema — on 4.5.0 it fired .default() factories
at compile time. Verified: compile-time factory calls 0 on 4.5.4, 1 on 4.5.0.
Generalizes the @linear/sdk-scoped prune to every packaged dependency,
matching the existing type-declaration prune's single-predicate walk over
Resources/node_modules. Recovers ~1.01 MB beyond the SDK.
Nothing in the packaged app enables Node source-map support
(no --enable-source-maps, no setSourceMapsEnabled, no source-map-support
require), and the CLI launchers strip NODE_OPTIONS, so these maps were
never read. Orca's own main-process maps live outside node_modules and
already ship as a separate release artifact.
`serializes FETCH_HEAD callers before they enter admission` assumed that two
same-repo fetches join the FETCH_HEAD lock lane in call order. They do not.
`runWithGitFetchHeadLock` first `await`s `fetchLockPath`, which walks the
filesystem (`realpath`, `stat` per parent directory, `readFile` of `commondir`,
`realpath` again) before it calls `runWithGitOperationLock`, and the lane is
registered only after that walk resolves. For a non-existent `/repo` that is
five libuv threadpool round-trips per caller. Two callers issued back to back
run their chains concurrently, so lane order is threadpool completion order,
not call order.
When the `interactive` fetch won that race it entered the lane ahead of the
`background` fetch. On the first caller's release it reached admission
immediately and, being interactive, took the free network headroom slot instead
of queueing, while the background fetch stayed parked on the lock. `queued`
therefore settled at 0 and never reached the asserted 1. Measured inversion
rate for the bare lock-path walk was 54/500 on an idle machine; the test itself
failed 5/20 locally, always at the same assertion, matching the two CI failures
on unrelated PRs (#17530, #17630) at the same line.
Fix the premise rather than the symptom: stub only the key derivation, keeping
the real FIFO `runWithGitOperationLock` that the test actually exercises, so the
lane is registered synchronously with the call. Key derivation keeps its own
coverage in `src/shared/git-fetch-head-lock.test.ts`. This also stops the fetch
tests in this file from sharing one global `/.git/FETCH_HEAD` lane with each
other and from touching the real filesystem.
Verified deterministic: 40/40, then 30/30 clean runs, plus 25/25 with twelve CPU
hogs and a concurrent `src/main/git/command-runner/` run saturating the box.
* perf(wsl): warn at project-add when the tree sits on a Windows drive
Worktree placement now puts new workspaces inside the distro, but a project
whose own tree is on C:\ still pays the 9p/drvfs crossing on every git command
it runs — measured at ~20x for a clean `git status` against the same tree on
ext4. Nothing in the UI says so, so the project just feels slow.
Warn once, right after the add succeeds, naming the distro the project's git
actually runs in. The advisory is wrapped so it can never fail the add.
Two path shapes cross the boundary and both warn: a Windows drive path under a
WSL project runtime, and the UNC spelling of a distro's own drvfs mount
(\\wsl.localhost\Ubuntu\mnt\c\...), which crosses it however the runtime is set.
A tree already inside the distro, a drive path under Windows-host git, a plain
UNC share, and every POSIX/SSH path stay silent.
* chore(i18n): register the WSL filesystem boundary advisory keys in en.json
* ci(release): publish main-process source maps with each release
Desktop bundles ship minified, and packaging drops out/**/*.map from
app.asar, so a stack trace from a released build cannot be mapped back to
source. main builds with sourcemap:'hidden' — the maps exist in CI but were
never published anywhere.
Zip them on the linux-x64 leg and upload to the draft release as
orca-sourcemaps-<tag>.zip (33.7MB raw, ~8MB zipped, 69 files). The main
bundle is platform-independent, so one leg covers the whole release. The
step fails loudly if no maps are found, so a regression of build.sourcemap
breaks the release instead of silently shipping undecodable builds.
* fix(release): stage source map bundle outside the checkout
Every entry in electron-builder's `files` is a negation, so app-builder hits
containsOnlyIgnore() and prepends `**/*` (fileMatcher.js:285). A zip left in
the workspace root would have been packed into the linux-x64 app.asar,
growing that platform's installers by ~8MB and diverging them from arm64 —
the same hazard the '!pr-evidence' exclusion already guards against.
Stage it in $RUNNER_TEMP, matching the release-state file at :444.
* perf(build): minify desktop JavaScript bundles
* perf(build): minify with rolldown's oxc and emit hidden main source maps
'esbuild' made rolldown disable its own minifier and re-print every chunk
through esbuild, which is not a declared dependency and resolves only via
pnpm's shamefullyHoist from electron-vite's tree (0.25.12 against a declared
peer of ^0.27.0). Switching to rolldown's in-process 'oxc' minifier drops
that second pass: main+renderer build falls 23.2s -> 11.9s and ships ~2.7MB
less JavaScript.
keepNames is dropped with it — it cost ~1.5MB and only recovered function
names. main now builds with sourcemap:'hidden', which restores names *and*
locations without emitting a sourceMappingURL. Packaging excludes
out/**/*.map so app.asar is unaffected; release CI publishes the maps.
Track scroll-restore generation to invalidate stale callbacks that were
resetting the scroll position to 0 when reopening a detail page. Prevent
restoration while a detail page is open.
Update automation test to use runtime.call RPC instead of removed preload
CRUD method. Hide browser import hint in E2E profile to prevent overlay from
intercepting test setup clicks.