Svelte 5 Runes Server-Side Module State Isolation Standard

Disallows root-level module-scoped $state and $derived runes in universal and server-evaluated files to prevent cross-request tenant memory pollution during Server-Side Rendering (SSR). In persistent runtime processes like Node.js, Bun, or Cloudflare Workers, module-level state survives individual request lifecycles and leaks sensitive tenant data across concurrent clients. All reactive state evaluated during SSR must be strictly scoped to the request lifecycle via Svelte Context or factory functions.

--- description: Svelte 5 Runes Server-Side Module State Isolation Standard - Disallows root-level module-scoped $state and $derived runes in universal and server-evaluated files to prevent cross-request tenant memory pollution during Server-Side Rendering (SSR). In persistent runtime processes like Node.js, Bun, or Cloudflare Workers, module-level state survives individual request lifecycles and leaks sensitive tenant data across concurrent clients. All reactive state evaluated during SSR must be strictly scoped to the request lifecycle via Svelte Context or factory functions. globs: src/**/*.{svelte.ts,svelte.js,svelte,ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-runes-ssr-module-state-isolation" --- # Svelte 5 Runes Server-Side Module State Isolation Standard > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Module-Scoped Top-Level $state in SSR Modules Causing Cross-Tenant Data Leakage ## System Constraints You are a Principal Software Architect enforcing the Svelte 5 Runes Server-Side Module State Isolation Standard. You must rigorously reject any top-level module-scope $state, $derived, or mutable reactive singletons in code paths evaluated during SSR. Mandate context-based injection or request-scoped instantiation factories to guarantee complete memory isolation across concurrent client requests. ## Strict Guidelines - Engineers MUST NEVER declare top-level root-scope $state(), $state.raw(), or $derived() runes inside universal (.svelte.ts/.svelte.js) or server modules. - Engineers MUST encapsulate shared mutable state inside factory functions or class instances created per-request and passed down via Svelte's setContext() and getContext(). - Code evaluated during SSR MUST treat module scope as immutable singleton memory that outlives individual HTTP request lifecycles. - Services that manage tenant-specific data (e.g., auth, permissions, carts) MUST bind their reactive instances to the component lifecycle root or SvelteKit's event.locals pipeline. - Components NEVER import global rune singletons to read or write user-specific or request-dependent data during SSR rendering. ## Bad vs Good Implementations ### Module-Level $state vs Context-Scoped Per-Request State Class #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Declaring $state at the module root creates a single memory address shared across all concurrent SSR requests running in the same Node.js/Bun process. When Tenant A populates sessionState, Tenant B's concurrently rendered HTML will read Tenant A's user session, causing severe cross-tenant data exfiltration and authentication bypass. ```typescript // src/lib/stores/user-session.svelte.ts // ANTI-PATTERN: Shared global module-level rune state leaks across SSR requests! export interface UserSession { id: string | null; tenantId: string | null; isAuthenticated: boolean; } // CRITICAL: Top-level $state creates a global singleton on the SSR server process export const sessionState = $state<UserSession>({ id: null, tenantId: null, isAuthenticated: false }); export function setSessionUser(id: string, tenantId: string): void { // Tenant A's request mutates this, poisoning Tenant B's concurrent SSR render sessionState.id = id; sessionState.tenantId = tenantId; sessionState.isAuthenticated = true; } ``` #### Production Standard (Correct) > **Standard**: Encapsulating rune state within an instantiable class and provisioning it strictly through Svelte's Context API (initSessionContext called at the root +layout.svelte per request) guarantees that the state lifecycle is bound to the component tree of a single request. It prevents cross-request data leaks on SSR while retaining full client-side reactivity. ```typescript // src/lib/stores/user-session.svelte.ts import { getContext, setContext } from 'svelte'; export interface UserSession { id: string | null; tenantId: string | null; isAuthenticated: boolean; } const SESSION_CONTEXT_KEY = Symbol('USER_SESSION_CONTEXT'); export class UserSessionStore { #state = $state<UserSession>({ id: null, tenantId: null, isAuthenticated: false }); constructor(initial?: Partial<UserSession>) { if (initial) { this.#state.id = initial.id ?? null; this.#state.tenantId = initial.tenantId ?? null; this.#state.isAuthenticated = Boolean(initial.id); } } get current(): Readonly<UserSession> { return this.#state; } update(id: string, tenantId: string): void { this.#state.id = id; this.#state.tenantId = tenantId; this.#state.isAuthenticated = true; } } export function initSessionContext(initial?: Partial<UserSession>): UserSessionStore { const store = new UserSessionStore(initial); setContext(SESSION_CONTEXT_KEY, store); return store; } export function getSessionContext(): UserSessionStore { const store = getContext<UserSessionStore>(SESSION_CONTEXT_KEY); if (!store) { throw new Error('UserSessionStore was not initialized in parent context.'); } return store; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes Server-Side Module State Isolation Standard

Svelte 5 Runes Server-Side Module State Isolation Standard defines an industrial-grade behavioral standard for frontend engineering. Disallows root-level module-scoped $state and $derived runes in universal and server-evaluated files to prevent cross-request tenant memory pollution during Server-Side Rendering (SSR). In persistent runtime processes like Node.js, Bun, or Cloudflare Workers, module-level state survives individual request lifecycles and leaks sensitive tenant data across concurrent clients. All reactive state evaluated during SSR must be strictly scoped to the request lifecycle via Svelte Context or factory functions. 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 Top-Level $state in SSR Modules Causing Cross-Tenant Data 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	Module-Scoped Top-Level $state in SSR Modules Causing Cross-Tenant Data 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 NEVER declare top-level root-scope $state(), $state.raw(), or $derived() runes inside universal (.svelte.ts/.svelte.js) or server modules.

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.