Skip to content

Finished work that never reached the trunk

Workers produce far more than integration absorbs, and nothing distinguishes work that is done from work that is done and landed.

→ found finished work on a branch that nobody ever merged

cost when it happens
high
how often
common
area
coordination
work-tracking
recognised by
ai-native-team
engineering-lead
research-team

The moment

A change is complete, tested and sitting on a branch. It has been there for two weeks. The worker that wrote it reported success and stopped; nothing since has been obliged to notice that the work exists.

Why it happens

Producing work got cheap and integrating it did not. The bottleneck moved to review and merge, and nothing measures the queue in front of that bottleneck, so the natural response is to produce more. In the environment this tool was distilled from, eighty parallel efforts produced nine merges.

Why a better model does not fix it

Better workers widen the gap. The constraint is downstream of them: a human decision to accept, and the review capacity behind it. Adding capability to the producing side makes the unintegrated pile larger.

What it costs

Every unmerged change decays — it conflicts more each day — so the work is not merely idle, it is depreciating. And because the pile is invisible, the team plans as though the produced work were delivered.

What Majordomus does

Finishing is an event with a typed outcome, not a message: completed, partial, blocked, no_match, failed, recorded with the verification command that ran, its exit code and its duration. The ledger therefore distinguishes what was started, what was handed over and what was accepted, and history reads the three back separately. Where the repository carries a plan, an issue is not done until its declared evidence is covered, so "finished by a worker" and "done" are different states with different gates.

Before and after

before   worker: "complete"          -> branch, indefinitely

after    $ majordomus history --since 7d --event task_finished
         t-…a4f1  completed  verify="make test" exit=0
         t-…b207  partial    "the backfill is written; the cutover is not"

What it does not do

It does not merge, review or schedule integration. It makes the difference between produced and accepted a fact the repository states rather than one a person estimates.

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. Eighty attempts, nine merges ai-native-team

    before
    Parallel workers produce dozens of complete changes; a fraction are reviewed and fewer land, and nothing records which.
    after
    A finish records a typed outcome and the verification that ran; what has not been finished, and what was finished as `partial`, are both visible.

  2. Measuring the wrong thing engineering-lead

    before
    Throughput is reported as work produced, which is the number that flatters and the number that does not matter.
    after
    The ledger distinguishes started, handed over, and finished with an outcome, so the gap between produced and accepted is a readable figure.

  3. The shelf of finished experiments research-team

    before
    A promising branch is complete and never written up, so it is neither used nor discarded.
    after
    Its handover names the objective and the next action, and the outcome vocabulary has a value for "this worked and stopped here".

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.

  • Far more work was produced this week than was integrated, and the gap is not tracked anywhere. more-produced-than-merged
  • Something reported as finished is sitting on a branch that nobody has looked at. done-but-unmerged
  • Nothing distinguishes "the worker finished" from "the change is in the trunk". no-landed-signal

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.verification-integrity
  • majordomus.isolated-parallelism
  • majordomus.verify-outcomes
  • majordomus.project-integrity

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 →