spec-merger

# Spec Merger Before the final `executing → closing` transition, delta specs (ADDED/MODIFIED/REMOVED/RENAMED) must be published into the main spec base. `changes/<change>/` remains the active workflow source; root `specs/` is only the published baseline. **Specs that aren't synced become lies.** A change already in `closing` must not be routed to `spec-merger`. ## Execution-State Guard Before `ssf sync` or any other write, run `npx --yes --package spec-superflow@0.12.0 ssf state get <change-dir> state`. Continue only when the persisted state is exactly `executing`. If it is `closing` → STOP: "Closing is terminal. Do not route this change to spec-merger; synchronization belongs before the final executing → closing transition." For any other state, or if the state cannot be read → STOP and route through `workflow-start`; do not perform side effects. ## Pre-Flight Checks ### Conflict Detection Run `npx --yes --package spec-superflow@0.12.0 ssf sync <change-dir>`. If conflicts are detected (same requirement modified by multiple changes), present the conflict list to the user for resolution order. ## Sync Process ### Step 1: Identify Deltas Each `specs/<capability>/spec.md` under the change folder contains delta operations under `## ADDED/MODIFIED/REMOVED/RENAMED Requirements`. ### Step 2: Apply by Operation **ADDED**: Append the requirement to the published baseline's `## Requirements`. Create a canonical main spec if it does not exist. **MODIFIED**: Match on `### Requi...