Add setter follows, profiles, and unified search

[marcodejongh]

Summary

Implements #812 - Allow following of all setters in the climbs dataset.

• Setter follows: Users can follow any setter (including non-Boardsesh users synced from Aurora API). Following a setter with a linked Boardsesh account also creates a user follow.
• Setter profile pages: New /setter/[username] route showing setter info, board type badges, follower count, follow button, linked Boardsesh profile link, and paginated created climbs list.
• Unified search: Search now returns both Boardsesh users and setters, with de-duplication for linked accounts. Setter results show climb count and board type badges.
• Created climbs on user profiles: Boardsesh user profiles now show a "Created Climbs" section for linked Aurora accounts.
• Sync notifications: Shared sync detects newly inserted climbs and creates batched new_climbs_synced notifications for setter followers.
• Notification display: New notification type renders as "{setter} set new climbs" and navigates to the setter profile on click.

Files changed across all packages:

• db: setter_follows table, new_climbs_synced notification enum, migration, index on board_climbs.setter_username
• shared-schema: GraphQL types/inputs/queries/mutations + TypeScript interfaces for setter profiles, climbs, unified search
• backend: Setter follow/unfollow resolvers, profile/climbs queries, unified search with de-duplication, notification enrichment
• web: Setter profile page, setter climb list component, unified search UI, user profile created climbs, sync notification creation, notification display

Test plan

• Search for a known setter username → appears in results with climb count and board badges
• Click setter result → navigates to /setter/[username] with profile and climbs
• Follow/unfollow setter → follow count updates, persists on reload
• View Boardsesh user with linked Aurora accounts → "Created Climbs" section appears
• Run shared sync with new climbs from a followed setter → batched notification appears
• Click new_climbs_synced notification → navigates to setter profile
• Linked setter+user search → de-duplicated, shows as single user result with climb count
• Run npm run typecheck → all packages pass

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
boardsesh	Building	Preview, Comment	Feb 14, 2026 11:08am

[claude]

Claude Review

✅ Ready to merge - Minor issues noted below, but nothing blocking.

Issues

1. Pagination bug in searchUsersAndSetters - packages/backend/src/graphql/resolvers/social/setter-follows.ts:339: The unified search collects all user and setter results into memory, sorts them, then applies offset/limit. This means totalCount reflects the in-memory array length, not the true database count. For large datasets, this could be inefficient and the pagination behavior may be surprising (e.g., total could change between pages). Consider using database-level pagination.

2. Missing N+1 query optimization in notifications - packages/backend/src/graphql/resolvers/social/notifications.ts:46-62: The new_climbs_synced notification enrichment fetches climb data individually within a loop over groups. If many notifications exist, this will issue many separate queries.

3. unfollowSetter always removes user_follows - packages/backend/src/graphql/resolvers/social/setter-follows.ts:442-458: When unfollowing a setter with a linked Boardsesh account, the code unconditionally removes the user_follows relationship. This could be unexpected if the user had independently followed the Boardsesh user before they linked their Aurora account. Consider checking if the user_follows was created via setter follow before removing.

4. Missing index usage verification - The migration adds a partial index on board_climbs.setter_username (WHERE setter_username IS NOT NULL), but queries like ilike(dbSchema.boardClimbs.setterUsername, searchPattern) may not fully utilize this index for pattern matching. This is not a bug but worth verifying query performance.

Documentation

No documentation updates appear to be needed - this is a new feature addition that doesn't modify existing documented systems.

[claude]

Claude Review

✅ Ready to merge - Well-structured feature implementation. Minor issues noted below, but nothing blocking.

Issues

1. N+1 Query in notification enrichment - packages/backend/src/graphql/resolvers/social/notifications.ts:74-91: The new_climbs_synced notification enrichment queries the database inside a loop (for (const group of groups)). For many notifications, this creates N+1 queries. Consider batching.

2. Missing error handling in navigation - packages/web/app/components/climb-list/setter-climb-list.tsx:110-118: The navigateToClimb function catches errors silently. Consider at minimum logging the error for debugging.

3. Potential memory issue in unified search - packages/backend/src/graphql/resolvers/social/setter-follows.ts:632-675: Results are fully materialized in memory and then sorted/paginated client-side. For large result sets, consider database-level pagination.

4. Missing index for setter climbs query performance - packages/backend/src/graphql/resolvers/social/setter-follows.ts:225-270: The setterClimbs query orders by ascensionist_count but there's no composite index on (setter_username, ascensionist_count). With large datasets, this could be slow.

5. Hardcoded default angle - packages/backend/src/graphql/resolvers/social/setter-follows.ts:319,489: Default angle of 40 is hardcoded. This works for most boards but may not be ideal for all board types.

Tests

• No tests included for the new GraphQL resolvers, mutations, or notification creation logic
• The setter follow/unfollow mutations and unified search would benefit from unit tests

Documentation

• No documentation updates needed - this is a new feature not covered by existing docs