| name | contract-testing-roster |
| description | Use when an agent must produce a provider-side contract test for THIS service's API and needs to know the stack adapter and whether the optional Microcks verification layer is enabled. Resolves the stack and reads the Microcks opt-in (off by default), then points to the concrete `contract-testing-<stack>` adapter. Loaded by the contract-testing-worker. A baseline in-process integration test is always produced; Microcks contract verification is an additive opt-in. |
Contract Testing Roster (stack agnostic, opt-in Microcks)
The single place that resolves how a provider-side contract test is built.
A baseline in-process integration test (the app started in-memory, exercised over
real HTTP) is ALWAYS produced. A Microcks contract-verification layer is an
ADDITIVE opt-in, stacked on top — never a replacement, never a default. The
concrete harness (e.g. WebApplicationFactory, @SpringBootTest, supertest) and the
concrete Microcks call are owned by the per-stack adapter, NOT by this roster.
This mirrors resolving-stack-commands: the roster owns routing + the opt-in
read; the per-stack adapter owns the concrete wiring of both layers.
One axis (stack) + one boolean (opt-in)
Unlike mocking, there is no exclusive strategy choice here. Only:
- Stack — WHICH toolchain, detected via
resolving-stack-commands.
- Microcks opt-in — a boolean ADD-ON.
false = baseline only (default);
true = baseline + Microcks contract-verification layer (the adapter picks the
stack-appropriate Microcks API).
Resolving the opt-in (cascade)
Read the opt-in by tool-call, never from recall. Precedence, first writer wins:
- Explicit prompt — the run prompt asks for Microcks contract verification.
- Repo instruction file — read
.github/instructions/skraft.instructions.md field
testing.contract.microcks. Read ONLY the testing.contract.* namespace.
- Default —
false.
Read the file with a tool call (fact-that-must-be-true, S7). If absent, default.
Detection -> adapter
Detect the stack (delegate to resolving-stack-commands), then resolve the
per-stack adapter. The adapter carries BOTH layers and branches on the opt-in
flag internally:
Adding a stack = add ONE contract-testing-<stack> adapter and the row here,
with zero edits to the worker or the orchestrator.
Generic source
Both layers consume the GENERIC contract artifacts authored by the
contract-testing skill (OpenAPI / .apiexamples
/ .apimetadata). The roster does not duplicate that authoring.
Unknown value -> stop, never guess
If testing.contract.microcks is neither true nor false, or the detected
stack has no adapter, STOP and emit a structured blocker:
status: blocked
type: invalid_contract_optin
message: Could not resolve the contract-testing configuration
context:
microcks: "maybe"
stack: dotnet
source: prompt | skraft.instructions.md | default
Contract for callers
- Resolve
(stack) + opt-in here; do not embed the decision in the worker.
- Baseline in-process integration test is ALWAYS produced regardless of the opt-in.
- Adding a stack = add an adapter and a row here, zero edits elsewhere.
