remove the needs_update system event: nothing emits it

Refs #5948

docs/README.md

@@ -27,7 +27,7 @@ declarations.
 
 - **How do config changes flow from manager to operator to container?** →
   [`agent-lifecycle/config-changes.md`](agent-lifecycle/config-changes.md)
-  (config PRs, the meta flake, helper events).
+  (config PRs, the meta flake, system messages).
 - **What state survives destroy / purge / restart?** →
   [`agent-lifecycle/persistence.md`](agent-lifecycle/persistence.md).
 - **Who can do what to whom — the agent roster and privilege?** →

docs/agent-lifecycle/config-changes.md

@@ -1,8 +1,8 @@
-# Config changes + helper events
+# Config changes + system messages
 
 Config changes are pull requests on the agent's config repo, which an
-operator merges on the forge; that merge deploys them. Helper events are
-how agents stay informed about lifecycle changes that need a reaction.
+operator merges on the forge; that merge deploys them. The "System messages"
+section covers the plain-text `system` messages hive-c0re sends agents.
 
 ## For operators
 
@@ -322,24 +322,17 @@ for the root agent. The root agent's role-specific
 behaviour comes from its AGENTS.md / agent-specific instructions, not
 the system prompt template.
 
-## Helper events
+## System messages
 
-`hive_sh4re::manager::HelperEvent` is the wire type for an event urgent
-enough to drive an immediate claude turn (delivered as a regular
-`system` inbox message, same `recv` path as any other message). It
-currently has one variant, `NeedsUpdate { agent }` (sub-agent's
-recorded flake rev is stale, operator rebuilds from the dashboard) —
-and nothing in the tree constructs it; this removal dropped the push path
-(`Coordinator::notify_agent`) once its last caller
-(`notify_manager`, used only for the crash event below) went away.
-`HelperEvent` stays as the type for whatever comes along that
-genuinely needs to interrupt an agent's turn loop, not because
-anything live uses it today.
+Hive-c0re has no typed event that drives an immediate claude turn. A
+message from sender `system` is plain inbox text, and the harness logs it
+(`log_system_event` in `hive-agent/src/main.rs`) without parsing the body.
+Today hive-c0re sends two: the `/knowledge updated` broadcast
+(`workers/knowledge.rs`) and the wake message for a graceful stop
+(`Coordinator::kick_agent`).
 
-**A previously running container crashing** used to be exactly that
-case (`ContainerCrash`, routed to the root agent via
-`Coordinator::notify_manager`) — it no longer drives any agent turn at
-all. `crash_watch` now only `tracing::warn!`s `"container crash
+**A previously running container crashing** drives no agent turn.
+`crash_watch` only `tracing::warn!`s `"container crash
 detected"`; a swarm-level grafana alert matches that log line directly
 and pages the operator, with no agent (and no per-hive dashboard
 banner) in the loop. See
@@ -348,18 +341,16 @@ banner) in the loop. See
 The remaining lower-urgency lifecycle notices — `Rebuilt`, `Killed`,
 `Destroyed`, `NeedsLogin`, `LoggedIn` — are "FYI, check
 when convenient" events with no reason to drive an immediate turn, so
-they go out via `swarm_notices::notify` instead
-of a `HelperEvent`: `subsystem = "core"`, `key = "<event>:<agent>"`,
-and a single free-text `summary` (`rebuilt_todo_summary` renders
-`Rebuilt`'s `ok`/`note`/`sha`/`tag` fields into that string).
+they go out via `swarm_notices::notify` instead: `subsystem = "core"`,
+`key = "<event>:<agent>"`, and a single free-text `summary`
+(`rebuilt_todo_summary` renders `Rebuilt`'s `ok`/`note`/`sha`/`tag`
+fields into that string).
 
 To add a new lifecycle notice: if it's "FYI, check when convenient,"
 call `swarm_notices::notify` — no new wire type needed. If it needs to
 drive an immediate turn, decide first whether it actually needs an
 *agent* in the loop at all (the crash case above didn't, once a
-swarm-level alert could carry the same signal) — only reach for a new
-`HelperEvent` variant + `notify_agent`-equivalent call site +
-`prompts/system.md` update when the answer is yes.
+swarm-level alert could carry the same signal).
 
 ## Autoupdate on startup
 

docs/scheduler/coordinator.md

@@ -519,7 +519,7 @@ config — all nspawn containers live in `machine.slice`.
 
 ## See also
 
-- `docs/agent-lifecycle/config-changes.md` — config PRs, meta flake, helper events
+- `docs/agent-lifecycle/config-changes.md` — config PRs, meta flake, system messages
 - `docs/agent-lifecycle/persistence.md` — SQLite schema, state-dir layout
 - `docs/process/conventions.md` — wire protocol, recipient sentinels
 - `docs/agent-lifecycle/agent-roster.md` — the agent roster and privilege

docs/turn-loop/mcp.md

@@ -68,13 +68,9 @@ runs on the change.
   `ack_until(N)` to prevent re-pop. Acked rows never redeliver.
   Transient pings (sentinel id 0) have nothing to ack and show no marker.
 
-**System messages** (from sender `system`): the broker delivers
-`hive_sh4re::manager::HelperEvent` (one variant, `NeedsUpdate` —
-declared, but no call site constructs it) as regular inbox messages
-(same `recv` path; body is a JSON object with an `event` discriminant
-field). A container crash used to be the other variant
-(`ContainerCrash`, routed to `ruth`) but this tree no longer has that
-path — a crash now only produces a log line + swarm-level grafana
+**System messages** (from sender `system`): the broker delivers them as regular inbox
+messages (same `recv` path). A container crash never reaches an
+agent — it only produces a log line + swarm-level grafana
 alert, no agent turn at all (`docs/scheduler/observability.md`). Lifecycle
 transitions the job-queue scheduler or crash watcher drive directly —
 stop/kill, destroy, a flake-rev login or logout state change — reach