| Filename | Latest commit message | Latest commit date |
|---|---|---|
afdfce67ec
Every agent on a hive authenticates to the swarm queue with the same hive-scoped OIDC client, so at the auth callout one agent is indistinguishable from its co-hived neighbours. The commit before this one mints a secret per agent at swarm level into secret/swarm/agents/<agent>/queue; nothing read it. Read it here, and read it from the container itself. A hive courier in the path would be the hive vouching for which agent this is, which is the property a per-agent credential exists to remove -- so the agent logs in to the store with the certificate hive-agent-bao-identity already proves it can log in with, and reads its own path. The store certificate is for reaching the store and nothing else: what the new unit writes to /run is the secret it read back, and nothing hands a BAO_CLIENT_* path to anything queue-shaped. The read needs no policy change. render_agent grants read on secret/data/swarm/agents/<agent>/*, which covers this path and the bao-mtls one beside it alike -- which is also why this unit degrades where the identity check fails. A refusal this unit sees and that check did not cannot be a policy that drifted; it is an object not yet minted, the ordinary state of every agent created before its swarm knew to mint one. The harness resolves the path and reports which credential this agent can present. It does not yet present it: the auth-callout responder still verifies only the hive-scoped token, and an agent offering a credential nothing on the other end reads back would simply be refused. Teaching swarm-nats-auth to read the same path is the next slice. |
||
| .. | ||
| prompts | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hive-agent
The in-container harness serve-loop binary — one instance per agent.
Long-polls the broker inbox and drives one claude --print turn per
inbox message, over the hive-claude driver. There is one role here
(agent); the Surface trait + AgentSurface zero-sized type tag keep
the turn loop generic and testable for future roles without a
parallel copy of the loop.
When to use it
You don't call into this crate from elsewhere — it's the top-level
binary systemd starts per agent container. Look here when you need to
understand or change: what happens between "a message lands in the
inbox" and "claude produces a reply", how login/auth is bootstrapped,
how the per-agent web UI is served, or how turn/event stats get
recorded. Architecture detail lives in
docs/turn-loop/; this README is just the
map of the module tree.
Shape
turn.rs— the turn-loop policy layer: renders the system prompt + MCP config, invokeshive-claude, classifies the outcome, and feeds the event/turn-stats sinks.client.rs— broker client (inbox poll, ack, send) speaking thehive-sh4rewire protocol.login.rs/login_session.rs— first-run and session-resume auth flow for theclaudeCLI.mcp_config.rs— renders the per-turn--mcp-config/--allowedToolsblob from tool groups + capabilities.todos.rs/reminders.rs/todo_server.rs— the harness-local loose-ends v2 stores (sqlite-backed) and the in-agent socket server extra MCP daemons +hive-agent-mcpdial into for todo/reminder ops.vacuum.rs— periodic sqlite vacuum sweep for the harness-local stores.events.rs/turn_stats.rs/stats.rs— append-only event sink and per-turn telemetry recording (context usage, cost, tool favorites) underharness/.forge_notify.rs— subscribes to forge notifications and wakes the harness on new activity.prompt.rs— system-prompt renderer (persona + tool docs + environment facts).web_ui/— the per-agent dashboard (terminal pane, status, schedules) served over the built-inhive-agentweb port.paths.rs— canonical path resolution for state/harness dirs and the harness-local sqlite files.
Sibling: hive-agent-mcp (the MCP server this loop points claude
at every turn). Both are described together in
docs/turn-loop/::Harness binary shape.