docs: name the specific daemon instead of the vague 'backend'

Per mara's ruling on hyperhive#4041 (Microsoft.Avoid): 'backend' never says
which system it means. Fixed all 21 fixable hits to name the actual daemon
(mostly hive-c0re; one hive-agent instance and one hive-matrix-daemon one,
both confirmed against surrounding context, not guessed). Also tightened
Weston's own 'VNC backend'/'RDP backend' plugin references to their literal
upstream names (vnc-backend/rdp-backend) rather than dropping the accurate
term entirely, and reworded one unrelated Microsoft.Avoid hit ('and so on').

Left alone (flagged on the issue, not guessed): docs/turn-loop/config.md's
3 remaining hits match the actual nix option name (backendEnvironmentFile)
and describe a genuinely pluggable concept (which LLM API provider), not
one specific internal system.

docs/agent-lifecycle/persistence.md

@@ -556,7 +556,7 @@ agent containers come up. Without the path-trigger sibling
 <this agent's state dir>/matrix-token*` — the trailing `*` also catches
 a secondary multi-account token like `matrix-token-ccc`), the daemon
 would exit 0 quietly the first time it ran and the MCP would have no
-backend until the next restart. The `.path` unit makes the appearance
+daemon until the next restart. The `.path` unit makes the appearance
 of the token re-fire the service so the daemon comes alive in the
 same boot cycle as
 provisioning. The same token watcher also drives avatar setting: on a

docs/networking/gateway.md

@@ -49,7 +49,7 @@ For matrix / per-agent static assets, `<final>` is `=404` (a missing asset is ju
 
 ### Dashboard: path-based routing (not Accept-header)
 
-Every hive-c0re backend route lives under `/api/` plus the single `/webhook/knowledge` endpoint, so the dashboard vhost routes by **path**, not Accept header — deterministic, unlike a content-type split where the same URL could resolve differently depending on the caller's `Accept` header:
+Every hive-c0re route lives under `/api/` plus the single `/webhook/knowledge` endpoint, so the dashboard vhost routes by **path**, not Accept header — deterministic, unlike a content-type split where the same URL could resolve differently depending on the caller's `Accept` header:
 
 - `location /api/` → hive-c0re (`7000`): all dashboard data, actions/mutations, and the two SSE streams (`/api/dashboard/stream`, `/api/build-logs/id/{id}/stream`). Carries `proxy_buffering off` + a 1d read timeout for the streams.
 - `location /webhook/` → hive-c0re: the knowledge webhook.

docs/process/conventions.md

@@ -280,8 +280,8 @@ straight to `new Date(s)` for display.
 Every HTTP API in this repo answers failures with **RFC 9457
 `application/problem+json`** (`{ type, title, status, detail }`), with the
 human-readable cause in `detail`. An endpoint of ours returning a bare string
-or a bespoke error shape is a **bug to file against the backend**, not
-something for the caller to work around.
+or a bespoke error shape is a **bug to file against the daemon that
+returned it**, not something for the caller to work around.
 
 Use the `problem_details` crate (`features = ["axum"]`), which the daemons
 already depend on: type a handler `Result<_, ProblemDetails>` and hand

docs/process/gotchas.md

@@ -369,7 +369,7 @@ Never use raw `curl` for forge access.
 ### Weston VNC compositor (per-agent `hyperhive.gui.enable`)
 
 `nix/agent-modules/weston-vnc.nix` adds an optional Weston Wayland
-compositor with the VNC backend, surfaced as
+compositor with the `vnc-backend` plugin, surfaced as
 `hyperhive.gui.enable = true` per-agent. The harness's
 `/screen/ws` WebSocket relay (`docs/web-ui/agent.md::Per-agent endpoints`)
 connects to the compositor at `127.0.0.1:<vnc_port>`.
@@ -413,8 +413,8 @@ connects to the compositor at `127.0.0.1:<vnc_port>`.
   back to a headless display or errors out, the app "works" on a
   second invisible display, and the VNC session shows a blank weston
   desktop (#540 double-screen).
-- **VNC bind address**: weston's VNC backend has no CLI
-  bind-address flag (unlike the RDP backend's `--address`), so the
+- **VNC bind address**: Weston's `vnc-backend` has no CLI
+  bind-address flag (unlike the `rdp-backend`'s `--address`), so the
   listener binds `0.0.0.0`. The harness relay only connects via
   `127.0.0.1`; the host firewall blocks the per-agent VNC port range
   from external access. A future weston.ini `[vnc] address=` will

docs/trust-boundary/boundary.md

@@ -26,7 +26,7 @@ always on), the gateway proxies all operator-facing traffic, and
 ## Design rule
 
 **Operator-authority actions never get a per-agent-socket entry
-point.** They live on the core backend.
+point.** They live in hive-c0re.
 
 Worked example — destroying or rebuilding a container is a
 `POST /api/{destroy,rebuild}/{name}` on the core dashboard, _never_ a

docs/web-ui/README.md

@@ -42,7 +42,7 @@ if the gateway isn't in front).
 
 **Check on an agent.** SW4RM shows every container as a row: name,
 whether it's running, what it's currently doing (a live status pill —
-`rebuilding…`, `starting…`, and so on — while something's in flight),
+`rebuilding…`, `starting…`, or similar — while something's in flight),
 and quick links (stats, screen, forge profile). Select the name to open
 its terminal and watch it work in real time.
 

docs/web-ui/dashboard.md

@@ -29,7 +29,7 @@ from the dashboard tab strip.
   H0M3, C0R3, BU1LDS, CR3D3NTIALS, ST4TS), injected at the top
   of `<body>` by `renderServerWarnings` in `common.js`. Driven by
   `state.server_warnings` — a list of `{ kind, level, message }` — and
-  coloured by `level` (`warn` amber / `crit` red). The backend owns the
+  coloured by `level` (`warn` amber / `crit` red). hive-c0re owns the
   threshold + message, so adding a new system warning needs no frontend
   change. Warnings are a push-based registry (`hive-c0re`'s
   `warnings.rs`): any subsystem raises/clears its own entry via an RAII
@@ -145,7 +145,7 @@ and that artifact set survives `lifecycle::destroy`. An agent
 part-way through a spawn is byte-identical on disk to a tombstone, and
 the pane lists both. The pane carries a standing warning to that effect, and
 the row badge says `offline` rather than `destroyed` — the absence of a
-container is all the backend can actually prove. Fixing it properly
+container is all hive-c0re can actually prove. Fixing it properly
 needs a recorded destroy: **#3020**, deferred to the swarm-controller /
 snapshot-storage rework where the problem changes shape.
 
@@ -232,7 +232,7 @@ own domain concept (the component knows nothing about that endpoint).
 **Rows carry no source chip, kind label, timing, or build-log
 deep-link** — the generic graph wire doesn't carry those fields, and
 rows deliberately present exactly what the endpoint provides rather
-than reconstructing chrome the backend no longer sends. Settled entries
+than reconstructing chrome hive-c0re no longer sends. Settled entries
 render their **full step tree**, not just a bare summary — the wire
 doesn't filter `Done` nodes out.
 
@@ -340,7 +340,7 @@ The status dot renders these states:
 
 The container-down cross-reference (`/api/state`) takes precedence over
 the age check. `as_of_unix` is tooltipped ("live as of N ago") throughout
-so freshness is always legible. When `live` is absent (an older backend
+so freshness is always legible. When `live` is absent (an older hive-c0re
 without the snapshot) the dot falls back to a token-present rendering.
 
 The provision form (account name, homeserver, login method) posts
@@ -407,8 +407,8 @@ deliberate non-goal of this tab — tracked separately.
 
 Per-agent permission configuration. Two sections, each rendered as a
 column-driven checkbox matrix: rows are agents, columns are the
-permission names fetched from the backend. The column list is
-authoritative — adding a new tool-group or capability to the backend
+permission names fetched from hive-c0re. The column list is
+authoritative — adding a new tool-group or capability to hive-c0re
 requires no UI change; the new column appears automatically.
 
 The snapshot carries `agents` (the full manageable roster — live
@@ -483,7 +483,7 @@ across *both* matrices and POSTs one batch to `POST /api/permissions` as
 includes only the perm-types that actually changed for each agent (an
 omitted field leaves that file untouched; an included array fully
 replaces it).
-The backend coalesces an agent's capabilities + tool-groups into a
+hive-c0re coalesces an agent's capabilities + tool-groups into a
 single rebuild, so changing both for one agent is one rebuild, not two.
 The batch is atomic: it validates every change first and on any error
 rejects the whole POST (`{error}`, nothing applied); a clean 200 (`ok`)
@@ -554,7 +554,7 @@ all-zero = one-shot), description). Select `＋` to POST to
 carry-state preserves partially typed inputs across re-renders. The tab pill shows the count of active
 schedules (at least one live target not yet cancelled).
 Refreshed on tab activation and after each submit/cancel. Backed by
-`GET /api/schedules`. No backend changes for the table layout
+`GET /api/schedules`. No hive-c0re changes for the table layout
 — it renders entirely from existing `schedulesState` +
 `containersState`.
 
@@ -767,14 +767,14 @@ fetch entirely.
 **Line 1** — agent name (link → new tab), m1nd/ag3nt chip, an
 **icon-only nav strip** plus live agent-owned state, all populated
 async from a single `GET /api/dashboard-state` call to the agent's
-own backend. The response (`DashboardState`) carries: `links` (nav
+own hive-agent. The response (`DashboardState`) carries: `links` (nav
 strip entries — `📊 stats`, `🖥 screen` when GUI is enabled, `⬡ forge
 profile`, `↳ agent-configs mirror`, plus any agent-declared
 `dashboardLinks` extras), `status_text` / `status_set_at` (agent
 self-reported status — the `(set N ago)` chip carries a `data-set-at`
 stamp and ticks every 30s to stay fresh across the long-lived keyed row
 cache), `rate_limited`, `ctx_tokens` / `context_window_tokens`
-(context-window badge data). The agent backend is the single source
+(context-window badge data). hive-agent is the single source
 of truth for all of these. The dashboard resolves each `AgentLink.kind`
 against a per-agent base URL depending on whether hive-gateway is in
 front (`StateSnapshot.gateway_enabled`, sourced from the
@@ -819,7 +819,7 @@ stopped deliberately. Both states read `running: false`; `failed` is
 the orthogonal fact (a fifth one alongside `paused`/`needs_update`/
 `needs_login`, same "independent flags, no state machine" shape —
 see `ContainerView`'s own doc comment) that tells them apart. An
-older backend without the field serves `failed: undefined`, which
+older hive-c0re without the field serves `failed: undefined`, which
 reads falsy — degrades cleanly to the single `not running` badge.
 
 When the container is running, status badges follow — `⊘ rate
@@ -854,7 +854,7 @@ life). Two consequences for anything rendering it:
   particular no longer exists, because no node kind is unique to a
   restart.
 - It's **not** exclusively operator-initiated, and **not** limited
-  to rebuild-shaped work — `running_transients()` on the backend is
+  to rebuild-shaped work — `running_transients()` in hive-c0re is
   a status-only test (any `Running` node whose payload names a
   non-empty agent lights a pill), so work the operator never
   triggered (a meta-update cascade, a crash-recover rebuild, a
@@ -961,7 +961,7 @@ bulk) carries a `stop gracefully — let the agent finish its turn
 and flush state before the container stops` checkbox. When ticked,
 the action POSTs `/api/kill/<name>?graceful=true` (the bulk path
 appends the flag per-agent); unticked is the instant hard stop
-(`/api/kill/<name>` with no query). The backend enqueues a
+(`/api/kill/<name>` with no query). hive-c0re enqueues a
 `Signal` → `Drain` job-queue node pair (`NodeKind::Signal` /
 `NodeKind::Drain`): `Signal` sets the graceful-stop fence and kicks
 the harness so it runs one stop-checkpoint turn (so the agent can
@@ -1025,14 +1025,14 @@ frosted-mauve bar slides up from the bottom of the viewport
   - `DESTR0Y` / `PURG3` — always available
   - `⇡ M0V3 → ROOT` — promote selected agents to top-level
     (parent = null); disabled when all selected are already at root.
-    Backend `topology::set_parent` refuses moves it can't satisfy
+    hive-c0re's `topology::set_parent` refuses moves it can't satisfy
     (for example a move that would create a cycle) and the refusal surfaces
     in the failure roll-up.
   - `⇢ M0V3 → [select]` — inline picker available for any
     selection size. The dropdown lists every container that isn't IN
     the selection itself nor a descendant of any selected agent
     (client-side BFS cycle prevention across the whole batch; the
-    backend re-checks per-agent). On submit:
+    hive-c0re re-checks per-agent). On submit:
     - **single agent** → `POST /api/topology/set-parent`
       (form-encoded `child=<name>&new_parent=<target>`)
     - **multiple agents** → `POST /api/topology/set-parent-bulk`