docs/swarm/README.md gets the routes, the revision, the apply semantics and the stopped-agent behaviour; the persistence doc points there from the AGENTS.md entry. The swarm-controller, swarm-controller-api and swarmctl READMEs and the repo map in AGENTS.md list the new bodies and routes. docs/tools/swarmctl-cli.md is regenerated for `swarmctl agent agents-md`, whose help text loses two passive phrasings vale flags.
1 KiB
swarm-controller-api
Wire types for swarm-controller's HTTP API, the request and response
bodies both swarm-controller (server) and swarmctl (client) import.
Serde only: no server or client logic, no tokio, no axum.
Why it's its own crate
swarmctl doesn't link swarm-controller, for the same reason hivectl
doesn't link hive-c0re. The two still share one contract, the same way
hivectl and hive-c0re share hive-host-sock: a field renamed on one side
is a compile error on the other, not a 400 the operator finds at runtime.
The schema feature derives utoipa's ToSchema on every type, for the
controller's OpenAPI spec. swarmctl leaves it off.
What's here
One module per endpoint family: agents (the responses of POST /api/agents
and POST /api/agents/{name}/forge-token), agents_md
(/api/agents/{name}/agents-md), forge
(POST /api/forge/users/{name}/admin) and schedules (/api/schedules).
The agent-create request, inference and permissions bodies are still mirrored
by hand in swarmctl.