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.
The turn-running core, shared by the harness server and the in-process replay transport.
One agent turn runs the same way regardless of who drives it: decode the
inbound wire transcript, verify the HITL approval responses, resolve the
per-turn backend + model, assemble [RunTurnOptions], run the
function-calling loop ([polyc_agent::run_turn_with]) against an injected
provider + [ToolExecutor], and frame the result as the terminal batch
message the control plane persists.
This crate owns that orchestration so the two callers cannot drift:
- the harness server (
polyc_harness) composes its proxy-augmented tool surface and streams live deltas, then calls the fine-grained pieces ([verify_approval_responses], [run_turn_options], [run_turn_captured], [build_final_batch], [connect_error_from_turn]) around its bidirectional pump; - the control-plane in-process transport composes a buffered tool surface and
calls the whole-turn entry [
run_wire_turn] directly.
The runner is generic over the injected [ToolExecutor]: the harness's
mid-turn proxies (payment / history / dispatch / peer) live in the caller, so
this crate never depends on them and stays a Component both Containers can
depend on inward.