¿Por qué Cursor olvida mis convenciones de casa?

Cursor olvida tus convenciones de casa porque las convenciones viven como conocimiento tácito del equipo que los archivos de Reglas no pueden capturar completamente, las Memorias se generan automáticamente por espacio de trabajo y no se comparten con los compañeros de equipo, y el modelo recurre a los valores predeterminados promedio de internet cada vez que la guía de convenciones pierde peso en el aviso. La solución es una memoria de convenciones compartida y consultable de la que lee cada Cursor de los compañeros de equipo.

Las Reglas y Memorias de Proyecto de Cursor intentan capturar las normas por equipo. La mecánica aún se pierde la mitad no escrita.

1. Las convenciones son tácitas. La mayor parte de lo que hace que el estilo de casa sea "casa" no está escrito. Vive en comentarios de revisión de código, hilos de Slack y las elecciones implícitas que hacen los ingenieros senior. Los archivos de Reglas capturan la fracción explícita; el resto solo aparece cuando un revisor senior lo detecta en una PR.

2. Las Memorias son por espacio de trabajo, por desarrollador. La función de Memorias de Cursor está limitada al espacio de trabajo y se construye a partir del historial de chat. Las convenciones que enseñaste a Cursor en tu máquina no son las convenciones que ve el Cursor de tu compañero de equipo. Los nuevos empleados obtienen un Cursor que no ha aprendido nada sobre tu equipo aún.

3. Los valores predeterminados de internet son ruidosos. Cuando la guía de convenciones en el aviso pierde peso, el modelo recurre a los patrones dominantes que vio en el entrenamiento, que son los patrones de cada repositorio público de React/Node en internet. Tu estilo de casa no tiene ninguna oportunidad contra esa señal a menos que se recupere activamente.

El resultado: Cursor refleja internet en tareas frías y a tu equipo solo cuando ha sido recordado recientemente.

Cada error de estilo de casa te cuesta ciclos de revisión, y la pérdida se acumula entre contrataciones y compañeros de equipo:

• Los nuevos empleados obtienen código promedio. Tu Cursor conoce tus convenciones; el Cursor de tu nuevo empleado no, por lo que sus primeras PR parecen React de internet en lugar de tu base de código.
• La revisión de código vuelve a enseñar las mismas lecciones. "Envuelve las solicitudes en nuestro useApi hook, no en SWR crudo" se convierte en un comentario que dejas cuatro veces a la semana en lugar de una regla que la IA aplica.
• La deriva de estilo se acumula. Cada archivo generado que omite una pequeña convención añade una pequeña inconsistencia, y después de un trimestre la base de código se ha desviado mediblemente hacia los valores predeterminados del modelo.

La solución no es "escribir una guía de estilo más larga". Es hacer que las convenciones del equipo sean una memoria consultable de la que lee automáticamente cada Cursor de los compañeros de equipo.

Cursor ha lanzado características reales aquí. Cada una ayuda. Ninguna de ellas cierra la brecha.

*Reglas de Proyecto (`.cursor/rules/.mdc)** capturan convenciones explícitas por proyecto, con frontmatter, globs y alwaysApply` para el alcance. Son buenas para las reglas que ya has articulado. Son débiles en las tácitas que nadie ha escrito aún, y comparten presupuesto de aviso con el código.

Memorias generan automáticamente reglas cortas a partir del historial de chat y las limitan al proyecto. Son útiles como base, pero son resúmenes de lo que Cursor inferió que querías, no un contrato compartido del equipo, y viven por espacio de trabajo en una máquina.

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 convenciones compartidas a nivel de equipo, porque MCP devuelve contexto bajo demanda desde una única fuente de verdad.

Puedes leer el propio desglose de Cursor sobre Reglas y Memorias en la documentación oficial de Cursor.

Para proyectos en solitario, los nativos están bien. Para equipos, se fragmentan.

El problema más profundo es que las convenciones de casa son un artefacto del equipo, no un individuo. Evolucionan en la revisión de código, se aclaran en retrospectivas y necesitan aplicarse de manera consistente en el editor de cada compañero de equipo. Un archivo .cursor/rules/*.mdc en el repositorio ayuda, pero no puede capturar decisiones tomadas ayer en un comentario de PR, y no puede ser leído por Claude Code, Cline o Windsurf si un compañero usa uno de esos en lugar de Cursor.

Eso es lo que una capa de memoria entre herramientas soluciona: un almacén de convenciones del equipo, alimentado por revisiones y decisiones, recuperado bajo demanda por cada editor de IA en el equipo.

MemoryLake es una capa de memoria entre modelos que se sitúa entre tú y cada IA que usas. En lugar de depender de Reglas y Memorias que viven por espacio de trabajo, tu equipo coloca convenciones en un Proyecto de MemoryLake compartido, y cada Cursor de los compañeros de equipo lee de ese Proyecto a través de MCP.

• Memoria compartida del equipo. Las convenciones se almacenan una vez y son accesibles para el editor de cada compañero de equipo, por lo que una regla aclarada en una PR se aplica en el siguiente archivo generado por IA en la máquina de otra persona.
• Conocimiento tácito hecho explícito. Captura comentarios de revisión ("envolvemos las solicitudes en useApi, no en SWR crudo") como Memorias estructuradas en el momento en que surgen, y se aplican a partir de entonces.
• Portátil a cualquier otra herramienta de codificación de IA. La misma memoria de convenciones funciona en Claude Code, Cline, Windsurf y cualquier editor compatible con MCP. Los nuevos empleados obtienen las convenciones del equipo desde el primer día, independientemente de qué herramienta usen.

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 de equipo y carga tus convenciones. Inicia sesión en MemoryLake, abre Gestión de Proyectos, haz clic en Crear Proyecto y nómbralo según el repositorio y el equipo (por ejemplo, "Cursor - estilo de casa del equipo web"). Coloca tu guía de estilo, ADRs y algunos archivos de referencia canónicos en el Document Drive. Captura convenciones tácitas ("usamos useApi, no en SWR crudo", "las migraciones viven en db/migrations/<YYYYMMDD>/") en la pestaña de Memorias para que sean recuperables por tema.
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 inmediatamente, ya que solo se muestra una vez. Comparte el endpoint con el equipo; cada compañero usa su propio token Bearer.
3. Conecta Cursor. Cursor ha tenido soporte nativo de MCP desde 2025, lo que hace que este sea el camino más limpio. Cada compañero añade una entrada de servidor MemoryLake a .cursor/mcp.json en la raíz del repositorio (o lo conecta a través de Configuración de Cursor > Características > MCP) con su endpoint y token Bearer, y luego recarga Cursor. Las convenciones de casa ahora se cargan bajo demanda en el editor de cada compañero de equipo.