spec-reconcilelisted

<!-- PATCHED(repository-standards): this skill is NOT vendored from github/spec-kit - ADR-015 extracted only five prompts (specify, clarify, plan, tasks, implement); spec-reconcile has no upstream equivalent. --> # spec-reconcile Run before completing a change. After merge, `specs/` must be current production truth - so the spec, the code, and the tests must agree. ## Steps 1. For each changed capability spec, compare **spec vs the code diff vs tests**. 2. Detect: - spec says X but the code does Y, - code or tests encode behavior missing from the spec, - spec requires a scenario with no implementation, - the implementation adds a side-effect described nowhere, - code that exists only to keep an **already-shipped** contract working - a compatibility shim, a deprecated alias, a function body with no header, a route kept alive for an old client. 3. Resolve each: update the spec, fix the code, or explicitly record why. Prefer making the spec accurate to the real behavior - **and where that preference would rewrite what "done" means, or move the capability's boundary, ask before it does.** The calls are in "Questions this skill must ask", below. Bending the criteria to fit what was built is the one resolution this skill cannot take on its own authority, because it is the party that built it. **A compatibility artifact is documented as one, or the record gets worse.** Where the source of truth for some behavior is someth