docs: the agent roster page is Agent permissions, and the docs say agent list

Roster named the permissions page, the hive's topology file and the swarm's list of agents without saying which. The page and its links are renamed; the implementation docs and UI text follow separately.

docs/1-getting-started/setup.md

@@ -206,7 +206,7 @@ container keeps starting with the hive meanwhile.
 From here on, ask ruth. Open her card on `/agents` in the swarm UI and use the
 message box under her terminal. She is the manager agent: her MCP surface is the
 privileged one that configures agents, and she can recover the others. Changes to
-an agent's config arrive as PRs you merge. → [`2-handbook/agents/agent-roster.md`](../2-handbook/agents/agent-roster.md)
+an agent's config arrive as PRs you merge. → [`2-handbook/agents/agent-permissions.md`](../2-handbook/agents/agent-permissions.md)
 
 To create an agent yourself instead, use the swarm UI, or:
 

docs/2-handbook/agents/README.md

@@ -6,8 +6,8 @@ runtime (Claude Code or any Agent Client Protocol agent) and its model. This
 section covers running one: its identity, what survives a restart, how its
 config changes, what its own page shows and how far you can trust it.
 
-- **[Roster](agent-roster.md)** — the agents of a hive, and who may do what
-  to whom.
+- **[Agent permissions](agent-permissions.md)** — the hive's list of agents, and
+  who may do what to whom.
 - **[Persistence and config changes](persistence.md)** — what survives a
   restart, a destroy and a purge, and how a change to an agent's config flows
   from a pull request to its container.

docs/2-handbook/agents/agent-permissions.md

@@ -0,0 +1,33 @@
+# Agent permissions
+
+Agents are a **flat set**: no agent manages another by position. The
+`manage_root_agent` permission is the one grant that reaches another agent.
+
+## The hive's list of agents
+
+Which agents exist is the swarm's to decide:
+[which agents exist](../swarm/README.md#which-agents-exist). Each hive also
+keeps a small file of its own, `topology.json`, with the agents this hive has
+state or config for. You never edit it: the hive rebuilds it from what it sees
+locally, so a hand edit is overwritten, and one that doesn't parse stops the
+rebuild until you fix it. It matters for one thing, covered next.
+
+## Who may reach whose state
+
+An agent holding no permission sees its own directories and nothing else. An
+agent holding `manage_root_agent` gets every other agent's `state` directory on
+this hive mounted read-write at `/agents/<name>/state`, never `config` or
+`harness`. It's the only grant that reaches another agent's state. Ruth, the
+root agent, holds it (the swarm creates her from the `ruth` archetype, see
+[which agents exist](../swarm/README.md#which-agents-exist)). The mounts
+follow the hive's list: an empty file means no mounts until the next rebuild.
+
+## The manager is a normal agent
+
+`ruth` differs from other agents in her name and in that grant. Her
+permissions, prompt and tools work as for every agent, and destroying her is as
+final as for any other.
+
+How the hive reads and rebuilds the file, the wire protocol and the prompt blocks:
+[`roster.md`](../../4-implementation/agent-state/roster.md). The operator/agent
+trust boundary is a separate axis: [`boundary.md`](../hives/boundary.md).

docs/2-handbook/agents/security.md

@@ -68,7 +68,7 @@ agent's whole encrypted history, not only messages from then on.
 That's deliberate and it's the interim state, not the intent. An agent's
 credential path doesn't name the hive hosting it (agents move between hives),
 so a per-hive grant has to be an enumeration the controller re-emits whenever
-the roster changes — and an enumeration that can drift or land out of order
+the agent list changes — and an enumeration that can drift or land out of order
 advertises a boundary it doesn't actually hold. A wide grant that says what it
 is beats a narrow one that only looks narrow.
 

docs/2-handbook/hives/dashboard.md

@@ -3,7 +3,7 @@
 > Part of [Hives](README.md). See also: [Per-agent page](../agents/web-page.md)
 
 The hive dashboard is the per-hive UI that hive-c0re serves at `/`. The
-[swarm UI](../swarm/ui.md) holds everything swarm-wide (the agent roster, agent
+[swarm UI](../swarm/ui.md) holds everything swarm-wide (the agent list, agent
 creation, linking external forge and matrix accounts, the controller's job
 graph) and is where you do day-to-day work. The hive dashboard keeps shrinking:
 parts of it go, bit by bit.

docs/2-handbook/hives/hivectl.md

@@ -29,7 +29,7 @@ single agent lives under `hivectl agent <name> <verb>` — `hivectl` hoists
 the name onto the parent command, so none of the verbs below repeat it.
 
 ```bash
-hivectl list-agents                # roster: every agent's status + technical state
+hivectl list-agents                # every agent's status + technical state
 hivectl list-agents --json         # same data as raw JSON rows (for scripting)
 hivectl agent agent1 restart       # stop + start the `agent1` container (no rebuild)
 hivectl agent agent1 pause         # park agent1's turn loop, leave the container running
@@ -41,7 +41,7 @@ hivectl agent agent1 resume        # let it drive turns again, draining what que
 (`running` / `stopped`, plus ` paused` / ` needs-login`
 when set — `paused` is orthogonal to running, see below);
 REMIND is the count of pending reminders. It reuses the same per-agent aggregation the dashboard
-renders, so the CLI roster and the web UI never drift. `--json` emits the
+renders, so the CLI list and the web UI never drift. `--json` emits the
 raw rows instead of the table.
 
 `agent <name> restart` is the manual equivalent of the MCP `restart`

docs/2-handbook/swarm/README.md

@@ -19,7 +19,7 @@ grafana, the controller, authelia, …) →
 
 ## Where each piece lives
 
-- **control plane** — `swarm-controller`: hive directory, agent roster, job
+- **control plane** — `swarm-controller`: hive directory, agent list, job
   graph, agent creation. → [below](#swarm-controller)
 - **scheduled prompts** — named prompts for one or more agents at set times,
   kept by the swarm and fired in each agent's container. → [`schedules.md`](schedules.md)
@@ -62,7 +62,7 @@ grafana, the controller, authelia, …) →
 ## Swarm controller
 
 `swarm-controller` is the swarm's control plane: it holds the hive directory,
-the agent roster and their wanted state, and the job graph. Creating an agent —
+the agent list and their wanted state, and the job graph. Creating an agent —
 from the swarm UI or `swarmctl agent create --hive <h>` — queues its SSO
 identity, forge user, config repo, store identity and matrix account, then
 sends the hive a deploy message. A new agent starts `paused`. A store identity
@@ -100,7 +100,7 @@ socket-directory constraint that governs where `socketPath` may point:
 The options, wire formats and failure modes of each:
 [`controller.md`](../../4-implementation/swarm/controller.md).
 
-### Who is on the roster
+### Which agents exist
 
 The swarm decides. An agent exists in the swarm if and only if it has an
 identity in the swarm's authelia identity store, which `swarmctl agent create`
@@ -114,7 +114,7 @@ The swarm UI's setup assistant creates `ruth` from the
 `manage_root_agent` and sets her model to `sonnet`. A ruth created before the
 archetype keeps her model; set `sonnet` in her inference settings in the swarm UI
 if you want it. What that grant lets an agent reach on a hive is on the
-[agent roster page](../agents/agent-roster.md).
+[agent permissions page](../agents/agent-permissions.md).
 
 ## Hives: the substrate
 

docs/4-implementation/agent-state/roster.md

@@ -2,7 +2,7 @@
 
 The hive-local `topology.json`, how the hive derives it, and what's special about the
 manager (`ruth`). The operator's overview is
-[the agent roster page](../../2-handbook/agents/agent-roster.md).
+[the agent permissions page](../../2-handbook/agents/agent-permissions.md).
 
 <!-- vale write-good.Passive = NO -->
 

docs/README.md

@@ -86,7 +86,7 @@ The host a hive runs on and the operator's tools for it. Start at
 
 ### Agents
 
-One agent: its roster entry, state, config and page. Start at
+One agent: its entry in the agent list, state, config and page. Start at
 [`2-handbook/agents/`](2-handbook/agents/README.md).
 
 - **How do config changes flow from agent to operator to container?** →
@@ -97,8 +97,8 @@ One agent: its roster entry, state, config and page. Start at
   [`2-handbook/agents/persistence.md`](2-handbook/agents/persistence.md); the
   tables and directory layout:
   [`4-implementation/agent-state/persistence.md`](4-implementation/agent-state/persistence.md).
-- **Who can do what to whom — the agent roster and privilege?** →
-  [`2-handbook/agents/agent-roster.md`](2-handbook/agents/agent-roster.md); how
+- **Who can do what to whom — the agent list and privilege?** →
+  [`2-handbook/agents/agent-permissions.md`](2-handbook/agents/agent-permissions.md); how
   `topology.json` is rebuilt and what's special about the manager:
   [`4-implementation/agent-state/roster.md`](4-implementation/agent-state/roster.md).
 - **What does an agent's own page show?** →