Refine genlocke epic with user flow, child features, and action items

Break down the genlocke tracking epic into 8 child beans with
checklists, dependency chains, and success criteria. Add CLAUDE.md
instruction for updating parent checklists on child completion.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Julian Tabel
2026-02-09 08:47:49 +01:00
parent 6a36738b8b
commit 3a1aedda32
10 changed files with 439 additions and 35 deletions

View File

@@ -1,36 +1,89 @@
---
# nuzlocke-tracker-25mh
title: Genlocke tracking
status: draft
status: todo
type: epic
priority: normal
created_at: 2026-02-08T12:17:19Z
updated_at: 2026-02-08T12:17:19Z
updated_at: 2026-02-09T07:45:10Z
---
Track a **genlocke** — a series of linked nuzlocke runs, typically one per generation or region. The player picks one game per generation (e.g. FireRed instead of Red) and surviving Pokemon carry over between legs.
Track a **genlocke** — a series of linked nuzlocke runs, typically one per generation or region. The player picks one game per generation/region and surviving Pokemon carry over between legs.
## Context
## User Flow
A genlocke connects multiple nuzlocke runs into a single overarching challenge. Key aspects:
### 1. Create Genlocke
The user starts a new genlocke and gives it a name.
- **Leg ordering**: Each run is a "leg" in a defined sequence (usually Gen 1 → Gen 2 → ... or by region). The user chooses which game represents each leg.
- **Pokemon transfer**: Pokemon that survive one leg can be bred/traded into the next leg as eggs (typically hatch at level 1). This is the core mechanic that ties legs together.
- **Cumulative graveyard**: Deaths across all legs are tracked together — a Pokemon that dies in Gen 3 stays dead for the whole genlocke.
- **Overall progress**: Dashboard showing completion status across all legs, total deaths, surviving lineage, etc.
- **Flexible structure**: Some players do one game per generation, others do one per region, or even custom orderings. The system should be flexible.
### 2. Select Games (Legs)
The user picks which games to play, in order. The UI offers **preset templates** to speed this up, but the user can always customize:
## Possible data model
- **True Genlocke** — One original game per generation (Red/Blue/Yellow → Gold/Silver/Crystal → Ruby/Sapphire/Emerald → ...). Uses the original releases only.
- **Normal Genlocke** — Uses the latest remake or enhanced version for each region (FireRed/LeafGreen → HeartGold/SoulSilver → Emerald → Platinum → ...). This is the most common format.
- **Custom** — The user picks any games in any order. No restrictions on which games or how many.
- A `Genlocke` entity that groups multiple `NuzlockeRun` records in a defined order (leg number)
- Each run gets a `genlocke_id` + `leg_order` to place it in the sequence
- A `GenlockeTransfer` or similar to track which Pokemon carry over between legs (linking an encounter from leg N to a starter/gift encounter in leg N+1)
For the preset templates, the user still picks *which* game within each generation/region slot (e.g., FireRed vs LeafGreen for Gen 1). The template just determines which slots are shown. The user can add/remove/reorder legs after selecting a template.
## Potential child features
Games are grouped by **region** (not release generation) for the purpose of presets, since that's how genlocke players think about it (e.g., FireRed is a "Kanto" leg, not a "Gen 3" leg).
- Create/manage a genlocke (pick games for each leg, reorder)
- Genlocke dashboard (overall progress, cumulative stats)
- Transfer UI: after completing a leg, select surviving Pokemon to carry forward
- Lineage tracking: show a Pokemon's journey across multiple legs
- Genlocke-aware graveyard (deaths across all legs)
- Templates for common genlocke formats ("one per gen", "one per region")
### 3. Configure Rules
Two categories of rules are configured:
**Per-game nuzlocke rules** — The standard nuzlocke ruleset (first encounter only, permadeath, duplicates clause, level caps, etc.). These are set once and apply uniformly to all legs. Uses the existing `NuzlockeRules` interface.
**Genlocke-specific rules** — Overarching rules that govern how legs connect:
- **Keep HoF** (default) — Pokemon that enter the Hall of Fame at the end of a leg are transferred to the next leg as eggs (breed at level 1). This is the standard genlocke mechanic.
- **Retire HoF** — Pokemon that enter the Hall of Fame are retired. They (and their evolutionary families) become unavailable in future legs (added to a cumulative dupe list). This is also known as the "Gauntlet" rule. Increases difficulty by forcing new Pokemon each leg.
- Potentially more rules in the future (e.g., item carry-over restrictions, level scaling).
### 4. Sequential Run Progression
- When the genlocke is created, the **first leg** is automatically started as a new nuzlocke run.
- Each leg is a full nuzlocke run, tracked exactly like any standalone run (encounters, team, bosses, graveyard, etc.).
- When a leg is marked as **completed** (Hall of Fame), the next leg is started. A transfer step happens between legs where the user selects which surviving Pokemon to carry forward.
- When a leg is marked as **failed** (wipe), the genlocke itself is marked as failed (game over).
- The final leg's completion marks the entire genlocke as completed.
### 5. Genlocke Overview Page
A dedicated page showing:
- **Progress** — Which leg is active, which are completed, which are upcoming. Visual timeline or step indicator.
- **Configuration** — Selected games, rules, genlocke-specific rules.
- **Cumulative Stats** — Total encounters, total deaths, total HoF entries across all legs.
- **Lineage Tracking** — Show Pokemon that have carried over across multiple legs (their journey through the genlocke).
- **Cumulative Graveyard** — All deaths across all legs in one view.
## Data Model
### New entities:
- **`Genlocke`** — Top-level entity: name, status (active/completed/failed), genlocke rules (JSONB), created_at.
- **`GenlockeLeg`** — Join table linking a Genlocke to a NuzlockeRun: genlocke_id, run_id, leg_order. Defines the sequence.
### Changes to existing entities:
- **`NuzlockeRun`** — No schema changes needed. A run that's part of a genlocke is just a normal run that happens to be referenced by a GenlockeLeg. The genlocke-level rules are stored on the Genlocke, not duplicated per run.
### Transfer tracking:
- **`GenlockeTransfer`** — Records which Pokemon were carried between legs: from_leg_id, to_leg_id, encounter_id (the source encounter from the completed leg), to_encounter_id (the egg/gift encounter created in the next leg).
## Child Features (suggested breakdown)
1. **Genlocke creation wizard** — Multi-step UI: name → game selection (with presets) → rules → confirm
2. **Genlocke overview page** — Dashboard with progress, stats, configuration
3. **Leg progression** — Auto-start next leg when current completes, transfer step
4. **Transfer UI** — Select surviving Pokemon to carry forward between legs
5. **Lineage tracking** — Show a Pokemon's journey across legs
6. **Cumulative graveyard** — Deaths across all legs in one view
7. **Gauntlet/Retire HoF rule** — Enforce the "retire" mechanic with cumulative dupe list
## Success Criteria
- [ ] A user can create a new genlocke via a multi-step wizard (name, game selection with presets, rules)
- [ ] Games can be selected using True Genlocke, Normal Genlocke, or Custom presets, grouped by region
- [ ] Nuzlocke rules are configured once and applied uniformly to all legs
- [ ] Genlocke-specific rules (Keep HoF / Retire HoF) can be selected
- [ ] The first leg starts automatically upon genlocke creation
- [ ] Each leg is a full nuzlocke run, tracked identically to standalone runs
- [ ] Completing a leg triggers a transfer step where surviving Pokemon can be carried forward
- [ ] Failing a leg marks the entire genlocke as failed
- [ ] Completing the final leg marks the genlocke as completed
- [ ] A genlocke overview page shows progress, configuration, cumulative stats, lineage, and graveyard
- [ ] Transferred Pokemon appear as eggs (base form, level 1) in the next leg
- [ ] Pokemon lineage is trackable across multiple legs
- [ ] A cumulative graveyard shows all deaths across the entire genlocke
- [ ] The Retire HoF / Gauntlet rule correctly retires HoF Pokemon and adds their families to the dupe list

View File

@@ -1,24 +1,40 @@
---
# nuzlocke-tracker-8w9s
title: Gauntlet rule option for genlockes
status: draft
status: todo
type: feature
priority: normal
created_at: 2026-02-08T19:15:43Z
updated_at: 2026-02-08T19:15:43Z
updated_at: 2026-02-09T07:46:32Z
parent: nuzlocke-tracker-25mh
---
Add an optional **Gauntlet** rule for genlocke runs. When enabled, Pokemon that enter the Hall of Fame at the end of a leg are NOT transferred to the next game — instead, they (and their evolutionary families) are added to the dupe list for subsequent legs.
Add the **Retire HoF** (aka Gauntlet) rule as a genlocke-specific rule option. When enabled, Pokemon that enter the Hall of Fame at the end of a leg are NOT transferred to the next game — instead, they and their entire evolutionary families are added to a cumulative dupe list for all subsequent legs.
## Behavior
- Toggled as an optional rule when creating/editing a genlocke
- When a leg is completed, surviving Hall of Fame Pokemon are marked as "dupes" for the next leg rather than being transferred as eggs/starters
- This means the player cannot catch anything in those evolutionary lines in future legs (standard dupe clause enforcement)
- The cumulative dupe list grows with each completed leg
- Effectively forces the player to use entirely new Pokemon each generation
- Toggled as a genlocke-specific rule during genlocke creation (step 3 of the wizard)
- Mutually exclusive with "Keep HoF" — you pick one or the other
- When a leg is completed:
- Surviving HoF Pokemon are marked as "retired" rather than being available for transfer
- Their evolutionary families (full chain: e.g., Charmander/Charmeleon/Charizard) are added to a cumulative dupe list
- In subsequent legs, the duplicates clause treats these families as already caught/dead
- The cumulative dupe list grows with each completed leg, making later legs increasingly restrictive
- The genlocke overview page should display the cumulative retired/duped families
## Dependencies
- Requires the genlocke creation wizard (to set the rule)
- Requires the leg progression system (to trigger retirement on leg completion)
- Should integrate with the existing duplicates clause enforcement in the encounter system
## Notes
- This is a variant of the standard genlocke format that increases difficulty
- The dupe list should track evolutionary families, not just the specific Pokemon (e.g., if Charizard is in the HoF, Charmander and Charmeleon are also duped)
- Should integrate with the existing dupe clause system already in the tracker
- Consider showing the cumulative gauntlet dupe list somewhere in the genlocke dashboard
- This is a popular variant that increases difficulty by forcing entirely new Pokemon each generation
- The dupe list should be visible somewhere in the genlocke dashboard so the player knows which families are off-limits
## Checklist
- [ ] Add a `retireHoF` boolean (or equivalent) to the genlocke rules JSONB schema
- [ ] On leg completion with Retire HoF enabled: resolve the full evolutionary families of all surviving HoF Pokemon
- [ ] Store the cumulative retired families list (could be a JSONB field on the Genlocke, or derived from completed legs)
- [ ] Implement `GET /api/v1/genlockes/{id}/retired-families` — return the list of retired evolutionary families with which leg they were retired in
- [ ] Integrate with the encounter system's duplicates clause: when logging an encounter in a genlocke leg, check the cumulative retired list and flag duplicates
- [ ] Build a "Retired Families" display on the genlocke overview page showing all off-limits Pokemon with their sprites
- [ ] Ensure the creation wizard's genlocke rules step correctly toggles between Keep HoF and Retire HoF

View File

@@ -3,9 +3,12 @@
title: Gather generation metadata (games, regions)
status: todo
type: task
priority: normal
created_at: 2026-02-08T19:20:49Z
updated_at: 2026-02-08T19:20:49Z
updated_at: 2026-02-09T07:45:21Z
parent: nuzlocke-tracker-25mh
blocking:
- nuzlocke-tracker-kz5g
---
Collect and store metadata about each Pokemon generation to support genlocke features. This data is needed so the app can present generation-aware options when setting up a genlocke (e.g. "pick one game per generation").
@@ -22,4 +25,13 @@ Collect and store metadata about each Pokemon generation to support genlocke fea
- This could be stored as seed data (JSON) or as a database table
- The existing Game model already has `generation` and `region` fields, so some of this data may already be derivable from existing games in the DB
- However, a dedicated generations reference would be useful for UI purposes (showing all generations even if not all games are seeded yet)
- Check if `backend/src/app/seeds/data/generations.json` already exists or if this needs to be created from scratch
- Check if `backend/src/app/seeds/data/generations.json` already exists or if this needs to be created from scratch
## Checklist
- [ ] Define the generation-to-region mapping (Gen 1 = Kanto, Gen 2 = Johto, ..., Gen 9 = Paldea)
- [ ] Determine how to group games by region (use `region` field on existing Game model, or create a dedicated lookup)
- [ ] Create a `generations.json` seed file (or equivalent) with: generation number, region name, region order, and which games belong to each region
- [ ] Categorize each game as "original", "remake", or "enhanced" so presets can filter appropriately
- [ ] Define which game is the "default" pick per region for the Normal Genlocke preset (e.g., FireRed for Kanto, HeartGold for Johto)
- [ ] Add an API endpoint or extend the games endpoint to return games grouped by region with generation metadata
- [ ] Verify all seeded games are correctly tagged with their region

View File

@@ -0,0 +1,65 @@
---
# nuzlocke-tracker-kz5g
title: Genlocke creation wizard
status: todo
type: feature
priority: normal
created_at: 2026-02-09T07:42:10Z
updated_at: 2026-02-09T07:45:34Z
parent: nuzlocke-tracker-25mh
blocking:
- nuzlocke-tracker-x4p6
- nuzlocke-tracker-thbz
---
Multi-step wizard UI for creating a new genlocke. This is the entry point for the entire genlocke feature.
## Steps
### Step 1: Name
- User enters a name for the genlocke (e.g., "My First Genlocke")
### Step 2: Game Selection
- Offer preset templates:
- **True Genlocke** — slots for each region using original releases only
- **Normal Genlocke** — slots for each region using the latest remake/enhanced version as the default pick
- **Custom** — start with an empty list, add games freely
- For preset templates, show one slot per region (Kanto, Johto, Hoenn, Sinnoh, Unova, Kalos, Alola, Galar, Paldea). Each slot shows available games for that region and lets the user pick one.
- The user can add/remove/reorder legs after selecting a template.
- Games are grouped by region (FireRed is a "Kanto" option, not "Gen 3").
### Step 3: Rules
- **Nuzlocke rules** — standard rules configuration (reuse existing `RulesConfiguration` component). Set once, applied to all legs.
- **Genlocke rules** — Keep HoF (default) vs Retire HoF. Radio select.
### Step 4: Confirm & Start
- Summary of the genlocke: name, legs in order, rules.
- "Start Genlocke" button creates the Genlocke entity, all GenlockeLeg records, and auto-creates + starts the first NuzlockeRun.
## Backend
- `POST /api/v1/genlockes` — Create a genlocke with all legs and rules in one request. Should create the Genlocke, GenlockeLeg records, and the first NuzlockeRun.
- Needs the `Genlocke` and `GenlockeLeg` database models + migration.
## Frontend
- New route: `/genlockes/new`
- Multi-step form component with back/next navigation
- Reuse `GameCard`/`GameGrid` components for game selection
- Reuse `RulesConfiguration` for nuzlocke rules step
## Dependencies
- Needs generation/region metadata to power the preset templates (see nuzlocke-tracker-glh8)
## Checklist
- [ ] Create `Genlocke` SQLAlchemy model (name, status, genlocke_rules JSONB, nuzlocke_rules JSONB, created_at)
- [ ] Create `GenlockeLeg` SQLAlchemy model (genlocke_id FK, run_id FK nullable, leg_order, game_id FK)
- [ ] Create Alembic migration for both new tables
- [ ] Create Pydantic schemas for genlocke creation request/response
- [ ] Implement `POST /api/v1/genlockes` endpoint (creates genlocke, legs, and first run)
- [ ] Build the multi-step wizard shell component with back/next navigation and step indicator
- [ ] Build Step 1: Name input
- [ ] Build Step 2: Preset template selector (True / Normal / Custom) with region-grouped game picker
- [ ] Build Step 3: Rules configuration (reuse `RulesConfiguration` + genlocke rules radio)
- [ ] Build Step 4: Confirmation summary with "Start Genlocke" action
- [ ] Add `/genlockes/new` route to the React Router config
- [ ] Add TypeScript types for genlocke API responses
- [ ] Wire up the wizard to call the create endpoint and redirect to the genlocke overview on success

View File

@@ -0,0 +1,43 @@
---
# nuzlocke-tracker-lsc2
title: Genlocke lineage tracking
status: todo
type: feature
priority: normal
created_at: 2026-02-09T07:42:41Z
updated_at: 2026-02-09T07:46:15Z
parent: nuzlocke-tracker-25mh
---
Track and display a Pokemon's journey across multiple genlocke legs. When a Pokemon is transferred between legs, its lineage (history across legs) should be visible.
## Concept
A "lineage" is the chain of transfers for a Pokemon across legs. For example:
- Leg 1: Caught Charmander on Route 1 → evolved to Charizard → entered HoF → transferred
- Leg 2: Received Charmander egg → evolved to Charmeleon → died on Route 7
The lineage view connects these into one story, showing the Pokemon's journey through the entire genlocke.
## Display
- On the genlocke overview page, show a "Lineage" section or tab
- Each lineage entry shows:
- The Pokemon's name/nickname
- Which legs it appeared in
- Key events per leg (caught, evolved, entered HoF, transferred, died)
- Final status (still alive, died in leg X, retired via Gauntlet rule)
- Visual: a horizontal timeline per Pokemon showing its presence across legs
## Data
- Lineage is derived from `GenlockeTransfer` records — follow the chain of from_encounter → to_encounter across legs
- No additional database tables needed; this is a read-only view computed from existing transfer + encounter data
## Dependencies
- Requires Transfer UI to be implemented first (needs GenlockeTransfer records to exist)
## Checklist
- [ ] Implement `GET /api/v1/genlockes/{id}/lineages` — build lineage chains by walking GenlockeTransfer records from first leg to last, grouping encounters that share a transfer chain
- [ ] Each lineage entry should include: origin encounter, all subsequent transferred encounters, per-leg status (alive/fainted/transferred), current status (alive/dead/retired)
- [ ] Build the lineage display component: one row per lineage with a horizontal timeline across legs
- [ ] Show Pokemon sprite, nickname, and key events (caught, evolved, HoF, transferred, died) per leg
- [ ] Integrate the lineage view as a tab or section on the genlocke overview page
- [ ] Handle edge cases: Pokemon that were never transferred (single-leg only), broken chains if a leg was skipped

View File

@@ -0,0 +1,41 @@
---
# nuzlocke-tracker-lsdy
title: Genlocke cumulative graveyard
status: todo
type: feature
priority: normal
created_at: 2026-02-09T07:42:46Z
updated_at: 2026-02-09T07:46:22Z
parent: nuzlocke-tracker-25mh
---
Display all deaths across all legs of a genlocke in a single unified graveyard view.
## Display
- Accessible from the genlocke overview page
- Shows all fainted Pokemon from every leg in one list
- Each entry shows:
- Pokemon sprite, nickname, species
- Which leg/game it died in
- Death cause (if recorded)
- Level at death
- Whether it was a transferred Pokemon (part of a lineage) or caught fresh in that leg
- Sortable/filterable by leg, species, level, etc.
- Summary stats: total deaths, deaths per leg, deadliest leg
## Backend
- `GET /api/v1/genlockes/{id}/graveyard` — Return all fainted encounters across all legs of the genlocke
- Aggregates encounters with status "fainted" from all runs belonging to the genlocke's legs
## Frontend
- Could be a tab on the genlocke overview page or a separate sub-page (`/genlockes/:id/graveyard`)
- Reuse existing graveyard/encounter display components where possible
## Checklist
- [ ] Implement `GET /api/v1/genlockes/{id}/graveyard` — query all encounters with status "fainted" across all runs linked to the genlocke's legs, include leg/game context per entry
- [ ] Add summary stats to the response: total deaths, deaths per leg, deadliest leg
- [ ] Indicate whether each dead Pokemon was a transferred Pokemon or caught fresh (join with GenlockeTransfer)
- [ ] Build the cumulative graveyard component: list of dead Pokemon with sprite, nickname, species, leg/game, death cause, level
- [ ] Add sorting (by leg, level, species) and filtering (by leg/game)
- [ ] Integrate as a tab on the genlocke overview page or as a sub-route
- [ ] Reuse existing graveyard display components where applicable

View File

@@ -0,0 +1,58 @@
---
# nuzlocke-tracker-p74f
title: Genlocke transfer UI
status: todo
type: feature
priority: normal
created_at: 2026-02-09T07:42:33Z
updated_at: 2026-02-09T07:46:06Z
parent: nuzlocke-tracker-25mh
blocking:
- nuzlocke-tracker-lsc2
---
After completing a genlocke leg, the user selects which surviving Pokemon to carry forward to the next leg. Transferred Pokemon appear as egg encounters in the next run.
## Flow
### Transfer Step (between legs)
1. User completes a leg (beats the Champion / enters Hall of Fame)
2. A transfer screen is shown, displaying all surviving Pokemon from the completed leg
3. User selects which Pokemon to transfer (typically up to 6, the HoF team)
4. Selected Pokemon are "bred" — they'll appear as level 1 eggs/starters in the next leg
5. The transfer is recorded and the next leg's run is started
### Transfer Records
- Each transfer links a source encounter (from the completed leg) to a new egg encounter (in the next leg)
- The new encounter in the next leg should:
- Be the base form of the evolutionary line (e.g., Charizard → Charmander egg)
- Have a special status/flag indicating it's a genlocke transfer (not a wild encounter)
- Optionally keep the same nickname
- Not count against any route's first-encounter rule
### UI Components
- Transfer selection screen: grid of surviving Pokemon with checkboxes
- Show each Pokemon's sprite, nickname, species, and level
- "Transfer Selected" button to confirm
- Option to skip transferring (transfer none) for added challenge
## Backend
- `POST /api/v1/genlockes/{id}/legs/{leg_id}/transfer` — Accept list of encounter IDs to transfer
- Creates `GenlockeTransfer` records linking source encounters to new egg encounters
- Auto-creates the egg encounters in the next leg's run
## Data Model
- `GenlockeTransfer` table: from_leg_id, to_leg_id, from_encounter_id, to_encounter_id
- Egg encounters need a way to be distinguished from regular encounters (possibly a flag or encounter method)
## Checklist
- [ ] Create `GenlockeTransfer` SQLAlchemy model (from_leg_id, to_leg_id, from_encounter_id, to_encounter_id)
- [ ] Create Alembic migration for the GenlockeTransfer table
- [ ] Add logic to resolve a Pokemon's base form from its evolutionary chain (e.g., Charizard → Charmander)
- [ ] Implement `GET /api/v1/genlockes/{id}/legs/{leg_order}/survivors` — return surviving (non-fainted) encounters from a completed leg
- [ ] Implement `POST /api/v1/genlockes/{id}/legs/{leg_order}/transfer` — accept encounter IDs, create GenlockeTransfer records, create egg encounters in the next leg's run
- [ ] Build the transfer selection screen: grid of surviving Pokemon with checkboxes, sprites, nicknames, and levels
- [ ] Add a "Transfer Selected" confirmation action and a "Skip" option
- [ ] Wire up the transfer screen to appear after leg completion (integrate with leg progression flow)
- [ ] Ensure transferred egg encounters don't count against route first-encounter rules
- [ ] Add TypeScript types for transfer API request/response

View File

@@ -0,0 +1,56 @@
---
# nuzlocke-tracker-thbz
title: Genlocke leg progression
status: todo
type: feature
priority: normal
created_at: 2026-02-09T07:42:33Z
updated_at: 2026-02-09T07:45:55Z
parent: nuzlocke-tracker-25mh
blocking:
- nuzlocke-tracker-p74f
- nuzlocke-tracker-8w9s
---
Handle the sequential progression of legs within a genlocke. When one leg is completed, the next leg should be started (with a transfer step in between).
## Behavior
### Leg Completion
- When a nuzlocke run that belongs to a genlocke is marked as **completed**:
1. The leg is marked as completed
2. If there is a next leg, trigger the **transfer step** (see Transfer UI feature)
3. After the transfer step, auto-create and start the next leg's NuzlockeRun
4. If this was the final leg, mark the entire genlocke as **completed**
### Leg Failure
- When a nuzlocke run that belongs to a genlocke is marked as **failed** (total party wipe):
- The genlocke itself is marked as **failed**
- No further legs are started
- The overview page reflects the failure
### Run Status Integration
- The existing run completion/failure flow needs to check if the run belongs to a genlocke
- If it does, trigger the genlocke-specific progression logic
- The run page should show context about which genlocke/leg this run belongs to (e.g., "Leg 3 of My Genlocke")
## Backend
- Extend run status update endpoint to trigger genlocke progression when applicable
- `POST /api/v1/genlockes/{id}/legs/{leg_id}/advance` — or handle automatically when run status changes
- Need to track genlocke status: active (a leg is in progress), completed (all legs done), failed (a leg was failed)
## Frontend
- When completing a run that belongs to a genlocke, show a genlocke-aware completion modal instead of the standard one
- Show "Leg X of Y" context on the run page header when the run is part of a genlocke
- After completion, redirect to the transfer step (or to the genlocke overview if it was the final leg)
## Checklist
- [ ] Add backend logic to detect when a completed/failed run belongs to a genlocke (query GenlockeLeg by run_id)
- [ ] On run completion: update GenlockeLeg status, determine if there's a next leg
- [ ] On run failure: mark the genlocke as failed, prevent further leg creation
- [ ] On final leg completion: mark the genlocke as completed
- [ ] Implement `POST /api/v1/genlockes/{id}/legs/{leg_order}/advance` endpoint to create the next leg's run
- [ ] Add genlocke context to the run detail API response (genlocke name, leg number, total legs) when the run belongs to a genlocke
- [ ] Update the frontend run page header to show "Leg X of Y — {Genlocke Name}" when applicable
- [ ] Update the run completion flow on the frontend to detect genlocke membership and redirect to transfer step instead of the standard completion screen
- [ ] Handle edge case: what happens if a genlocke run is manually deleted?

View File

@@ -0,0 +1,59 @@
---
# nuzlocke-tracker-x4p6
title: Genlocke overview page
status: todo
type: feature
priority: normal
created_at: 2026-02-09T07:42:19Z
updated_at: 2026-02-09T07:45:45Z
parent: nuzlocke-tracker-25mh
---
A dedicated dashboard page for a genlocke, showing progress, configuration, and cumulative stats across all legs.
## Page Layout
### Progress Section
- Visual timeline or step indicator showing all legs in order
- Each leg shows: game icon/color, game name, leg status (upcoming / active / completed / failed)
- The active leg is highlighted and links to its run page
- Completed legs show key stats (encounters, deaths, HoF team)
### Configuration Section
- Display the selected genlocke rules (Keep HoF / Retire HoF)
- Display the nuzlocke rules applied to all legs
- List of all games in leg order
### Cumulative Stats Section
- Total encounters across all legs
- Total deaths across all legs
- Total unique Pokemon caught
- Current surviving team count
- Legs completed / total legs
### Quick Actions
- Link to active leg's run page
- Link to genlocke-wide graveyard (if implemented)
- Link to lineage view (if implemented)
## Backend
- `GET /api/v1/genlockes` — List all genlockes (for a genlocke list page)
- `GET /api/v1/genlockes/{id}` — Get genlocke with legs, runs, and aggregated stats
## Frontend
- New route: `/genlockes/:genlockeId`
- Also need a genlocke list page at `/genlockes` (or integrate into the existing runs list)
- Consider adding a "Genlockes" nav item alongside "Runs"
## Checklist
- [ ] Implement `GET /api/v1/genlockes` endpoint (list all genlockes with basic info and leg count)
- [ ] Implement `GET /api/v1/genlockes/{id}` endpoint (full genlocke with legs, runs, and aggregated stats)
- [ ] Add TypeScript types for genlocke detail/list API responses
- [ ] Build the genlocke list page at `/genlockes` showing all genlockes with status and progress
- [ ] Build the genlocke detail page at `/genlockes/:genlockeId`
- [ ] Build the progress section: visual leg timeline with game colors, statuses, and links to runs
- [ ] Build the configuration section: display genlocke rules and nuzlocke rules
- [ ] Build the cumulative stats section: aggregate encounters, deaths, and completions across legs
- [ ] Add quick action links (active leg, graveyard, lineage — placeholder links for unimplemented features)
- [ ] Add "Genlockes" navigation item to the app nav bar
- [ ] Add `/genlockes` and `/genlockes/:genlockeId` routes to the React Router config