| Filename | Latest commit message | Latest commit date |
|---|---|---|
1db2ac26a7
`swarm.*` is what a hive needs to be a *client* of the swarm. For the forge that is what it IS from any hive's point of view: its package, the names and ports it answers on, the URLs it advertises, and the client id it is registered under. How it is served, what it mirrors and where its host-local secrets sit are decisions of the machine running it, so behindGateway, openFirewall, mirrors, sso.clientSecretFile and hostSwarmControllerTokenFile move to `deploy.forgejo.*`. Unlike the wireguard mesh this SPLITS a module rather than relocating a whole namespace. `sso` splits with it: `clientId` stays because it must match the id in authelia's register, while the secret beside it is a path on one host. Moving the whole `sso` block for symmetry with `ci` was considered and rejected on exactly that asymmetry. Declared in hive-forge/default.nix under the `deploy.*` path, following swarm-victorialogs.nix; deploy.nix carries only the renames. `mirrors` renames in one entry rather than one per field — it is a single option of a list-of-submodule type, so the rename carries its whole value, where `ci` needed five because it is a plain attrset of options. Readers outside the module: hive-ci.nix binds `deploy.forgejo` for its behindGateway assertion; swarm-authelia.nix and swarm-controller.nix read theirs off the `deployCfg` they already bind. hivectl's `open` printed `services.hyperhive.forge.behindGateway` in an operator-facing hint — a path that never existed, missing `swarm.` — and hive-c0re's state_snapshot doc comment carried the same defect; both now name the new path. The rendered docs put the two halves on separate pages, so the five descriptions of staying options that explain themselves in terms of `behindGateway` now qualify it in full. module-eval gains a forge case configured entirely through the old paths, asserting the rendered firewall ports and the mirror env var c0re seeds from: the new paths evaluate fine without the shims, so dropping them reads as a clean tree. All five old paths are defined in the fixture, so removing any single shim entry fails the eval rather than only the two the assertion reads. |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hivectl
The operator-facing host CLI. A thin client for the hive-c0re
daemon — speaks the host admin socket protocol (hive-host-sock) and
does not link the daemon crate. Container lifecycle, the approval
queue, and provisioning verbs all forward to the daemon and need it
running; a few (wg/peer-config, choom) work off local host state
instead.
When to use it
Reach for this crate when adding an operator-run host command — agents
talk to the daemon over their own MCP tool surface
(hive-agent-mcp), not this binary. hivectl is what a human operator
(or a host-side script) runs.
Shape
One module per subcommand family; main.rs is just the clap parse +
dispatch:
agents.rs— container lifecycle (start/stop/create/kill/rebuild/restart/…).approvals.rs— the config/init-config/meta-input approval queue.dag_progress.rs— rebuild-queue progress rendering.power.rs— restart/start/stop at the container level.choom.rs— drop into an interactive claude session in a container.forge.rs,matrix.rs,github.rs,gateway.rs— per-integration account/token provisioning.wg.rs— WireGuard mesh helpers.subvol.rs— btrfs state-subvolume ops.quota.rs,util.rs,completions.rs,open.rs— shared helpers, shell completions, browser-open.
Full verb reference: docs/tools/hivectl.md.