nuzlocke-tracker/.beans/nuzlocke-tracker-thbz--genlocke-leg-progression.md

title, status, type, priority, created_at, updated_at, parent, blocking

title	status	type	priority	created_at	updated_at	parent	blocking
Genlocke leg progression	in-progress	feature	normal	2026-02-09T07:42:33Z	2026-02-09T08:42:15Z	nuzlocke-tracker-25mh	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?