vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

remove the needs_update system event: nothing emits it

Browse source 
Refs #5948
This commit is contained in:
atlas 2026-11-01 22:49:01 +01:00
commit 99752f81d9
1 changed files with 40 additions and 79 deletions
Download patch file Download diff file Expand all files Collapse all files

43
docs/agent-lifecycle/config-changes.md
View file

@ -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