rf4-spotter/docs/ROADMAP.md

План работ RF4 Spotter

Этот файл — единственный актуальный список задач. Завершённые аудиты сохранены как история в PROJECT_AUDIT_2026-09-08.md, REGRESSION_AUDIT_2026-09-09.md и RECOVERY_PLAN_2026-09-10.md; их старые чекбоксы не являются текущей очередью.

Последняя сверка: 12 сентября 2026.

Подтверждено:

• пакет восстановления A01–A13 завершён; итог и доказательства собраны в RECOVERY_FIXES_REPORT.md;
• полный Python suite: 130 passed, 1 skipped; skip относится к интеграционной проверке PostgreSQL и покрывается Docker-приёмкой;
• Astro check: 40 файлов, 0 errors / 0 warnings / 0 hints; production build проходит;
• API после миграции healthy; apps/api/tests/test_api.py: 20 passed;
• локальная БД и чистый bootstrap достигают Alembic head 20260910_recovery;
• изолированный production bootstrap проходит Caddy adapt, scheduler validation и Playwright-сценарий отправки/модерации без обращения к внешним источникам;
• Astro + FastAPI + PostgreSQL остаются целевым стеком; Next.js и Vinext не используются.

Ближайший пакет — без сервера

Пункты выполняются сверху вниз, небольшими связанными коммитами.

• Q01 · Документы источников. Приложить или дать устойчивые ссылки на первичные разрешения RF4DB, RF4-STAT, RF4MAP и RF4 Posts; для каждого зафиксировать атрибуцию, точный production-лимит, срок хранения и процедуру удаления.
• Q02 · Управляемое удаление источника. Добавить обнаружение изменённых/удалённых опубликованных записей без отдельного частого обхода: статус, журнал решения и безопасное исключение из активности после проверки.
• Q03 · Целостность ссылок. Проверять исходные ссылки только во время разрешённого планового обращения к площадке, разделяя missing, temporary_error и blocked; не создавать дополнительный сетевой цикл.
• Q04 · Состояния ожидания. Асинхронные admin-очереди получили каркасные карточки, aria-busy, очистку при ошибке и поддержку prefers-reduced-motion. Публичные страницы остаются SSR и не показывают искусственный skeleton; форма уже блокирует повторную отправку и сообщает «Отправка…».
• Q05 · Базовая визуальная матрица. Главная проверена в браузере на 320/390/768/1280 px, ключевые public-маршруты — на 320 px; удалён корневой min-width, создававший горизонтальный scroll. Добавлен E2E-контракт для /, records, report, waterbodies, status и видимого skip-link. Ширина 320 px также покрывает reflow, эквивалентный 200% zoom для окна 640 px. Расширенная матрица наполненных/длинных/error-состояний остаётся постоянной частью приёмки UI, а не отдельным блокером.
• Q06 · Performance baseline. На локальной production-сборке после оптимизации hero: performance 100, LCP 1,66 с, FCP 1,15 с, CLS 0,023, TBT 9 мс. Устранены найденные Lighthouse проблемы контраста и accessible name; методика и бюджеты записаны в performance-baseline.md. Полевой INP измеряется только после запуска.
• Q07 · Нагрузочная методика. Подготовить воспроизводимый сценарий измерения p95 для activity, records, staging и moderation без объявления результатов до запуска на целевом сервере.
• Q08 · Политика MinIO. Ограничить app credentials одним bucket и добавить безопасную автоматическую проверку policy; root credentials оставить только bootstrap-задаче.
• Q09 · Release-процедура. Разделить миграционный/release-шаг и запуск приложения либо документировать выбранную стратегию отката; проверить upgrade с предыдущей ревизии на копии данных.
• Q10 · Документальная ревизия. После каждого пакета обновлять этот файл и README, не возвращая закрытые R/A/T-задачи в активный backlog.

Готовность открытой альфы — требуется сервер или внешний сервис

• Купить/подготовить Linux-сервер и подтвердить его публичный IPv4/IPv6.
• Настроить DNS rf4spotter.ru и files.rf4spotter.ru, открыть только необходимые внешние порты и получить корректный TLS через Caddy.
• Создать .env.production, заменить все демонстрационные секреты и выполнить deploy/preflight.sh.
• Создать публичные контакты privacy/abuse и подключить их к сайту и alpha-баннеру.
• Настроить внешний backup, выполнить восстановление с сервера и подключить реальный канал уведомлений.
• Наполнить альфу небольшим разрешённым набором данных и провести финальную приёмку по open-alpha-acceptance.md.
• После 24 часов стабильной работы пригласить первых игроков, собрать обратную связь и закрыть блокирующие проблемы пилота.
• Подключить Search Console/Яндекс Вебмастер и проверить реальные canonical, sitemap, robots, OG и JSON-LD.
• Снять серверные p95 и Lighthouse; скорректировать индексы, кэш и изображения только по измерениям.

После пилота

• Решить по обратной связи, нужны ли OCR, Telegram, профили и уведомления о клёве.
• Рассмотреть cursor pagination при росте объёмов; текущая offset pagination достаточна для альфы.
• Рассмотреть общую инвалидацию кэша при нескольких API-процессах; сейчас действует TTL и локальная инвалидация.
• Подготовить тематические обложки и индивидуальные OG для рыб/водоёмов, если страницы подтверждают поисковую ценность.

Правила выполнения

• Сетевой парсинг одной площадки — не чаще одного раза за 30 минут, включая ошибки и разные endpoint.
• Каждая публичная запись обязана показывать источник; неполные данные — отдельную пометку и список отсутствующих полей.
• Реальные источники не используются в тестах: только fixtures и изолированные Docker-сценарии.
• Docker запускается одним общим прогоном для инфраструктурного пакета, а не после каждой правки.
• Пункт закрывается только после адресной проверки; команда и результат фиксируются в коммите или отчёте.
• Не менять целевой стек Astro + FastAPI + PostgreSQL.