Cuando Claude usa la versión antigua

Qué es y por qué importa

Le pides a Claude una función nueva, la escribe muy seguro, y la app ya no arranca. Miras el error y descubres que ha usado una opción que en la versión instalada de la librería ya no existe, o un archivo con su nombre antiguo. El código parecía correcto. Y lo era, para la librería de hace unos meses.

Para eso sirve stalemap. Mira las versiones de las librerías de tu proyecto, encuentra qué ha cambiado después de la fecha hasta la que Claude aprendió y se lo da en una lista corta antes de empezar. Luego, después de cada cambio, revisa el código: si Claude ha usado algo antiguo, le dice qué usar ahora.

Es para quien construye con Claude Code una app en JavaScript o TypeScript, con librerías que cambian a menudo. Una cosa desde el principio: no es de Anthropic. Es un proyecto open source de la comunidad, con licencia MIT, creado el 19 de octubre de 2026. Es joven y lo mantiene una sola persona: tómalo como una ayuda extra, no como una garantía.

1. Por qué Claude escribe código antiguo

Un modelo como Claude aprende de una montaña de textos y código recogidos hasta una fecha concreta. Esa fecha se llama fecha de corte del entrenamiento, en inglés training cutoff. Lo que pasa después, Claude no lo sabe.

Las librerías, en cambio, no se detienen. Sale la última versión, una opción desaparece, una función cambia de nombre, un archivo pasa a llamarse de otra forma. Claude no lo sabe y usa los nombres que vio mil veces cuando aprendía. El README de stalemap pone tres ejemplos:

• maxSteps, una opción de streamText en el AI SDK, que las versiones nuevas ya no aceptan.
• required_error, una opción de zod que las versiones nuevas han cambiado.
• middleware.ts en Next.js, que en las versiones nuevas se llama proxy.ts.

stalemap hace una cuenta sencilla. Lee qué modelo estás usando y encuentra su fecha de corte. Para cada librería que importa tu código, estima qué versión conocía el modelo: la más reciente publicada al menos 30 días antes de esa fecha. Luego la compara con la versión que tienes instalada de verdad, mirando los tipos de la librería y sus notas de versión, es decir, la lista de novedades que publica quien la mantiene. Lo que ha cambiado entre medias se convierte en una nota.

2. Instálalo en Claude Code

Necesitas Node.js 20 o posterior y un proyecto JavaScript o TypeScript con un package.json. Luego, dentro de una sesión de Claude Code, escribe dos comandos:

/plugin marketplace add Umair/stalemap
/plugin install stalemap@stalemap

1. El primero añade el marketplace de stalemap, es decir, el catálogo del que Claude Code saca el plugin. Lo haces una sola vez.
2. El segundo no instala enseguida: abre el panel /plugin en la ficha del plugin, donde eliges dónde activarlo, por ejemplo solo para ti o para todo el proyecto.
3. Antes de confirmar, lee la ficha. Un plugin puede ejecutar comandos y un servidor MCP en tu ordenador: conviene saber qué instalas.
4. Para desactivarlo o quitarlo más adelante, abre /plugin y ve a la pestaña Installed.

El plugin añade dos hooks, es decir, comandos que Claude Code lanza solo en un momento concreto: uno al empezar la sesión y otro después de cada cambio. Además, un servidor MCP, con el que Claude puede buscar los cambios de una librería con sus propias palabras, y dos skills. Los vemos uno a uno.

3. Qué ve Claude al empezar la sesión

Cuando abres una sesión, stalemap pone en el contexto de Claude las notas sobre las librerías que han cambiado, calculadas para el modelo de esa sesión. Lo repite después de /clear y después de la compactación, cuando Claude Code resume una conversación larga. No escribe ningún archivo: las notas solo viven en la sesión.

Las notas son una lista corta y ordenada. Primero van los cambios que tocan lo que tu proyecto usa de verdad: las funciones que importas, las opciones de configuración, los nombres de los archivos. Cada nota dice qué se ha quitado o renombrado y qué usar en su lugar.

Si quieres las notas en el CLAUDE.md

Con la skill /stalemap:sync las notas también acaban en el CLAUDE.md o en el AGENTS.md, el archivo con las reglas del proyecto. Así se quedan en el repositorio y las ve quien trabaja contigo. El bloque está entre dos marcas, <!-- stalemap:start --> y <!-- stalemap:end -->, y el resto del archivo no lo toca.

Un detalle: Claude Code lee el CLAUDE.md, no el AGENTS.md. Si tus notas están en el AGENTS.md, añade al CLAUDE.md la línea @AGENTS.md.

4. La revisión después de cada cambio

Cada vez que Claude escribe o modifica un archivo, se lanza el segundo hook, el guardián. Ejecuta la comprobación de tipos de tu proyecto, es decir, tsc, el compilador de TypeScript, y le cuenta a Claude lo que encuentra, en este orden:

1. Los errores que vienen de una librería que cambió después de la fecha de corte, con la nota que dice cómo corregirlos.
2. Lo que todavía compila pero ha cambiado: claves de configuración y miembros movidos, archivos renombrados, como middleware.ts que pasó a ser proxy.ts.
3. Los demás errores del compilador, en el archivo modificado y en los que lo usan. Estos no dicen que una librería haya cambiado: son errores normales.

Así Claude ve el error y la corrección enseguida, mientras trabaja, en lugar de descubrirlo tú al abrir la app. Un límite que conviene saber: el código antiguo que todavía compila, el guardián solo lo encuentra en parte. El resto lo detecta solo si hay una nota que hable de ello.

Antes de actualizar una librería

El plugin también tiene una skill, upgrade, que le dice a Claude que busque los cambios de un paquete antes de usarlo o actualizarlo. Yo se lo pido así:

Quiero actualizar [nombre de la librería] a la última versión. Antes de tocar el código, usa stalemap para buscar qué ha cambiado en esta librería: funciones eliminadas o renombradas, opciones nuevas obligatorias, archivos con un nombre nuevo.
Luego hazme una lista de los puntos de mi proyecto que hay que cambiar, con el nombre del archivo de cada uno.
No modifiques nada hasta que te diga ok.

Y cuando la actualización está hecha:

He actualizado [nombre de la librería]. Lanza la comprobación de tipos y los tests, y dime qué se ha roto y por qué. Corrige una cosa cada vez.

5. Desde el terminal y en las comprobaciones automáticas

stalemap también se usa sin el plugin, desde el terminal, en la carpeta del proyecto:

• npx stalemap: una vista previa. Te muestra qué ha cambiado y el bloque que escribiría.
• npx stalemap sync: escribe el bloque en el CLAUDE.md o en el AGENTS.md.
• npx stalemap check: comprueba que el bloque está y está al día.

check está pensado para la CI, es decir, las comprobaciones automáticas que se ejecutan en cada push, por ejemplo con GitHub Actions. Si el bloque falta o está desactualizado, termina con un error y la comprobación falla. Así, si alguien actualiza una librería y se olvida de las notas, te enteras enseguida. En el README también hay una GitHub Action lista para usar.

Recuerda que las notas ocupan espacio en el contexto de Claude, es decir, tokens de más en cada sesión. Por defecto stalemap las mantiene en unos 1.800 tokens y pone primero las que tienen que ver con el código que usas.

6. Qué sale de tu ordenador

Es la parte que yo revisaría primero, así que te la explico claro. En el uso básico:

• Tu código no sale nunca. Qué librerías importas lo mira en tu propio ordenador.
• Solo salen nombres y versiones de los paquetes: van al registro de npm, a GitHub para las notas de versión y a models.dev para las fechas de corte de los modelos.
• No hace falta una clave API, y stalemap no tiene servidor propio ni recoge telemetría.

Luego hay tres opciones, --llm, --guides y --examples, que hacen que Claude escriba resúmenes, notas sacadas de las guías de actualización y ejemplos de antes y después. Con ellas, a Claude le llegan las diferencias de tipos, fragmentos de las notas de versión y los nombres de las funciones que importas. Tu código no. Pero gastan tokens: úsalas cuando las necesites, no por costumbre.

Errores comunes

• Instalarlo en un proyecto Flutter, Python o Swift. Solo funciona con JavaScript y TypeScript.
• Confirmar la instalación sin leer la ficha del plugin. Ejecuta comandos en tu ordenador: mira antes qué hace.
• Pensar que sustituye a los tests. Las notas ayudan, pero a veces Claude las ignora. Los tests y la comprobación de tipos siguen siendo tu red de seguridad.
• Usarlo en un monorepo con varios package.json. Por ahora solo lee uno, sin workspaces.
• Activar --llm, --guides o --examples en cada ejecución. Envían datos a Claude y gastan tokens.

Lista de comprobación

• El proyecto es JavaScript o TypeScript, con un solo package.json
• Tengo Node.js 20 o posterior
• He leído la ficha del plugin antes de instalarlo
• He lanzado los dos comandos en Claude Code
• He mirado las notas con npx stalemap
• Si quiero las notas en el repositorio, he lanzado /stalemap:sync
• En la CI está npx stalemap check
• Uso --llm, --guides y --examples solo cuando hacen falta

Preguntas frecuentes