[Feature] Реализация модуля задач (Tasks Module) #66

Контекст

После внедрения функционала досок необходимо реализовать основной модуль системы — задачи. Модуль задач является центральной единицей данных, вокруг которой строится взаимодействие пользователя с системой. Это требует создания масштабируемой структуры, поддерживающей связь с досками, учет сложности (Story Points), статусы выполнения и метаданные исполнителей.

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

• Локация логики: src/tasks, api/v1/tasks
• Инструменты: PostgreSQL, бибилиотека валидации (Zod/Class-validator).
• Логика работы:
  1. Создать сущность Task со связью "многие к одному" (ManyToOne) к сущности Board.
  2. Реализовать поле status, поддерживающее кастомные состояния (по умолчанию: BACKLOG, IN_PROGRESS, DONE).
  3. Добавить поддержку полей: title (string), description (text), priority (enum), due_date (timestamp).
  4. Интегрировать созданную ранее ролевую модель CASL для проверки прав на создание задач внутри конкретной доски.

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

• База: Разработана миграция для таблицы tasks с внешним ключом board_id и индексами по статусу и приоритету.
• Функционал: Реализован CRUD API: GET /tasks (с фильтрацией по board_id), POST /tasks, PATCH /tasks/{id}, DELETE /tasks/{id}.
• Лимиты/SLA: Время выполнения запроса на создание задачи не должно превышать 150мс (включая валидацию прав).
• Интеграция: Модуль подключен к общей системе логирования Loki и экспортирует события создания/изменения статуса.

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

• Производительность: Реализовать поддержку пагинации (Limit/Offset или Cursor-based) для эндпоинта получения списка задач, чтобы избежать деградации производительности на больших досках.
• Ошибки: Выбрасывать 400 Bad Request при попытке привязать задачу к несуществующей доске и 403 Forbidden при отсутствии прав доступа к родительской доске.
• Безопасность: Обеспечить атомарность операций через транзакции СУБД, особенно при смене статусов, влияющих на агрегированные показатели доски.