Svelte 5 Universal Context Boundary Isolation and SSR Reactive Graph Concurrency Guardrail

--- description: Svelte 5 Universal Context Boundary Isolation and SSR Reactive Graph Concurrency Guardrail - Enforces rigid request-boundary isolation for Svelte 5 reactive primitives ($state, $derived) in multi-tenant SSR environments. Prevents catastrophic cross-request data leaks and signal graph memory accumulation by eliminating module-level reactive singletons in favor of scoped component tree contexts. globs: src/**/*.{svelte,svelte.ts,svelte.js,ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-universal-context-boundary-isolation-standard" --- # Svelte 5 Universal Context Boundary Isolation and SSR Reactive Graph Concurrency Guardrail > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Module-Scoped Reactive Singletons Leaking Multi-Tenant State and Retaining Signal Graphs in High-Concurrency SSR ## System Constraints You are a Principal Software Architect enforcing the Svelte 5 Universal Context Boundary Isolation Standard. In server-side rendering (SSR), module-level state persists across requests across the Node.js/runtime process lifetime. You must reject any module-level reactive runes ($state, $derived) and force strictly encapsulated context-bound state instantiated within component lifecycles or request handlers. ## Strict Guidelines - Engineers MUST NEVER declare reactive primitives ($state, $derived, $state.raw) in the global or module scope of *.svelte.ts or *.ts files consumed during SSR. - Engineers MUST ALWAYS encapsulate request- or tenant-specific state inside classes or closure factories instantiated per-component lifecycle using Svelte 5 setContext/getContext with unique Symbol keys. - Components NEVER import a shared reactive singleton directly; all shared reactive domain models MUST be retrieved via an explicit typed context accessor hook (e.g., useTenantSession()). - Code MUST explicitly throw a descriptive invariant error if a context accessor function is invoked outside an active Svelte component initialization lifecycle. - Services MUST keep reactive state instances strictly isolated to the component tree or explicit request event boundaries (event.locals in SvelteKit) to allow garbage collection of the reactive graph immediately following render completion. ## Bad vs Good Implementations ### Preventing Module-Level Reactive Singletons in Multi-Tenant SSR #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: In Svelte 5 SSR, module-scoped $state is evaluated once per Node.js process. When multiple tenants execute SSR requests concurrently, Tenant A's state overrides and leaks into Tenant B's render pipeline. Additionally, the reactive dependency nodes are never reclaimed by the garbage collector, driving exponential memory leaks. ```typescript // tenantSession.svelte.ts // VULNERABILITY: Module-scoped rune acts as a server-wide singleton across all concurrent requests. export interface Session { tenantId: string; userId: string; cart: string[]; } // Module-level reactive state retains subscriber graphs and bleeds across tenant requests export const session = $state<Session>({ tenantId: '', userId: '', cart: [] }); export function setTenantSession(next: Session) { session.tenantId = next.tenantId; session.userId = next.userId; session.cart = [...next.cart]; } ``` #### Production Standard (Correct) > **Standard**: The TenantSessionStore binds to the Svelte component tree via setContext. Every SSR request initializes its own unique store instance inside its root layout or page boundary. When SSR completes, the component tree and its reactive graph are completely de-referenced and collected by the garbage collector, guaranteeing zero multi-tenant data bleed. ```typescript // tenantSession.svelte.ts import { getContext, setContext } from 'svelte'; export interface Session { readonly tenantId: string; readonly userId: string; readonly cart: readonly string[]; } const SESSION_KEY = Symbol.for('svelte5.tenant.session.boundary'); export class TenantSessionStore { #state = $state<Session>({ tenantId: '', userId: '', cart: [] }); constructor(initial: Session) { this.#state = initial; } get current(): Session { return this.#state; } updateCart(items: string[]): void { this.#state = { ...this.#state, cart: items }; } } export function createTenantSessionContext(initial: Session): TenantSessionStore { const store = new TenantSessionStore(initial); setContext(SESSION_KEY, store); return store; } export function useTenantSession(): TenantSessionStore { const store = getContext<TenantSessionStore>(SESSION_KEY); if (!store) { throw new Error('TenantSessionContext invariant violation: Accessed outside component hierarchy boundary.'); } return store; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Universal Context Boundary Isolation and SSR Reactive Graph Concurrency Guardrail

Svelte 5 Universal Context Boundary Isolation and SSR Reactive Graph Concurrency Guardrail defines an industrial-grade behavioral standard for frontend engineering. Enforces rigid request-boundary isolation for Svelte 5 reactive primitives ($state, $derived) in multi-tenant SSR environments. Prevents catastrophic cross-request data leaks and signal graph memory accumulation by eliminating module-level reactive singletons in favor of scoped component tree contexts. 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 Leaking Multi-Tenant State and Retaining Signal Graphs in High-Concurrency 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	Module-Scoped Reactive Singletons Leaking Multi-Tenant State and Retaining Signal Graphs in High-Concurrency 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 declare reactive primitives ($state, $derived, $state.raw) in the global or module scope of .svelte.ts or .ts files consumed during SSR.

Engineers MUST NEVER declare reactive primitives ($state, $derived, $state.raw) in the global or module scope of *.svelte.ts or *.ts files consumed 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.