Appendix: Crates, Features, Dependency Graph

The go-look-here reference, drawn from the family registry and the workspace manifests. For the narrative of how these fit together, see How the Crates Fit Together; this is the exhaustive index. The framework and its add-ons are at version 0.5, and every family dependency between repos is a plain version requirement resolved through the patch table until the family publishes.

The capi_rs framework workspace

The framework proper — contracts and their in-tree reference implementations, thirty-two members. All are #![no_std] + alloc except the proc-macro crates (capi_derive, capi_cookies_macro) and the macro-authoring kit they share (capi_macro_support), which are build-time only.

The other workspaces

Single-crate repos

Reference clients (*_capi_rs): aws_s3, azure_tables, generic_llm (a workspace over the OpenAI and Claude clients), google_places, google_routes, graphqlzero, grok, icecast_connect, paychex, ringcentral; the canaries grpc_test (tonic interop), nostd_canary (bare-metal QEMU), and runtime_canary (non-Tokio executors).

Tooling: capi_verify — a workspace of its own, the capi_verify planner library and the cargo-capi binary; capi-extension-template — the cargo generate template for a new codec, transport, auth, middleware, or client crate; and the private capi_test_suite — the registry, dev-config, and the family sweep.

The facade and prelude

capi_rs re-exports the Capi framework workspace under short module aliases — ::core, ::config, ::decoders, ::encoders, ::interface, ::protocol, ::transport, ::middleware, ::extras, ::authentication, ::rate_limiters, ::notification, ::lock, ::time, ::feature_state, ::http_headers, ::http_types, ::derive (behind derive), and ::cookies (behind cookies) — plus reexport for downstream forwarding. The protocol-generic core is reachable as capi_rs::protocol. The derives it surfaces are ApiEndpoint, capi, and AuthScheme, all behind derive. use capi_rs::prelude::*; brings the endpoint-authoring surface into scope — the core’s Protocol, Speaks, ApiClient, and Duplex among the names it carries; the seams that are meant to be unusual — FollowUp, Finalize, the capture types — ride no prelude and are imported from ::transport by name.

Crates outside that workspace are named directly by the client that uses them: the wire derives from capi_wire_model, Json from capiw_ext_json, UrlForm and urlform_extension from capiw_ext_urlencoded, the date and money carriers from capi_wire_datetime / capi_wire_decimal, and the capabilities and auth flows from capi_websocket, capi_grpc, capi_html_forms, capi_auth_oauth2, and capi_auth_jwt. capi_firewall and capi_debug_dump are members of the workspace but not of the facade: a wrapper is chosen by the application that seats the client, and depended on directly so that a look-alike cannot be substituted.

Feature matrix

capi_rs — default = ["std", "derive"].

The three axes (the compilation target picks the platform; see Features and Targets):

Add-ons: auth-basic, cookies, cookies-jar-access, derive (default). That is the whole list: the facade re-exports the framework workspace and nothing else, so the OAuth2 and JWT flows, WebSocket, gRPC, HTML forms, and the wire model are direct dependencies of the client that uses them, with their lanes forwarded from that client’s own features.

Adapter features that gate a lane: websocket on capic_reqwest, capic_ureq, capic_wasm_fetch, and capic_native_client; grpc on capic_reqwest (implying trailers, and therefore async) and capic_native_client; redis and voip on capic_native_client for the protocols it speaks off the pipeline. capic_reqwless is single-threaded by design and declares no lane beyond Http.

Harness features: capi_test_framework adds reqwest / native-client (the bundled live recorder, each exclusive with single-threaded), grpc, websocket, oauth2, serde-json / serde-form-urlencoded / quick-xml (structural body comparison), and js.

assert_feature_alignment! takes the tokens "async", "single-threaded", !"async", !"single-threaded", "native-only", and "browser-only"; assert_lane_alignment!("single-threaded") is the lane form. None of them is a Cargo feature, and std has no token.

Dependency graph

The edges are the manifests’ own — each workspace member’s family [dependencies], collapsed into layers:

graph TD
    client["client crate"] --> facade["capi_rs (facade)"]
    client --> protocols["capi_websocket / capi_grpc / capi_html_forms / capi_http_batch / capi_graphql"]
    client --> flows["capi_auth_oauth2 / capi_auth_jwt / signers"]
    client --> contracts["capiw_ext_json / capiw_ext_urlencoded / capiw_ext_xml / capiw_ext_protobuf"]
    facade --> interface["capi_base_interface"]
    facade --> extras["capi_extras"]
    facade --> config["capi_base_config / capi_limiters"]
    facade --> addons["capi_cookies / capiw_wire_headers"]
    facade --> codecs_in["capi_base_decoders / capi_base_encoders"]
    interface --> extras
    interface --> codecs_in
    extras --> codecs_in
    extras --> transport["capi_transport"]
    codecs_in --> transport
    config --> core["capi_core"]
    addons --> config
    addons --> core
    protocols --> core
    flows --> core
    transport --> core
    core --> planes["capip_http / capi_middleware / capi_authentication / capi_rate_limit / capi_url"]
    core --> wire["capi_wire_model (+ derive / value / datetime / decimal)"]
    contracts --> wire
    planes --> types["capi_http_types / capi_bytestream"]
    planes --> floor["capi_protocol (+ capi_context)"]
    types --> leaves["capi_notification / capi_time / capi_lock / capi_feature_state"]
    floor --> leaves
    wrappers["capi_firewall / capi_debug_dump"] --> planes
    codecs["capiw_serde_json / urlencoded / quick_xml / prost"] -.implements.-> contracts
    adapters["capic_reqwest / ureq / wasm_fetch / reqwless / native_client"] -.implements.-> planes
    harness["capi_test_framework"] --> facade
    harness --> testcore["capi_test_core"]
    testcore --> core

Three edges deserve a sentence. capi_base_config depends on capi_core and nothing above it — a config carries codecs and stores, and the decoders reach it through the endpoint, never the reverse. capi_base_decoders depends on capi_transport, because the paged, resumable, and flat-map decoders open the door and run traversals. And the wrappers depend only on capip_http and the HTTP vocabulary, which is what lets a firewall wrap any client the family or a third party ships.

That closes the book. From the decoupling thesis to here: you can build a Capi client, understand why it is shaped the way it is, and consume, patch, test, verify, and ship one everywhere.