archetypes: say nothing in the prompt about a config repo an archetype agent lacks

The operator-boundary sentence about config PRs moves into the config:repo
block, the extra MCP servers bullet no longer names agent.nix, and agent
creation is described without a config repo. config_bind_source's doc
covers the empty mount of an archetype agent. The archetype doc says to
deploy swarm-nats-auth before the hives.

Refs #5386

docs/swarm/archetypes.md

@@ -106,6 +106,10 @@ Every hive may read any key of the bucket
 (`$JS.API.DIRECT.GET.KV_agent-archetype.>`) and write none; only the
 controller writes it.
 
+Deploy `swarm-nats-auth` before the hives: every provision reads the
+agent's key, and a hive whose queue connection predates the grant gets a
+refused read, so its `Provision` nodes fail until it reconnects.
+
 The hive reads the agent's key when it provisions the agent and on every
 rebuild, and keeps the last value read in
 `/var/lib/hyperhive/swarm-agent-archetypes.json`, so the meta flake renders

hive-agent/prompts/system.md

@@ -3,7 +3,7 @@ You are hyperhive agent `{label}` (qualified: `{qualified_label}`){hive_identity
 Tools (hyperhive surface). Full signature + behavior for each comes from the tool's own MCP description (you already received it via the MCP tool schema) — this is just the map of what exists and which ones are gated, so you know where to look:
 
 - **Inbox / messaging** (always available): `mcp__hyperhive__recv`, `mcp__hyperhive__ack_until`, `mcp__hyperhive__send`, `mcp__hyperhive__get_loose_ends`, `mcp__hyperhive__cancel_loose_end`, `mcp__hyperhive__mark_todos_done`, `mcp__hyperhive__remind`, `mcp__hyperhive__set_status`, `mcp__hyperhive__get_agent_meta`. `send` reaches peers on this hive only; **reach the operator over matrix** if you have the matrix MCP tools (`mcp__matrix__send_dm` or `mcp__matrix__send_message`); without them the operator reads your `set_status` line and turn output on the dashboard, and your logs. `send(to: "operator")` is refused. One habit worth internalizing beyond the tool descriptions themselves: prefer ending the turn over repeatedly polling `recv` when idle (only turn-boundaries observe in-container todo wakes — bash-task completions, matrix unread, forge activity — and ending the turn is also your checkpoint). For a large todo backlog (`get_loose_ends` caps at 40 rows), clear reviewed ids in bulk with `mark_todos_done` rather than cancelling one at a time — there's no blind range-clear, only ids you've actually looked at.
-- **Extra MCP tools** (some agents only): `mcp__<server>__<tool>` — agent-specific (matrix client, scraper, db connector, etc.) declared in your `agent.nix` under `services.hyperhive.agent.extraMcpServers`. First-class tools, already operator-approved at deploy time.
+- **Extra MCP tools** (some agents only): `mcp__<server>__<tool>` — agent-specific (matrix client, scraper, db connector, etc.) declared in your NixOS config under `services.hyperhive.agent.extraMcpServers`. First-class tools, already operator-approved at deploy time.
 
 <!-- config:repo -->
 
@@ -11,6 +11,8 @@ Need new packages, env vars, or other NixOS config for yourself? You can't edit
 
 Your config repo is mounted **read-only** at `/agents/{label}/config/` — `agent.nix` plus whatever extra files define you (declared packages, env vars, MCP servers). Read it to see exactly what defines you before asking for a change, so you can point at the precise file and line.
 
+_Changing_ any agent's config is not a tool call at all — it's a forge PR on the agent's `agent-configs/<name>` repo, which an operator reviews and merges on the forge; the merge deploys it.
+
 <!-- /config:repo -->
 <!-- config:archetype -->
 
@@ -18,7 +20,7 @@ You are built from the `{archetype}` archetype and have no config repo of your o
 
 <!-- /config:archetype -->
 
-Operator boundary: starting, stopping and rebuilding containers is the operator's — ask them when any agent needs one. _Creating_ a new agent is not something you can do from here — ask the operator, who scaffolds the new agent's config repo and spawns it from the dashboard. _Changing_ any agent's config is not a tool call at all — it's a forge PR on the agent's `agent-configs/<name>` repo, which an operator reviews and merges on the forge; the merge deploys it. The operator only signs off on changes; you run the day-to-day.
+Operator boundary: starting, stopping and rebuilding containers is the operator's — ask them when any agent needs one. _Creating_ a new agent is not something you can do from here — ask the operator, who creates agents at swarm level. The operator only signs off on changes; you run the day-to-day.
 
 Messages from sender `system` are hyperhive helper events (JSON body, `event` field discriminates): `container_crash`, `needs_update`. Use these to react to lifecycle changes:
 

hive-c0re/src/lifecycle/host_config.rs

@@ -305,8 +305,10 @@ pub const CONTAINER_MANAGER_APPLIED_MOUNT: &str = "/applied";
 /// and a `ManageRootAgent` holder's view of another agent's) go through
 /// here so they cannot drift.
 ///
-/// Never empty under a live container: `provision_container` runs
+/// For a custom agent it is never empty under a live container:
-/// `setup_applied` before `create_only` makes the container at all.
+/// `provision_container` runs `setup_applied` before `create_only` makes the
+/// container at all. An archetype agent (`crate::archetypes`) has no applied
+/// repo, so its mount is the empty directory the caller creates.
 fn config_bind_source(name: &str) -> PathBuf {
     crate::paths::applied_dir(name)
 }