Files
agents/docs/agent/TASKS.md
T
2026-10-01 00:11:34 +07:00

124 lines
10 KiB
Markdown

# Задачи проекта
Единый список задач для разработки и работы агента.
Это единственный источник истины по задачам. Новые задачи добавляются сюда сразу;
отдельный файл-план для нетривиальной задачи не создаётся.
## Формат задачи
Каждая активная задача содержит:
- цель и ожидаемый результат;
- критерии готовности;
- проверку и ручной smoke-сценарий, если он нужен;
- ограничения и явно исключённые из задачи изменения;
- следующий конкретный шаг.
## Статусы
- `TODO` — готово к работе.
- `IN_PROGRESS` — выполняется.
- `BLOCKED` — заблокировано, причина указана в задаче.
- `DONE` — завершено и проверено.
## Активные задачи
### ED-001 — Исправить `actions_count` в `GetGameAnswers`
- Статус: `TODO`
- Приоритет: `P2`
- Репозиторий: `evening_detective_server`
- Цель: показывать реальное количество ходов команды в панели оценки игры.
- Проблема: `GetGameAnswers` строит команды без `actions_count`, поэтому в панели оценки показывается `0`.
- Решение: получить количество действий через `actionsRepo.GetActionsCountByTeamIDs` по тому же паттерну, что используется в `GetFullGame`.
- Следующий шаг: проверить всех callers `GetGameAnswers` и реализовать общий для этого пути расчёт.
- Критерии: количество ходов совпадает с результатами игры; добавлен тест на сервисный путь.
- Ограничения: не менять контракт API и не дублировать подсчёт в каждом caller.
- Не входит: исправление других расхождений панели оценки.
- Проверка: `cd evening_detective_server && go test ./...`
- Ручная проверка: открыть панель оценки завершённой игры и сравнить число ходов с результатами игры.
### ED-002 — Rate-limit публичной регистрации команды
- Статус: `TODO`
- Приоритет: `P1`
- Репозиторий: `evening_detective_server`
- Цель: ограничить спам-регистрации и расход SMTP-квоты.
- Контекст: публичный `POST /api/games/{id}/registrations` не требует авторизации и вызывает отправку email.
- Решение: ограничить регистрации как минимум по `(IP, game)`, а повторную отправку — по email; лимиты должны быть согласованы до реализации.
- Следующий шаг: определить лимиты и выбрать место хранения счётчика без зависимости от production-базы.
- Критерии: превышение лимита отклоняется предсказуемой ошибкой; нормальная регистрация не ломается; есть тесты на границы лимита.
- Ограничения: не добавлять внешнюю инфраструктуру без необходимости; не блокировать легитимные регистрации организатора.
- Не входит: полноценная CAPTCHA и общая защита всех публичных endpoint.
- Проверка: `cd evening_detective_server && go test ./...`
- Ручная проверка: отправить несколько регистраций с одного IP и проверить ответ после достижения лимита.
### ED-003 — Очистка персональных данных регистраций
- Статус: `TODO`
- Приоритет: `P1`
- Репозиторий: `evening_detective_server`
- Цель: удалять персональные данные завершённых игр по утверждённому сроку хранения.
- Контекст: `contact_email` и связанные данные регистрации остаются в БД после завершения игры.
- Решение: очищать персональные поля команд завершённых игр, сохраняя данные, нужные для итогов; удалять истёкшие confirmation-токены.
- Следующий шаг: утвердить срок хранения и точный список полей, затем спроектировать job.
- Критерии: срок хранения зафиксирован в политике; job идемпотентен; игровые итоги не ломаются; есть тест на очистку.
- Ограничения: не удалять команды и данные, необходимые для итоговой таблицы; не запускать очистку без утверждённого срока хранения.
- Не входит: изменение всей политики хранения данных приложения.
- Проверка: `cd evening_detective_server && go test ./...`
- Ручная проверка: проверить завершённую игру после запуска job и убедиться, что итоги доступны без персональных полей.
### ED-004 — Просмотр графа сценария
- Статус: `TODO`
- Приоритет: `P2`
- Репозиторий: `evening_detective_frontend`
- Цель: показывать граф переходов сценария в редакторе.
- Решения: граф открывается из редактора в полноэкранной модалке; узлы — вступление, точки и вопросы; двери и текстовые маркеры — рёбра; `[Код]` и `([Код])` равнозначны.
- Реализация: чистый построитель графа, иерархическая раскладка сверху вниз, динамический импорт `vis-network`, подсветка связей выбранного узла.
- Следующий шаг: сверить актуальное состояние редактора и реализовать построитель, модалку и интеграцию без изменения сгенерированного API.
- Критерии: отображаются скрытые точки и вопросы; ненайденные коды видны отдельно; выбор узла подсвечивает входящие/исходящие связи; граф работает на мобильной ширине.
- Ограничения: не менять `src/api/generated/**`; не добавлять новую библиотеку, если текущего frontend-стека достаточно.
- Не входит: редактирование сценария через граф и автоматическое исправление ненайденных ссылок.
- Проверка: `cd evening_detective_frontend && npm run type-check && npm run lint && npm run lint:css && npm run build`
- Ручная проверка: открыть граф сценария с дверями, текстовыми маркерами, скрытой точкой и ненайденным кодом.
## Завершённые задачи
### ED-005 — Исправить сброс настроек игры поллингом
- Статус: `DONE`
- Репозиторий: `evening_detective_frontend`
- Результат: настройки редактируются через локальный черновик и не перезаписываются поллингом.
- Проверки: type-check, lint и lint:css пройдены.
### ED-006 — Добавить страницу итогов игры
- Статус: `DONE`
- Репозиторий: `evening_detective_frontend`
- Результат: добавлена страница результатов, обработка ошибок и входы из админки и списка игр.
- Проверки: type-check, lint, lint:css и build пройдены.
### ED-007 — Добавить пьедестал победителя на странице итогов
- Статус: `DONE`
- Репозиторий: `evening_detective_frontend`
- Результат: добавлены баннер победителя, медали мест 1–3 и обработка ничьих.
- Проверки: type-check, lint, lint:css и build пройдены.
### ED-008 — Добавить создание игры из списка игр
- Статус: `DONE`
- Репозиторий: `evening_detective_frontend`
- Результат: добавлено создание игры из каталога сценариев, выбор даты и времени, отображение даты и исправлена передача RFC 3339 `startAt`.
- Проверки: type-check, lint и lint:css пройдены; build указан в отчёте плана.
## Правила обновления
1. Перед началом работы перевести выбранную задачу в `IN_PROGRESS`.
2. Не держать больше одной задачи в `IN_PROGRESS`, если работа не разделена явно.
3. При блокировке записать конкретную причину и следующий внешний шаг.
4. После проверки обновить критерии и перевести задачу в `DONE`.
5. Устойчивое знание записывать в будущую базу знаний отдельно, а не раздувать этот список.