Grading

Every run rolls up into one grade. You get a score out of 100, a letter from A+ down to F, and a healthy / needs-attention / failing verdict. The grade is what makes care a single signal you can gate on or badge.

How the score is computed

Each check carries a weight that sets how much it counts toward the score out of 100. Critical failures then cap the score, so a serious problem cannot hide behind an otherwise good average.

Two checks impose caps when they fail. A committed secret is a live exposure and caps the score hard. A reachable vulnerability is real but often transitive and caps it less severely. A check with no cap relies on its weight alone.

A weight of 0 makes a check informational. It runs and reports but never moves the score. That is the default for benchmarks and for the runtime check.

The default Go grade

care ships a published grading opinion for Go repos. Security and a broken build dominate, style and docs are minor, and benchmarks are informational.

A broken build has no cap on purpose, so a transient non-compiling module in active development is weighted, not graded as a hard failure. A committed secret caps the score at 40, roughly an F. A reachable vulnerability caps it at 72, roughly a C.

Retuning the grade

The weights and caps are yours to retune. Add a health block to care.yml. It overlays the ecosystem defaults, so you set only the keys you want to change and the rest keep care's published Go values.

health:
  weights:
    docs: 10          # care more about documentation coverage
    benchmarks: 5     # make benchmarks count toward the grade
  caps:
    vulnerabilities: 50   # a reachable vuln caps harder

Seeing what lowered the grade

--explain prints the per-check grading breakdown beneath the report. Each weighted feature, the points it cost the score, and any cap that lowered the grade. The breakdown is always present in --json, so a downstream tool never needs the flag.

care --explain

Every health key is documented in the configuration reference.