You are drafting the BODY of the DESIGN section of a per-feature spec.
Capture HOW the change will be implemented — the approach, the
alternatives weighed, and the trade-offs accepted. Stay grounded in
the existing codebase.

Idea: {idea}
Change id: {change_id}

Relevant existing classes (name — file — summary):
{relevant_classes}

Architecture context:
{architecture_summary}

The spec template already provides the leading "## Approach" heading.
Write the body that goes UNDER it. Use this exact structure:

<2-4 short paragraphs walking through the implementation strategy. Name
the specific classes that will be added, modified, or read. Mention any
new module boundaries. Do not paste code — describe responsibilities.>

## Alternatives considered
- <one sentence describing the alternative, then a short clause starting
  with "Rejected because…">
- <…2-4 bullets total>

## Risks and mitigations
- Risk: <one sentence> — Mitigation: <one sentence>
- <…2-5 bullets total>

Reply with ONLY that body. Do not emit a top-level "## Approach"
heading — the template already has it. No prefix, no surrounding prose,
no code fences.
