dispatching

Dispatching

Parallel work fails in four places, in order: the split was wrong, the workspaces overlapped, the brief was incomplete, or the report was believed. Each step below closes one of them.

Splitting work you could have done yourself in one pass costs more than it saves. Dispatch when the pieces genuinely do not need each other, or when one of them needs a fresh context to be judged honestly.

Step 1 — Prove the pieces are independent

Independent means all three: no shared dependency, no shared file, and each piece understandable without reading the others. Two failures in the same module, or a fix that might turn out to fix the others too, are one piece — dispatch them as one.

Write the split down before dispatching: which piece owns which files. A piece whose file list you cannot state is not scoped yet.

• Done when every piece has a file list and no file appears on two lists.

Do not pre-negotiate conflicts beyond that list. Predicting which lines will collide is guesswork that costs more than resolving the collision later.

Step 2 — Give every writer its own worktree

Two agents writing into one checkout will overwrite each other's edits and stage each other's files. Isolation is not a precaution here, it is the precondition: if the pieces write, each gets its own worktree.

arcforge worktree add <name> [--branch <b>] [--from <ref>] [--setup] --json
arcforge worktree list --json
arcforge worktree remove <name> [--force]

Read the path field out of the JSON. The location is derived by the engine, so a path you construct, remember, or guess will be the wrong one and everything downstream that looks for the worktree will miss it. --setup runs the project's installer inside the new tree; list annotates each entry by kind, and cd to a path is how you enter one — there is no switch command.

Already inside a worktree? Work there. Never nest a worktree inside a worktree. A path the user names explicitly overrides all of this — honor it with raw git.