Svelte 5 Runes SSR Cross-Request State Leakage Prevention

--- description: Svelte 5 Runes SSR Cross-Request State Leakage Prevention - Enforces strict lexical encapsulation of Svelte 5 reactive runes ($state, $derived) within component lifecycles and context trees during Server-Side Rendering (SSR). Module-level mutable state in shared server processes leaks across concurrent multi-tenant requests, causing catastrophic data corruption and security breaches. globs: src/**/*.svelte, src/**/*.svelte.ts, src/**/*.svelte.js, src/**/*.ts alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-runes-ssr-cross-request-isolation" --- # Svelte 5 Runes SSR Cross-Request State Leakage Prevention > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Global Module-Level Runes Instantiation in Server-Rendered Contexts ## System Constraints You are a Principal Software Architect enforcing zero-trust state isolation in Svelte 5 and SvelteKit applications. You must prevent cross-request state leakage caused by module-level runes ($state, $derived) during SSR. Enforce factory functions and Svelte Context (setContext/getContext) patterns to ensure every server request maintains a totally isolated reactive scope. ## Strict Guidelines - Engineers MUST NOT declare top-level, module-scoped mutable runes ($state, $state.raw, $derived) in universal `.svelte.ts` or `.svelte.js` files evaluated on the server. - Engineers MUST instantiate all reactive state stores via factory functions or classes within component initialization boundaries or request handlers. - Engineers MUST pass per-request state down component trees using Svelte's Context API (`setContext` / `getContext`) keyed by unique Symbol tokens. - Code SHOULD leverage immutable request locals (`event.locals` in SvelteKit) for initial SSR data hydration rather than shared module instances. - Components NEVER import global singleton state instances directly if those instances contain tenant-, user-, or session-specific properties. - Stores that wrap `$state` in `.svelte.ts` MUST export an instantiation factory (`createStore()`) rather than an instantiated singleton instance. ## Bad vs Good Implementations ### Module-Level Singleton Rune vs. Context-Encapsulated Class Factory #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: In SSR, Node.js or edge runtimes keep module-level variables in persistent process memory. Concurrent requests will read and overwrite `sessionStore`, resulting in Tenant A viewing or mutating Tenant B's session data. ```typescript // src/lib/stores/session.svelte.ts - CRITICAL VULNERABILITY // Module-level $state persists across concurrent SSR requests in the same Node.js/Bun process. interface UserSession { userId: string | null; tenantId: string | null; isAuthenticated: boolean; } // ANTI-PATTERN: Shared mutable state across all SSR requests export const sessionStore = $state<UserSession>({ userId: null, tenantId: null, isAuthenticated: false }); export function setSession(user: { id: string; tenantId: string }) { sessionStore.userId = user.id; sessionStore.tenantId = user.tenantId; sessionStore.isAuthenticated = true; } ``` #### Production Standard (Correct) > **Standard**: State is encapsulated inside a class instance created per-request and anchored to Svelte's Context lifecycle. SSR instances remain strictly isolated per render pass without memory bleeding between requests. ```typescript // src/lib/stores/session.svelte.ts - THREAD-SAFE SSR ISOLATION import { getContext, setContext } from 'svelte'; interface UserSession { userId: string | null; tenantId: string | null; isAuthenticated: boolean; } const SESSION_KEY = Symbol('USER_SESSION'); export class SessionStore { #state = $state<UserSession>({ userId: null, tenantId: null, isAuthenticated: false }); constructor(initial?: Partial<UserSession>) { if (initial) { Object.assign(this.#state, initial); } } get current() { return this.#state; } setSession(user: { id: string; tenantId: string }) { this.#state.userId = user.id; this.#state.tenantId = user.tenantId; this.#state.isAuthenticated = true; } } export function initSessionStore(initial?: Partial<UserSession>): SessionStore { const store = new SessionStore(initial); setContext(SESSION_KEY, store); return store; } export function useSessionStore(): SessionStore { const store = getContext<SessionStore>(SESSION_KEY); if (!store) { throw new Error('useSessionStore must be called within an initialized component hierarchy'); } return store; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes SSR Cross-Request State Leakage Prevention

Svelte 5 Runes SSR Cross-Request State Leakage Prevention defines an industrial-grade behavioral standard for frontend engineering. Enforces strict lexical encapsulation of Svelte 5 reactive runes ($state, $derived) within component lifecycles and context trees during Server-Side Rendering (SSR). Module-level mutable state in shared server processes leaks across concurrent multi-tenant requests, causing catastrophic data corruption and security breaches. 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: Global Module-Level Runes Instantiation in Server-Rendered Contexts 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	Global Module-Level Runes Instantiation in Server-Rendered Contexts	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, module-scoped mutable runes ($state, $state.raw, $derived) in universal `.svelte.ts` or `.svelte.js` files evaluated on the server.

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.