the channel select dropdown on the dashboard/servers page should have a…

[quarterback-ai-dev-environment]

Intent

the channel select dropdown on the dashboard/servers page should have a field at the top that allows you to filter the options in the dropdown, since some servers have many channels. There should also be a vertical limit to the dropdown of about 10 rows so that a server with 100 channels doesn't open a select box that takes up the whole vertical limit of the screen.

Claims proven

• The admin channel picker in the channel-region partial offers a case-insensitive substring text filter over the guild's text channels: typing a fragment narrows the visible channel options to those whose name contains that fragment regardless of case. (CAN)
• The channel picker's scrollable option list shows at most 10 channel rows at once as a hard cap; a guild with more than 10 channels renders all of them but the list is height-capped to 10 rows and scrolls to reach the rest. (WITHIN)
• When the substring filter matches no channels, the picker shows an italic 'not found' message in place of the (now empty) option list. (CAN)
• The searchable channel picker is built from DaisyUI component primitives wherever a DaisyUI primitive fits the need (the input, the dropdown/menu list container, the option rows), rather than bespoke unstyled markup. (MUST)
• Selecting a channel through the new picker still submits that channel's id as channel_id to POST /dashboard/servers/{guildID}/channel via the existing confirm-modal htmx flow, and SetGuildChannel's membership + channel-ownership validation and persistence behaviour are unchanged. (MUST)
• The confirm modal's 'New channel' preview text reflects the channel chosen in the new picker (the selected channel's display name), not the option of a native that no longer exists. (CAN) Confidence: medium

[quarterback-ai-dev-environment]

Review findings

Advisory:

• REQ-2 requirement-vs-intent drift: the approved requirement hardens the original intent's "about 10 rows" into "capped at exactly 10 rows maximum visible." The artifact implements the cap as max-h-80 (320px) with overflow-y-auto on #channel-picker-options (web/templates/partials/channel-region.html:52) and rows at h-8 (32px, line 56). 10 rows would be 320px, but the <ul> also carries p-2 (16px vertical padding) and DaisyUI menu inter-item gaps, so the actual simultaneously-visible count is ~9-10, not pixel-exact 10 (and a static max-height cannot be pixel-exact across zoom/font-size anyway). This faithfully satisfies the ORIGINAL intent ("about 10 rows") and CLM-2's "hard cap sized to ~10 rows, scroll for the rest" mechanism, which is why it is not blocking — but the requirement text overstates exactness. Recommend reconciling REQ-2's wording to "about 10" or tightening the CSS (e.g. drop the vertical padding / size max-height to 10*row incl. gaps) if strict-10 is truly wanted.