GitAlert posts exactly one label per pull request, as a neutral GitHub check. It never fails your build and never blocks a merge — the label is a triage signal for your reviewers.
| Label | What it means | What to do |
|---|---|---|
| ✅ Looks solid | No reward-hacking smells were detected in the diff. | A normal review is still a good idea. |
| 👀 Worth a closer look | Soft, informational signals showed up, but nothing rises to a hard rule. | Use your judgment; a quick human glance is worth it. |
| ⚠️ Likely needs attention | One or more deterministic rules fired (for example a weakened test or a package that doesn't exist on the registry). | Review carefully before merging. |
Each label comes with the exact file:line reasons behind it, so a reviewer can jump straight to what matters instead of re-reading the whole diff.
Sometimes GitAlert posts Couldn’t verify instead of a label. This is honest by design — it means GitAlert could not analyse the change, and you should treat the PR as unverified rather than assume it's fine. Common reasons:
Every check also shows a confidence percentage, so you always know how much of the intended analysis actually ran.
The label is computed by a deterministic engine: the same diff always produces the same result. There is no random model verdict deciding your merge. Any written summary on the check only describes what the deterministic rules already found — it never invents a reason and never overrides the rules.
{note} GitAlert is triage, not proof. A “Looks solid” label is not a guarantee the code is correct — it means none of GitAlert's checks fired. Your reviewers always make the final call.
The label shows up as a check named “GitAlert Triage” in the checks section of the pull request, alongside your existing CI. Its status is always neutral — never a red ✗ — so it sits beside your build and test checks without ever blocking the merge.