Skip to content

Execution waves are computed from the graph, and issues in one wave that touch the same paths are reported as serialised

A wave is the set of issues whose dependencies are all satisfied at the same depth. Wave zero is every root; an issue sits one layer past its deepest dependency. Waves are derived on every read and stored nowhere, so no execution plan can go stale. Sharing a wave is necessary for two issues to run concurrently and is not sufficient: if their declared scope paths overlap, the overlap is reported and they are serialised.

declared statusdeclared status: guaranteed Declared deterministic and blocking, implemented, and naming the behavioural test that is to prove it. Whether a recorded run supports it is the evidence verdict, shown beside it.

recorded evidencerecorded evidence: not run Declared guaranteed, and not supported by a recorded run: the test is named, and no passing run of the current inputs is recorded. how evidence is recorded

Sharing a wave is necessary for concurrency, not sufficient. Overlapping declared scope serialises conservatively, because a false serialisation costs time and a false parallel costs a conflict.

What it means

A wave is the set of issues whose dependencies are all satisfied at the same depth. Wave zero is every root; an issue sits one layer past its deepest dependency. Waves are derived on every read and stored nowhere, so no execution plan can go stale. Sharing a wave is necessary for two issues to run concurrently and is not sufficient: if their declared scope paths overlap, the overlap is reported and they are serialised.

How it works

The same Kahn layering that detects cycles assigns the waves. Scope conflict is a containment test on the declared paths of two issues in the same wave that are both READY or ACTIVE; a path equal to, inside, or containing another counts as an overlap.

How to see it

majordomus plan waves
# Wave 1
#   I0002   READY     …
#   I0003   READY     …
#
# serialised by scope overlap:
#   I0002 shares lib/project.awk with I0003; they may not run concurrently

What it does not cover

Scope is what an issue declares, not what it touches. Two issues that both edit a file neither of them claimed will conflict, and this reports nothing — the same limit check has.

Why it exists

A false serialisation costs time. A false parallel costs a merge conflict and two workers discovering it after the work is done. The conservative direction is the cheap one.

Detail rendered from docs/claims/execution-waves.md.

From the statement to the proof

  1. 1 · the public statement

    Execution waves are computed from the graph, and issues in one wave that touch the same paths are reported as serialised

    Made on Planning, Plan.

  2. 2 · the canonical claim

    execution-wavesdeclared status: guaranteed in docs/CLAIMS.yaml

    Defined in read it on this site · docs/PLANNING.md

  3. 3 · the implementation

    lib/project.awk

  4. 4 · the test and the scenarios

    Test: test/cases/42_dag_waves.sh

    Executed in Deliver issues in waves the graph computes, and take the next one, Keep the plan as milestones and issues the tool can validate.

  5. 5 · the recorded runs

    recorded evidence: not run how evidence is recorded

Verify it yourself

The test runs in a disposable temporary repository and asserts the behaviour, not a string in the source.

from a clone of the repository
bash test/run.sh 42_dag_waves

Where this claim is used

Related claims same implementation

The moments this answers

Searches the titles and descriptions of every page this site publishes.