[gabynevada]

Problem

An MCP form elicitation is shown one field per page. Skald's plan.answer form sends an optional single-select and an optional free-text field, so the owner saw "1/2" and "2/2" and read the text field as a second, separate question. Skald is changing its side (ATLI-2472) so that one submission can carry an option, an option with a note, or only text, and the client must therefore send both values together.

Change

• A single-select string field directly followed by an optional plain text field (no enum, oneOf, format or default) is now one step. The choice question carries the text field as an optional companionText in OrchestrationV2UserInputQuestion and the provider-runtime UserInputQuestion. Without it, behaviour is unchanged.
• Web: the options show as today, and the composer answers the companion field with its title as the placeholder, for example "Your own answer (optional)". The pair counts as one step.
• Mobile: the paired question shows the companion's description and a text input.
• Both values are submitted under their own keys: the option when one is picked, the text when it is non-blank. The text field's constraints (such as maxLength) are still enforced, now through a shared userInputAnswersError that the orchestrator calls.
• ACP parseElicitationForm skips the paired text field as a separate question but still types and sends its answer. The t3_pending_request tool schema exposes companionText.
• The rule is purely structural, with no field names or server conventions. Every other form shape keeps one question per field.

Scope and approval

This is a client-side rendering fix for a confusion the owner reported. Three independent UX reviews (rendering across clients, form and accessibility design, and an argued alternative) agreed that showing a form's fields together is the spec-faithful fix. The MCP spec leaves layout to the client.

Verification

• mcpElicitationForm: 11/11, including pairing, content mapping (option only, option and text, text only, neither) and non-pair shapes (required text, a text field not adjacent, multi-select).
• provider-acp elicitationForm: 7/7.
• client-runtime pendingUserInput: 13/13.
• shared userInputConstraints: 5/5.
• web pendingUserInput: 11/11.
• Server adapter suites (Codex, ACP, Claude, AcpRegistry, CodexMcpElicitation): 644/644.
• ClaudeMcpElicitation.integration: 8/8.
• RuntimeRequestService and ThreadMessageIntake: 14/14.
• effect-tsgo tsrs --noEmit shows no errors in contracts, shared, client-runtime, provider-core, provider-acp, server, web and mobile.
• vp fmt --check and vp lint pass on the changed files.

Not checked: the ComposerPendingUserInputPanel browser tests, and the UI itself. I have no before/after screenshots yet.

Known limits:

• A paired step takes no attachments.
• In answer history the note shows as its own block with no heading.
• AcpAdapterV2.test.ts had a "generic MCP form" fixture with a required choice followed by an optional note. It now pairs by design, so I updated the expectation.

🤖 Generated with Claude Code (Claude Opus 5.5)