Actuá como arquitecto/a de software. Necesito diseñar un juego web
"¿Quién es ese Pokémon?" para un laboratorio de contenedores.

Requisitos funcionales:
- La persona ingresa su nombre y juega 10 rondas.
- En cada ronda ve la silueta de un Pokémon de la primera generación y elige
  entre 4 nombres. Al responder se revela la imagen y sus tipos.
- Se guarda un ranking con el mejor puntaje de cada jugador/a y un historial
  de las últimas partidas.
- Los datos de los Pokémon vienen de PokeAPI (https://pokeapi.co).

Requisitos no funcionales:
- Frontend y backend separados, cada uno en su contenedor.
- Respetar la política de uso justo de PokeAPI (cachear los recursos).
- La respuesta correcta nunca debe llegar al navegador antes de responder.
- Las partidas abandonadas no deben acumularse para siempre.
- Todo tiene que levantarse con Docker Compose.

Proponé: los componentes y su responsabilidad, qué base de datos usarías y por
qué, el modelo de datos, y las rutas de la API. Si evaluás alternativas
(por ejemplo, PostgreSQL frente a Valkey), compará ventajas y desventajas en una tabla.
No escribas código todavía.

Contexto: API para el juego "¿Quién es ese Pokémon?". Node.js 24, CommonJS,
Express 5 y la librería oficial "redis" (node-redis v5) para conectarse a Valkey.
Los datos de los Pokémon vienen de PokeAPI (https://pokeapi.co/api/v2).

Contrato (respetá nombres de rutas, campos y claves exactamente):
- GET /health: PING a Valkey. Responde el texto "ok", o 503.
- GET /api/info: { version (de package.json), partidas (contador stats:partidas) }.
- POST /api/partidas { jugador } (máx. 20 caracteres, obligatorio o 400):
  crea el hash partida:{uuid} con TTL de 1 hora e incrementa stats:partidas.
  Responde 201 con { id, jugador, total: 10 }.
- GET /api/partidas/:id/ronda: elige un Pokémon al azar entre 1 y 151 que no se
  haya usado en la partida, más 3 nombres distintos como distractores, y mezcla
  las 4 opciones. Guarda la ronda pendiente en el hash. Responde
  { ronda, total, imagen, opciones }. Si hay una ronda sin responder, devuelve
  la misma. NUNCA incluye el nombre correcto por separado.
- POST /api/partidas/:id/respuesta { opcion }: 400 si la opción no es de la
  ronda; 409 si no hay ronda pendiente. Acierto: 100 puntos + 20 por cada
  acierto consecutivo previo. Responde { correcta, puntos, pokemon: { id, nombre,
  tipos: [{ clave, nombre en español }], imagen, altura, peso }, puntaje, racha,
  aciertos, ronda, total, terminada }.
  Al terminar la ronda 10: guarda en el sorted set "ranking" solo si supera el
  récord del jugador, y agrega un resumen a la lista "historial" (máximo 10).
- GET /api/ranking: top 10 del sorted set, [{ jugador, puntaje }].
- GET /api/historial: la lista "historial", [{ jugador, puntaje, aciertos, total, fecha }].
- Partida inexistente: 404.

PokeAPI y caché:
- Nombres: GET /pokemon?limit=151, cacheado en "pokeapi:lista:151".
- Detalle: GET /pokemon/{id}, cacheado en "pokeapi:pokemon:{id}".
  Imagen: sprites.other["official-artwork"].front_default.
- Caché con TTL de 24 horas (patrón cache-aside) y timeout de 5 segundos por consulta.
- Nombres legibles: "mr-mime" → "Mr. Mime", "nidoran-f" → "Nidoran♀",
  "farfetchd" → "Farfetch'd"; el resto con mayúscula inicial.
- Si PokeAPI falla, la API responde 502 con un mensaje claro.

Configuración y resiliencia:
- PORT (3000), VALKEY_URL (redis://localhost:6379), POKEAPI_URL.
- Listener de "error" en el cliente, disableOfflineQueue: true, y 503 si el
  cliente no está listo. La app arranca aunque Valkey no esté disponible.
- Manejo de errores centralizado en un middleware de Express.

Restricciones: solo express y redis. Separá el código en estos módulos, todos
en la raíz de api/: valkey.js (conexión), pokeapi.js (acceso a PokeAPI con
caché), juego.js (lógica del juego) y server.js (rutas HTTP y arranque).

Salida: api/package.json, api/valkey.js, api/pokeapi.js, api/juego.js,
api/server.js, api/Dockerfile (node:24-alpine, usuario node, CMD con server.js,
HEALTHCHECK contra /health con wget) y api/.dockerignore.
Formato: un bloque de código por archivo, con la ruta como título justo antes
del bloque (por ejemplo: ### api/server.js). Nunca pongas la ruta como
comentario dentro del archivo: en JSON y en el Dockerfile rompe el build.
Sin explicaciones entre los archivos.

Escribí un compose.yaml con nombre de proyecto "pokedex" y tres servicios:
- web: se construye desde ./web, imagen "pokedex-web". Adentro corre nginx sin
  privilegios, que escucha en el 8080 (no en el 80): publicalo como "8080:8080".
- api: se construye desde ./api, imagen "pokedex-api", con las variables
  VALKEY_URL=redis://valkey:6379 y POKEAPI_URL=https://pokeapi.co/api/v2.
  Publica el 3000 solo en 127.0.0.1, para probarla con curl desde la máquina.
- valkey: imagen valkey/valkey:8-alpine con persistencia AOF, datos en un
  volumen nombrado "valkey-data" y healthcheck con "valkey-cli ping".

Requisitos:
- web arranca cuando api está healthy, y api cuando valkey está healthy.
- Si un contenedor se cae, se reinicia solo, salvo que lo detenga manualmente.
- Valkey no publica ningún puerto.
- Especificación actual de Compose (sin la clave "version").
Devolveme solo el archivo, sin comentarios con su nombre.

Contexto: frontend del juego "¿Quién es ese Pokémon?". HTML, CSS y JavaScript
sin frameworks ni librerías externas. Lo sirve nginx, que reenvía /api y /health
a la API, así que todas las llamadas usan rutas relativas.

API disponible:
- POST /api/partidas { jugador } → { id, jugador, total }
- GET /api/partidas/:id/ronda → { ronda, total, imagen, opciones }
- POST /api/partidas/:id/respuesta { opcion } → { correcta, puntos, pokemon:
  { nombre, tipos: [{ clave, nombre }], imagen }, puntaje, racha, aciertos,
  ronda, total, terminada }
- GET /api/ranking → [{ jugador, puntaje }]
- GET /api/historial → [{ jugador, puntaje, aciertos, total, fecha }]
- GET /health → "ok"

Pantallas:
1. Inicio: título "¿Quién es ese Pokémon?", campo de nombre, botón Jugar,
   y dos tableros: ranking y últimas partidas.
2. Juego: marcador (jugador, ronda, puntaje, racha), barra de progreso, la
   imagen como silueta negra (CSS filter: brightness(0)) sobre un fondo de rayos
   animado, y 4 botones de opción. Al responder: revelar la imagen con una
   transición, marcar en verde la correcta y en rojo la elegida si falló,
   mostrar el nombre y los tipos con sus colores, y un botón Siguiente.
   Atajos de teclado: 1 a 4 para responder.
3. Fin: puntaje grande, aciertos, un mensaje según el resultado y un botón
   para volver a jugar.
Además, un indicador de salud en la barra superior que consulte /health.

Requisitos:
- Mostrá todo texto que venga de la API con textContent, nunca con innerHTML.
- Estilo: modo oscuro, acentos rojo y amarillo, responsive.
- Mostrá los errores de la API en pantalla.

Servidor web:
- nginx.conf: escucha en el 8080, sirve los archivos estáticos y reenvía
  /api/ y /health a http://api:3000. Usá el DNS de Docker (resolver 127.0.0.11)
  y una variable en proxy_pass, para que nginx siga encontrando a la API si su
  contenedor se recrea.
- Dockerfile: imagen nginxinc/nginx-unprivileged:1.27-alpine y HEALTHCHECK con
  wget contra http://127.0.0.1:8080/ (no localhost: resuelve primero a IPv6 y
  nginx escucha en IPv4).

Salida: web/index.html, web/styles.css, web/app.js, web/nginx.conf y
web/Dockerfile.
Formato: un bloque de código por archivo, con la ruta como título justo antes
del bloque (por ejemplo: ### web/index.html). Nunca pongas la ruta como
comentario dentro del archivo: en JSON y en el Dockerfile rompe el build.
Sin explicaciones entre los archivos.

Actuá como revisor/a de código con foco en seguridad y operación.
Revisá esta API y este frontend:
[pegá los archivos]

Evaluá SOLO estos puntos y respondé en una tabla con: hallazgo, severidad
(alta/media/baja), archivo y línea, y cómo lo verifico con un comando o prueba.
1. ¿La respuesta correcta puede llegar al navegador antes de responder?
2. ¿Se valida la entrada (jugador, opción, id de partida)?
3. ¿Hay riesgo de inyección de HTML en el frontend?
4. ¿Qué pasa si PokeAPI está caída o tarda? ¿Y si Valkey no está?
5. ¿Se respeta el uso justo de PokeAPI (caché)?
6. ¿Las claves de Valkey tienen la expiración adecuada?
7. ¿Hay condiciones de carrera (por ejemplo, responder dos veces a la vez)?
No reescribas el código: solo el diagnóstico.

Corregí estos dos problemas en la API, sin cambiar las demás rutas ni sus
campos y sin agregar dependencias:

1. La imagen revela la respuesta. En GET /api/partidas/:id/ronda, el campo
   imagen tiene que ser una ruta de la propia API:
   /api/partidas/:id/imagen?ronda=<número de ronda>.
   Agregá GET /api/partidas/:id/imagen, que devuelve la imagen de la ronda
   pendiente con su Content-Type (image/png). La API la descarga de PokeAPI una
   sola vez y la guarda en Valkey en "pokeapi:imagen:{id}" (en base64, TTL 24 h).
   Sin ronda pendiente: 409.

2. Responder dos veces a la vez suma doble. La escritura de la respuesta tiene
   que ser atómica: usá un script Lua (EVAL) que actualice el hash de la partida
   solo si el campo pokemonId sigue siendo el de la ronda pendiente. El segundo
   pedido recibe 409.

Devolveme solo los archivos modificados y, aparte, la lista de cambios.
Formato: un bloque de código por archivo, con la ruta como título justo antes
del bloque (por ejemplo: ### api/server.js). Nunca pongas la ruta como
comentario dentro del archivo: en JSON y en el Dockerfile rompe el build.

Este es el código actual de la API y del frontend:
[pegá los archivos involucrados]

Restricciones:
- No modifiques el comportamiento de las rutas existentes ni sus campos.
- No agregues dependencias.
- La respuesta correcta no puede llegar al navegador antes de responder.
Devolveme solo los archivos modificados y, aparte, la lista de cambios.
Formato: un bloque de código por archivo, con la ruta como título justo antes
del bloque (por ejemplo: ### api/server.js). Nunca pongas la ruta como
comentario dentro del archivo: en JSON y en el Dockerfile rompe el build.

Quiero agregar:
[pegá acá una de las especificaciones]

Una pista que muestra los tipos del Pokémon antes de responder.
- POST /api/partidas/:id/pista → { tipos, costo: 30 }. Sin ronda pendiente: 409.
- Marca la ronda como "con pista" en el hash; pedirla otra vez no cobra dos veces.
- Si se acierta con pista: 100 + 20 por racha − 30. Si se falla, no descuenta nada.
- POST /respuesta suma el campo pista (true o false).
- Frontend: botón "💡 Pista" y tecla P.

Elegir la generación de Pokémon al crear la partida.
- GET /api/generaciones → [{ generacion, region, desde, hasta }], con:
  0 Todas 1-1025, 1 Kanto 1-151, 2 Johto 152-251, 3 Hoenn 252-386,
  4 Sinnoh 387-493, 5 Teselia 494-649, 6 Kalos 650-721, 7 Alola 722-809,
  8 Galar 810-905, 9 Paldea 906-1025.
- POST /api/partidas acepta "generacion" opcional (por defecto 1). Fuera de 0 a 9: 400.
  La respuesta suma el campo generacion.
- Los nombres salen de GET /pokemon-species?offset=<desde-1>&limit=<cantidad>,
  cacheados en "pokeapi:lista:gen{n}".
- El historial guarda la generación de cada partida.
- Frontend: un selector de generación en la pantalla de inicio.

Un resumen con los 10 Pokémon de la partida.
- Cada respuesta agrega al hash de la partida un elemento a "resumen" (lista JSON):
  { id, nombre, imagen, correcta, puntos, pista }.
- Frontend: en la pantalla final, una grilla con los 10 Pokémon, marcando
  aciertos y errores.

Poder retomar una partida después de recargar la página.
- GET /api/partidas/:id → { id, jugador, estado, generacion, ronda, total,
  puntaje, racha, aciertos, pendiente, resumen }, en ese orden, con resumen
  como último campo. estado vale "jugando" o "terminada", y pendiente indica
  si hay una ronda sin responder. No incluye el Pokémon de la ronda pendiente.
- Frontend: guarda el id de la partida en localStorage y, al cargar la página,
  ofrece continuarla si sigue en curso.