💭 I'm checking the relevant files—ScheduledTasksSection.tsx, ProjectSettingsPanel.tsx, entities.ts, and orchestration.ts—to understand how they're structured, particularly focusing on UI consistency and the shared primitives like Button, Input, Select, and SettingsRow/SettingsSection.

1. browse_code — apps/web/src/components/settings/*.tsx

2. browse_code — apps/web/src/components/settings/settingsLayout.tsx

💭 I need to check ScheduledTasksSection.tsx directly in the repo for exact lines, and verify the Button component's size variants, the Select component's API for value handling, and the Input component's props.

3. browse_code — apps/web/src/components/ui/button.tsx

4. browse_code — apps/web/src/components/ui/select.tsx

💭 I'm checking how the ScheduledTasksSection's Select component compares to other settings panels' usage patterns, particularly around whether they pass an items prop or use SelectValue with children for rendering values from keys. If the SelectValue has no children, it'll just show the raw preset key string instead of a friendly label like "Once, tomorrow at 9:00" — that seems like an actual bug worth verifying against other call sites.

5. git_tools — SelectValue

💭 I've confirmed that a bare <SelectValue /> without an items map will just display the raw stored value—so in ScheduledTasksSection this means the schedule preset would show "tomorrow-9" instead of readable text, and the thread select would show the raw ID instead of the title, which is a real regression on the changed lines. Now I'm checking whether BrowserDeviceToolbar and BranchToolbar have the same bare pattern to see if this is a broader issue or isolated to this file.

6. browse_code — apps/web/src/browser/BrowserDeviceToolbar.tsx

7. browse_code — apps/web/src/components/settings/ScheduledTasksSection.tsx

💭 I'm confirming two issues: bare SelectValue components without items or explicit labels causing raw values to render in triggers instead of proper labels (two occurrences), and missing aria-label attributes on SelectTriggers that violate the repo's established convention. I also notice fixed widths like w-64 and w-56 on SelectTriggers deviate from the pattern used elsewhere (w-full sm:w-40), which could cause overflow issues on smaller screens — worth flagging as a responsive consistency concern, while the SelectPopup alignment defaults and hideIndicator inconsistencies seem more minor and probably not worth calling out. I'm also verifying how Base UI's Select.Value handles rendering when items are provided versus not, since the thread selector's composite value key needs proper label mapping to display correctly rather than showing the raw value string. Let me check whether the button shows a loading state during submission — it uses submitting to disable, which seems fine. I also want to verify whether the Input in this row has an accessible name, since the title is rendered as an h3 rather than a label, so I should check how other settings rows handle aria-label on their inputs.

8. git_tools — <Input$|<Input\b

💭 Let me try searching for the exact fixed string "<Input" instead.

9. git_tools — <Input

💭 I notice the new Input is missing the aria-label convention used elsewhere in SettingsRow, which is worth flagging alongside the disabled-state issue. I'm also checking whether the fixed w-64 width matches the sizing convention other controls use, like w-full sm:w-40. I'll settle on three concrete review comments: the thread Select showing the raw stored value instead of the thread title (needs a proper SelectValue child plus aria-label and consistent width), the preset Select similarly displaying the raw preset key instead of its label, and the Schedule button remaining enabled even when no anchor thread is selected, which should be guarded with an added condition. Now I'm drafting the actual inline suggestion for the Select component, adding an aria-label to the SelectTrigger for accessibility, matching the existing indentation in the file. For the Input field suggestion, I'm adding an aria-label attribute to improve accessibility on the prompt input, keeping it consistent with the surrounding indentation. Then I'm noting the Button element for the schedule action doesn't need changes, just confirming its indentation matches. I'll finalize the review with these four comments and mark the review as requesting changes since accessibility issues were found, after double-checking that the title prop is already properly used in the EnvironmentThreadShell component.

10. modify_pr — UI consistency review of the new ScheduledTasksSection settings panel. Four findings, all in apps/web/src/components/settings/ScheduledTasksSection.tsx: two Select triggers render the raw stored value instead of a label (the repo's documented SelectValue contract), the two triggers and the prompt input are missing the accessible names every other settings control provides, the trigger widths break the w-full sm:w-* responsive pattern used by sibling rows, and the Schedule button stays enabled in a state where submitting is a silent no-op.