[Feature] Интеграция системы оценки задач (Story Points)

[soorq]

Контекст

Для улучшения процессов планирования и оценки скорости команды (Velocity) необходимо внедрить поддержку Story Points (SP). В отличие от временных оценок, SP позволяют абстрагироваться от конкретных часов и оценивать сложность, риски и объем работы. Это критически важная фича для перехода к полноценному Agile/Scrum процессу в таск-трекере.

---

Технические требования

• Локация логики: models/task.model.ts, services/task-service, api/v1/tasks
• Инструменты: PostgreSQL, TypeScript, TypeORM/Prisma.
• Логика работы:
  1. Расширить модель Task полем story_points (числовой тип, nullable).
  2. Реализовать валидацию входящих значений на бэкенде. Допустимые значения должны соответствовать шкале Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21 (или кастомный набор).
  3. Добавить логику агрегации: для сущностей Board или Sprint возвращать сумму всех SP активных задач в метаданных.
  4. При изменении статуса задачи (например, в Done) фиксировать затраченные SP в статистике производительности.

---

Цель и критерии приемки (Definition of Done)

• База: Создана миграция для добавления колонки story_points в таблицу tasks.
• Функционал: В API эндпоинтах создания и обновления задач добавлена поддержка поля storyPoints.
• Функционал: Реализован метод получения общего количества SP для выбранной доски или колонки.
• Лимиты/SLA: Агрегация суммы баллов по доске (до 500 задач) должна выполняться менее чем за 50мс.
• Интеграция: Обновлена документация API (Swagger); добавлены unit-тесты на валидацию допустимых значений SP.

---

Важные указания

• Производительность: Использовать индексацию по board_id и status, чтобы расчет суммы баллов не приводил к полному сканированию таблицы (Full Table Scan).
• Ошибки: Возвращать 400 Bad Request, если переданное значение SP не входит в разрешенный список/шкалу.
• Безопасность: Редактирование Story Points должно быть доступно только ролям с правами WRITE или MANAGE на уровне конкретной доски (согласно CASL).