nfs-add-cachelisted

# Retrofit Redis-backed cache Use when a project from `nextjs-fullstack-starter` (which uses Next.js's in-process cache by default) outgrows that. Typical triggers: - The user is deploying multiple Next.js processes / containers and wants a shared cache. - A blue-green deploy throws away the warm cache every release and that's becoming painful. - The user wants to use `src/server/lib/cache.ts` as a general-purpose Redis helper for non-Next.js caches too (rate limits, queues, etc.). If the project ISN'T at one of those tipping points, push back gently — Next.js's default cache is fine until measurably not. ## Pre-flight checks Refuse if any of these is true: 1. `src/server/modules/` doesn't exist — the project wasn't scaffolded with this plugin. 2. `src/server/lib/cache.ts` already exists — Redis is already wired. Suggest `/nfs-review-project` for an audit instead. ## Plan 1. Add `ioredis` to dependencies. Add `@neshca/cache-handler` if the user wants the Next.js cache itself to go through Redis. 2. Add `redis` service to `docker-compose.yml` (under the `cache` profile so it doesn't always run). 3. Add `REDIS_URL` to `src/env.ts` and `.env.example`. 4. Write `src/server/lib/cache.ts` — a typed wrapper exposing `get`, `set`, `del`, and a `cached(fn, key, ttl)` helper. 5. (Optional) Configure `next.config.ts`'s `cacheHandler` to use `@neshca/cache-handler` against Redis. 6. Update `CLAUDE.md` with the new pattern. ## The cache helper ```ts // src/server/lib/cache.ts im