| Filename | Latest commit message | Latest commit date |
|---|---|---|
d2a550e685
A webhook has exactly one target URL, so every hive registering one against the shared internal/knowledge repository was last-writer-wins rather than idempotent: all but the most recent silently stopped receiving deliveries. The swarm controller holds the single registration and now addresses an event to each hive over the queue instead. This is a migration, not a deletion. Not registering any more fixes nothing on a hive that has already run — the hook it created persists on the forge, so the contention would survive on exactly the deployments that have it while fresh installs looked fixed. The hive that created a hook removes it. It removes only its OWN, matched on the full URL rather than the /webhook/knowledge suffix. A hook with that suffix and a different base belongs to another hive, possibly one not yet upgraded, and deleting it would break that hive's knowledge sync until it caught up. Reaping a neighbour's registration is the behaviour being removed here; doing it while fixing it would only invert the direction. The predecessor did reap by suffix, to clear loopback hooks left by an older single-hive layout. That was safe when a hive was alone on its forge and is not safe now. The hive-side registrars also acted as reapers of hooks under their own path, which is why the swarm hook lives under /webhook/forge/; removing this registrar removes that reaper too. Intended, and stated because no reviewer would infer it from the diff. The receive endpoint goes with it. A live HMAC-verified /webhook/knowledge that nothing can legitimately reach would tell the next reader that this is how a hive learns about knowledge changes. Docs move in the same commit: docs/swarm/README.md said two hooks exist per swarm-wide repo and neither should be deleted, which is now true for agent-configs and wrong for internal/knowledge — a half-correct description being worse than an uncorrected one. |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hive-c0re
The unprivileged host daemon (runs as hive-core). Owns the sqlite
broker, the approval/question/schedule queues, the generic job-DAG
queue, container lifecycle, gateway/forge/matrix provisioning,
per-container stats, and the axum operator dashboard. Largest crate in
the workspace — bin-only, no separate lib.
When to use it
Host-level, cross-container orchestration: spawning/rebuilding/
destroying agent containers, the approval flow, dashboard-visible
state, provisioning per-agent forge/matrix/gateway accounts. Agent-side
behavior (turn loop, MCP tools) lives in hive-agent/hive-agent-mcp
instead — this daemon only talks to agents over the socket wire types
in hive-sh4re.
Shape
Cohesive clusters live in directory submodules, each re-exported at
the crate root (crate::broker::… keeps resolving regardless of which
subdirectory a module actually lives in). One line each — read the
module's own //! doc-comment for real detail, don't expect this file
to track it:
dashboard/— the operator dashboard (containers, approvals, schedules, questions, logs, topology).job_queue/— the job-DAG queue + desired-state reconciliation (docs/coordinator.md).lifecycle/—nixos-containerlifecycle + per-agent config flake generation.stores/— sqlite-backed stores (broker, queues, audit, power).workers/— background sweeps (crash watch, scheduled prompts, auto-update, knowledge sync).agent_config/— per-agent registries (tool groups, capabilities, resource limits, topology).stats/— dashboard metrics aggregation + OTEL export.socket_server/— the unix-socket request server shared by per-agent + manager sockets.forge/— optional Forgejo wiring (docs/forge.md).coordinator.rs— top-level wiring forserve.meta.rs,migrate.rs— the meta flake + schema/state migrations.matrix.rs,gateway_nginx.rs,webhook_secret.rs,priv_client.rs— matrix provisioning, gateway vhosts, webhook secrets, and thehive-privclient respectively.
See the top-level CLAUDE.md/docs/ index for the full reading-path
map.