perf: stabilize list queries for pilot

docs/ROADMAP.md

@@ -61,10 +61,10 @@
 - [x] Автоматизировать ежедневную цепочку backup → dry-run → retention с блокировкой параллельного запуска; ограничить Docker JSON-логи пятью файлами по 10 МБ на сервис.
 - [x] Добавить структурированные JSON-логи без пользовательских секретов и персональных технических данных (whitelist полей, redaction, request ID; Uvicorn access-log отключён).
 - [x] Добавить Gitea Actions CI: backend tests, Astro check/build, E2E и применение всех миграций на чистой PostgreSQL; сохранять логи Compose и Playwright-артефакты при падении (`.gitea/workflows/ci.yml`).
-- [x] Добавить отдельный тест полного bootstrap: пустые production volumes → миграции `0010` → seed без демо-уловов → readiness → браузерная отправка и проверка moderation API (`deploy/test-production-bootstrap.sh`, 6 сентября 2026).
+- [x] Добавить отдельный тест полного bootstrap: пустые production volumes → миграции `0011` → seed без демо-уловов → readiness → браузерная отправка и проверка moderation API (`deploy/test-production-bootstrap.sh`, 7 сентября 2026).
 - [x] Сделать seed устойчивым к частично заполненной БД: справочники досеиваются независимо, демо-уловы идемпотентны и принудительно отключены в production; повторный/частичный запуск покрыт конфигурационными и интеграционными проверками.
-- [ ] Проверить списочные API по требованию раздела 12: пагинация, предсказуемая сортировка и валидация фильтров для справочников, импортов, модерации и внешнего staging.
-- [ ] Проверить необходимые индексы PostgreSQL и планы запросов для activity, модерации, дедупликации и очистки rate limit; зафиксировать допустимый бюджет запросов пилота.
+- [x] Проверить списочные API по требованию раздела 12: все выдачи имеют ограниченные `limit`/`offset`, детерминированный tie-breaker и типизированные фильтры; фильтр категории рекордов перенесён до пагинации.
+- [x] Добавить составные индексы PostgreSQL для activity, модерации, официальных рекордов, staging, импорта, аудита и очистки rate limit (миграция `0011`); бюджет и процедура проверки планов зафиксированы в `docs/query-performance.md`.
 - [x] Провести security-проверку admin-аутентификации, CORS, headers, загрузок, контейнерных пользователей и секретов: двойная защита admin web/API, constant-time token, no-store, non-root API/web и отдельные MinIO root/app credentials; остаточные ограничения записаны в `docs/security-review.md`.
 - [x] Проверить авторизацию повторной загрузки скриншота: используется отдельный одноразовый случайный токен, в БД хранится только SHA-256, UUID заявки недостаточно.
 - [x] Определить сроки хранения ников, исходных payload, staging-наблюдений, moderation events и submission attempts; добавлены настраиваемая dry-run-first очистка, тест и `docs/data-retention.md`.
@@ -119,12 +119,10 @@
 
 Технический production-контур, health/readiness, backup/restore и безопасные логи готовы. Следующие пункты выполняются строго по одному:
 
-1. защита официального импорта от конкурентных запусков;
-2. пагинация/сортировка списочных API и индексы PostgreSQL;
-3. UI/UX-пакеты B–D: мобильная главная, форма и рекорды;
-4. accessibility/admin safety и Lighthouse;
-5. мониторинг, DNS/TLS и проверка production-профиля на целевом сервере;
-6. финальное обновление README, лицензия кода и политика данных.
+1. UI/UX-пакеты B–D: мобильная главная, форма и рекорды;
+2. accessibility/admin safety и Lighthouse;
+3. мониторинг, DNS/TLS и проверка production-профиля на целевом сервере;
+4. финальное обновление README, лицензия кода и политика данных.
 
 После каждого пункта необходимо:
 

docs/query-performance.md

@@ -0,0 +1,38 @@
+# Бюджет запросов для альфа-пилота
+
+Дата фиксации: 7 сентября 2026 года.
+
+## Контракт списочных API
+
+Все списочные endpoint'ы принимают ограниченный `limit` и неотрицательный `offset`. Справочники ограничены 500 строками, публичные и административные журналы — 100–200 строками. Сортировка всегда имеет уникальный `id` последним ключом, поэтому соседние страницы не меняются местами при одинаковых датах или названиях. Значения перечислимых фильтров проверяет FastAPI; неподдерживаемое значение возвращает `422`.
+
+Фильтры применяются в SQL до `offset` и `limit`. Это особенно важно для `GET /api/v1/records?category=...`: фильтрация JSON-поля после пагинации могла возвращать пустую страницу при наличии подходящих записей.
+
+## Индексы
+
+Миграция `0011` добавляет составные индексы для основных путей чтения:
+
+- activity и лента точки — статус модерации, удаление, время и точка;
+- очередь модерации — источник, статус, удаление и время;
+- официальные рекорды — источник, дата и вес;
+- журнал импорта — источник, статус и время запуска;
+- staging — статус, система-источник и время последнего наблюдения;
+- rate limit — отпечаток клиента и время попытки;
+- retention аудита — время события модерации.
+
+## Измеримый бюджет
+
+На сервере альфа-пилота при объёме до 100 000 уловов и до 100 000 staging-наблюдений принимаются следующие server-side цели без учёта сети и браузерного рендера:
+
+- p95 публичных списков и activity — не более 250 мс;
+- p95 административных очередей — не более 500 мс;
+- один запрос очистки rate limit или retention-пакет — не более 2 с;
+- ни один интерактивный запрос не должен читать более 10 000 строк фактов по `Rows Removed by Filter`.
+
+Это стартовый эксплуатационный бюджет, а не результат синтетического бенчмарка. Планы на пустой bootstrap-БД не показательны: PostgreSQL обоснованно выбирает последовательное чтение маленьких таблиц.
+
+## Проверка после загрузки пилотных данных
+
+После наполнения выполнить `EXPLAIN (ANALYZE, BUFFERS)` для activity, moderation queue, records, staging queue и удаления старых submission attempts. Проверять фактическое время, `Rows Removed by Filter`, объём buffers и соответствие выбранного индекса фильтрам. Если таблица превышает 10 000 строк, а план остаётся последовательным и выходит за бюджет, сохранить план в журнал релиза и скорректировать индекс или форму запроса до открытия альфы.
+
+Bootstrap-тест отдельно проверяет, что Alembic дошёл до `0011` и все восемь составных индексов созданы на чистой PostgreSQL.