···11+## Context
22+33+The public runner already has a partial keyboard model in `components/public-form-runner.tsx`: a window-level `Enter` handler advances the current step, `Escape` moves back when back navigation is enabled, and typed-answer fields call the same advance helper on `Enter`. Choice options are rendered as buttons with their own `onKeyDown` behavior, so a focused choice button can still treat `Enter` as an activation event instead of a pure advance command. The runner also does not currently autofocus the primary input when a new text-like question becomes active, and choice questions do not visibly advertise any keyboard shortcuts.
44+55+This change is limited to the respondent-facing public runner. It should not alter form data, branching semantics, creator-facing editing, or submission APIs. The builder already limits choice questions to at most 10 options, which makes a numeric shortcut model feasible without adding pagination or multi-key sequences.
66+77+## Goals / Non-Goals
88+99+**Goals:**
1010+- Let respondents answer choice-based questions quickly with number keys in display order.
1111+- Make keyboard shortcuts visible so the feature is discoverable.
1212+- Focus the primary input automatically for typed-answer questions when a new step becomes active.
1313+- Make `Enter` mean “continue/submit this step” without also toggling a focused choice option.
1414+- Preserve existing validation, branching, pointer interactions, and back-navigation behavior.
1515+1616+**Non-Goals:**
1717+- Redesign the visual layout of the public runner.
1818+- Add new block types or creator-facing settings for keyboard behavior.
1919+- Change submission payloads, persistence format, or server-side APIs.
2020+- Introduce complex shortcut schemes beyond the current visible step, such as arrow-key roving focus across the whole form.
2121+2222+## Decisions
2323+2424+### 1. Add a runner-scoped numeric shortcut layer for choice-style questions
2525+For `SINGLE_CHOICE`, `MULTIPLE_CHOICE`, and `AGREEMENT` steps, the runner should listen for unmodified digit key presses when the respondent is not typing in an input-like control. The shortcut mapping should follow visible option order: `1` through `9`, with `0` mapped to the tenth visible option when present. Single-choice and agreement shortcuts replace the current answer; multiple-choice shortcuts toggle the targeted option in place.
2626+2727+**Why this approach:**
2828+- Matches the user's requested `123456...` flow.
2929+- Fits the builder's existing 10-option cap.
3030+- Keeps keyboard selection aligned with what the respondent currently sees on screen.
3131+3232+**Alternatives considered:**
3333+- Letter shortcuts derived from option text: rejected because labels can repeat, localize differently, or begin with non-Latin characters.
3434+- Arrow-key navigation only: rejected because it is slower for direct selection and does not match the requested behavior.
3535+3636+### 2. Show shortcut affordances directly on option rows
3737+Choice-style options should render a small numeric badge or similar inline affordance for their shortcut key, plus lightweight helper copy near the question that tells respondents they can use number keys. Agreement blocks should use the same pattern for consistency even when there is only one actionable option. These shortcut badges and hints should remain visible on mobile layouts as well, not only at tablet/desktop breakpoints.
3838+3939+**Why this approach:**
4040+- Makes the feature discoverable instead of hidden.
4141+- Avoids requiring respondents to guess whether shortcuts exist.
4242+- Keeps the hint localized and reusable across question types.
4343+- Preserves the same discoverability on touch devices, where respondents may still use external keyboards or benefit from understanding the numbered mapping.
4444+4545+**Alternatives considered:**
4646+- No visible hint: rejected because hidden shortcuts have low product value.
4747+- A one-time global keyboard tutorial: rejected because respondents may enter mid-flow or ignore dismissible help.
4848+4949+### 3. Centralize `Enter` as an advance action and suppress native choice-button activation
5050+The runner should treat plain `Enter` as a continue/submit command for the active step when validation passes. To avoid the current bug on choice steps, focused option buttons must not interpret `Enter` as a toggle/select action. Pointer clicks remain unchanged, and keyboard selection for choice questions moves to digit shortcuts. If the product still needs a direct keyboard activation on focused choice buttons, that should use a non-conflicting key such as Space rather than Enter.
5151+5252+**Why this approach:**
5353+- Directly fixes the reported bug where `Enter` both changes a choice and advances.
5454+- Preserves a simple mental model: `Enter` advances, digits answer.
5555+- Avoids split behavior where Enter means different things depending on which option currently has focus.
5656+5757+**Alternatives considered:**
5858+- Keep Enter toggling focused options and remove global advance: rejected because it slows down step progression and conflicts with the user's request.
5959+- Blur focused buttons before continuing: rejected because it is brittle and still relies on native button activation timing.
6060+6161+### 4. Autofocus the primary typed input on active step changes
6262+For short text, long text, number, link, and date questions, the runner should keep a ref to the primary input control and focus it when that block becomes the active step after mount, route advance, or route restoration. Focus should run only after the active step is rendered and should avoid stealing focus during submission or completion.
6363+6464+**Why this approach:**
6565+- Reduces friction for keyboard-first respondents.
6666+- Matches the requested “input field focused by default” behavior.
6767+- Works cleanly with the existing one-step-at-a-time runner model.
6868+6969+**Alternatives considered:**
7070+- Rely on browser autofill/autofocus attributes alone: rejected because the active block is replaced dynamically and needs controlled focus on each step change.
7171+- Focus the card container instead of the input: rejected because it still requires an extra keystroke before typing.
7272+7373+### 5. Preserve multiline authoring with `Shift+Enter` while keeping plain `Enter` for progression
7474+For long-text questions, plain `Enter` should advance to the next step just like other input questions, while `Shift+Enter` may continue inserting a newline. This keeps the product's “Enter continues” rule intact without fully removing multiline entry.
7575+7676+**Why this approach:**
7777+- Respects the user's request that Enter advances.
7878+- Avoids regressing long-text questions into effectively single-line fields.
7979+- Minimizes behavior changes because the current code already distinguishes `Shift+Enter`.
8080+8181+**Alternatives considered:**
8282+- Make Enter always insert a newline in long text: rejected because it breaks the requested keyboard progression model.
8383+- Remove multiline entry entirely: rejected because it harms legitimate long-answer use cases.
8484+8585+## Risks / Trade-offs
8686+8787+- **Shortcut collisions with browser or assistive-technology commands** → Ignore modified key combinations and scope numeric shortcuts only to the active runner step when no text input is being edited.
8888+- **The `0` mapping for a tenth option may be less obvious than `1`-`9`** → Show the visible key badge on the option itself so the mapping is explicit on both desktop and mobile.
8989+- **Suppressing Enter on focused choice buttons can surprise users who expect default button semantics** → Keep the continue affordance visible, make digit shortcuts prominent, and allow pointer clicks to behave normally.
9090+- **Autofocus can feel jumpy if applied too aggressively during animation** → Focus only after the active block changes and skip focus moves during submission/completion states.
9191+9292+## Migration Plan
9393+9494+1. Add localized public-runner hint strings for numeric shortcuts and any related keycap labels.
9595+2. Refactor `components/public-form-runner.tsx` so active-step keyboard handling is centralized around the current block type.
9696+3. Add refs and active-step focus effects for text-like inputs and the date picker trigger/input.
9797+4. Update choice option rendering to show shortcut badges on both desktop and mobile and remove Enter-driven toggle behavior.
9898+5. Verify keyboard flows for single choice, multiple choice, agreement, text-like inputs, back navigation, and final submission.
9999+100100+Rollback strategy:
101101+- Revert the runner keyboard/focus changes and localized hint copy. No persisted data or schema rollback is required.
102102+103103+## Open Questions
104104+105105+- Should agreement blocks also advertise a numeric shortcut when there is only one visible action, or is consistent badge treatment enough?
106106+- Do we want a future creator setting to disable visible shortcut hints for highly customized branded forms?
···11+## Why
22+33+The public form runner currently requires too much pointer interaction for common question flows and has at least one keyboard bug: pressing Enter to continue can also toggle the selected option on choice questions. Improving keyboard-first behavior now will make submissions faster, more accessible, and more predictable for respondents.
44+55+## What Changes
66+77+- Add keyboard-first answering support in the public runner for choice-based questions so respondents can use number keys like `1`, `2`, `3`, and so on to select or toggle visible options.
88+- Show respondents that numbered choice questions support keyboard shortcuts instead of leaving the capability hidden, and keep those button hints visible on mobile layouts too.
99+- Automatically focus the primary text-like input on questions that accept typed answers so respondents can start typing immediately.
1010+- Restrict Enter handling so Enter advances to the next question or submits only when appropriate, and does not also toggle a selected choice option.
1111+- Keep existing validation, branching, submission, and non-keyboard interaction behavior intact.
1212+1313+## Capabilities
1414+1515+### New Capabilities
1616+- None.
1717+1818+### Modified Capabilities
1919+- `anonymous-form-runner`: extend respondent interaction requirements so published forms support clearer, more reliable keyboard-driven answering and navigation.
2020+2121+## Impact
2222+2323+- Affected code: public runner keyboard event handling, responsive question option rendering, input focus management, localized helper copy, and runner regression coverage.
2424+- No API or database changes are expected.
2525+- The change is limited to respondent-facing published form behavior.
···11+## ADDED Requirements
22+33+### Requirement: Runner supports keyboard-first response entry
44+The system SHALL support keyboard-first answering for the active step in the public form runner. For single-choice, multiple-choice, and agreement questions, the system SHALL map visible options in display order to digit shortcuts using `1` through `9` and `0` for the tenth visible option when present, and SHALL show respondents that those shortcuts are available. The shortcut affordances for those choice-style actions SHALL remain visible on mobile layouts as well as larger screens. For questions with a primary typed input, the system SHALL focus that input when the step becomes active. Pressing Enter on the active step SHALL advance to the next question or submit on the last step when validation succeeds, and SHALL NOT also toggle or change a choice answer.
55+66+#### Scenario: Respondent selects a single-choice option with a number key
77+- **WHEN** a respondent is on a single-choice question and presses the digit key for a visible option
88+- **THEN** the system selects that option as the current answer for the question
99+1010+#### Scenario: Respondent toggles a multiple-choice option with a number key
1111+- **WHEN** a respondent is on a multiple-choice question and presses the digit key for a visible option that is already selected
1212+- **THEN** the system removes that option from the current answer for the question
1313+1414+#### Scenario: Respondent sees that keyboard shortcuts are available
1515+- **WHEN** a respondent views a choice-based question in the public runner
1616+- **THEN** the system shows visible shortcut affordances or helper text indicating which number keys can be used for the available options
1717+1818+#### Scenario: Respondent sees shortcut hints on mobile
1919+- **WHEN** a respondent views a choice-based question on a mobile layout
2020+- **THEN** the system still shows the shortcut affordances for the available actions instead of hiding them at that viewport size
2121+2222+#### Scenario: Respondent lands on a text-input question
2323+- **WHEN** a respondent advances to a short text, long text, number, link, or date question
2424+- **THEN** the system focuses the primary input control for that question by default
2525+2626+#### Scenario: Respondent presses Enter on a choice question
2727+- **WHEN** a respondent presses Enter on an active choice question after making a valid selection
2828+- **THEN** the system advances to the next step or submits on the last step without changing the current choice selection as a side effect
···11+## 1. Runner keyboard behavior
22+33+- [x] 1.1 Refactor `components/public-form-runner.tsx` to centralize active-step keyboard handling for Enter, Escape, and digit shortcuts by block type.
44+- [x] 1.2 Implement digit-key selection/toggling for single-choice, multiple-choice, and agreement steps using visible option order and preserving existing validation/branching behavior.
55+- [x] 1.3 Prevent Enter on focused choice controls from toggling an option so Enter only continues or submits when the current step is valid.
66+77+## 2. Focus and affordance updates
88+99+- [x] 2.1 Add active-step autofocus for short text, long text, number, link, and date questions without stealing focus during submission or completion.
1010+- [x] 2.2 Update choice and agreement option rendering to show visible numeric shortcut badges and helper affordances for keyboard-driven answering, including on mobile layouts.
1111+- [x] 2.3 Add or update localized public-runner strings needed for keyboard shortcut hints and any related key labels.
1212+1313+## 3. Verification
1414+1515+- [x] 3.1 Verify keyboard flows for single-choice, multiple-choice, and agreement questions, including number-key answering, visible mobile shortcut hints, and Enter-to-continue behavior.
1616+- [x] 3.2 Verify autofocus and Enter behavior for short text, long text, number, link, and date questions, including multiline long-text handling.
1717+- [x] 3.3 Add or update regression coverage for the Enter double-action bug and the new keyboard-first runner interactions.