Working with issues

Issues and recipes

One fault, across every run it appeared in, with what a fix needs.

From finding to issue

A finding gets a fingerprint built from what identifies the fault (its kind, its place, its channels), not from the run. The same fault in a later run lands on the same issue, so you see how often it came back and on which machines.

States

StateMeans
OpenFound and not yet worked on.
In repairSomeone claimed a repair: a person in the app, or a coding agent over MCP, with what changed.
ResolvedA verification passed. If the fault comes back, the issue opens again as regressed.
IgnoredSeen and set aside. It stays ignored when it comes back.

The recipe

Every finding carries the same nine fields. A field that could not be filled says what is missing instead of disappearing.

FieldWhat it holds
1. SymptomWhat the machine did.
2. Causal chainHow that follows from the cause.
3. ConditionThe measured numbers this rests on.
4. Change classWhat kind of change is needed.
5. Files and linesWhere to make it.
6. Reference patternWhat the corrected form looks like.
7. Acceptance criterionThe test that rejects a partial fix.
8. Blast radiusWhat else the change touches.
9. EffortWhat it costs to do.

trialone diagnose --json writes the recipes as JSON with exactly these fields, which is what the website shows and what a coding agent reads.

The incident page

A run and its issue share one page. At the top: the machine at the time (commit, configuration, devices, and what changed since the previous run), then four answers (what happened, why, the fix, what to check first), then the minute around the finding for every channel involved. All channels of the run can be scrubbed below.

Sharing

From an issue you can open a GitHub issue, share it to Slack or Discord, and open the recording in Foxglove when the machine uploads its recordings. Connect these under Settings, Integrations.

Something missing or wrong here? Tell us.