hive-c0re, docs: sweep remaining stale ask/answer-dashboard references

docs/approvals.md

@@ -635,10 +635,13 @@ root agent. Variants (`hive_sh4re::manager::HelperEvent`):
 - `NeedsUpdate { agent }` — sub-agent's recorded flake rev is
   stale. The root agent calls `update(name)` to rebuild — idempotent,
   no approval required.
-- `QuestionAnswered { id, question, answer, answerer }` —
-  dashboard `/answer-question/{id}` (answerer = `"operator"`),
-  peer `Answer` request (answerer = agent name), or ttl watchdog
-  expiry (answerer = `"ttl-watchdog"`, answer = `"[expired]"`).
+- `QuestionAnswered { id, question, answer, answerer }` — peer
+  `Answer` request (answerer = agent name) or ttl watchdog expiry
+  (answerer = `"ttl-watchdog"`, answer = `"[expired]"`). The dashboard's
+  own `/answer-question/{id}` trigger (answerer = `"operator"`) is
+  gone — removed along with the rest of the dashboard's ask/answer
+  surface, so an operator-targeted question now has no path to an
+  answer at all.
 - `QuestionAsked { id, asker, question, options, multi }` —
   fired when an agent calls `Ask { to: Some(<this-agent>), ... }`.
   The recipient responds via `Answer { id, answer }` and the

docs/boundary.md

@@ -28,14 +28,12 @@ always on), the gateway proxies all operator-facing traffic, and
 **Operator-authority actions never get a per-agent-socket entry
 point.** They live on the core backend.
 
-Worked example — answering an operator-targeted question is a
-`POST /api/answer-question/{id}` on the core dashboard, _never_ a
+Worked example — destroying or rebuilding a container is a
+`POST /api/{destroy,rebuild}/{name}` on the core dashboard, _never_ a
 per-agent-socket `Request` variant. If it were a per-agent-socket
-request, an agent could `curl` its own socket and spoof an operator
-answer.
-The per-agent web UI POSTs cross-origin to the core for these
-(see the inline-answer feature — the loose-ends section on each
-agent page).
+request, a compromised agent could `curl` its own socket and destroy
+or rebuild itself (or, if the variant took an arbitrary target, another
+agent) without ever touching the core's own authenticated surface.
 
 ## Why network isolation is the load-bearing step
 
@@ -67,9 +65,10 @@ The boundary rests on three layers:
 
 1. **Gateway** — fronts all surfaces (dashboard + every per-agent UI)
    on one origin. An nginx nixos-container proxies per-agent UIs under
-   `/agent/<name>/`, which is what lets the inline-answer POST to
-   `/answer-question/{id}` go same-origin instead of needing a
-   cross-origin CORS shim. Pure ergonomics — no behavioural risk on
+   `/agent/<name>/`, which is what lets each agent page's inbox panel
+   POST `mark-all-read` to the core dashboard's
+   `/api/agent/{name}/mark-all-read` go same-origin instead of needing
+   a cross-origin CORS shim. Pure ergonomics — no behavioural risk on
    its own.
 2. **Network isolation** — the load-bearing layer: every agent
    container runs in a private netns behind the hive bridge, always

docs/conventions.md

@@ -174,14 +174,16 @@ the dashboard's "mark all read" (unbounded, per-agent).
 ### Question routing (Ask / Answer)
 
 `AgentRequest::Ask` (and the manager-flavour mirror) surfaces a
-structured question that either lands in the operator's dashboard
-queue or in a peer agent's inbox. The recipient is the `to` field:
+structured question that either lands in the operator-question queue
+or in a peer agent's inbox. The recipient is the `to` field:
 
 - `to = None` or `to = Some("operator")` — routes to the
-  operator-question queue. The dashboard renders the question with
-  any `options` as a chip strip plus a free-text fallback (`Other…`)
-  so the operator is never trapped by an incomplete list. The
-  legacy `AskOperator` variant collapses into this case.
+  operator-question queue. ⚠️ The dashboard's whole ask/answer
+  surface (the UI that used to render this queue and let the operator
+  reply) has been removed — an operator-targeted question currently
+  has no reader anywhere; this routing case is being removed too as
+  the same effort continues. The legacy `AskOperator` variant
+  collapses into this case.
 - `to = Some(<agent>)` — peer Q&A. The target agent receives a
   `HelperEvent::QuestionAsked { id, asker, question, options, multi }`
   in their inbox. They reply via `AgentRequest::Answer` (or
@@ -191,21 +193,23 @@ queue or in a peer agent's inbox. The recipient is the `to` field:
 
 Shape fields are uniform across both targets:
 
-- `options` is advisory — the dashboard chips are decoration over a
-  free-text fallback; peer-agent recipients see the list in their
-  `QuestionAsked` event and can return any string.
-- `multi = true` lets the answerer pick multiple options (checkboxes
-  in the dashboard, a hint in the peer-agent event). The answer
-  comes back as a single string with selections joined by `", "`.
+- `options` is advisory — a list is never enforced; peer-agent
+  recipients see it in their `QuestionAsked` event and can return any
+  string regardless.
+- `multi = true` is a hint that the answerer should treat `options` as
+  a multi-select rather than pick-one. The answer comes back as a
+  single string with selections joined by `", "`.
 - `ttl_seconds` auto-cancels with answer `[expired]` (and `answerer:
   "ttl-watchdog"`) when the wait becomes moot. `None` = wait
   indefinitely or until manual cancel.
 
 Response shape is always `QuestionQueued { id }` — the asker stores
 the id and correlates the asynchronous answer event when it lands.
-Authorisation on `Answer`: only the question's `target` agent (or
-the operator via the dashboard) is permitted to reply; an answer
-attempt from anyone else fails the wire-side check.
+Authorisation on `Answer`: only the question's `target` agent, or the
+operator, is permitted to reply; an answer attempt from anyone else
+fails the wire-side check. (The operator's only path to invoke this
+was the now-removed dashboard — see the note above; the
+authorisation rule itself is unchanged.)
 
 ### Loose-ends wire shape
 

docs/web-ui/dashboard.md

@@ -1172,13 +1172,6 @@ below — some endpoints aren't in it yet.
 - `POST /api/{rebuild,kill,restart,start,destroy}/{name}` — lifecycle.
   `destroy` accepts `purge=on` to also wipe state dirs.
 - `POST /api/purge-tombstone/{name}` — wipe a tombstone's state dirs.
-- `POST /api/answer-question/{id}` — answer a pending operator question.
-  No dashboard UI calls this any more (the questions pane is gone —
-  see hyperhive#3721); kept as long as the backend `ask`/`answer`
-  mechanism itself still exists.
-- `POST /api/cancel-question/{id}` — cancel a pending question with
-  the sentinel `[cancelled]`. Same code path as a real answer. Same
-  no-UI-consumer note as above.
 - `POST /api/request-spawn` — queue a Spawn approval.
 - `POST /api/update-all` — rebuild every stale container.
 - `POST /api/rebuild-queue/{id}/cancel` — drop a `Queued` entry.
@@ -1383,12 +1376,6 @@ payload):
   sha_short, status, resolved_at, note, description) — pending
   queue + history mutations. Client mutates a derived store and
   re-renders only the approvals section.
-- `question_added` (id, asker, question, options, multi,
-  asked_at, deadline_at, target) / `question_resolved` (id,
-  answer, answerer, answered_at, cancelled, target) — still
-  fired by the backend `ask`/`answer` mechanism, but the
-  dashboard no longer subscribes to either kind: the questions
-  pane that used to surface them is gone (hyperhive#3721).
 - `transient_set` (name, transient_kind, since_unix) /
   `transient_cleared` (name) — lifecycle action spinners. The
   client ticks the elapsed-seconds badge off `since_unix`