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

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

Новые задачи добавляются сюда после уточнения требований; отдельный файл-план для нетривиальной задачи не создаётся. Завершённые задачи переносятся в COMPLETED_TASKS.md.

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

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

цель и ожидаемый результат;
критерии готовности;
проверку и ручной smoke-сценарий, если он нужен;
ограничения и явно исключённые из задачи изменения;
следующий конкретный шаг.

Статусы

TODO — готово к работе.
IN_PROGRESS — выполняется.
BLOCKED — заблокировано, причина указана в задаче.
DONE — завершено и проверено.

Активные задачи

ED-011 — Строгий стандарт написания Go-бэкенда

Статус: TODO
Приоритет: P1
Репозиторий: evening_detective_server
Цель: зафиксировать однозначные правила написания чистого, понятного и гибкого Go-кода для последующей миграции всего бэкенда.
Решение: создать отдельный документ со строгими правилами структуры пакетов и слоёв, размещения функций, структур, интерфейсов, ошибок, SQL, handlers, DTO и тестов; описать именование, границы ответственности, допустимые зависимости и типовые примеры выбора места для нового кода. Подключить документ через AGENTS.md только для задач, затрагивающих Go-бэкенд.
Следующий шаг: изучить фактическую структуру и паттерны evening_detective_server, затем подготовить проект стандарта и согласовать спорные архитектурные решения перед записью документа.
Критерии: для типовых вопросов о размещении кода документ даёт один основной ответ; правила обязательны; каждое отклонение требует разрешения пользователя и письменного обоснования; документ не применяется к фронтенду, инфраструктуре и задачам, не затрагивающим Go-бэкенд; существующий код не изменён.
Ограничения: не мигрировать существующий код в рамках этой задачи; не менять API и зависимости; не трогать вложенный .git; не добавлять task-файлы в дочерний репозиторий.
Не входит: исправление нарушений стандарта в текущем коде; автоматический линтер или архитектурный enforcement; правила для Vue/TypeScript и инфраструктуры.
Проверка: проверить наличие стандарта и условной ссылки на него в корневом AGENTS.md; убедиться, что git diff содержит только документационные изменения.
Ручная проверка: проверить по примерам, что для новой функции, структуры, интерфейса, запроса и теста документ однозначно определяет место размещения.

ED-012 — Строгий стандарт написания фронтенда

Статус: TODO
Приоритет: P1
Репозиторий: evening_detective_frontend
Цель: зафиксировать однозначные правила написания чистого, понятного и гибкого Vue/TypeScript-кода для последующей миграции всего фронтенда.
Решение: создать отдельный документ со строгими правилами структуры каталогов и компонентов, размещения composables, функций, типов, API-кода, состояния, стилей, валидации и тестов; описать именование, границы ответственности, допустимые зависимости и типовые примеры выбора места для нового кода. Подключить документ через AGENTS.md только для задач, затрагивающих фронтенд.
Следующий шаг: изучить фактическую структуру и паттерны evening_detective_frontend, затем подготовить проект стандарта и согласовать спорные архитектурные решения перед записью документа.
Критерии: для типовых вопросов о размещении компонента, composable, функции, типа, API-вызова, состояния и стиля документ даёт один основной ответ; правила обязательны; каждое отклонение требует разрешения пользователя и письменного обоснования; документ не применяется к бэкенду, инфраструктуре и задачам, не затрагивающим фронтенд; существующий код не изменён.
Ограничения: не мигрировать существующий код в рамках этой задачи; не менять API и зависимости; не менять сгенерированный API без отдельной необходимости; не трогать вложенный .git; не добавлять task-файлы в дочерний репозиторий.
Не входит: исправление нарушений стандарта в текущем коде; автоматический линтер или архитектурный enforcement; правила для Go и инфраструктуры.
Проверка: проверить наличие стандарта и условной ссылки на него в корневом AGENTS.md; убедиться, что git diff содержит только документационные изменения.
Ручная проверка: проверить по примерам, что для нового компонента, composable, функции, типа, API-вызова, состояния и стиля документ однозначно определяет место размещения.

ED-009 — Оптимизировать изображения для web

Статус: TODO
Приоритет: P1
Репозиторий: evening_detective_server
Цель: ускорить загрузку фотографий на сайте, сохраняя оригиналы для печати.
Контекст: сейчас для просмотра на сайте используются оригинальные изображения, подготовленные для печати, поэтому страницы загружаются медленно.
Решение: при загрузке фотографии сохранять оригинал и создавать облегчённую web-версию; сайт должен получать web-версию, а оригинал оставаться доступным для печати. Для уже загруженных фотографий предусмотреть отдельную безопасную пакетную обработку с созданием web-версий без удаления оригиналов.
Следующий шаг: изучить текущий flow загрузки, хранения и выдачи фотографий, проверить объём уже загруженных файлов, затем выбрать минимальный способ генерации web-версий и запуска обработки без новой инфраструктуры.
Критерии: оригинал не теряется; web-версия создаётся автоматически для новых файлов; web-версии создаются для уже загруженных фотографий; endpoint сайта выдаёт web-версию; размер и время загрузки заметно уменьшены; ошибки обработки не приводят к потере оригинала; повторный запуск обработки безопасен.
Ограничения: не менять оригиналы; не добавлять зависимость или отдельный сервис без необходимости; не менять API шире требуемого для переключения выдачи.
Не входит: изменение качества оригиналов; полноценный CDN.
Проверка: cd evening_detective_server && go test ./...
Ручная проверка: загрузить фото, убедиться в наличии оригинала и web-версии, открыть страницу сайта и проверить, что выдаётся облегчённый файл.

ED-010 — Расширить MCP функциями автора сценария

Статус: TODO
Приоритет: P2
Репозиторий: evening_detective_server
Цель: дать автору сценария возможность работать со сценарием через существующий MCP.
Контекст: текущий MCP нужно дополнить авторскими операциями, чтобы сценарий можно было просматривать и редактировать без обходных ручных действий.
Решение: изучить существующий MCP и добавить минимальный набор авторских функций для просмотра сценария, добавления и редактирования точек, а также связанных сущностей и операций, необходимых для полноценного авторского flow.
Следующий шаг: инвентаризировать текущие MCP-инструменты, модели и сервисы сценариев, затем зафиксировать точный набор операций и права доступа автора.
Критерии: автор может получить структуру и содержимое сценария; добавлять точки; редактировать точки; выполнять необходимые связанные операции через MCP; ошибки и недоступные операции возвращаются предсказуемо; существующие MCP-инструменты не ломаются.
Ограничения: переиспользовать существующие сервисы и правила доступа; не дублировать бизнес-логику в MCP; не менять сгенерированный API без необходимости.
Не входит: отдельный новый MCP-сервер; полноценный визуальный редактор; изменение сценарной модели без подтверждённой необходимости.
Проверка: cd evening_detective_server && go test ./...
Ручная проверка: подключиться к MCP от имени автора, просмотреть сценарий, добавить точку, изменить её и проверить результат в редакторе/хранилище.

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
Ручная проверка: открыть граф сценария с дверями, текстовыми маркерами, скрытой точкой и ненайденным кодом.

Правила обновления

Перед началом работы перевести выбранную задачу в IN_PROGRESS.
Не держать больше одной задачи в IN_PROGRESS, если работа не разделена явно.
При блокировке записать конкретную причину и следующий внешний шаг.
После проверки обновить результат, перевести задачу в DONE и перенести её в COMPLETED_TASKS.md.
Устойчивое знание записывать в будущую базу знаний отдельно, а не раздувать этот список.

20 KiB Raw Blame History