Skip to content

Issue and milestone status is derived from recorded facts and is stored nowhere

There is no status: field in an issue or a milestone. Writing one is an unknown key. An issue records what happened to it — started_at, verified_at, completed_at, cancelled, and its evidence — and BLOCKED, READY, ACTIVE, VERIFY, DONE or CANCELLED follows from those facts together with the state of the issues it depends on. A milestone's status follows from its issues and its own evidence.

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

An issue records started_at, verified_at, completed_at, cancelled and its evidence. BLOCKED, READY, ACTIVE, VERIFY, DONE and CANCELLED follow from those and from the state of its dependencies. `status` is not a field, so writing one is an unknown key.

What it means

There is no status: field in an issue or a milestone. Writing one is an unknown key. An issue records what happened to it — started_at, verified_at, completed_at, cancelled, and its evidence — and BLOCKED, READY, ACTIVE, VERIFY, DONE or CANCELLED follows from those facts together with the state of the issues it depends on. A milestone's status follows from its issues and its own evidence.

How it works

lib/project.awk computes, for each issue, whether it is locally done (completed, not cancelled, every required evidence token covered), then whether any dependency is not done. The precedence is cancelled, done, verify, active, blocked, ready. A milestone is DONE only when every issue that is not cancelled is DONE and its own evidence_required is covered; when the issues are all done and the milestone's evidence is not, it is VERIFY. The active milestone is the lowest-ordered milestone that is ACTIVE, or failing that the lowest-ordered one that is not finished.

How to see it

majordomus plan list
# I0002   BLOCKED   1    M000   Define the canonical milestone and issue schema
majordomus plan done I0001
# plan: I0001 DONE
# next ready issue: I0002

What it does not cover

Derivation cannot tell you that a recorded fact is false. If completed_at is set on an issue whose work was never done, the graph believes it — which is why plan done refuses without evidence, and why the evidence has to be a command.

Why it exists

A stored status is a second opinion. The moment it can disagree with the dependency graph, somebody has to decide which one is right, and the answer is always the graph.

Detail rendered from docs/claims/project-status-derived.md.

From the statement to the proof

  1. 1 · the public statement

    Issue and milestone status is derived from recorded facts and is stored nowhere

    Made on Planning, Plan.

  2. 2 · the canonical claim

    project-status-deriveddeclared 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/41_project_status.sh

    Executed in Complete an issue only when its evidence exists, 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 41_project_status

Where this claim is used

Related claims same implementation

The moments this answers

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