diff --git a/docs/agent-lifecycle/approvals.md b/docs/agent-lifecycle/approvals.md
index 25ddea72..6ec0f062 100644
--- a/docs/agent-lifecycle/approvals.md
+++ b/docs/agent-lifecycle/approvals.md
@@ -1,8 +1,8 @@
 # Approvals + helper events
 
 The approval queue is where an agent asks the operator for something it
-can't do itself: a scheduled prompt, or (legacy rows only) a meta-input
-bump. Config changes don't go through this queue: they're pull requests
+can't do itself: a scheduled prompt, or a meta-input bump. Config
+changes don't go through this queue: they're pull requests
 on the agent's config repo, which an operator merges on the forge, and
 that merge deploys them. The submitting agent — any agent with the
 `approvals` tool group, which manages the config of its **direct
@@ -23,10 +23,9 @@ it stays informed about what happens after a decision lands.
   directly from the SCH3DUL3S tab, which skips this approval step
   entirely — the gate here is specifically for an *agent* asking to
   schedule something, not for you doing it.
-- **Meta/flake update** (`UpdateMetaInputs`) — legacy: nothing queues
-  this kind, but an existing row still reads back and you can approve it.
-  Approving runs the update and commits the lock change; it doesn't
-  rebuild anything by itself.
+- **Meta/flake update** (`UpdateMetaInputs`) — an existing row reads
+  back and you can approve it. Approving runs the update and commits
+  the lock change; it doesn't rebuild anything by itself.
 
 Don't want to approve something? **Deny it** (`DENY` on the dashboard
 card, or `hivectl approvals deny <id>`) — nothing runs. Either way the
diff --git a/docs/swarm/README.md b/docs/swarm/README.md
index 81f5fc61..e62f7d58 100644
--- a/docs/swarm/README.md
+++ b/docs/swarm/README.md
@@ -259,6 +259,9 @@ A `config-pr` delivery reporting a PR merged into `main` queues a deploy
 of its `merge_commit_sha` on the one hive whose wanted state places the
 agent; with no such hive, or several, the controller deploys nothing. See
 [approvals.md § Config changes](../agent-lifecycle/approvals.md#config-changes).
+A merge whose `closed` delivery never arrives deploys nothing either; the
+operator recovers by redelivering that delivery from the forge hook page,
+which re-enters the same handler and re-queues the deploy.
 
 **`internal/knowledge` is on that path.** The controller's is the only
 hook on it ([`knowledge.md`](../integrations/knowledge.md) covers clearing a
@@ -268,10 +271,11 @@ would take delivery away from the first rather than add a recipient.
 <!-- vale write-good.Passive = NO -->
 
 **The `agent-configs` org is on it too.** The controller's hook is the
-only one that acts on config PRs. A hive's `/webhook/config-pr` hook left
-on the org by an older release delivers to a route no hive serves; each
-hive deletes its own on startup. Removing the controller's hook stops
-forge-UI merges from deploying until its next start recreates it.
+only one that acts on config PRs. Each hive deletes its own
+`/webhook/config-pr` org hook on startup, since a route no hive serves
+would otherwise sit on the org collecting failed deliveries. Removing
+the controller's hook stops forge-UI merges from deploying until its
+next start recreates it.
 
 <!-- vale write-good.Passive = YES -->
 
diff --git a/hive-c0re/README.md b/hive-c0re/README.md
index 417e8f87..bfc1c876 100644
--- a/hive-c0re/README.md
+++ b/hive-c0re/README.md
@@ -43,9 +43,9 @@ to track it:
 - **`coordinator.rs`** — top-level wiring for `serve`.
 - **`meta.rs`**, **`migrate.rs`** — the meta flake + schema/state
   migrations.
-- **`matrix.rs`**, **`gateway_nginx.rs`**, **`webhook_secret.rs`**,
-  **`priv_client.rs`** — matrix provisioning, gateway vhosts, webhook
-  secrets, and the `hive-priv` client respectively.
+- **`matrix.rs`**, **`gateway_nginx.rs`**, **`priv_client.rs`** —
+  matrix provisioning, gateway vhosts, and the `hive-priv` client
+  respectively.
 
 See the top-level `CLAUDE.md`/`docs/` index for the full reading-path
 map.