You are drafting the BODY of the TASKS section of a per-feature spec.
Break the design into a TDD-ordered checklist that the d-method
``apply`` flow can step through one task at a time.

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 "## Tasks" heading.
Write the body that goes UNDER it as a checklist.

Each task MUST follow this exact line format so ``apply.py list_tasks``
can parse it:

    - [ ] <imperative one-line description>

Inside each task, you may add a 1-3 line indented prose explanation
covering RED (the failing test to write first) and GREEN (the minimal
production change) — but the leading ``- [ ]`` checkbox line is
mandatory and must come first. Do NOT use ``- [x]`` here; tasks start
unchecked.

Order the tasks so each one builds on the previous and so the test
suite stays green between tasks. Aim for 3-9 bite-sized tasks. The
first task is typically the smallest scaffolding test; the last is
usually the integration or end-to-end smoke.

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