style: format docs markdown

docs/roadmap.md

@@ -1,23 +1,39 @@
 # План разработки: easy-png-tools
 
 > **Статус (2026-09-07):** Фаза 1 (полноценный TS-сайт) в основном выполнена —
-> сайт живёт, каталог переведён в типизированный `registry-new` (121/125),
-> идёт редизайн на `preview/*` по `plan-redesign.md` (параллельная ветка,
-> старый UI на `(old)/`). Фазы 2–8 (эталоны, Rust/wasm, CLI, harness) —
-> будущие, разделам ниже не запущены.
+> сайт живёт, каталог переведён в типизированный `registry-new` (121/125), идёт
+> редизайн на `preview/*` по `plan-redesign.md` (параллельная ветка, старый UI
+> на `(old)/`). Фазы 2–8 (эталоны, Rust/wasm, CLI, harness) — будущие, разделам
+> ниже не запущены.
 
 ## 0. Решения
 
-- **Набор PNG-утилит, всё в браузере** (SvelteKit + `adapter-static`), данные не покидают машину.
-- **Первый и главный приоритет — полностью рабочий TS-сайт**: максимум простых инструментов уровня EASY, UX/UI, пайплайны (несколько инструментов подряд), описания инструментов. Сайтом можно пользоваться уже после этой фазы.
-- **Никакого wasm/Rust на этом этапе.** TS-реализация на canvas + `ImageData` — эталон алгоритмов, из которого позже генерируются эталонные файлы для проверки Rust-порта. Rust-ядро, WASM и CLI — отдельные фазы позже, когда сайт живёт.
-- **Пайплайн = JSON-список шагов** `{tool, params}`. Формат закладывается сейчас и потом станет общим для браузера, wasm и CLI.
-- **Реестр инструментов** (id, title, description, схема параметров, `run`) — источник истины: из него генерируются страницы, формы, пайплайны. Позже — общий формат для Rust-парсера.
-- Валидация будущего Rust-порта — эталонные файлы, сгенерированные из TS-реализации. Сравнение: **бит-в-бит** для чистых пиксельных операций, **perceptual diff** для canvas-зависимых.
-- **Единая точка исполнения инструментов.** Страницы вызывают операции только через `web/src/lib/tools/executor.ts::executeStep` — нигде напрямую `tool.run`. Контракт уже асинхронный (`Promise<PixelImage>`), поэтому:
-  - когда появятся тяжёлые MEDIUM-операции (свёртки, квантование), внутренности `executeStep` переезжают в Web Worker — воркер импортирует тот же чистый core как TS-фолбэк, алгоритмы не дублируются, вызывающий код не меняется;
-  - в WASM-фазе тот же воркер принимает wasm-модуль и диспетчеризует по `toolId` — свитч A/B из фазы 5 сводится к замене реализации внутри исполнителя;
-  - до появления MEDIUM-операций воркер не вводится: EASY-операции быстры и не блокируют UI.
+- **Набор PNG-утилит, всё в браузере** (SvelteKit + `adapter-static`), данные не
+  покидают машину.
+- **Первый и главный приоритет — полностью рабочий TS-сайт**: максимум простых
+  инструментов уровня EASY, UX/UI, пайплайны (несколько инструментов подряд),
+  описания инструментов. Сайтом можно пользоваться уже после этой фазы.
+- **Никакого wasm/Rust на этом этапе.** TS-реализация на canvas + `ImageData` —
+  эталон алгоритмов, из которого позже генерируются эталонные файлы для проверки
+  Rust-порта. Rust-ядро, WASM и CLI — отдельные фазы позже, когда сайт живёт.
+- **Пайплайн = JSON-список шагов** `{tool, params}`. Формат закладывается сейчас
+  и потом станет общим для браузера, wasm и CLI.
+- **Реестр инструментов** (id, title, description, схема параметров, `run`) —
+  источник истины: из него генерируются страницы, формы, пайплайны. Позже —
+  общий формат для Rust-парсера.
+- Валидация будущего Rust-порта — эталонные файлы, сгенерированные из
+  TS-реализации. Сравнение: **бит-в-бит** для чистых пиксельных операций,
+  **perceptual diff** для canvas-зависимых.
+- **Единая точка исполнения инструментов.** Страницы вызывают операции только
+  через `web/src/lib/tools/executor.ts::executeStep` — нигде напрямую
+  `tool.run`. Контракт уже асинхронный (`Promise<PixelImage>`), поэтому:
+  - когда появятся тяжёлые MEDIUM-операции (свёртки, квантование), внутренности
+    `executeStep` переезжают в Web Worker — воркер импортирует тот же чистый
+    core как TS-фолбэк, алгоритмы не дублируются, вызывающий код не меняется;
+  - в WASM-фазе тот же воркер принимает wasm-модуль и диспетчеризует по `toolId`
+    — свитч A/B из фазы 5 сводится к замене реализации внутри исполнителя;
+  - до появления MEDIUM-операций воркер не вводится: EASY-операции быстры и не
+    блокируют UI.
 
 ## 1. Структура репозитория (этап TS)
 
@@ -39,15 +55,28 @@ easy-png-tools/
 
 ### Фаза 1 — Полноценный TS-сайт (единственный приоритет)
 
-**Цель: сайт, которым можно пользоваться.** Без wasm, без Rust, без clamp-семантики (в TS это делает `Uint8ClampedArray` сам).
+**Цель: сайт, которым можно пользоваться.** Без wasm, без Rust, без
+clamp-семантики (в TS это делает `Uint8ClampedArray` сам).
 
-1.1 **Каркас и UX/UI.** SvelteKit + static adapter, дизайн-система (цвета, типографика, компоненты), общий лейаут, шапка с навигацией по категориям.
+1.1 **Каркас и UX/UI.** SvelteKit + static adapter, дизайн-система (цвета,
+типографика, компоненты), общий лейаут, шапка с навигацией по категориям.
 
-1.2 **Ядро.** Тип `Image` (обёртка над `ImageData`), загрузка/декодирование файла, кодирование и скачивание, библиотека операций (color/alpha/geometry/format/text/analyze). Всё без DOM-зависимостей внутри `core`.
+1.2 **Ядро.** Тип `Image` (обёртка над `ImageData`), загрузка/декодирование
+файла, кодирование и скачивание, библиотека операций
+(color/alpha/geometry/format/text/analyze). Всё без DOM-зависимостей внутри
+`core`.
 
-1.3 **Реестр инструментов.** Одна запись = `{ id, title, description, category, params: ParamDef[], run }`. Универсальный рендерер: страница инструмента и форма параметров строятся из записи реестра автоматически; маршруты-утилиты генерируются из реестра на билде. Новый инструмент = новая запись + функция `run`.
+1.3 **Реестр инструментов.** Одна запись =
+`{ id, title, description, category, params: ParamDef[], run }`. Универсальный
+рендерер: страница инструмента и форма параметров строятся из записи реестра
+автоматически; маршруты-утилиты генерируются из реестра на билде. Новый
+инструмент = новая запись + функция `run`.
 
-1.4 **Пайплайн-workspace** (`/workspace`): загрузил изображение → список шагов (инструмент + его параметры) → последовательное применение с превью каждого шага → скачивание финального результата. Добавление/удаление/перестановка шагов. Сохранение пайплайнов в localStorage, экспорт/импорт JSON. Общие компоненты: DropZone, Preview, ParamForm, Download, PipelineSteps.
+1.4 **Пайплайн-workspace** (`/workspace`): загрузил изображение → список шагов
+(инструмент + его параметры) → последовательное применение с превью каждого шага
+→ скачивание финального результата. Добавление/удаление/перестановка шагов.
+Сохранение пайплайнов в localStorage, экспорт/импорт JSON. Общие компоненты:
+DropZone, Preview, ParamForm, Download, PipelineSteps.
 
 1.5 **Массовая реализация EASY-инструментов** по категориям:
 
@@ -56,29 +85,36 @@ easy-png-tools/
 - цвет: замена, тон, каналы, оттенки серого, инверсии;
 - геометрия и холст: resize, crop, rotate, flip, border, padding, background;
 - текст и простые эффекты: watermark, add-text, рамки, шум, pixelate;
-- анализ: размеры, палитра, проверки, просмотр.
-  Приоритет — ширина, не глубина: как можно больше простых инструментов.
+- анализ: размеры, палитра, проверки, просмотр. Приоритет — ширина, не глубина:
+  как можно больше простых инструментов.
 
-1.6 **Полировка.** Описания и подсказки для всех инструментов, состояния загрузки/ошибок, доступность, пустые состояния.
+1.6 **Полировка.** Описания и подсказки для всех инструментов, состояния
+загрузки/ошибок, доступность, пустые состояния.
 
-**Checkpoint:** загрузил PNG → применил пайплайн из N шагов → сохранил и вернул пайплайн → скачал результат. Все инструменты 1.5 работают на сайте. Ни одного wasm.
+**Checkpoint:** загрузил PNG → применил пайплайн из N шагов → сохранил и вернул
+пайплайн → скачал результат. Все инструменты 1.5 работают на сайте. Ни одного
+wasm.
 
 ### Фаза 2 — Тестовые PNG и генератор эталонов
 
 - Фикстурные входы: градиенты/паттерны/шум + пара «настоящих» PNG.
 - Правило: сравниваем **распакованные пиксели**, не байты файла.
-- **Checkpoint:** в `tests/reference/<op>/` лежат `input-*.png` + `expected-*.png`.
+- **Checkpoint:** в `tests/reference/<op>/` лежат `input-*.png` +
+  `expected-*.png`.
 
 ### Фаза 3 — Playwright-тесты
 
-- `tools/gen-references.ts`: грузит страницу, гоняет TS-эталон, сохраняет `expected-*.png`.
+- `tools/gen-references.ts`: грузит страницу, гоняет TS-эталон, сохраняет
+  `expected-*.png`.
 - Регресс: изменение TS-ядра ловится тестами.
 - **Checkpoint:** регресс-тесты падают при изменении выхода эталона.
 
 ### Фаза 4 — Rust-ядро
 
-- Порт 1:1 чистых операций (первым делом те, что покрыты эталонными файлами) с `Image` ↔ TS `ImageData`.
-- `clamp_to_u8` с семантикой `ToUint8Clamp` (round-half-to-even, ≥255 → 255) + юнит-тесты на краях.
+- Порт 1:1 чистых операций (первым делом те, что покрыты эталонными файлами) с
+  `Image` ↔ TS `ImageData`.
+- `clamp_to_u8` с семантикой `ToUint8Clamp` (round-half-to-even, ≥255 → 255) +
+  юнит-тесты на краях.
 - `cargo test` читает эталонные файлы напрямую, **без браузера**.
 - **Checkpoint:** `cargo test` зелёный на всех эталонных файлах.
 
@@ -97,14 +133,18 @@ easy-png-tools/
 
 ### Фаза 7 — Сквозная проверка идентичности
 
-- Матрица: **эталонные файлы (из TS) ↔ Rust-native ↔ Rust-wasm**, одна команда `harness compare`.
+- Матрица: **эталонные файлы (из TS) ↔ Rust-native ↔ Rust-wasm**, одна команда
+  `harness compare`.
 - **Checkpoint:** сходимость по всем покрытым операциям во всех трёх рантаймах.
 
 ### Фаза 8 — Масштабирование и продвинутое
 
-- Порт оставшихся EASY → MEDIUM (свёртки, морфология, квантование; кодеки через крейт `image`).
-- Canvas-зависимые операции (текст, градиенты, штампы, `ctx.filter`): остаются в TS с perceptual-классом либо реимплементация в Rust.
-- batch-страница: дроп папки → wasm по всем файлам → zip. localStorage-пресеты (тот же JSON, что у CLI).
+- Порт оставшихся EASY → MEDIUM (свёртки, морфология, квантование; кодеки через
+  крейт `image`).
+- Canvas-зависимые операции (текст, градиенты, штампы, `ctx.filter`): остаются в
+  TS с perceptual-классом либо реимплементация в Rust.
+- batch-страница: дроп папки → wasm по всем файлам → zip. localStorage-пресеты
+  (тот же JSON, что у CLI).
 - HARD: compress/optimize через oxipng/zopfli (в Rust — нативно).
 
 ## 3. Правила сравнения (для фаз 4–7)
@@ -120,12 +160,18 @@ easy-png-tools/
 
 ## 4. Риски и контрмеры
 
-- **Реестр разрастается, страницы дублируются** — один универсальный рендерер страниц/форм из записей реестра; инструмент = данные + `run`.
-- **Семантика пайплайна** — зафиксировать: каждый шаг применяется к результату предыдущего; единый тип `Image` на всём пути; схема параметров на шаге.
-- **Canvas-операции не бит-в-бит** — класс perceptual закладывается на Фазе 2–3, а не в конце.
-- **WASM + Vite** — спайк на Фазе 5 до массовой интеграции (риск отложен сознательно: сайт уже живёт на TS).
-- **Расползание реестра при будущем Rust-порте** — схема параметров в JSON, её можно парсить и из Rust.
-- **Разные декодеры PNG** — фикстурные PNG генерировать самим, чтобы не тащить чужие артефакты.
+- **Реестр разрастается, страницы дублируются** — один универсальный рендерер
+  страниц/форм из записей реестра; инструмент = данные + `run`.
+- **Семантика пайплайна** — зафиксировать: каждый шаг применяется к результату
+  предыдущего; единый тип `Image` на всём пути; схема параметров на шаге.
+- **Canvas-операции не бит-в-бит** — класс perceptual закладывается на Фазе 2–3,
+  а не в конце.
+- **WASM + Vite** — спайк на Фазе 5 до массовой интеграции (риск отложен
+  сознательно: сайт уже живёт на TS).
+- **Расползание реестра при будущем Rust-порте** — схема параметров в JSON, её
+  можно парсить и из Rust.
+- **Разные декодеры PNG** — фикстурные PNG генерировать самим, чтобы не тащить
+  чужие артефакты.
 
 ## 5. Команды верификации