tomato-bazel

This is what happens when a monorepo is decomposed into a constellation of independently versioned modules and the seams have to be held by machines rather than convention. At the centre is a self-hosted bzlmod registry carrying 84 modules — 56 of them rules_* — across 480 published versions, released through a purpose-built Rust CLI that computes source integrity itself. Admission used to be audited by weekly cron, which is how, in the workflow's own words, "135 findings accrued across 300-odd published versions"; it now happens at pull-request time through gate, a Rust pipeline that evaluates MODULE.bazel files, runs minimal version selection, projects the resulting facts into Turtle, and runs one SPARQL query per invariant. Ten such gates exist today — unpinned overrides in published modules, atoms selected at multiple versions, toolchain-registration leakage, unnamespaced extension repos, metadata drift — and a gate is one query file plus one target, so adding an invariant needs no Rust rebuild. Because the corpus is not yet clean, the merge check runs as a ratchet rather than a gate: it projects both the pull request and its base, compares per-gate counts, and fails only on regression, which stops things getting worse instead of demanding zero first. The execution side is a Buildbarn cluster expressed as RbeCluster and WorkerPool custom resources, with a CI action that lets a workflow name only its tenant and receive its endpoint, credential and exec-property flags from the platform at runtime rather than transcribing them. The rulesets themselves are deeper than wrappers: rules_lean reuses mathlib's upstream olean cache and adds a test that audits a theorem's transitive axiom set through Lean.collectAxioms, catching a dependency that silently introduces Classical.choice; rules_cloudformation generates roughly 1,582 typed rules, one per AWS resource type, from the pinned upstream schema; rules_tla runs TLC model-checking as ordinary bazel test targets.