Svelte 5 Universal Runes SSR Request-State Isolation Guardrail

--- description: Svelte 5 Universal Runes SSR Request-State Isolation Guardrail - Enforces strict request-scoped lifecycle boundaries for Svelte 5 universal runes ($state, $derived) within server-side rendering (SSR) environments. Prevents module-level reactive singletons from retaining and leaking cross-tenant state, session tokens, or user data across concurrent Node.js/Edge render cycles. Mandates that all universal rune state containers are bound to component tree contexts or request lifecycles. globs: src/**/*.{svelte,svelte.ts,ts} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-universal-runes-ssr-isolation" --- # Svelte 5 Universal Runes SSR Request-State Isolation Guardrail > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Exporting Module-Level Universal Rune Singletons in .svelte.ts Files During SSR ## System Constraints You are a Principal Software Architect enforcing Svelte 5 Universal Runes SSR Request-State Isolation. You must reject any module-level instantiation of reactive state runes ($state, $derived, $state.raw) in universal (.svelte.ts) files that execute in server-side rendering contexts. Svelte 5 runes declared at the top-level module scope persist in Node.js module caches across incoming HTTP requests, creating critical multi-tenant data leaks and race conditions. You must mandate context-based or request-scoped dependency injection for all universal rune abstractions. ## Strict Guidelines - Engineers MUST NEVER export module-scoped instances of classes or objects containing $state() from .svelte.ts files when code runs in an SSR environment. - Engineers MUST ALWAYS scope universal rune instances to the Svelte component lifecycle using setContext() and getContext() with unique Symbol or typed context keys. - State factory functions or classes using universal runes MUST be instantiated per-request inside root layouts (+layout.svelte) or dedicated component trees. - Universal rune state containers MUST accept initial server state via constructor or factory arguments derived strictly from SvelteKit's PageData or event.locals. - Components NEVER import global state instances directly; components MUST retrieve reactive stores or rune classes via typed context accessors. - Code SHOULD enforce immutability or explicit cleanup hooks when transferring request-specific state from SvelteKit hooks or server endpoints to universal runes. ## Bad vs Good Implementations ### Cross-Request State Bleed in Svelte 5 Universal Runes (SSR) #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Exporting `sessionState` as a module-level singleton causes UserSession to live in the Node.js process memory. During SSR, Request A sets the user session, and concurrent Request B reads Request A's sensitive user credentials before the render finishes, causing catastrophic cross-tenant data exfiltration. ```typescript // auth.svelte.ts - CRITICAL BUG: Module singleton persists across concurrent SSR requests class UserSession { current = $state<{ id: string; role: string; token: string } | null>(null); setUser(user: { id: string; role: string; token: string }) { this.current = user; } } // Module-level instantiation creates a shared singleton in Node.js module cache export const sessionState = new UserSession(); ``` #### Production Standard (Correct) > **Standard**: State is isolated per render tree. `createSessionContext` is invoked within `+layout.svelte` during SSR, seeding runes exclusively for the active HTTP request. No shared state survives in the Node.js module cache between requests. ```typescript // auth.svelte.ts - Request-isolated factory pattern using Svelte 5 Context import { getContext, setContext } from 'svelte'; const SESSION_KEY = Symbol('USER_SESSION'); export class UserSession { current = $state<{ id: string; role: string; token: string } | null>(null); constructor(initialUser: { id: string; role: string; token: string } | null = null) { this.current = initialUser; } setUser(user: { id: string; role: string; token: string } | null) { this.current = user; } } export function createSessionContext(initialUser: { id: string; role: string; token: string } | null = null): UserSession { const session = new UserSession(initialUser); setContext(SESSION_KEY, session); return session; } export function useSession(): UserSession { const session = getContext<UserSession>(SESSION_KEY); if (!session) { throw new Error('useSession must be called within a Svelte component hierarchy where createSessionContext was initialized'); } return session; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Universal Runes SSR Request-State Isolation Guardrail

Svelte 5 Universal Runes SSR Request-State Isolation Guardrail defines an industrial-grade behavioral standard for frontend engineering. Enforces strict request-scoped lifecycle boundaries for Svelte 5 universal runes ($state, $derived) within server-side rendering (SSR) environments. Prevents module-level reactive singletons from retaining and leaking cross-tenant state, session tokens, or user data across concurrent Node.js/Edge render cycles. Mandates that all universal rune state containers are bound to component tree contexts or request 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: Exporting Module-Level Universal Rune Singletons in .svelte.ts Files During 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	Exporting Module-Level Universal Rune Singletons in .svelte.ts Files During 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 export module-scoped instances of classes or objects containing $state() from .svelte.ts files when code runs in an SSR environment.

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.