Land a cross-repo cascade in one Wave.
Bumping a shared module means opening a version-bump PR in every repo that depends on it — then herding all of them to green. PlanningService walks the consumer graph, classifies conflicts, opens the coordinated PRs, and tracks the whole cascade as a single Wave.
A version bump is never just one PR.
Bump a shared module and every consumer needs the same change. Doing that by hand — a PR per repo, then chasing each to green — is exactly the coordination a machine should own.
PlanningService models it as a Wave: give it a module and a new version, and it walks the consumer graph from every repo's MODULE.bazel, classifies semver conflicts (a consumer already at the target, or pinned to something newer), and opens a coordinated bump PR in each bumpable consumer — branch, edit the bazel_dep version, commit, open the PR. All of them are tracked together as one Wave with a state machine, so the whole cascade is one object you watch land, not a dozen tabs.
Bump a module, and every consumer gets a coordinated PR — tracked as one Wave, not a dozen open tabs.
See the cascade before you open it.
ProposeWave is a dry run: every consumer of the module, its current pin, and whether it's bumpable or a conflict. This previews the surface the contract will drive; values illustrative.
| consumer | current | → target | status |
|---|---|---|---|
| botnoc | 0.1.0 | 0.2.0 | bumpable |
| rules_microkit | 0.1.0 | 0.2.0 | bumpable |
| rules_board | 0.2.0 | 0.2.0 | already at target |
| rules_lang | 0.3.0 | 0.2.0 | conflict — pinned newer |
The whole cascade, tracked.
StartWave opens the coordinated PRs and returns a Wave that carries every PR ref and moves through one state machine. Values illustrative.
| wave | module → version | PRs | state |
|---|---|---|---|
| wave-rules_cc_cross-v0.2.0-… | rules_cc_cross → 0.2.0 | 6 | OPEN |
| wave-fastverk_layout-v0.4.1-… | fastverk_layout → 0.4.1 | 9 | MERGING |
| wave-rules_ci-v0.1.0-… | rules_ci → 0.1.0 | 4 | COMPLETED |
Propose → start → track → measure.
Four RPCs over your own repos and forge.
Propose
Given a module + new version, scan every consumer's MODULE.bazel, compare pins with semver, and classify each as bumpable, already-at-target, or a conflict — returning the cascade before anything opens.
Start
For each bumpable consumer: branch, regex-bump the bazel_dep version, commit, and open a PR. All of them are assembled into one Wave in state OPEN.
Track
The Wave carries its PR refs and state; ListWaves shows what's in flight, and auto-merge lands them as CI goes green.
Measure
TechDebtReport trends the org's tech debt over a window — the net TODO-delta of each merged PR, with the top adders and removers.
Coordinate the cascade, don't chase it.
The alternative is finding the consumers yourself, opening each PR by hand, and discovering conflicts at merge time.
Preview: the Wave contract opens the coordinated PRs today. Dependency-order sequencing and milestone grouping are on the roadmap.
source · github.com/fastverk/plugin-planning
Prove it's safe to merge.
planning is one of 14 plugins in the fastverk console — hosted, or in your own cloud.