Memory

Memory is what the agent knows about your project from one session to the next: the rules it must follow, the decisions your team already made and the concerns left for later review.

Without it, every conversation with the agent would start from scratch. The agent could propose something you already ruled out, or break something the team agreed on.

Tabs

Rules and decisions have the filters Active, Needs review and Obsolete. Concerns have Open and Resolved.

The agent tag marks what's sent to the agent. agent, on edit marks items that apply only to certain files and arrive right before the agent edits one of them.

Rule or decision?

• A rule is an instruction that always applies, in any part of the work: "never delete another account's tokens", "auth lives in Supabase". It goes to the agent in every session, and to any subagents it starts.
• A decision is a choice made at a point in time, with the reason: "Inter as the text font because the system font looked bad". It matters when the work touches that topic.

If a decision has turned into something that should always apply, make it a rule: faundr memory-edit "<part of the title>" --rule.

When each one reaches the agent

Space at the start of a session is limited, so Faundr delivers each item when it's needed:

All of this runs on your computer, with no AI and no internet: Faundr keeps a copy of the memory in .faundr/painel/memory.json at the start of each session.

Create from the dashboard

Use New rule, New decision or New concern. In the rule or decision form:

• Title: the rule in one sentence.
• Details and why: the context. A rule with a reason gets followed with better judgment.
• Only applies to these files: one path per line. It can be a folder (src/server), a file or a pattern with * and **. With files set, the rule reaches the agent only when it's about to edit one of them, so it doesn't take up space in every session.
• Keep as proposed: the rule is saved, but it isn't sent to the agent until someone clicks Confirm. Use it when you want to discuss with the team first.

Create from the agent

/faundr:rule Every server route checks project access, in src/routes/api
/faundr:decision Payments through Stripe because it supports Pix
/faundr:concern Login might get slow — review once we have more users

The agent also records things on its own:

• Decisions while it works. A new decision is linked to the files the session edited (when there are only a few), so it shows up the next time someone touches them. If it looks like an existing decision, Faundr flags it, and the agent can retire the old one.
• Rules you state in the chat. Phrases like "from now on…", "never…" or "be careful with…" make Faundr suggest that the agent record a team rule. That way the rule doesn't live only in that one conversation.

Change a decision

When a decision replaces another, the old one becomes obsolete and the two are linked ("replaces"). From the agent:

faundr decision "Geist font instead of Inter" --why "more readable" --replaces "Inter as the font"
faundr memory-edit "<id or part of the title>" --obsolete
faundr memory-edit "<id or part of the title>" --file "src/styles.css"
faundr memory-edit "<id or part of the title>" --global

You can find the ids with faundr board --memory.

Rules the code itself can check

Some rules forbid something you can find in the code's text, like "don't use console.log" or "don't use the axios library". For these, the rule can carry a forbidden pattern. With it:

• Faundr warns the agent before an edit that introduces the pattern;
• the quality check points out where the pattern already exists in the code.

Ask the agent, for example: /faundr:rule Don't use axios, use the fetch client in src/lib/api.ts. It builds the pattern itself.

For rules that can't be checked from the text, use /faundr:memory-check. The agent reads the code looking for contradictions with your rules and decisions and records each one as a concern, with the file and what to do. It also tidies the memory: it proposes linking decisions to files, merging duplicates, retiring superseded ones and turning into rules whatever should always apply. It only changes things with your OK.

Item details

Click an item to open the side panel. From there you can:

• Confirm a proposal;
• Edit the text and files;
• Link it to another item with a relationship (implements, depends on, justifies, affects, replaces, is part of…);
• Mark as obsolete when the rule no longer applies, or Reactivate it;
• Delete it.

The detail also shows the confidence (explicit, when someone said it; inferred, when the agent deduced it; ambiguous) and the source.

On a concern, the detail has Mark as resolved, Reopen and the command to resolve it through the agent (/faundr:resolve P-n).

Best practices

• Keep rules short and checkable. "Use the Button component from src/components/ui" works better than "keep the code organized".
• Always include the why. The agent follows a rule better when it understands the reason, and so does your team.
• Link local things to files. A rule that only matters for the database doesn't need to take up space in every session.
• Rules are for what always applies. If every decision becomes a rule, the start of every session gets heavy.
• Mark items obsolete instead of deleting them. The history of decisions helps explain why the project is the way it is.

Commands