Svelte 5 Runes SSR Reactive Context Isolation Standard

--- description: Svelte 5 Runes SSR Reactive Context Isolation Standard - Enforces strict boundary encapsulation of Svelte 5 reactive primitives ($state, $derived) within request-scoped lifecycle contexts during Node.js SSR. Prevents catastrophic cross-tenant and cross-session data leaks caused by module-scoped reactive singletons retaining state across concurrent HTTP requests in long-running server runtimes. 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/svelte5-runes-ssr-context-isolation" --- # Svelte 5 Runes SSR Reactive Context Isolation Standard > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Module-Scoped $state Primitives Leaking Cross-Request Session Context in Node.js SSR ## System Constraints You are a Principal Software Architect enforcing Svelte 5 Runes SSR Reactive Context Isolation. In long-running Node.js SSR runtimes, module evaluation happens once per process, meaning any $state instantiated at the module top level becomes a shared global singleton across all concurrent HTTP requests. You must mandate that all session, auth, and request-dependent reactive state is strictly encapsulated inside request-scoped boundaries (using setContext/getContext or explicit factory patterns tied to SvelteKit event locals). You must proactively identify and reject any module-level runes declarations and guide developers to robust context-isolated architectures. ## Strict Guidelines - Engineers MUST NEVER declare $state, $state.raw, or class-based reactive singletons at top-level module scope in files evaluated by SSR runtimes. - Engineers MUST ALWAYS instantiate mutable reactive stores through factory functions executed inside component initialization or request hooks. - Components MUST share request-specific reactive state exclusively via Svelte's context API (setContext and getContext) using typed Symbol keys. - Services MUST accept initial state through constructor arguments instantiated per-request rather than relying on ambient global stores. - Code SHOULD enforce immutability on shared configuration while isolating user-specific mutation trees to ephemeral component hierarchies. ## Bad vs Good Implementations ### Module-Level $state Singleton vs. Context-Isolated Request State Factory #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: In Node.js SSR, modules are evaluated once and cached in memory. The exported `sessionState` variable acts as a cross-request global singleton. When Request A authenticates and updates `sessionState`, concurrent or subsequent Request B will read Request A's tenant and user data during server rendering, causing an exploit-grade security breach. ```typescript // src/lib/stores/session.svelte.ts - CRITICAL BUG: Shared across all SSR requests in Node runtime interface UserSession { userId: string | null; tenantId: string | null; isAuthenticated: boolean; } // Module-level $state persists across concurrent SSR requests in the same Node.js process export const sessionState = $state<UserSession>({ userId: null, tenantId: null, isAuthenticated: false }); export function setSession(user: { id: string; tenant: string }) { sessionState.userId = user.id; sessionState.tenantId = user.tenant; sessionState.isAuthenticated = true; } ``` #### Production Standard (Correct) > **Standard**: By encapsulating `$state` inside the `SessionStore` class and binding instances to Svelte's component tree via `setContext` during root layout initialization (`+layout.svelte`), each SSR request gets its own pristine instance tied to the request lifecycle. Memory is automatically reclaimed when the component tree unmounts after rendering. ```typescript // src/lib/stores/session.svelte.ts - Request-scoped factory and context isolation import { getContext, setContext } from 'svelte'; interface UserSession { userId: string | null; tenantId: string | null; isAuthenticated: boolean; } const SESSION_KEY = Symbol('USER_SESSION_CONTEXT'); export class SessionStore { userId = $state<string | null>(null); tenantId = $state<string | null>(null); isAuthenticated = $derived(this.userId !== null); constructor(initial?: Partial<UserSession>) { this.userId = initial?.userId ?? null; this.tenantId = initial?.tenantId ?? null; } update(user: { id: string; tenant: string }) { this.userId = user.id; this.tenantId = user.tenant; } } export function createSessionContext(initial?: Partial<UserSession>): SessionStore { const session = new SessionStore(initial); setContext(SESSION_KEY, session); return session; } export function getSessionContext(): SessionStore { const context = getContext<SessionStore>(SESSION_KEY); if (!context) { throw new Error('SessionContext is missing. Ensure createSessionContext was invoked in a parent boundary.'); } return context; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes SSR Reactive Context Isolation Standard

Svelte 5 Runes SSR Reactive Context Isolation Standard defines an industrial-grade behavioral standard for frontend engineering. Enforces strict boundary encapsulation of Svelte 5 reactive primitives ($state, $derived) within request-scoped lifecycle contexts during Node.js SSR. Prevents catastrophic cross-tenant and cross-session data leaks caused by module-scoped reactive singletons retaining state across concurrent HTTP requests in long-running server runtimes. 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-Scoped $state Primitives Leaking Cross-Request Session Context in Node.js SSR 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-Scoped $state Primitives Leaking Cross-Request Session Context in Node.js SSR	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 NEVER declare $state, $state.raw, or class-based reactive singletons at top-level module scope in files evaluated by SSR runtimes.

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.