BikeTrack Main Map — канонический аудит

Статус: рабочий baseline до начала исправлений Дата перепроверки: 2026-07-18, Asia/Tbilisi Ревизия продукта: aabfa583cf3949ecfc5243e93071599244b4a85dТекущий release verdict: FAIL для narrow viewport и modal/keyboard accessibility Подтверждённых P0: 0

Эта папка сохраняет и нормализует результаты трёх независимых отчётов о главной карте. Исходные отчёты оказались полезны как набор гипотез, но противоречат друг другу и местами неверно трактуют код, WCAG и успешные E2E-запуски. Поэтому они не используются напрямую как backlog.

Каноническим считается только утверждение, которое:

1. воспроизведено на зафиксированной ревизии;
2. подтверждено измерением, accessibility tree, DOM/CSS или целевым тестом;
3. имеет корректную нормативную или продуктовую классификацию;
4. записано в реестре подтверждённых находок.

Итог в одном абзаце

Главная карта пока не готова к релизу на узких экранах и для полноценного keyboard/modal сценария. Подтверждены два мобильных перекрытия: верхний toolbar закрывает MapLibre controls, а Changelog перекрывает действия нижних drawer-панелей. SaveModal семантически является диалогом и получает начальный фокус, но не удерживает его; общий Escape-handler закрывает одновременно модалку и нижележащий Route Builder. Также подтверждены несоответствие accessible name кнопки Gradient, контраст Logout 2.40:1, отдельные слишком малые touch targets и несколько системных долгов по motion, stacking и theme tokens. При этом заявления о «двух P0», отсутствии role="dialog", отсутствии имени fieldset, безымянной Changelog-кнопке и нарушении AA всеми кнопками 32×32 опровергнуты или требуют более узкой формулировки.

Комплект документов

Документ	Для чего читать
01 — Сверка исходных отчётов	Что в каждом отчёте верно, частично верно или ошибочно
02 — Реестр подтверждённых находок	Канонический backlog с ID, приоритетом, доказательствами и exit criteria
03 — Поэтапный план исправления	Очерёдность работ с отдельной остановкой для проверки после каждого шага
04 — Evidence и test baseline	Среда, команды, измерения, screenshots, ограничения и provenance
05 — Матрица повторного аудита	Что именно прогнать после исправлений и что означает PASS
Raw geometry baseline	Машиночитаемые размеры, пересечения, focus и contrast на baseline; source хранится в docs/public/audits/main-map-2026-07/evidence/

Принятая шкала приоритетов

Приоритет	Значение в этом аудите
P0	Crash, необратимая потеря данных или невозможность выполнить основной сценарий почти для всех пользователей без обхода
P1	Релиз-блокирующий дефект для конкретного обязательного viewport/input/a11y пути; основной control закрыт или modal interaction нарушен
P2	Значимый, но обходной UX/a11y/design-system дефект; исправляется после release blockers
P3	Улучшение, code hygiene или неподтверждённый риск, который сначала нужно измерить

P0 в исходном статическом отчёте понижен до P1: дефекты серьёзные, но не соответствуют принятому определению crash/data-loss/system-wide block.

Порядок источников истины

При расхождении используем следующий порядок:

1. воспроизводимый probe или целевая assertion на указанном commit;
2. текущая реализация и accessibility tree;
3. визуальный screenshot с известным viewport/state/theme;
4. исходные аудиторские отчёты;
5. старые общие документы проекта.

Связанные, но не канонические документы:

• docs/ui-ux/bike-track-regression-plan.md — более общий исторический план;
• docs/tech-debt/ux-ui-review-report.md — старый обзор UX/UI, не заменяет перепроверку июля 2026;
• skill audit-bike-map-home и его audit matrix/quality gates — методика, по которой нормализован этот комплект.

Как будем исправлять постепенно

Для каждого этапа действует один и тот же контракт:

1. выбрать только находки текущего этапа;
2. сначала добавить или ужесточить regression assertion, которая красная на baseline;
3. внести минимальный продуктовый fix;
4. прогнать узкие тесты и обязательные соседние состояния;
5. сохранить до/после geometry и screenshots;
6. обновить реестр и матрицу;
7. остановиться и показать результат пользователю, не переходя к следующему этапу без подтверждения.

Первый продуктовый этап — Phase 1: mobile top zone. Само создание этого комплекта — Phase 0; оно не меняет код приложения.

Правила обновления этих документов

• Не удалять исходное наблюдение после исправления: менять Open на Fixed, добавлять commit и результаты retest.
• Не повышать severity только из-за формулировки WCAG; указывать точный критерий и уровень conformance.
• Не объявлять screenshot-capture тест visual regression, если в нём нет baseline assertion/diff.
• Не считать raw color/radius/z-index literal автоматически дефектом: data visualization, brand colors, 50% circles и локальный z-index: 1/2 могут быть осознанными исключениями.
• Любой новый blocker должен иметь state, viewport, input modality, expected/actual, evidence и regression guard.