Skip to content
Raw Markdown

Issues commands

Triage the issues Cassis raised on the project without leaving the checkout: refresh the queue from the latest conversations, list the issues, read the diagnosis and the evidence behind them, and record the outcome.

These commands work on the same queue as the Review page and the MCP issue tools. Like the other project-bound commands, the project id comes from cassis/project.yml in the checkout, CASSIS_PROJECT_ID, or --project.

issues list

Lists the project’s issues, prioritized by impact then recurrence: one line per issue with its id, impact, occurrence count, status, and title. The id is what the other issues commands take.

# The triage queue
cassis issues list --status open

# Narrow by impact or cause
cassis issues list --impact wrong_answer --cause ontology_gap

# Raw JSON
cassis issues list --json
Filters
--status (open, resolved, dismissed), --impact (wrong_answer, unreliable_answer, no_answer, inefficient), --cause (ontology_gap, missing_data). All optional and combinable.
Output
One line per issue, or the full records with --json.

issues show

Shows one issue in full: its diagnosis, suggested action, whether a fix proposal exists, and the occurrences behind it. Each occurrence’s id feeds issues evidence.

cassis issues show 019f0000-0000-7000-8000-0000000000e1

issues evidence

Prints the evidence behind one occurrence, joined back from its source: the generated SQL and its results, the agent’s process log, and either the user’s rating (a chat) or the judge’s verdict (an eval failure). Read it when the extracted fields are not enough to judge an issue.

cassis issues evidence 019f0000-0000-7000-8000-0000000000e1 019f0000-0000-7000-8000-0000000000c1

issues analyze

Analyzes the project’s conversations that nobody has analyzed yet and turns what went wrong into issues — the same pass as the Review page’s “Analyze conversations” button, started on demand instead of waiting for the nightly one. It runs on Cassis’s workers, so a lost connection or a Ctrl-C after the start never loses the work; by default the command waits and prints the run’s summary. Needs cassis-cli 1.7.

# Refresh the queue, then read it
cassis issues analyze
cassis issues list --status open

# Start it and come back later
cassis issues analyze --no-wait

# Raw JSON for a pipeline step
cassis issues analyze --json | jq .run.status
Nothing new
When every conversation is already analyzed the command is a no-op that exits 0, so a scheduled job re-running it on a quiet project stays green.
Waiting
--wait (default) or --no-wait, --poll-interval, --timeout. The run keeps going server-side if the CLI stops waiting; Ctrl-C cancels it and exits 130.
Exit codes
0 when the run completes (or there was nothing to analyze), 1 when it fails or is cancelled, 3 on transport errors, on an analysis already in flight, or on --timeout.
Role
Editor or admin, like the Review page button.

issues resolve, dismiss, reopen

Set the issue’s status: resolve once the ontology change that fixes it is published, dismiss for issues you deliberately will not act on, reopen to put a resolved or dismissed issue back in the queue. Status changes require the editor or admin role.

cassis issues resolve 019f0000-0000-7000-8000-0000000000e1
cassis issues dismiss 019f0000-0000-7000-8000-0000000000e1
cassis issues reopen 019f0000-0000-7000-8000-0000000000e1

Exit 1 when the issue or occurrence does not exist in the project; nothing is changed.

Resolving records an outcome, it does not change the ontology. The typical loop from a checkout: read the issue and its evidence, fix the gap in the ontology files, prove the fix with cassis eval run or cassis ontology test, then resolve once the merge is published.