Fan Out a Research-Repo Migration One Bounded Run at a Time
You need to migrate 200 experiment configs to a new schema, or move 200 eval tasks onto a new harness API. Claude Code's best-practices guide describes the fan-out pattern: generate a task list, loop claude -p over it with --allowedTools scoping what each run may do, and refine the prompt on the first two or three files before running the rest.
Do the reliability arithmetic first. If each run is correct with probability 0.98, independently, all 200 are correct with probability
0.98²⁰⁰ = e^(200 × ln 0.98) ≈ e^(−4.04) ≈ 0.018.
You should expect about 200 × 0.02 = 4 bad files. The question is not whether some runs fail but whether you will find the ones that did. Chapter 3 derives this compounding and what retries do to it.
Keep a ledger. One row per file: path, hash before, hash after, commit, and the result of your config loader's real validation on that file. Load each migrated config, and run one short smoke step for a sample of them. An agent printing OK is a report to check, not the gate that authorizes the next file.
Read the permission scope for what it is. The permissions guide says Bash rules match command text, and that a rule such as Bash(git commit *) allows the command, not its target. A flag like --allowedTools "Edit,Bash(git commit *)" decides which calls run without asking. It does not by itself keep an edit inside the intended file. For filesystem and network enforcement that does not depend on command text, the guide points to the sandbox.
Run from an isolated checkout with no production credentials. Include one file that should fail, such as a config with a key the new schema rejects, and confirm the ledger records it as a failure rather than a success.
