v0.9.14: write-claim contention forbids N workers writing disjoint files under one shared root — the natural fan-out pattern is impossible

[Hmbown]

Why this matters

The obvious delegation pattern — N parallel workers, one results directory, one disjoint output file each — is the one coord/ledger.rs:587 forbids: any write-roots overlap between active claims is rejected, including when their exact_files are disjoint. Models burn whole rounds discovering this: in one observed session, six read-only workers each writing their own file under tmp/anomaly/ were all refused, the model retried all five spawns identically, failed again, and only on the third round manually split into tmp/anomaly_w2…w6/ — eleven wasted spawns. Today's parallel wave work pays the same tax: our planner and designer both had to be given separate root directories for what is logically one output area.

Current behavior

crates/tui/src/tools/subagent/coord/ledger.rs:587 — the overlap check compares roots only; disjoint exact_files under a shared root still collide. The error text steers toward per-worker sibling roots, which the model must discover by trial and error.

Desired behavior

1. Two active claims whose exact_files are disjoint may share a write root (the files are the real exclusion boundary).
2. Alternatively (or additionally), a parent-declared shared root can auto-suffix per-worker subroots so the pattern needs no trial and error.

Acceptance criteria

• Two concurrent workers with write_roots: ["tmp/scan"] and disjoint exact_files both start and both write without contention errors
• Regression test in the coord ledger tests covering the disjoint-files-under-shared-root case
• Overlap with truly intersecting exact_files is still refused

Related

• agent tool description claims the write-contention refusal names release; it does not, and the liveness filter says it could not #6272 (the contention error's remedy text does not name release although the tool description claims it does — verified against ledger.rs:587's message)

[Hmbown]

Complementary finding from the harness comparison (codewhale-ops/designs/HARNESS-COMPARISON-20260916.md): alongside allowing disjoint exact_files under a shared root, fan-out needs bounded, self-describing results — every child result schema'd with truncated booleans (kimi fs.ts pattern) flowing as events under a hard concurrency ceiling (codex MAX_UNIFIED_EXEC_PROCESSES = 64, unified_exec/mod.rs:83), so N waiters cannot multiply unbounded output. Tracked separately as the capture-time caps issue #6282; linked here because the fan-out pattern this issue unlocks multiplies whatever each result can pull.