Full-tier specs produce four documents in sequence — requirements.md, tech.md, design.md, tasks.md — each building on the ones before it. That sequence is a strength right up until one of the earlier documents changes after the later ones already exist. spec-sync is what keeps that change from silently rotting the rest of the spec.
The problem it solves
Say requirements.md gets reverted from approved back to draft because a genuinely new constraint came up, and a requirement changes. tech.md might have made a stack decision that assumed the old requirement. design.md might have architected around it. tasks.md might reference acceptance-criteria numbers that no longer line up. None of these downstream documents know anything changed — they were approved against a version of reality that no longer exists.
What spec-sync actually checks
Run after any full-tier document is edited by hand or revised mid-review, spec-sync walks the other documents for the same piece of work and checks whether they still hold up against the change. It's not a rewrite — it's a targeted drift check, surfacing specifically what might now be stale rather than regenerating everything from scratch and discarding decisions that are still perfectly valid.
Why numbering discipline matters here
This is also why SpecDevShip is strict about requirement and acceptance-criteria numbering staying stable once tasks.md or tests reference it. If you must renumber after those exist, that's exactly the trigger for running spec-sync — a renumbering that isn't propagated is a silent break, the kind that shows up three weeks later as a task referencing an acceptance criterion that no longer exists.
The habit worth building
Treat any hand edit to an approved-then-reopened full-tier document as incomplete until spec-sync has run against it. It's a small extra step, and it's the difference between four documents that actually describe the same piece of work and four documents that used to.