Blazor Rendering and Routes

Requirement A page MUST render without server-side execution at first paint.

Rationale Interactive server rendering, automatic render mode, and prerendering each require a live server connection, so all three are outside this stack.

Requirement A routable component MUST live under Pages/, declare one @page template, and type every route parameter.

Rationale Feature components stay unroutable. An unparsable parameter renders the not-found state rather than throwing.

Requirement A route MUST define its loading, empty, error, forbidden, not-found, and ready behavior.

Rationale A route reading persisted state renders its loading state until the read completes, so it never shows an unloaded store as ready. All six apply to a client-rendered route: an unparsable parameter renders not-found, and a route the actor is not allowed to read renders forbidden. Each state name is a term in the project's language record. This realizes litespec/frontend/rendering#represent-route-states.

Requirement A marketing, search-landing, or informational page MUST be served as a static document outside the WebAssembly application.

Rationale A first-time visitor then downloads no runtime. The application boundary begins where a visitor starts using the product.

Requirement A client MUST register a service worker that caches the application shell and framework payload.

Rationale The application then starts and navigates with no network. A feature that cannot work offline states that in its use-case specification and degrades to an explicit offline state.

The rule covers the online case as much as the offline one. A cached shell serves the version it cached, so a visitor who never goes offline still receives yesterday's payload until the worker updates. The worker therefore declares its update strategy and what a visitor sees while a new version installs.