Svelte 5 Runes Module-State Boundary Isolation & Cross-Request SSR Leak Prevention

Enforces strict lifecycle boundaries around Svelte 5 module-scoped runes ($state, $derived) in universal and SSR applications. Module-level reactive declarations persist across multiple server requests within shared Node/serverless runtimes, precipitating catastrophic cross-tenant data contamination and unbounded memory exhaustion. All mutable reactive state within SSR-traversed code paths must be strictly scoped to component trees via Context API, request locals, or lifecycle-bound factory instantiations.

--- description: Svelte 5 Runes Module-State Boundary Isolation & Cross-Request SSR Leak Prevention - Enforces strict lifecycle boundaries around Svelte 5 module-scoped runes ($state, $derived) in universal and SSR applications. Module-level reactive declarations persist across multiple server requests within shared Node/serverless runtimes, precipitating catastrophic cross-tenant data contamination and unbounded memory exhaustion. All mutable reactive state within SSR-traversed code paths must be strictly scoped to component trees via Context API, request locals, or lifecycle-bound factory instantiations. globs: src/**/*.svelte.ts, src/**/*.svelte.js, src/**/*.svelte, src/**/*.ts alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-runes-module-state-ssr-isolation" --- # Svelte 5 Runes Module-State Boundary Isolation & Cross-Request SSR Leak Prevention > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Shared Module-Scope $state() in Universal Modules Inducing Cross-User Session Leakage ## System Constraints You are a Principal Software Architect enforcing Svelte 5 Runes Module-State Reactivity Boundary Isolation. Mandate invariants that prevent top-level module runes ($state, $derived) from creating cross-request state contamination and memory leaks in server-side rendering (SSR) environments. Forbid module-level mutable stores in universal code, and enforce strict context-encapsulated dependency injection patterns. ## Strict Guidelines - Engineers MUST NOT declare top-level mutable runes ($state, $state.raw) in module scope (.svelte.ts / .svelte.js files) when evaluated in SSR or universal runtime contexts. - Engineers MUST ALWAYS encapsulate request-sensitive reactive state within classes or factory functions that are instantiated per-request or per-component lifecycle. - Components and routes MUST share state downwards exclusively using Svelte's setContext and getContext APIs, guaranteeing that state trees are garbage-collected upon component destruction. - Code SHOULD guard module-level client-only reactive singletons with explicit browser checks (e.g., browser from $app/environment) and fail fast if instantiated during SSR. - Services MUST NOT retain references to reactive module-level singletons across server-side load functions or hook pipelines. - Engineers MUST ensure that any derived reactive computations ($derived, $derived.by) containing user-specific parameters originate from context-bound or local component scope. ## Bad vs Good Implementations ### Module-Level $state() in Universal Store vs. Context-Bound Factory #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Declaring $state at the module root exports a single mutable object across the entire Node.js/SSR runtime. Concurrent and sequential HTTP requests share this pointer, resulting in high-severity data leakage between tenants and cumulative memory growth. ```typescript // src/lib/stores/user-session.svelte.ts // ANTI-PATTERN: Shared module state persists across SSR requests in the same Node.js process. // User B will receive User A's session data if rendered sequentially on the server. interface Session { user: { id: string; email: string } | null; isAuthenticated: boolean; } export const sessionState = $state<Session>({ user: null, isAuthenticated: false }); export function setSession(user: { id: string; email: string }) { sessionState.user = user; sessionState.isAuthenticated = true; } ``` #### Production Standard (Correct) > **Standard**: Encapsulating $state inside a class coupled with Svelte's Context API guarantees that reactive instances are tied strictly to individual SSR request component subtrees. Each incoming request instantiates an isolated SessionStore, eliminating cross-request pollution. ```typescript // src/lib/stores/user-session.svelte.ts import { getContext, setContext } from 'svelte'; interface User { id: string; email: string; } export class SessionStore { user = $state<User | null>(null); isAuthenticated = $derived(this.user !== null); constructor(initialUser: User | null = null) { this.user = initialUser; } setSession(user: User) { this.user = user; } clear() { this.user = null; } } const SESSION_CONTEXT_KEY = Symbol('USER_SESSION_CONTEXT'); export function createSessionContext(initialUser: User | null = null): SessionStore { const session = new SessionStore(initialUser); setContext(SESSION_CONTEXT_KEY, session); return session; } export function useSession(): SessionStore { const session = getContext<SessionStore>(SESSION_CONTEXT_KEY); if (!session) { throw new Error('useSession must be consumed within a component tree wrapped with createSessionContext.'); } return session; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes Module-State Boundary Isolation & Cross-Request SSR Leak Prevention

Svelte 5 Runes Module-State Boundary Isolation & Cross-Request SSR Leak Prevention defines an industrial-grade behavioral standard for frontend engineering. Enforces strict lifecycle boundaries around Svelte 5 module-scoped runes ($state, $derived) in universal and SSR applications. Module-level reactive declarations persist across multiple server requests within shared Node/serverless runtimes, precipitating catastrophic cross-tenant data contamination and unbounded memory exhaustion. All mutable reactive state within SSR-traversed code paths must be strictly scoped to component trees via Context API, request locals, or lifecycle-bound factory instantiations. 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: Shared Module-Scope $state() in Universal Modules Inducing Cross-User Session Leakage 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	Shared Module-Scope $state() in Universal Modules Inducing Cross-User Session Leakage	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 top-level mutable runes ($state, $state.raw) in module scope (.svelte.ts / .svelte.js files) when evaluated in SSR or universal runtime contexts.

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.