What happened?
When tabbing through search surfaces in PawWork (for example the model selector search field, workspace list search, or any @opencode-ai/ui List with search={...} enabled), the focus-visible ring does not appear. This is a follow-up to #215 which covered the workspace chip half of the same pattern; #215 fixed workspace chip in-app but deliberately deferred the search input because its root lives in a synced-from-upstream package.
Steps to reproduce
- Open PawWork home page
- Open the model selector popover (click the model chip)
- Tab into the search input at the top of the list
- Observe that no focus ring is rendered around the search field
The same pattern reproduces in any surface that uses @opencode-ai/ui List with search={...} enabled.
What did you expect to happen?
Every keyboard-reachable input in the app renders a consistent focus-visible ring so users can follow keyboard navigation. In particular, the search input should receive a ring matching the pattern used elsewhere in PawWork (focus-visible:ring-2 focus-visible:ring-interactive-base, as seen on debug-bar.tsx and model/variant chips).
PawWork version
v0.2.10
OS version
macOS (Darwin 25.3.0)
Can you reproduce it again?
Yes, every time
Screenshots, recordings, or extra context
Root cause (from code inspection):
packages/ui/src/components/list.tsx:285 uses <TextField variant="ghost"> for the search input
TextField ghost variant inherits transparent focus treatment from @opencode-ai/ui
packages/ui/ is a synced-from-upstream package, so a direct fix requires one of:
- Add
focus-within:ring-* or focus-visible:ring-* to the data-slot="list-search-input" / data-slot="list-search-container" wrapper in packages/ui/src/components/list.tsx and mark the file with a file-level accept-HEAD carveout
- Adjust the
@opencode-ai/ui TextField ghost variant itself (higher blast radius — affects every TextField ghost usage in the app)
- Push the fix upstream
This is split from #215 so that the workspace chip fix can land as an app-only change while this item is scheduled with its upstream-coupling tradeoff in mind.
What happened?
When tabbing through search surfaces in PawWork (for example the model selector search field, workspace list search, or any
@opencode-ai/uiListwithsearch={...}enabled), the focus-visible ring does not appear. This is a follow-up to #215 which covered the workspace chip half of the same pattern; #215 fixed workspace chip in-app but deliberately deferred the search input because its root lives in a synced-from-upstream package.Steps to reproduce
The same pattern reproduces in any surface that uses
@opencode-ai/uiListwithsearch={...}enabled.What did you expect to happen?
Every keyboard-reachable input in the app renders a consistent focus-visible ring so users can follow keyboard navigation. In particular, the search input should receive a ring matching the pattern used elsewhere in PawWork (
focus-visible:ring-2 focus-visible:ring-interactive-base, as seen ondebug-bar.tsxand model/variant chips).PawWork version
v0.2.10
OS version
macOS (Darwin 25.3.0)
Can you reproduce it again?
Yes, every time
Screenshots, recordings, or extra context
Root cause (from code inspection):
packages/ui/src/components/list.tsx:285uses<TextField variant="ghost">for the search inputTextFieldghost variant inherits transparent focus treatment from@opencode-ai/uipackages/ui/is a synced-from-upstream package, so a direct fix requires one of:focus-within:ring-*orfocus-visible:ring-*to thedata-slot="list-search-input"/data-slot="list-search-container"wrapper inpackages/ui/src/components/list.tsxand mark the file with a file-level accept-HEAD carveout@opencode-ai/uiTextFieldghost variant itself (higher blast radius — affects everyTextField ghostusage in the app)This is split from #215 so that the workspace chip fix can land as an app-only change while this item is scheduled with its upstream-coupling tradeoff in mind.