vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs: clear write-good.Passive hits in docs/agent-lifecycle/approvals.md

Browse source
This commit is contained in:
iris 2026-09-20 14:29:48 +02:00
commit 99a4a75bf7
1 changed files with 8 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/agent-lifecycle/approvals.md
View file

@ -25,9 +25,9 @@ CLI) before it takes effect. What you'll see, and what to do with it:
the agent stays on its last-good config, no recovery action needed
from you.
- **New agent** (`Spawn`) — the one approval in creating a brand-new
agent. Its config repo is scaffolded first, outside the approval
queue, by the swarm controller's `InitAgentConfigRepo` job
(`POST /api/agents`); `Spawn` then creates the container from that
agent. The swarm controller's `InitAgentConfigRepo` job
(`POST /api/agents`) scaffolds its config repo first, outside the
approval queue; `Spawn` then creates the container from that
config. Tailoring what the template seeded isn't a separate
mechanism — it's the config-change flow above, a PR you review like
any other. Every later change goes through that flow — there's no
@ -133,9 +133,9 @@ agent that lacks the `approvals` tool group: only an agent with that
group submits approvals (for its direct children), so an agent
without it has nothing of its own to withdraw.
A brand-new agent's config repo is created outside this queue, by the
swarm controller's `InitAgentConfigRepo` job, which seeds it with a
default `agent.nix` template. The operator then **spawns** the agent
The swarm controller's `InitAgentConfigRepo` job creates a brand-new
agent's config repo outside this queue, seeding it with a default
`agent.nix` template. The operator then **spawns** the agent
(the `Spawn` approval / `◆ R3QU3ST SP4WN` button), which creates the
container from that config.
@ -612,8 +612,8 @@ root agent. Variants (`hive_sh4re::manager::HelperEvent`):
approval transitions to its terminal state.
- `ContainerCrash { agent, note }` — `crash_watch`: a previously-
running container went away with no operator-initiated transient
state (Stopping / Restarting / Destroying / Rebuilding) AND no
such transient was cleared in the last 30s (`RECENT_TRANSIENT_GRACE`
state (Stopping / Restarting / Destroying / Rebuilding) AND nothing
cleared that transient in the last 30s (`RECENT_TRANSIENT_GRACE`
tombstone, three `POLL_INTERVAL`s — closes the race where a
lifecycle op finishes between two crash-watch polls and the
container shows briefly as "stopped without transient" before