181 lines
27 KiB
Markdown
181 lines
27 KiB
Markdown
# Задачи проекта
|
|
|
|
Активный список задач для разработки и работы агента.
|
|
|
|
Новые задачи добавляются сюда после уточнения требований; отдельный файл-план
|
|
для нетривиальной задачи не создаётся. Завершённые задачи переносятся в
|
|
[`COMPLETED_TASKS.md`](COMPLETED_TASKS.md).
|
|
|
|
## Формат задачи
|
|
|
|
Каждая активная задача содержит:
|
|
|
|
- цель и ожидаемый результат;
|
|
- критерии готовности;
|
|
- проверку и ручной smoke-сценарий, если он нужен;
|
|
- ограничения и явно исключённые из задачи изменения;
|
|
- следующий конкретный шаг.
|
|
|
|
## Статусы
|
|
|
|
- `TODO` — готово к работе.
|
|
- `IN_PROGRESS` — выполняется.
|
|
- `BLOCKED` — заблокировано, причина указана в задаче.
|
|
- `DONE` — завершено и проверено.
|
|
|
|
## Активные задачи
|
|
|
|
### ED-014 — Периодическое сохранение сценариев в Git
|
|
|
|
- Статус: `TODO`
|
|
- Приоритет: `P2`
|
|
- Репозиторий: `evening_detective_server`
|
|
- Цель: автоматически сохранять все сценарии в отдельный Git-репозиторий после изменений.
|
|
- Решение: после изменения сценария запускать отложенное сохранение с ограничением не чаще одного раза в 5 минут; экспортировать сценарии в текущем экспортном формате, выполнять commit и push на сервере. Адрес репозитория, ветка и учётные данные задаются через переменные окружения. Ошибку commit/push показывать в панели администратора.
|
|
- Критерии: изменение сценария приводит к его появлению в отдельном репозитории; частые изменения не создают операции чаще одного раза в 5 минут; commit и push выполняются автоматически; ошибка синхронизации видна администратору; все сценарии экспортируются без потери данных.
|
|
- Ограничения: использовать серверный flow сохранения сценария; не хранить URL, ключи и пароли в коде или Git; не добавлять новую инфраструктуру и зависимости без необходимости; не выполнять commit или push в текущих репозиториях проекта.
|
|
- Не входит: ручной UI для редактирования Git, восстановление сценария из Git и ручная проверка пользователем.
|
|
- Проверка: ручная проверка пользователем — изменить сценарий, убедиться в появлении commit и push в отдельном репозитории, проверить ограничение частоты и отображение ошибки при недоступном push.
|
|
- Следующий шаг: изучить серверный flow изменения сценариев, экспортный формат, текущие фоновые механизмы и конфигурацию окружения, затем выбрать минимальную точку запуска отложенной Git-синхронизации.
|
|
|
|
### ED-013 — Просмотр ответов перед окончательным завершением игры
|
|
|
|
- Статус: `TODO`
|
|
- Приоритет: `P1`
|
|
- Репозитории: `evening_detective_server`, `evening_detective_frontend`
|
|
- Цель: дать команде возможность после завершения игрового этапа посмотреть свои ответы и правильные ответы, затем автоматически окончательно закрыть игру через 15 минут.
|
|
- Контекст: в таких играх одна игра соответствует одной команде; любой игрок команды может открыть просмотр ответов.
|
|
- Решение: после обычного завершения переводить игру в отдельный статус просмотра ответов; при первом открытии просмотра сохранять время начала 15-минутного периода; по истечении периода переводить игру в финальный статус с фиксацией результата и отображением формы отзыва. Если просмотр не открыт, игра остаётся в статусе просмотра ответов.
|
|
- Критерии: любой игрок команды видит ответы команды вместе с правильными ответами; первый просмотр запускает общий для игры таймер; время хранится на сервере и не сбрасывается обновлением страницы; до истечения 15 минут игровые действия недоступны; после истечения игра окончательно завершена, результат доступен, форма отзыва показывается; повторные открытия не продлевают период; доступ к ответам и переходы статусов проверяются на сервере.
|
|
- Ограничения: переиспользовать существующие endpoint, авторизацию, сервисы и форму отзыва; не добавлять отдельный сервис или зависимость без необходимости; не ломать текущие сценарии `draft`/`run`/`pause`/`finish`; сгенерированные protobuf-файлы менять только через существующую генерацию.
|
|
- Не входит: отдельный таймер для команды, так как одна игра содержит одну команду; изменение состава или подсчёта результата; редизайн формы отзыва.
|
|
- Проверка: `cd evening_detective_server && go test ./...`; `cd evening_detective_frontend && npm run type-check && npm run lint && npm run lint:css`.
|
|
- Ручная проверка: завершить игру, открыть просмотр ответов, обновить страницу и убедиться, что отсчёт продолжается; проверить недоступность игровых действий, автоматическое финальное завершение через 15 минут, результат и форму отзыва.
|
|
- Следующий шаг: изучить текущие переходы статусов игры, авторизацию игрока, endpoint выдачи ответов и flow формы отзыва, затем выбрать минимальное серверное хранение времени первого просмотра и точку запуска финального завершения.
|
|
|
|
### 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`
|
|
- Ручная проверка: открыть граф сценария с дверями, текстовыми маркерами, скрытой точкой и ненайденным кодом.
|
|
|
|
## Правила обновления
|
|
|
|
1. Перед началом работы перевести выбранную задачу в `IN_PROGRESS`.
|
|
2. Не держать больше одной задачи в `IN_PROGRESS`, если работа не разделена явно.
|
|
3. При блокировке записать конкретную причину и следующий внешний шаг.
|
|
4. После проверки обновить результат, перевести задачу в `DONE` и перенести её в `COMPLETED_TASKS.md`.
|
|
5. Устойчивое знание записывать в будущую базу знаний отдельно, а не раздувать этот список.
|