Fix Windows test failures and restore workspace: protocol in manifests

[Tahshsa]

Summary

Hi! First-time contributor here. I was trying out InkOS on Windows and found the test suite was red (43 failed / 32 passed from a clean clone + build). Digging in, there were three independent bugs — two Windows-portability issues in the tests and one real latent bug in the committed package manifests that would have affected the next release regardless of platform.

After the fixes: 79 passed / 0 failed on Windows, typecheck clean across all three packages.

1. Windows path-separator bugs in tests (6 failures)

studio.test.ts, studio-runtime.test.ts, and daemon.test.ts hard-coded POSIX paths in their assertions and mock implementations:

```ts
if (path === "/project/packages/studio/src/api/index.ts") { return; }
```

But the production code (resolveStudioLaunch, upCommand) uses path.join, which on Windows produces \project\packages\studio\src\api\index.ts. The accessMock string comparison never matched, firstAccessiblePath returned undefined, and the command bailed with process.exit(1) — surfacing as the confusing "process.exit unexpectedly called with 1" error.

Fix: build expected paths with path.join so they match whichever separator the host OS uses. No production code changes — the production code is correct; it should use OS-native separators because those paths are passed to fs.access and spawn.

2. execFileSync(\"npm\", ...) ENOENT on Windows (2 failures)

publish-package.test.ts shells out to npm pack, but on Windows npm ships as npm.cmd and execFileSync without a shell can't launch .cmd files. Switched to npm.cmd + shell: true when process.platform === \"win32\".

3. Committed manifests had prepack-normalized dependencies (1 failure, all platforms)

This one's the real find. packages/cli/package.json and packages/studio/package.json were committed with concrete versions for their workspace siblings:

```json
"@actalk/inkos-core": "1.1.1",
"@actalk/inkos-studio": "1.1.1"
```

instead of the expected \"workspace:*\". The test publish-package.test.ts > keeps source CLI dependencies linked through the workspace protocol was correctly flagging this, but it was failing on every platform — Linux CI just didn't surface it because the rest of the test file couldn't get past the Windows-pack issue... actually it's easier than that: the test was silently red on main. Worth double-checking whether your CI was gating on it.

The practical impact: the next npm publish from that state would have pinned siblings to 1.1.1, so if you'd cut a 1.1.2 release the published @actalk/inkos@1.1.2 would have pulled in @actalk/inkos-core@1.1.1 from the registry instead of the matching 1.1.2 sibling. Bumpy release.

Most likely cause: a publish where the postpack restore script didn't run (Ctrl-C, pnpm skipping lifecycle hooks, etc.), leaving the dirty state committed. FYI pnpm publish has a native workspace:* → concrete transform built in, so you could drop the prepack/postpack script pair entirely if you wanted fewer moving parts.

Fix: restored \"workspace:*\" in both manifests.

Test plan

• pnpm install && pnpm build && pnpm test — 79 passed / 0 failed on Windows 11, Node 22
• pnpm typecheck — clean across core, cli, studio
• Linux CI (will run when this PR opens)
• A Windows CI job to prevent regression — I have a one-line ci.yml change ready for a follow-up PR (needed a separate token scope to push workflow files from my fork; happy to either open that as a second PR or add it here if you'd like to push directly to this branch)

Thanks for the project — excited to try writing a novel with it once this lands!

🤖 Generated with Claude Code