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

docs/approvals.md

@@ -42,19 +42,15 @@ 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_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.
+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.
 
 ## Meta flake
 
@@ -333,8 +329,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` (Spawn-kind)
-  + admin `HostRequest::Spawn`.
+- `Spawned { agent, ok, note }` — `actions::approve` (first-time
+  ApplyCommit-kind) + admin `HostRequest::Spawn` (deprecated).
 - `Rebuilt { agent, ok, note }` — `auto_update::rebuild_agent`
   (covers startup scan + manual `/rebuild` from dashboard) +
   `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
   just seeded (post-`InitConfig` approval). The manager can now
   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
   stale. Manager calls `update(name)` to rebuild — idempotent,
   no approval required.

docs/turn-loop.md

@@ -216,6 +216,12 @@ 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
 
@@ -281,6 +287,12 @@ 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