Lovable ahora lee las reglas de cada carpeta.

Reglas por carpeta, no un solo archivo

El 3 de noviembre, Lovable empezó a seguir los archivos AGENTS.md y CLAUDE.md de las subcarpetas del proyecto. Según el anuncio, cuando abre o edita un archivo lee los archivos de instrucciones de su carpeta y de todas las carpetas de arriba.

La documentación de memoria explica de dónde salen esos archivos: Lovable escribe sus decisiones técnicas como reglas cortas en un AGENTS.md en la raíz, y cuando ese archivo crece mueve las reglas de una parte de la app a un segundo AGENTS.md junto a esa parte. Los archivos son tuyos: se editan en el editor de código y viajan a GitHub con el resto.

Dreaming: la memoria se ordena sola

El 4 de noviembre llegó Dreaming, en los planes pagos y sin gastar créditos. En segundo plano, Lovable compara lo que recuerda del proyecto y las reglas de sus AGENTS.md con el código y el chat, y reescribe lo que cambió y borra lo que ya no aplica o está repetido.

La frase que importa para el diseño está en la documentación: una regla que tú pediste queda como la escribiste, aunque el código todavía no la cumpla. Cuando Lovable vuelva a tocar ese código, va a señalar la diferencia y preguntar si cambia la regla o el código. Lo mismo vale para los caminos que descartaste.

• Los cambios en los AGENTS.md aparecen en el chat y en el historial como Lovable tidied up its notes, con un botón para ver el diff.
• Lo que Dreaming borra de la memoria no se ve en los ajustes de memoria: la pantalla muestra solo lo que recuerda ahora.
• No corre en proyectos con Git sync, con inferencia en la UE ni con la memoria del proyecto en Nothing.

Más genérico o menos, según quién escriba la regla

Prefiero leerlo así: Dreaming alinea las notas con el código. Si el código ya está lleno de los valores por defecto del modelo, lo que se infirió de él se va a parecer a ese promedio. Una regla que nadie pidió no tiene a quién defender.

En cambio, una regla pedida de forma explícita queda firme y, además, se vuelve un control: si el código se aleja, Lovable avisa. Eso hace la salida menos genérica, pero solo si la decisión existe antes. Es la misma idea de Figma y Lovable cuidando lo que ya decidiste, con un detalle nuevo: ahora puedes ponerla junto al código que la usa.

Un AGENTS.md para tus componentes

Crea src/components/AGENTS.md en el editor de código de Lovable y adapta los valores. Cada línea apunta a una señal que el Slop Score marca con ese nombre, para que puedas comprobar después si se cumplió.

# Reglas de diseño (pedidas por el equipo, no cambiar sin preguntar)

- Esquinas: 6px en campos y chips, 12px en tarjetas e imágenes,
  pastilla solo en botones. Nada de rounded-2xl en todo. ("Las mismas esquinas redondeadas")
- Sin manchas de color con blur-3xl detrás del título.
  ("Manchas de color difuminadas")
- Sin pastilla "Nuevo:" sobre el H1. ("Pastilla de novedad en el hero")
- Etiquetas sobre los títulos: como máximo una por página.
  ("Etiquetas sobre cada título")
- Nada de grillas de tres tarjetas iguales con ícono.
  ("Grillas de tarjetas iguales")
- Color principal #1E3A2F; ningún degradé de violeta a azul.
  ("Degradés de violeta a azul o rosa")

Después, en el chat: "Recuerda que las reglas de src/components/AGENTS.md las pedí yo". Así Lovable sabe que son reglas pedidas y no notas que Dreaming puede reescribir. Si quieres un brief más completo para el arranque, está en la guía de prompts; y para elegir los valores de las esquinas, en radios con jerarquía.

Qué hacer esta semana

• Abre el historial de tu proyecto y busca Lovable tidied up its notes. Mira el diff: si quitó algo que querías, pídelo de nuevo en el chat.
• Lee el AGENTS.md de la raíz. Si no hay ninguna regla de diseño, no es que no haya decisiones: las está tomando el modelo.
• Mide la web con el Slop Score antes y después de escribir las reglas, y fíjate si bajan las señales que nombraste.