Implementation work executes serially; parallelism only for read-only work

Status: accepted

The loop operating model could run multiple implementation workers in parallel (the docs/research/2026-06-15-loop-engineering.md note frames worktrees as a parallelism enabler). We chose instead to run implementation serially — one worker, one bounded slice, against a clean and fully-validated codebase, with the next worker starting only after the previous slice passes validation. Parallelism is restricted to read-only work: validation, code review, research, exploration. This follows Factory's "Missions" evidence (docs/wip/factory-ai.md): "parallel software agents generating changes simultaneously result in compounding coordination overhead… duplicated work, and broken architectures."

Considered Options

• Parallel implementation workers (worktree-per-feature). Highest throughput; matches the loop-engineering note. Rejected: simultaneous writers create merge conflicts, duplicated work, and architectural drift that no validator can cheaply untangle — the coordination cost compounds with worker count.
• Serial implementation, parallel read-only work (chosen). Each worker inherits a clean, validated baseline; coherence holds over long runs. Lower raw throughput, but the throughput we keep is trustworthy.

Consequences

• Worktrees / isolation: worktree are used for clean context per worker, not to run multiple writers at once.
• Each worker must produce a structured Handoff report so the next serial worker inherits a legible baseline (see the operating-model doc's Memory section).
• Raw parallel throughput is traded away deliberately; revisit only if serial execution becomes the dominant bottleneck and a coordination mechanism exists that demonstrably avoids the compounding-overhead failure mode.