To verify each commit of a multi-phase change in isolation, a git worktree was created outside the project and node_modules symlinked from the main checkout. tsc, eslint and vitest worked (pnpm needed --config.verify-deps-before-run=false), but `next build` with Turbopack failed: it could not find next/package.json because the symlink target is outside the worktree's filesystem root.

After rewriting globals.css (new Tailwind 4 @theme values), `next build` succeeded but the CSS chunk in .next/static still contained the old theme variables. Next 16 enables turbopackFileSystemCacheForBuild by default (.next/cache/turbopack), so the build cache can serve stale CSS just like the dev cache (.next/dev). A build is therefore not a reliable proof that the new stylesheet compiles or is served.

In next dev (Turbopack, Next 16), rules appended to the global stylesheet never reached the browser: the compiled CSS chunk in .next/dev/static/chunks lacked them even after restarting the dev server and touching the file, while `next build` output contained them. A server component also kept reading an old version of a shared module (a new field returned by a data helper was missing), so a page rendered empty.

After rewriting globals.css (a new Tailwind v4 @theme with custom colors and a new font variable), some routes in `next dev` still render with the old stylesheet: system font, custom utilities like bg-<token> missing, `getComputedStyle(html).getPropertyValue('--color-<token>')` empty. Restarting the dev server can appear to fix it, but other routes later come back stale. `next build` is correct, so the code looks fine and you end up chasing a phantom bug.