agents/docs/agent/TASKS.md

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

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

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

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

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

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

Статусы

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

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

ED-041 — Подготовить юридические документы сервиса

• Статус: TODO
• Приоритет: P1
• Репозиторий: evening_detective_server
• Цель: заполнить Пользовательское соглашение, Политику конфиденциальности и отдельное согласие на обработку данных по фактическим потокам сервиса.
• Согласовано: оператор — физическое лицо Федоров Владимир Васильевич; текущий адрес обращений — vladimir.fodorow@gmail.com. Собственный сервер, БД, файлы, резервные копии и почтовый сервер находятся в России; заявки поступают через Яндекс Формы. Публиковать домашний адрес на сайте не согласовано; адрес для уведомления РКН уточняется отдельно в ED-045. Передача исключительных прав на опубликованные сценарии сохраняется.
• Решение: заполнить реквизиты, домены и редакции; убрать шаблонные поля и технические инструкции из публичных текстов. Отделить принятие соглашения от согласий; описать аккаунты, заявки, контент, игровые результаты, внешние сервисы, хранение в браузере, сроки и отзыв. Не обещать уже реализованную полную очистку, отсутствие зарубежной обработки или существующую систему истории команд. Проверить действующие нормы на дату выполнения.
• Критерии: три документа согласованы между собой и с кодом, не содержат необоснованных обещаний; политика раскрывает цели, данные, основания, сроки/условия хранения и уничтожения; законные права автора и потребителя сохранены. Приглашения разрешаются только отдельным согласием ED-044.
• Проверка: ревью текстов по актуальным источникам; go test ./...; существующие RPC выдают полные тексты без шаблонных полей и внутренних инструкций.
• Не входит: уведомления РКН, смена почтового адреса без решения владельца, регистрация пользователей, рассылка, публикация на рабочем сервере, commit/push.
• Контекст отката: реализация ED-041 от 14.10.2026 отменена по просьбе владельца; предыдущая запись DONE удалена из архива. Копия прежнего diff находится в /tmp/ed041-deferred-20261014; это временный ориентир, не источник актуальной юридической редакции.
• Следующий шаг: сверить текущую обработку данных и тексты, учесть предварительную проверку инфраструктуры и внешних сервисов из ED-045, затем подготовить новые согласованные редакции.

ED-042 — Получать отдельное согласие при регистрации аккаунта

• Статус: TODO
• Приоритет: P1
• Репозитории: evening_detective_server, evening_detective_frontend
• Зависимость: ED-041 — тексты и версии документов.
• Цель: фиксировать принятие соглашения и отдельного согласия на обработку данных, не подменяя их ознакомлением с политикой.
• Решение: ссылка второй галочки ведёт на /consent, политика доступна отдельно; добавить ссылку на согласие в подвал. Отметки изначально выключены; чтение документа мышью или клавиатурой не устанавливает галочку. Указать подтверждение 18+ в принятии соглашения. Передавать версии документов при signup и проверять их на сервере до создания аккаунта и отправки письма.
• Данные: сохранять новые записи terms и consent атомарно с аккаунтом, с версией, серверным временем, IP и User-Agent; расширить тип записи отдельной миграцией. Существующие записи privacy сохраняют прежний смысл. Не менять прежние номера и имена protobuf-полей; добавить поля версий. Старые вкладки без актуальных версий должны получить понятное требование обновления страницы.
• Критерии: без обеих отметок или с отсутствующими/устаревшими версиями аккаунт не создаётся; актуальные согласия сохраняются; исторические записи не переписываются; ссылки работают с клавиатуры; политика не используется вместо согласия.
• Проверка: тесты отказов, версий, фиксации соглашений и transport-кодов; миграция на отдельной PostgreSQL; make generate, npm run proto:gen, go test ./..., npm run type-check, npm run lint, npm run lint:css, npm run build; браузерный smoke регистрации и ссылок.
• Не входит: повторный акцепт всех существующих аккаунтов, рекламные согласия, очистка данных, публикация, commit/push.
• Следующий шаг: изучить текущие Signup → users_service → users_repo и callers фронтенда; после ED-041 внести минимальную миграцию, проверку версий и исправить форму.

ED-043 — Фиксировать согласия в заявках Яндекс Форм

• Статус: TODO
• Приоритет: P1
• Репозитории: evening_detective_server, настройки prod; внешний кабинет Яндекс Форм.
• Зависимость: ED-041 — тексты и версии документов.
• Цель: получать соглашение и согласие капитана на обработку заявки до её отправки и сохранять подтверждение на сервере.
• Решение: отдельные обязательные, изначально выключенные отметки соглашения (18+) и обработки данных, ссылки на документы и политику. Расширить JSON / JSON-RPC webhook отметками и версиями; проверку выполнять в сервисе. Явный отказ в новом формате не считать старым запросом.
• Данные: версии соглашения и согласия, серверное время и связь с ID доставки сохраняются атомарно с командой. Старым заявкам согласие задним числом не присваивается. Повтор одного ID доставки не изменяет данные, пароль или согласия и не создаёт новую команду.
• Включение: подготовить точную инструкцию формы и JSON; использовать переходный режим YANDEX_FORMS_REQUIRE_CONSENT=false, затем после обновления формы и проверки доставок включить true. Передать флаг через оба compose-файла и описать порядок миграции / публикации. Доступа к кабинету формы сейчас нет: её настройку выполняет владелец либо агент после предоставления доступа, без передачи секретов в публичные поля.
• Критерии: проверены старый формат в переходном режиме, его отказ в строгом, явный отказ, отсутствующая/устаревшая версия, успешная регистрация и повторы; сбой записи согласия не оставляет команду; исторические данные сохранены.
• Проверка: service/handler/SQL-тесты на отдельной PostgreSQL, go test ./..., миграции и безопасный откат, compose config --quiet; контрольная отправка из реальной формы после её настройки владельцем.
• Не входит: рекламные приглашения и их согласия (ED-044), rate-limit (ED-002), статистика команд, очистка (ED-003), commit/push.
• Следующий шаг: изучить текущую интеграцию и callers регистрации, подготовить миграцию и совместимый переходный JSON-контракт; отдельно согласовать с владельцем момент обновления внешней формы.

ED-044 — Отдельное добровольное согласие на приглашения

• Статус: TODO
• Приоритет: P1
• Репозитории: evening_detective_server, evening_detective_frontend; внешний кабинет Яндекс Форм.
• Зависимости: ED-041, ED-043; перед реальными отправками — ED-045 и порядок отзыва / очистки ED-003.
• Цель: отдельно подтвердить право использовать email капитана для приглашений на новые игры, сохранив возможность записаться без подписки.
• Согласовано: приглашения добровольны; email для этой цели хранится не более одного года с последней записи с действующим отдельным согласием. Повторная доставка и новая заявка без согласия не продлевают срок. Для обезличенных игровых результатов контактный email не нужен; статистика одной команды между играми — отдельная будущая работа.
• Решение: подготовить самостоятельный текст согласия на приглашения с учётом 152-ФЗ и 38-ФЗ и проверки необходимости раздельного оформления разрешений на рекламу и обработку данных. Добавить публичный RPC, маршрут /invitation-consent, ссылку в документах и подвале. В форме — отдельная необязательная отметка, не установленная заранее; две взаимоисключающие ветки интеграции передают явное согласие или отказ.
• Данные: сохранять только явно предоставленное согласие, его версию, серверное время и дату истечения атомарно с заявкой; не считать старые контакты или принятие соглашения согласием на рекламу. При отказе не создавать активное рекламное согласие. Откат миграций не должен уничтожать подтверждения.
• Критерии: запись без приглашений успешна; согласие на приглашения не заменяет согласие на заявку; версии проверяются; повторы не меняют согласие и срок; порядок отказа и условия хранения согласованы с ED-003 / ED-045.
• Проверка: генерация обоих protobuf-клиентов, tests service/handler/SQL, go test ./..., проверки типов и обоих линтеров фронтенда, сборка; браузерный smoke страницы и ссылок, контроль обеих веток реальной формы владельцем.
• Не входит: сама рассылка, автоматическая отписка и очистка, объединение команд между играми, публикация, commit/push.
• Следующий шаг: после ED-041 / ED-043 согласовать отдельный текст, расширить текущий контракт и миграцию заявки, затем подготовить настройку добровольной отметки в форме.

ED-045 — Подготовить обработку данных к публичному запуску

• Статус: TODO
• Приоритет: P1
• Область: документы проекта и организационные действия владельца.
• Цель: проверить готовность сервиса с регистрацией и заявками к публичному запуску, включая обязанности вне кода.
• Этапы: сначала проверить реквизиты, инфраструктуру и внешние сервисы для подготовки ED-041; после ED-041–ED-044 выполнить итоговую проверку перед публичным запуском.
• Решение: проверить уведомление РКН по статье 22 152-ФЗ и подготовить сведения / черновик, если оно не подано; уточнить адрес оператора для уведомления. Проверить фактические условия Яндекс Форм и Gmail, оценить локализацию и возможную трансграничную передачу по статьям 12 и 18. Использование Gmail в политике само по себе не подтверждает законность передачи; собственная почта в РФ без пересылки — вариант для решения владельца, не автоматическая смена адреса.
• Процедуры: определить сроки/условия хранения журналов, переписки и резервных копий; описать исполнение запросов, удаление/блокирование данных, подтверждение уничтожения, повторное применение удаления после восстановления копии и реакцию на инциденты. Учесть контакты заявок, файлы и персональные сведения в контенте, ответы Яндекс Форм и почту. До автоматизации допустима исполнимая ручная процедура; техническую очистку заявок вести в ED-003.
• Критерии: зафиксированы подтверждённые факты и оставшиеся препятствия, согласованы данные уведомления и способы обработки внешними сервисами; процедуры можно выполнить в сроки закона; итоговые тексты ED-041 соответствуют процедурам. Перед запуском проверены опубликованные документы, регистрация и реальная Яндекс Форма после ED-042 / ED-043. Перед приглашениями подтверждены отдельное согласие ED-044, немедленное прекращение отправок при отзыве и исключение истёкших согласий.
• Проверка: актуальные первичные нормативные источники, сверка фактической инфраструктуры и настроек внешних сервисов, подтверждение подачи уведомлений владельцем, ручной сценарий запроса/удаления на тестовых данных; составить краткий итог готовности без заявления о проверке непроверенных действий.
• Ограничения: не публиковать домашний адрес на сайте, не менять контактный email, не подавать уведомления от имени владельца, не отправлять сообщения третьим лицам и не менять production без отдельного явного поручения. Паспортные сведения, личный почтовый адрес и секреты не добавлять в Git.
• Не входит: разработка рассылки и статистики, автоматизация всей очистки, налоговые вопросы, регистрация ИП/ООО, commit/push.
• Следующий шаг: уточнить у владельца подачу уведомления и данные для него, проверить условия Gmail / Яндекс и фактические копии данных; затем определить исполнимые процедуры и согласовать вывод о запуске.

ED-018 — Удаление неиспользуемых пользовательских файлов

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

ED-021 — Магазин игр: каталог и доступ к сценариям

• Статус: TODO
• Приоритет: P1
• Репозитории: evening_detective_server, evening_detective_frontend
• Цель: дать игроку возможность выбрать опубликованный сценарий в магазине, получить одну игру по нему и запустить её.
• Решение: автор или администратор отправляет сценарий на модерацию; администратор одобряет или отклоняет публикацию; одобренный сценарий появляется в каталоге магазина и на странице игры; администратор может бесплатно выдать игроку доступ.
• Критерии: опубликованный сценарий проходит модерацию; одобренный сценарий виден в магазине; отклонённый сценарий не публикуется; игрок получает доступ к одной игре по сценарию и может её запустить; администратор может выдать доступ вручную; используются существующие данные сценария для карточки магазина.
• Ограничения: переиспользовать текущие модели, авторизацию, каталог и flow запуска игры; не добавлять зависимость без необходимости; оплату в эту задачу не включать — способ оплаты определить отдельно.
• Не входит: платёжный сервис, рейтинги, отзывы, корзина, промокоды и автоматические выплаты автору.
• Проверка: cd evening_detective_server && go test ./...; cd evening_detective_frontend && npm run type-check && npm run lint && npm run lint:css.
• Ручная проверка: отправить сценарий на модерацию от автора, одобрить и отклонить его от администратора, проверить видимость в каталоге и на странице игры, выдать игроку доступ вручную и запустить игру.
• Следующий шаг: изучить текущие модели и API сценариев, каталог, авторизацию, модерацию и выдачу доступа к игре, затем выбрать минимальную модель магазина и точки интеграции.

ED-022 — Вход через Яндекс ID

• Статус: TODO
• Приоритет: P1
• Репозитории: evening_detective_server, evening_detective_frontend
• Цель: дать всем пользователям возможность регистрироваться и входить через Яндекс ID.
• Решение: добавить OAuth-вход через Яндекс; при новой регистрации получать только email и запрашивать позывной отдельной формой; сохранить существующий способ входа; если email уже есть в системе, отправлять ссылку для подтверждения привязки Яндекс ID к аккаунту.
• Критерии: новый пользователь регистрируется через Яндекс; позывной вводится пользователем; существующий аккаунт связывается с Яндекс ID после подтверждения ссылки; после связывания доступны оба способа входа; обычная регистрация и вход не ломаются; используются только email и идентификатор Яндекс ID, без аватара и других данных.
• Ограничения: использовать существующую авторизацию, пользователей и email-flow; OAuth client ID, secret и callback URL хранить в переменных окружения; не добавлять новый платёжный или внешний сервис без необходимости; ручную проверку выполняет пользователь.
• Не входит: отключение обычного входа, получение аватара, импорт других данных профиля и восстановление доступа через Яндекс сверх стандартного OAuth-flow.
• Проверка: ручная проверка пользователем регистрации, входа, привязки по ссылке и сохранения обычного входа; после реализации — релевантные backend- и frontend-проверки по изменённым репозиториям.
• Следующий шаг: изучить текущие модели пользователей, авторизацию, email-подтверждения и frontend-flow входа, затем выбрать минимальные точки интеграции Яндекс OAuth.

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-017 — Демо-игра из каталога

• Статус: TODO
• Приоритет: P1
• Репозитории: evening_detective_server, evening_detective_frontend
• Цель: дать зарегистрированному пользователю возможность один раз пройти выбранную администратором демо-игру из каталога.
• Контекст: демо использует один конкретный сценарий; каждая попытка пользователя создаёт отдельную обычную игру с одной командой.
• Решение: в админ-панели администратор выбирает игру из каталога и назначает её демо-игрой, а также задаёт используемый сценарий. Пользователь запускает демо обычным игровым flow; незавершённую игру можно продолжить. После завершения повторный запуск запрещён, вместо него показывается сообщение о прохождении и предлагаются другие игры каталога.
• Критерии: администратор может назначить и настроить демо-игру; зарегистрированный пользователь видит её в каталоге; при запуске создаётся отдельная игра с одной командой; выбранный сценарий используется без подмены; незавершённая игра возобновляется; завершивший пользователь не может создать вторую демо-игру и видит альтернативы каталога.
• Ограничения: переиспользовать существующие каталог, авторизацию, создание игры, игровые состояния и результаты; не добавлять отдельный игровой flow или зависимость без необходимости; не ломать обычные игры.
• Не входит: несколько сценариев в одной демо-игре, повторное прохождение одним пользователем, анонимный доступ и отдельная система прогресса.
• Проверка: cd evening_detective_server && go test ./...; cd evening_detective_frontend && npm run type-check && npm run lint && npm run lint:css.
• Ручная проверка: назначить игру демо и выбрать сценарий, запустить её двумя пользователями, продолжить незавершённую игру, завершить одну и проверить запрет повторного запуска и показ других игр каталога.
• Следующий шаг: изучить модель каталога, админ-панель, создание игр и проверку завершённых игр пользователя, затем выбрать минимальную модель настройки демо и точку запуска из каталога.

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-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-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-токены.
• Следующий шаг: учесть согласованный в ED-044 срок приглашений — один год с последней записи с действующим отдельным согласием; после определения процедур ED-045 уточнить очистку по целям (участие / приглашения), точный список полей и учёт отзывов, затем спроектировать 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. Устойчивое знание записывать в будущую базу знаний отдельно, а не раздувать этот список.