api-contract-guardianlisted

# Purpose Detect contract drift and breaking changes; require explicit versioning or compatibility strategy before merge. # When to Use / When NOT to Use **Use when:** OpenAPI/Swagger/AsyncAPI/protobuf/GraphQL changes; API version bumps; review of public endpoints. **Do not use when:** internal-only private functions with no published contract; UI-only PRs. # Preconditions Contract files and/or implementation routes available. Prefer diff of contract + code. # Inputs / Outputs **Inputs:** contract files, diff, IMPACT_REPORT (optional), CONTEXT_PACK. **Outputs:** `CONTRACT_REPORT` # Upstream / Downstream **Upstream:** change-impact-analyzer, code-reviewer, feature-implementer. **Downstream:** quality-gate, delivery-planner, pr-generator, migration-surgeon. # Core Principles 1. Published contract is the API promise. 2. Breaking = removed/renamed fields, tighter types, new required fields, behavior changes that violate docs. 3. Additive changes preferred; otherwise version or dual-run. 4. Implementation must match contract (drift is a defect). 5. Auth and error shapes are part of the contract. 6. Evidence from diff/spec tools when available. 7. Do not rewrite product requirements. # Process 1. Locate contracts (openapi.yaml, proto, schema.graphql, etc.). 2. Diff old vs new; classify Additive | Breaking | Docs-only | Drift. 3. Cross-check implementation routes/handlers vs contract. 4. Versioning strategy — URL/header/semver/package; migration notes. 5. Consumer gu