docs: update plans, backlog

docs/roadmap.md

@@ -1,20 +1,23 @@
 # План развития: easy-png-tools
 
-> **Статус (2026-09):** Фаза 1 (полноценный TS-сайт) в основном выполнена — сайт
-> живёт, каталог переведён в типизированный `registry`, production UI — корневые
-> маршруты. Tech debt не закрыт полностью; состав quality-проверок —
-> `docs/quality-gates.md`, архитектура кода — `docs/architecture.md`, список
-> инструментов — `docs/tools-map.md`. Текущий фокус: SEO S1-free
-> (`docs/plan-seo.md`) + продуктовые задачи из `docs/backlog.md`. Домен нужен
-> для SEO (`plan-seo.md`, S1-domain). Фазы 2–8 — будущие; фазы 9–10 спланированы
-> в `docs/plan-platform.md`.
+> **Статус:** фаза 1 выполнена — сайт живёт на типизированном реестре,
+> production UI — корневые маршруты. Текущий фокус: SEO S1-free
+> (`docs/plan-seo.md`) + открытые задачи (`docs/backlog.md`). Домен нужен для
+> SEO (S1-domain). Фазы 2–8 — будущие; 9–10 спланированы в
+> `docs/plan-platform.md`; 11 — пайплайн.
 >
-> **Нумерация фаз этого документа не совпадает с волнами разработки** (`Q*`/`C*`
-> в других документах) и не используется как идентификатор задач: ссылаться на
-> фазу, а не на номер волны.
+> **Идентификаторы.** Ссылаться на фазу этого документа. Пространства
+> идентификаторов задач: `FA-*` — правки полей и раскладки
+> (`docs/plan-fields-audit-fixes.md`); `S*` — SEO/GEO (`docs/plan-seo.md`); `A*`
+> — API, `P*` — PWA, `F*` — шрифты (`docs/plan-platform.md`); `R*` — бренд и
+> домен (`docs/plan-seo.md`, §6). Буквы `Q*`/`C*` в архивных документах
+> относятся к волнам редизайна и как идентификаторы задач не используются.
 
 ## 0. Решения
 
+Продуктовые и стратегические — здесь; устройство кода (реестр, исполнитель,
+слои) — `docs/architecture.md`, разделы 2–3.
+
 - **Набор утилит для изображений, всё в браузере** (SvelteKit +
   `adapter-static`), данные не покидают машину.
 - **Первый и главный приоритет — полностью рабочий сайт**: максимум простых
@@ -23,24 +26,12 @@
 - **Никакого wasm/Rust на этом этапе.** TS-реализация на canvas + `ImageData` —
   эталон алгоритмов, из которого позже генерируются эталонные файлы для проверки
   Rust-порта. Rust-ядро, WASM и CLI — отдельные фазы позже, когда сайт живёт.
-- **Пайплайн = JSON-список шагов** `{tool, params}`. Формат закладывается сейчас
-  и потом станет общим для браузера, wasm и CLI.
-- **Реестр инструментов** (`web/src/lib/registry/`: id, title, description,
-  category, schema, `run`) — источник истины: из него генерируются страницы,
-  формы, пайплайны. Позже — общий формат для Rust-парсера.
+- **Пайплайн = JSON-список шагов** `{tool, params}`. Формат зафиксирован этим
+  решением и станет общим для браузера, wasm и CLI; реализуется в фазе 11, не в
+  фазе 1.
 - Валидация будущего Rust-порта — эталонные файлы, сгенерированные из
   TS-реализации. Сравнение: **бит-в-бит** для чистых пиксельных операций,
-  **perceptual diff** для canvas-зависимых.
-- **Единая точка исполнения инструментов.** Страницы вызывают операции только
-  через `web/src/lib/executor/` — нигде напрямую `tool.run`. Контракт уже
-  асинхронный, поэтому:
-  - когда появятся тяжёлые MEDIUM-операции (свёртки, квантование), внутренности
-    исполнителя переезжают в Web Worker — воркер импортирует тот же чистый core
-    как TS-фолбэк, алгоритмы не дублируются, вызывающий код не меняется;
-  - в WASM-фазе тот же воркер принимает wasm-модуль и диспетчеризует по `toolId`
-    — свитч A/B из фазы 5 сводится к замене реализации внутри исполнителя;
-  - до появления MEDIUM-операций воркер не вводится: EASY-операции быстры и не
-    блокируют UI.
+  **perceptual diff** для canvas-зависимых (правила сравнения — раздел 3).
 
 ## 1. Где что лежит
 
@@ -50,46 +41,22 @@
 
 ## 2. Фазы
 
-### Фаза 1 — Полноценный TS-сайт (единственный приоритет)
+### Фаза 1 — Полноценный TS-сайт (выполнена)
 
-**Цель: сайт, которым можно пользоваться.** Без wasm, без Rust, без
-clamp-семантики (в TS это делает `Uint8ClampedArray` сам).
+Поставлено: каркас SvelteKit + static, дизайн-система и общий лейаут; ядро над
+`ImageData` (загрузка/декодирование, кодирование, операции по категориям) без
+DOM-зависимостей; типизированный реестр с универсальным рендерером страницы и
+формы; массовая реализация EASY-инструментов; i18n, темы, состояния
+загрузки/ошибок. Checkpoint достигнут: загрузил PNG → применил инструмент →
+скачал результат, без wasm.
 
-1.1 **Каркас и UX/UI.** SvelteKit + static adapter, дизайн-система (цвета,
-типографика, компоненты), общий лейаут, шапка с навигацией по категориям.
+**В фазе 1 пайплайна нет.** Workspace цепочек с сохранением в localStorage и
+экспортом в JSON — фаза 11, не поставленная часть фазы 1. Страница инструмента
+работает ровно с одной записью реестра; что именно зарезервировано под пайплайн
+(компонент `StepCard`, ключи `chain.*`), перечислено в `docs/architecture.md`,
+раздел 1 «Чего в коде нет».
 
-1.2 **Ядро.** Операции над `ImageData` (загрузка/декодирование файла,
-кодирование и скачивание, библиотека операций
-color/alpha/geometry/format/text/analyze). Всё без DOM-зависимостей внутри
-`core`.
-
-1.3 **Реестр инструментов.** Одна запись =
-`{ id, title, description, category, schema, run }`. Универсальный рендерер:
-страница инструмента и форма параметров строятся из записи реестра
-автоматически; маршруты-утилиты генерируются из реестра на билде. Новый
-инструмент = новая запись + функция `run` (рецепт — `docs/architecture.md` §8).
-
-1.4 **Пайплайн-workspace**: загрузил изображение → список шагов (инструмент +
-его параметры) → последовательное применение с превью каждого шага → скачивание
-финального результата. Добавление/удаление шагов. Сохранение пайплайнов в
-localStorage, экспорт/импорт JSON.
-
-1.5 **Массовая реализация EASY-инструментов** по категориям:
-
-- конвертация форматов (png/jpg/webp/bmp/base64/gif) и текстовые представления;
-- прозрачность и альфа-канал;
-- цвет: замена, тон, каналы, оттенки серого, инверсии;
-- геометрия и холст: resize, crop, rotate, flip, border, padding, background;
-- текст и простые эффекты: watermark, add-text, рамки, шум, pixelate;
-- анализ: размеры, палитра, проверки, просмотр. Приоритет — ширина, не глубина:
-  как можно больше простых инструментов.
-
-1.6 **Полировка.** Описания и подсказки для всех инструментов, состояния
-загрузки/ошибок, доступность, пустые состояния.
-
-**Checkpoint:** загрузил PNG → применил пайплайн из N шагов → сохранил и вернул
-пайплайн → скачал результат. Все инструменты 1.5 работают на сайте. Ни одного
-wasm.
+Незакрытый долг по фазе — в `docs/backlog.md`; он не входит в фазы 2–8 и 11.
 
 ### Фаза 2 — Тестовые PNG и генератор эталонов
 
@@ -159,6 +126,29 @@ Manifest + service worker, оффлайн-режим («работает без
 устройство»), установка как приложение. Wasm-фаз не требует, идёт после S1 из
 `plan-seo.md`. Чек-лист — `docs/plan-platform.md`, §2.
 
+### Фаза 11 — Пайплайн (цепочки шагов)
+
+Продуктовая фича, **не зависит от wasm-фаз**: работает на существующем
+исполнителе и реестре, поэтому может идти параллельно с SEO. Номер 11 выбран
+чтобы не сдвигать уже используемые ссылки на фазы 2–10.
+
+- **Формат шага** — `{tool, params}`, список шагов применяется последовательно,
+  результат предыдущего идёт в следующий. Формат зафиксирован в §0 как общий для
+  браузера, wasm и CLI, поэтому версионируется с первого дня.
+- **Первый шаг фазы:** модуль состояния цепочки + сохранение в localStorage +
+  экспорт/импорт JSON (ошибки разбора уже описаны ключами
+  `errors.badPipelineShape` / `errors.pipelineVersion` / `errors.noSteps`).
+- **Затем:** редактирование шагов (drag-n-drop, удаление, добавление), переход
+  «один инструмент → цепочка» без перезагрузки, сохранённые именованные цепочки,
+  отображение маски результата.
+- **Checkpoint:** собрал цепочку из N шагов → сохранил → вернулся позже → скачал
+  результат последнего шага, всё в браузере.
+
+Ограничения и открытые вопросы (1 → many не терминален, many → 1, частичные
+ошибки, имена частей) — `docs/backlog.md`, раздел «Идеи». Пайплайн из архивного
+UI-v1 удалён; что осталось в коде под эту фазу — `docs/architecture.md`,
+раздел 1.
+
 ## 3. Правила сравнения (для фаз 4–7)
 
 | Класс операции                                                                 | Критерий                                                                    |
@@ -187,7 +177,8 @@ Manifest + service worker, оффлайн-режим («работает без
 
 ## 5. Команды верификации
 
-Текущие команды и матрица «изменение → проверки» — `docs/quality-gates.md`
-(`pnpm verify` — быстрый gate текущего этапа). Для будущих фаз добавляются
-`cargo test` (Rust-ядро против эталонных файлов, фаза 4+) и
-`harness compare tests/reference` (сквозная сверка native + wasm, фаза 7).
+Команды текущего этапа и матрица «изменение → проверки» —
+`docs/quality-gates.md` (`pnpm verify` — быстрый gate). Команды фаз 2–8
+(`cargo test`, `harness compare`) **в проекте не существуют** и появятся вместе
+с соответствующими фазами: до этапа 2 проверять нечем, кроме `pnpm verify` и
+e2e.