Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Connect RPC surface for the ArcBox sandbox API.
The sandbox contract (arcbox.sandbox.v1) is the product's public API,
so it is served over Connect rather than plain gRPC: one set of handlers
answers Connect (HTTP POST with JSON or binary protobuf), gRPC, and
gRPC-Web. A caller with no proto toolchain can reach it with curl,
native clients keep gRPC performance, and browsers get gRPC-Web.
Message types here are generated by buffa and are the ONE runtime Rust
representation of the .proto files for ArcBox-owned protocols
(CORE-73): daemon handlers, abctl, and both ends of the host↔guest
vsock wire all use these types. The crate compiles for
aarch64-unknown-linux-musl (base connectrpc is transport-free) and
must stay musl-clean for the guest agent's sake.
The fleet agent's daemon client and reflection's descriptor set (see
[FILE_DESCRIPTOR_SET]) use these types too. The prost twins in
arcbox-protocol remain ONLY as test support: the daemon/e2e tonic
clients that prove the gRPC wire format still answers, and the fleet
agent's tonic mock daemon. buffa and prost encode identical protobuf
bytes, so those mixed-codec test peers interoperate; both
representations are generated from the same .proto sources and
therefore cannot drift.