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.
car-messaging
Multi-channel message transports for the CAR daemon — the iMessage and
Slack surfaces. Two directions share this crate: the older inbound
approval transport (a human answering an approval request), and the outbound
send an agent makes when it needs to reach a human. Extracted from
car-server-core (#418) to cut its test-binary link/disk footprint in CI.
What's here
messaging_config— per-channel config/allowlist/pairing store (~/.car/messaging.json); the host/local-auth-gated config channel.messaging_orchestrator— inbound poller + orchestrator: resolves an inbound message to a session/approval, applies allowlist/anti-injection, and drives the reply via aMessageSender.slack_adapter— Slack wire parsing (Events API / interactive / socket mode), theSlackTransporttrait, and token/pairing provisioning.fanout— theFanoutCoordinatorthat dispatches a resolved inbound message across the registered channel adapters.channel_supervisor— lifecycle for the per-channel inbound listeners.outbound— the outbound half:OutboundRegistry(the host'sMessageSink, holding the registered per-channel adapters and the bounded idempotency ledger that keeps a retried send from delivering twice), theOutboundAdaptertrait one channel implements, andImessageOutboundAdapter. This is the host side of the runtime'smessaging.sendtool — a channel CAR has no adapter for falls back to the host via themessaging.channel_sendtool callback.
Layering
Depends on car-server-types (HostState, channel types + inbound traits,
approval_core) and on car-engine for the MessageSink seam outbound
implements — not on car-server-core's dispatcher, so there is no
cycle. car-server-core depends on this crate and re-exports its modules
(crate::messaging_config::* etc.) so the JSON-RPC dispatcher keeps wiring the
messaging.* methods with no call-site change.
The dispatcher-coupled end-to-end tests (those that boot a ServerState /
run_dispatch) stay in car-server-core; the component/harness tests for the
adapters live here.