fix(web): keep the plan card to decisions it can actually answer

Review follow-ups on the presentation intent.

The card claimed any single-question request declaring the intent, then sent one
of two labels — so a producer offering a third option, or a multi-select batch,
lost answers the generic flow would have shown. That contradicts the intent's
own contract, so `planReviewOf` now claims only a binary single choice and
leaves everything else to the flow that can express it.

`ask()` also rejects a plan-review intent on a question with no `detail`: the
intent declares detail IS the plan, and without one a honouring UI asks the
user to approve something invisible. The client keeps its own fallback — it sits
downstream of a wire boundary — but the misconfiguration now fails at the asker.

`planReviewOf` stops being a value export of the client contract face (client
export discipline: pure helpers stay internal; the tests already import it
relatively), and the ui-question README fallback list, both languages, now
states every condition the code enforces.

.agents/notes/implemented/feature/2026-07-30-plan-review-presentation-intent.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write .agents/notes/implemented/feature/2026-07-30-plan-review-presentation-intent.md
-2026-07-30-plan-review-presentation-intent.md: aa85156d87a35d049f3cfab465fc668a63781a73
-2026-07-30-plan-review-presentation-intent.zh.md: fffee3de6341d45b26b88e1cc67a3895e747afac
+2026-07-30-plan-review-presentation-intent.md: aeab12aac308c24aa5c4b5953a60ae0f2cf6c5b5
+2026-07-30-plan-review-presentation-intent.zh.md: 4096018e374212c821675ce6ed3a2355df20edc9

.agents/notes/implemented/feature/2026-07-30-plan-review-presentation-intent.md

@@ -16,11 +16,11 @@ A question may declare a **presentation intent**, and the Web composer renders a
 
 An intent shapes presentation only. The answer protocol is untouched: a UI honouring the intent answers with the same option labels a generic UI would send, so `exit_plan_mode` reads one answer shape regardless of which surface collected it, and a UI that does not know a tag renders the generic flow with nothing lost but the layout.
 
-`approve` names the affirmative option instead of relying on option order, so no UI infers a verdict from a position. Because the types cannot tie that label to the question's own option list, `UserInteractionService.ask()` rejects an intent whose `approve` names none of its options (`BAD_INTENT`) — at the asker, before any UI can answer a choice that was never offered. On the wire the intent is a discriminated union, so an unrecognised tag is a rejected frame rather than a silently generic render.
+`approve` names the affirmative option instead of relying on option order, so no UI infers a verdict from a position. Two assertions an intent makes are beyond the types, and `UserInteractionService.ask()` rejects both as `BAD_INTENT` at the asker: an `approve` naming none of that question's own options — before any UI can answer a choice never offered — and an intent on a question with no `detail`, the thing it declares itself a review of, which would ask the user to approve something invisible. On the wire the intent is a discriminated union, so an unrecognised tag is a rejected frame rather than a silently generic render.
 
 `ui-question` renders the intent as `PlanReviewPanel`, in the waiting-approval card language: the amber strip carries `Plan review`, the plan is the scrolling markdown body, and the decision row holds three actions — `Chat about it`, `Refuse`, `Approve`. The question text becomes the card's accessible name rather than a headline, because the buttons already say what the decision is. Approve and Refuse answer with the asker's own option labels and keep the asker's descriptions as tooltips; `Chat about it` cancels the request, which returns the composer so the user can simply say what they want. All copy is bilingual under the existing `question` namespace.
 
-Routing lives inside the single composer entry (`QuestionComposer` chooses the shape) rather than in a second chain registration, and `planReviewOf` claims a request only when the batch is one question that declares the intent, carries the plan as its `detail`, and offers the named approve label. Anything else stays a generic question — the client is downstream of a wire boundary, so a request it cannot render as a card must still be answerable.
+Routing lives inside the single composer entry (`QuestionComposer` chooses the shape) rather than in a second chain registration, and `planReviewOf` claims a request only when the card can send every answer that request allows: one question declaring the intent, the plan as its `detail`, the named approve label offered, and a binary single choice — at most one option besides approve, and not multi-select. A third option or a multi-select batch has answers two buttons cannot express, so the generic flow keeps it, and keeps anything else the card cannot render. "Presentation only" is therefore literal: an intent never costs the user a reachable answer, and the client — downstream of a wire boundary — leaves every request answerable.
 
 Dismissal became its own model-facing outcome. `ASK_CANCELLED` previously reached the model as "the user cancelled ask_user_question", naming a tool it never called; `exit_plan_mode` now reports that the user dismissed the review to speak instead and to stay in plan mode and wait. Every other ask failure — an abort from turn cancel or provider teardown, where no user is coming — keeps its own message.
 
@@ -50,6 +50,6 @@ A deployment whose client half predates this change still shows the quiz layout
 
 ## Testing
 
-`ui-question` tests pin the narrowing (single-question batch, intent present, plan as detail, named approve label offered, decline absent when only approve is offered) and the panel (strip, markdown plan, accessible name, absence of pager/radio/skip/custom, approve and decline answering with the asker's labels, dismissal cancelling, one-shot latch with re-arm and message on a rejected receipt, tooltips present and absent, both locales). `user-interaction` tests pin `BAD_INTENT` and intent pass-through; `plan-mode` tests pin the declared intent against its own option list and both failure messages; the apiproxy schema test pins wire acceptance and an unknown tag's rejection.
+`ui-question` tests pin the narrowing (single-question batch, intent present, plan as detail, named approve label offered, binary single choice, decline absent when only approve is offered) and the panel (strip, markdown plan, accessible name, absence of pager/radio/skip/custom, approve and decline answering with the asker's labels, dismissal cancelling, one-shot latch with re-arm and message on a rejected receipt, tooltips present and absent, both locales). `user-interaction` tests pin both `BAD_INTENT` rejections and intent pass-through; `plan-mode` tests pin the declared intent against its own option list and both failure messages; the apiproxy schema test pins wire acceptance and an unknown tag's rejection.
 
 The `plan-review` Web e2e lane records `/plan` entering plan mode for real, the model calling `exit_plan_mode`, the decision card taking the composer (asserting the generic flow did **not** claim the request), and the card's own Approve completing the turn — two keyless goldens, the waiting card and the approved transcript.

.agents/notes/implemented/feature/2026-07-30-plan-review-presentation-intent.zh.md

@@ -16,11 +16,11 @@ Status: implemented
 
 意图只塑造呈现。回答协议不变：遵循意图的 UI 回答的仍是通用 UI 会发送的那些选项标签，因此无论由哪个界面收集，`exit_plan_mode` 读到的都是同一种回答形状；而不认识某个标签的 UI 渲染通用流程，除布局之外一无所失。
 
-`approve` 指名肯定选项，而不依赖选项顺序，因此没有任何 UI 会从位置推断裁决。由于类型无法把该标签绑定到问题自身的选项列表，`UserInteractionService.ask()` 会拒绝 `approve` 未命中任一选项的意图（`BAD_INTENT`）—— 拦在提问方一侧，早于任何 UI 回答一个从未被提供过的选择。在协议格式（wire format）上意图是可辨识联合，因此无法识别的标签是被拒绝的帧，而不是静默退回通用渲染。
+`approve` 指名肯定选项，而不依赖选项顺序，因此没有任何 UI 会从位置推断裁决。意图作出的两项断言超出类型的表达能力，`UserInteractionService.ask()` 都以 `BAD_INTENT` 在提问方一侧拒绝：`approve` 未命中该问题自身的任一选项 —— 早于任何 UI 回答一个从未被提供过的选择；以及意图落在没有 `detail` 的问题上，而 `detail` 正是它自称在审阅的东西，那会让用户去批准一件看不见的事。在协议格式（wire format）上意图是可辨识联合，因此无法识别的标签是被拒绝的帧，而不是静默退回通用渲染。
 
 `ui-question` 把该意图渲染为 `PlanReviewPanel`，沿用等待审批卡片的语言：琥珀色条带写着 `Plan review`，计划是可滚动的 markdown 主体，决定行放三个操作 —— `Chat about it`、`Refuse`、`Approve`。问题文本成为卡片的无障碍名称而非标题，因为按钮已经说明了这次决定是什么。Approve 与 Refuse 用提问方自己的选项标签回答，并把提问方的描述保留为 tooltip；`Chat about it` 取消该请求，从而让输入区归位，用户直接说他想说的话即可。所有文案在既有 `question` 命名空间下双语。
 
-路由住在单一输入区条目内部（由 `QuestionComposer` 选择形状），而不是第二个链式注册；`planReviewOf` 仅在这一批只有一个问题、该问题声明了意图、以 `detail` 承载计划、并提供了被指名的批准标签时才接管请求。其他情形一律保持通用问题 —— 客户端位于协议边界的下游，它无法渲染成卡片的请求仍必须可回答。
+路由住在单一输入区条目内部（由 `QuestionComposer` 选择形状），而不是第二个链式注册；`planReviewOf` 仅在卡片能够发出该请求允许的每一个答案时才接管：只有一个问题且声明了意图、以 `detail` 承载计划、提供了被指名的批准标签，且是二元单选 —— 除批准外最多一个选项，且非多选。出现第三个选项或多选批次时，其答案是两个按钮无法表达的，通用流程保留它，也保留其他任何卡片渲染不了的请求。因此"只塑造呈现"是字面意义上的：意图绝不让用户失去一个可达的答案，而位于协议边界下游的客户端让每个请求都保持可回答。
 
 放弃审阅成为面向模型的独立结果。`ASK_CANCELLED` 以前传到模型的是"the user cancelled ask_user_question"，指名了一个它从未调用的工具；现在 `exit_plan_mode` 报告用户放弃审阅是为了改用说话，并要求留在 plan mode 中等待。其余每一种 ask 失败 —— 轮次取消或提供方拆卸导致的中止，那里并没有用户会来 —— 保留它们自己的消息。
 
@@ -50,6 +50,6 @@ Status: implemented
 
 ## 测试
 
-`ui-question` 测试钉住收窄（单问题批、意图存在、计划作为 detail、被指名的批准标签确实被提供、只提供批准时 decline 缺席）与面板（条带、markdown 计划、无障碍名称、无分页/单选/跳过/自定义、批准与拒绝用提问方的标签回答、放弃触发取消、一次性闭锁在回执被拒时重新武装并给出消息、tooltip 有与无、两种语言）。`user-interaction` 测试钉住 `BAD_INTENT` 与意图透传；`plan-mode` 测试钉住已声明的意图与其自身选项列表的一致、以及两条失败消息；apiproxy schema 测试钉住协议接受与未知标签的拒绝。
+`ui-question` 测试钉住收窄（单问题批、意图存在、计划作为 detail、被指名的批准标签确实被提供、二元单选、只提供批准时 decline 缺席）与面板（条带、markdown 计划、无障碍名称、无分页/单选/跳过/自定义、批准与拒绝用提问方的标签回答、放弃触发取消、一次性闭锁在回执被拒时重新武装并给出消息、tooltip 有与无、两种语言）。`user-interaction` 测试钉住两种 `BAD_INTENT` 拒绝与意图透传；`plan-mode` 测试钉住已声明的意图与其自身选项列表的一致、以及两条失败消息；apiproxy schema 测试钉住协议接受与未知标签的拒绝。
 
 `plan-review` Web e2e 通道录制了 `/plan` 真实进入 plan mode、模型调用 `exit_plan_mode`、决定卡片接管输入区（并断言通用流程**没有**接管该请求）、以及卡片自身的 Approve 完成该轮 —— 两份无密钥 golden：等待中的卡片与批准后的会话记录。

docs/core-data-structures/user-interaction.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write docs/core-data-structures/user-interaction.md
-user-interaction.md: 4ebaf66131b3ab7a7c205bef1ba533e9321d4f0b
-user-interaction.zh.md: 8e5542b995bbf061b097d650ab79505e93151fa8
+user-interaction.md: 2483382eee07d379b13d456149096c8afab70e4b
+user-interaction.zh.md: 57f57277975597fff712705cc741ae8e78643642

docs/core-data-structures/user-interaction.md

@@ -22,7 +22,7 @@ interface AskUserQuestionOption {
 
 ## Presentation intent
 
-`AskUserQuestionIntent` is the optional declaration that a question IS a decision of a known shape. It is tagged on `kind` so intents can be added; a UI that does not recognise a tag renders the generic option list. An intent shapes presentation only — a UI honouring it answers with the same option labels a generic UI would send, so the caller reads one answer shape either way. `approve` names the affirmative option instead of relying on option order, and `ask()` rejects an `approve` naming none of its own question's options.
+`AskUserQuestionIntent` is the optional declaration that a question IS a decision of a known shape. It is tagged on `kind` so intents can be added; a UI that does not recognise a tag renders the generic option list. An intent shapes presentation only — a UI honouring it answers with the same option labels a generic UI would send, so the caller reads one answer shape either way. `approve` names the affirmative option instead of relying on option order. `ask()` rejects the two assertions no type can carry: an `approve` naming none of its own question's options, and an intent on a question with no `detail`.
 
 ```ts type-equiv
 /**
@@ -33,7 +33,7 @@ interface AskUserQuestionOption {
  * either way — an intent shapes presentation only, never the protocol.
  */
 type AskUserQuestionIntent = {
-  /** A plan submitted for review: `detail` is the plan markdown, and the decision approves or declines it. */
+  /** A plan submitted for review: `detail` is the plan markdown `ask()` requires, and the decision approves or declines it. */
   kind: 'plan-review'
   /**
    * The option label that approves the plan; every other option declines it.

docs/core-data-structures/user-interaction.zh.md

@@ -22,7 +22,7 @@ interface AskUserQuestionOption {
 
 ## 呈现意图
 
-`AskUserQuestionIntent` 是一项可选声明：某个问题本身就是一次已知形状的决定。它按 `kind` 打标签，因此意图可以扩充；不认识某个标签的 UI 渲染通用选项列表。意图只塑造呈现 —— 遵循它的 UI 回答的仍是通用 UI 会发送的那些 option label，因此调用方两种情况下读到的都是同一种回答形态。`approve` 指名肯定选项，而不依赖选项顺序；`ask()` 会拒绝未命中该问题自身任一选项的 `approve`。
+`AskUserQuestionIntent` 是一项可选声明：某个问题本身就是一次已知形状的决定。它按 `kind` 打标签，因此意图可以扩充；不认识某个标签的 UI 渲染通用选项列表。意图只塑造呈现 —— 遵循它的 UI 回答的仍是通用 UI 会发送的那些 option label，因此调用方两种情况下读到的都是同一种回答形态。`approve` 指名肯定选项，而不依赖选项顺序。有两项断言是任何类型都承载不了的，`ask()` 会拒绝它们：`approve` 未命中该问题自身的任一选项，以及意图落在没有 `detail` 的问题上。
 
 ```ts type-equiv
 /**
@@ -33,7 +33,7 @@ interface AskUserQuestionOption {
  * either way — an intent shapes presentation only, never the protocol.
  */
 type AskUserQuestionIntent = {
-  /** A plan submitted for review: `detail` is the plan markdown, and the decision approves or declines it. */
+  /** A plan submitted for review: `detail` is the plan markdown `ask()` requires, and the decision approves or declines it. */
   kind: 'plan-review'
   /**
    * The option label that approves the plan; every other option declines it.

packages/client/ui-question/README.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write packages/client/ui-question/README.md
-README.md: 6b40c503be61c2458cefceabbb35e16a3befbe66
-README.zh.md: 7c0c4ee67d1ef8b4507f3899bdb1ae2f76408032
+README.md: 5ebba2a1da6e6108b82e9deb235b84f987600345
+README.zh.md: 0aa6428a9b6472fc5b525c11b4716ebc50c378c3

packages/client/ui-question/README.md

@@ -6,7 +6,7 @@ Web `ask_user_question` feature plugin. Its host half mounts `dsh-tool-ask-user`
 
 The component renders one question at a time with progress navigation, single- and multi-select choices, recommendation badges derived from label suffixes, and custom answers. Question detail reuses the assistant-output `MarkdownText` primitive, including its GFM rendering and untrusted-content policy. The capped card keeps its title, navigation, and submission actions fixed while long detail and choices share an internal scroll region. Single-select choices advance immediately, and Enter submits once every question is answered or skipped; Enter during IME composition confirms the input candidate without advancing. It submits one structured answer batch for the whole request: “Skip this question” retains other drafts and emits the existing blank `{ selected: [] }` shape for that item, while close rejects the whole wait as `ASK_CANCELLED`.
 
-A request whose single question declares a presentation intent renders as that intent's own surface instead. `plan-review` — set by `dsh-plan-mode` on the `exit_plan_mode` review — takes the waiting-approval card shape: a `Plan review` strip, the plan as the scrolling markdown body, the question text as the card's accessible name, and one decision row of `Chat about it` / `Refuse` / `Approve`. Approve and Refuse answer with the asker's own option labels (the intent names which label approves, so the verdict never rides option order) and keep the asker's descriptions as tooltips; `Chat about it` rejects the wait as `ASK_CANCELLED`, returning the composer so the user can say what they want instead. A request that declares no intent, batches more than one question, or fails to offer the named approve label stays on the generic flow — the layout is all an intent changes, never the answer.
+A request whose single question declares a presentation intent renders as that intent's own surface instead. `plan-review` — set by `dsh-plan-mode` on the `exit_plan_mode` review — takes the waiting-approval card shape: a `Plan review` strip, the plan as the scrolling markdown body, the question text as the card's accessible name, and one decision row of `Chat about it` / `Refuse` / `Approve`. Approve and Refuse answer with the asker's own option labels (the intent names which label approves, so the verdict never rides option order) and keep the asker's descriptions as tooltips; `Chat about it` rejects the wait as `ASK_CANCELLED`, returning the composer so the user can say what they want instead. The card claims a request only when it can send every answer that request allows: one question, the intent declared, the plan present as `detail`, the named approve label offered, and a binary single choice (at most one option besides approve, not multi-select). Anything else — no intent, a batch of several questions, a missing plan, an approve label naming no option, a third option, a multi-select decision — stays on the generic flow, which can express it. An intent changes the layout, never which answers are reachable.
 
 Selection state is local to a component keyed by the request rpcId. A replay with the same id preserves a still-mounted draft, while `question/resolved` from the host removes the composer. The host remains authoritative: successful HTTP delivery does not remove pending state locally.
 

packages/client/ui-question/README.zh.md

@@ -6,7 +6,7 @@ Web `ask_user_question` 功能插件。只有选择 Web 功能时，其主机侧
 
 组件每次渲染一个问题，提供进度导航、单选和多选选项、由标签后缀派生的推荐徽标，以及自定义答案。问题详情复用助手输出的 `MarkdownText` 原语，包括其 GFM 渲染与不受信内容策略。封顶卡片保持标题、导航与提交动作固定，超长的详情与选项共享内部滚动区。单选选项会立即前进；所有问题均已回答或跳过后，Enter 会提交；IME 输入法组合期间按 Enter 只会确认输入候选，不会前进。组件为整个请求提交一批结构化答案：「跳过此问题」会保留其他草稿，并为该项发出既有的空 `{ selected: [] }` 形状；关闭则以 `ASK_CANCELLED` 拒绝整个等待。
 
-若某个请求的唯一问题声明了呈现意图，则改为渲染该意图自己的界面。`plan-review` —— 由 `dsh-plan-mode` 在 `exit_plan_mode` 审阅上设置 —— 采用等待审批卡片的形状：一条 `Plan review` 条带、计划作为可滚动的 markdown 主体、问题文本作为卡片的无障碍名称，以及一行 `Chat about it` / `Refuse` / `Approve` 的决定操作。Approve 与 Refuse 用提问方自己的选项标签回答（意图指名哪个标签表示批准，因此裁决绝不依赖选项顺序），并把提问方的描述保留为 tooltip；`Chat about it` 以 `ASK_CANCELLED` 拒绝该等待，让编辑器归位，用户可以直接说出他想说的话。未声明意图、一批含多个问题、或未提供被指名的批准标签的请求，一律留在通用流程上 —— 意图改变的只是布局，从不改变答案。
+若某个请求的唯一问题声明了呈现意图，则改为渲染该意图自己的界面。`plan-review` —— 由 `dsh-plan-mode` 在 `exit_plan_mode` 审阅上设置 —— 采用等待审批卡片的形状：一条 `Plan review` 条带、计划作为可滚动的 markdown 主体、问题文本作为卡片的无障碍名称，以及一行 `Chat about it` / `Refuse` / `Approve` 的决定操作。Approve 与 Refuse 用提问方自己的选项标签回答（意图指名哪个标签表示批准，因此裁决绝不依赖选项顺序），并把提问方的描述保留为 tooltip；`Chat about it` 以 `ASK_CANCELLED` 拒绝该等待，让编辑器归位，用户可以直接说出他想说的话。卡片只在能够发出该请求允许的每一个答案时才接管：只有一个问题、声明了意图、计划以 `detail` 存在、提供了被指名的批准标签，且是二元单选（除批准外最多一个选项，且非多选）。其他任何情形 —— 没有意图、一批含多个问题、缺少计划、批准标签未命中任何选项、出现第三个选项、多选决定 —— 都留在能够表达它的通用流程上。意图改变的只是布局，从不改变可达的答案。
 
 选择状态只存在于以请求 rpcId 为 key 的组件本地。使用相同 id 回放时，只要组件仍挂载，就会保留草稿；主机发出的 `question/resolved` 则会移除编辑器。主机仍具有最终决定权：HTTP 交付成功不会在本地移除待处理状态。
 

packages/client/ui-question/src/client/contract/slots.ts

@@ -49,12 +49,16 @@ export interface PlanReview {
  * Narrow a request to a renderable plan review, or return undefined to leave it
  * to the generic question flow.
  *
- * The card is one decision over one plan, so it claims a request only when the
- * batch is a single question that declares the intent, carries the plan as its
- * detail, and offers the approve label the intent names. The asker's own
- * service validates that label, but this is a wire boundary: a request failing
- * any part of it still renders and stays answerable as a generic question
- * rather than reaching a card that cannot express it.
+ * The card is one decision over one plan, and it claims a request only when it
+ * can send every answer that request allows — an intent changes the layout,
+ * never which answers are reachable. So the batch must be a single question
+ * that declares the intent, carries the plan as its detail, offers the approve
+ * label the intent names, and is a binary single choice: at most one option
+ * besides approve, and not multi-select. A third option or a multi-select batch
+ * has answers two buttons cannot express, so the generic flow keeps it — as it
+ * keeps any request whose intent the asker's own service would have rejected,
+ * because the client sits downstream of a wire boundary and every request must
+ * stay answerable.
  *
  * @param questions - the request's whole question batch.
  * @returns The narrowed review, or undefined when the generic flow owns it.
@@ -65,7 +69,9 @@ export function planReviewOf(questions: readonly QuestionItem[]): PlanReview | u
   const question = questions[0] as QuestionItem
   const intent = question.intent
   if (intent?.kind !== 'plan-review' || question.detail === undefined) return undefined
+  if (question.multiSelect === true) return undefined
   const options = question.options ?? []
+  if (options.length > 2) return undefined
   const approve = options.find(option => option.label === intent.approve)
   if (approve === undefined) return undefined
   const decline = options.find(option => option.label !== intent.approve)

packages/client/ui-question/src/client/index.ts

@@ -20,7 +20,7 @@ import type { QuestionWait } from './contract/slots.ts'
 import { QuestionComposer } from './QuestionComposer.tsx'
 import { en, zh, type QuestionKey } from './locales.ts'
 
-export { PendingQuestion, planReviewOf } from './contract/slots.ts'
+export { PendingQuestion } from './contract/slots.ts'
 export type {
   PlanReview, QuestionAnswer, QuestionComposerProps, QuestionWait,
 } from './contract/slots.ts'

packages/client/ui-question/tests/plan-review-panel.spec.tsx

@@ -95,6 +95,13 @@ describe('planReviewOf', () => {
       ...questions()[0] as object, intent: { kind: 'plan-review', approve: 'Ship it' },
     }]],
     ['an intent with no options at all', () => [{ ...questions()[0] as object, options: undefined }]],
+    // Two buttons cannot send a third label or a combination, and the generic
+    // flow can: an intent never costs the user a reachable answer.
+    ['a third option the card could not offer', () => [{
+      ...questions()[0] as object,
+      options: [{ label: 'Approve' }, { label: 'Keep planning' }, { label: 'Start over' }],
+    }]],
+    ['a multi-select decision', () => [{ ...questions()[0] as object, multiSelect: true }]],
   ])('declines %s, leaving the request to the generic flow', (_case, build) => {
     expect(planReviewOf(build() as never)).toBeUndefined()
   })

packages/ui/user-interaction/README.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write packages/ui/user-interaction/README.md
-README.md: f134e912149190efb81ea9f64c5d63632ce8c626
-README.zh.md: ab6432dcbddc36d3ef9ca957b3901cb76257539a
+README.md: d62e75d110b8be339c5f9449b0834320f695ac99
+README.zh.md: 55258e85e56df2375ed8f195fa0b3b731a9cb816

packages/ui/user-interaction/README.md

@@ -24,7 +24,7 @@ When an answer includes `custom`, `selected` is empty; custom text is an overrid
 
 ### Presentation intent
 
-`intent` declares that a question IS a decision of a known shape, so a UI that recognises the tag may present it as such — `plan-review` says `detail` is a plan under review, and `dsh-plan-mode` sets it on the `exit_plan_mode` question. An intent shapes presentation only: a UI honouring it answers with the same option labels a generic UI would send, and a UI that does not know the tag renders the generic option list, so callers read one answer shape either way. `approve` names the label that approves rather than relying on option order; `ask()` rejects an intent whose `approve` names none of that question's own options with `BAD_INTENT`, since no type can tie the two together.
+`intent` declares that a question IS a decision of a known shape, so a UI that recognises the tag may present it as such — `plan-review` says `detail` is a plan under review, and `dsh-plan-mode` sets it on the `exit_plan_mode` question. An intent shapes presentation only: a UI honouring it answers with the same option labels a generic UI would send, and a UI that does not know the tag renders the generic option list, so callers read one answer shape either way. `approve` names the label that approves rather than relying on option order. `ask()` rejects with `BAD_INTENT` the two assertions no type can carry: an `approve` naming none of that question's own options, and an intent on a question with no `detail` — the thing it declares itself a review of.
 
 ## Role
 

packages/ui/user-interaction/README.zh.md

@@ -24,7 +24,7 @@
 
 ### 呈现意图
 
-`intent` 声明某个问题本身就是一次已知形状的决定，因此认识该标签的 UI 可以照此呈现 —— `plan-review` 表示 `detail` 是一份待审阅的计划，`dsh-plan-mode` 会在 `exit_plan_mode` 的问题上设置它。意图只塑造呈现：遵循它的 UI 回答的仍是通用 UI 会发送的那些选项标签，不认识该标签的 UI 渲染通用选项列表，因此调用方两种情况下读到的都是同一种回答形态。`approve` 指名表示批准的标签，而不依赖选项顺序；由于没有类型能把两者绑定起来，`ask()` 会以 `BAD_INTENT` 拒绝 `approve` 未命中该问题自身任一选项的意图。
+`intent` 声明某个问题本身就是一次已知形状的决定，因此认识该标签的 UI 可以照此呈现 —— `plan-review` 表示 `detail` 是一份待审阅的计划，`dsh-plan-mode` 会在 `exit_plan_mode` 的问题上设置它。意图只塑造呈现：遵循它的 UI 回答的仍是通用 UI 会发送的那些选项标签，不认识该标签的 UI 渲染通用选项列表，因此调用方两种情况下读到的都是同一种回答形态。`approve` 指名表示批准的标签，而不依赖选项顺序。有两项断言是任何类型都承载不了的，`ask()` 会以 `BAD_INTENT` 拒绝它们：`approve` 未命中该问题自身的任一选项，以及意图落在没有 `detail` 的问题上 —— 而 `detail` 正是它自称在审阅的东西。
 
 ## 职责
 

packages/ui/user-interaction/src/index.ts

@@ -87,10 +87,13 @@ export class UserInteractionService extends Service {
     if (request.questions.length === 0) {
       throw new UserInteractionError('ask_user_question requires at least one question', 'EMPTY_QUESTIONS')
     }
-    // A presentation intent names an option label the types cannot pin to its
-    // own question's option list. A UI honouring the intent answers with that
-    // label, so a name matching nothing would answer a choice the asker never
-    // offered — caught here, at the asker, rather than in a UI.
+    // A presentation intent asserts two things the types cannot: that the
+    // named approve label is one of this question's own options, and that a
+    // plan-review carries the plan it is a review of. A UI honouring the
+    // intent answers with that label, and shows that detail as the plan, so
+    // either gap would put a choice the asker never offered — or an approval of
+    // something invisible — in front of the user. Caught at the asker, where
+    // the mistake is, rather than in each UI.
     for (const question of request.questions) {
       const intent = question.intent
       if (intent === undefined) continue
@@ -100,6 +103,11 @@ export class UserInteractionService extends Service {
           + `${JSON.stringify(intent.approve)} names none of its options`,
           'BAD_INTENT')
       }
+      if (question.detail === undefined) {
+        throw new UserInteractionError(
+          `question ${question.id} declares intent ${intent.kind} without the detail it reviews`,
+          'BAD_INTENT')
+      }
     }
     if (this.provider === undefined) {
       throw new UserInteractionError('no user-interaction provider is registered', 'NO_PROVIDER')

packages/ui/user-interaction/src/types.ts

@@ -21,7 +21,7 @@ export interface AskUserQuestionOption {
  * either way — an intent shapes presentation only, never the protocol.
  */
 export type AskUserQuestionIntent = {
-  /** A plan submitted for review: `detail` is the plan markdown, and the decision approves or declines it. */
+  /** A plan submitted for review: `detail` is the plan markdown `ask()` requires, and the decision approves or declines it. */
   kind: 'plan-review'
   /**
    * The option label that approves the plan; every other option declines it.

packages/ui/user-interaction/tests/user-interaction.spec.ts

@@ -104,6 +104,24 @@ describe('UserInteractionService', () => {
     expect(p.ask).not.toHaveBeenCalled()
   })
 
+  it('rejects a plan-review intent on a question carrying no plan to review', async () => {
+    const ctx = new Context()
+    await ctx.plugin(UserInteractionService)
+    const p = { ask: vi.fn(async () => ({ answers: [] })) }
+    ctx.userInteraction.registerProvider(p)
+
+    // Detail IS the plan for this intent, so a UI honouring it would ask the
+    // user to approve something they cannot see.
+    await expect(ctx.userInteraction.ask({
+      questions: [{
+        id: 'plan-review', question: 'Approve?',
+        options: [{ label: 'Approve' }, { label: 'Keep planning' }],
+        intent: { kind: 'plan-review', approve: 'Approve' },
+      }],
+    })).rejects.toMatchObject({ name: 'UserInteractionError', code: 'BAD_INTENT' })
+    expect(p.ask).not.toHaveBeenCalled()
+  })
+
   it('passes an intent through once its approve label names an offered option', async () => {
     const ctx = new Context()
     await ctx.plugin(UserInteractionService)