CI note: the only red job is test integration (1/2) debug windows-aarch64, which failed in integration::watcher::serve_watch_parallel_stops_old_workers with Output did not contain "..." after 60 seconds (watcher_tests.rs:116). That's a deno serve --watch output-timing flake on the slow Windows-aarch64 emulated runner — unrelated to this PR, which only touches cli/tools/framework.rs and adds a tests/specs/compile/framework_detection/vite_spa spec.

Everything that actually exercises this change is green on every platform: all test specs shards (the new vite_spa spec runs here), all test unit (the framework unit test), and all lint/lint title. Re-triggering CI to clear the flaky shard.

One gap worth closing: unlike vite_ssr, the new vite_spa test stops at compiling the binary — it never executes it. I understand why (the generated SPA entrypoint blocks on Deno.serve, and serveDir is stubbed out, so there's nothing to assert and no way for a spec step to terminate), but that means the runtime half of the path — the binary actually booting and loading the generated entrypoint + remapped import out of the embedded VFS — is still uncovered, and that's exactly the layer where compile bugs have historically shown up.

There's a cheap way to get that coverage with the existing stub: since _file_server.ts is imported by the generated entrypoint at startup, its module top-level runs before Deno.serve is ever reached. Something like:

// _file_server.ts
console.log("file-server stub loaded");
if (Deno.env.get("EXIT_ON_LOAD")) Deno.exit(0);

export function serveDir(_req: Request): Promise<Response> {
  return Promise.resolve(new Response(null, { status: 404 }));
}

plus a second step per platform mirroring vite_ssr ("commandName": "./main", env EXIT_ON_LOAD: "1", asserting the stub's output). That verifies the compiled binary starts, resolves the import-map-remapped specifier from the VFS, and reaches the entrypoint — without hanging the harness.

Not a blocker, but since this test's whole purpose is end-to-end coverage of the SPA path, running the artifact it produces seems worth the extra step.

Good call — done in 8fc2c65. The stub now logs file-server stub loaded at module top level and Deno.exit(0)s when EXIT_ON_LOAD is set (it's imported by the generated entrypoint before that entrypoint reaches Deno.serve, so it runs at startup). Added a run step per platform mirroring vite_ssr — commandName: ./main, envs: { EXIT_ON_LOAD: "1" }, asserting main.out.

That gives the runtime coverage you described: the compiled binary boots, resolves the import-map-remapped @std/http specifier out of the embedded VFS, and reaches the generated entrypoint — without hanging the harness on a live server.

Verified locally: cargo test --test specs -- framework_detection → 5 passed (both steps of vite_spa plus vite_ssr, no regression).