fix: scaffolded-project path assumptions (#283, #284, #287, #288, #290)

[antosubash]

Fixes #283, fixes #284, fixes #287, fixes #288, fixes #290.

Five reports filed against a sm new project scaffold, all one root cause: the framework assumed its own monorepo layout, where a module's directory and assembly are both SimpleModule.<Module>. sm new module scaffolds a bare <Module> for both.

#287 — page bundle 404 on every page load

The client built the bundle URL as _content/SimpleModule.<Module>/…, but an RCL serves its assets under its AssemblyName, so every scaffolded module 404'd before the fallback probe found it.

HtmlFileInertiaPageRenderer now declares the module-name → assembly-name mapping in the page shell, and resolvePage reads it, so the first request goes to the path that actually serves the bundle. Probing stays as a fallback for shells that predate the map, and for an unparseable one.

The same prefix assumption also meant a bare-named module's stylesheet was never linked — BuildModuleCssLinks only matched _content/SimpleModule.*. Module CSS discovery now consults the same mapping.

#283 / #284 — types.ts written into a directory no project owns

extract-ts-types.mjs hardcoded SimpleModule.<Module> as the output project and mkdirSync'd it unconditionally. It now resolves the project directory that actually exists and skips modules with no local source, so:

• a scaffolded module gets its types next to the Pages/ that import them (extract-ts-types.mjs writes types.ts into a SimpleModule.<Module> directory that sm new module never creates #284)
• NuGet-installed modules no longer materialise phantom source trees in a consumer's repo (extract-ts-types.mjs writes types.ts for NuGet-installed modules into the consumer's source tree #283)
• deleting a module no longer resurrects its directory on the next generate:types

Also removes two committed artifacts of the old behaviour — modules/Identity/src/SimpleModule.Identity/ and modules/Core/src/SimpleModule.Core/ — each holding only a generated types.ts and belonging to no project.

#288 — Tailwind never recompiled for new pages

Styles/app.css declares its scan roots as @source directives, but TailwindBuild did not treat them as inputs, so a new page's utility classes were silently never generated. All five declared roots are now inputs: module Pages//Views/, the host ClientApp, the @simplemodule/ui and @simplemodule/client packages, and the staged module bundles — with @(TailwindExtraSourceFiles) as an extension point for hosts that add @source directives of their own.

template/SimpleModule.Host/wwwroot/css/app.css is no longer tracked. .gitignore's "Tailwind CSS build output" rule already excluded it (allowlisting only favicon.svg, index.html, error.html); it had been force-added. With the input set widened, the target now reruns on nearly every frontend edit, so the stale committed copy was being rewritten constantly and produced a ~5,000-line spurious diff on every build. CI and Docker each compile the CSS themselves and the Host is IsPackable=false, so nothing depended on it.

#290 — scaffolded hosts never scanned packaged modules' bundles

HostTemplates.AppCss() stripped the @source "./_scan/" line, so a scaffolded host staged every packaged module's built .pages.js into Styles/_scan/ and then never scanned it — utility classes appearing only in a packaged module rendered unstyled. The path is relative to Styles/, so the same line is correct in both layouts.

This was originally deferred out of a concern that Tailwind would fail on a missing directory in a fresh scaffold. It does not — v4 skips absent @source roots without error (verified directly), and CollectModuleAssets creates the folder before TailwindBuild runs regardless. The monorepo-only docs/design-system root is now stripped instead, since a scaffold has no such directory.

Verification

• Tailwind build does not re-run when module Pages change, so new utility classes silently never compile #288 — reproduced on unmodified main: added bg-lime-700 to a module page, rebuilt, class absent from app.css. With the fix, bg-fuchsia-800 compiles in.
• extract-ts-types.mjs writes types.ts for NuGet-installed modules into the consumer's source tree #283/extract-ts-types.mjs writes types.ts into a SimpleModule.<Module> directory that sm new module never creates #284 — ran the script against a fixture with all three shapes: src/<Name> (scaffold), src/SimpleModule.<Name> (framework), and a module with no source. Writes into the first two, skips and creates nothing for the third. Re-running against this repo produces zero changes to any existing types.ts.
• Page bundle requested as _content/SimpleModule.<Module>/ but the RCL serves it at _content/<Module>/ — 404 on every page load #287 — against a running host, every route fetches exactly one bundle at its declared assembly name (HTTP 200) on both full page loads and client-side SPA navigation, with zero failed requests and zero console errors. A fabricated assembly name still 404s, so those 200s are meaningful.
• Scaffolded host strips @source "./_scan/", so packaged modules' Tailwind classes are never compiled #290 — HostTemplatesAppCssTests fails when the strip is restored and passes without it.

Tests added

• InertiaEndpoint_DeclaresAssemblyNameThatServesEachModuleBundle — asserts every module with pages is declared and every declared value is a real loaded assembly.
• tests/e2e/tests/smoke/module-bundles.spec.ts — end-to-end: for each module route the shell must declare an assembly for that page's module and the browser must fetch exactly that bundle, once, with a 200. Expectations are derived from the shell's own Inertia component name and assembly map rather than a hardcoded route table. Confirmed it fails (5/5 route cases) when the map is emptied. Also asserts Tailwind utilities survive compilation, with an unused control class proving the check discriminates.
• HostTemplatesAppCssTests — guards the retained _scan source and the scaffold path rewrites. SimpleModule.Cli.Tests sets IsTestProject=false, so dotnet test skipped it entirely and these would have guarded nothing; the build job now runs that class explicitly.

Local CI

Lint/format, validate-pages, validate:i18n, framework-scope, typecheck 15/15, dotnet build 0 warnings / 0 errors under TreatWarningsAsErrors, full suite green (20 assemblies, 1,309 tests, 0 failures), CLI template tests 4/4, e2e smoke suite 72/72.

Out of scope

Review surfaced issues in code already on main that this PR does not touch, left alone deliberately rather than bundled into a path-fix change:

• Default admin credentials reachable in Production. auth.show_test_accounts has DefaultValue = "true" with no environment gate and LoginEndpoint falls back to it, while Login.tsx hardcodes admin@simplemodule.dev / Admin123! and the seeder now always applies that default (fix: shutdown-noise in background services + seed defaults so the app starts out of the box #279). A Production container with no seed config renders a working "Login as Admin" button. Fixing it reverses part of the deliberate out-of-box decision, so it needs its own change.
• ProgressFlushService re-reads moduleOptions.Value in the shutdown drain instead of the captured opts.
• IsLocalOrTest's doc comment still describes fail-closed guards that now only warn.

[antosubash]

Addressed the review in 10bc18b. Four of six findings fixed; two declined with reasons.

Fixed

• Untracked @source roots — correct, and the more serious of the two Tailwind findings. app.css declares five roots; I had tracked two. Editing packages/SimpleModule.UI left the CSS stale with exactly the Tailwind build does not re-run when module Pages change, so new utility classes silently never compile #288 symptom, in the repo's most-edited shared code. Added the UI and client package roots via new SimpleModuleUiDir/SimpleModuleClientDir properties (npm packages in a scaffold, packages/ in the monorepo), and wired docs/design-system/ through @(TailwindExtraSourceFiles) — which also exercises the extension point.
• _scan glob evaluated too early — correct. Moved the item declaration into CollectModuleAssets, after the Copy. Verified by deleting Styles/_scan/ and rebuilding: TailwindBuild runs in that same build (zero Skipping target "TailwindBuild") and the bundles are re-staged, rather than being missed until a second build.
• Unanchored glob walking bin//obj/ — correct. Anchored to */src/*/Pages/**, which matches both the framework layout and sm new module's. Confirmed module pages are still tracked.
• Fallback probe burying the real error — correct. resolvePage now reports the declared candidate's error instead of the last probe's. Checked all four cases; with {"Invoicing":"Invoicing"} declared, a failure now reports the error from _content/Invoicing/ rather than the 404 from the SimpleModule.Invoicing fallback.

Declined

• Duplicate [Module] name last-write-wins — unreachable. SM0040 is a generator diagnostic with DiagnosticSeverity.Error, so two modules sharing a name fail the build. A runtime throw or warning would be dead code.
• Scaffold strips @source "./_scan/" — a real bug, and the review is right that it is the reason those staged files go unscanned in a scaffold. It is a CLI template change with its own failure mode (a fresh scaffold has no Styles/_scan/, and Tailwind errors on a missing @source path), so it needs the scaffold to create the directory and wants its own verification against a real sm new project. Filed as Scaffolded host strips @source "./_scan/", so packaged modules' Tailwind classes are never compiled #290 and referenced from the comment on CollectModuleAssets so the staging target cannot be misread as covering packaged modules everywhere.

One correction to my own verification. My first attempt to reproduce the untracked-UI-root gap reported a false pass — a leftover mtime from a previous probe, then incidental input churn that reruns Tailwind on many builds in this repo. A clean before/after via timestamps is not reliable here. The finding is settled by inspection instead (none of the committed globs cover packages/SimpleModule.UI), plus MSBuild's own Skipping target "TailwindBuild" after touching that file on the pre-fix tree. After the fix, all five roots report tracked.

Full suite green (20 assemblies, 0 failures), npm run check clean, dotnet build 0 warnings.