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

10 KiB

Задачи проекта

Единый список задач для разработки и работы агента.

Это единственный источник истины по задачам. Новые задачи добавляются сюда сразу; отдельный файл-план для нетривиальной задачи не создаётся.

Формат задачи

Каждая активная задача содержит:

  • цель и ожидаемый результат;
  • критерии готовности;
  • проверку и ручной 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. Устойчивое знание записывать в будущую базу знаний отдельно, а не раздувать этот список.