jellybit/openspec/changes/archive/2026-07-03-review-source-selection/design.md

Context

Экран ревью уже умеет много: выбор кандидата (ChooseCandidate), ручной ввод id (SetProviderID), «без базы» (ClearProvider), превью текущего плана (ReviewData.Preview через layout.BuildLinks). Механика выбора источника — это overrides: выбор кандидата пиннит provider, provider_id и (если есть) title/year, после чего эффективный план пересобирается applyOverrides и печатается превью путей.

Проблемы текущего экрана — не в отсутствии операций, а в подаче:

• нейронка и кандидаты баз показаны как разные сущности (план сверху, кандидаты снизу; «без базы» — особое состояние);
• превью есть только для уже выбранного источника: чтобы увидеть пути для другого кандидата, его надо сначала выбрать (запись пиннится), т.е. «примерить вслепую».

Ограничение capability web-ui: клиент не пересчитывает доменное состояние — все доменные величины (пути, поля) приходят с сервера (требование «Клиентские взаимодействия без сборки»).

Goals / Non-Goals

Goals:

• Единый список источников: нейронка + кандидаты баз + добавленные вручную, один активный.
• Предпросмотр полей (тип/название/год) и целевых путей для любого источника до его выбора, посчитанный на сервере.
• Ручное добавление источника по id/URL как строки списка.
• Переиспользовать существующую логику (applyOverrides + layout.BuildLinks), не дублируя правила именования.

Non-Goals:

• Fetch деталей записи из метабазы (режиссёр и пр.) — только резервируем место в UI.
• Сила совпадения кандидата (per-candidate score) и сортировка/подсветка списка по ней — сегодня у кандидата такого поля нет; список берём в порядке сбора. Отдельная идея беклога (там же — пересмотр процесса распознавания/матчинга).
• Изменение решения «авто vs review» и модели уверенности — не трогаем: авто по-прежнему только при единственном сильном матче + валидации, иначе review; фича работает внутри уже наступившего review.
• Отдельный capability review и перекройка домена метабаз — отдельная задача беклога.
• Редактор маппинга «файл → серия» и правки в Telegram.

Decisions

0. Двухуровневая модель ревью сохраняется, нового подтверждения нет

В ревью два независимых шага, оба остаются как есть:

1. Выбор источника — кнопки «выбрать» / «Задать id» / «Без базы» (POST → ChooseCandidate/SetProviderID/ClearProvider) фиксируют матч, записывая overrides. Файлы не раскладываются, лишь пересобирается план.
2. «Применить» (POST → Apply) — единственный шаг, создающий хардлинки.

Фича добавляет только предпросмотр до шага 1: увидеть поля и целевые пути каждого источника, не нажимая «выбрать» (не трогая БД). Семантику «выбрать» и «Применить» не меняем, новых кнопок-подтверждений не вводим.

1. Предпросмотр считается на сервере эфемерно, без записи overrides

Добавляем в worker чистый расчёт: по текущему плану и гипотетическому источнику (provider, provider_id, опц. title/year) собрать эффективные поля и []layout.Link, не записывая overrides в БД. Технически — тот же applyOverrides + layouter.BuildLinks(toLayoutPlan(...)), что и в ReviewData, но поверх копии плана с временными пинами источника; в БД ничего не пишем.

ReviewData расширяется срезом «источник → (поля, превью путей, активен ли)» для нейронки и каждого кандидата. Транспорт рендерит их строками списка.

• Почему так, а не «выбрать → посмотреть → отменить»: выбор сейчас пиннит запись (пишет overrides) и меняет сохранённый матч; «примерка» не должна трогать состояние (инвариант «предпросмотр ничего не раскладывает и не фиксирует»).
• Альтернатива — отдельный эндпоинт GET /review/{id}/preview?source=…, отдающий htmx-фрагмент: отвергнута для известных источников — превью считается быстро и без сети (BuildLinks — чистая работа с путями), их дешевле посчитать сразу и вложить в страницу; лишний раундтрип на каждое наведение не нужен.

1a. Единая деривация «источник → набор overrides» (гарантия preview == apply)

Проблема, найденная на ревью дизайна. Пины ovrTitle/ovrYear пишутся SetOverride и не удаляются (в store нет DeleteOverride). ChooseCandidate пиннит title/year только при непустых полях кандидата (review.go:573-579), а ClearProvider их вообще не трогает (review.go:624-640). Значит после выбора кандидата «Fargo/2014» и последующего переключения на нейронку или на ручной кандидат без title запиненный ovrTitle=Fargo остаётся. Тогда applyOverrides (review.go:742) при Apply возьмёт Fargo, а эфемерное превью источника без собственного title покажет title из плана → пути превью ≠ пути применения. Это и латентный баг текущего кода (переключение кандидатов тянет чужой title).

Решение. Ввести одну чистую функцию «источник → полный самосогласованный набор overrides» и использовать её и в превью, и в коммите:

• источник-кандидат с title/year → пиннит их; без title/year → пишет пустую строку в ovrTitle/ovrYear (в applyOverrides пустая строка трактуется как «нет override», review.go:742,745 — DeleteOverride не нужен, берётся значение плана);
• источник-нейронка (ClearProvider) → provider=none и пустые ovrTitle/ovrYear (поля из плана распознавания).

Так каждый источник даёт детерминированный эффективный план; превью считается тем же набором overrides, что запишет выбор → preview == apply по построению.

• Затрагивает поведение worker (ChooseCandidate/ClearProvider теперь очищают title/year), а не только web-ui. Это осознанно: спека остаётся в web-ui (наблюдаемое — «превью == применение» и «переключение не тянет чужие поля»), а правка команд ревью — реализация. Заодно чиним латентный баг.
• Альтернатива — превью «симулирует» унаследованные пины (показывать чужой title у нейронки): отвергнута — противоречит принципу «нейронка = поля распознавания» и путает пользователя.

2. Клиент только показывает предпосчитанное, не считает пути

Превью всех источников предпосчитываем на сервере и вкладываем в страницу (данных немного — кандидатов мало, порога/ленивой загрузки не вводим). Клиент лишь раскрывает/скрывает предпосчитанный блок строки по клику (нативный <details> или минимальный vanilla-JS) — никакого доменного пересчёта на клиенте, соблюдаем требование web-ui.

UI-модель: секция «Раскладка» остаётся отдельной и показывает пути активного источника (как сейчас); раскрываемое инлайн-превью в строке — для сравнения неактивных источников до выбора. Фактическая смена активного источника (пиннинг) — по явному действию формой (раундтрип), как сейчас.

3. Нейронка — синтетическая строка, а не особый режим

Строку «распознано нейронкой» синтезируем из сырого плана распознавания (provider = none): её поля — то, что дал LLM без базы, её превью — раскладка без тега провайдера. Выбор этой строки = существующий ClearProvider. Так «без базы» перестаёт быть отдельным состоянием UI и становится обычной строкой списка.

4. Ручной источник — кандидат в том же списке

Ручной ввод (id или URL) на входной границе httpapi парсим в (provider, provider_id). Допустимые провайдеры — tmdb, tvdb, imdb (набор согласован с providerTag/providerURL; tvmaze — только источник автопоиска, вручную не вводится). Добавляем как строку списка: сохраняем metadata_candidate с этим provider/provider_id и (если дан) url; title/year — пустые (деталей не тянем). Дедуп по provider:id: если такой источник уже в списке — не плодим строку, а выбираем существующую. Такой кандидат участвует в выборе и предпросмотре наравне с автонайденными; выбор — тот же ChooseCandidate (с очисткой title/year по решению 1a).

Парсинг URL реалистичен не для всех баз. providerURL строит TVDB как thetvdb.com/dereferrer/series/{numeric_id}, но с сайта пользователь копирует thetvdb.com/series/{slug} — без числового id. Поэтому обещаем: URL — для TMDB/IMDb, для TVDB — ручной ввод числового id (slug из URL не распознаём). Список принимаемых паттернов фиксируем в реализации как обратный к providerURL.

• Превью ручного источника корректно и без title/year из базы: имя папки берётся из title плана, а от источника меняется лишь тег провайдера в пути. Значит «предпросмотр путей» для ручного кандидата полноценен.
• Альтернатива — просто пиннить SetProviderID без строки в списке: отвергнута — тогда ручной источник не «переключаемый» наравне с остальными, что противоречит принципу единого списка.

5. Режиссёр — зарезервированное место, источник позже

В предпросмотре полей выводим строку «Режиссёр» пустой (прочерк). Fetch деталей из метабазы — отдельная задача; при появлении источника (детали по id или парсинг из контекста загрузки) заполняем это же место.

Risks / Trade-offs

• [Рассинхрон превью и применения] Превью и реальная раскладка должны идти одной логикой. → Оба используют layout.BuildLinks/naming и одну деривацию «источник → overrides» (решение 1a); в тестах проверяем равенство путей превью и применения (требование web-ui «Превью совпадает с реальной раскладкой», сценарий «Переключение источника не тянет чужие поля»).
• [Залипший override title/year] Пины title/year не удаляются и могут утечь между источниками (латентный баг). → Решение 1a: выбор источника пишет полный самосогласованный набор (пустая строка = сброс к плану).
• [Раздувание страницы] Предпосчёт превью для всех кандидатов кладёт N наборов путей в HTML. → Кандидатов немного (потолок сбора уже есть в recognition); BuildLinks без сети. Приемлемо; если станет тяжело — ленивый htmx-фрагмент (решение 1, альтернатива) как эволюция.
• [Ручной кандидат с пустыми title/year] Строки списка и матч-ссылка должны переживать пустые поля. → matchURL уже строит URL из provider/id; заголовок берём из плана. Проверить рендер строки без title/year.
• [Дубль ручного и автокандидата] Пользователь может ввести id, уже присутствующий в списке. → Дедуп по provider:id при добавлении (как в сборе кандидатов): не плодим строку, просто выбираем существующую.

Migration Plan

• Данные: миграций схемы не требуется — ручной кандидат ложится в существующую metadata_candidate (title/year nullable уже так). Новый источник строки — пользовательское действие, обратная совместимость полная.
• Откат: изменения ограничены страницей ревью и добавочным методом предпросмотра в worker; откат — возврат прежнего шаблона/обработчика, данные не затрагиваются.

Open Questions

Блокирующих открытых вопросов нет. Оставшийся детерминированный на реализацию пункт — точный список принимаемых URL-паттернов ручного ввода (обратный к providerURL: themoviedb.org/{movie,tv}/{id}, imdb.com/title/{id}; TVDB — числовой id, не slug), см. решение 4.