Inline question choices, compact one-click inbox cards, drop snooze

docs/plan.md

@@ -114,8 +114,8 @@ Vendor specifics live behind adapters. The event model is a **shared core plus v
 
 The Go server hosts an MCP server attached to every agent session.
 
-- `ask_human(context, question, why_blocked, options[], recommended_option, attachments[], blocking, thread_id?)`
-  - `context` carries the background the human needs to answer without reading the transcript.
+- `ask_human(context, question, why_blocked, attachments[], blocking, thread_id?)`
+  - `context` carries the background the human needs to answer without reading the transcript, with the choices inline as `- ( ) text` / `- (*) recommended` (pick one) or `- [ ] text` / `- [x] recommended` (pick any) list items.
   - Non-blocking at the protocol level: returns immediately with "question filed."
   - `blocking: true` means the agent should end its turn; `false` means it continues with unblocked work.
   - The human's answer arrives as a structured next turn.
@@ -127,7 +127,7 @@ The Go server hosts an MCP server attached to every agent session.
 
 `attachments` share one schema across tools, inbox replies, and reviews: file and line-range references, diff references, images, diagrams (Mermaid source), links to tasks or snapshots, and URLs.
 
-Validation: reject malformed calls with a corrective message (for example, an `ask_human` with no options or no `why_blocked`).
+Validation: reject malformed calls with a corrective message (for example, an `ask_human` with no choices in its context or no `why_blocked`).
 
 **Turn summaries.** There is no report tool. Each turn's final message is its summary: session guidance asks agents to end every turn with one covering what they did, every departure from the plan, risks, and what's next, and byre files it to the inbox as a report. A dedicated report tool was tried and dropped: models wrote the closing recap anyway, even when the tool's result, the system prompt and a per-turn reminder all said not to, so the human read everything twice.
 
@@ -158,10 +158,9 @@ Event           (seq, agent_session_id, task_id, project_id, kind,
 Snapshot        (id, task_id, agent_session_id, n, commit_sha, tree_sha,
                  event_seq, trigger, created_at)
 InboxItem       (id, project_id, task_id, agent_session_id, thread_id, kind,
-                 priority, blocking, payload, snapshot_id, review_id, state,
-                 snoozed_until)
-InboxResponse   (id, inbox_item_id, user_id, type, text, attachments,
-                 created_at)          -- type: option | other | snooze | dismiss
+                 priority, blocking, payload, snapshot_id, review_id, state)
+InboxResponse   (id, inbox_item_id, user_id, type, options, text, attachments,
+                 created_at)          -- type: option | other | dismiss
 Review          (id, task_id, snapshot_id, tree_sha, profile, reviewer_vendor,
                  trigger, state, summary, highlights, attachments, stale)
 ReviewProfile   (id, name, prompt, vendor, model, output_schema, capture_config)
@@ -408,9 +407,8 @@ In increasing order of how much the UI encourages their use:
 
 ### Response types
 
-- **Pick an option**.
+- **Pick choices**: one for a pick-one question, any number for a pick-any one, chosen where they appear in the context.
 - **Other**: the only text field, for an answer outside the options, a question back, or new instructions. If it asks the agent something, the agent answers through a follow-up `ask_human` with the same `thread_id`.
-- **Snooze**: hidden until a set time; the agent stays blocked.
 - Reports are FYI and take only an OK.
 
 Responses can carry attachments (pasted images and sketches, file and line references, links to tasks or snapshots, URLs). When an agent asks several questions at once, they are answered as one form with one submit.