Skip to main content
Every bug in a Mo report starts untriaged. Mo records your decision on the bug, with who made it and when, so the next reader sees it.

​
The decisions

Reset clears a decision and returns the bug to untriaged.

​
Works as intended

Mo reports an intended behavior again on the next run unless the run knows about it, so a works-as-intended decision records the reason:
1

Explain why the behavior is expected

Type the reason, for example “The confirmation modal is intentional. It prevents accidental deletes.”
2

Review the suggested entry

Mo drafts a knowledge base entry from your reason and the bug, or matches an entry that already covers it.
3

Accept or reject it

Accept, and Mo saves the entry and links it to the bug. Reject it, or choose Skip knowledge, and Mo still marks the bug as intended and writes no entry.
Later sessions can retrieve the entry as guidance when investigating the same behavior. Review the entry’s scope so it applies to the intended environment and flows. Momentic test agents can also use the knowledge base. The linked entry stays visible on the bug. If you change the decision later, Mo asks whether to unlink the entry as well.

​
What to do with an accepted bug

Fix it, then keep the flow covered by a Momentic test, so the next release checks it without a Mo session. For the fix itself, qa report exports report data and available recordings into a directory your coding agent reads, and qa send asks Mo to rerun the original reproduction after the patch lands. See fix what it found, then recheck. To keep the flow covered, the case in the report already has the preconditions, the outline, and the acceptance criteria a test needs. Give the case to your coding agent with the Momentic MCP server and the momentic-test skill for web or momentic-mobile-test for mobile. The agent writes the .test.yaml file in your repository:
Run it with npx momentic run or npx momentic-mobile run, then add it to the suite your CI runs. See run tests locally.