Docs
Guides for using, testing and contributing to Mockingbird. Each page is a file in docs/, the same markdown GitHub renders, so the two never differ. Each service's own guide is its README, on itsservice page.
- Why MockingbirdYour tests are only as honest as the fakes they run against. Most suites that touch Stripe, Twilio or a lab partner either call a shared sandbox or stub the client. Both fail in ways that are expensive to notice. Mockingbird is a third option.
- Testing and parityHow every mock is proven to behave like its vendor: differential contracts, property-based walks, and live parity against real sandboxes.
- Authoring a Mockingbird serviceHow to add a vendor mock to this repo. The reference implementation is [`packages/service/rxvortex`](../packages/service/rxvortex): copy its layout and patterns.
- Service catalog coverageWhere each section of the geviti "Mockingbird wish list — service catalog" (2026-09-20) lives in this repo, how it is proven, and what the proof turned up. Every package follows [AUTHORING_A_SERVICE.md](AUTHORING_A_SERVICE.md) and ships the same evidence:
- Developing MockingbirdWorking on this repo: requirements, how the packages are layered, and the quality gates every change passes.
- Reporting issuesHow coding agents in other projects file a GitHub issue when a mock diverges from its oracle, lacks a feature they call, or breaks, or when they need a service mocked that the catalog does not have yet. Agents in this repository pick the issues up and resolve them.
- ReleasingHow packages get from `main` to npm. There is nothing to run by hand.
- Secrets runbook (maintainers)The mock services (`@crvouga/mockingbird-service-*`, the only published packages) are released automatically on every green push to `main` (see [RELEASING.md](RELEASING.md)) and publish with **npm Trusted Publishing (OIDC)**.