Two condition sets. A fixed set of 24 supported conditions, content already live for these. A much larger taxonomy, thousands of conditions, no content yet. Every condition anywhere in the UI carries one flag: supported or not. That single flag is the only thing deciding whether a "Coming soon" tag shows next to it.

Search matching is a plain case-insensitive substring match against the condition name. No fuzzy matching, no synonyms, no ranking beyond whatever order the underlying list is in. Same matching logic is reused everywhere search happens in this prototype, there's only one matcher.

The main screen always shows the 24 supported conditions, in a fixed order, and never filters based on search activity. This list only ever changes in one scenario: something gets added after it (see "Picking from the sheet" below).

Selection is single choice, radio style. Tapping a condition selects it, tapping the same one again deselects it, tapping a different one moves the selection. Continue only ever enables when something is selected. Nothing else affects that button's state.

There are two tappable search bars, one sitting above the 24, one sitting right after the last of them. Neither one is a real search box you can type into directly, both are pure triggers, tapping either opens the same modal sheet. There's no live filtering happening on the main screen itself.

They exist twice on purpose. Whichever one is currently on screen is the one someone will tap. The bottom one only becomes visible once someone has scrolled past all 24 without finding their condition, which is exactly the moment they'd want a way to search without scrolling back up.

Opens with the search field already focused, and shows every condition, supported and taxonomy both, before anyone types a single character. Nothing is hidden behind a "type to search" empty state. Typing filters live, same substring match as everywhere else, and unsupported matches get the "Coming soon" tag.

Picking from the sheet

What happens next depends on whether the pick is already one of the 24:

• If it's already in the 24, nothing moves. That existing row just becomes the selection, and the view scrolls to wherever that row already sits.
• If it's not one of the 24, it gets appended as a 25th row at the very end of the list, selected. It's never inserted at the top, and it never creates a duplicate row if it happens to match something already visible.

Either way, the result always scrolls into view automatically once the sheet closes, regardless of which of the two triggers opened it or how far down the list the result ends up.

Worth calling out on its own since it affects layout, not just polish. As someone scrolls down past a small threshold, the header title shrinks and the subtitle line disappears entirely, freeing up vertical space for the list. Scrolling back up near the top reverses it completely, full title size and subtitle both return.

This behavior is deliberately suspended for the entire time the sheet is open. Any incidental scroll change that happens while the sheet is up should not cause the header behind it to shrink or expand, that would read as the screen resetting itself for no reason.