Add drag-and-drop boss reordering and new feature beans
Adds boss battle reorder API endpoint with two-phase order update to avoid unique constraint violations. Includes frontend mutation hook and API client. Also adds draft beans for progression dividers and conditional boss battle teams features. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,31 @@
|
||||
---
|
||||
# nuzlocke-tracker-x8ol
|
||||
title: Conditional boss battle teams
|
||||
status: draft
|
||||
type: feature
|
||||
priority: normal
|
||||
created_at: 2026-02-08T13:23:00Z
|
||||
updated_at: 2026-02-08T13:29:26Z
|
||||
---
|
||||
|
||||
Some boss battles have teams that vary based on conditions in the player's run. The most common case is starter choice (e.g., Blue's team in Gen 1 depends on whether you picked Bulbasaur, Charmander, or Squirtle), but other conditions exist too — in Pokemon Yellow, the rival's team changes based on the outcomes of two early-game fights, not the starter. This feature adds support for defining multiple team variants per boss battle, each associated with a named condition.
|
||||
|
||||
## Context
|
||||
|
||||
Currently each boss battle has a single fixed team (`boss_pokemon` table). This doesn't account for games where the rival/champion adapts their team based on player decisions or battle outcomes. To accurately model these encounters, boss battles need to support variant teams keyed by a general condition system — not just starter choice.
|
||||
|
||||
## Scope
|
||||
|
||||
- **Variant conditions**: Support a general condition system for team variants. Starter choice is the most common condition, but the design must also handle arbitrary conditions (e.g., "won/lost early rival fight" in Yellow). Each variant should have a human-readable label describing the condition.
|
||||
- **Admin side**: Allow defining multiple team variants per boss battle, each with a condition label and a team composition
|
||||
- **Run side**: When viewing a boss battle during a run, allow the player to select which variant applies (or auto-resolve when possible, e.g., from the run's recorded starter)
|
||||
- **Fallback**: If no variant teams are defined, the boss uses the existing single team as today
|
||||
|
||||
## Checklist
|
||||
|
||||
- [ ] Design database schema for conditional team variants (e.g., a `boss_team_variant` table grouping pokemon by a condition label, rather than tying directly to starter)
|
||||
- [ ] Add backend models and migrations
|
||||
- [ ] Add API endpoints for managing team variants per boss battle
|
||||
- [ ] Update admin UI (BossTeamEditor) to support defining teams per condition/variant
|
||||
- [ ] Update run-side boss display to let the player pick or auto-resolve the correct variant
|
||||
- [ ] Handle edge cases: boss battles with no variants (use default team), unknown conditions
|
||||
Reference in New Issue
Block a user