# Согласование канона нумерации серий с провайдером тега

**Приоритет:** низкий

Косметика и редкий случай: порядок просмотра не страдает (файлы уже
пронумерованы канонически и лежат по порядку), разъезжаются только подписи серий
в Jellyfin — не то название/описание у части эпизодов. Задевает лишь тайтлы с
исторически спорным порядком, таких мало.

## Проблема

У некоторых сериалов есть несколько *легитимных* порядков серий, и разные
метабазы придерживаются разных. Каноничный пример — «Ковбой Бибоп»: в титрах и
на дисках/IMDb/TVDB порядок «сессий» (Session #1 «Asteroid Blues» … #26), а TMDB
по своей политике нумерует по **самой ранней дате эфира**. Часть серий вышла
раньше на TV Tokyo вразнобой (2, 3, 7–15, 18) — при сортировке по дате они
всплывают вперёд, и диапазон ~1–18 перемешивается. Это не баг одной базы: оба
порядка «правильные», просто разные каноны. У TMDB канон отдаётся отдельной
episode group (тип DVD/production), у TVDB — отдельными order-типами
(Aired/DVD/Absolute).

## Где это бьёт по jellybit (и где нет)

jellybit **не** матчит серии по `(season, episode)` между провайдерами —
описанного класса бага у нас нет. Номер эпизода рождается из имён файлов через
LLM (`recognize.PlanFile.Episode`), проходит без изменений в раскладку и
печатается в `SxxEyy`; метабаза даёт лишь `SeasonEpisodeCounts` для гейта
полноты пака. То есть мы **доверяем нумерации релиз-группы** и про порядок вообще
не знаем.

Настоящий риск — тихий и уже существует:

> jellybit пишет `SxxEyy` **и** тег папки `[tmdbid-…]`/`[tvdbid-…]`. Дальше
> Jellyfin по этому тегу заново скрейпит серии у *того же* провайдера. Номер в
> имени файла и порядок, который ждёт скрейпер, обязаны быть **из одного
> канона** — иначе метаданные разъедутся на именно тех сериях.

Для Бибопа: релиз почти всегда пронумерован канонически (session order). Если
матч ушёл на TVDB и написан `[tvdbid-…]` — Jellyfin скрейпит aired order TVDB,
для Бибопа = канон, всё сходится. Если матч ушёл на **TMDB** и написан
`[tmdbid-…]` — Jellyfin ждёт airing order TMDB (перемешанные 1–18), а файлы
канонические → метаданные поедут. Инвариант «канон нумерации файлов ↔ провайдер
тега» сейчас нигде не проверяется.

## Что можно сделать (варианты, не решение)

- **Минимум (дёшево, ценно):** осознать инвариант и эскалировать в review, когда
  у распознанного тайтла провайдер матча — из тех, где порядок известно спорный
  (episode groups у TMDB, absolute order у TVDB), а нумерация файлов может не
  совпадать с дефолтным скрейп-порядком этого провайдера. Лучше явный вопрос
  человеку, чем тихий разъезд.
- **Предпочтение провайдера тега:** для сериалов с известным расхождением тегать
  папку провайдером, чей дефолтный порядок совпадает с каноном файлов (обычно
  TVDB), даже если матч найден в TMDB.
- **Максимум:** знать про порядок явно — тянуть episode group (TMDB) / order-тип
  (TVDB) и сверять нумерацию файлов с выбранным каноном. Требует, чтобы у нас
  появилось понятие «канон эпизода», которого сейчас в модели нет (эпизодов как
  сущностей в БД нет, план — JSON-блоб).

## Связи

- Тот же класс «у тайтла несколько легитимных порядков», что и
  [Аниме с абсолютной нумерацией](anime-absolyutnaya-numeraciya.md) (absolute
  order через TVDB) — стоит проработать совместно, возможно как одну тему.
- [Сложные сериальные раздачи](slozhnye-serialnye-razdachi.md) — соседний пласт
  крайних случаев раскладки.
- Схема «локальная сущность каноническая, provider id — опциональный внешний
  ключ» уже заложена (draft `logical-title-model.md`, сущность `title` осознанно
  отвергнута) — эту же логику надо дотянуть до эпизодов/порядка, если пойдём в
  «максимум».
- specs/recognition.md (гейт полноты пака, крайние случаи), specs/jellyfin-layout.md
  (нумерация серий, тег провайдера), specs/review-ux.md (эскалация в review).