widget-forms

# Widget Forms

Use the form tool instead of hand-writing markup: the editor chat renders the
form as an interactive card and returns the user's structured answer.

## Runtime Rule

Call `ask_followup_questions`. It serializes your fields into the editor's
native form card; the user's submission comes back as their next message.

Plan the whole questionnaire before calling the tool. Send one final form, not a
trial form followed by a corrected form. The tool supports at most 12 fields; if
the user asks for more questions, merge related prompts into combined fields
before the first call.

After calling `ask_followup_questions`, stop the turn and wait for the submitted
answer to appear in chat. Do not apply a choice, create assets, or continue
planning from a recommendation until the user's selection is present in the
conversation.

## Supported Field Mapping

Build a `fields` array. Write every visible string in the user's conversation
language.

- Native `<form-single>` -> `{ type: "single", variant: "default" }`
- Native `<form-multi>` -> `{ type: "multi", variant: "default" }`
- Native `<form-text>` / `<form-textarea>` -> `{ type: "text" }`
- Native `<form-visual>` -> `{ type: "single", variant: "visual" }`
- Voice audition cards -> `{ type: "single", variant: "voice" }`
- Native start-scenario cards -> `{ type: "single", variant: "scenario" }`

## Form Copy Tone

For form-level text (`title`, `prompt`, `fields[].label`, `submitLabel`, and
`messagePrefix`), write like OpenChatCut is a capable video-making partner inviting
the user to describe what they want, not like a rigid survey.

Aim for:

- Warm, open-ended, and action-oriented. The copy should imply "choose the
  closest video need or just tell me your idea; we can figure it out together."
- Short and scannable. Use one natural sentence for `prompt` and concise
  question labels.
- Honest capability framing. OpenChatCut can help with many video workflows, but do
  not claim unsupported abilities or guarantee a result before inputs are known.
- The user's language and local product terms. Keep "OpenChatCut", "B-roll",
  "Motion Graphics", "MG 动画", model/product names, and platform names in their
  established forms.
- User-facing creative wording. For early planning or creative-intake forms,
  prefer natural terms such as idea, direction, plan, story, shot list, audience,
  mood, or video need over internal production-document language.

Avoid stiff labels such as "Select video type", "Please choose the video type
for this project", or "What type of video do you want to make?" for scenario
intake unless the host has no room for warmer copy.

For a scenario-intake form, prefer copy like:

```json
{
  "title": "What do you want to make?",
  "prompt": "Choose the closest video scenario, or choose Something else and describe your idea.",
  "submitLabel": "Start creating",
  "messagePrefix": "I want to start with this video direction:",
  "fields": [
    {
      "id": "scenario",
      "label": "Which scenario fits your video best?",
      "type": "single",
      "variant": "scenario",
      "otherPlaceholder": "For example: turn my travel footage into an atmospheric vlog / make a launch video for a new product"
    }
  ]
}
```

Do not include file-upload questions in forms. If a task actually needs
source media and the project/chat does not already have it, ask the user
separately to upload files in the editor (drag & drop or the upload button, or
paste into the chat composer). File upload is not a default prerequisite for every
questionnaire; only ask for it when the next editing step depends on missing
media.

For choice fields:

- Use `id` for the internal value the next tool call needs.
- Use `label` for what the user sees.
- For ordinary single-select and multi-select cards (`variant: "default"`), keep
  options label-only. Do not add per-option `description` unless the user cannot
  distinguish the choices from labels alone.
- Use `description` mainly for voice cards. Visual style cards should usually
  use only `preview` + `label`.
- When an off-list answer is acceptable, add an explicit option with
  `id: "__other__"` and a `label` in the same language as the rest of the form,
  using the word the user would expect for an off-list answer. The widget will
  turn this option into a text entry when selected. Use `otherPlaceholder` if
  the text entry needs a placeholder.

For visual cards:

- Use real image URLs or data image URLs in `preview`.
- For Design Style catalog choices, call `manage_design_style` with
  `action: "list"` first, then map each returned preset to
  `{ id: preset.presetId, label: preset.name }` (no thumbnails in this build).
- Never hardcode catalog preset ids unless the user already selected one.

For voice cards:

- Use `audioUrl` for the sample file.
- Prefer the documented sample path such as `/voice-samples/doubao-liuchang.mp3`
  or a public HTTPS URL. Do not pass localhost sample URLs; MCP host iframes do
  not reliably resolve editor-local media.
- Keep user-visible descriptions provider-neutral. Describe the voice the same
  way the native OpenChatCut audition UI does: gender / age range / tone / use case,
  such as `Female / young / friendly, general` or `男 / 中年 / 低沉知识解说`.
  Do not show provider names like ElevenLabs or Doubao in option descriptions.
- Keep the option `id` equal to the provider voice id needed by `submit_voice`.

For native start-scenario cards:

- Use this when the user should choose which OpenChatCut video workflow to start,
  such as talking-head editing, MG animation, long-video-to-shorts,
  product/app promo, AI short film, or explainer video.
- Present these as common video needs/scenarios, not as the only possible video
  workflows. The form must also let the user describe a different video need.
- Use exactly one single-select field with `variant: "scenario"`.
- Provide options using the canonical ids below and localized labels in the
  user's language. Include `id: "__othe