Only a build from a clean checkout proves a framework migration will deploy

A dev machine that has run the old framework version still carries its generated files, and those files can make a broken migration look finished.

SvelteKit 2 generated .svelte-kit/tsconfig.json; SvelteKit 3 does not. Replicator's tsconfig.json still extended that generated file. On the dev machine a leftover copy from before the upgrade was still on disk, so bun run build and bun run check stayed green. Vercel builds from a clean checkout, where the file does not exist, and three consecutive pushes failed with Tsconfig not found. The one step that should have complained, svelte-kit sync, ran inside prepare: svelte-kit sync || echo '', which swallowed its failure.

The fix pointed extends at the package-provided $app/tsconfig base and declared the path aliases directly in tsconfig.json. A test (tests/tsconfigAliases.test.ts) now checks that alias list against vite.config.ts so the two cannot drift.

The general rule: when a migration changes what a framework generates, verify it from a genuinely clean checkout. A machine with pre-migration artifacts on disk is testing a project that no longer exists anywhere else.

Receipt: Replicator v3.287.1, after v3.285.0 through v3.287.0 failed to deploy (FINDINGS.md, "SvelteKit 3").