Review detected issues

Open Review in the web app, or use the MCP issue tools or the CLI issues commands. Review opens as a list of context domains, sorted by wrong answers then by how often users hit them, so you pick the area your team is ready to work on rather than a single issue in isolation. Issues no occurrence can attach to a modeled table are listed last.

Open a domain to work through its issues. The domain is part of the URL, so the view survives a reload and can be handed to a colleague. cassis issues list --domain <path> is the same cut from the terminal.

Races	7	19 occurrences · 3 wrong answers · 2 fixes ready · active this week
Drivers	3	5 occurrences · 1 fix ready · active this month
Not in a domain	2	no occurrence references a modeled table

☑	"Podium" is computed inconsistently	Wrong answer	5 chats · 1 eval · fix ready
☑	No rule for a race that was red-flagged	Wrong answer	3 chats
☐	"Sprint" is not defined anywhere	No answer	2 chats

Work through a domain

Tick the issues that one change would fix, then act on them together.

Fix in chat: Creates a branch and opens one context chat seeded with every selected issue. The assistant reads all the evidence first, groups the issues by the change that fixes them, and recaps which change addresses which issue.
Resolve, Dismiss: Set the status of the whole selection at once. Resolve only after the fix is published. Dismiss with an explicit reason when you deliberately will not act.

Read the issue

Cause: An context gap needs a definition or relationship. Missing data usually means modeling another warehouse table.
Impact: Wrong, unreliable, or missing answers rank ahead of inefficiency. Recurrence and recency break ties.
Occurrences: The questions, symptoms, diagnoses, and user corrections behind the issue. This is the evidence for the fix.

Choose the response

Apply a proposed rule: When the conversations agree on the missing rule, review the proposal and apply it in the project’s chosen editing workflow.
Model referenced tables: When the data exists but is not in the context, inspect the named source tables and model them.
Decide manually: When the evidence does not establish one business meaning, ask the domain owner instead of inventing a default.
Dismiss: Choose Invalid, Irrelevant, Duplicate, or Declined, and add detail when useful. Leave uncertain issues open.

Resolve after publication. Changing the issue status alone fixes nothing: the queue tracks outcomes, the context carries the fix.

Let the change close the issue

Cassis closes an issue with the change that fixes it, so nobody has to remember to come back.

From a pull request: Write Resolves <issue id> in the PR description, on any branch of the connected repository, and the merge resolves the issue. cassis issues show prints the exact line, Closes and Fixes work too, and one description can carry a mention per issue the change fixes.
From a fix chat: Merging the branch a “Fix in chat” opened resolves the issues that chat set out to fix, and the confirmation says how many. Opening a merge PR instead resolves them when that PR merges. Issues already dismissed or resolved by hand are left alone.

Each issue keeps its status history, including how it was closed and the pull request it came through, in the app and in cassis issues show. A fix applied from Review stays open and marked as awaiting publication until the context is published. New evidence against a later published version reopens a resolved issue; a dismissed issue stays dismissed and flags the recurrence for review.

Continue with Curate in a repository or Curate in the web app.