Skip to content

Handover

append-only records with computed front matter and required sections, created atomically, never staged; --resolve finds the right one for this worktree and branch and labels how far git has moved since

append-only records with computed front matter and required sections, created atomically, never staged; --resolve finds the right one for this worktree and branch and labels how far git has moved since

Where it lives

The command that acts on it

majordomus handover

Write an append-only continuation record, and resolve the most relevant prior one.

  • state-mutating
  • active task optional
majordomus handover [--derive] [--close] [--no-task] < body.md

See it refuse, and accept

A handover is the one artifact designed to be read by someone who was not there. It carries the sections the policy requires and no transcript.

Given this repository

# ... and an active task scoped to lib, with work done inside that scope.
. "$FIXTURE_SETUP/installed.sh"
"$MJ" start "narrow the parser" --scope lib >/dev/null
echo work >> lib/a

Run

$ majordomus handover < body.md

Output contains

  • .ai/local/state/handovers/

exit 0

Objective, Current State and Next Action. The front matter — task, branch, head, worktree — is computed, so the body cannot disagree with git about where it was written.

Given this repository

# ... and an active task scoped to lib, with work done inside that scope.
. "$FIXTURE_SETUP/installed.sh"
"$MJ" start "narrow the parser" --scope lib >/dev/null
echo work >> lib/a

Run

$ majordomus handover < body.md

Output contains

  • missing or empty section

exit 10

The sections are named in the refusal. A handover without a Next Action is the failure mode this record exists to prevent, so it is not accepted and quietly filed.

What enforces it

What is guaranteed

The moments this answers