docs: add competitive ux roadmap

docs/ROADMAP.md

@@ -88,6 +88,18 @@
 - [x] **D06 · Метаданные браузера и CSP.** Добавлены парные `theme-color` для системной light/dark схемы; явный cookie-выбор согласуется с SSR и мгновенно переключает активный meta-тег. PWA manifest использует устойчивый тёмный brand chrome и splash background. Production build сохраняет `inlinedScripts: []`; новые inline script/style/attributes не появились, ослабление CSP не потребовалось.
 - [ ] **D07 · Визуальная и accessibility-приёмка.** In-app Chromium подтвердил отсутствие горизонтального scroll на публичных `/`, `/waterbodies`, `/records`, `/report`, `/status`, `/media`, `/rules`, waterbody detail `/waterbodies/р-вьюнок` и fish detail `/fish/pike`, а также admin `/admin`, `/admin/moderation`, `/admin/external-sources`, `/admin/media` в 320/390/768/1280 px; исправлены tablet header и media-grid overflow. Автоматизированный visual-matrix regression и `scripts/capture-visual-matrix.mjs` подтверждают 13 маршрутов × 4 ширины × 3 режима (`156` комбинаций): document overflow отсутствует, везде есть `main`/`h1`, SSR-тема совпадает; полная screenshot-матрица захвачена во внешнюю директорию. Для media и двух detail-страниц light/dark/system корректно переключаются, broken images — `0`; axe `9/9`, отдельная domain accessibility-проверка добавлена для `/waterbodies`, waterbody detail, spot detail и `/media`, keyboard/focus, forced-colors и print-regression проходят. Остались ручная проверка shadows/gradients и выбор сохраняемого reference-набора. Для обеих тем обеспечить WCAG AA, отсутствие горизонтального scroll и CLS, reduced motion и переключение без потери введённых данных; сохранить эталонные screenshots и краткий отчёт.
 
+### UX/UI и конкурентное преимущество
+
+Результаты сравнительного аудита и ссылки сохранены в [ux-competitive-audit.md](ux-competitive-audit.md). Целевой критерий проекта: RF4 Spotter должен быстрее и честнее отвечать на вопрос «куда идти, на что ловить и почему этому можно доверять», чем каталог или лента community-постов.
+
+- [ ] **U01 · UX-контракт и scorecard.** Зафиксировать task-based навигацию, смысловой порядок ответа, словарь статусов (`fresh`, `stale`, `insufficient_data`, `blocked`, `temporary_error`) и единый scorecard: time-to-first-useful-answer, filter-to-result steps, completion rate, overflow, axe и keyboard regression. Сверить каждый публичный маршрут с контрактом; не добавлять фичи, которые не улучшают решение игрока.
+- [ ] **U02 · Главный сценарий «рыба → водоём → точка → снасть».** Перестроить home/filter journey так, чтобы один URL сохранял рыбу, водоём, период, сортировку и режим list/map; показать 3–5 вариантов с понятным CTA и сохранить текущие empty/error/partial states. Acceptance: первый полезный вариант виден без регистрации, back/refresh сохраняют контекст, mobile не теряет фильтры.
+- [ ] **U03 · Evidence/trust card.** Ввести общий компонент доказательности для activity, spot, waterbody и tackle: freshness, период, число наблюдений, независимые игроки, `coordinate_precision`, completeness, source badges, confidence и конфликт источников. Нельзя показывать «лучшую точку» или AI-like рекомендацию без объяснения и минимальной выборки.
+- [ ] **U04 · List/map и progressive disclosure.** Добавить единый контракт list/map: одинаковые фильтры, сортировка, URL-состояние и карточки; на mobile список остаётся базовым режимом, карта открывается отдельным действием. Не перегружать первый экран: вторичные raw/provenance-поля раскрываются по запросу, но не исчезают.
+- [ ] **U05 · Mobile-first и сохранённый план рыбалки.** Добавить лёгкий сценарий сравнения и сохранения 3–5 вариантов без обязательного аккаунта: рыба, водоём, координаты, метод, наживка, свежесть, доверие и риск. Acceptance: shareable URL/print-карточка, 320/390 px, восстановление после reload, удаление локального плана без внешнего сервиса.
+- [ ] **U06 · Контентная и визуальная иерархия.** Сократить конкурирующие цифры на карточках, привести badges/source labels к одной семантике, сделать «что делать» главным текстом, а provenance — вторичным раскрываемым слоем. Провести ручной review на 5 ключевых маршрутах и проверить, что цвет не является единственным носителем статуса.
+- [ ] **U07 · UX-приёмка и измерения.** Добавить Playwright-контракты для полного journey, list/map, evidence states, saved plan, stale/blocked/insufficient data и share/print. Зафиксировать baseline Lighthouse/axe/CLS/INP и time-to-first-useful-answer; закрывать U01–U06 только по evidence, screenshots и обратной связи пилота.
+
 - [ ] **Q01 · Документы источников — реестр готов, нужны первичные подтверждения.** Создан единый production-gate с атрибуцией, общим лимитом 30 минут, хранением и процедурой отзыва для RF4DB, RF4-STAT, RF4MAP, RF4 Posts и официального RF4. До открытой публикации приложить устойчивые ссылки/копии первичных разрешений, контакты, даты и отдельно подтвердить право на изображения; пустое поле блокирует соответствующий источник.
 - [x] **Q02 · Управляемое удаление источника.** Изменение ранее опубликованной записи возвращает её в staging, сбрасывает сопоставление и переводит связанный улов в pending с новой версией решения. Результат проверки хранится как `available`, `missing`, `temporary_error` или `blocked`: только подтверждённый `missing` отзывает публикацию, временная ошибка и блокировка остаются диагностикой. Повторное появление требует ручного подтверждения. Withdrawn-записи исключены из публичной активности, а статус и время проверки доступны в admin provenance и журнале решений. Отдельного сетевого обхода нет: Q03 подключит эту реакцию к разрешённому плановому запросу.
 - [x] **Q03 · Целостность ссылок.** Результат уже разрешённого scheduler-запроса классифицируется без retry и дополнительного HTTP: `404/410` — `missing`, `401/403/429` — `blocked`, остальные сетевые/парсерные сбои — `temporary_error`. Результат применяется только к наблюдениям с точным совпадением source system и запрошенного URL. Отсутствие записи в агрегатном списке намеренно не считается удалением; появившиеся в успешном ответе записи отмечаются `available` обычным staging-проходом. Все попытки по-прежнему резервируются до запроса и расходуют общий cooldown домена.

docs/ux-competitive-audit.md

@@ -0,0 +1,70 @@
+# UX/UI-аудит RF4 Spotter
+
+Дата среза: 20 сентября 2026 года.
+
+Цель проекта — быть не самым большим каталогом, а самым понятным и проверяемым
+инструментом ответа на вопрос: «куда идти, на что ловить и насколько этому
+можно доверять?»
+
+## Что стоит взять
+
+- [RF4 Database](https://rf4db.com/en) хорошо делит задачи игрока на Hunt,
+  Silver Farm, Café и Wiki, показывает временное окно и объясняет ограничения
+  player data. Берём task-based навигацию и обязательное объяснение границ
+  данных.
+- [RF4-STAT](https://rf4-stat.ru/) удачно сочетает карту, список, период и
+  сортировку. Берём синхронные list/map представления, но не прячем основной
+  ответ за рекламой или Premium.
+- [RF4MAP](https://rf4map.ru/) хорошо формулирует задачу «где сейчас клюёт»,
+  показывает свежесть каталога и рейтинг точек. Берём freshness и понятный
+  discovery, но рейтинг обязан иметь объяснимую методику.
+- [RF4 Posts](https://rf4-posts.com/en) полезно разделяет Trophy/Farming,
+  использует screenshots и модерацию. Берём visual evidence, но показываем
+  дату проверки, проверяющего и срок актуальности.
+- [Fishbrain](https://fishbrain.com/explore) и [FishAngler](https://home-dev.fishangler.com/)
+  показывают ценность слоёв карты, private waypoints, catch log и фильтров.
+  Берём progressive disclosure и сохранение личных планов, но не превращаем
+  основной сценарий в тяжёлую social/app-платформу.
+
+## Что не повторять
+
+- смешивание official, community и inferred данных без различимой метки;
+- точные координаты без уровня точности, свежести и размера выборки;
+- «AI знает ответ» без списка доказательств и конфликтующих сигналов;
+- Premium/реклама как барьер для базового ответа;
+- длинные ленты карточек, где цифр больше, чем решения;
+- рейтинг без формулы, периода и минимального числа наблюдений;
+- loading-состояние без понятного результата, retry и объяснения неполноты.
+
+## Целевой сценарий
+
+1. Игрок выбирает рыбу, водоём и период.
+2. Система показывает 3–5 вариантов точки или тактики.
+3. Каждая рекомендация содержит «что делать» и «почему мы так считаем».
+4. Игрок открывает координаты, снасть и первоисточники без второго поиска.
+5. При малом или устаревшем наборе система говорит `insufficient_data` или
+   `stale`, а не изображает точный прогноз.
+
+## Обязательная evidence-карточка
+
+Карточка рекомендации должна показывать:
+
+- target fish, waterbody, spot и method;
+- bait/tackle и неполные поля;
+- freshness и период выборки;
+- число наблюдений и независимых игроков;
+- `coordinate_precision`;
+- source badges и ссылку на первоисточник;
+- confidence/status с текстовым объяснением;
+- конфликт источников и причину, если данные расходятся.
+
+## Критерии образцового UI/UX
+
+- первый полезный ответ виден без регистрации и без внешнего поиска;
+- desktop и 320 px mobile сохраняют один и тот же смысловой порядок;
+- list/map, фильтры и URL-параметры синхронны;
+- любая цифра имеет период, единицу и контекст;
+- любое утверждение о свежести имеет timestamp;
+- неполнота и неопределённость видны текстом, а не только цветом;
+- keyboard, screen reader, forced-colors, reduced-motion и print проходят;
+- путь от фильтра до полезной рекомендации измеряется и не деградирует.