Product Memory | QA.army

Product Memory is available for Test creation and Web Runs. Published knowledge supplies context; saved assertions still determine correctness from current evidence.

Open Memory inside your Project. Add intended behavior, product context, or testing guidance using Add memory. Keep passwords and tokens in Test Accounts.

Workspace owners approve memories for publication. Other members can propose memories for review. Choose this Project, one Test Group, or explicit Workspace-wide sharing. An optional target origin restricts where a memory applies.

Understand the three views

Memories shows searchable cards with category, importance, status, evidence, and usage. Open a card to inspect its source, edit a correction, approve a proposal, or archive old knowledge.

3D graph displays relationships between published knowledge. Select a node to inspect its supporting memory. A text view provides accessible navigation.

memory.md is a downloadable summary of published knowledge, including record revisions and sources.

Control automatic learning

Auto updates starts off. When enabled by an owner, evidence-backed observations from completed Runs can be published automatically. Inferences, conflicting claims, and historical imports require review. Existing approved knowledge stays available when automatic updates are off.

Import TXT, Markdown, or text-based PDF specifications, or paste product context. Uploads are limited to 10 MiB; PDFs to 100 pages and extracted text to 100,000 characters. Extracted statements are proposals for review.

Import historical Runs examines up to 100 completed Runs from the past 90 days and creates proposals supported by available evidence.

How the agents use memory

The Test-generation agent retrieves relevant published memories when drafting a Test. Intended behavior can inform expectations; an observation describes past behavior and does not establish correctness.

Each new Run freezes the memory revisions it will use and receives relevant published context for its current action. Assertions retain the saved Test expectation and use current evidence. Editing memory affects future Runs; it does not rewrite historical results.

A usage count means a memory was supplied to generation or an attempted action. It does not prove that the memory improved a result.

Archive a memory to stop future retrieval. Clear all archives this Project’s memories and turns automatic updates off; historical Run snapshots remain in their reports.

CLI and MCP

Memory management requires a user session or profile API key; setup-only WorkOS credentials cannot manage memory.

Use qa-army memories list --project prj_... to inspect memory. Creation accepts --input JSON containing title, content, and optional classification and scope fields. Review commands accept --memory mem_... --version N.

MCP exposes memories.list, memories.create, memories.update, memories.decide, memories.settings, memories.graph, memories.summary, memories.import, memories.history, and memories.clear. The server applies the same Workspace permissions as the UI.

Daily clarification preview

The redesigned Memory page and daily questions are in release validation. Production acceptance is pending.

The Knowledge view separates Published, Needs review, Publishing and History. Search by content and inspect a selected memory beside the list. Source links preserve the requested revision; if it differs from the current record, the page explains the difference. Explore graph and Summary retain alternate navigation and export.

Open the optional daily card to clarify critical workflows. A Project receives one stable UTC-day set with three questions and three suggested choices per question. Add optional detail, save your intended behavior, or skip. Nothing is selected or submitted for you. If there are fewer than three unresolved questions, the page explains that no new set is available instead of repeating resolved topics.

Answers become customer-declared proposals and require owner review, including answers submitted by owners. Correcting an answer retains its history and creates a new proposal. Review conflicting earlier knowledge before publication. A published answer can become context for a later Test or Run; this does not establish that it improved a result.

The API uses GET /v1/projects/{projectId}/memory/clarifications and POST on the same path. The answer body includes the set’s day, question_id, prior answer revision (initially 0), zero-based choice (0–2), skipped, and optional elaboration. To skip, send choice: null and skipped: true. To select a choice, send its zero-based index and skipped: false. CLI commands are memories questions and memories answer; MCP tools are memories.questions and memories.answer. Refresh after a revision conflict.

To revisit a saved set, select its date in Memory, use CLI memories questions --project prj_... --day YYYY-MM-DD, or pass day to MCP memories.questions. The historical API is GET /v1/projects/{projectId}/memory/clarifications/{day}. Only existing sets are returned; prior answers remain correctable with revision checks.