parallel-trackslisted

# Parallel Tracks This is a generic, project-agnostic methodology for deciding when sliced work can be dispatched to parallel, worktree-isolated subagents instead of one sequential subagent after another. It does not replace a project's own stage gates (design review, code review, verification) — a track still has to pass those on its own before it merges. ## When To Load Load this when an orchestrator command (e.g. `/develop-phase`, `/implement`) has already sliced work into more than one piece and needs to decide dispatch order — not when there's only one piece of work, and not as a default for every implementation run. Parallel dispatch is an opt-in optimization for genuinely independent work, not the normal path. ## The Independence Test Two pieces of work are an independent track pair only if **both** hold: 1. Neither track reads or writes the other's owned code, database, or module. 2. Both tracks build only against an interface that is already frozen — neither track is itself still changing that interface. If either condition fails, the tracks are dependent: the prerequisite track must merge before the dependent one starts, and they run sequentially in the main tree, dispatched the normal way (see each command's own `## Execution Note`). A change to a shared library or shared abstraction (something more than one track would otherwise touch) is never split across two parallel tracks — treat it as its own prerequisite track that merges first, then re-evaluate ind