Your OpenAPI spec says one thing and your handlers do another. This workflow reconciles the drift between spec and code, hardens each endpoint with request validation and standardized error handling, then classifies every change as breaking or non-breaking so you know exactly what the release does to consumers.
Point spec-sync at your OpenAPI or GraphQL file and it compares every documented endpoint against the actual handlers. It surfaces missing routes, undocumented parameters, wrong types, and stale response shapes, then reconciles the spec so it matches what the code really does.
Take a handler that reconciled cleanly and make it production-ready. harden-endpoint adds request validation, wraps failures in RFC 9457 problem+json error envelopes, and applies idempotency keys, pagination, and rate-limit headers where they belong.
Before you tag the release, run version-guard over the diff to sort every change into breaking versus non-breaking. It flags removed fields, tightened validation, and altered response shapes that would break existing consumers, so you bump the version correctly and warn clients ahead of time.
Run /spec-sync first and treat its output as the source of truth. Reconciling the spec before you harden means you harden against the real contract, not the stale one.
Point /harden-endpoint at one handler at a time. Reviewing the validation schema and problem+json envelope per endpoint catches wrong assumptions before they spread across the codebase.
Give /version-guard a git range that spans the whole release, not just the last commit. A change is only non-breaking relative to what consumers last saw, so compare against the previously shipped tag.