¿Por qué Cursor olvida mis decisiones arquitectónicas?

Cursor olvida tus decisiones arquitectónicas porque las Reglas del Proyecto describen el comportamiento en lugar de la razón, las Memorias son resúmenes cortos derivados del chat y los ADRs en /docs solo aparecen en el aviso cuando la recuperación los trae a la superficie. El modelo predetermina arquitecturas estándar de la industria siempre que falte el contexto de decisión. La solución es exponer las decisiones como memoria consultable que Cursor lee antes de proponer la arquitectura.

Cursor indexa tu repositorio y recupera fragmentos relevantes por turno. Las decisiones arquitectónicas se escapan de ese proceso por tres razones.

1. El porqué es más difícil de recuperar que el qué. La indexación del código base saca a la luz el código bien y la prosa de manera menos confiable. Un ADR en /docs/adr/0017-single-postgres.md solo entra en el aviso cuando la recuperación lo considera relevante para la consulta actual, y "estoy añadiendo un nuevo servicio" rara vez puntúa alto un documento de decisión.

2. Las Reglas del Proyecto llevan la regla, no la razón. Una regla que dice "usar un único Postgres" es aplicable. Una regla que explica "elegimos un único Postgres porque los commits de dos fases entre servicios eran inaceptables para nuestro modelo de consistencia" no cabe en el frontmatter de .mdc, por lo que la razón se pierde, y el modelo lucha contra la regla cada vez que la tarea superficial parece requerir una segunda base de datos.

3. Las Memorias son resúmenes, no registros de decisiones. Las Memorias de Cursor generan automáticamente reglas cortas a partir del chat. No son un registro de decisiones. El razonamiento que informó una elección arquitectónica, las compensaciones consideradas, las restricciones que importaron, no sobreviven como Memoria estructurada.

El resultado: Cursor sigue decisiones cuando están en contexto y las anula cuando no lo están.

Cada decisión olvidada te cuesta un nuevo argumento y a veces una reimplementación, y el costo se acumula a lo largo de la vida de un servicio:

• Debates resueltos se reabren. "Elegimos Postgres sobre Mongo por las consultas JSONB y la integridad transaccional" se vuelve invisible, y Cursor sugiere Mongo nuevamente tres meses después.
• Se violan restricciones. "No llamamos a servicios internos desde funciones de borde debido al presupuesto de inicio en frío" se ignora en un controlador de borde generado.
• Los nuevos servicios se desvían del estándar. Cursor busca el patrón más común en la web para nuevos servicios, no el que tu equipo de plataforma estandarizó.

La solución no es "hacer que cada ADR también sea una regla .mdc". Eso inunda la carpeta de reglas con prosa que nadie mantiene. La solución es exponer decisiones como memoria consultable con su razonamiento intacto.

Cursor ha lanzado características reales aquí. Ninguna de ellas cierra completamente la brecha.

*Reglas del Proyecto (`.cursor/rules/.mdc)** pueden codificar la regla de un ADR, con frontmatter y globs para controlar cuándo se activa. Son buenas para la conclusión aplicable. Son débiles en el razonamiento, ya que las reglas alwaysApply` comparten el presupuesto del aviso y la prosa de reglas más largas se recorta.

Memorias capturan orientación corta y autogenerada del chat. Son buenas para "usamos Zod para validación en tiempo de ejecución" y malas para "elegimos Zod sobre Yup en 2024 por la inferencia de tipo estático, y revisamos esta decisión trimestralmente."

Soporte nativo de MCP permite a Cursor conectarse a memoria externa a través de .cursor/mcp.json o la interfaz de usuario de Configuración. Este es el camino más limpio para decisiones arquitectónicas, porque MCP puede exponer el ADR completo con razonamiento bajo demanda en lugar de comprimirlo en una regla.

Puedes leer la propia guía de configuración de MCP de Cursor en la documentación oficial de Cursor.

Para repositorios pequeños, las Reglas y la indexación lo manejan. Para sistemas con una arquitectura real, las decisiones se escapan.

El problema más profundo es que las decisiones arquitectónicas son artefactos de razonamiento, no reglas. Necesitan ser recuperables en su totalidad, con su porqué, sus alternativas y su fecha, en el momento en que Cursor propone algo que las violaría. También necesitan aplicarse a través de cada editor de IA que use el equipo, ya que un compañero en Claude Code puede reintroducir el patrón que pasaste un sprint eliminando.

Eso es lo que una capa de memoria cruzada de herramientas soluciona: un registro de decisión, recuperable bajo demanda, compartido entre cada editor de IA en el equipo.

MemoryLake es una capa de memoria cruzada que se sitúa entre tú y cada IA que usas. En lugar de confiar en que los ADRs en /docs serán recuperados cuando importen, almacenas decisiones en un Proyecto de MemoryLake, y Cursor extrae la relevante por turno a través de MCP.

• Decisiones como memoria consultable. Cada ADR vive como una Memoria estructurada con regla, razonamiento, alternativas y fecha. Cursor recupera el registro completo, no una línea comprimida.
• Control de versiones estilo Git sobre decisiones. Cuando un ADR es reemplazado, el control de versiones de MemoryLake rastrea la supersesión, por lo que las decisiones antiguas no pueden resurgir silenciosamente.
• Portátil a cualquier otra herramienta de codificación de IA. La misma memoria de decisión funciona en Claude Code, Cline, Windsurf y cualquier editor compatible con MCP. Un compañero en una herramienta diferente no puede reintroducir un patrón obsoleto por error.

MemoryLake obtuvo un 94.03% en el benchmark de contexto largo de LoCoMo, el mejor resultado publicado hasta 2026, con recuperación en milisegundos y cifrado de extremo a extremo AES-256.

1. Crea un proyecto y carga tus decisiones. Inicia sesión en MemoryLake, abre Gestión de Proyectos, haz clic en Crear Proyecto y nómbralo según el sistema (por ejemplo, "Cursor - arquitectura de plataforma de pagos"). Coloca tus ADRs y documentos de diseño en el Document Drive. Captura las conclusiones y razonamientos principales como entradas estructuradas en la pestaña de Memorias para que cada decisión sea recuperable por tema, con el porqué intacto.
2. Genera un endpoint de servidor MCP. Abre la pestaña de Servidores MCP dentro de tu proyecto, haz clic en Agregar Servidor MCP, nómbralo "integración de Cursor" y haz clic en Generar. MemoryLake devuelve un ID de clave API, secreto y URL de endpoint. Copia el secreto de inmediato, ya que solo se muestra una vez.
3. Conecta Cursor. Cursor ha tenido soporte nativo de MCP desde 2025, lo que hace que este sea el camino más limpio. Agrega una entrada de servidor MemoryLake a .cursor/mcp.json en la raíz del repositorio (o conéctalo a través de Configuración de Cursor > Funciones > MCP), pega la URL del endpoint y el token Bearer, y recarga Cursor. Ahora Cursor puede consultar el registro de decisiones antes de proponer arquitectura o conectar un nuevo servicio.