ask: rename ask_operator → ask + optional 'to' for agent-to-agent Q&A

README.md

@@ -33,12 +33,12 @@ host (NixOS, runs hive-c0re.service)
    ├── hm1nd      hive-m1nd serve : claude turn loop +
    │              MCP (send / recv / request_spawn / kill / start /
    │                   restart / update / request_apply_commit /
-   │                   ask_operator) + web UI on :8000
+   │                   ask / answer / remind) + web UI on :8000
    │
    └── h-<name>   hive-ag3nt serve : claude turn loop +
-                  MCP (send / recv / ask_operator + agent-declared extras
-                       via hyperhive.extraMcpServers) + web UI on a
-                  hashed :8100-8999
+                  MCP (send / recv / ask / answer / remind + agent-declared
+                       extras via hyperhive.extraMcpServers) + web UI
+                  on a hashed :8100-8999
 ```
 
 Each turn: harness pops one inbox message (Recv long-polls server-side and
@@ -89,10 +89,13 @@ inside the container — so `git fetch applied`,
 `cat /meta/flake.lock` all just work without constructing paths by
 hand. See [`docs/approvals.md`](docs/approvals.md) for the full state
 machine + lock-flow walkthrough.
-For decisions the manager needs human signal on, `ask_operator(question,
-options?, multi?)` queues a free-text/checkbox/radio form on the
-dashboard; the answer arrives later as a `HelperEvent::OperatorAnswered`
-in the manager's inbox.
+For decisions any agent (manager or sub) needs structured signal on,
+`ask(question, options?, multi?, ttl_seconds?, to?)` queues a question:
+default recipient is the operator (dashboard renders a free-text /
+checkbox / radio form), or pass `to: "<agent>"` to route a structured
+peer question into another agent's inbox. The answer arrives later as
+a `HelperEvent::QuestionAnswered { id, question, answer, answerer }`
+in the asker's inbox. Peer recipients respond via `answer(id, answer)`.
 
 ## Host config