- Shipped
- August 26, 2026 at 2:32 AM UTC
- Author
- kamo
- Commit
- 8309000
The two surfaces had each grown their own answer to "which days?". The settings tab put Workweek Days, Weekend Days and Every Day behind a dropdown; the calendar editor had a multi-select ribbon and no groups at all. Whichever a member learned first, the other could not do what it did. They share AvailabilityDayPicker now — the group buttons AND the seven chips, on both pages, defined once. That is the only arrangement that keeps them the same the next time either is touched. Groups select rather than save. Pressing "Workweek Days" turns on five chips and nothing downstream interprets a sentinel: the member can immediately deselect the Wednesday they are away for, and what reaches the backend is what it has always taken, one window per day. A group button reads as on only when EXACTLY its days are chosen, so the control can say "this is the workweek" instead of leaving somebody to count lit chips. The settings tab gains something it never had — an arbitrary multi-day pick. "Monday, Wednesday and Friday" was not expressible there before; it was one day or one group. daysToSave therefore takes a day LIST rather than a day-or-group, which is what lets both surfaces share a selection type. Both guardrails still hold and are still pinned: an edit never expands into several rows, and a multi-day pick never collapses to one. The panel's "What does this mean?" now starts collapsed for everybody. Opening it for a member with nothing declared was meant as a kindness and was the wrong one — it pushed the list and the button that starts the whole thing down the column, so the first thing a new presenter met was a wall of prose rather than the control the prose is about. Also raises the timeout on the sound catalogue's whole-tree scan. It reads and concatenates every source file in the app, lands at 6-13s whenever the machine is busy, and was failing the suite against vitest's 5s default — with a message that named no event, because it never reached its assertion. The scan is worth keeping; the default timeout is simply not sized for it.