| Filename | Latest commit message | Latest commit date |
|---|---|---|
d94bc2188d
`topology.json` was a map of `name -> parent | null`, and that value fed the whole agent hierarchy: `<parent>` / `<children>` recipient sentinels, the reparenting API (CLI verb, wire verb, dashboard endpoints, DAG node), the dashboard tree, the rebuild depth sort, and an unconditional bind-mount grant giving every agent RW on its direct children's state. Per the operator's ruling the field goes, and with it all of the above. The file survives as what remains once the value is gone: the roster of agent names, which is the set `ManageRootAgent` grants mounts over. It is now a JSON array; `read` still accepts the old map shape and keeps its keys, so a hive that upgrades across this does not blank its roster (and so no capability holder loses its mounts for the length of that window). Two sites kept their behaviour under a different recipient rather than losing it. Both addressed `<parent>`, which the broker already resolved to `operator` for a root agent, and every agent is now what that fallback called a root: - the harness's turn-failure / plugin-failure notification (`Surface::send_to_parent` -> `send_to_operator`), and - the send allow-list's always-permitted escape hatch, so an agent with a restrictive allow-list still has a way to say it is stuck. What is NOT preserved, deliberately: an agent with no capability no longer sees any other agent's dirs. `ManageRootAgent`'s own grant is unchanged -- still every agent in the roster, still state RW + config RO, still no `harness`. The dashboard's reparenting control (the M0V3 picker) is deleted with its CSS. The tree rendering that reads `ContainerView.parent` is left for the frontend owner -- it degrades to a flat list with the field gone. |
||
| .. | ||
| 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.