¿Por qué Bolt.new olvida mis decisiones de diseño?

Bolt.new olvida tus decisiones de diseño porque las restricciones que estableces en el chat son solo tokens de mensaje dentro de la misma ventana de 200K tokens de Claude que tu código, y son lo primero que se expulsa a medida que el proyecto crece. La solución es mantener las reglas de diseño en una capa de memoria persistente que se cargue en cada sesión de Bolt.

Las decisiones de diseño en Bolt no son "reglas" en ningún sentido estructurado. Son oraciones en tu historial de chat. Esa oración tiene que competir por espacio con tres cosas en cada turno:

1. Tu base de código. Bolt lee cada archivo en el proyecto en cada aviso a menos que se excluya a través de .bolt/ignore. A medida que los componentes se multiplican, la parte de la ventana que queda para el historial de chat se reduce.

2. El aviso del sistema. Las propias instrucciones de Bolt a Claude (reglas de formato, protocolos de escritura de archivos, valores predeterminados del marco) ocupan una parte fija de cada turno.

3. La cola de conversación. Los mensajes recientes se mantienen textualmente. Los mensajes más antiguos —incluyendo el donde dijiste "solo Tailwind, sin CSS-in-JS"— se truncarán tan pronto como el total acumulado se acerque al límite de 200K tokens del modelo.

No hay una "capa de reglas" separada en Bolt. Solo hay el flujo de mensajes, y los flujos de mensajes olvidan por diseño.

Cuando la restricción desaparece, la consecuencia se muestra como código:

• Desviación de pila. Bolt reintroduce una biblioteca que rechazaste explícitamente (Material UI, styled-components, Zustand) y pasas una hora sacándola.
• Componentes inconsistentes. La mitad de los botones usan tus tokens de diseño; los nuevos usan clases de Tailwind en bruto porque Bolt ya no ve el archivo de tokens en contexto.
• Regresiones de arquitectura. "Componentes del servidor solo para esta ruta" se olvida, y Bolt convierte la página en un componente del cliente en su siguiente pase.

El costo acumulativo es peor que el costo por incidente. Cada decisión revertida enseña a Bolt una versión ligeramente diferente del proyecto, y la base de código se aleja más del resumen original con cada aviso.

StackBlitz te da algunas formas de contrarrestar, pero ninguna de ellas mantiene seguras las decisiones de diseño.

Recordatorios en línea. Puedes prefijar cada aviso con "recuerda: solo Tailwind". Funciona para un turno. Luego, el prefijo en sí comienza a consumir contexto.

El espacio del aviso del sistema. Bolt te permite fijar un pequeño conjunto de instrucciones en la parte superior del chat. El espacio es corto, compartido con reglas de formato, y se reinicia por chat — no por proyecto.

`.bolt/ignore`. Excluir carpetas generadas libera espacio para el historial de chat, lo que preserva indirectamente decisiones más antiguas un poco más de tiempo. Es un buffer, no una solución.

La guía oficial de StackBlitz sobre eficiencia de tokens está documentada en el centro de ayuda de Bolt. La conclusión honesta de esos documentos: mantén los avisos ajustados, poda archivos y acepta que los proyectos de larga duración perderán estado.

Las decisiones de diseño son el tipo de contexto que necesita sobrevivir a cualquier chat individual. Son la constitución del proyecto. Mantenerlas dentro de una ventana de conversación en curso es como escribir reglas de la casa en una pizarra blanca y reiniciar la pizarra cada pocas horas.

El problema se agrava cuando traes otras herramientas. La regla de Tailwind que estableciste en Bolt no viaja a v0 cuando bifurcas una pantalla para pulir, y ciertamente no llega a Cursor cuando cambias a trabajo de backend. Cada herramienta necesita que las reglas se peguen de nuevo.

MemoryLake le da a tu proyecto una verdadera capa de reglas que vive fuera de cualquier chat individual.

• Decisiones almacenadas como memoria estructurada. Cada regla de diseño vive como una entrada nombrada en la pestaña de Memorias — "Estilo: solo Tailwind + shadcn/ui", "Estado: TanStack Query, sin Redux", "Autenticación: Supabase, nunca Firebase". No están enterradas en un registro de chat; son objetos de memoria de primera clase.
• Cargadas en cada nueva sesión de Bolt. Cuando abres un nuevo chat de Bolt, extraes las reglas actuales de MemoryLake a través de REST y las pegas como el primer mensaje. El chat comienza con la constitución del proyecto ya frente a Bolt.
• Las mismas reglas en todas las demás herramientas. La misma memoria alimenta v0, Lovable, Cursor, Claude y cualquier IA que hable REST o MCP. Cambia de herramientas a mitad de proyecto y el sistema de diseño sigue.

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

1. Crea un proyecto y carga tus reglas de diseño. Inicia sesión en MemoryLake, abre Gestión de Proyectos, haz clic en Crear Proyecto y nómbralo "Bolt — reglas del proyecto". Sube tus documentos del sistema de diseño, guías de marca y cualquier registro de decisiones arquitectónicas a través del Document Drive. Agrega cada regla no negociable como su propia entrada en la pestaña de Memorias para que sean fáciles de recuperar.
2. Genera un endpoint de servidor MCP. Abre la pestaña de Servidores MCP, haz clic en Agregar Servidor MCP, nómbralo "Reglas de diseño de Bolt" y haz clic en Generar. Copia el token Bearer — se muestra solo una vez.
3. Conectar Bolt.new. Bolt aún no tiene un cliente MCP nativo, así que usa la API REST con el token Bearer para obtener tu paquete de reglas, luego pégalo como el mensaje de apertura de cualquier nuevo chat de Bolt. Los desarrolladores pueden scriptar esto en un gancho de inicio de proyecto para que las reglas se carguen automáticamente.