docs: the handbook follows the three layers: swarm, hives, agents

The handbook's sections were agent-lifecycle, integrations, swarm, tools,
trust-boundary and web-ui, which do not follow how the system is built, so a
reader could not tell which layer a page is about. Its pages now sit in
swarm/, hives/ and agents/, with the accounts an agent can hold outside the
system in external-accounts/.

- swarm/: forge, matrix and the knowledge repo join the swarm pages, and so
  does the swarmctl reference.
- hives/: the dashboard, hivectl and its reference, and the operator/agent
  boundary, with a README that takes over the old web-ui and tools pages.
- agents/: the roster, persistence, config changes, the agent's own web page
  (was web-ui/agent) and the security model, with a README.
- external-accounts/: GitHub and GitLab.

Pages are moved whole; none is split yet. Every reference follows: relative
links in the docs, `docs/2-handbook/...` paths in code comments, the nix
checks that regenerate the CLI references and the ignore list, and docs/README.md,
whose handbook section is now by layer.

docs/4-implementation/agent-tools/README.md

@@ -5,7 +5,7 @@ an agent's own claude session can call, plus the CLIs it shells out to).
 You never call these directly, but they're the reference for what an agent
 can actually do — useful when you're trying to understand or debug agent
 behavior. The operator's own tools are in
-[`2-handbook/tools/`](../../2-handbook/tools/README.md).
+[`2-handbook/hives/`](../../2-handbook/hives/README.md).
 
 ## What your agents can do
 

docs/4-implementation/agent-tools/matrix.md

@@ -149,7 +149,7 @@ pending invites, resolve_invite to accept or reject`. The daemon clears
 the keyed todo when a `resolve_invite` (or `join_room`) call resolves
 the invite.
 
-See [`docs/2-handbook/integrations/matrix.md`](../../2-handbook/integrations/matrix.md) for the homeserver setup,
+See [`docs/2-handbook/swarm/matrix.md`](../../2-handbook/swarm/matrix.md) for the homeserver setup,
 provisioning flow, and federation config.
 
 ## Extra MCP servers (per-agent)

docs/4-implementation/networking/gateway.md

@@ -433,7 +433,7 @@ Three render sites follow it: the agent-name link, the favicon fetch
 (`<url>/icon`), and the nav-strip `container`-kind links from
 `DashboardState.links` (`GET /api/dashboard-state`). Forge links come from
 `swarm.forge.publicUrl`; with it unset the dashboard hides them rather than
-guess. See `docs/2-handbook/web-ui/dashboard.md::Container row` for the frontend side.
+guess. See `docs/2-handbook/hives/dashboard.md::Container row` for the frontend side.
 
 ### Dialing another vhost by name (`verifiedProxyTo`)
 

docs/4-implementation/networking/snapshot-store.md

@@ -194,8 +194,8 @@ the access-review list.
 
 The snapshot covers an agent's **state subvolume**, which is the parent
 of `state/`, `claude/` and `harness/` (see
-[`docs/2-handbook/agent-lifecycle/persistence.md`'s btrfs subvolume
-section](../../2-handbook/agent-lifecycle/persistence.md#btrfs-subvolumes-for-varlibhyperhiveagentsname)
+[`docs/2-handbook/agents/persistence.md`'s btrfs subvolume
+section](../../2-handbook/agents/persistence.md#btrfs-subvolumes-for-varlibhyperhiveagentsname)
 for how and when hive-c0re creates that subvolume). Consequences:
 
 <!-- vale write-good.Passive = NO -->

docs/4-implementation/scheduler/coordinator.md

@@ -2,7 +2,7 @@
 
 Architecture notes for the `hive-c0re` coordinator daemon's internal subsystems.
 For the public API surface (dashboard, socket protocol) see `docs/5-project/process/conventions.md`
-and `docs/2-handbook/agent-lifecycle/persistence.md`.
+and `docs/2-handbook/agents/persistence.md`.
 
 ---
 
@@ -328,7 +328,7 @@ boot with no operator action in this process never finds drift of its own.
 
 Agents build from the swarm's `internal/meta` flake, which swarm-controller
 commits and the swarm builder builds from (see
-[Config changes](../../2-handbook/agent-lifecycle/config-changes.md#the-swarms-meta-flake)).
+[Config changes](../../2-handbook/agents/config-changes.md#the-swarms-meta-flake)).
 The hive keeps no flake of its own and deploys the closure the swarm builds
 from it, as the agent's `agent-closures` record declares (`attic/closure.rs`).
 `agent_set.rs` keeps the
@@ -536,7 +536,7 @@ config — all nspawn containers live in `machine.slice`.
 
 ## See also
 
-- `docs/2-handbook/agent-lifecycle/config-changes.md` — config PRs, meta flake, system messages
-- `docs/2-handbook/agent-lifecycle/persistence.md` — SQLite schema, state-dir layout
+- `docs/2-handbook/agents/config-changes.md` — config PRs, meta flake, system messages
+- `docs/2-handbook/agents/persistence.md` — SQLite schema, state-dir layout
 - `docs/5-project/process/conventions.md` — wire protocol, recipient sentinels
-- `docs/2-handbook/agent-lifecycle/agent-roster.md` — the agent roster and privilege
+- `docs/2-handbook/agents/agent-roster.md` — the agent roster and privilege

docs/4-implementation/scheduler/jobq.md

@@ -34,7 +34,7 @@ swarm controller and hive-c0re each build their own graph on it.
 Two views, one per graph, drawn by the same component: the swarm UI's
 `/jobs` page shows the swarm controller's graph, and the hive dashboard's
 **R3BU1LD QU3U3** tab (see
-[`2-handbook/web-ui/dashboard.md`](../../2-handbook/web-ui/dashboard.md)) shows that hive's. Each
+[`2-handbook/hives/dashboard.md`](../../2-handbook/hives/dashboard.md)) shows that hive's. Each
 **row** is one job; the rows nested under it are that job's steps, in
 order (occasionally a couple run side by side). A step shows one of:
 

docs/4-implementation/scheduler/observability.md

@@ -104,7 +104,7 @@ smuggled out in resource attributes on an otherwise-legitimate export.
 That's a **different risk from the one the collector fixes**: an agent that
 held the upstream credential could do everything above _and_ use the token
 anywhere else. The collector removes the token and keeps the pipe. Agents are inside the trust
-boundary (`docs/2-handbook/trust-boundary/security.md`: capability = accepted risk), so an agent being
+boundary (`docs/2-handbook/agents/security.md`: capability = accepted risk), so an agent being
 able to _send_ is an accepted extension of that boundary — but it's not
 closed by this design, and don't read anything here as closing it.
 

docs/4-implementation/swarm/builder.md

@@ -179,7 +179,7 @@ the deploy node, and the graph shows the update as failed and the deploy as
 skipped. Each ten-minute retry of a failed update declares a fresh build and
 deploy behind it for every agent whose latest deploy the failed update skipped,
 so the run that succeeds sends them (see
-[Config changes](../../2-handbook/agent-lifecycle/config-changes.md#the-swarms-meta-flake)). A render
+[Config changes](../../2-handbook/agents/config-changes.md#the-swarms-meta-flake)). A render
 equal to the committed `flake.nix` sends no lock.
 
 The controller sends a deploy to every agent a hive places whenever the pin in

docs/4-implementation/swarm/inference.md

@@ -30,7 +30,7 @@ swarmctl agent inference clear iris
   running on, each with where it comes from.
 - `clear` removes every field; the agent goes back to its own values.
 
-The full flag reference is [`swarmctl-cli.md`](../../2-handbook/tools/swarmctl-cli.md). The
+The full flag reference is [`swarmctl-cli.md`](../../2-handbook/swarm/swarmctl-cli.md). The
 swarm UI's agents page edits the same settings; see [UI](../../2-handbook/swarm/ui.md). The
 swarm is the only place to change an agent's model or effort at runtime:
 its web UI shows both but has no picker and no `/model` or `/effort`

docs/4-implementation/trust-boundary/boundary-mechanism.md

@@ -2,7 +2,7 @@
 
 How systemd activates `hive-priv` and how the per-agent socket directory
 gets its owner and mode, the two pieces of the boundary described in
-[the operator/agent boundary](../../2-handbook/trust-boundary/boundary.md).
+[the operator/agent boundary](../../2-handbook/hives/boundary.md).
 
 ## hive-priv socket activation
 
@@ -42,7 +42,7 @@ root:root`, no symlink followed) and leaves an existing one alone. The
 container's own activation (`hive-agent-user-migrate`) then chowns it to
 the agent user and sets `0751`. Without a user namespace
 that uid is the host inode's owner. (A namespaced agent, see "User namespace" in
-`docs/2-handbook/agent-lifecycle/persistence.md`, gets the dir from `EnsureAgentSocketDir`
+`docs/2-handbook/agents/persistence.md`, gets the dir from `EnsureAgentSocketDir`
 owned by its data owner instead, because the container can't chown through
 the id map.) Don't add another host-side chown or chmod:
 two owners of one path revert each other. Until the container activates,

docs/4-implementation/trust-boundary/hive-c0re-privilege.md

@@ -1,7 +1,7 @@
 # hive-c0re privilege separation
 
 How `hive-c0re` runs unprivileged and delegates its root operations to
-`hive-priv`, from the [security model](../../2-handbook/trust-boundary/security.md).
+`hive-priv`, from the [security model](../../2-handbook/agents/security.md).
 
 ## Background
 

docs/4-implementation/trust-boundary/nix-builds.md

@@ -1,7 +1,7 @@
 # Nix builds and credential isolation
 
 The mechanism and threat model for `nix build` inside an agent container, from
-the [security model](../../2-handbook/trust-boundary/security.md).
+the [security model](../../2-handbook/agents/security.md).
 
 ## Background
 

docs/4-implementation/turn-loop/README.md

@@ -27,7 +27,7 @@ agents) runs:
    queued and unacked, so a resume drains the backlog instead of
    losing it; reminders and todo wakes buffer in their channels. Set
    it with `hivectl agent <name> pause` or the dashboard toggle; see
-   [persistence](../../2-handbook/agent-lifecycle/persistence.md#-harnesspaused-per-agent).
+   [persistence](../../2-handbook/agents/persistence.md#-harnesspaused-per-agent).
 1. Long-poll `Recv` on its socket. The host-side broker
    (`broker.rs::recv_blocking_batch`) returns immediately if there's
    a pending message, otherwise waits up to 30 s for a broker `Sent`
@@ -118,14 +118,14 @@ installs claude plugins, spawns `web_ui::serve` + `vacuum::run`,
 and either drops into `serve_loop` directly (`Online`) or parks on
 the login flow first (`NeedsLogin`). `hive-forge-notify` polls forge
 notifications on its own, not this loop — see
-[`forge.md`](../../2-handbook/integrations/forge.md).
+[`forge.md`](../../2-handbook/swarm/forge.md).
 
 Boot also opens the todos store and the socket in-container producers
 dial. Matrix / bash / forge-notify daemons and the in-process
 `disk_watch` todo producer (low state-disk space) are the built-in
 producers, but the socket accepts any `subsystem` marker — a
 user-configured MCP server can push its own todos the same way. See
-[`docs/2-handbook/agent-lifecycle/persistence.md`](../../2-handbook/agent-lifecycle/persistence.md#state-dirs-per-agent) for
+[`docs/2-handbook/agents/persistence.md`](../../2-handbook/agents/persistence.md#state-dirs-per-agent) for
 what each built-in todo producer watches and how the store + `get_loose_ends`
 merge work.
 

docs/4-implementation/turn-loop/claude-invocation.md

@@ -216,7 +216,7 @@ agent's durable bind-mounted dir. AGENTS.md autoload walks
 upward from `/state` — drop a per-agent AGENTS.md there if you
 want long-term hints that survive destroy/recreate. A `CLAUDE.md`
 in `/state` or above it shadows `AGENTS.md`: claude then loads only
-the `CLAUDE.md` (see `docs/2-handbook/agent-lifecycle/persistence.md` for the
+the `CLAUDE.md` (see `docs/2-handbook/agents/persistence.md` for the
 boot-time rename).
 
 The wake prompt is intentionally minimal: the popped message's

docs/4-implementation/turn-loop/config.md

@@ -330,7 +330,7 @@ KEYS
 The file lives in the agent's bind-mounted **harness** dir, not `state/`
 — `harness/` survives container rebuilds exactly like `state/` does, but
 (unlike `state/`) is never bind-mounted into a parent agent's container
-(see `docs/2-handbook/agent-lifecycle/persistence.md`'s "Parent access to child state"), so an API
+(see `docs/2-handbook/agents/persistence.md`'s "Parent access to child state"), so an API
 key placed here is reachable by nothing but this agent and the host. The
 file doesn't stay root-owned, though: the container's activation chowns the
 whole harness dir to the agent, so after the next boot the file is agent-owned

docs/4-implementation/turn-loop/mcp.md

@@ -144,7 +144,7 @@ hive_name?, swarm_name?, matrix_accounts? }`. `matrix_accounts` is a
   [`docs/4-implementation/agent-tools/subagent.md`](../agent-tools/subagent.md).
 - **Config changes** — no permission: they go through a forge PR on
   `agent-configs/<name>` — see
-  [`docs/2-handbook/agent-lifecycle/config-changes.md`](../../2-handbook/agent-lifecycle/config-changes.md).
+  [`docs/2-handbook/agents/config-changes.md`](../../2-handbook/agents/config-changes.md).
 - **Web egress** (`web_tools`) — enables Claude's built-in `WebFetch`
   and `WebSearch` tools (not MCP tools; added directly to the
   `--allowedTools` list). Off by default.

docs/4-implementation/web-ui/shape.md

@@ -1,7 +1,7 @@
 # Shape (shared by both)
 
-> Part of [Web UI](../../2-handbook/web-ui/README.md). See also:
-> [Dashboard layout](../../2-handbook/web-ui/dashboard.md) · [Per-agent page](../../2-handbook/web-ui/agent.md)
+> Part of [Hives](../../2-handbook/hives/README.md). See also:
+> [Dashboard layout](../../2-handbook/hives/dashboard.md) · [Per-agent page](../../2-handbook/agents/web-page.md)
 
 ## Shared routes