| Filename | Latest commit message | Latest commit date |
|---|---|---|
2cdd7f2ff1
The harness has had its queue coordinates since the credential reached the container, but nothing used them. This offers each terminal row upward on `$SWARM.term.<hive>.<agent>`, so a swarm-level terminal can render an agent without reaching into the hive that hosts it. It publishes the same `TermMsg` the web UI is handed rather than a second model of the same events, so a new tool or a reclassified event changes both surfaces together. It subscribes to the event bus rather than to the SSE handler: the handler classifies per connected browser, so hanging this off it would mean an agent nobody is watching publishes nothing. That also means its own long-lived `ClassifyCtx`, since a publisher restarting its correlation state would lose the `tool_use` → name mapping a `tool_result` needs to render. The hive in the subject is derived from the queue client id, not from the harness's hive display name. Those come from different sources with no rule tying them together, and the responder builds its grant from the client id — so deriving it from the display name yields a publish the broker refuses, reaching an operator as a terminal that is merely empty. The prefix and suffix that bracket the hive are the responder's flags, which the agent is not told; it restates their defaults, and the symptom of a deployment retuning one without changing this is every publish refused rather than a wrong subject accepted. Oversize rows degrade in the publisher. Exceeding `max_payload` is not a truncation: the server refuses the message and closes the connection, so an oversize publish costs the row, the connection, and the rows racing behind it through the reconnect. The body is the only unbounded field — summaries are already trimmed at classification — so it is the field spent, and the row keeps its icon, level, summary and coalesce key. A row that does not fit even then is logged and dropped rather than sent. The limit is read off the connection, so `8388608` stays spelled once in the queue's own module; size is measured by serializing, because JSON escaping separates character count from wire length by an unbounded factor on exactly the rows already near the limit. Best-effort throughout: no queue, an unparseable client id and a failed connect each disable the publisher with one log line, and a failed publish loses its row and nothing else. The turn loop and the web UI never block on the queue. Refs #3805 |
||
| .. | ||
| 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.