Update beans tracking files

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

.beans/nuzlocke-tracker-5bez--non-evolution-form-changes.md

@@ -0,0 +1,30 @@
+---
+# nuzlocke-tracker-5bez
+title: Non-evolution form changes
+status: draft
+type: feature
+created_at: 2026-02-07T13:40:00Z
+updated_at: 2026-02-07T13:40:00Z
+---
+
+Some Pokemon can change form without evolving, using items or abilities. These form changes affect types, stats, and appearance but are not part of the evolution chain.
+
+## Examples
+
+- **Oricorio**: Changes form (Baile/Pom-Pom/Pa'u/Sensu) by using nectar items from different islands. Each form has a different type (Fire, Electric, Psychic, Ghost + Flying).
+- **Darmanitan**: Has a Zen Mode ability that changes it to Darmanitan (Zen) in battle (Fire/Psychic). Galarian Darmanitan Zen Mode is Ice/Fire.
+- **Rotom**: Changes form by interacting with appliances (Heat/Wash/Frost/Fan/Mow), each with different secondary types.
+- **Shaymin**: Changes between Land and Sky forme using the Gracidea flower.
+- **Tornadus/Thundurus/Landorus**: Incarnate vs Therian forms via the Reveal Glass.
+- **Hoopa**: Confined vs Unbound via the Prison Bottle.
+
+## Scope
+
+This is lower priority than basic form support (bean f44d) and submodule update (bean 6aje). It matters for tracking because a player might catch an Oricorio in one form and change it to another — the tracker should reflect the current form's types.
+
+## Design considerations
+
+- Should the tracker allow manually changing a caught Pokemon's form?
+- Or should it just track the form as encountered and leave it static?
+- How to represent form-change items/methods in the data model?
+- This may not need seed data support — could be a manual UI action on a caught Pokemon

.beans/nuzlocke-tracker-6aje--update-pokeapi-data-submodule-to-latest-version.md

@@ -3,23 +3,28 @@
 title: Update PokeAPI data submodule to latest version
 status: todo
 type: task
+priority: high
 created_at: 2026-02-06T10:53:45Z
-updated_at: 2026-02-06T10:53:45Z
+updated_at: 2026-02-07T13:39:12Z
 ---
 
-The local PokeAPI data repository we use as a submodule is outdated. It's missing newer games like Pokemon Legends: Z-A.
+The local PokeAPI data repository we use as a submodule is outdated. It's missing data for newer Pokemon forms and potentially newer games.
 
-## Context
-- We fetch seed data from a local copy of PokeAPI data (submodule)
-- This avoids hitting the API directly but means we need to periodically update
-- Missing games won't have encounter data until the submodule is updated
+## Why this is important now
+
+After adding form support to seeding (bean f44d), we discovered that the submodule is missing many form entries. Currently only 16 forms are included — all from Gen 7 (Alolan + Oricorio/Lycanroc). Missing forms include:
+
+- **Galarian forms** (Gen 8): Galarian Meowth, Ponyta, Rapidash, Slowpoke, Farfetch'd, Weezing, Mr. Mime, Corsola, Zigzagoon, Linoone, Darumaka, Darmanitan, Stunfisk, Yamask
+- **Hisuian forms** (Gen 8/Legends Arceus): Hisuian Growlithe, Voltorb, Typhlosion, Samurott, Decidueye, Zorua, Zoroark, Braviary, Goodra, Avalugg, Sneasel, Lilligant, Qwilfish, Sliggoo
+- **Paldean forms** (Gen 9): Paldean Wooper, Tauros
+- **Other missing forms**: Basculin (White-Striped), regional bird variants, etc.
+
+These forms have different types and stats from their base species and appear in encounter data for their respective games. Without them in the submodule, the seeding script can't create Pokemon records for them.
 
 ## Action
+
 - Check for updates to the PokeAPI data repository
 - Update the submodule to the latest version
 - Re-run fetch_pokeapi.py to regenerate seed data
 - Add any new games to VERSION_GROUPS in fetch_pokeapi.py
-
-## Notes
-- Low priority - current games (Gen 1-9) are sufficient for MVP
-- Legends Z-A may not have traditional encounter data anyway (open world)
+- Verify that form count increases significantly after update

.beans/nuzlocke-tracker-zwmk--pinwheel-clause-support.md

@@ -0,0 +1,31 @@
+---
+# nuzlocke-tracker-zwmk
+title: Pinwheel Clause support
+status: draft
+type: feature
+created_at: 2026-02-07T13:39:46Z
+updated_at: 2026-02-07T13:39:46Z
+---
+
+Some Nuzlocke games use the **Pinwheel Clause** (also called the Dupes Clause variant for multi-encounter areas). In certain areas, players are allowed multiple encounters instead of the standard one-per-route rule.
+
+## Context
+
+The Pinwheel Clause is named after Pinwheel Forest in Black/White, where the inner and outer areas are considered separate encounter zones. Other examples include Safari Zones, large caves with distinct floors, and similar multi-zone areas.
+
+Currently the tracker enforces strict one-encounter-per-route. This feature would allow toggling the Pinwheel Clause for a run, which would let players mark multiple encounters as valid on designated routes.
+
+## Design considerations
+
+- Should this be a per-run toggle (enabled/disabled when creating a run)?
+- Which areas qualify? Could be data-driven (flag on route data) or user-controlled (manually mark routes as multi-encounter)
+- How does this interact with the UI? Maybe routes with the clause show multiple encounter slots
+- Consider also supporting other common clauses (Dupes Clause, Shiny Clause) as a general "house rules" system
+
+## Checklist
+
+- [ ] Decide on clause toggle mechanism (per-run setting vs per-route flag vs both)
+- [ ] Design data model changes (run settings, route flags)
+- [ ] Implement backend support
+- [ ] Update frontend encounter UI to handle multi-encounter routes
+- [ ] Add clause toggle to run creation/settings