AskUserQuestion: clearer prompt guidance and a free-text input question form

**What & Why** — Qwen3 32B misreads AskUserQuestion as a fill-in-the-blank form: it keeps the question text but turns option 1 into a placeholder — asking "Which folder should I build this app in?" with the single option "Please choose a folder" — leaving the user no real choice and no way to type an answer. The tool's prompt guidance does not distinguish between the different kinds of question a model may need to ask, so smaller local models default to the select shape even when free text is what they actually want. AskUserQuestion should offer an input-type question alongside the select-type one, and its prompt should make the intended usage of each unmistakable. Users on local models then get answerable questions instead of dead-end single-option pickers. --- ## Reproduction evidence (qwen3:32b via Ollama, 2026-08-22) Three runs against a real `unchain` Agent with `CoreToolkit`, capturing raw `tool_call` arguments before validation. **Run 3 — reproduces the reported defect.** Task: 「我要你在我电脑上创建一个项目。动手之前，先问我具体要放在哪个文件夹路径。」 ```json { "title": "项目存放路径", "question": "请选择或输入项目要创建的具体文件夹路径", "selection_mode": "single", "options": [ {"label": "使用默认开发目录（如 ~/projects）", "value": "default_dev_dir"}, {"label": "指定自定义路径", "value": "custom_path"} ], "allow_other": true, "other_label": "输入具体路径", "other_placeholder": "/home/username/your/project/path" } ``` - `custom_path` is not an answer — it is a "let me type" affordance smuggled in as an option. - The model set `allow_other: true` **and** invented the fake option, expressing "I need free text" twice. It does not know `allow_other` alone suffices. - The question text 「请选择**或输入**」 shows the model arguing with the select-only frame in prose. - Selecting `custom_path` returns the bare string `"custom_path"` with no text — a guaranteed dead-end round-trip. - `other_placeholder` is a Linux path on macOS. **Run 1 — clean pass.** Task: 「帮我做一个简单的 todo app」. Two concrete options, no placeholder. The defect is **not** universal; it triggers when the answer space is unbounded (a path, a name). An acceptance test using a bounded question will pass vacuously. **Run 2 — a second, quieter failure.** Task: 「帮我做一个 todo app，放到我电脑上的一个文件夹里」. Explicitly told to place the app in a folder, the model **never asked where**. It substituted a 5-option feature-scope question it could express as a select, and left the blocking decision unasked. This dodge is more damaging than the placeholder because nothing looks wrong in the UI. `allow_other` across the three runs: `false`, omitted, `true`. Even the legal escape hatch is not reliably reached. ## Root cause Prompt hardening is already present and is already failing — the model violated instructions that exist today: - `unchain/src/unchain/input/human_input.py:16` — "Do not use categories, placeholders, or meta options" - `unchain/src/unchain/input/human_input.py:47` — "make each option a concrete answer the user can directly pick" The structural cause is that a free-text question is **unrepresentable**: - `human_input.py:122` — `kind: Literal["selector"]`; there is no other kind. - `human_input.py:141` — `options` must be a non-empty array. A model needing free text has no legal encoding, so it fabricates an option. **The renderer already supports the target shape.** `src/COMPONENTs/chat-bubble/interact/single_select_interact.js:132` (and `multi_select_interact.js:145`) bail only when `options.length === 0 && !allowOther`. Zero options plus `allow_other: true` renders a bare text input with no fake choices, and the Other input is wired at `single_select_interact.js:236-264`. This is a runtime schema restriction, not a missing UI. ## Boundary contract **BC-001 — `ask_user_question` tool arguments → `HumanInputRequest` → renderer interact config** - Producer: provider tool call (model-authored arguments), parsed by `HumanInputRequest.from_tool_arguments` in `unchain/src/unchain/input/human_input.py`. - Consumer: `single_selec