api-contract-testinglisted

# API Contract Testing ## Scope Boundaries - Use when API compatibility must be continuously validated between producers and consumers. - Use proactively when schema/endpoint/protocol diffs exist but executable compatibility evidence is missing. - Use when compatibility judgment is currently human-only and needs codified CI gates. - Do not use for API schema design from scratch; use `api-design-*`. - Do not use for end-to-end UI validation. ## Goal Catch contract drift before deployment impacts consumers. ## Shared API Contract (Canonical) - Use `../api-design-rest/references/api-governance-contract.md` as the canonical contract. - Optional consistency checks (only if your repository enforces manifest validation): - `python3 ../api-design-rest/scripts/validate_api_contract.py --manifest <path/to/manifest.json>` - Use API contract-testing templates in `../api-design-rest/assets/`. - Use transport decision reference: - `../api-design-rest/references/transport-selection-matrix.md` - Keep compatibility states and approval gates aligned with the canonical contract. ## Implementation Templates - Contract test matrix template: - `../api-design-rest/assets/api-contract-test-matrix-template.yaml` ## Inputs - Provider API specification and implementation - Consumer expectations and critical integration cases - Versioning and deprecation policy constraints - Transport mix and interaction modes under test (`sync`, `async`, `streaming`, `bidirectional_realtime`) ## Outputs - E