know the blast radius

See what a change breaks — before it breaks.

tbzl browses your Bazel module graph and subscribes to your forge: a push becomes a graph-scoped build on your own RBE, testing exactly the reverse-dependencies a change can reach. Blast radius is computed from the real graph — not guessed from folder names — and a green build that tested nothing is caught before it merges.

available
Browse the Bazel module graph in the consoleA push → a graph-scoped build on your RBEBlast radius = reverse-dependencies, from the real graphassess_merge blocks a green build that tested nothingTen agent-callable graph + build tools
rdeps
blast radius, computed
targets that transitively depend on a change
1 push
→ a graph-scoped RBE build
EventSink → BuildRun CR
10
agent-callable tools
9 read · run_build confirm-gated
vacuous
greens, caught
assess_merge checks every change has a test
why it's different

A change's blast radius is its reverse-dependencies.

Package-heuristic CI selects tests by folder and hopes. That over-runs on a small change and under-runs on a graph-breaking one. The Bazel graph already knows the truth.

tbzl asks the module graph directly. query_rdeps on a changed target returns exactly the targets that transitively depend on it — the literal blast radius. On a push, the runner reifies the impacted test set from changedFiles via reverse-dependency traversal (content-hash impact, superseding a blunt package match), and when a BUILD or toolchain change dirties everything, it says so — full_run=true, with a reason. The graph is the oracle, not a guess.

Blast radius is a change's reverse-dependencies. tbzl computes it from the real Bazel graph — not from which folder a file lives in.

plugin-tbzl · query_rdeps = the blast radius of changing it
the console

Your module graph, browsable.

The Modules panel projects the Bazel module registry — each module with its version and its dependency / reverse-dependency counts. A high rdeps count is a module the whole org leans on. Values illustrative.

Modules
tbzl.graph.v1.Graph · ListModules
moduleversiondepsrdeps
rules_cc_cross 0.2.0 4 23
fastverk_layout 0.4.1 2 31
rules_ci 0.1.0 6 18
botnoc 0.9.3 41 0
graph: served by modgraph graphd, git-pinned per repo@ref
agent-callable

Ask the graph anything.

The same reverse-dependency, dependency, path, and stats queries the console runs are MCP tools. run_build is the one write — confirm-gated. Results illustrative.

graph + build tools
modgraph.v1.GraphQuery · via MCP
toolcallresult
query_rdeps //lib:greet 6 targets — the blast radius
query_deps //app:server 128 targets
affected_targets changedFiles: [lib/greet.rs] 4 impacted tests · full_run=false
affected_targets changedFiles: [MODULE.bazel] full_run=true — toolchain change
graph_stats — 5,142 targets · 18,903 edges
run_build confirm: true BuildRun created — polling phase
reads: rdeps · deps · somepath · kind · statswrite: run_build — confirm-gated
the pipeline

A push becomes a scoped build.

tbzl subscribes to your forge as an EventSink. Every stage is graph-aware.

01

Push

The webhook receiver HMAC-verifies a push and calls EventSink.Deliver. On EVENT_PUSH to the default branch, tbzl creates a BuildRun CR (fastverk.savvifi.com/v1), named <repo>-<sha12>, idempotent per sha.

02

Scope

No explicit test list? The runner derives the impacted tests from spec.changedFiles by reverse-dependency traversal — filtered to test targets — so it runs what the change can actually break.

03

Build

The fastverk-deploy operator reconciles the BuildRun into a build-runner Job that runs bazel test on your RBE. Status moves Pending → Building → Succeeded / Failed, pollable via get_build_status.

04

Assess

assess_merge grades the result before auto-merge: it checks the green build wasn't vacuous — that every changed source file has a test in its reverse-dependencies. A high-confidence pass is a real one.

build state

Every scoped build, tracked.

get_build_status reports each BuildRun's phase and message; assess_merge turns that into an auto-merge verdict with its signals. Values illustrative.

BuildRun · status
get_build_status · assess_merge
buildrepo@shaphasemerge verdict
rules-cc-cross-abcdef012345 rules_cc_cross@abcdef Succeeded high — every change tested
botnoc-0123456789ab botnoc@012345 Building pending
rules-ci-fed210987654 rules_ci@fed210 Succeeded low — a changed file has no test
verdict: confidence high | low, with signals + reasons
vs folder-based CI

Test what a change reaches. Nothing less, nothing more.

The alternative selects tests by directory — over-running trivial changes and, worse, missing the far-away target a graph edge connects.

fastverk tbzl
package-heuristic CI
Test selection
✓ Reverse-deps + content-hash impact
Guess by folder, or run everything
Blast radius
✓ Computed from the real graph
Unknown until something breaks
Graph-breaking change
✓ full_run=true, with the reason
Silently under-tests
Vacuous greens
✓ assess_merge blocks a test-less pass
Green even if nothing exercised it
Trigger
✓ One push → a scoped RBE build
A hand-maintained CI matrix
Agent access
✓ Ten typed graph + build tools
Parse CI logs

assess_merge won't call a build safe if the changed code has no test in its reverse-dependencies. A green that tested nothing is not a pass.

plugin-tbzl · guards against a vacuous green

source · github.com/fastverk/plugin-tbzl · tools: query_rdeps, query_deps, affected_targets, run_build, assess_merge, graph_stats

Prove it's safe to merge.

tbzl is one of 14 plugins in the fastverk console — hosted, or in your own cloud.