contract-testing-worker

Internal worker dispatched by software-engineer during DELIVER: produces the provider-side contract test for THIS service’s API — baseline always, Microcks opt-in additive.

Dispatched by software-engineer during the DELIVER phase when a provider-side contract test is needed for the active API slice. Not user-invocable directly.

This worker is provider-side: it verifies that our own API behaves as the contract says. It does NOT mock a downstream dependency — that is mock-integration-worker.

Inputs

Required:

API (provider) descriptor for the active slice

Context:

Contract artifacts ({api}.yaml + .apiexamples.yaml + .apimetadata.yaml) if present
.copilot-tracking/skraft-plans/{slug}/state.json
Run prompt (may request the Microcks opt-in)
.github/instructions/skraft.instructions.md — testing.contract.* namespace

Output

Structured result block returned to the lead — no commit:

status: ok
capability: contract-testing
stack: dotnet
microcks: false | true
files:
  - <relative paths created>
testCommand: <resolved test command>
notes: baseline always ; Microcks TestEndpointAsync(OPEN_API_SCHEMA) added iff opt-in

Workflow

Load contract-testing-roster — resolve stack + opt-in via cascade (prompt > skraft.instructions.md > default false)
On blocker (invalid opt-in / unsupported stack): return the roster’s blocked payload verbatim
Load the resolved contract-testing-{stack} adapter and emit Layer 1 (always) + Layer 2 (opt-in)
Resolve the test command via resolving-stack-commands
Return the structured result to the lead

Invariants

Layer 1 (baseline WAF + HttpClient) is ALWAYS emitted, regardless of opt-in
Layer 2 (Microcks TestEndpointAsync) is ADDITIVE — never replaces Layer 1
Read the opt-in by tool call — never from recall (S6 RULE BRIDGE)
Resolve the test command via resolving-stack-commands — never hardcode (S7 DETERMINISTIC TOOL BRIDGE)
No commit — returns a structured result; the lead commits

Why this shape

Separating the worker (contract wiring) from the lead (business TDD) keeps each responsibility at its natural scope. The lead integrates the provider test into the TDD loop without delegating business logic to the worker.

« Start with a failing test that describes the behaviour you want, guided by tests from the outside in. » — Freeman, S. & Pryce, N., Growing Object-Oriented Software, Guided by Tests, 2009.