| Filename | Latest commit message | Latest commit date |
|---|---|---|
8b01dbeef1
The `--tools` list a harness session gets is not a constant: the base set plus whatever the agent's `HIVE_TOOL_GROUPS` add (today, `web_tools` → `WebFetch`/`WebSearch`). That resolution lived in `hive-agent`'s `mcp_config`, which is fine while the harness is the only thing that spawns a `claude` — and it is not: `hive-subagent-mcp` spawns one too. `hive-agent` is binary-only (no `src/lib.rs`, no lib target), so nothing can depend on it to reach `builtin_tools_arg`. The alternative to a shared home is a second list in the subagent daemon, which diverges on the first tool anyone adds to either — and diverging upward is a subagent holding a built-in its parent does not have. So move the base list, the `HIVE_TOOL_GROUPS` parse and the resolution into `hive_sh4re::permissions`, beside `ToolGroup` — whose `builtin_tools()` was already half of the answer. `hive-agent` re-exports them, so `mcp_config::builtin_tools_arg()` still reads the same at the call site, and `allowed_tools_arg` now derives its built-in half from the same function rather than repeating the merge loop. Behaviour is unchanged. The parse is `strum::EnumString` rather than a `serde_json::from_value` round-trip through a `Value::String`: same `snake_case` names (a test pins the two derives against each other), without `hive-sh4re` needing `serde_json` outside its dev-dependencies. It is now a pure function of its input, so the fallbacks are testable without mutating the environment — which under edition 2024 is `unsafe` and racy across a test binary's threads. Refs #4416 |
||
| .. | ||
| 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.