feat(code): clean up plan question response key handling and validation

[adboio]

Problem

hitting "enter" after typing a custom response to a question does nothing. but shift+enter does correctly make a newline

Changes

• makes "enter" submit the custom response
• adds validation to disable the submit button per question if nothing is selected

How did you test this?

manually

Publish to changelog?

no

[adboio]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat(code): show more context for MCP permission requests #2071
• feat(code): clean up plan question response key handling and validation #2070 👈 (View in Graphite)
• fix(code): fix styling on inline file links #2069
• feat(code): add diff stats to convo view #2065
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Comments Outside Diff (2)

1. apps/code/src/renderer/components/action-selector/useActionSelectorState.ts, line 480-485 (link)

   setIsEditing(false) fires before the early-return guard

   setIsEditing(false) is called unconditionally on line 480, then on line 482 we potentially return early (empty text, nothing checked). This means pressing Enter on an empty "Other" input silently collapses the editor without submitting — the user has to click "Other" again to re-open it. This matches the previous behaviour so it isn't a regression, but it is easy to miss. Consider moving the setIsEditing(false) call to just before each exit path so the intent is explicit, or at least add a comment explaining that closing the editor on a no-op Enter is the desired UX.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/code/src/renderer/components/action-selector/useActionSelectorState.ts
   Line: 480-485
   
   Comment:
   **`setIsEditing(false)` fires before the early-return guard**
   
   `setIsEditing(false)` is called unconditionally on line 480, then on line 482 we potentially `return` early (empty text, nothing checked). This means pressing Enter on an empty "Other" input silently collapses the editor without submitting — the user has to click "Other" again to re-open it. This matches the previous behaviour so it isn't a regression, but it is easy to miss. Consider moving the `setIsEditing(false)` call to just before each exit path so the intent is explicit, or at least add a comment explaining that closing the editor on a no-op Enter is the desired UX.
   
   How can I resolve this? If you propose a fix, please make it concise.

2. apps/code/src/renderer/components/action-selector/useActionSelectorState.ts, line 252-272 (link)

   Submit-path logic duplicated in four places

   The same "check canSubmitOrAdvance, step-advance or call handleSubmitMulti/handleSubmitSingle" block now appears in selectCurrent, selectByIndex, handleClick, and handleInlineSubmit. The new canSubmitOrAdvance guard had to be added to all four independently. Extracting this into a shared handleSubmit() helper would satisfy OnceAndOnlyOnce, make future changes (like adding more guards) a single-site edit, and reduce the risk of the paths drifting out of sync again.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/code/src/renderer/components/action-selector/useActionSelectorState.ts
   Line: 252-272
   
   Comment:
   **Submit-path logic duplicated in four places**
   
   The same "check `canSubmitOrAdvance`, step-advance or call `handleSubmitMulti`/`handleSubmitSingle`" block now appears in `selectCurrent`, `selectByIndex`, `handleClick`, and `handleInlineSubmit`. The new `canSubmitOrAdvance` guard had to be added to all four independently. Extracting this into a shared `handleSubmit()` helper would satisfy OnceAndOnlyOnce, make future changes (like adding more guards) a single-site edit, and reduce the risk of the paths drifting out of sync again.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/code/src/renderer/components/action-selector/useActionSelectorState.ts:480-485
**`setIsEditing(false)` fires before the early-return guard**

`setIsEditing(false)` is called unconditionally on line 480, then on line 482 we potentially `return` early (empty text, nothing checked). This means pressing Enter on an empty "Other" input silently collapses the editor without submitting — the user has to click "Other" again to re-open it. This matches the previous behaviour so it isn't a regression, but it is easy to miss. Consider moving the `setIsEditing(false)` call to just before each exit path so the intent is explicit, or at least add a comment explaining that closing the editor on a no-op Enter is the desired UX.

### Issue 2 of 2
apps/code/src/renderer/components/action-selector/useActionSelectorState.ts:252-272
**Submit-path logic duplicated in four places**

The same "check `canSubmitOrAdvance`, step-advance or call `handleSubmitMulti`/`handleSubmitSingle`" block now appears in `selectCurrent`, `selectByIndex`, `handleClick`, and `handleInlineSubmit`. The new `canSubmitOrAdvance` guard had to be added to all four independently. Extracting this into a shared `handleSubmit()` helper would satisfy OnceAndOnlyOnce, make future changes (like adding more guards) a single-site edit, and reduce the risk of the paths drifting out of sync again.

_{Reviews (1): Last reviewed commit: "feat(code): clean up plan question respo..." | Re-trigger Greptile}