Reviews
Findings and severities
The three severities
| Severity | Meaning | Blocks? |
|---|---|---|
critical |
A security or correctness problem with a concrete consequence. | Yes |
warn |
Something that departs from this repo’s own standard. | No — advisory |
info |
Worth knowing; not worth stopping for. | No — advisory |
The check run reflects this: a review with any blocking finding fails, and a review with only advisories does not.
Advisories can be made to block
garboard gate --advisory-errors fails the CI step on any finding, not just blocking ones. That is a per-pipeline decision — some teams want a clean tree, some want the gate to speak only when it is serious.
No evidence, no finding
A finding without a file and a line is dropped by the ranker before the comment is composed. Not shown with a hedge — dropped, and treated internally as a bug in whatever produced it.
This is the rule that makes everything else worth reading. A reviewer who cannot open the file and look is being asked to trust an assertion, and replacing that with something checkable is the entire point of the product.
What a learned convention may do
A convention derived from your repository can raise a warn, and it is advisory only. It cannot block a merge.
That asymmetry is deliberate. A convention is an inference — a strong one, backed by evidence and a support count, but still something we worked out rather than something you declared. Blocking a merge on an inference would be the fastest possible way to lose the argument. Built-in security rules block; things we noticed about your repo advise.
Ranking
Findings are ranked by severity first, then confidence. Confidence is deliberately second: a critical finding we are somewhat less sure about still outranks an advisory we are certain of.
The top three are shown. The rest are stored and visible in the UI — the cap is a property of the comment, not of the record, so a status line saying “7 findings” and the stored list always agree.