Add beans for evolutions, area grouping, UX pass, and gift encounters

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

.beans/nuzlocke-tracker-a7q2--handle-pokemon-evolutions.md

@@ -0,0 +1,14 @@
+---
+# nuzlocke-tracker-a7q2
+title: Handle pokemon evolutions
+status: todo
+type: feature
+created_at: 2026-02-05T14:27:07Z
+updated_at: 2026-02-05T14:27:07Z
+parent: nuzlocke-tracker-f5ob
+---
+
+Add support for pokemon evolutions in the tracker. When a pokemon evolves during a Nuzlocke run, the tracker should reflect the new species while preserving the encounter history (original catch route, catch level, nickname, etc.). Needs investigation into:
+- How to model evolutions (track current species vs. original species)
+- Whether to pull evolution chain data from PokeAPI during seeding
+- UX for marking a pokemon as evolved (from the team view or encounter edit)

.beans/nuzlocke-tracker-qeim--ux-improvements-pass.md

@@ -0,0 +1,21 @@
+---
+# nuzlocke-tracker-qeim
+title: UX improvements pass
+status: draft
+type: task
+created_at: 2026-02-05T14:27:17Z
+updated_at: 2026-02-05T14:27:17Z
+---
+
+The current encounter tracking and run dashboard UX is clunky. Do a holistic UX review and propose improvements.
+
+Areas to evaluate:
+- Encounter logging flow (too many clicks? modal vs inline?)
+- Route list readability and navigation (long lists, no grouping)
+- Run dashboard information density
+- Mobile usability
+- Navigation between run dashboard and encounters
+- Empty states and onboarding flow
+- Visual feedback for actions (success/error toasts, optimistic updates)
+
+Produce a concrete plan with specific UI/UX changes to implement.

.beans/nuzlocke-tracker-rxrt--support-giftstatic-encounter-marking.md

@@ -0,0 +1,10 @@
+---
+# nuzlocke-tracker-rxrt
+title: Support gift/static encounter marking
+status: todo
+type: feature
+created_at: 2026-02-05T14:21:47Z
+updated_at: 2026-02-05T14:21:47Z
+---
+
+Add ability to distinguish gift/static encounters in the encounter tracking interface. Currently all encounters are treated the same regardless of encounter method. The backend RouteEncounter model already has an encounterMethod field from PokeAPI (gift, walk, etc.) — surface this in the UI and potentially allow logging encounters on routes that don't have PokeAPI encounter data (e.g. starter pokemon, in-game trades).

.beans/nuzlocke-tracker-u7i9--combine-sub-areas-into-single-locations.md

@@ -0,0 +1,19 @@
+---
+# nuzlocke-tracker-u7i9
+title: Combine sub-areas into single locations
+status: todo
+type: feature
+created_at: 2026-02-05T14:27:13Z
+updated_at: 2026-02-05T14:27:13Z
+parent: nuzlocke-tracker-f5ob
+---
+
+Some game locations have multiple encounter tables (e.g. Mount Moon 1F, Mount Moon B1F, Mount Moon B2F) but are treated as a single location for Nuzlocke first-encounter rules. 
+
+Needs a concept of 'location groups' — a parent location that contains multiple sub-areas, each with their own encounter table. For Nuzlocke purposes, the first encounter in *any* sub-area of the group counts as that location's encounter.
+
+## Considerations
+- Data model: add a parent_route_id or location_group concept to the Route model
+- Seed data: identify which routes should be grouped (may need manual curation per game)
+- Encounter tracking: when logging an encounter in a sub-area, mark the whole group as visited
+- Route list UI: show grouped locations as collapsible sections