Memory

Memory is project knowledge that helps Qodex reuse facts, rules, and patterns across sessions.

Memory

Memory is the project knowledge Qodex keeps between sessions.

It helps the agent remember your app, rules, auth patterns, UI behavior, and past findings without rediscovering the same facts on every scan.

How memory is organized

Qodex keeps five small markdown files per project. You write two of them. The agent writes the other three.

Files you write

File	Content
project.md	App overview, stack, test accounts, known quirks, focus areas, team context.
workflow_rules.md	Hard rules the agent must follow on every turn, like “never run destructive tests on /admin/reset.”

Both files paste verbatim into every LLM call. They are the smallest, highest-signal context the agent should never need to rediscover.

Files the agent writes

File	Content
api_behavior.md	Auth mechanisms, pagination shapes, error formats, observed API patterns.
ui_behavior.md	Selector patterns, form behaviors, navigation flows.
findings_digest.md	Distilled summary of past findings by endpoint or page.

These three are not pasted up front. The agent pulls them in on demand when a turn needs them.

project.md

You write this. It is the business and operational context the agent should never have to rediscover. A typical project.md covers:

• What the app does, in two paragraphs
• The stack: framework, hosting, database, third-party services
• Test accounts (email, password, role) for staging
• Quirks that look like bugs but are not (“The settings page takes 4 seconds on first load. That is expected.”)
• Focus and skip areas
• Team conventions

The onboarding agent fires once on a fresh project and asks for the minimal version of this. You can edit it any time in the Knowledge tab.

workflow_rules.md

You write this. The agent reads it on every turn and must obey it. Use it for hard rules: read-only environments, sensitive endpoints, “always file a finding when a security scenario fails.” Keep it small; the always-in-prompt budget is precious.

Agent-written memory files

The agent writes these during scans, organized under section headings. You can edit and curate in the Knowledge tab. Delete entries that drifted; the agent will rediscover anything that matters, or skip it if you removed it deliberately.

Why markdown

Vector retrieval is good for “find me passages similar to this query.” The files that paste into every turn are not that. project.md and workflow_rules.md are universal facts every authoring call needs, not retrieval candidates.

For the on-demand files, search works against the markdown text directly. You can read your project’s accumulated knowledge in the Knowledge tab, fix what is wrong, add what is missing. A vector DB is a black box.

When to use it

• Put facts about your app in project.md when the agent should never rediscover them.
• Put hard rules in workflow_rules.md when the agent must obey them on every turn.
• Let the agent write auth, API, UI, and findings patterns into the other three files.

When not to use it

• Per-scenario state. Use the scenario’s own setup steps.
• Secrets like passwords or tokens. Use environment credentials, not memory.
• Long transcripts of past chats. Chat history lives in the chat itself, not memory.

On the roadmap

Planned: source-aware memory. Once a GitHub repo is linked, the agent reads the route table and component tree into memory and uses it as the strongest prior for authoring.

Planned: reflection passes after each scan distill what was new and update the on-demand files automatically.

Related

Memory reference

The deeper reference for each file and the tools that read them.

project.md

What goes in the user-managed file.

Skills

The reasoning rules that read memory.

Projects

The tenancy boundary that scopes memory.