| Filename | Latest commit message | Latest commit date |
|---|---|---|
2a02c76ad5
Every agent container reports the hostname `nixos`, so every log line it ships carries that as its `_HOSTNAME`. Measured: host `muede-lpt2`, `hive-matrix` (declared as `containers.hive-matrix`) `hive-matrix`, and `h-atlas` `nixos`. nixpkgs sets the hostname in the merge function of the `containers.<name>.config` option (nixos-containers.nix:524), so it reaches a guest evaluated through that option and nothing else. Agent containers are `nixos-container create --flake meta#<name>` — an independent `nixosSystem` off the meta flake, which never evaluates that submodule. nspawn also names a container's hostname after the machine by default; that is ruled out as the source here, because `h-atlas`'s machine name is `h-atlas` and it reports `nixos`. The machine name rather than the logical one: `stats/otel_metrics.rs:345` already labels metrics `container.name = "h-<name>"`, so the logical name would make logs say `atlas` while metrics say `h-atlas` — a prefix transform on every join between the two signals. Declarative containers and nspawn both use the machine name too, so this is one rule with no exception for agents. The emission sits next to `hyperhive.user.name = name;`, which already derives the container's unix user from the agent name; the hostname was the one identity attr nobody wired. Also drops the prose in swarm-otel.nix and module-eval.nix that explained `_MACHINE_ID` by "every container is `nixos`" — that motivating example is what this commit removes, and the argument for `_MACHINE_ID` never depended on it. Checked before editing: nothing in the tree assumes the hostname is "nixos" (0 hits across *.rs and *.nix), and nothing reads the hostname at runtime. Gate: cargo fmt 0, clippy -D warnings 0, cargo test -p hive-c0re meta:: 0 (23 run, 22 passed, 1 ignored), nix fmt 0 changed. Refs #4304 |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hive-c0re
The unprivileged host daemon (runs as hive-core). Owns the sqlite
broker, the approval/reminder/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, logs, topology).job_queue/— the job-DAG queue + desired-state reconciliation (docs/scheduler/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/integrations/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.