update rules

docs/agent/TASKS.md

@@ -5,6 +5,16 @@
 Это единственный источник истины по задачам. Новые задачи добавляются сюда сразу;
 отдельный файл-план для нетривиальной задачи не создаётся.
 
+## Формат задачи
+
+Каждая активная задача содержит:
+
+- цель и ожидаемый результат;
+- критерии готовности;
+- проверку и ручной smoke-сценарий, если он нужен;
+- ограничения и явно исключённые из задачи изменения;
+- следующий конкретный шаг.
+
 ## Статусы
 
 - `TODO` — готово к работе.
@@ -24,7 +34,10 @@
 - Решение: получить количество действий через `actionsRepo.GetActionsCountByTeamIDs` по тому же паттерну, что используется в `GetFullGame`.
 - Следующий шаг: проверить всех callers `GetGameAnswers` и реализовать общий для этого пути расчёт.
 - Критерии: количество ходов совпадает с результатами игры; добавлен тест на сервисный путь.
+- Ограничения: не менять контракт API и не дублировать подсчёт в каждом caller.
+- Не входит: исправление других расхождений панели оценки.
 - Проверка: `cd evening_detective_server && go test ./...`
+- Ручная проверка: открыть панель оценки завершённой игры и сравнить число ходов с результатами игры.
 
 ### ED-002 — Rate-limit публичной регистрации команды
 
@@ -36,7 +49,10 @@
 - Решение: ограничить регистрации как минимум по `(IP, game)`, а повторную отправку — по email; лимиты должны быть согласованы до реализации.
 - Следующий шаг: определить лимиты и выбрать место хранения счётчика без зависимости от production-базы.
 - Критерии: превышение лимита отклоняется предсказуемой ошибкой; нормальная регистрация не ломается; есть тесты на границы лимита.
+- Ограничения: не добавлять внешнюю инфраструктуру без необходимости; не блокировать легитимные регистрации организатора.
+- Не входит: полноценная CAPTCHA и общая защита всех публичных endpoint.
 - Проверка: `cd evening_detective_server && go test ./...`
+- Ручная проверка: отправить несколько регистраций с одного IP и проверить ответ после достижения лимита.
 
 ### ED-003 — Очистка персональных данных регистраций
 
@@ -48,7 +64,10 @@
 - Решение: очищать персональные поля команд завершённых игр, сохраняя данные, нужные для итогов; удалять истёкшие confirmation-токены.
 - Следующий шаг: утвердить срок хранения и точный список полей, затем спроектировать job.
 - Критерии: срок хранения зафиксирован в политике; job идемпотентен; игровые итоги не ломаются; есть тест на очистку.
+- Ограничения: не удалять команды и данные, необходимые для итоговой таблицы; не запускать очистку без утверждённого срока хранения.
+- Не входит: изменение всей политики хранения данных приложения.
 - Проверка: `cd evening_detective_server && go test ./...`
+- Ручная проверка: проверить завершённую игру после запуска job и убедиться, что итоги доступны без персональных полей.
 
 ### ED-004 — Просмотр графа сценария
 
@@ -60,7 +79,10 @@
 - Реализация: чистый построитель графа, иерархическая раскладка сверху вниз, динамический импорт `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`
+- Ручная проверка: открыть граф сценария с дверями, текстовыми маркерами, скрытой точкой и ненайденным кодом.
 
 ## Завершённые задачи