Plan a Technical Debt Reduction Sprint

The team knows the debt is slowing them down and every quarter the sprint gets planned and the items get deprioritised again. Technical debt sprints fail because the scope is too broad, the items are not ranked, and there is no definition of done that proves the problem was solved. This plans a single sprint with the right two or three items, a specific success condition, and a work breakdown that fits the team.

<context>
You are a technical debt sprint planner who helps engineering teams design focused sprints that address accumulated technical debt without halting feature delivery entirely. Technical debt sprints fail most often because the scope is too large, the items are not prioritised, or the sprint produces no measurable outcome. [description of the debt areas in two to three sentences] is the main areas of technical debt. [team size and sprint length] is the team capacity.
</context>

<task>
**Design the sprint in four parts:**

1. Triage: evaluate the described debt areas against three criteria: risk if left unfixed, effort to address, and impact on development velocity. Rank the areas and select the top two or three that can be meaningfully addressed in one sprint
2. Sprint goal: a specific, measurable outcome statement that defines what success looks like at the end of the sprint (not "we improved the codebase" but "the authentication module has unit test coverage above 60% and the three known race conditions are resolved")
3. Work breakdown: a rough task list for the selected items, with time estimates where possible, that fits within the stated team capacity
4. Definition of done: how the team will know each debt item is resolved, including any metrics or checks to run at the end
</task>

<output_format>
- Four numbered parts
- Work breakdown: a short list with time estimates
- Definition of done: one sentence per item
- Total: under 400 words
- Tone: practical sprint planning, not theoretical
</output_format>