Opening a single issue gives you everything Pirros used to reach its conclusion. Understanding one issue properly is worth more than scrolling past twenty.

The sheet opens zoomed to the thing being flagged, so you are looking at the condition rather than hunting for it.

This works the other way too: on the sheet view, the highlighted regions are clickable. Click one and it takes you to its issue.

Each issue shows the rule it came from, collapsed by default. Click it to read the exact excerpt — the actual clause text from the code book or from your standards document.

It is collapsed because most people do not want two paragraphs of code language every time. It is there because when you do need it, paraphrase is not good enough.

Plain-language explanation of why this was flagged. In practice this is the part reviewers actually read, and it is what you would forward to whoever needs to fix it.

The record of how the conclusion was reached — which sheets were opened, which schedules were consulted, which specification sections were read.

The references are links. If an issue depended on something in a door schedule, you can go and look at the door schedule.

This is the answer to "how did it decide that?", and it is worth opening the first few times so you develop a sense of how findings are reached.

If a violation occurs in more than one place, the issue carries a count. Open it and move through the instances one at a time.

The reasoning changes between instances, because the locations are different — the same rule broken in two places is rarely broken for identical reasons. Read them rather than assuming the first one covers the rest.

From the issue you can:

Comments are the most underused of these. An issue that was considered and consciously accepted is worth recording as such — it is the difference between a decision and an oversight when someone reviews the project later.

Q: What are "Mira's thoughts"?

A: The record of how the conclusion was reached — which sheets were opened, which schedules were consulted, which spec sections were read. The references are links, so you can go and check them yourself. It is the answer to "how did it decide that?"

Q: Why does the reasoning differ between instances of the same issue?

A: Because the locations differ. The same rule broken in two places is rarely broken for identical reasons, so each instance carries its own reasoning. Read them rather than assuming the first covers the rest.

Q: Can I see the exact code text a finding rests on?

A: Yes. Click the rule on the issue to expand the exact excerpt — the real clause text from the code book or your standards document. It is collapsed by default because most people don't want two paragraphs of code language every time.

Q: What is the raw JSON view?

A: A debugging view we use internally. There is nothing there you need.

Q: Can I get from a sheet to the issue on it?

A: Yes. Highlighted regions on the sheet view are clickable and take you straight to the issue.

Q: The highlighted region looks slightly off. Is the finding wrong?

A: Not necessarily — the framing is occasionally imprecise even when the finding is sound. Judge the issue on its reasoning. If a finding is genuinely wrong, dismiss it as a false positive so we can see it.

Q: Who gets notified when I @mention someone?

A: The person you mention. It is the way to pull someone into a specific issue rather than sending them the whole review.