| Filename | Latest commit message | Latest commit date |
|---|---|---|
swarm-controller now creates `term-main-<agent>` for every live agent, in the same one-minute pass and with the same config style as `term-sub-<agent>` (#4897): subjects `$SWARM.term.<agent>` only, max_age 24h, max_bytes 64 MiB, discard Old, max_message_size from the queue's max_payload. An existing stream is opened as it is. The agent keeps its plain publish on `$SWARM.term.<agent>` and gets no JetStream subject. `GET /api/agents/{name}/term/stream` creates an ephemeral push consumer on that stream starting 100 rows back, so a swarm-ui terminal opens with recent history and then follows new rows, in order, from one subscription. Each SSE event carries the row's stream sequence as its id, and a reconnect's Last-Event-ID resumes after it. Without the stream the route falls back to the live core subscription it used before. The stream is `term-main-<agent>`, not `term-<agent>`: an agent may be named `sub-x`, whose `term-<agent>` would be agent `x`'s subagent stream. Its one literal subject cannot match `$SWARM.term.<agent>.sub.>`, which needs more tokens, so the two streams never overlap. The reader gains `$JS.API.CONSUMER.CREATE.*.*.$SWARM.term.*`, the extended create form whose last tokens are the consumer's filter. Checked against nats-server 2.14.4, the trailing `*` also admits a literal `*` or `>` filter, so a consumer under it reaches any terminal row, main or subagent; those are rows the reader already subscribes to and reads with `STREAM.MSG.GET.*`. Closes #4826 |
||
| .. | ||
| 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 turn per inbox message
through hive-runtime, on the agent's runtime (claude --print by
default, or an ACP agent). It has one role
(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 landing in the
inbox and the agent's reply, how the harness bootstraps login/auth,
how it serves the per-agent web UI, 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
main.rs— the serve loop and theSurfacetrait; broker calls (inbox poll, ack, send) go throughhive-sock-clientwithhive-core-agent-sockwire types.turn.rs— the turn-loop policy layer: renders the system prompt + MCP config, runs the turn throughhive-runtime, classifies the outcome, and feeds the event/turn-stats sinks.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/.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.
Siblings: hive-agent-mcp (the MCP server this loop points the
agent at every turn) and hive-runtime (the library a turn runs
through).
docs/turn-loop/::Harness binary shape
covers all three together.