M002 — A durable record names the worker that wrote it

PLANNED 0 of 4 issues done

ready

1

blocked

3

active

0

verify

0

done

0

cancelled

0

Problem

Every durable record is attributed to the task that is active in the checkout, because decision, checkpoint and question all read .majordomus/state/current.yaml to find out whose work they belong to. Several workers share one checkout, so the record names whoever started a task there rather than whoever ran the command. In one evening three sessions wrote under another session's active task, and one decision had to be dropped by hand after the fact because the premise it recorded belonged to somebody else. Attribution is the one property of a record that cannot be reconstructed later: the conversation that would settle it is gone.

Outcome

A durable record either names the worker that produced it or is refused, and a record written from one session can never arrive attributed to another session's task.

Current state

Not started. lib/decision.sh, lib/checkpoint.sh and lib/question.sh each resolve the active task from the checkout and write it into the record. Nothing distinguishes two workers sharing that checkout, and nothing reports that it cannot.

Desired state

Attribution is verifiable from the record alone. Where the tool cannot establish who wrote something, it says so and refuses rather than guessing from what happens to be active.

Scope

• lib
• share
• test/cases
• docs

Out of scope

• A registry of named workers, personas or agents
• Any identity the repository has to maintain, or that outlives the session that used it
• Locking a checkout to one worker

Acceptance criteria

• A record written while another worker's task is active is attributed correctly or refused by name
• The attribution can be checked from the record alone, with no conversation history
• No new record type and no registry of workers is introduced
• A behavioural case reproduces two workers writing in one checkout

Validation

• bash test/run.sh
• bin/majordomus doctor

Evidence required

• suite

Risks

• The obvious fix is an identity the tool maintains, which is a registry of named workers by another name and is refused everywhere else in this repository. Whatever is chosen has to be supplied by the session and stored only inside the record it explains.
• Refusing to write an unattributable record can lose a decision somebody was trying to make. The refusal has to say what to run instead, in the same breath.

Issues

Each one is an execution contract with its own acceptance criteria, validation command and required evidence. The wave column is the layer of the dependency graph it sits in.

The graph

flowchart LR
    I0701["I0701<br/>Reproduce the misattribution as an executable case"]:::ready
    I0702["I0702<br/>Decide how a record is attributed, between named alternatives"]:::blocked
    I0703["I0703<br/>Implement the decision and prove it holds"]:::blocked
    I0704["I0704<br/>Publish what attribution guarantees, and what it still cannot"]:::blocked
    I0701 --> I0702
    I0702 --> I0703
    I0703 --> I0704
    classDef done stroke:#16a34a,fill:#052e16,stroke-width:2px
    classDef active stroke:#2563eb,fill:#eff6ff,stroke-width:2px
    classDef verify stroke:#7c3aed,fill:#f5f3ff,stroke-width:2px
    classDef ready stroke:#0891b2,fill:#ecfeff,stroke-width:2px
    classDef blocked stroke:#b45309,fill:#fffbeb,stroke-width:2px
    classDef cancelled stroke:#6b7280,fill:#f9fafb,stroke-width:2px

Canonical record: .ai/repo/project/milestones/M002.yaml. Read it back with majordomus plan show M002.