| Filename | Latest commit message | Latest commit date |
|---|---|---|
Seven places described an authoring flow that does not exist: the manager editing and committing a child's config in the bind-mounted config dir. mara, on the snapshot issue: "the pr workflow is the main one, anything else is legacy … the config dir in agent container is read only copy to see own config … changes need to go through local clone and via forge". Two of the seven are the request_init_config MCP tool description and its args struct, which are rendered into the system prompt of every agent holding the approvals tool group. A wrong tool description is not a stale comment; it is an instruction the whole hive reads as fact, which is why the claim kept being repeated back. The init tool creates the repo and seeds it. Nothing else. Tailoring the seeded template is not a separate mechanism - it is the ordinary config-change flow, a PR reviewed like any other. Prose only; the code already implements the PR flow (an approval's commit_ref is a PR number). Where a doc justified the parent's read-write mount on the child's config dir with the authoring model, the justification is removed rather than replaced: that mount is a defect tracked on its own issue, and it should not read as intentional while it waits. |
||
| .. | ||
| 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.