What problem does it solve? Running per-item pipeline stages serially costs wall-clock time linear in the number of items, but naive parallelization risks write conflicts, git state corruption, and nondeterministic reports. This contract states exactly when a caller may fan work out across concurrent agents and what obligations it must satisfy. ## Core Features & Use Cases - Four safety conditions: Provably disjoint write sets, no git state changes in members, order-independent aggregation sorted by change id, and join-then-gate semantics. - Config-driven control: parallel.mode (off/on, default off) and parallel.maxConcurrency (1-10, default 3) resolve through layered ptp config with a forgiving reader that never throws. - Per-invocation token: A parallel:on|off token overrides the resolved mode for one invocation without persisting anything, and can never override the safety conditions. - Use Case: When planning multiple OpenSpec change slices via /ptp:plan-multiple, a caller with pre-allocated change ids can run up to 3 members concurrently in joined batches, producing a byte-stable report identical to a serial run. ## Quick Start Ask the AI to plan multiple OpenSpec change slices in parallel using the parallel:on token with a concurrency cap of three.
