Session reports - Momentic

Test cases

A test case describes one behavior Mo plans to check. Its setup, outline, and acceptance criteria let you review the coverage or turn it into a repository test:

Field	Content
`name`	Short name for the behavior under test.
`summary`	What the case checks.
`preconditions`	The state and the account needed before the first step.
`outline`	The steps through the flow.
`acceptanceCriteria`	What must be true for the case to pass.

Two cases are duplicates when they check the same behavior under the same meaningful conditions, so Mo keeps distinct roles, permissions, and outcomes as separate cases.

Verdicts

A bug bash agent submits one verdict per case:

Verified: the case behaved as its acceptance criteria require.
Issues found: the agent saw behavior that does not match the criteria.
Blocked: the case could not be checked. Access, missing data, or a sandbox limit stopped it.

Each verdict carries a summary, the parts the agent verified, and the gaps it could not close. Alongside the verdict, the agent records the individual controls it exercised, each marked checked, failed, partial, or out of scope. A case blocked before a bug bash agent runs can have a blockedReason without a verdict. Review case blockers as well as verdicts; a case without a verdict is unverified coverage.

Bugs

Functional bugs reach the report after a separate agent reproduces them. Mo can also flag static mistakes, such as typos, with a screenshot instead of a reproduction. Each entry holds:

Field	Content
`kind`	`bug` for a functional bug, or `flag` for a static finding.
`name`	Short name for the finding.
`summary`	The finding in one paragraph.
`expected`	The behavior or content the product should have.
`actual`	The behavior or content the agent observed.
`reproSteps`	The steps from the start of the flow to the finding.
`recording`	Reproduction recording metadata, including start and end times, if present.
`screenshot`	Screenshot artifact metadata for a static finding, if present.

For a reproduced bug, the report records the reproducer’s conversation so you can inspect the run that confirmed it. From a finding you make a triage decision.

Review the coverage

Compare the case list with the scope you requested, then read the verdicts and gaps to see what Mo checked. A case in the list does not establish that Mo verified it. Message Mo to add missing coverage or explain expected behavior. When a reported finding is expected, record the reason through triage and review the suggested knowledge base entry.

Export the report

qa report writes the report’s findings to a directory your coding agent can read:

qa report <session-id> --require-idle --output mo-report

--require-idle exits without writing unless Mo is idle and every sub-agent is done; omit it for an in-progress snapshot. The directory holds report.json, a manifest that names the finding files and downloaded reproduction recordings:

File	Contents
`bugs.json`	Reviewed bugs and static findings: expected and actual behavior, reproduction steps, evidence metadata, timestamps.
`testCases.json`	The intended coverage: preconditions, outline, and acceptance criteria per case.
`verdicts.json`	The verification outcome, confirmed behavior, and coverage gaps per case.
`triage.json`	Human dispositions such as accepted or works as intended. A bug with no entry is still open.

Each recording download lands in the manifest’s artifacts list as { bugName, path } or { bugName, error }. Read every file findings names; newer servers can add categories. Check artifact errors before relying on a recording. The export keeps screenshot metadata in bugs.json; it does not download screenshots for static findings. This is the handoff for the fix loop: hand mo-report/ to Claude Code, Codex, Devin, or Cursor, so the agent can read the reproduction steps and available recordings. After the fix deploys to the same target, qa send asks Mo to rerun the original reproduction, and a second export into a separate directory shows the new verdicts.