¿Por qué Cursor olvida mi estructura de archivos?

Cursor olvida tu estructura de archivos porque su indexación de la base de código es aproximada, no autoritativa: el modelo ve fragmentos recuperados, no el árbol de directorios completo, y los archivos de Reglas no codifican completamente las convenciones de carpetas. Una vez que una sesión crece, la guía estructural pierde peso frente al código reciente en el aviso, por lo que Cursor vuelve a los valores predeterminados genéricos de React/Node. La solución es exponer tu estructura real como memoria consultable.

Cursor indexa tu base de código y utiliza la recuperación para alimentar fragmentos relevantes en el aviso. Tres realidades de ese pipeline explican la deriva de la estructura.

1. El modelo ve fragmentos, no un árbol. La indexación de la base de código devuelve contenidos de archivos relevantes, no un mapa completo de directorios. El modelo generalmente puede adivinar tu estructura a partir de lo que ha visto, pero para una carpeta que no ha tocado en esta sesión, vuelve a los valores predeterminados.

2. Las Reglas describen comportamiento, no topología. Las Reglas del proyecto (.cursor/rules/*.mdc) son buenas para "usar Zustand para el estado global" y malas para "los componentes viven en src/features/<feature>/components/, hooks en la misma carpeta, pruebas con sufijo .test.tsx." Codificar la topología en prosa es frágil y compite con el código por el presupuesto del aviso.

3. El contexto es desalojado bajo carga. Una vez que una sesión carga muchos archivos, el contexto de trabajo efectivo del modelo disminuye, y las pistas estructurales anteriores pierden peso. Los usuarios de Cursor informan rutinariamente sobre la deriva en la colocación de archivos en refactorizaciones más grandes por esta razón.

El resultado: Cursor coloca archivos correctamente cuando el código circundante hace que la convención sea obvia, y deriva hacia valores predeterminados genéricos cuando no lo es.

Cada archivo mal colocado te cuesta un ciclo de mover y arreglar, y el costo se acumula en una base de código:

• Los archivos aterrizan en la carpeta equivocada. Un nuevo hook se coloca en src/hooks/ en lugar de al lado de su componente, rompiendo tu convención de colocación.
• Las importaciones apuntan a rutas ficticias. Cursor inventa @/lib/dateUtils porque el alias y el nombre de la carpeta suenan bien, a pesar de que tu utilidad real vive en @/utils/date/format.ts.
• Los archivos de prueba terminan huérfanos. Mantienes .test.tsx junto al código fuente; Cursor crea __tests__/ porque ese es el valor predeterminado que ha visto con más frecuencia.

La solución no es "escribir un README más largo." Cursor no siempre lo cargará. La solución es exponer tu estructura como memoria consultable que Cursor pueda consultar antes de escribir un nuevo archivo.

Cursor ha lanzado algunas características que tocan esto. Ninguna de ellas cierra la brecha.

La indexación de la base de código potencia la recuperación y le da a Cursor un sentido de trabajo de dónde viven las cosas. Mejora con la familiaridad y se degrada en partes frías del repositorio. Es aproximada por diseño, ya que el modelo nunca ve el árbol completo a la vez.

*Las Reglas del proyecto (`.cursor/rules/.mdc`)** te permiten declarar reglas de topología en prosa con globs de archivos. Ayudan, pero las convenciones de carpetas son difíciles de expresar en reglas, y las reglas comparten el presupuesto del aviso con todo lo demás.

Soporte nativo de MCP permite que Cursor hable con servidores externos a través de .cursor/mcp.json o la interfaz de usuario de Configuración. Este es el camino más limpio para exponer datos de directorios y convenciones en vivo, porque MCP los devuelve bajo demanda en lugar de introducirlos en el aviso.

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

Para repositorios pequeños, la indexación y las Reglas son suficientes. Para bases de código reales y en capas, la estructura deriva.

El problema más profundo es que la estructura de archivos es un contrato, no una descripción. El equipo acordó que las características viven en src/features/<feature>/, que los hooks se colocan juntos, que los tipos van en un hermano types.ts. Ese contrato necesita ser consultable, no solo estar presente en un README o distribuido en treinta archivos de reglas. Y el mismo contrato necesita aplicarse cuando un compañero edita el mismo repositorio en Claude Code, Cline o Windsurf.

Eso es lo que una capa de memoria entre herramientas soluciona: una memoria estructural, recuperable bajo demanda, compartida entre cada editor de IA.

MemoryLake es una capa de memoria entre modelos que se sitúa entre tú y cada IA que usas. En lugar de depender solo de las Reglas y la indexación de la base de código, almacenas tu contrato estructural en un Proyecto de MemoryLake, y Cursor recupera la porción correcta por edición a través de MCP.

• Topología como memoria consultable. Las convenciones de carpetas, patrones de nombres y mapas de alias de importación viven como Memorias estructuradas que Cursor puede leer bajo demanda, en lugar de ser prosa introducida en un archivo de reglas.
• 10,000x más contexto que la solicitud en bruto. El motor de recuperación de MemoryLake lee de miles de millones de decisiones de tokens de repositorio y presenta solo la porción estructural relevante para el archivo actual. Dejas de competir con el código por el presupuesto del aviso.
• Portable a todas las demás herramientas de codificación de IA. La misma memoria estructural funciona en Claude Code, Cline, Windsurf y cualquier editor que reconozca MCP. Cuando un compañero usa una herramienta diferente, el contrato se mantiene.

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 tu estructura. Inicia sesión en MemoryLake, abre la Gestión de Proyectos, haz clic en Crear Proyecto y nómbralo según el repositorio (por ejemplo, "Cursor - estructura de aplicación web"). Coloca tu mapa de carpetas, configuración de alias y una muestra canónica de características en el Document Drive. Captura el contrato ("las características viven en src/features/<feature>/, los hooks se colocan juntos, las pruebas usan .test.tsx") en la pestaña de Memorias.
2. Genera un endpoint del 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.
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 del servidor MemoryLake a .cursor/mcp.json en la raíz del repositorio (o conéctalo a través de Configuración de Cursor > Características > MCP), pega la URL del endpoint y el token Bearer, y recarga Cursor. Cursor ahora puede consultar tu memoria estructural antes de escribir o mover cualquier archivo.