Expand description
The vendored core contract, and the surface reduced from it.
§One reducer, two document sources
The generated cassette surface answers “what can this server do?” by
reducing an OpenAPI document to callable methods — discovered at runtime,
because the cassette set is deployment configuration. The core tapes API is
the opposite kind of fact: it is a published contract, sealed in the tapes
repository (api/CONTRACT) and attached to releases, so the right copy to
build from is the vendored one in contracts/tapes-api.yaml, pinned by
fingerprint (see contracts/PROVENANCE.md).
Both feed crate::cassettes::spec::reduce_methods. What used to be a
set of hand-written URL builders in each client is a lookup into this
surface: the verb, the path template, and the set of declared parameters all
come from the contract bytes, and a request naming a parameter the contract
does not declare is refused before it is sent.
§Why the contract is vendored rather than fetched
Neither client builds against the tapes working tree; both build against a published release asset. Vendoring it here — once — is what stops two clients holding two copies that nothing checks for agreement.
Modules§
- ops
- Operation ids of the vendored contract, named once so client methods, coverage tables, and tests cannot drift apart on a string.
Structs§
- Core
Surface - The core read surface, reduced from the vendored contract.
Constants§
- TAPES_
API_ YAML - The vendored read-API contract, byte-for-byte what
contracts/tapes-api.yamlholds.
Functions§
- call_
for - Build the
Callfor one operation from wire-named values. - call_
for_ with_ body - Build the
Callfor one operation from wire-named values and a body. - core
- The core surface, or the build-defect error.