# Backlog

## Идеи

1. **Менять первый инструмент цепочки** — оценка M.
   Сейчас базовый инструмент зафиксирован при открытии страницы; хочется заменить его на другой без разборки цепочки: шаги и их параметры сохраняются, вход перечитывается. Открытый вопрос: что делать с несовместимыми параметрами (text-source ↔ file).

2. **UI-эксперимент: параметры между исходником и результатом** — оценка S/M.
   Раскладка «Исходник → Параметры → Результат» в один ряд вместо параметров отдельным блоком снизу. Проверить на узких экранах; возможно за флагом/A-B, чтобы сравнить с текущей.
   Ждет нового дизайна

3. **Сворачивать инструменты в chain** — оценка S.
   Тоггл сворачивания звена до заголовка «Шаг n: название» (превью скрываются). Состояние свёрнутости помнить в workspace-pipeline.

4. **Несколько цепочек: сохранение и загрузка** — оценка M.
   Именованные цепочки в localStorage (список, создать/переименовать/удалить), быстрое переключение. Формат экспортного JSON расширить опциональным полем имени, старые файлы читаются как безымянные.

5. **Batch-обработка архивов выбранным chain** — оценка L.
   Вход — zip-архив картинок (распаковка в браузере), прогон текущего или выбранного сохранённого chain по каждому файлу, сборка результата обратно в zip для скачивания. Зависит от п.4 (выбор цепочки) и от экспортного формата pipeline JSON; прогресс и ошибки — пофайлово.

6. **Избранные инструменты (fav tools)** — оценка S/M.
   Тоггл-звёздочка на карточках каталога, результатах поиска и в шапке страницы инструмента; список id в localStorage. Избранное показывается отдельной секцией сверху каталога и поднимается в выдаче поиска (бонус к popularity при скоринге).

7. **Конвертация формата — НЕ отдельный инструмент, а выбор в кнопке Download** — оценка M/L.
   Инструменты `convert-png-to-jpg` / `convert-png-to-webp` (и др. форматы) не должны жить как самостоятельные инструменты цепочки. Вместо этого — бесшовное внедрение выбора формата/качества прямо в кнопку/диалог **Download**: юзер скачивает результат в нужном формате (mime/ext/quality), а pipeline при этом не усложняется лишним звеном.
   Связано с планом типизации: в новом `ToolEntry<P>` под `run` в `registry-new` нет поля `output` (mime/ext/qualityParamId), которое есть у старых конвертеров — см. `plan-composite-params.md`, замечание по Фазе 2. Формат-метаданные должны переехать в понятие «формат результата» на уровне скачивания, а не отдельного инструмента.
   **Решение «не сейчас» (исследование, 2026-09):**
   - В старом UI этот паттерн уже работает: `convert-*`-инструменты не конвертируют в `run`, а только настраивают `output` (mime/ext/qualityParamId), который читает `DownloadButton` → `encode(img, mime, quality)`. То есть формат уже фактически «поле скачивания» в старом pipeline.
   - В новом preview `registry-new` поля `output` нет, `executor.worker` возвращает только пиксели, а `SchemaToolView.download()` захардкожен на `image/png` + имя `with-border.png`. Делать ретработу сейчас = параллельный спец-проект.
   - **Когда делать:** вместе с достройкой нового download/сохранения в новом UI (в рамках `plan-composite-params`, Фаза 4/UI). Тогда выбор формата встраивается в download-flow естественно, без выдёргивания отдельным проектом. Не начинать, пока не закрыта типизация pipeline.