vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity
hyperhive/hive-agent
History
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas 0f7b403803 agents get a todo when assigned to an issue or PR, rewritten when unassigned and cleared on close 
A new swarm service, swarm-notify-router, in its own container on the host
that sets deploy.notify-router.enable (defaulted on by allSwarmServices where
the host has the router's store leaf, like the claude login minter).

- swarm-controller registers instance-wide hooks for `issues` +
  `issue_assign` and `pull_request` + `pull_request_assign`, updates the
  event list of a hook already registered with fewer (leaving its active flag as it is), and keeps each
  verified body unchanged in the SWARM_EVENTS stream on
  $SWARM.events.forge.<X-Forgejo-Event-Type>, deduped by X-Forgejo-Delivery.
  A delivery the stream did not keep answers 503.
- swarm-notify-router drains its durable consumer on that stream, runs its
  flows (source -> match -> todo sink, stored as nodes plus edges and checked
  to be a tree) and queues each op on $SWARM.router.todo.<agent> in the
  work-queue stream ROUTER_TODOS. Built-in flows: assigned, unassigned (same
  key, rewritten) and closed (prefix-clears every holder's router todos). A
  per-issue snapshot in its notify-router-state bucket holds the last
  assignees and the todo holders; only agents in the agent-status bucket get
  ops, and an assignee that was not one is left out of the snapshot so the
  next assign event retries it. After the first event that must be retried,
  the rest of the batch is nakked so redelivery keeps stream order.
- hive-agent creates its own durable consumer todo-<agent> and applies each
  op to its todo store as subsystem `router`, then acks; a refused op stops
  the rest of its batch the same way. The store's (subsystem, key) dedup
  makes a redelivery harmless. New Todos::clear_prefix.
- swarm-nats-auth: a --notify-router-client arm; the controller may publish
  $SWARM.events.forge.*; each agent gets three {agent} templates (extended
  consumer create whose filter the server checks, MSG.NEXT, ACK).
- Credentials: a notify-router store leaf minted by glue-bao-tls, a
  swarm-notify-router bao policy (read on its own queue client secret), an
  authelia machine client, the secret publisher entry, a journal forwarder
  route. No manual step.

hive-forge-notify is unchanged, so agents also still get forge's own
notifications.

Refs #5571
2026-10-22 07:28:53 +02:00
..
prompts agent prompt: point the forge condition at HIVE_FORGE_TOKEN_FILE instead of a state-dir file 2026-10-21 23:55:44 +02:00
src agents get a todo when assigned to an issue or PR, rewritten when unassigned and cleared on close 2026-10-22 07:28:53 +02:00
Cargo.toml agents get a todo when assigned to an issue or PR, rewritten when unassigned and cleared on close 2026-10-22 07:28:53 +02:00
README.md agent permissions: one set, tool groups included, set at agent creation 2026-10-15 18:01:40 +02:00

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 the Surface trait; broker calls (inbox poll, ack, send) go through hive-sock-client with hive-core-agent-sock wire types.
  • turn.rs — the turn-loop policy layer: renders the system prompt + MCP config, runs the turn through hive-runtime, classifies the outcome, and feeds the event/turn-stats sinks.
  • login.rs / login_session.rs — first-run and session-resume auth flow for the claude CLI.
  • mcp_config.rs — renders the per-turn --mcp-config / --allowedTools blob from the agent's permissions.
  • 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-mcp dial 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) under harness/.
  • prompt.rs — system-prompt renderer (persona + tool docs + environment facts).
  • web_ui/ — the per-agent dashboard (terminal pane, status, schedules) served over the built-in hive-agent web 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.