vinzenz/hyperhive
0
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: update spawn flow docs for apply_commit handling first spawn (follow-up to 66f1568)

Browse source
This commit is contained in:
lexis 2026-05-22 21:46:27 +02:00
parent 3abb00c327
commit 40589c8510
1 changed files with 9 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

21
docs/approvals.md
View file

@ -42,19 +42,15 @@ happens after a decision lands.
ApplyCommit kind) land in the manager's inbox, carrying both ApplyCommit kind) land in the manager's inbox, carrying both
the canonical sha and the terminal tag. the canonical sha and the terminal tag.
`Spawn` approvals follow the same shape but skip the commit-diff
step — the operator just sees the name. On approve, hive-c0re
creates the container in a background task while the dashboard
shows a spinner.
`InitConfig` approvals are the first step in a two-step spawn `InitConfig` approvals are the first step in a two-step spawn
flow. On approve, hive-c0re seeds the proposed config repo with flow. On approve, hive-c0re seeds the proposed config repo with
a default `agent.nix` template and sends the manager a default `agent.nix` template and sends the manager
`HelperEvent::ConfigReady { agent }`. The manager then reviews, `HelperEvent::ConfigReady { agent }`. The manager then reviews,
edits, and commits the template before calling `request_spawn` edits, and commits the template before calling `request_apply_commit`
to proceed to a Spawn approval. This gives the manager (and to proceed to an `ApplyCommit` approval. The first `ApplyCommit`
operator) an explicit review gate on the initial configuration creates the container; subsequent ones rebuild it with new config.
before any container is created. This gives the manager (and operator) an explicit review gate on the
initial configuration before any container is created.
## Meta flake ## Meta flake
@ -333,8 +329,8 @@ regular claude turn so the manager can react. Variants
- `ApprovalResolved { id, agent, commit_ref, status, note }` — - `ApprovalResolved { id, agent, commit_ref, status, note }` —
fired by `actions::approve` + `actions::deny` whenever an fired by `actions::approve` + `actions::deny` whenever an
approval transitions to its terminal state. approval transitions to its terminal state.
- `Spawned { agent, ok, note }` — `actions::approve` (Spawn-kind) - `Spawned { agent, ok, note }` — `actions::approve` (first-time
+ admin `HostRequest::Spawn`. ApplyCommit-kind) + admin `HostRequest::Spawn` (deprecated).
- `Rebuilt { agent, ok, note }` — `auto_update::rebuild_agent` - `Rebuilt { agent, ok, note }` — `auto_update::rebuild_agent`
(covers startup scan + manual `/rebuild` from dashboard) + (covers startup scan + manual `/rebuild` from dashboard) +
`actions::approve` (ApplyCommit). `actions::approve` (ApplyCommit).
@ -353,7 +349,8 @@ regular claude turn so the manager can react. Variants
- `ConfigReady { agent }` — a new agent's proposed config repo was - `ConfigReady { agent }` — a new agent's proposed config repo was
just seeded (post-`InitConfig` approval). The manager can now just seeded (post-`InitConfig` approval). The manager can now
edit `/agents/<agent>/config/agent.nix`, commit the changes, edit `/agents/<agent>/config/agent.nix`, commit the changes,
and submit `request_spawn` to create the container. and submit `request_apply_commit` with the commit sha to create
the container (first ApplyCommit also triggers spawn bookkeeping).
- `NeedsUpdate { agent }` — sub-agent's recorded flake rev is - `NeedsUpdate { agent }` — sub-agent's recorded flake rev is
stale. Manager calls `update(name)` to rebuild — idempotent, stale. Manager calls `update(name)` to rebuild — idempotent,
no approval required. no approval required.