fix(dev): the dev launch survives cmd.exe, and stages the sidecar it declares

[Amir-SSVLabs]

Two things stood between a Windows checkout and a running app. Both are in the launch path, neither is in the app.

1. dev:app did not survive cmd.exe

The script was a line of shell:

sh -c 'set -a; BRAINS_ENABLE_APPS=$(node scripts/dev/installed-apps.mjs); [ -f .env ] && . ./.env; set +a; tauri dev --config src-tauri/tauri.dev.conf.json'

npm hands a script to cmd.exe on Windows, which does not parse those single quotes. The . ./.env fell out of the quoting as a bare command and every Windows dev launch died before a single file compiled:

'.' is not recognized as an internal or external command,
operable program or batch file.

The assembly moves to scripts/dev/app.mjs, in the one language both platforms have. Same three steps, same order, same semantics: scan src/apps/*/app.json into BRAINS_ENABLE_APPS, read .env after it so naming a variable there still wins, launch with the dev config. The CLI is invoked as node …/@tauri-apps/cli/tauri.js rather than through node_modules/.bin, for the reason recall/host.mjs already documents about .cmd shims needing a shell.

2. beforeDevCommand never staged the externalBin it declares

recall:prepare runs from beforeBuildCommand only. But tauri_build::build() hard-fails on a declared externalBin that is not on disk, on dev as much as on build:

resource path `binaries\recall-node-x86_64-pc-windows-msvc.exe` doesn't exist
warning: build failed, waiting for other jobs to finish...

So a fresh checkout could build a release and not run a dev build. The launcher now runs prepare-sidecar.mjs (the real binary when the Recall SDK is installed; skips cleanly when it isn't) and then stub-bundle-artifacts.mjs (a no-op when the real one landed, an empty file otherwise) — the same two steps CI already runs for its own jobs. The prepare step is non-fatal: a flaky S3 download must not be the reason nobody can launch.

This one is not Windows-specific in principle. It is just that everyone on macOS already has a staged sidecar, so nobody hits it.

Verification

Tested on Windows from the cold state — sidecar deleted, npm run dev:app run through npm so it goes via cmd.exe exactly as a fresh checkout would:

Recall sidecar prepared for x86_64-pc-windows-msvc (SDK 2.0.27 @ b79e27c5fa80)

then a running brains.exe. Before this change that state failed twice over, once per bug above.

npm run check 740 files / 0 errors. drive:test and eval:test pass. All five lints green.

Left out on purpose

• scripts/cef-dev.mjs carries its own copy of the same env assembly and spawns node_modules/.bin/tauri, which would break identically on Windows — but it hard-exits on non-darwin, so it is macOS-only by construction. Refactoring a script I cannot run here did not belong in this PR; it is a follow-up.
• scripts/dev/installed-apps.mjs stays: cef-dev.mjs still shells out to it, so it is not orphaned.

🤖 Generated with Claude Code

[nir-ssvlabs]

The port is faithful where it matters: findPacks(root).join(",") is byte-for-byte what installed-apps.mjs printed (it is that CLI's only statement), .env still overlays the scan so naming the variable there still wins, and env is actually threaded to the tauri dev call rather than assembled and dropped. Two things to fix, neither blocking.

🟡 Medium · issue (non-blocking): @Amir-SSVLabs readEnvFile loses shell parity on a trailing comment, which corrupts the value silently. The function claims to read "the KEY=value subset that set -a; . ./.env actually reads", but I ran both against the same file: for INLINE=http://localhost:3000 # local override, the shell sets http://localhost:3000 and this sets http://localhost:3000 # local override. A commented .env line is common enough that someone will hit it, and the app will fail on a garbage value rather than on anything that names the cause. Fix inline. Worth noting the shape of it: the one # branch the function does have (line 57) can never fire — a line starting with # fails the identifier regex before that check runs — so the file has dead comment handling and lacks the live case.

🟡 Medium · issue (non-blocking): scripts/dev/installed-apps.mjs:5 still opens "This is what npm run dev:app sets", which this PR makes false — dev:app now calls findPacks directly and that script's only remaining caller is scripts/cef-dev.mjs:94. You correctly kept the file and correctly updated CLAUDE.md and scripts/dev/README.md; this is the third place the same sentence lived. Suggest: "Print the ids of every INSTALLED app … Used by scripts/cef-dev.mjs; the dev:app launcher calls the same findPacks directly." It matters because the next reader of that header will think editing it changes what dev:app does.

Also, all pre-existing and none of it yours to fix here:

• The red Pixel eval is inherited, not caused. Your #54 (merged 40 min before this run) changed GmailTab.svelte, ChatColumn.svelte and ComposerPills.svelte and re-recorded zero goldens; 5 of 7 surfaces now diverge, worst on gmail-thread (0.389%). ci.yml triggers only on pull_request and push: main, so merging into dev never re-ran it — it went in invisibly and now reddens every PR built on dev. Nothing in this diff can move a pixel. Re-recording the goldens is its own commit, and it unblocks more than this PR.
• README.md:404 points BRAINS_ENABLE_APPS at `scripts/dev/installed-removable apps.mjs` — a path with a space in it that has never existed. Already on dev; now doubly stale since dev:app doesn't use that script at all. One line, cheap to fold in while you're in the neighbourhood.
• No BRNS-DESK- id on the title. About half this repo's recent PRs carry one, so read this as a note rather than a process complaint.

Checked: the old shell line step-by-step against the new launcher (scan → .env overlay → sidecar → tauri dev, plus the new arg pass-through), findPacks vs the CLI it replaces, .env parsing against real sh by execution, both sidecar scripts' env needs, the import.meta.dirname floor (already the pattern in that directory, and engines is >=20 — pre-existing, not introduced here), and the Pixel eval attribution. Not read: cef-dev.mjs's duplicate assembly, which you disclosed as a follow-up.

Merge: ✅ into dev. The red check is #54's golden drift, not this PR — don't hold this on it, and don't let it merge unnoticed either.

[Amir-SSVLabs]

The red Pixel eval is inherited from dev, not from this PR. Leaving the detail here so nobody has to re-derive it.

This branch changes four files — scripts/dev/app.mjs, package.json, CLAUDE.md, scripts/dev/README.md. None of them is frontend, so it cannot move a pixel. What the job reports:

✓ start-menu           0.000% px, RMSE 0.0000
✓ settings             0.000% px, RMSE 0.0000
✗ gmail-inbox          0.015% px, RMSE 0.0038
✗ rail-open            0.015% px, RMSE 0.0038
✗ ws-mention-picker    0.015% px, RMSE 0.0036
✗ aim-armed            0.015% px, RMSE 0.0038
✗ gmail-thread         0.389% px, RMSE 0.0155

Same five surfaces, same numbers, as #54 reported before it merged: 0.015% is the ✕ dismiss control on the deepest scope chip, and gmail-thread's 0.389% is that plus the duplicate grounding pill no longer being drawn — a whole row gone. Both were the intended change. Two surfaces still at 0.000% is the useful part: the baseline isn't broadly stale, it is precisely the five those two changes touched.

Since #54 merged, the goldens in scripts/drive/goldens/ no longer describe dev. Every branch cut from dev now inherits this red check, and each one costs a reviewer the same investigation.

@nir-ssvlabs — could you re-capture on macOS? It can't come from a Windows machine: manifest.json stamps the goldens darwin-arm64 and the job runs on macos-latest, so regenerating here would turn five failing surfaces into seven. I haven't touched them. npm run eval:pixels:update on an arm64 Mac at dev, then the diff is the new baseline.

Everything else on this PR is green: Frontend, Lint resources, Eval (token-less), Rust (macos-latest) and Rust (windows-latest) — the last one being the first clean Windows Rust run on a branch that is actually about Windows.

[sebastian-ssvlabs]

Reviewed-at: cc93cc5