Используйте следующий план для реализации задачи.

КРИТИЧЕСКОЕ КОНТЕКСТ — РЕАЛИЗАЦИЯ ЛЛМ:
Все этапы будут реализованы LLM, который генерирует код в одном проходе. Это означает, что LLM может уместно сгенерировать 500-1500 строк коherent code в одном проходе.
Квалитет не ухудшается из-за объема, а из-за смешения разных задач в один этап. Каждый новый этап имеет значительный затрат: LLM должен повторно прочитать спецификацию, план, конституцию, архитектуру и все предыдущие AI_NOTES. Меньше этапов = меньше потерь контекста.
НЕ РАСДЕЛЬТИ ВАЖКИ ЕЩЕ НА МАЛЫЕ ЭТАПЫ СТРОК 50-100. Это неэффективно.

ГRANNYE ГРАНИЦЫ — группируйте по логаческой целостности, а не по размеру:
- Один этап = один логически полный единиц (модуль, слой, вертикальная среза, API группа).
- Этап МУСТ ОБЕСПЕЧИТЬ ЧЕГО-ЛИБО ТЕСТИРОВАНОЕ ИЛИ ПОДВЕРЖДИМОЕ.
- Преференция: меньше, крупные этапы над многими маленькими.
- Только разделяйте, когда есть настоящая зависимость: этап B не может начаться без выхода этапа A.
- Обычное задание должно иметь 2-5 этапов, а не 8-15.

ВАЖНО — СТРУКТУРА ПРОЕКТА:
Если проект еще не имеет структуру каталогов, то первый этап МUST БЫТЬ "Проектная Структура Установка": создание каталогов, входов, конфигурационных файлов и пустых модулей по документу архитектуры.
Все последующие этапы МUST ССЫЛАТЬСЯ НА ФАЙЛЫ с полными относительными путями от корня проекта (например, `src/game/collision.py`, А НЕ `collision.py`).
Файлы в плане МUST СОВПАДАТЬ С ДОКУМЕНТОМ ARCHITECTURE.

Правила:
1. Разделите на этапы согласно принципу целостности выше.
2. Для каждого этапа укажите:
   - **Цель**: что этот этап достигает
   - **Входные данные**: что нужно для работы
   - **Выходные данные**: что будет создано/изменено (полные пути!)
   - **DoD**: определение готовности — конкретный список
   - **Risks**: что может пойти не так
3. Укажите зависимости между этапами явно.
4. Маркируйте этапы, которые можно параллельно выполнять.
5. Проверьте, что план НЕ нарушает инварианты архитектуры.
6. Проверьте, что план соответствует конституции.

Не добавляйте этапы, не описанные в спецификации. Не переинженеруйте.
НЕ СОЗДАВАЙТЕ ЭТАПЫ С МЕНЬШИМИ НЕЖЕ 3 ФАЙЛАМИ, ЕСЛИ НЕТ СТРОГОГО ПОЛАЗА.

ВЕРИФИКАЦИОННЫЕ КОМАНДЫ — ОБЯЗАТЕЛЬНО:
На конце плана (после всех этапов) добавьте `## Verify` секцию с командами, которые будут выполнены автоматически после реализации для проверки правильности.

КРИТИЧЕСКО: Команды МUST БЫТЬ совместимы с ОС и оболочкой, указанными в документе ENVIRONMENT секции системного приглашения. Не используйте Unix-команды на Windows или наоборот. Например, на Windows/PowerShell используйте `python -m pytest` вместо `pytest`, используйте точки вместо `&&`, и избегайте Unix-только инструментов, таких как `grep`, `sed`, `awk`.
Корректные команды проверки: запуск тестов для конкретных файлов, типизацию конкретных модулей, линтинг.
Некорректные команды проверки: общие "pytest" без пути, "npm test", когда задача касается только одного модуля.
Если задача не производит тестируемый выходной (например, документация только), Вы можете опустить эту секцию.