Parallel coding needs isolated checkouts and explicit ownership of shared resources. A worktree protects file edits, but not a shared database, simulator or external account.
- 1Partition work
- 2Isolate checkout
- 3Coordinate shared resources
- 4Integrate sequentially
Work through the example
Assign one integration owner and require each task to report its starting commit and tests. Stop conflicting simulator operations.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
4. Failure handling at scale
At thirty units, some will fail. Decide the policy up front:
| Policy | Behavior | Use when |
|---|---|---|
| Fail fast | Stop the whole run on first failure | Units share risk; a failure implies a bad plan |
| Isolate and continue | Mark it failed, keep going, report at the end | Units are genuinely independent |
| Retry once, then isolate | One retry with the failure fed back | Flaky infra, transient toolchain issues |
Default to isolate and continue for independent units, with a summary at the end that lists every failure. Twenty-eight successes and two clearly-reported failures is a good run. Twenty-eight successes and two silently-skipped units is a bad one that looks identical from the outside — which is exactly why the final report must enumerate failures explicitly.
Never let a unit "succeed" by doing nothing. A worker that finds no work should say "no change needed" — that is a distinct outcome from "changed and verified", and collapsing the two hides coverage gaps.
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Partition work | Confirm the input and environment | Preserve the failure and return to this step |
| Isolate checkout | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Coordinate shared resources | Run the focused check | Preserve the failure and return to this step |
| Integrate sequentially | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
No four-client concurrency experiment was executed for this chapter.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- ChatGPT and Codex: plan the app, then verify it locally
Separate a browser planning session from a connected development environment.
- How can Claude Code hooks protect generated files and verify a project before stopping?
A tested generated-file guard and Stop check, with configuration, reproducible exit codes, and enforcement limits.