Svelte 5 Runes SSR State Isolation & Request Concurrency Guardrail

--- description: Svelte 5 Runes SSR State Isolation & Request Concurrency Guardrail - Universal Svelte 5 runes ($state, $derived) declared at module scope create persistent singletons in Node.js/SSR runtimes that survive across individual HTTP transactions. Any mutable rune instantiated outside the component lifecycle or Svelte context leaks user sessions, permissions, and reactive proxies across concurrent requests. All dynamic or user-specific state must be instantiated per-request using context encapsulation or factory injection. 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-concurrency-isolation" --- # Svelte 5 Runes SSR State Isolation & Request Concurrency Guardrail > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Module-Scoped Runes Singletons Leaking State Across Concurrent SSR Requests ## System Constraints You are a Principal Software Architect enforcing absolute state isolation in Svelte 5 SSR applications. In Node.js or Edge SSR runtimes, module-level code runs in a long-lived shared process. Instantiating `$state()` or `$derived()` at the module root of universal `.svelte.ts` files creates a shared memory proxy across all concurrent SSR requests, causing catastrophic data breaches and race conditions. Mandate per-request encapsulation using Svelte context APIs or request-scoped factories. ## Strict Guidelines - Engineers MUST NEVER declare or export top-level mutable `$state()` or `$derived()` instances at the module root of `.svelte.ts` files for user, session, or request-specific data. - Engineers MUST ALWAYS encapsulate request-dependent state within classes or factory functions that are instantiated inside Svelte component lifecycles or SvelteKit hooks. - Engineers MUST ALWAYS bind per-request state to the component tree using Svelte 5 `setContext` and retrieve it via `getContext` to ensure state destruction upon request completion. - Shared constant configuration MAY be declared at module scope ONLY IF it is deeply immutable and contains no `$state` proxies. - Components NEVER import global writable state instances directly from shared library files; state MUST be passed via typed context hooks or component props. ## Bad vs Good Implementations ### Module-Level Runes Singleton vs. Context-Encapsulated State #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Declaring `sessionStore` at module scope creates a single persistent proxy in the Node.js memory space. When Request A sets `sessionStore.userId = 'alice'`, a concurrent Request B executing on the same SSR thread reads Alice's data, causing catastrophic multitenant leakage. ```typescript // src/lib/stores/session.svelte.ts // FATAL: Evaluated once per Node process; shared across all concurrent SSR requests! export interface UserSession { userId: string | null; tenantId: string | null; roles: string[]; } // Module-level $state proxy singleton leaks data between tenants during SSR export const sessionStore = $state<UserSession>({ userId: null, tenantId: null, roles: [] }); export function setSession(user: UserSession): void { sessionStore.userId = user.userId; sessionStore.tenantId = user.tenantId; sessionStore.roles = user.roles; } ``` #### Production Standard (Correct) > **Standard**: By encapsulating the rune within `SessionState` and binding it through `setContext` during the root component or layout mount, each concurrent SSR request receives its own isolated instance that is automatically garbage-collected when the request finishes. ```typescript // src/lib/stores/session.svelte.ts import { getContext, setContext } from 'svelte'; export interface UserSession { userId: string | null; tenantId: string | null; roles: string[]; } export class SessionState { current = $state<UserSession>({ userId: null, tenantId: null, roles: [] }); isAuthenticated = $derived(this.current.userId !== null); constructor(initialData?: Partial<UserSession>) { if (initialData) { this.current = { ...this.current, ...initialData }; } } } const SESSION_KEY = Symbol('SESSION_STATE'); export function setSessionContext(initialData?: Partial<UserSession>): SessionState { const session = new SessionState(initialData); return setContext(SESSION_KEY, session); } export function getSessionContext(): SessionState { const session = getContext<SessionState>(SESSION_KEY); if (!session) { throw new Error('SessionContext is missing. Ensure setSessionContext was called in a parent layout/component.'); } return session; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes SSR State Isolation & Request Concurrency Guardrail

Svelte 5 Runes SSR State Isolation & Request Concurrency Guardrail defines an industrial-grade behavioral standard for frontend engineering. Universal Svelte 5 runes ($state, $derived) declared at module scope create persistent singletons in Node.js/SSR runtimes that survive across individual HTTP transactions. Any mutable rune instantiated outside the component lifecycle or Svelte context leaks user sessions, permissions, and reactive proxies across concurrent requests. All dynamic or user-specific state must be instantiated per-request using context encapsulation or factory injection. 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 Runes Singletons Leaking State Across Concurrent SSR 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-Scoped Runes Singletons Leaking State Across Concurrent SSR 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 or export top-level mutable `$state()` or `$derived()` instances at the module root of `.svelte.ts` files for user, session, or request-specific data.

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.