Speckit.tasks

## Ввод пользователя

```text
$ARGUMENTS
```

Вы **ДОЛЖНЫ** учесть ввод пользователя перед продолжением (если он не пустой).

## Структура

1. **Настройка**: Запустите `.specify/scripts/bash/check-prerequisites.sh --json` из корня репозитория и разберите FEATURE_DIR и список AVAILABLE_DOCS. Все пути должны быть абсолютными. Для одинарных кавычек в аргументах типа "I'm Groot" используйте синтаксис экранирования: например 'I'\''m Groot' (или двойные кавычки, если возможно: "I'm Groot").

2. **Загрузите документы проектирования**: Прочитайте из FEATURE_DIR:
   - **Обязательные**: plan.md (технологический стек, библиотеки, структура), spec.md (пользовательские истории с приоритетами)
   - **Необязательные**: data-model.md (сущности), contracts/ (API endpoints), research.md (решения), quickstart.md (тестовые сценарии)
   - Примечание: Не все проекты имеют все документы. Генерируйте задачи на основе того, что доступно.

3. **Выполните процесс генерации задач**:
   - Загрузите plan.md и извлеките технологический стек, библиотеки, структуру проекта
   - Загрузите spec.md и извлеките пользовательские истории с их приоритетами (P1, P2, P3 и т.д.)
   - Если существует data-model.md: Извлеките сущности и сопоставьте их с пользовательскими историями
   - Если существует contracts/: Сопоставьте endpoints с пользовательскими историями
   - Если существует research.md: Извлеките решения для задач настройки
   - Сгенерируйте задачи, организованные по пользовательским историям (см. Правила генерации задач ниже)
   - Сгенерируйте граф зависимостей, показывающий порядок завершения пользовательских историй
   - Создайте примеры параллельного выполнения для каждой пользовательской истории
   - Проверьте полноту задач (каждая пользовательская история имеет все необходимые задачи, независимо тестируемые)

4. **Сгенерируйте tasks.md**: Используйте `.specify.specify/templates/tasks-template.md` как структуру, заполните:
   - Правильное имя функции из plan.md
   - Фаза 1: Задачи настройки (инициализация проекта)
   - Фаза 2: Основополагающие задачи (блокирующие предварительные условия для всех пользовательских историй)
   - Фаза 3+: Одна фаза для каждой пользовательской истории (в порядке приоритета из spec.md)
   - Каждая фаза включает: цель истории, критерии независимого тестирования, тесты (если запрошены), задачи реализации
   - Финальная фаза: Доработка и сквозные вопросы
   - Все задачи должны следовать строгому формату чеклиста (см. Правила генерации задач ниже)
   - Четкие пути к файлам для каждой задачи
   - Раздел зависимостей, показывающий порядок завершения историй
   - Примеры параллельного выполнения для каждой истории
   - Раздел стратегии реализации (сначала MVP, постепенная поставка)

5. **Отчет**: Выведите путь к сгенерированному tasks.md и сводку:
   - Общее количество задач
   - Количество задач для каждой пользовательской истории
   - Выявленные возможности параллельного выполнения
   - Критерии независимого тестирования для каждой истории
   - Предлагаемая область MVP (обычно только пользовательская история 1)
   - Валидация формата: Подтвердите, что ВСЕ задачи следуют формату чеклиста (чекбокс, ID, метки, пути к файлам)

Контекст для генерации задач: $ARGUMENTS

tasks.md должен быть немедленно исполняемым - каждая задача должна быть достаточно конкретной, чтобы LLM мог выполнить ее без дополнительного контекста.

## Правила генерации задач

**КРИТИЧНО**: Задачи ДОЛЖНЫ быть организованы по пользовательским историям, чтобы обеспечить независимую реализацию и тестирование.

**Тесты НЕОБЯЗАТЕЛЬНЫ**: Генерируйте тестовые задачи только если явно запрошено в спецификации функции или если пользователь запрашивает подход TDD.

### Формат чеклиста (ОБЯЗАТЕЛЬНО)

Каждая задача ДОЛЖНА строго следовать этому формату:

```text
- [ ] [TaskID] [P?] [Story?] Описание с путем к файлу
```

**Компоненты формата**:

1. **Чекбокс**: ВСЕГДА начинайте с `- [ ]` (markdown чекбокс)
2. **ID задачи**: Порядковый номер (T001, T002, T003...) в порядке выполнения
3. **Маркер [P]**: Включайте ТОЛЬКО если задача параллелизуема (разные файлы, нет зависимостей от незавершенных задач)
4. **Метка [Story]**: ОБЯЗАТЕЛЬНА только для задач фазы пользовательских историй
   - Формат: [US1], [US2], [US3] и т.д. (соответствует пользовательским историям из spec.md)
   - Фаза настройки: БЕЗ метки истории
   - Основополагающая фаза: БЕЗ метки истории
   - Фазы пользовательских историй: ДОЛЖНА быть метка истории
   - Фаза доработки: БЕЗ метки истории
5. **Описание**: Четкое действие с точным путем к файлу

**Примеры**:

- ✅ ПРАВИЛЬНО: `- [ ] T001 Создать структуру проекта согласно плану реализации`
- ✅ ПРАВИЛЬНО: `- [ ] T005 [P] Реализовать middleware аутентификации в src/middleware/auth.py`
- ✅ ПРАВИЛЬНО: `- [ ] T012 [P] [US1] Создать модель User в src/models/user.py`
- ✅ ПРАВИЛЬНО: `- [ ] T014 [US1] Реализовать UserService в src/services/user_service.py`
- ❌ НЕПРАВИЛЬНО: `- [ ] Создать модель User` (отсутствует ID и метка Story)
- ❌ НЕПРАВИЛЬНО: `T001 [US1] Создать модель` (отсутствует чекбокс)
- ❌ НЕПРАВИЛЬНО: `- [ ] [US1] Создать модель User` (отсутствует ID задачи)
- ❌ НЕПРАВИЛЬНО: `- [ ] T001 [US1] Создать модель` (отсутствует путь к файлу)

### Организация задач

1. **Из пользовательских историй (spec.md)** - ОСНОВНАЯ ОРГАНИЗАЦИЯ:
   - Каждая пользовательская история (P1, P2, P3...) получает свою собственную фазу
   - Сопоставьте все связанные компоненты с их историей:
     - Модели, необходимые для этой истории
     - Сервисы, необходимые для этой истории
     - Endpoints/UI, необходимые для этой истории
     - Если запрошены тесты: Тесты, специфичные для этой истории
   - Отметьте зависимости историй (большинство историй должны быть независимыми)

2. **Из контрактов**:
   - Сопоставьте каждый контракт/endpoint → с пользовательской историей, которую он обслуживает
   - Если запрошены тесты: Каждый контракт → задача контрактного теста [P] перед реализацией в фазе этой истории

3. **Из модели данных**:
   - Сопоставьте каждую сущность с пользовательской историей(ями), которой она нужна
   - Если сущность обслуживает несколько историй: Поместите в самую раннюю историю или в фазу настройки
   - Отношения → задачи слоя сервисов в соответствующей фазе истории

4. **Из настройки/инфраструктуры**:
   - Общая инфраструктура → Фаза настройки (Фаза 1)
   - Основополагающие/блокирующие задачи → Основополагающая фаза (Фаза 2)
   - Настройка, специфичная для истории → внутри фазы этой истории

### Структура фаз

- **Фаза 1**: Настройка (инициализация проекта)
- **Фаза 2**: Основополагающая (блокирующие предварительные условия - ДОЛЖНЫ быть завершены перед пользовательскими историями)
- **Фаза 3+**: Пользовательские истории в порядке приоритета (P1, P2, P3...)
  - Внутри каждой истории: Тесты (если запрошены) → Модели → Сервисы → Endpoints → Интеграция
  - Каждая фаза должна быть полным, независимо тестируемым инкрементом
- **Финальная фаза**: Доработка и сквозные вопросы