aoa-contract-test

Interface contract testing formalizes expected inputs, outputs, and verification obligations across component boundaries. You need it when downstream assumptions are implicit and fragile, requiring explicit validation at module, service, or workflow boundaries to ensure consumers receive correct data.

To make interface contracts explicit, inspect the boundary between a service and its consumers, state expected inputs and outputs, and propose concrete tests or smoke checks tied to the interface rather than internal implementation details for verifiable downstream impact.

Write smoke tests by inspecting the service boundary, stating the expected request and response shapes, and translating them into structured checks. This produces verification steps and downstream impact notes so reviewers can confirm what the validation proves.

Yes, you need a test or smoke harness to express inputs, outputs, and verification checks. The skill requires repository file access and a test harness to formalize interface contracts and validate downstream assumptions at component boundaries.

The best way to document downstream impact assumptions is to translate expected inputs and outputs into concrete verification checks tied to the interface. This produces reviewable contract expressions and structured smoke summaries clarifying what validation proves.

Smoke tests often fail after downstream service changes because interface contracts are implicit and fragile. Making those contracts explicit through structured checks tied to the interface ensures downstream assumptions remain clear and testable across component boundaries.