Skip to content

One worker undoing another worker's change

A worker sees an unexplained change in its path, judges it wrong, and removes it — correctly, on the evidence it had.

→ watched one worker revert another worker's change, on purpose

cost when it happens
high
how often
occasional
area
coordination
recognised by
ai-native-team
engineering-lead
platform-team

The moment

A worker adds a guard for a case it found the hard way. An hour later a second worker, tidying the same function, deletes it: there is no test for it, no comment on it, and it looks like defensive noise. Both changes are reasonable. One of them is a regression.

Why it happens

The second worker had no way to learn that the first change was deliberate. An edit with no recorded reason is indistinguishable from an accident, and a capable worker cleaning up a file will remove what looks accidental. Isolation does not help here: the change had already landed, so both workers were looking at the same tree.

Why a better model does not fix it

A stronger second worker is more likely to remove the guard, not less — it will be more confident that the code path is unreachable, and it is reasoning from the same absent evidence. What was missing is the sentence saying why the guard exists.

What it costs

The defect returns, and it returns silently, because the change that reintroduced it looks like a cleanup. Recovering costs the original investigation a second time, plus the archaeology to work out which of two plausible changes was the wrong one.

What Majordomus does

Two mechanisms meet here. Scope makes concurrent ownership visible: majordomus start requires the paths a task may touch, and another worktree holding an overlapping scope is reported at the moment work begins. Decisions make past intent legible: decision add refuses a decision with no --why, records the rejected alternative, and computes the task and head from git. The next worker is assembled with the recent decisions before it starts.

Before and after

before   A: + if (session == null) return;      (reason: in A's head)
         B: - if (session == null) return;      (reason: looks unreachable)

after    B: majordomus start ... --scope lib/session
            OVERLAP ../checkout-a holds lib/session (task t-0091, active)
            decisions: "the guard covers the legacy mobile callback" — t-0091

What it does not do

It does not lock files and it does not block a change. Whether a guard should stay is a judgement; the tool's job is to make sure the judgement is made with the reason in view.

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. The guard that looked redundant ai-native-team

    before
    Worker A adds a null guard for a case it discovered; worker B, refactoring the same function an hour later, removes it as dead code.
    after
    The guard was added under a declared scope; B''s start reports that A holds those paths, and the reason is a decision record B is given.

  2. Two conventions, one file platform-team

    before
    Two workers apply two different formatting conventions to the same file across a week, each undoing the other.
    after
    The convention is a scoped context document for that directory, resolved by both.

  3. A revert that reached review engineering-lead

    before
    A reviewer sees a change that removes a fix, with no explanation on either side, and has to reconstruct which is right.
    after
    The ledger carries both events with their tasks and heads, and the decision record says why the guard exists.

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.

  • A change made this week was removed by another worker who thought it was a mistake. change-reverted
  • Workers regularly encounter edits in their path that nothing explains. unexplained-edit
  • The same line has been changed back and forth by different sessions. ping-pong

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.scope-integrity
  • majordomus.one-worker-one-scope
  • majordomus.externalise-decisions

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 →