Project-state observation, not architectural prescription.
During the 2026-05-20→21 5-way concurrent-batch burst, 5 race-condition recoveries occurred in ~24h:
| # | Batch | Race-type | Recovery technique |
|---|---|---|---|
| 1 | BATCH τ | concurrent BATCH acquirer-dd-package collision | clean re-baseline (git checkout HEAD on conflicted files + re-apply at next-available A-NNN) |
| 2 | BATCH acquirer-dd-package | 3-way commit-time race (q-046-substrate + OASIS evidence-pack landed during synthesis) | worktree-isolation + rebase + renumber A-229+task-116 → A-231+task-118 |
| 3 | BATCH δ′ | git reset --hard dropped local commits | git reflog + git cherry-pick a89e9a8 (see feedback-reflog-cherry-pick-recovery-pattern) |
| 4 | BATCH τ′ | main working-tree blocked by BATCH δ′ unresolved rebase | worktree-isolation at /tmp/batch-tau-prime-docs-strategy; bumped to v4.28+A-236 next-available |
| 5 | BATCH π″ | 3-way collision: ω′ A-234 + δ′ A-235 landed mid-execution; later SECOND collision with τ′ A-236 | git checkout HEAD + git pull --rebase + renumber to v4.30+A-237+task-124 |
All 5 recoveries completed cleanly net of cherry-pick recovery in #3. Methodology held. No work lost.
The pattern: at 4-5+ concurrent autopilot sessions, collisions on shared arch-state §15 + ledger become routine — not exceptional. The baseline rate from prior weeks (2-session bursts) was ~0.5 race-conditions per day; the 5-session burst spiked the rate by 10×. Empirically, 4 concurrent sessions seems to be the threshold where the in-tree race-condition surface dominates the bookkeeping overhead.
Recommendation for future 4+ session bursts: A-NNN range pre-allocation.
Before launching the autopilot wave, the launching session (typically the one authoring all the launch prompts) should pre-allocate amendment-number ranges per session:
Session A (BATCH ω′): claims A-234..A-236 (3-row range)
Session B (BATCH δ′): claims A-237..A-239
Session C (BATCH ε′): claims A-240..A-242
Session D (BATCH τ′): claims A-243..A-245
Session E (BATCH π″): claims A-246..A-248
Pre-allocation eliminates the renumber-on-collision pattern entirely: each session writes into its claimed range with no in-tree collisions on §15 body (only on lastmod_summary scalar where a git pull --rebase resolves cleanly). Same for ledger task-NNN ranges + version bumps.
Alternative: worktree-isolation per session (simpler; doesn’t require launch-time coordination):
Each session starts in /tmp/batch-<name> via git worktree add (see feedback-worktree-isolation-under-concurrent-storm). Collisions only surface at push-time; recoverable via git pull --rebase + renumber. Less efficient than pre-allocation but doesn’t require pre-launch synchronisation.
When this becomes load-bearing: Anthropic-acquirer-track delivery in 2026-Q2 implies more concurrent substrate work, not less. Without pre-allocation discipline, expect race-rate to scale with concurrent-session-count.
Honesty caveat: this is empirical observation from ONE 24h window. The pattern may not generalise — a different work-mix (more code-inherit-v2 schema edits vs docs-strategy edits) might have different collision surfaces. Treat as project-state data-point pending more empirical evidence.
Routing: loaded via MEMORY.md index. Fires during autopilot wave planning (launch-prompt authoring for ≥4-session burst). Companion to feedback-worktree-isolation-under-concurrent-storm (per-session discipline) + feedback-reflog-cherry-pick-recovery-pattern (post-incident recovery) + feedback-verify-after-author-via-directory-ls (within-session verification).