Parallel-worktree Playwright runs silently serve another worktree's source

[BorisTyshkevich]

What

Parallel Playwright runs in different git worktrees of this repo silently serve each other's files, producing failures that have nothing to do with the branch under test.

playwright.config.js sets reuseExistingServer: !process.env.CI and the webServer binds a fixed default port. Every worktree uses the same config, so the second worktree to start a run finds the port already bound, skips launching its own build/e2e-serve.mjs, and attaches to the first worktree's server — which raw-serves that worktree's /src and tests/e2e. The specs then run against another branch's source with no warning.

How it showed up

During a multi-worktree /ship run (PRs #554–#558), three separate workers reported e2e failures in tests/e2e/tile-open-workbench.spec.js — one reported 4 failures, another 2, on branches that touch nothing related. One worker "confirmed" them as pre-existing by git stash-ing its own changes, which of course changed nothing, because its own files were never being served. CI was green on main and on all five branches the whole time.

Cost: a wrong conclusion that main had failing e2e specs, plus wasted diagnosis on all three workers.

Suggested fix

Make the harness worktree-safe rather than relying on discipline:

• derive the webServer port per checkout (hash the repo root path, or read an env var the npm script sets) so concurrent worktrees cannot collide; and/or
• set reuseExistingServer: false so a run always owns its own server; and/or
• have build/e2e-serve.mjs refuse to be reused by a different checkout — e.g. serve a /__root probe returning its own absolute repo path, and let the config assert it matches before any spec runs. The assertion is the valuable part: it converts a silent wrong-source run into an immediate, legible failure.

A related smaller footgun in the same class: two vitest runs in one worktree clobber each other's coverage/.tmp and report phantom test failures with an unrelated ENOENT … coverage-*.json rejection. Worth at least a note in docs/DEVELOPMENT.md.

Why deferred

Test-infrastructure defect found while shipping unrelated bug/low issues; not in scope for any of them.