Skip to content

The issue says done and the repository disagrees

Completion is recorded as a state change in a tracker rather than as evidence in the repository, so the two drift immediately.

→ closed an issue whose acceptance criteria nothing had actually checked

cost when it happens
high
how often
common

The moment

The issue is closed. Two of its four acceptance criteria were never implemented, and the evidence field says "tested locally". Nobody lied; the issue was closed by someone who believed the work was finished, and nothing was in a position to disagree.

Why it happens

Closing is a state change in a tracker, and the tracker knows nothing about the repository. The acceptance criteria are prose in a field, so checking them is a reading, and the reading is done by the person most convinced the work is complete.

Why a better model does not fix it

The worker was not asked to check the criteria; it was asked to do the work, and it did. Asking a worker to also assess its own completion returns a confident assessment, which is the input we already had.

What it costs

The gap between recorded and actual completion is invisible until something downstream fails. Meanwhile the plan is used to decide what to start next, so work begins on top of foundations that were only reported as laid.

What Majordomus does

No status is stored anywhere. READY, BLOCKED, ACTIVE, VERIFY and DONE are derived from the events an issue recorded about itself and from the state of its dependencies, every time the plan is read; a hand-written status field is an unknown key. plan evidence refuses narrative — it needs a command or an artifact, and it records the result with the commit. plan done refuses while any declared evidence is uncovered or a dependency is not done. finish applies the same discipline to the task: nothing is written while a line of the contract fails.

Before and after

before   tracker: closed          repository: two criteria unimplemented

after    $ majordomus plan done I0042
         refused: evidence 'behaviour_tested' is uncovered
                  evidence must name a command or an artifact

What it does not do

It does not decide whether the evidence is good evidence. It refuses evidence that is not a command or an artifact, records what the command actually returned, and will not derive DONE while a declared requirement is uncovered.

What this looks like

Concrete situations, one per audience. Each is declared in the moment's front matter, so the before and the after are data rather than prose a page could drift from.

  1. Four criteria, none checked engineering-lead

    before
    An issue with four acceptance criteria is closed because the work "feels done"; two of them were never implemented.
    after
    `plan done` refuses while any declared evidence is uncovered, and names which.
  2. Evidence that is a command, not a claim platform-team

    before
    The evidence field says "tested locally".
    after
    Evidence is refused unless it names a command or an artifact, and the recorded result carries the exit code and the commit.
  3. Done before its dependency ai-native-team

    before
    An item is marked complete although the item it depends on was reverted last week.
    after
    Status is derived from events and the dependency graph, so it changes when the dependency does.

How you would know

The observable symptoms this moment declares. They are the questionnaire on the index and the input of majordomus why diagnose; nothing else defines them.

  • Something was closed as done without anything checking its acceptance criteria. closed-not-proven
  • The tracker and the repository disagree about what is finished. tracker-vs-repo
  • The evidence recorded for a completed item is a sentence somebody wrote. evidence-is-prose

Where this lives in the tool

Everything below is read out of this moment's own front matter and resolved against the repository. A name here that did not exist would fail validation.

the commands that answer it

the capabilities of the executable that answer it

what it supervises — derived from the claims below

the claims that back this page, and the evidence behind each

the rules that govern it

  • majordomus.project-integrity
  • majordomus.verification-integrity
  • majordomus.dag-integrity
  • majordomus.verify-outcomes

the use cases that show the way out

If this one is familiar, so is the next

What this moment names, what names it, and what shares its area, audience or tags. The second and third are derived; only the first is written down.

All 38, and how they connect to the tool →