42 lines
5.2 KiB
Markdown
42 lines
5.2 KiB
Markdown
Используйте следующий план для реализации задачи.
|
||
|
||
КРИТИЧЕСКОЕ КОНТЕКСТ — РЕАЛИЗАЦИЯ ЛЛМ:
|
||
Все этапы будут реализованы 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", когда задача касается только одного модуля.
|
||
Если задача не производит тестируемый выходной (например, документация только), Вы можете опустить эту секцию. |