[ErgoCodes]

Resumen

• POST /conversations/:id/messages ahora consulta Redis antes de buscar chunks o llamar al LLM: si hay hit, responde con la respuesta y citas cacheadas y setea X-Cache: HIT sin tocar embeddings/LLM (RNF-07, <300ms); si hay miss, sigue el camino normal y guarda el resultado en caché antes de persistir el mensaje.
• Clave de caché = hash SHA-256 de usuario + documentos consultados (ordenados) + pregunta normalizada + contador de generación por usuario. Función pura en cache/utils/cache-key.ts, con tests exhaustivos (RNF-11 la nombra explícitamente como lógica de dominio a cubrir).
• Invalidación por contador de generación (INCR cache:gen:{userId}) en vez de borrado activo: subir o borrar un documento incrementa la generación, lo que cambia la clave de caché de la siguiente pregunta — las entradas viejas quedan huérfanas y expiran solas por el TTL de 24h, sin necesitar SCAN/KEYS bloqueante sobre Redis.
• El mensaje se persiste en el historial tanto en cache hit como en cache miss (repetir la pregunta crea una nueva entrada en la conversación con la respuesta correcta; la caché ahorra cómputo, no historial).
• Nunca se loguea el contenido de una respuesta cacheada.

Independiente de #16 en lógica de negocio; solo comparten conversation.service.ts/conversation.routes.ts en puntos no adyacentes (verificado con merge de prueba local, sin conflictos).

Test plan

• pnpm --filter api typecheck
• pnpm --filter api lint
• pnpm --filter api test (252 passed)
• pnpm --filter api test:coverage (100% en services/schemas/utils, incluida cache-key.ts)
• pnpm --filter api test:integration (295 passed, Mongo real)
• Verificado en conjunto con feat(api): historial de conversaciones (RF-09) #16 (merge de prueba local, sin conflictos)

🤖 Generated with Claude Code

https://claude.ai/code/session_01BoVKssKAe1Z1vGJAEBEzvy