Svelte 5 Runes Context Isolation Guardrail for Universal SSR State

--- description: Svelte 5 Runes Context Isolation Guardrail for Universal SSR State - Enforces strict isolation of Svelte 5 reactive state in multi-tenant SSR runtimes by prohibiting top-level module-scoped $state() singletons in universal modules. Eliminates cross-request data pollution by mandating scoped dependency injection via getContext/setContext or per-request factory lifecycles. 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-state-leakage-guardrail" --- # Svelte 5 Runes Context Isolation Guardrail for Universal SSR State > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Module-Scoped Reactive Singletons Causing Cross-Tenant Data Leakage in Concurrent SSR Runtimes ## System Constraints You are a Principal Software Architect enforcing the Svelte 5 Runes Universal SSR State Leakage Guardrail. In Node.js, Bun, or Cloudflare Workers SSR runtimes, module-level variables outlive individual HTTP requests. You must mandate strict state isolation: prohibit module-scoped $state() instances in shared modules and enforce context-bound or request-bound state instantiation using Svelte 5's getContext/setContext APIs. ## Strict Guidelines - Engineers MUST NOT declare module-scoped, top-level $state(), $derived(), or stateful class singletons in files executed in server environments. - Engineers MUST ALWAYS encapsulate reactive state within factory functions or classes instantiated inside component lifecycles or Svelte context. - Engineers MUST ALWAYS access request-dependent shared state through typed getContext/setContext wrappers instantiated at the root layout or page level. - Services MUST NEVER cache tenant-identifying, session-identifying, or authorization-sensitive rune instances across requests at the module evaluation level. - Components NEVER instantiate shared state via direct singleton import when serving multi-tenant SSR applications. ## Bad vs Good Implementations ### Module-Scoped Rune Singleton vs Context-Bound State Factory #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: In an SSR environment, modules are loaded once and evaluated globally per worker instance. When Request A calls setCurrentUser(), it alters currentUserState for all subsequent or concurrent requests handled by that worker process, leading to severe cross-tenant data leakage and privilege escalation. ```typescript // src/lib/stores/user.svelte.ts - CRITICAL BUG: Module singleton persists across concurrent SSR requests interface UserProfile { id: string; tenantId: string; name: string; } // Module-level $state retains mutations in long-running Node/Bun SSR worker process! export const currentUserState = $state<UserProfile>({ id: '', tenantId: '', name: '' }); export function setCurrentUser(user: UserProfile) { currentUserState.id = user.id; currentUserState.tenantId = user.tenantId; currentUserState.name = user.name; } ``` #### Production Standard (Correct) > **Standard**: Encapsulating rune state in a class and injecting it through Svelte's context API ensures that the state instance is bound directly to the active component tree. In SSR, each incoming request instantiates a new component tree with isolated context, completely preventing cross-request state bleeding. ```typescript // src/lib/stores/user.svelte.ts - SECURE: Scoped context factory isolating state per SSR request boundary import { getContext, setContext } from 'svelte'; export interface UserProfile { id: string; tenantId: string; name: string; } export class UserSessionState { user = $state<UserProfile | null>(null); constructor(initialUser: UserProfile | null = null) { this.user = initialUser; } setUser(user: UserProfile) { this.user = user; } } const USER_SESSION_KEY = Symbol('USER_SESSION_KEY'); export function initUserSession(initialUser: UserProfile | null = null): UserSessionState { const session = new UserSessionState(initialUser); return setContext(USER_SESSION_KEY, session); } export function useUserSession(): UserSessionState { const session = getContext<UserSessionState>(USER_SESSION_KEY); if (!session) { throw new Error('useUserSession must be used within an initialized component context'); } return session; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes Context Isolation Guardrail for Universal SSR State

Svelte 5 Runes Context Isolation Guardrail for Universal SSR State defines an industrial-grade behavioral standard for frontend engineering. Enforces strict isolation of Svelte 5 reactive state in multi-tenant SSR runtimes by prohibiting top-level module-scoped $state() singletons in universal modules. Eliminates cross-request data pollution by mandating scoped dependency injection via getContext/setContext or per-request factory lifecycles. 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 Reactive Singletons Causing Cross-Tenant Data Leakage in Concurrent SSR Runtimes 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 Reactive Singletons Causing Cross-Tenant Data Leakage in Concurrent SSR Runtimes	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 module-scoped, top-level $state(), $derived(), or stateful class singletons in files executed in server environments.

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.