Namespace Kuestenlogik.Bowire.Contracts
Classes
- BowireContractMatrix
Builds the consumer × provider result matrix (#364) from a set of contract-verification reports. Pure aggregation — no I/O — so the endpoint, the CLI
contract matrixcommand and the MCP tool all project the same grid from whatever set of reports they gathered.
- BowireContractsEndpointContribution
Discoverable endpoint-mount entry point for the Contracts rail (#364). Picked up by Core's
BowireApiEndpointsscan via the IBowireEndpointContribution seam, so the matrix endpoint inherits the auth-gated route group and the host's base path without core knowing this package exists.
- BowireContractsEndpoints
The Contracts rail's HTTP surface: the consumer × provider matrix assembled from stored verification results.
- BowireContractsRailContribution
#364 — the Contracts rail: a consumer × provider matrix of contract verification results with per-interaction drill-in. Discovered by
BowireRailRegistry.Discover's assembly scan (public sealed type with a default constructor), so referencing the package is all a host has to do.
- ContractAssertion
A single contract assertion (status match or structural body match).
- ContractBroker
Minimal Pact Broker REST client (#191). Only two operations — publish a consumer contract and retrieve the latest contract for a provider — over the broker's documented, stable URL scheme. Reused rather than reinvented, per the issue.
Every method here reaches the network, so the whole broker path is gated behind an explicit
--broker-urlon the CLI: outbound calls stay opt-in, never a default.
- ContractBrokerException
Broker interaction failed (non-success status or unparseable body).
- ContractInteractionResult
One interaction replayed against the provider.
- ContractMatrix
The assembled consumer × provider matrix: the two axes plus the cell for every pair. Cells is dense — one entry per (consumer, provider) combination, in row-major order — so a renderer can lay out the grid without probing for gaps.
- ContractMatrixCell
One consumer × provider cell in the matrix (#364). Carries the roll-up (status + counts + last run) for the grid and the full Report for the per-interaction drill-in.
- ContractResultStore
On-disk store of contract-verification results (#364), under
.bowire/contract-results/. One JSON file per consumer × provider pair, overwritten by the newest run.This is what makes the matrix possible without the workbench reaching out on its own:
bowire contract verify(locally or in CI) writes results here, and the matrix endpoint only ever reads them. Rendering a grid never triggers an outbound call to someone's provider — outbound stays opt-in and explicit, exactly as on the CLI.
- ContractVerificationReport
Result of verifying one consumer contract against a provider (#364). The engine's own report type, deliberately decoupled from the CLI's generic
RunReport: it carries the consumer and provider as structured names (not folded into a "C → P" title) plus a start timestamp, which is exactly what the consumer × provider matrix needs for its axes and per-cell "last run". The CLI adapter maps this onto aRunReportfor the shared JUnit / SARIF emitters.
- ContractVerifier
Provider-side contract verification (#191). Replays every interaction in a consumer contract against the provider's live base URL and checks the actual response satisfies the contract: the status code must match, and the response body must satisfy the expected shape (structural match — the provider may add fields / vary values, but every field the consumer relies on must be present with the same JSON kind).
- PactContract
Pact-compatible consumer contract (#191). A deliberately small subset of the Pact v3 specification — enough that a Pact Broker accepts a published document and that
bowire contract verifycan replay each interaction against a live provider. Serialised camelCase so the wire shape matches what brokers expect (consumer.name/provider.name/interactions[]).
Enums
- ContractCellStatus
Cell verdict in the contract matrix. NotRun marks a consumer × provider pair that has no verification result — the grid is the cross-product of every consumer and provider seen, so pairs no one verified show up as blanks rather than silently vanishing.