Registry conformance
Every invariant here is a zero-row gate: the
query selects violations, so an empty result set means the invariant holds and
any row is a counterexample you can act on. They run as Bazel targets over a projection
of the registry's MODULE.bazel graph.
as of 2026-09-14 · tomato-bazel/bazel-registry @ ce604dd
The invariants#
Five gates today. Each is one .rq file plus one Bazel target, so
adding an invariant needs no code change — and the rationale on each page is extracted
from the query's own header comment, which is why the documentation cannot drift from the
gate it documents.
Modules#
28 of 83 modules have at least one finding.
Worst first, because the point of a scoreboard is to say what to fix next. Each row goes
to that module's reference page, where its findings sit beside the
bazel_dep lines that cause them.
How this is produced#
tomato-bazel/gate projects
the registry's module graph to RDF, runs every .rq against it as a
Bazel target, and emits the result as a
tomato.gate.v1.ConformanceReport. This site fetches that
message and renders it. Nothing is computed here: every count above is a field in the
report, and if one is wrong, the query is wrong.
Not a judgement
A gate reports; it does not rank blame. Registry-level invariants like C1 say "this atom is live at two versions", not "this module is at fault" — so they are counted here and attributed per-module only where a companion query makes that meaningful, as contested atoms.