Lovable now reads the rules in every folder.

One rules file per folder

On November 3, Lovable started following the AGENTS.md and CLAUDE.md files in a project's subfolders. Per the announcement, when it opens or edits a file it reads the instruction files in that file's folder and in every folder above it.

The memory docs explain where those files come from. Lovable records technical decisions as short rules in a root AGENTS.md, and once that file grows it moves the rules for one part of the app into a second AGENTS.md beside that part. The files belong to you: you edit them in the code editor and they sync to GitHub like everything else.

Dreaming, or memory that cleans itself

Dreaming arrived on November 4, on paid plans and at no credit cost. In the background, Lovable checks what it remembers about the project and the rules in its AGENTS.md files against the code and the chat, then rewrites whatever changed and drops whatever no longer applies or shows up twice.

The line that matters for design is in the docs: a rule you asked for stays as written, even when the code doesn't follow it yet. Next time Lovable touches that code, it flags the mismatch and asks whether to keep the rule or change the code. Approaches you ruled out stay too.

• Edits to AGENTS.md files show up in the chat and in version history as Lovable tidied up its notes, with a button to see the diff.
• Whatever Dreaming removes from memory is gone from the Memory settings page, which only shows what Lovable remembers now.
• It doesn't run on projects with Git sync, with EU inference, or with project memory set to Nothing.

Who wrote the rule decides how generic it gets

Here is how I'd read it: Dreaming brings the notes in line with the code. If the code is already full of the model's defaults, anything inferred from it will drift toward that average. A rule nobody asked for has nobody to defend it.

A rule you asked for explicitly, on the other hand, stays put and turns into a check: if the code wanders off, Lovable says so. That makes the output less generic, but only when the decision exists first. It's the same idea as Figma and Lovable keeping what you already decided, with one new twist: the rule can now live next to the code that uses it.

An AGENTS.md for your components

Create src/components/AGENTS.md in Lovable's code editor and swap in your own values. Each line maps to a signal the Slop Score flags under that name, so you can check afterwards whether it stuck.

# Design rules (set by the team, ask before changing)

- Corners: 6px on inputs and chips, 12px on cards and images,
  pills only on buttons. No rounded-2xl on everything.
  ("Rounded corners on everything")
- No blur-3xl color blobs behind the headline. ("Blurry color blobs")
- No "New:" pill above the H1. ("A New pill above the headline")
- At most one small label above a heading per page.
  ("Labels above every heading")
- No grids of three identical cards with an icon. ("The same card grid, again")
- Primary color #1E3A2F; no purple-to-blue gradients.
  ("Purple-to-blue gradients")

Then, in the chat: "Remember that I set the rules in src/components/AGENTS.md myself." That way Lovable knows they are requested rules, not notes Dreaming is free to rewrite. For a fuller starting brief, see the prompt guide; for picking corner values, see radii with a hierarchy.

What to do this week

• Open your project's history and look for Lovable tidied up its notes. Check the diff, and if it dropped something you wanted, ask for it again in the chat.
• Read the root AGENTS.md. If it has no design rules at all, that doesn't mean nothing was decided. It means the model is deciding.
• Run the Slop Score before and after writing the rules, and see whether the signals you named go away.