MOTIR-1492Done
Sprint ⋯ actions menu is disabled — enable it + wire Delete (backend DELETE /api/sprints/[id] already exists)
Verified against shipped motir-core (local HEAD 42725b51; the single commit behind origin/main touches only AI-telemetry files, so the sprint code is identical). A bug report is a rung-3 claim — this is the rung-2 check.
Reality: backend COMPLETE, the UI affordance is the only gap
sprintsService.deleteSprint()(lib/services/sprintsService.ts:246) works, status-gated: planned + complete are deletable; active throwsCannotDeleteActiveSprintError(:250). On delete, items are NOT lost —work_item.sprint_idisonDelete: SetNull, so they fall back to the backlog inbacklogRankorder (lib/repositories/sprintRepository.ts:198).- Endpoint
DELETE /api/sprints/[id](app/api/sprints/[id]/route.ts:118) + MCPdelete_sprintboth exist. - The gap: the sprint header
⋯menu is hard-disabled —app/(authed)/backlog/_components/SprintContainer.tsx:198-206(disabled,title={t('sprintActionsComingSoon')}). No component issues aDELETE. So a user can't delete a backlog sprint from the UI (only via API/MCP).
This card = enable the ⋯ menu (shared) + Delete
Enable the sprint ⋯ actions menu and wire Delete → the existing DELETE /api/sprints/[id], behind a confirm (reuse the shipped Modal), offered for planned/complete, hidden/disabled for active. Items return to the backlog automatically. This card owns enabling the menu; the sibling actions (MOTIR-1493 rename, MOTIR-1494 edit-dates) build on it (blocked_by this).
Acceptance criteria
- The
⋯menu is enabled on planned/complete sprints and offers Delete →DELETE /api/sprints/[id]after a confirm; items fall back to the backlog; not offered for active. - E2E: backlog sprint with items → delete → sprint gone, items in backlog.
Context refs
- Service
lib/services/sprintsService.ts:246; repolib/repositories/sprintRepository.ts:198; routeapp/api/sprints/[id]/route.ts:118; disabled menuapp/(authed)/backlog/_components/SprintContainer.tsx:198.