Third-party integrator test double

client-integration-app is the active half of the pair: where the customer-infrastructure double receives what an application sends, this one authenticates and drives. It holds an authentication face, a role-checked API client, an agent-protocol client, a model-context-protocol agent driven by a real language model, and a webhook receiver of its own. It reaches the application over HTTP only, holds no literal secrets, and takes its credentials from the scenario at bind time.

The problem it solves

An application’s outward-facing surface is the one part of it that no in-process test can honestly exercise. Authentication, audience binding, role checks, tenant scoping and tool exposure all behave differently to a caller that shares the process and its types than to one that does not, and the differences are exactly where the interesting failures are: a token minted for one surface accepted on another, a tool that advertises one contract and enforces a second, a webhook signed with a key nobody validated.

There is a second reason to build the caller rather than script the calls. When the surface is an agent protocol, the realistic consumer is a language model choosing tools from a catalogue it just discovered, and what it chooses is not what a hand-written script would send. A double that discovers and drives the way a real integrator does is the only way to find out whether the catalogue is usable.

What it does

An outside integrator, driven as a real client: it authenticates the three ways an application actually offers, calls the agent surfaces, and receives the outbound webhooks.

One frozen contract crosses the boundary. The double runs as a spawned subprocess exposing a command endpoint; the scenario posts a command and reads back an observation. The shapes were frozen after the first real path was built rather than sketched in advance, and later faces extended them additively.

Authentication covers all three methods: machine credentials with discovery, a delegated authorisation-code exchange with a proof key where the audience is required, and an API key echoed as a raw secret. Tokens are cached per principal and the header is resolved per method, so a scenario asks for a PRINCIPAL rather than for a mechanism.

The tool-protocol face is a real agent. It discovers the catalogue and drives real work through it, and reports its tool trace so a scenario can assert what the model actually called. Because a real model can also run out of credit, that outcome is reported as INCONCLUSIVE rather than as a failure: a lane whose skips are indistinguishable from failures teaches everyone to ignore it.

The webhook receiver is a second server inside the same process. It verifies the signature against the application’s own published key, fetched at run time from the administrative read rather than pinned in the double, and records what it received on the same inspection shape the other double uses — so the harness orchestrates both the same way.

Limits

It has no business logic of its own. It proves that an outside caller reaches, or is refused by, the application’s surface; what the application then stores is asserted through the application’s own adapter.

Both model-driven legs run real models on purpose, so those scenarios need credentials and cost money — which is why they sit outside the deterministic lane families and why credit exhaustion is a distinct outcome.

The tool-protocol client has no instance selector, because the command contract is frozen — so it always drives the default server. Tools curated onto named servers are outside what it can reach.

Its own status notes describe the build in phases, some of which predate later work. Read the source for what a face does today; the status prose is a record of how it arrived.