The decisions
Reset clears a decision and returns the bug to untriaged.
From the CLI
List bug names and their current statuses, then use the exact name to record a decision:open, accepted, works-as-intended, cannot-reproduce,
and duplicate. Use open to reset a decision. Both commands print JSON.
CLI decisions appear in the dashboard. These commands do not create Linear or
Jira issues. works-as-intended saves the decision without creating a knowledge
entry; use the dashboard to capture the reason. Changing to another status
unlinks any existing knowledge entry from the bug but keeps the entry in the
knowledge base.
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.
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:
npx momentic run or npx momentic-mobile run, then add it to the
suite your CI runs. See run tests locally.