parallel-featureslisted

<!-- Methodology adapted from arittr/spectacular (decomposing-tasks, executing-parallel-phase, cross-phase-stacking) + SPECTER shared-state analysis (2026-07 audit). --> # Parallel Features — Running Independent DAG Branches Concurrently Serial cycles cost sum(feature-hours); parallel costs max(). This skill defines when parallelizing is safe in SPECTER and the discipline that keeps the gates intact. ## 1. Eligibility — BOTH tests must pass **Test A — DAG independence.** In `docs/prd/feature-map.md`, neither Feature depends on the other, directly or transitively, and neither is the stub-and-forward *activator* of a structure the other consumes. Features the map marks as parallel-eligible pass; when in doubt, trace the dependency graph by hand. **Test B — file-overlap check (plan-time).** Compare the planned touched-file sets: each Feature's `plan.md` (or, pre-plan, the Feature section's In-scope deliverables). `intersection ≠ ∅` → **serialize** — shared files mean rebase conflicts and blurred review scope. Different top-level dirs (backend/ vs frontend/) or different repos are automatically independent. Same shared module (config, schema, router registry) → treat as overlap even if line ranges look disjoint. If either test fails: run serially. Do not rationalize ("the lines don't actually conflict") — the point of isolation is uncommitted-state separation and reviewable scope, not just merge conflicts. ## 2. One-time setup: union merge for append-shaped files Thr