flights_web/docs/user-stories-7-errors-accessibility.md

# Пользовательские истории: Обработка ошибок, граничные случаи и доступность

## US-85: Ошибка 404 — Страница не найдена

**Цель:** Пользователь видит понятное сообщение при переходе на несуществующий URL и может быстро вернуться к рабочему разделу.

**Путь клиента:**

1. **Переход по неверному URL — ввод или клик по битой ссылке** — пользователь вводит `/onlineboard/invalid` или попадает на устаревшую ссылку.
2. **Router сопоставляет маршрут — wildcard redirect** — роутер не находит соответствия и перенаправляет на `/error/404`.
3. **Страница ошибки загружается — ErrorPageComponent** — компонент читает `errorCode`, `title`, `description` из `route.snapshot.data`.
4. **Отображение сообщения — код и текст** — на экране виден код «404», заголовок `PAGE404.HEADER` и описание `PAGE404.DESCRIPTION`.
5. **Скрытие баннеров хоста — hideAflComponents()** — страница скрывает `.afl-component--banners` на время показа ошибки.
6. **Поле поиска на странице ошибки** — на странице отображается текстовое поле с кнопкой поиска; ввод запроса и клик по кнопке открывает результаты поиска на aeroflot.ru в новой вкладке.
7. **Возврат к работе — переход на главную** — пользователь нажимает кнопку и возвращается на `/onlineboard` или в поиск.

**Критерии приёмки:**

- ✅ Маршрут `/error/404` отображает страницу с кодом 404.
- ✅ Любой неизвестный URL приводит к редиректу на `/error/404`.
- ✅ Заголовок и описание берутся из переводов (`PAGE404.*`).
- ✅ Поле поиска позволяет выполнить поиск на aeroflot.ru из страницы ошибки (открывается в новой вкладке).
- ✅ Кнопка «На главную» возвращает на рабочий раздел.
- ✅ Баннеры хост-приложения скрыты на время показа ошибки и восстанавливаются при уходе со страницы (`ngOnDestroy`).

**Примечание:** URL онлайн-табло — `/onlineboard` (без дефиса). Компонент ошибки — общий для 404 и 500, различие задаётся через `route.data`.

---

## US-86: Ошибка 500 — Внутренняя ошибка сервера

**Цель:** Пользователь получает понятное сообщение при серверной ошибке и возможность повторить запрос или вернуться на главную.

**Путь клиента:**

1. **Действие пользователя — поиск или загрузка расписания** — пользователь запускает поиск рейсов.
2. **Ошибка на бэкенде — HTTP 5xx** — API возвращает 500 либо приложение роутится на `/error/500` как default.
3. **Показ страницы ошибки — ErrorPageComponent с errorCode=500** — читаются `PAGE500.HEADER` и `PAGE500.DESCRIPTION`.
4. **Скрытие баннеров — hideAflComponents()** — сторонние компоненты хоста временно скрываются.
5. **Действия пользователя — повтор или возврат** — пользователь может повторить запрос или перейти на главную.
6. **Восстановление — ngOnDestroy** — при уходе со страницы баннеры возвращаются в прежнее состояние.

**Критерии приёмки:**

- ✅ При неизвестной ошибке приложение показывает `/error/500` (дефолтный редирект с `/error`).
- ✅ На странице отображается код «500» и локализованные `PAGE500.*` строки.
- ✅ Кнопка «На главную» доступна и работает.
- ✅ Баннеры хоста скрываются и корректно восстанавливаются.
- ✅ Страница не ломает верстку хост-приложения.

**Примечание:** URL онлайн-табло — `/onlineboard` (без дефиса). В Angular-источнике ErrorPage один компонент на оба кода; дифференциация — через `route.data`.

---

## US-88: Timeout при загрузке данных

**Цель:** Пользователь видит корректное состояние, если ответ сервера долго не приходит, и может отменить или повторить запрос.

**Путь клиента:**

1. **Запуск запроса — пользователь выполняет поиск** — отправляется запрос на API рейсов/расписания.
2. **Отображение спиннера — loading state** — UI показывает индикатор загрузки до получения ответа.
3. **Ожидание превышает лимит — длительное отсутствие ответа** — сеть медленная или сервер не отвечает.
4. **Обработка таймаута — http-cancel / error handler** — запрос завершается с ошибкой, приложение переходит в состояние ошибки.
5. **Сообщение пользователю — понятный текст** — отображается сообщение о проблеме соединения и предложение повторить.
6. **Повтор или отмена — пользователь управляет ситуацией** — можно повторить поиск либо отказаться.

**Критерии приёмки:**

- ✅ Во время загрузки виден индикатор прогресса.
- ✅ При длительном отсутствии ответа приложение не «зависает».
- ✅ После таймаута пользователь видит понятное сообщение об ошибке.
- ✅ Доступно действие «Повторить».
- ✅ Отменённые запросы не обновляют UI задним числом.

**Примечание:** Сценарий тестовый — описывает ожидаемое поведение; в Angular-источнике явного лимита таймаута нет, обработка опирается на общий error handler и `HttpCancelService`.

---

## US-89: Некорректный ввод (специальные символы)

**Цель:** Система безопасно обрабатывает ввод со специальными символами и не допускает XSS.

**Путь клиента:**

1. **Ввод спецсимволов — пользователь печатает `<script>`, кавычки, HTML-теги** — данные попадают в поле поиска/фильтра.
2. **Санитизация — Angular/React встроенная защита** — фреймворк экранирует значения при выводе.
3. **Валидация — проверка на валидные коды IATA или названия** — некорректные значения не проходят в запрос к API.
4. **Безопасное отображение — текст как текст** — символы показываются экранированными, без исполнения.
5. **Ответ пользователю — подсказка об ошибке** — при невалидном вводе показывается сообщение.

**Критерии приёмки:**

- ✅ Ввод `<script>`-тегов не приводит к исполнению JS.
- ✅ HTML-теги отображаются как текст, а не как разметка.
- ✅ Невалидные IATA/названия отклоняются до отправки на сервер.
- ✅ Ответ сервера также экранируется при выводе.
- ✅ Атрибуты DOM не собираются из пользовательского ввода напрямую.

**Примечание:** Тестовый сценарий безопасности; в кодовой базе обеспечивается framework-уровнем (автоэкранирование).

---

## US-90: Невалидная комбинация параметров

**Цель:** Система валидирует комбинации параметров поиска и предотвращает бессмысленные запросы.

**Путь клиента:**

1. **Пользователь заполняет форму — города, даты, направление** — вводятся параметры поиска.
2. **Обнаружение конфликта — валидаторы формы** — пользователь выбирает одинаковый город для «Откуда» и «Куда», либо прошлую дату, либо недопустимый диапазон.
3. **Блокировка отправки — disable submit** — кнопка «Найти» остаётся неактивной или поиск не запускается.
4. **Отображение ошибок — подсказки под полями** — рядом с полем выводится причина ошибки.
5. **Исправление — пользователь меняет параметры** — после корректного ввода ошибки очищаются и поиск становится доступен.

**Критерии приёмки:**

- ✅ Совпадающие города «Откуда»/«Куда» отклоняются.
- ✅ Даты в прошлом недопустимы для выбора.
- ✅ Недопустимый диапазон дат показывает сообщение об ошибке.
- ✅ Пока форма невалидна, кнопка поиска неактивна.
- ✅ Сообщения об ошибках локализованы.

**Примечание:** Тестовый сценарий; в Angular-источнике правила валидации частично присутствуют в `shared/services/validators`.

---

## US-91: Пустой результат поиска

**Цель:** Пользователь получает понятное сообщение, когда по запросу нет рейсов.

**Путь клиента:**

1. **Поиск — пользователь задаёт параметры** — выбирает города и даты, запускает поиск.
2. **Запрос к API — корректные параметры** — валидация пройдена, запрос уходит на сервер.
3. **Пустой ответ — нет рейсов** — API возвращает пустой список для указанных условий.
4. **Отображение empty state — сообщение «Рейсов не найдено»** — вместо списка показывается информационный блок.
5. **Подсказки пользователю — альтернативы** — предлагается изменить дату/направление или сбросить фильтры.

**Критерии приёмки:**

- ✅ Пустой массив результатов не показывает «сломанный» UI.
- ✅ Отображается локализованное сообщение об отсутствии рейсов.
- ✅ Пользователь может легко изменить параметры поиска.
- ✅ Активные фильтры не блокируют новый поиск.
- ✅ Состояние empty отличается визуально от состояния ошибки.

---

## US-92: Unicode символы в вводе

**Цель:** Система корректно отображает и обрабатывает строки в Unicode (кириллица, CJK, арабский, emoji).

**Путь клиента:**

1. **Ввод Unicode — пользователь печатает нелатинские символы** — в поле поиска появляется текст в разных алфавитах.
2. **Передача в API — UTF-8 кодирование** — запрос корректно кодирует параметры.
3. **Ответ сервера — Unicode в названиях** — города и аэропорты возвращаются с корректной кодировкой.
4. **Отображение — шрифты и вёрстка** — названия видны без «кракозябр».
5. **Фильтрация и поиск — регистронезависимое сравнение** — совпадения находятся вне зависимости от регистра и алфавита.

**Критерии приёмки:**

- ✅ Кириллица, CJK и арабский отображаются корректно.
- ✅ Emoji не ломают верстку (допустимо отклонить при валидации IATA).
- ✅ Поиск работает с Unicode-запросами.
- ✅ Параметры корректно кодируются в URL.
- ✅ Ответ API с Unicode-строками рендерится без повреждений.

---

## US-93: Очень длинные имена городов и аэропортов

**Цель:** Интерфейс не ломается при очень длинных названиях городов, аэропортов и авиакомпаний.

**Путь клиента:**

1. **Загрузка данных — длинное название** — API возвращает запись с длинным именем (например, полное название аэропорта).
2. **Отображение в списке — ограниченная ширина** — карточка или строка имеет фиксированную ширину.
3. **Обрезка текста — CSS ellipsis** — длинный текст усекается с многоточием.
4. **Полное имя — tooltip/title** — при наведении доступно полное название.
5. **Адаптив — разные breakpoints** — поведение сохраняется на мобильных и десктопе.

**Критерии приёмки:**

- ✅ Длинные названия не выходят за границы контейнера.
- ✅ Текст усекается с видимым многоточием.
- ✅ Полное название доступно через tooltip или аналогичный механизм.
- ✅ Верстка соседних элементов не сдвигается.
- ✅ Поведение работает на всех breakpoint.

**Примечание:** Тестовый сценарий устойчивости; в кодовой базе опирается на CSS-классы текстовых ячеек.

---

## US-94: Быстрая последовательность поисков

**Цель:** Система корректно обрабатывает быстро выполняемые подряд запросы и показывает результат последнего.

**Путь клиента:**

1. **Пользователь запускает поиск — первый запрос** — уходит HTTP-запрос на сервер.
2. **Смена параметров — новый запрос до завершения предыдущего** — пользователь меняет город/дату и снова нажимает поиск.
3. **Отмена предыдущего — HttpCancelService** — незавершённые запросы отменяются через cancel-механизм.
4. **Обработка последнего — применение свежего ответа** — в UI показывается результат только последнего запроса.
5. **Защита от гонок — state не перезаписывается старым ответом** — отменённые запросы не обновляют список.

**Критерии приёмки:**

- ✅ Отменённый запрос не обновляет UI.
- ✅ В результатах отображается ответ последнего запроса.
- ✅ Индикатор загрузки виден до завершения последнего запроса.
- ✅ Быстрые клики не приводят к миганию результатов.
- ✅ Нет утечек подписок/обработчиков.

**Примечание:** В Angular-источнике есть `shared/services/http-cancel.service.ts`, обеспечивающий отмену предыдущих запросов.

---

## US-95: Клавиатурная навигация

**Цель:** Пользователь может полностью управлять приложением только с клавиатуры.

**Путь клиента:**

1. **Навигация по Tab — обход интерактивных элементов** — фокус проходит по полям, кнопкам и ссылкам в логичном порядке.
2. **Активация — Enter/Space** — кнопки и ссылки активируются клавиатурой.
3. **Отправка формы — Enter в поле поиска** — запускает поиск без использования мыши.
4. **Закрытие попапов — Escape** — выпадающие списки и диалоги закрываются по Esc.
5. **Навигация по спискам — стрелки** — в dropdown и списках работает перемещение стрелками.
6. **Видимый фокус — focus ring** — текущий элемент визуально выделен.

**Критерии приёмки:**

- ✅ Tab-порядок соответствует визуальному порядку элементов.
- ✅ Нет «ловушек» фокуса вне диалогов.
- ✅ Enter отправляет форму поиска.
- ✅ Escape закрывает выпадающие меню и диалоги.
- ✅ На всех интерактивных элементах виден focus-индикатор.

**Примечание:** Тестовый сценарий доступности; поведение собирается из встроенной семантики и ARIA.

---

## US-96: Читатели экрана (ARIA-метки)

**Цель:** Приложение корректно работает со screen reader (NVDA, VoiceOver, JAWS).

**Путь клиента:**

1. **Загрузка страницы — screen reader озвучивает заголовок** — `<title>` и `h1` корректно читаются.
2. **Формы — label и aria-label** — каждое поле связано с текстовой меткой.
3. **Кнопки и иконки — aria-label для icon-only** — иконочные кнопки имеют текстовую аннотацию.
4. **Динамический контент — aria-live** — появление результатов поиска или ошибок объявляется.
5. **Списки и таблицы — корректные роли** — расписание использует семантическую структуру.
6. **Изображения — alt** — декоративные скрыты (`alt=""`), смысловые имеют описание.

**Критерии приёмки:**

- ✅ Все поля форм имеют связанный label или aria-label.
- ✅ Icon-only кнопки озвучиваются со смысловой подписью.
- ✅ Динамические обновления (результаты, ошибки) объявляются screen reader.
- ✅ Используется семантический HTML (`button`, `nav`, `main`, `h1`–`h3`).
- ✅ Изображения имеют корректный alt.

**Примечание:** Тестовый сценарий WCAG; конкретная реализация ARIA — часть компонентного слоя.

---

## US-98: Фокусное кольцо (focus-visible)

**Цель:** Пользователь, навигирующий с клавиатуры, всегда видит, какой элемент находится в фокусе.

**Путь клиента:**

1. **Навигация Tab — пользователь переходит между элементами** — каждое нажатие Tab смещает фокус.
2. **Рендеринг focus ring — CSS `:focus-visible`** — обводка появляется только при клавиатурной навигации.
3. **Скрытие при клике мышью — `:focus:not(:focus-visible)`** — кольцо не отображается при обычных кликах.
4. **Контрастность — видимое кольцо** — цвет и толщина заметны на фоне.
5. **Единообразие — стиль одинаков для всех интерактивных элементов** — кнопки, ссылки, поля ввода.

**Критерии приёмки:**

- ✅ При Tab-навигации фокус виден на всех интерактивных элементах.
- ✅ При кликах мышью кольцо не появляется (используется `:focus-visible`).
- ✅ Контраст кольца соответствует WCAG AA.
- ✅ Стиль фокуса согласован между компонентами.
- ✅ Ни один интерактивный элемент не остаётся без индикатора фокуса.

**Примечание:** Тестовый сценарий доступности, реализуется через глобальные CSS-стили.

---

## US-99: Масштабирование текста (zoom)

**Цель:** Пользователь может увеличивать текст/страницу до 200% без потери функциональности.

**Путь клиента:**

1. **Запуск zoom — Ctrl + / Cmd +** — браузер увеличивает масштаб страницы.
2. **Адаптация текста — относительные единицы** — `rem`/`em` корректно пересчитываются.
3. **Адаптивный layout — reflow** — сетка перестраивается под новую ширину.
4. **Отсутствие горизонтального скролла — контент остаётся в viewport** — до 200% без обрезки.
5. **Интерактив доступен — все кнопки и поля видны** — форма поиска и результаты пригодны к использованию.

**Критерии приёмки:**

- ✅ Увеличение до 200% не ломает layout.
- ✅ Нет горизонтального скролла на типовых breakpoint.
- ✅ Текст не перекрывается и не обрезается.
- ✅ Все интерактивные элементы остаются доступными.
- ✅ Relative units используются для размеров текста и отступов.

**Примечание:** Тестовый сценарий WCAG 1.4.4; реализация зависит от CSS.

---

## US-100: Сенсорная навигация (touch)

**Цель:** Мобильные пользователи могут полностью управлять приложением пальцами.

**Путь клиента:**

1. **Touch-жесты — tap, swipe, pinch** — пользователь взаимодействует с экраном.
2. **Размер целей — минимум 44×44px** — кнопки и ссылки достаточны для попадания пальцем.
3. **Интервалы — достаточные отступы** — соседние цели не кликаются случайно.
4. **Альтернативы жестам — обычные кнопки** — любое действие через swipe дублируется кнопкой.
5. **Отсутствие hover-only — tap доступен всегда** — функциональность не скрыта за hover.

**Критерии приёмки:**

- ✅ Touch-таргеты не меньше 44×44px.
- ✅ Расстояние между целями предотвращает случайные нажатия.
- ✅ Все функции доступны без hover.
- ✅ Жесты (где используются) имеют альтернативу обычным тапом.
- ✅ Скролл и pinch-zoom работают штатно.

**Примечание:** Тестовый сценарий мобильной доступности.

---

## US-101: Персистентное состояние (StateService)

**Цель:** Ключевое состояние приложения сохраняется между переходами и переживает перезагрузку страницы там, где это предусмотрено.

**Путь клиента:**

1. **Сохранение — StateService.set(key, data)** — страница кладёт состояние в Map по ключу.
2. **Переход между разделами — навигация** — пользователь уходит с экрана и возвращается.
3. **Чтение — StateService.get(key)** — экран восстанавливает данные из сервиса.
4. **Параметры поиска в URL — query params** — часть состояния синхронизируется через URL.
5. **Перезагрузка страницы — refresh** — параметры из URL позволяют восстановить форму и запустить поиск.
6. **Очистка — StateService.delete(key)** — при необходимости состояние сбрасывается.

**Критерии приёмки:**

- ✅ `StateService.set`/`get`/`delete` работают как in-memory Map хранилище.
- ✅ При возврате на страницу её состояние восстанавливается из сервиса.
- ✅ Параметры поиска присутствуют в URL и читаются при старте.
- ✅ После refresh форма заполняется из URL-параметров.
- ✅ Данные не «текут» между независимыми ключами.

**Примечание:** В Angular-источнике `StateService` — простой in-memory Map (`shared/services/state.service.ts`), он не использует localStorage; персистенция между перезагрузками достигается через URL.

---

## US-102: История браузера (back/forward)

**Цель:** Кнопки браузера «Назад» и «Вперёд» корректно перемещают пользователя по состояниям приложения.

**Путь клиента:**

1. **Переход по разделам — пользователь открывает страницы** — роутер добавляет записи в history.
2. **Обновление URL — query params отражают фильтры** — параметры поиска и сортировки видны в URL.
3. **Нажатие Back — popstate** — роутер восстанавливает предыдущее состояние.
4. **Нажатие Forward — возврат к следующему состоянию** — аналогично, без потери данных.
5. **Синхронизация UI — чтение query params** — фильтры и форма обновляются под URL.

**Критерии приёмки:**

- ✅ Каждая значимая навигация создаёт запись в history.
- ✅ Back возвращает на предыдущий URL с корректным состоянием.
- ✅ Forward работает симметрично.
- ✅ Query params читаются при навигации и обновляют UI.
- ✅ Глубокие ссылки открывают нужный раздел напрямую.

**Примечание:** В Angular-источнике навигация — стандартный Angular Router; синхронизация через query params.

---

## US-103: Обработка больших объёмов данных

**Цель:** Приложение остаётся отзывчивым при отображении длинных списков рейсов/расписания.

**Путь клиента:**

1. **Загрузка данных — большой ответ API** — приходит расписание с сотнями рейсов.
2. **Рендер списка — оптимизированный вывод** — используется виртуализация либо разумная пагинация/ограничение.
3. **Скролл — плавная прокрутка** — браузер не проседает по FPS.
4. **Фильтрация и сортировка — мгновенная реакция** — действия не вызывают полной перерисовки.
5. **Освобождение памяти — unsubscribe при уходе** — подписки и кэши корректно очищаются.

**Критерии приёмки:**

- ✅ Список из сотен элементов рендерится без ощутимых задержек.
- ✅ Скролл остаётся плавным на типовых устройствах.
- ✅ Фильтрация и сортировка не «замораживают» UI.
- ✅ При уходе со страницы не остаётся зомби-подписок.
- ✅ Память приложения не растёт неограниченно при повторных поисках.

**Примечание:** Тестовый сценарий производительности; конкретный механизм (виртуализация/пагинация) — на выбор реализации.

---

## US-104: Кэширование ответов (CacheService 30s)

**Цель:** Повторные одинаковые запросы к API обслуживаются из кэша, чтобы снизить нагрузку и ускорить отклик.

**Путь клиента:**

1. **Первый запрос — CacheService.get(key, options)** — кэш пуст, запрос уходит на сервер.
2. **Сохранение ответа — CacheService.set(key, options, result)** — результат кладётся в `requestsMap` по ключу.
3. **Таймер инвалидации — setTimeout 30s** — через `INVALID_TIMEOUT = 30 * 1000` запись удаляется.
4. **Повторный запрос в пределах окна — быстрый ответ** — `get()` возвращает закэшированный `result`.
5. **Истечение 30 секунд — удаление ключа** — следующий запрос снова идёт на сервер.
6. **Ручная инвалидация — CacheService.delete(key)** — позволяет сбросить запись принудительно.

**Критерии приёмки:**

- ✅ `CacheService.set/get/delete` работают по in-memory Map.
- ✅ Таймаут инвалидации — 30 секунд (`INVALID_TIMEOUT = 30 * 1000`).
- ✅ Повторный запрос в пределах окна не порождает сетевой вызов.
- ✅ После таймаута запись удаляется и следующий запрос уходит на сервер.
- ✅ `delete(key)` очищает указанную запись вручную.

**Примечание:** Источник истины — `shared/services/cache.service.ts`. Таймер на каждую `set()` перезапускается (`clearTimeout`), поэтому окно отсчитывается от последнего обновления записи.

---

## US-105: Обновление данных в реальном времени (SignalR)

**Цель:** Данные онлайн-табло автоматически обновляются при поступлении серверных событий, чтобы пользователь видел актуальную информацию без ручной перезагрузки.

**Путь клиента:**

1. **Подключение к хабу** — при загрузке страницы результатов или деталей рейса `RefreshBoardService` / `RefreshService` инициализирует SignalR-соединение с `environment.urlForTrackerHub`.
2. **Подписка на события** — сервис подписывается на события `RefreshDate` (для списка рейсов) или `Refresh` (для деталей рейса по ID).
3. **Тихое обновление** — при поступлении события данные перезагружаются с флагом `silent`, без показа индикатора загрузки, чтобы не отвлекать пользователя.
4. **Оверлей устаревших данных** — `FadeService` запускает таймер; при бездействии пользователя в течение `environment.refreshPauseMin` минут поверх страницы появляется полупрозрачный оверлей с сообщением «Данные устарели, обновите страницу!».
5. **Автоматический редирект** — если бездействие превышает `environment.refreshStopMin` минут, приложение перенаправляет пользователя на главную страницу (`/`).
6. **Очистка** — при уходе со страницы (`ngOnDestroy`) подписки SignalR и таймеры `FadeService` очищаются.

**Критерии приёмки:**

- ✅ На страницах результатов онлайн-табло устанавливается SignalR-соединение для получения обновлений.
- ✅ На странице деталей рейса подписка привязана к конкретному ID рейса.
- ✅ Обновление данных происходит без видимого индикатора загрузки (silent reload).
- ✅ После `refreshPauseMin` минут бездействия показывается полноэкранный оверлей (z-index 9999, полупрозрачный фон).
- ✅ После `refreshStopMin` минут бездействия происходит автоматический редирект на главную.
- ✅ SignalR-подписки и таймеры корректно очищаются при уничтожении компонентов.

**Примечание:** Функция актуальна только для онлайн-табло (реальное время). Расписание и карта полётов не используют SignalR. `FadeService` создаёт overlay программно через DOM API (`document.createElement`).

---

## US-106: Встроенный чат-бот

**Цель:** Пользователь может воспользоваться чат-ботом для получения справочной информации.

**Путь клиента:**

1. **Инициализация** — компонент `chat-bot` в `ngAfterViewInit` динамически создаёт `<script>` элемент с URL из `environment.chatBotScript`.
2. **Загрузка виджета** — скрипт монтируется к `#app-chat-bot-container`, загружая внешний чат-виджет.
3. **Использование** — после загрузки пользователь видит виджет чата и может задавать вопросы.

**Критерии приёмки:**

- ✅ Чат-бот загружается динамически через внешний скрипт из `environment.chatBotScript`.
- ✅ Виджет монтируется в контейнер `#app-chat-bot-container`.
- ✅ Ошибки загрузки скрипта не ломают остальной интерфейс.

**Примечание:** URL скрипта настраивается через конфигурацию окружения.

---

## US-107: Canonical URL и SEO мета-теги по страницам

**Цель:** Каждая страница приложения имеет корректные canonical URL и уникальные SEO мета-теги для правильной индексации поисковыми системами.

**Путь клиента:**

1. **Установка canonical** — `CanonicalService` формирует `<link rel="canonical">` для текущей страницы.
2. **Мета-теги по разделам** — каждый раздел (онлайн-табло, расписание, карта полётов) имеет собственные компоненты мета-тегов с уникальными ключами `SEO.*`:
   - Онлайн-табло: стартовая, результаты (по номеру/маршруту/отправлению/прибытию), детали рейса
   - Расписание: стартовая, результаты, детали рейса
   - Карта полётов: стартовая
3. **Динамические значения** — для страниц результатов и деталей мета-теги включают названия городов, даты и номера рейсов.
4. **OpenGraph** — для страниц деталей формируются `og:title`, `og:description`, `og:image` теги.
5. **noRobots** — на страницах с динамическими параметрами (результаты, детали) установлен `noRobots: true` для предотвращения индексации.

**Критерии приёмки:**

- ✅ Canonical URL корректен для каждой страницы.
- ✅ Мета-теги `title` и `description` уникальны для каждого типа страницы.
- ✅ Динамические страницы включают контекст (город, дата, номер рейса) в мета-теги.
- ✅ Стартовые страницы разделов индексируются (`noRobots: false`), страницы результатов — нет.
- ✅ OpenGraph-теги формируются для страниц деталей.

**Примечание:** Компоненты мета-тегов наследуют от `MetaBaseComponent` и переопределяют `translateTitle()`/`translateDescription()`.

---

## US-108: Отображение версии API (debug-режим)

**Цель:** В debug-режиме разработчик может видеть текущую версию API для диагностики.

**Путь клиента:**

1. **Проверка флага** — `AppVersionComponent` проверяет `settings.showDebugVersion` из `APP_SETTINGS`.
2. **Запрос версии** — если флаг включён, `NetworkService.getApiVersion()` загружает номер версии.
3. **Отображение** — версия выводится компонентом `app-version` рядом с навигацией.
4. **Скрытие баннера** — при включённом debug-режиме скрывается элемент `.banner--top`.

**Критерии приёмки:**

- ✅ В обычном режиме версия не отображается.
- ✅ При `showDebugVersion = true` показывается номер версии API.
- ✅ Компонент `app-show-debug` условно рендерит debug-информацию.

**Примечание:** Предназначено для разработки и тестирования, не для конечных пользователей.

---