the browser reads the shell before the shell can explain itself

A single-page application served from several mount points has an ordering problem that never appears in development. The shell needs to know which mount it is under before it can resolve a relative asset reference, and the usual answer is to supply that knowledge at runtime: a small script that sets the base before anything else loads.

That answer works for everything except the browser itself. The speculative preload scanner reads the document before a runtime-injected base exists, resolves relative asset paths against the document's own address, and on a nested route requests a script path that returns the application shell instead. The module then dies on an incompatible content type and the page is blank. Worse, a service worker controlled the revisit path, so the second visit worked — which is why the defect survived so long.

The fix removed the disagreement rather than racing it: the generated shell now contains no static asset references at all. One inline bootstrap sets the base for whichever of three mounts it is under, then creates the stylesheet, the manifest link and the module script dynamically, because elements inserted after the base exists resolve against it. There is nothing static left for the scanner to mis-fetch.

The same pattern was then applied to the second application with a multi-mount shape, where an absolute asset prefix was impossible for exactly that reason.

Cost: a generated shell and a post-build step that must stay idempotent and run in every build mode, including the ones used only for checks.

What it proves: the team fixes ordering problems by removing the race, not by winning it.