docs(#1014): update stale root→ruth references in conventions, approvals, agent-hierarchy

This commit is contained in:
iris 2026-06-02 18:38:52 +02:00 committed by mara
commit a8ffdf31e0
3 changed files with 20 additions and 25 deletions

View file

@ -104,16 +104,14 @@ which axis the post-milestone version reads each special-case along:
### A — naming + bootstrap
- `MANAGER_AGENT = "root"` (broker recipient name),
`MANAGER_NAME = "root"` (logical name, state-dir key), and
`MANAGER_CONTAINER = "h-root"` (nixos-container name). The `h-`
prefix makes the manager consistent with all sub-agents and lets
`lifecycle::list()` use a single `starts_with("h-")` filter.
Existing `root` containers are renamed to `h-root` by migration
phase 5 in `migrate.rs` (idempotent, marker-guarded).
- `MANAGER_AGENT = "ruth"` (broker recipient name),
`MANAGER_NAME = "ruth"` (logical name, state-dir key), and
`MANAGER_CONTAINER = "h-ruth"` (nixos-container name); the `h-`
prefix lets `lifecycle::list()` use a single `starts_with("h-")`
filter.
- `auto_update::ensure_manager` runs at hive-c0re boot and spawns
`h-root` if missing. **Topology**: root has no parent, so
hive-c0re itself owns its lifecycle (no parent to delegate to).
`h-ruth` if missing. **Topology**: ruth defaults to root-level (no
parent); hive-c0re handles the bootstrap lifecycle directly.
### B — wire-protocol privileges
@ -175,7 +173,6 @@ read.
### F — drive-by checks across c0re
(`grep -n MANAGER_AGENT` produced ~28 hits)
- `loose_ends.rs`: manager sees hive-wide loose-ends, sub-agents only
their own. **Topology** — every agent sees its own + its
@ -238,9 +235,8 @@ repos they're working on.
meta-flake's per-agent flake.nix wrapper). For the manager unit
that means a hardcoded `HIVE_LABEL` env value:
- `HIVE_LABEL = "root"` — logical agent name; matches what `meta.rs`
injects at deploy time. (The nixos-container is `h-root`, but the
harness identifies itself by logical name.)
- `HIVE_LABEL = "ruth"` — logical agent name; matches what `meta.rs`
injects at deploy time.
Real deploys never read these — `meta::render_flake` overrides them
via the generated wrapper. They exist so the manager

View file

@ -2,7 +2,7 @@
The approval queue is hyperhive's pivot: nothing that changes the
shape of an agent (its config, whether it exists) happens without an
operator click. The manager (`root`) is the policy gate in front of
operator click. The manager (`ruth`) is the policy gate in front of
that queue; helper events are how it stays informed about what
happens after a decision lands.
@ -114,7 +114,7 @@ kind-specific payload carrier.
operator approval. Step 1 of the two-step spawn flow above.
- `UpdateMetaInputs``commit_ref` stores the JSON-encoded inputs
array (`"[]"` = all inputs, `"[\"nixpkgs\"]"` = just nixpkgs,
etc.). `agent` field is set to `root` (the requesting manager).
etc.). `agent` field is set to `ruth` (the requesting manager).
On approve hive-c0re runs `nix flake update [inputs...]` on the
meta flake and commits the resulting lock changes.
- `SchedulePrompt``commit_ref` stores the JSON-encoded
@ -438,23 +438,22 @@ notes, the events DB, proposed history, and applied history
all survive. The manager keeps its session; sub-agents stay
logged in.
## Manager (`root`) is hive-c0re-managed
## Manager (`ruth`) is hive-c0re-managed
The manager container runs through the **same lifecycle as
sub-agents**. On `hive-c0re serve` startup, if `root` is missing,
sub-agents**. On `hive-c0re serve` startup, if `ruth` is missing,
hive-c0re creates it. The manager's flake lives at
`/var/lib/hyperhive/applied/root/`; its proposed config at
`/var/lib/hyperhive/agents/root/config/`. Manager can edit its own
`agent.nix` (visible inside the container at `/agents/root/config/`)
and submit `request_apply_commit("root", <sha>)` for operator
`/var/lib/hyperhive/applied/ruth/`; its proposed config at
`/var/lib/hyperhive/agents/ruth/config/`. Manager can edit its own
`agent.nix` (visible inside the container at `/agents/ruth/config/`)
and submit `request_apply_commit("ruth", <sha>)` for operator
approval.
Differences from sub-agents:
- `flake.nix` extends `hyperhive.nixosConfigurations.manager`
(vs `agent-base`).
- Container name is `root` (no `h-` prefix).
- Web UI port via `lifecycle::agent_web_port("root")` — same
- Web UI port via `lifecycle::agent_web_port("ruth")` — same
FNV-1a hash as every other agent (8100..8999 range).
- `set_nspawn_flags` adds two extra binds: `/var/lib/hyperhive/agents`
`/agents` (RW) so the manager can edit per-agent proposed repos,

View file

@ -7,7 +7,7 @@ exist because something already went wrong without them.
- Containers are length-bounded by `nixos-container` (≤ 11 chars).
- Sub-agents are `h-<name>` with `<name>` ≤ 9 chars.
- The manager is `root` (no `h-` prefix, fixed name).
- The manager is `ruth` (fixed name).
- `MAX_AGENT_NAME` in `lifecycle.rs` enforces the cap.
- Per-agent web UI port = `WEB_PORT_BASE + FNV1a(name) % WEB_PORT_RANGE`
(8100..8999) for every agent including the manager; dashboard
@ -331,7 +331,7 @@ that allows the underlying resource access.
**Config storage** — per-agent capabilities live in
`/var/lib/hyperhive/meta/capabilities.json` alongside `tool-groups.json`.
Format: `{ "atlas": ["read_host_journal"], "root": ["manage_root_agent"] }`.
Format: `{ "atlas": ["read_host_journal"], "ruth": ["manage_root_agent"] }`.
An absent entry means "no extra capabilities". `render_flake` in `meta.rs`
reads this file and injects `HIVE_CAPABILITIES` (comma-separated
`snake_case` names) into each agent's systemd service env; absent entries emit