docs/approvals.md

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

docs/turn-loop.md

@@ -216,12 +216,6 @@ it as a stdio child via `--mcp-config`. The hyperhive socket name is
   scheduling a new one fails if the cap is already hit.
 - `whoami()` — `{ name, role, pronouns, hyperhive_rev }` for
   self-identification without scraping the system prompt.
-- `request_next_turn()` — ask the harness to start another turn
-  immediately after this one ends, even if the inbox is empty. Use for
-  multi-turn tasks (long builds, sequential steps) where you want to
-  continue without waiting for an external message. The next turn starts
-  with `from: "self"` and `body: "continue"`. No-op if new inbox
-  messages arrive before this turn ends. No args.
 
 ### Waking the agent from inside the container
 
@@ -287,12 +281,6 @@ meta's.
 - `request_apply_commit(agent, commit_ref)` — submit a config
   change for any agent (`hm1nd` for the manager's own config) for
   operator approval.
-- `request_update_meta_inputs(inputs?, description?)` — queue an
-  approval to run `nix flake update [inputs...]` on the meta flake.
-  Pass specific input names (e.g. `["bitburner-agent"]`) or omit
-  for all. Returns immediately; lock update runs on operator
-  approval. Does NOT trigger rebuilds — call `update(name)` on
-  affected agents after approval resolves.
 - `ask(question, options?, multi?, ttl_seconds?, to?)` —
   surface a structured question to the operator (default) or a
   sub-agent (`to: "<agent>"`). Non-blocking — returns the