Browser Lanes
The browser acceptance lanes for hosts, development servers, sites, demos, and static output.
One lane, one port
Every browser lane owns one machine-global port and one server. Stop other lanes before starting one; an occupied port is a failed precondition, not a reason to let the server silently select another port. The lane scripts and Playwright configs are the executable source of truth:
| Lane | Command | Port | Config | What it proves |
|---|---|---|---|---|
| Host | corepack pnpm test:browser:host | 4173 | playwright.host.config.ts | Runs zudo-composer dev through the package's installed-bin shape against a disposable host, after activating the Sample Studio project, and exercises the tests/browser authoring proof (excluding the SiteProject spec). |
| Development | corepack pnpm test:browser:dev | 5173 | playwright.dev.config.ts | Runs this repository's own pnpm dev with disposable release, Assets, Composition, and CMS roots and exercises tests/browser-dev. |
| SiteProject | corepack pnpm test:browser:site-project | 4174 | playwright.site-project.config.ts | Verifies the Sample Studio static artifact and frozen route parity, activates the committed project into isolated roots, and crawls site-project-acceptance.pw.ts against the repository Vite app. |
| Hosted demo | corepack pnpm test:browser:hosted-demo | 4175 | playwright.hosted-demo.config.ts | Serves the already-built dist-hosted-demo artifact, then checks the hosted-demo routes and asset/runtime behavior as a static site. |
| Demos | corepack pnpm test:browser:demos | 4176 | playwright.demos.config.ts | Visits each of demo-webshop, demo-landing, and demo-blog in turn through its installed host dev server, crawls every verified static route, and performs the demo's one mock interaction. |
The packed-host smoke proof also owns port 4175, so it cannot overlap the hosted-demo lane. The reserved set is therefore 4173, 4174, 4175, 4176, and 5173. The demo packages' interactive one-off servers use 4181 (Webshop), 4182 (Landing), 4183 (Blog), and 4184 (Sample Studio); those are not browser-lane ports.
Preparation and artifact rules
The SiteProject and demos lanes consume artifacts prepared before the browser run:
corepack pnpm demo:build-sites
corepack pnpm test:browser:site-project
corepack pnpm test:browser:demosThe hosted-demo lane consumes the corresponding static artifact:
corepack pnpm build:hosted-demo
corepack pnpm hosted-demo:verify dist-hosted-demo
corepack pnpm test:browser:hosted-demoPreparation builds and verifies; browser lanes only read the verified bytes and never rebuild them. Before using a route, the SiteProject and demo runners check the artifact manifest, file checksums, source/tool identity, Assets, and sitemap route parity. A stale or missing artifact fails with the preparation instruction rather than falling back to a newly generated route list. The hosted-demo runner likewise requires dist- before it starts its static server.
What each proof isolates
The host lane creates a fresh host under the OS temporary directory, links the package as a host dependency, runs the installed seed command, and removes the tree afterward. This proves the installed-host boundary rather than a Vite preview of the checkout. The development lane gives each spec file a fresh set of disposable filesystem roots so one spec's writes cannot leak into the next invocation.
The SiteProject lane reads packages/ through its verified-manifest helper, compares the authoring routes with Studio's frozen production route data, and seeds a release in temporary roots. The demos lane copies each committed cms/ tree into a temporary host-local directory, seeds a separate release root, starts one demo at a time on 4176, and checks every route from that host's verified site-manifest.json. It never authors into a committed CMS tree.
Both host and development configs route specs by filename. *.coarse.pw.ts runs only in the touch-capable 390x844 coarse project, while *.responsive.pw.ts runs in both coarse and desktop projects. The coarse-only rules are disabled on a fine pointer, so the suffix is part of the proof and not just a label. Traces, screenshots, and videos are retained on failure in the ignored test-results/ tree.
For the assertions behind the lanes, see the workspace acceptance operator guide and the static-site build section.