Svelte 5 Runes SSR Boundary and Cross-Request Memory Isolation Guardrail

--- description: Svelte 5 Runes SSR Boundary and Cross-Request Memory Isolation Guardrail - Mandates deterministic request isolation in Svelte 5 applications by strictly forbidding module-scoped mutable rune state in SSR runtime environments. Enforces per-request context providers and factory-instantiated state boundaries to eliminate cross-request state pollution and race conditions during high-concurrency Node.js and Bun SSR hydration. globs: src/**/*.{svelte,svelte.ts,svelte.js,ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-runes-ssr-boundary-isolation-standard" --- # Svelte 5 Runes SSR Boundary and Cross-Request Memory Isolation Guardrail > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Module-Level $state() Singletons Leaking User Sessions Across Concurrent SSR Requests ## System Constraints You are a Principal Engineer enforcing the Svelte 5 Runes Reactive Boundary and Cross-Context Mutation Isolation Standard. Mandate absolute memory isolation for server-side rendered Svelte 5 applications. Prohibit module-level shared mutable runes, enforce strict context boundaries, and guarantee zero cross-request data bleed in Node.js and Bun runtimes. ## Strict Guidelines - Engineers MUST NOT declare or export module-level mutable runes (`$state`, `$state.raw`) in universal modules (`.ts`, `.svelte.ts`) or component module scripts. - Engineers MUST ALWAYS instantiate reactive state objects within component lifecycles or request-scoped boundaries using `setContext` and `getContext` with unique `Symbol` keys. - State classes utilizing runes MUST be exposed via factory functions or constructors invoked inside component setup, never as pre-instantiated global singletons. - Components NEVER execute state-mutating operations or global variable assignments inside SSR execution paths (`$derived` getters or initial script evaluation). - Engineers MUST encapsulate shared mutable server data within SvelteKit `event.locals` or request-bound contexts, passing snapshots to the client via root layout data loaders. ## Bad vs Good Implementations ### Cross-Request State Isolation in Svelte 5 `.svelte.ts` Module #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Declaring mutable rune state at the module root creates a global singleton across the server process. Under concurrent SSR requests in Node.js or Bun, User B's request will read or mutate User A's profile data, causing catastrophic data leaks and hydration mismatch errors. ```typescript // src/lib/stores/auth.svelte.ts // ANTI-PATTERN: Module-level rune singleton leaks state across concurrent SSR requests interface UserProfile { id: string; name: string; roles: string[]; } // Module-level $state creates a single shared instance in the Node.js/Bun process export const authState = $state({ user: null as UserProfile | null, isAuthenticated: false }); export function setUser(user: UserProfile) { authState.user = user; authState.isAuthenticated = true; } ``` #### Production Standard (Correct) > **Standard**: Encapsulating the `$state` rune within a class instantiated per-component via `setContext` guarantees strict lexical and request-scoped isolation. Each incoming SSR request constructs an isolated instance bound only to its render tree, preventing server memory leaks and cross-tenant pollution. ```typescript // src/lib/stores/auth.svelte.ts import { getContext, setContext } from 'svelte'; interface UserProfile { id: string; name: string; roles: string[]; } const AUTH_KEY = Symbol('AUTH_STATE'); export class AuthStore { user = $state<UserProfile | null>(null); isAuthenticated = $derived(this.user !== null); constructor(initialUser: UserProfile | null = null) { this.user = initialUser; } setUser(user: UserProfile) { this.user = user; } logout() { this.user = null; } } export function initAuthContext(initialUser: UserProfile | null = null): AuthStore { const store = new AuthStore(initialUser); setContext(AUTH_KEY, store); return store; } export function getAuthContext(): AuthStore { const store = getContext<AuthStore>(AUTH_KEY); if (!store) { throw new Error('AuthContext must be consumed within a valid component tree with initAuthContext()'); } return store; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes SSR Boundary and Cross-Request Memory Isolation Guardrail

Svelte 5 Runes SSR Boundary and Cross-Request Memory Isolation Guardrail defines an industrial-grade behavioral standard for frontend engineering. Mandates deterministic request isolation in Svelte 5 applications by strictly forbidding module-scoped mutable rune state in SSR runtime environments. Enforces per-request context providers and factory-instantiated state boundaries to eliminate cross-request state pollution and race conditions during high-concurrency Node.js and Bun SSR hydration. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Module-Level $state() Singletons Leaking User Sessions Across Concurrent SSR Requests Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Module-Level $state() Singletons Leaking User Sessions Across Concurrent SSR Requests	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST NOT declare or export module-level mutable runes (`$state`, `$state.raw`) in universal modules (`.ts`, `.svelte.ts`) or component module scripts.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.