Schedule filter URL params (stages) should use slugs, not UUIDs

[chiptus]

Problem

The Timeline/List schedule filter sheet encodes the stages search param as raw stage UUIDs (e.g. stages=["11111111-1111-1111-1111-11111111111a"]), matching src/lib/searchSchemas.ts:41 (stages: z.array(z.string()).catch([])) and written via useTimelineUrlState.updateStages (src/hooks/useTimelineUrlState.ts:44-53).

This makes the URL both illegible to users (nothing readable in a shared/bookmarked link) and easy to get wrong when constructing URLs by hand (e.g. in tests) — a UUID silently fails schema validation if not JSON-array-encoded exactly as TanStack Router's default serializer expects, falling back to [] with no error.

stages already has a slug column (supabase/migrations/20250905000000_add_group_stage_slugs.sql), so switching the stages search param (and any other filter params keyed by UUID) to use slugs would make schedule filter URLs human-readable and more robust to construct/share, consistent with how festivalSlug/editionSlug already work in the route path.

Suggested scope

• Audit src/lib/searchSchemas.ts and useTimelineUrlState/ScheduleFilterSheet for any other UUID-keyed filter params (stages is the one found so far).
• Serialize/deserialize stages by slug instead of id, resolving to the underlying stage id internally where needed (e.g. StageFilterButtons.tsx, useScheduleData.ts).
• Update e2e tests that build filter URLs directly (tests/e2e/schedule-filter-sheet.spec.ts) to use slugs.

Found while investigating an e2e flake in schedule-filter-sheet.spec.ts where a hand-built stages=<uuid> URL failed schema validation and silently reset to no stage filter.

[chiptus]

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: Replace UUID-keyed filter search params (stages in both the Schedule and Sets/Explore tabs, plus groupId in the Sets/Explore tab) with slug-keyed equivalents, resolved internally to the underlying id.

Current behavior:
Three URL search params encode entity UUIDs directly:

• timelineSearchSchema.stages (Schedule tab's Timeline/List views) — array of stage UUIDs, validated only as z.array(z.string()).catch([]). Any malformed value (e.g. a hand-built URL not matching the router's exact array serialization) silently resets to an empty array with no error — this caused a real e2e flake.
• filterSortSearchSchema.stages (Sets/Explore tab) — same shape, same problem, separate schema.
• filterSortSearchSchema.groupId (Sets/Explore tab's group filter, driven by GroupFilterDropdown) — a single group UUID, always chosen from the current user's own groups list.

None of these are human-readable in a shared/bookmarked link, and none have format validation beyond "is a string."

Both stages and groups already have slug columns: stages.slug is unique per festival_edition_id (safe to resolve unambiguously within a known edition), and groups.slug is unique per created_by (not globally unique — the same slug can exist under different creators). The codebase already has a working resolution pattern for the group case: fetchGroupBySlug/groupBySlugQuery (used by the /groups/$groupSlug route) resolves a slug by checking, in order, groups the current user is a member of, then groups the current user created. Since groupId in the filter context is always drawn from the current user's own groups list already, this exact resolution rule applies directly — reuse it rather than inventing a new one.

Desired behavior:

• All three search params are serialized/deserialized as slugs in the URL. Internally, wherever the current id is used for comparison or lookup (stage filtering, group filtering), resolve the slug to the underlying id once and continue using the id for all internal logic — the split is purely at the URL-encoding boundary.
• Stage slug resolution is scoped to the current festival edition (matching the DB uniqueness constraint).
• Group slug resolution follows the existing member-then-creator, current-user-scoped rule from fetchGroupBySlug.
• An unresolvable slug (typo'd, belongs to a different edition/user, etc.) degrades gracefully — same "filter not applied" fallback behavior as an invalid value does today, not a crash or an unhandled error.
• All existing user-facing filtering behavior (Schedule stage filter, Sets/Explore stage filter, Sets/Explore group filter) is unchanged — same results, different URL encoding only.

Key interfaces:

• timelineSearchSchema.stages / filterSortSearchSchema.stages (src/lib/searchSchemas.ts) — change the array element type/validation from raw string (UUID) to stage slug; resolution to stage.id happens where the schedule/sets data is filtered (currently keyed by stage.id in places like the stage filter buttons and schedule data hook).
• filterSortSearchSchema.groupId — change from raw group UUID to group slug; resolution reuses the same lookup shape as fetchGroupBySlug(slug, userId).
• Any component currently comparing selectedStages.includes(stage.id) or stages.find((s) => s.id === stageId) style logic — keep comparing by id internally; only the URL read/write boundary changes to slugs.

Acceptance criteria:

• timelineSearchSchema.stages and filterSortSearchSchema.stages are stage slugs in the URL, not UUIDs.
• filterSortSearchSchema.groupId is a group slug in the URL, not a UUID.
• Group slug resolution matches the existing member-then-creator, current-user-scoped rule already used by /groups/$groupSlug — not a new or different rule.
• An unresolvable/unknown slug in any of these three params degrades to "no filter applied" rather than throwing.
• All existing filter behavior (Schedule stage filter, Sets/Explore stage filter, Sets/Explore group filter) produces identical results to before the change — verified by existing tests continuing to pass.
• tests/e2e/schedule-filter-sheet.spec.ts and any other e2e spec that builds one of these three URL params directly is updated to use slugs instead of UUIDs.

Out of scope:

• Other search params not named here (day, time, votes, minRating, sort, timelineView, use24Hour, invite, sortLocked) — already human-readable or not entity ids.
• The festivalSlug/editionSlug route path params — already slugs, unaffected.
• Changing the underlying DB slug columns or their uniqueness constraints.
• The invite search param's token-based flow — unrelated to entity-id filtering.

---

Generated by Claude Code