CLAUDE.md Template: SvelteKit + Redis + Custom JWT Memory Auth + RedisOM Pipeline

Overview

CLAUDE.md template for a SvelteKit stack using Redis, RedisOM, and a Custom JWT Memory Auth pattern. It targets a memory-based token store with Redis as the authoritative data layer and RedisOM for typed queries.

Direct answer: This CLAUDE.md Template provides a complete blueprint and a copyable Claude Code block to implement a SvelteKit app with Redis-backed auth, an in-memory JWT token store, and a RedisOM Pipeline for efficient data access.

When to Use This CLAUDE.md Template

• You are building a SvelteKit app that requires fast, Redis-backed authentication state while minimizing external dependencies.
• You want an in-process JWT memory store with a Redis fallback/refresh mechanism using RedisOM for multi-key fetches.
• You need a repeatable, copyable CLAUDE.md template to onboard teammates quickly.
• You require a clear architecture and file structure for a Redis-powered authentication flow in a SvelteKit project.

Copyable CLAUDE.md Template

# CLAUDE.md

Project role: You are a SvelteKit backend engineer with Redis experience, implementing a memory-based JWT auth flow and RedisOM Pipeline orchestration.

Architecture rules:
- Redis as the source of truth for user data and session state.
- In-memory JWT store per Node process; Redis stores refresh tokens and user metadata for recovery.
- Use RedisOM Pipeline to batch fetch user and permission data in a single round trip when possible.
- Do not bypass RedisOM for batched reads; prefer Pipeline whenever you can combine reads.
- All secrets come from environment variables; never hard-code.

File structure rules:
- src/routes/api/auth/login.ts
- src/routes/api/auth/logout.ts
- src/routes/api/auth/refresh.ts
- src/lib/redis.ts
- src/lib/redisom/models/User.ts
- src/lib/auth/memoryStore.ts
- src/lib/auth/jwtUtil.ts
- src/lib/auth/redisom.ts
- tests/

Authentication rules:
- Use a memory-based access token store (in-memory Map) per Node process.
- Access tokens are JWTs signed with HS256 using JWT_SECRET.
- Refresh tokens are persisted in Redis via RedisOM and rotated on each refresh.
- Do not expose tokens via localStorage; use HTTP-only cookies or Authorization headers as appropriate for your app design (document your choice).

Database rules:
- Use Redis as the main datastore; users, roles, and sessions are RedisOM models.
- Use Redis pipelines for batched reads to reduce round trips.
- Never store secrets in plain text in Redis; hash sensitive fields where possible and use proper expirations.

Validation rules:
- Validate payloads with Zod (login payload: { username, password }).
- Validate JWT structure and expiration on every request.
- Validate RedisOM model schemas before save.

Security rules:
- Do not store plaintext passwords; use password hashes and secure comparison.
- Use HttpOnly cookies or Authorization headers; set SameSite=Lax or Strict as appropriate.
- Rotate refresh tokens and invalidate old tokens.
- Enforce TLS in production.

Testing rules:
- Unit tests for jwtUtil.sign/verify, memoryStore token lifecycle, and RedisOM queries.
- Integration tests for login, refresh, and logout flows using a mocked Redis instance.
- End-to-end tests should cover the happy path and failure cases.

Deployment rules:
- Inject Redis connection details via environment variables (REDIS_HOST, REDIS_PORT, REDIS_PASSWORD).
- Enable Redis TLS in production; configure Redis client accordingly.
- Ensure Node process has enough memory for in-memory token storage and set appropriate memory limits.
- Run tests in CI and gate merges with test results.

Things Claude must not do:
- Do not bypass RedisOM or ignore Pipeline capability for batched reads.
- Do not store tokens in in-memory persistence across restarts without a Redis fallback.
- Do not implement insecure password handling or expose secrets.
- Do not generate code that leaks memory or grows unbounded in the token store.

Recommended Project Structure

src/
  lib/
    redis.ts                # Redis client setup
    redisom.ts               # RedisOM helpers and models
    auth/
      memoryStore.ts          # In-memory JWT store (per-process)
      jwtUtil.ts              # JWT signing/verification
      redisom.ts               # RedisOM pipeline helpers
  routes/
    api/
      auth/
        login.ts
        refresh.ts
        logout.ts
  tests/
  +layout.svelte
  +page.svelte
  vite.config.ts
  package.json

Core Engineering Principles

• Single source of truth for user data in Redis; memory store is transient.
• Prefer RedisOM with Pipeline for efficient batched queries.
• Keep secrets in environment variables; never hard-code.
• Validate all inputs and handle errors gracefully without leaking internals.
• Favor explicit, typed contracts between layers (DTOs and models).

Code Construction Rules

• Use TypeScript strict mode; define interfaces for request/response payloads.
• Encapsulate JWT logic in a dedicated module (jwtUtil.ts).
• Encapsulate RedisOM pipeline usage in a dedicated module (redisom.ts).
• Do not mix in-memory tokens with Redis store across modules without clear boundaries.
• Keep API routes lean; delegate business logic to services in src/lib.

Security and Production Rules

• Protect in-memory tokens with process isolation; limit per-process memory growth.
• Use secure cookies or Authorization headers; set HttpOnly, Secure, SameSite attributes in production.
• Enable TLS, rotate JWT secret periodically, and implement token revocation strategy (via RedisOM).
• Audit Redis access with proper key namespaces and expirations.

Testing Checklist

• Unit tests for jwtUtil and memoryStore token lifecycle.
• Integration tests for login, refresh, and logout flows using a mocked Redis server.
• End-to-end tests that cover happy path and edge cases (expired tokens, revoked tokens).
• Performance checks for RedisOM PipelineBatch reads.

Common Mistakes to Avoid

• Storing tokens in memory without a Redis fallback in production.
• Ignoring RedisPipeline capabilities for batched reads.
• Weak password handling or missing token rotation on refresh.
• Hard-coding secrets or exposing them in client-side code.

FAQ