Svelte 5 Runes SSR Cross-Request Reactive Isolation Standard

--- description: Svelte 5 Runes SSR Cross-Request Reactive Isolation Standard - Enforces strict architectural boundaries on Svelte 5 $state runes within universal and server-side contexts. Top-level reactive singletons in shared modules persist across the entire Node.js/Bun process lifetime, causing catastrophic cross-request data leaks and multi-tenant session poisoning in SSR applications. globs: src/**/*.svelte.ts, src/**/*.svelte, src/**/*.ts alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-runes-ssr-state-isolation-barrier" --- # Svelte 5 Runes SSR Cross-Request Reactive Isolation Standard > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Module-Level Singleton Reactive Runes Mutating Across Concurrent Server Requests ## System Constraints You are a Principal Engineer enforcing the Svelte 5 Runes Universal SSR State Leakage Barrier. Mandate strict encapsulation of all $state, $derived, and reactive rune hierarchies in universal `.svelte.ts` and `.svelte` files. Module-scoped reactive state persists across the lifecycle of long-running SSR server processes and corrupts tenant isolation. You must reject any module-level runes that contain per-request or user-specific state and enforce Context-based or hook-scoped instantiation. ## Strict Guidelines - Engineers MUST NEVER declare module-level `$state` variables or instantiate reactive classes at the root scope of universal `.svelte.ts` files evaluated during SSR. - Engineers MUST instantiate user-specific or request-specific reactive state inside component lifecycles using factory functions bound via `setContext` and `getContext` with strongly typed `Symbol` keys. - Services MUST route server-specific user identity, authentication, and tenant metadata strictly through SvelteKit `event.locals` and pass it down via `PageData` or layout contexts. - Code SHOULD conditionally restrict any unavoidable global client state using `browser` guards from `$app/environment`, explicitly asserting that the construct throws or remains null on the server. - Components NEVER bridge request boundaries by mutating shared singleton exports during server-side execution paths. ## Bad vs Good Implementations ### Tenant & User State Isolation via Context API vs Module-Level Singleton #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: In SvelteKit or universal SSR runtimes, modules are evaluated once per worker/process. Exporting `new UserSession()` directly creates an in-memory singleton. If two requests hit the SSR pipeline concurrently, mutations made for Tenant A mutate the global state, leaking private data into Tenant B's server-rendered HTML. ```typescript // src/lib/stores/user-session.svelte.ts // FATAL: This module-scoped singleton persists across all incoming HTTP requests in SSR. // User A's data will be served to User B during concurrent server-side evaluations. class UserSession { currentTenantId = $state<string | null>(null); isAuthenticated = $state(false); setTenant(id: string) { this.currentTenantId = id; this.isAuthenticated = true; } } export const sessionStore = new UserSession(); ``` #### Production Standard (Correct) > **Standard**: By tying `UserSession` to Svelte's Context API via `initUserSession` (called within a root layout or component initialization phase), the reactive runes are isolated strictly to that specific request's component tree. When SSR finishes, the tree and context are garbage-collected, preventing cross-request pollution. ```typescript // src/lib/stores/user-session.svelte.ts import { getContext, setContext } from 'svelte'; const SESSION_CONTEXT_KEY = Symbol('USER_SESSION_CONTEXT'); export class UserSession { currentTenantId = $state<string | null>(null); isAuthenticated = $state(false); constructor(initialTenantId: string | null = null) { this.currentTenantId = initialTenantId; this.isAuthenticated = initialTenantId !== null; } setTenant(id: string): void { this.currentTenantId = id; this.isAuthenticated = true; } } export function initUserSession(initialTenantId: string | null = null): UserSession { const session = new UserSession(initialTenantId); return setContext(SESSION_CONTEXT_KEY, session); } export function useUserSession(): UserSession { const session = getContext<UserSession>(SESSION_CONTEXT_KEY); if (!session) { throw new Error('useUserSession must be called within an initialized component hierarchy'); } return session; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes SSR Cross-Request Reactive Isolation Standard

Svelte 5 Runes SSR Cross-Request Reactive Isolation Standard defines an industrial-grade behavioral standard for frontend engineering. Enforces strict architectural boundaries on Svelte 5 $state runes within universal and server-side contexts. Top-level reactive singletons in shared modules persist across the entire Node.js/Bun process lifetime, causing catastrophic cross-request data leaks and multi-tenant session poisoning in SSR applications. 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 Singleton Reactive Runes Mutating Across Concurrent Server 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 Singleton Reactive Runes Mutating Across Concurrent Server 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 NEVER declare module-level `$state` variables or instantiate reactive classes at the root scope of universal `.svelte.ts` files evaluated during SSR.

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.