5.2 KiB
Используйте следующий план для реализации задачи.
КРИТИЧЕСКОЕ КОНТЕКСТ — РЕАЛИЗАЦИЯ ЛЛМ: Все этапы будут реализованы 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.
Правила:
- Разделите на этапы согласно принципу целостности выше.
- Для каждого этапа укажите:
- Цель: что этот этап достигает
- Входные данные: что нужно для работы
- Выходные данные: что будет создано/изменено (полные пути!)
- DoD: определение готовности — конкретный список
- Risks: что может пойти не так
- Укажите зависимости между этапами явно.
- Маркируйте этапы, которые можно параллельно выполнять.
- Проверьте, что план НЕ нарушает инварианты архитектуры.
- Проверьте, что план соответствует конституции.
Не добавляйте этапы, не описанные в спецификации. Не переинженеруйте. НЕ СОЗДАВАЙТЕ ЭТАПЫ С МЕНЬШИМИ НЕЖЕ 3 ФАЙЛАМИ, ЕСЛИ НЕТ СТРОГОГО ПОЛАЗА.
ВЕРИФИКАЦИОННЫЕ КОМАНДЫ — ОБЯЗАТЕЛЬНО:
На конце плана (после всех этапов) добавьте ## Verify секцию с командами, которые будут выполнены автоматически после реализации для проверки правильности.
КРИТИЧЕСКО: Команды МUST БЫТЬ совместимы с ОС и оболочкой, указанными в документе ENVIRONMENT секции системного приглашения. Не используйте Unix-команды на Windows или наоборот. Например, на Windows/PowerShell используйте python -m pytest вместо pytest, используйте точки вместо &&, и избегайте Unix-только инструментов, таких как grep, sed, awk.
Корректные команды проверки: запуск тестов для конкретных файлов, типизацию конкретных модулей, линтинг.
Некорректные команды проверки: общие "pytest" без пути, "npm test", когда задача касается только одного модуля.
Если задача не производит тестируемый выходной (например, документация только), Вы можете опустить эту секцию.