3a1aedda32
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>
56 lines
2.8 KiB
Markdown
56 lines
2.8 KiB
Markdown
---
|
|
# 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? |