Memory & Grounding
Two related capabilities live under this section. Project memory lets an agent working over MCP recall what a prior session already verified — instead of rediscovering the same locators, re-running the same crawl, or regenerating a script that already passed. Grounding is the separate discipline of keeping AI-generated content — test cases, learnings, repairs — tied to facts a scanner or a passing run actually observed, so a generation can always be traced back to its evidence.
Why this exists
Section titled “Why this exists”An agent with no memory of a project re-derives everything from scratch on every call: it re-lists test cases, re-reads scripts, and re-discovers which selector is stable versus which one just broke. That costs tokens and tool calls, and worse, it can silently regenerate a locator that was already proven fragile last time. Grounding solves a different problem: an ungrounded generation can assert a route, a field, or a behavior that does not exist in the code it claims to describe. Both failure modes look like ordinary output — the point of this section is that neither one is invisible in QualityMax: memory recall is inspectable, and every grounded fact carries a source reference back to where it was verified.
The two mechanisms at a glance
Section titled “The two mechanisms at a glance”| Project memory | Grounding | |
|---|---|---|
| Problem it solves | Re-discovering the same facts across sessions | Generating content the code doesn’t support |
| Primary tool | get_project_memory (MCP) |
get_discovery_graph (MCP) + the project-memory learning gate |
| Unit of evidence | Verified scripts, MCP sessions, ranked negotiation sequences | Repository-scanned facts (routes, models, tests, files) |
| Where it’s visible | The Sessions tab’s navigable memory graph | The Discovery Map / repository analysis |