Anchor runs

A check stands for as long as the code it ran on stays the same, and an anchor is more than one command. The book therefore records the tree each run saw instead of trusting the clock.

Trees, standing checks, and adopted runs

Every anchor run records the working-state tree of the repo it ran in: a leading cd moves it, and an adopted worker run keeps the worker’s worktree. A run stands while that tree is unchanged and no later edit names that repo. A write in another repo or a worker’s edit in its own worktree leaves it standing, and a change through a shell command voids it.

A parent’s git merge, cherry-pick, or pull that succeeds, or a returned subagent result, can make a child’s run the parent’s own verify (adopted). That happens when the parent’s working-state trees are exactly the trees of the child’s latest run of the same anchor (a leading cd into a repo root aside), and that run passed. A fast-forward of a worker’s branch, or a child that worked in the parent’s checkout, needs no second run. A merge onto a base that moved, a parent edit or repo the child never saw, or a file the child ran with but did not commit does.

Run checkpoints and observe checkpoints

An anchor is a run checkpoint plus observe checkpoints, which are written on the kind call or in todo metadata. Each observe checkpoint is closed by verify with its checkpoint number, after the last landing. A prose anchor is not quoted back as a command.