easy-png-tools2/docs/plan-codebase-quality.md

План: линтеры, тесты и качество кодовой базы

Статус: draft — Q0–Q5 и Q6a–Q6f.5 готовы к ревью; Q7 — следующий этап.

Источник: docs/backlog.md, аудит конфигурации web/, e2e-тестов и инфраструктурных скриптов. Q0–Q5 и Q6a–Q6f.5 выполнены; Q7–Q8 выполняются отдельными атомарными шагами.

Цель: сделать качество кодовой базы воспроизводимым, убрать ложную «зелёность» проверок, стабилизировать тестовые контракты и только после этого расширять автоматические правила.

1. Границы и принципы

1. Сначала stabilизировать существующие проверки и тестовые контракты, а не добавлять новые сложные lint-правила.
2. Старый UI удалён: production работает на корневых маршрутах, а /v1/** и v1-specific код больше не являются частью приложения.
3. Не добавлять новые v1-фичи, не чинить v1-баги и не расширять v1-тесты.
4. core/ и theme/ — общие модули. Их изменения проверяются unit-тестами и smoke-сценариями production-потребителей.
5. Изменения делаются небольшими атомарными частями, в соответствии с AGENTS.md.
6. Каждый новый lint-rule сначала появляется в report-only/warn-only режиме, получает fixtures и тесты, и только после очистки baseline становится blocking.
7. Детали реализации правил остаются в web/eslint-plugins/README.md; AGENTS.md содержит краткие обязательные политики, понятные агенту без дополнительных поисков, и ссылки на подробные документы.

Политика удаления legacy v1

• Q3 — отдельная атомарная cleanup-задача; поддержка v1 не возвращается.
• Старые маршруты и UI-файлы удаляются без redirects и без совместимого maintenance-режима.
• В рабочей кодовой базе не оставлять UI-v1-пути, исключения или документацию, которые выглядят как действующий источник совместимости.
• Исторические упоминания допустимы только в docs/archive/.
• Будущий API-контракт POST /v1/process из docs/plan-platform.md не связан с удалённым UI-v1 и остаётся в планах.

2. Текущее состояние quality-контура

• pnpm verify объединяет typecheck, unit, rule-тесты, lint, форматирование, docs и production build; deploy выполняет его перед сборкой.
• i18n/dict-consistency даёт 0 warnings на текущем baseline; после Q7 вычищены 4 неиспользуемых design token, token audit тоже чист.
• E2E-контракт использует semantic locators и общий source-aware schema resolver; активных known-issue test.fixme нет.
• ToolError хранится как key/vars и переводится только при выводе; смена локали обновляет уже видимый alert.
• E2E гоняется в четырёх Playwright-проектах: полный Chromium, Firefox и WebKit для browser-critical спецификаций и mobile Chromium 390×844. Job остаётся non-blocking, число воркеров ограничено из-за памяти.

3. Этапы выполнения

Q0. Зафиксировать baseline и синхронизировать документацию

Статус: готов к ревью. Оценка: S. Зависимости: нет.

• Проверить фактические команды и зафиксировать их в quality-gate документации.
• Вынести расширенный workflow агента в docs/agent-workflow.md, оставив в AGENTS.md только обязательные инварианты и ссылки.
• Обновить docs/backlog.md:
  • отметить dictionary linter как реализованный, но не доведённый до zero-warning;
  • убрать противоречие по кнопке Generate;
  • синхронизировать числа инструментов и тестовых сценариев.
• Восстановить или исправить ссылку на раздел G в docs/checklist-manual-testing.md.
• Убрать устаревшее утверждение про hardcoded debt в kit из AGENTS.md, если оно больше не соответствует коду.
• Перенести явно устаревшие docs/analysis.md и docs/sorting-backend.md в docs/archive/, добавить даты архивирования и удаления через 30 дней.
• Создать docs/README.md как индекс активных документов и карту источников истины; подробные правила не дублировать в корневых файлах.

Готово, когда: один документ описывает текущие команды, актуальный baseline и все известные test.fixme имеют ссылки на зарегистрированный баг.

Q1. Единый quality gate и CI

Статус: готов к ревью. Проверено: pnpm verify проходит; E2E оставлен отдельным non-blocking job. Оценка: S–M. Зависимости: Q0.

Добавить read-only verify-команду, которая запускает:

pnpm --dir web check
pnpm --dir web test
pnpm --dir web test:rules
pnpm --dir web lint:all
pnpm --dir web exec prettier --check .
pnpm check:docs
pnpm --dir web build

E2E оставить отдельным тяжёлым гейтом:

pnpm --dir web test:e2e

• Не дублировать вручную аргументы ESLint/Stylelint в нескольких скриптах; оркестратор должен вызывать package scripts или единый общий модуль.
• Описать фактические команды и semantics ошибок/warnings в docs/quality-gates.md; здесь нужна точная процедура, а не длинный дубль в AGENTS.md.
• На первом этапе явно разделить errors и warnings.
• После очистки i18n baseline добавить строгий режим --max-warnings=0.
• Добавить отдельный workflow для pull request: typecheck, unit, rule-тесты, lint, format и build.
• E2E сначала запускать отдельным job; сделать его blocking после закрытия известных ошибок и стабилизации baseline. Решение отложено: условия matrix пересматриваются после Q6f.3, см. раздел 7 «Отложенное решение».

Готово, когда: одна команда воспроизводит все быстрые проверки, а deploy не может пройти при type/unit/lint/build-ошибке.

Q2. Политика i18n и zero-warning baseline

Статус: готов к ревью. Проверено: i18n lint даёт 0 warnings, rule-тесты и полный pnpm verify проходят. Оценка: M. Зависимости: Q0, Q1.

• BASE_LOCALE — единственный источник registry-English fallback для tools.*.title и tools.*.description; остальные локали требуют физические ключи.
• Временно неиспользуемые tools.*.params исключены pattern-based policy до отдельной очистки мёртвого словаря; пустые значения и placeholders не подавляются.
• Исправлены три реальных RU option-label gaps и удалены неиспользуемые option-группы из ru.ts.
• Исправлен tie-break placeholder parity: при равенстве голосов выбирается BASE_LOCALE.
• lint-all запускает ESLint с --max-warnings=0; unused-token сообщение оставалось неблокирующим и закрыто в Q7.
• Plural-формы остаются отдельной задачей после Q2 и не смешиваются с этим этапом.

Q3. Удалить UI-v1 (cleanup завершён)

Статус: выполнен. Проверено: pnpm verify и production E2E smoke проходят; после проверки обновлены конфиги и активные документы. Оценка: M. Зависимости: Q0, Q1, Q2.

• Удалены web/src/routes/v1/**, web/src/lib/v1/**, app_v1.css, v1-specific i18n/tests и fixtures.
• Удалены isolation plugin, его тест и все v1-исключения из lint-конфигураций.
• Убраны v1-ссылки из production-кода и активных документов; исторические упоминания остаются в docs/archive/.
• Проверены production build, verify и отдельный E2E smoke production-маршрутов.

Результат: /v1/**, UI-v1-файлы и legacy-конфигурация отсутствуют; следующий этап — Q5.

Q4. Тестовый контракт e2e

Статус: выполнен. Проверено: pnpm verify и полный Playwright smoke проходят; 105 тестов passed, 4 known-issue теста skipped. Оценка: M. Зависимости: Q0–Q3.

• Добавлен docs/testing-strategy.md с locator, fixture, i18n и test.fixme policy.
• В production markup добавлены только разрешённые hooks для source/result/ verdict/empty-state; текстовые элементы получили accessible labels, фильтры — aria-pressed, а каталог — семантические heading/status landmarks.
• E2E переведён на role, label и stable href; удалены TOTAL/GROUPS, exact fuzzy counts, internal CSS selectors, alt-locators и полные verdict strings. Точные verdict-переводы перенесены в unit-тесты.
• Helpers централизованы в web/e2e/helpers/page.ts; исправлены stale theme/source/locale checks. Theme fixme снят.
• Q5-фиксы resize/crop, generator, Reset и error-сценария не смешивались с этим этапом.

Результат: изменение формулировки, класса или порядка элементов не ломает поведенческий тест без изменения пользовательского контракта; следующий этап — Q6.

Q5. Закрыть известные preview-баги

Статус: выполнен. Проверено: unit, Q5 E2E smoke и полный pnpm verify проходят; активных known-issue test.fixme нет. Оценка: M–L. Зависимости: Q4.

• Добавлен общий opt-in defaultFromSource resolver в registry-schema: он принимает source dimensions, обновляет только source-aware поля при upload и используется в UI, executor и worker. resize-png и crop-png получают размеры текущего source; static/generator/text schemas не затронуты.
• Reset сохраняет source/text, восстанавливает source-aware defaults и запускает deferred auto-run через debounce.
• Генераторы проверены в auto-run без кнопки Generate; кнопка не добавляется.
• ToolError хранится как key/vars, переводится derived-значением при выводе и обновляется при смене локали. E2E использует независимый invalid pixel-count сценарий.
• Resize/crop, generator, Reset и localization fixme сняты; Q6a расширяет покрытие, не смешиваясь с исправлением этих контрактов.

Результат: Q5 known issues закрыты и отражены в docs/backlog.md и docs/checklist-manual-testing.md; Q6a выполнен, следующий этап — Q6b.

Q6. Расширение unit и browser-покрытия

Оценка: M–L. Зависимости: Q4, Q5.

Q6a. Executor protocol, fallback и debounce

Статус: выполнен. Unit-тесты покрывают debounce, worker image/string/ verdict/files protocol, ToolError transport, constructor/postMessage/onerror/ malformed fallback, source-aware sanitization и DOM metadata. Browser smoke проверяет rapid auto-run и no-worker fallback; deferred transport fallback покрыт unit-тестами.

• execute(tool, ctx) сохраняет публичный API; createExecutor и protocol handler являются внутренними test seams.
• ToolError не запускает direct retry повторно; transport/protocol failures отключают worker и переходят в direct fallback.
• DOM-зависимые registry entries помечены domOnly, поэтому зелёный smoke не скрывает нормальный worker fallback.
• debounce покрыт fake timers; E2E подтверждает последние значения при быстрых последовательных изменениях генератора.

Q6b. FileResult → ZIP → download

Статус: выполнен. Q6a закрыл worker-транспорт; Q6b добавил проверяемый ZIP seam, unit round-trip для FileResult, защиту пустого результата и error/busy контракт download. Отдельный browser-сценарий скачивает архив и проверяет имена частей и PNG-сигнатуры.

• buildZipEntries не зависит от DOM; downloadZip остаётся UI-обёрткой.
• SchemaToolView переиспользует downloadBlob, ловит ошибки кодирования и блокирует повторный download на время сборки.
• E2E использует downloadResultFile и unzipSync, не добавляя новые data-testid; files-инструменты не проходят через image-smoke.

Q6c. Output MIME/quality

Статус: выполнен. Q6c покрывает текущий фиксированный output-контракт JPG/WebP/BMP, не превращаясь в UX-райз кнопки Download. Registry проверяет согласованность MIME/extension/quality-поля, unit — границы quality, browser — реальные сигнатуры файлов и разницу размера при изменении quality.

• ToolEntry.output остаётся декларативным описанием формата; новый селектор форматов не добавляется.
• validateOutputQuality отделяет проверку 0..1 от DOM-рендеринга; JPEG/WebP используют quality 1..100 из schema, BMP не имеет quality-параметра.
• E2E проверяет JPEG FF D8 FF, WebP RIFF/WEBP, BMP BM и PNG-фолбэк.
• Ошибки кодирования и unsupported MIME используют существующие i18n-ключи.

Q6d. Malformed и special PNG fixtures

Статус: выполнен. Runtime-fixtures покрывают CRC, truncated, palette и 16-bit без бинарных файлов в git. E2E фиксирует браузерный контракт: critical CRC/truncated отклоняются без падения, ancillary CRC и хвост после IEND допускаются, palette/16-bit декодируются. Unit фиксирует контракт анализаторов для RGBA-данных, которые браузер отдаёт после нормализации.

• web/e2e/helpers/fixtures.ts собирает indexed, 16-bit, CRC-mutation, truncation и tail-варианты из уже существующих crc32/chunk.
• Отклонение битых файлов — свойство декодера движка, а не единый продуктовый контракт: Q6f.3 зафиксировал, что Firefox и WebKit декодируют idat-cut и truncated-no-iend, а WebKit ещё и crc-bad-idat. Это ожидаемое поведение, которое закреплено per-engine в web/e2e/png-fixtures.spec.ts.
• Обязательное требование при любом исходе: файл не роняет страницу, ошибка показывается alert-ом, а не «пустым» результатом.
• Поведение createImageBitmap является частью browser-контракта, а не самостоятельного PNG-парсера product-кода.
• Сырое сообщение браузера при decode-ошибке не локализуется в Q6d; это отдельная задача в backlog.

Q6e. Registry-wide smoke

Статус: выполнен. Smoke расширен до всех 122 production tools из registry: image→image, image→text, text→image, generator input→image и verdict. FileResult и malformed/special PNG не дублируются — они уже покрыты Q6b/Q6d.

• tools-smoke.spec.ts расширен image/text-output кейсами, включая все незакрытые color/geometry инструменты.
• generators.spec.ts использует единый data-harness для всех генераторов; single-color-png сохраняет отдельную проверку auto-run/размеров.
• Text-input сценарии используют общий renderText helper, включая data-uri-to-png.
• Component-тесты не добавлены: Vitest работает в node без DOM/Testing Library, а текущий e2e-контракт уже покрывает поведение preview. Выбор test seam или DOM-окружения перенесён в Q6f.

Q6f.1. Layout resolver seam

Статус: выполнен. Чистая логика группировки полей вынесена из SchemaFields.svelte в resolveLayoutGroups и покрыта unit-тестами на дедупликацию, неизвестные поля, пустые группы, cols и default-хвост.

• Компонент использует общий resolver, поэтому unit-тесты блокируют изменения layout-логики без DOM/Testing Library.
• SchemaPreview view-model и DOM-компоненты не менялись; их seam остаётся отдельным решением Q6f.2.
• Новые зависимости, vitest-конфиг и browser matrix не добавлялись.

Q6f.2. SchemaPreview model seam

Статус: выполнен. Вычисления sourceValue, resultValue, formatValue и hasResult вынесены в buildSchemaPreviewModel; Svelte-компонент использует модель, а unit-тесты проверяют все input/result-ветки без DOM.

• Translator передаётся в модель явно, поэтому unit-тесты не зависят от locale state и проверяют только view-model.
• image/text/verdict/files и пустые результаты покрыты в pnpm verify.
• Новые зависимости, vitest-конфиг и browser matrix не добавлялись.

Q6f.3. Browser matrix и mobile viewport

Статус: выполнен. Playwright запускает четыре проекта: полный Chromium, Firefox и WebKit для browser-critical спецификаций и mobile Chromium 390×844 с hasTouch для навигации, каталога, генераторов и pipeline.

• web/playwright.config.ts: browserContractTests — pipeline.spec.ts, png-fixtures.spec.ts, text-and-verdicts.spec.ts; mobileTests — navigation.spec.ts, catalog.spec.ts, generators.spec.ts, pipeline.spec.ts.
• workers — 1 локально и 2 в CI. Browser matrix ограничена памятью: при 12 воркерах на машине с 16 GB RAM браузеры не успевают поднять worker, и тесты падают без ошибок (проверено и в Chromium). Локально matrix поэтому медленная, но почти не нагружает компьютер. Per-project лимита воркеров в Playwright нет.
• Per-project expect.timeout не задаётся: Firefox и WebKit отдают результат так же быстро, а расхождения объясняются памятью, а не скоростью движка.
• Декодеры движков расходятся, и это зафиксировано как ожидаемое поведение: png-fixtures.spec.ts хранит список движков, отклоняющих каждый битый файл, и не пропускает проверки. В любом браузере файл не должен ронять страницу, а отказ декодера показывается alert-ом.
• CI устанавливает chromium firefox webkit; job остаётся non-blocking.
• Локальный прогон: 276 passed, 0 skipped, 0 failed. Visual snapshots и coverage thresholds не добавлялись — это Q6f.4.

Q6f.4. Coverage thresholds

Статус: выполнен для чистой логики. Vitest считает покрытие только по src/lib, с явным списком исключений, и pnpm verify падает при падении ниже порога.

• web/vitest.config.ts: provider v8, reporter: text-summary, пороги statements 90, branches 82, functions 72, lines 91.
• Пороги поставлены на 1.5–2.5 п.п. ниже измеренного baseline (91.77 / 83.3 / 74.31 / 92.53), поэтому gate ловит регрессию, а не текущий долг.
• Scope — логика, которую node-Vitest вообще может исполнить. Исключены браузерные модули core/domText.ts и core/io.ts (canvas, createImageBitmap), data-модули i18n/en.ts, i18n/ru.ts, tool-icons.ts, rune-файлы *.svelte.ts, entry worker-а и type-only components/define.ts. Причина каждого исключения зафиксирована в конфиге и в docs/testing-strategy.md.
• registry/* (47–81% statements, 25–47% functions) в scope остаётся: это обычная непокрытая логика, а не ограничение окружения. Покрывается e2e-smoke Q6e, но unit-порог её не скрывает.
• verify теперь выполняет test:coverage вместо test: набор тестов тот же, двойного прогона нет.
• Порог functions самый слабый (74.31% против 91.77%): добавление инструмента с непокрытым run быстрее всего опускает именно его. Это ожидаемо, порог держит запас.
• DOM-тесты SchemaToolView/controls не начаты: браузерные модули исключены из coverage сознательно, а их перенос в scope — отдельное решение вместе с visual snapshots, см. Q6f.5.

Не применять один одинаковый smoke-сценарий к image-, text-, generator- и file-result-инструментам.

Q6f.5. Visual snapshots — решение отложено

Статус: сознательно не делаем. Это решение, а не долг.

• Механика: toHaveScreenshot сравнивает отрендеренную страницу с PNG-baseline, закоммиченным в web/e2e/<spec>-snapshots/. Эталон — картинка из прошлого коммита, а не замысел дизайнера; обновление идёт через --update-snapshots и ревью картинок.
• Почему отложено:
  • визуальный язык сейчас активно меняется, поэтому каждый дизайн-PR превращается в перегенерацию и ревью картинок, а соблазн обновить снапшот не глядя появляется постоянно;
  • baseline привязан к платформе (ОС, шрифты, особенности рендеринга): снимок с Windows не совпадёт на ubuntu-latest, значит эталоны должны рождаться на Linux, а локальные прогоны будут постоянно расходиться;
  • при матрице из четырёх проектов плюс тема и viewport число файлов Baseline растёт нелинейно.
• Что закрывает потребность сейчас: e2e-поведение (276 тестов), lint:tokens и token audit, i18n-гейт, ручной чеклист docs/checklist-manual-testing.md. Не закрыто только «элемент визуально наехал» — это ловится чеклистом и ревью.
• Условие возврата: визуальный язык стабилен, изменения редкие, ручной чеклист перестал справляться. Тогда первым идёт /kit в двух темах, а эталоны генерируются на Linux (docker-образ Playwright или отдельный CI-job).

Q7. Укрепление lint-инфраструктуры

Оценка: M. Зависимости: Q1, Q2, Q3.

Q7a. Очистка неиспользуемых design tokens

Статус: выполнен. Token audit чист: All app.css tokens are used somewhere.

• Удалены --color-text-accent-muted (light и dark, иначе ломается parity), --space-text-s: 0, --size-content-max: 880px и --duration-m: 0.3s.
• Проверено, что мёртвые токены — это пыль, а не признак хардкода: дублирующих значений (max-width, 0.3s, muted-цвет) в src нет. Потребители space-text-m/xl/2xl, size-content-max-wide и size-workspace-min используются, поэтому шкалы не тронуты.
• Шкалы остались неполными намеренно (duration-s/l без m, space-text без s): мёртвый элемент шкалы хуже, чем «дырявая» шкала, а вернуть его можно вместе с потребителем.
• Второй пункт («после очистки решить, должен ли unused audit быть fail-режимом») остаётся открытым: сам audit пока только сообщает.

Q7b. Тесты token audit и PostCSS HCT-плагина

Статус: выполнен. У обоих не было ни одного теста, хотя HCT-плагин (web/scripts/postcss-hct.mjs, 430 строк) пересчитывает всю палитру.

• web/scripts/__tests__/postcss-hct.test.mjs — 17 тестов: literal и производный hct(), seed из :root и из hex, цепочка hct-токенов, refs h/c/t, calc/min/max/clamp, обёртка hue, клампы tone/chroma, несколько вызовов в одном объявлении, а также warn-and-keep для неизвестного seed, циклической ссылки и битого тела hct().
• web/scripts/__tests__/token-audit.test.mjs — 15 тестов на parity (light-only, dark-only, derived, не-цвет), authorship (hct, color-mix, seed-токены, хардкод с локацией, игнор не-цветов и обычных свойств), unused и предикаты isColorValue/isDerived.
• Ожидания не зашивают вывод плагина, а сравнивают его с эквивалентной литеральной записью: hct(from var(--seed) h c calc(t + 10)) должен совпасть с hct(120 40 60), если seed — hct(120 40 50). Иначе тест просто зафиксировал бы текущее поведение.
• Единственный seam: checkUnused(root, used = collectUsedTokens()) — зависимость от чтения src стала инъецируемой, production-вызов не изменился.
• vitest.config.ts подхватывает scripts/**/*.test.mjs, поэтому скрипты покрываются обычным прогоном и verify; test:rules не трогали.
• Проверка мутацией выявила дыру: первая версия тестов не ловила кламп tone в ветке from (смена clamp(t, 0, 100) на 0, 90 проходила зелёной). Добавлен отдельный тест на производный кламп; после этого мутация падает.

Q7c. Базовый JS recommended для инфраструктуры линтинга

Статус: выполнен. eslint-plugins/** и scripts/** больше не вне линта.

• web/eslint.config.js: toolingFiles = ["**/eslint-plugins/**/*.js", "**/scripts/**/*.mjs"] получают js.configs.recommended плюс languageOptions с globals.node (иначе no-undef ругается на console, process и URL в Node-скриптах).
• Полные TS/svelte-наборы туда не подключаются: это .mjs и конфиги, а не продуктовый код.
• Масштаб оказался небольшим: 28 проблем, из них 26 — no-undef на Node-глобалах и только 2 настоящие: мёртвые импорты existsSync и resolve в scripts/serve-static.mjs. Линтер сразу нашёл пыль в инфраструктуре, для которой его раньше не было.
• eslint-plugins/** дал ноль проблем, а новые тесты scripts/__tests__ тоже попали под правило.
• Проверено пробой: после включения неиспользуемая переменная и вызов неопределённого глобала в scripts/ дают ошибки, то есть правило применилось, а не молча пропустило файлы.

Q7d. Решения по оставшимся вопросам

Статус: закрыт тремя решениями.

1. Обычный CSS под те же токен-правила, что Svelte styles — узко. В src всего один CSS-файл, и он же словарь токенов, поэтому переносить туда no-hardcoded-in-svelte и подобные нечего: stylelint уже проверяет src/**/*.css (префиксы, запрет !important, цвет только у brand-токенов), а check-tokens.mjs дублирует проверку цвета. Реальный пробел был один — var() может ссылаться на несуществующий токен, — его закрыл новый модуль web/scripts/token-audit/refs.mjs (см. Q7e). Широкую унификацию механизмов решено не делать: это лишний слой поверх дублирующихся проверок.
2. Конфиги под рекомендации — только JS. *.config.js (eslint/postcss/stylelint) добавлены в toolingFiles; по измерению они дают 0 проблем, поэтому это бесплатно. TS-конфиги (vite, vitest, playwright) не подключены: им потребовался бы tseslint-парсер и запись vite.config.ts в allowDefaultProject, а выигрыш близок к нулю. Попутно удалена мёртвая запись svelte.config.js в allowDefaultProject — такого файла нет.
3. Unused-аудит остаётся предупреждением. Правило «новый токен — вместе с потребителем» закреплено в AGENTS.md. Причина: verify входит в deploy-workflow, поэтому стилевой долг блокировал бы деплой сайта; кроме того, чтение токена из JS (getPropertyValue) аудит не видит и дал бы ложное срабатывание. Baseline чистый, пыль вычищена в Q7a.

Q7e. Проверка резолва var() в app.css

Статус: выполнен. Аудит падает, если var(--x) в app.css указывает на токен, которого нет в этом же файле.

• web/scripts/token-audit/refs.mjs + вызов в check-tokens.mjs; режим — ошибка, а не предупреждение, потому что это дефект (объявление молча отбрасывается), а не стилистический долг.
• var(--x, fallback) не считается ошибкой: fallback легален без определения токена.
• 7 тестов в scripts/__tests__/token-audit.test.mjs: резолв в обеих темах, опечатка с локацией, fallback, дедуп повторов, ссылка внутри определения токена, var() в обычном свойстве.
• Проверено на живом файле: временная опечатка var(--color-bordr) дала Unresolved var() references и код выхода 1; app.css восстановлен байт в байт.

Q7f. Оставшиеся направления

• Новые правила подключать только после fixtures, test:rules и baseline.
• Если в коде появится чтение токенов из JS, collectUsedTokens придётся расширить — иначе unused-аудит начнёт считать используемые токены пылью.

Q8. Новые автоматические правила

Оценка: L. Зависимости: Q4, Q7.

Дублирование HTML/Svelte-разметки

Сначала провести report-only аудит новых components/** и routes/**. Определить:

• минимальный размер клона;
• нормализацию Svelte blocks и динамических классов;
• список допустимых fixture/allowlist-случаев.

Только после оценки false positives выбирать между готовым detector и собственным AST-правилом. Не включать detector в blocking gate сразу.

Пользовательские тексты вне i18n

Сделать warn-only пилот с исключениями для:

• бренда и версии;
• форматов и имён файлов;
• X/Y и технических значений;
• registry source strings;
• /kit;
• тестовых данных и внутренних сообщений.

Blanket-запрет всех string literals не использовать.

Согласованность комментариев

Автоматический lint не делать. Это review/process policy: комментарий должен объяснять причину исключения, а TODO/FIXME — ссылаться на backlog или issue и иметь критерий закрытия.

4. Что описать в AGENTS.md

В AGENTS.md добавить только следующие неочевидные правила:

1. Какой набор команд считается полным quality gate и что означает успешный результат при warnings.
2. Production-scope и политику удаления v1: новые изменения относятся только к production UI; исторические UI-v1-упоминания остаются в архиве.
3. Политику e2e: semantic locators, допустимый data-testid, запрет бессмысленных counts/classes/alt/exact prose.
4. Политику i18n: новые пользовательские тексты через i18n; registry source, brand, formats и /kit — явные исключения.
5. Жизненный цикл test.fixme: только для зарегистрированного бага, с ссылкой; исправление и удаление теста происходят вместе.
6. Комментарии и TODO/FIXME должны объяснять «почему» и иметь ссылку на работу.
7. Shared-модули core/theme требуют проверки production-потребителей.

Синтаксические списки ESLint-правил и подробные токены остаются в web/eslint-plugins/README.md.

Политика документации для агентов

AGENTS.md не должен превращаться в полный справочник проекта. В нём оставляем только обязательный рабочий контракт: команды, production-scope, ключевые инварианты, исключения и ссылки на подробные документы. Если агенту нужно понять причину или workflow, в AGENTS.md должна быть короткая понятная формулировка; длинные примеры, точные процедуры, таблицы и критерии проверки переносятся в docs/ или в README рядом с соответствующей подсистемой.

Принцип выбора места документа:

1. Поведение агента, которое нельзя пропустить — кратко в AGENTS.md.
2. Точная команда, скрипт, параметр или критерий качества — в docs/quality-gates.md или в README соответствующей подсистемы.
3. Архитектурное решение, поток данных и границы модулей — в docs/architecture-overview.md или существующем плане.
4. Реализация конкретного lint-правила и его fixtures — только в web/eslint-plugins/README.md и исходниках правила.
5. Продуктовая задача, backlog и ручная приёмка — в docs/backlog.md, активном плане или docs/checklist-manual-testing.md.

Подробные документы не дублируются в нескольких местах: у документа должен быть один источник истины, а остальные файлы ссылаются на него. Все подробные материалы хранятся в docs/, чтобы не засорять корень репозитория.

Активный документ должен иметь статус (draft, active, completed или archived) и понятную область применения. Архивные планы не используются как текущие критерии приёмки без отдельной сверки с кодом. Новый документ создаётся только когда темы нет в существующем файле; иначе обновляется существующий.

Архивирование и срок хранения

Завершённые, отменённые или явно устаревшие документы переносятся в docs/archive/, а не остаются в корне docs/ как рабочие планы. При переносе добавляются дата архивирования, дата удаления и причина. Архивный документ — временная справка для быстрого просмотра прошлых решений, но не источник текущих требований.

Срок хранения после архивирования — 30 дней. После этой даты документ можно удалить после проверки ссылок; если он снова нужен, его восстанавливают из git history или пересоздают как новый активный документ. Подробная процедура и шаблон метаданных находятся в docs/archive/README.md.

Какие документы подготовить

Документ	Назначение	Когда создавать/обновлять
docs/README.md	Индекс активных документов, карта источников истины и краткий порядок чтения для агента	Q0; при добавлении нового активного документа
docs/agent-workflow.md	Подробный workflow: исследование, изменение, проверка и обновление документации	Q0–Q1; только для процессов, не описанных кратко в AGENTS.md
docs/quality-gates.md	Команды проверки, semantics errors/warnings, порядок запуска и требования CI	Q1; при изменении scripts/config/CI
docs/testing-strategy.md	Слои тестов, locator policy, i18n assertions, fixtures, test.fixme и правила e2e	Q4; при изменении тестовой архитектуры
docs/architecture-overview.md	Карта core, registry, executor, production UI и shared-модулей	Q5 или перед крупным рефакторингом; не дублировать существующие планы
web/eslint-plugins/README.md	Детали custom lint rules, token policy и fixtures	Уже существует; менять только вместе с правилами
docs/archive/README.md	Политика временного архива, даты и удаления через 30 дней	Q0; обновлять при изменении архивной политики

Не создавать отдельные docs/commands.md, docs/known-issues.md или копию backlog: команды принадлежат quality-gates, известные проблемы — backlog и checklist. README.md в корне остаётся кратким обзором продукта, а не вторым руководством агента.

5. Порядок PR

1. Q0 — синхронизация backlog/checklist/AGENTS.
2. Q1 — verify и PR quality gate.
3. Q2 — i18n parity и strict warning gate.
4. Q3 — удалить v1 отдельной атомарной задачей.
5. Q4 — тестовый контракт и stale-тесты для production UI.
6. Q5 — preview-баги и снятие fixme.
7. Q6 — расширенное покрытие.
8. Q7 — тесты lint-инфраструктуры и unused tokens.
9. Q8 — report-only duplicate/text audits; blocking — только после baseline.

Каждый PR должен быть атомарным и небольшим; не объединять SchemaPreview refactor, новые i18n-правила и исправление продуктовых багов в одну работу.

6. Отдельные направления и что не начинать автоматически

• полноценный browser/visual/coverage matrix;
• полноценная PWA/API/WASM-платформа;
• SchemaPreview state/view-model refactor;
• plural-формы до модели словаря;
• универсальный линтер одинаковых комментариев;
• batch/архивы, region-инструменты и остальные продуктовые волны из backlog.

7. Решения, которые нужно принять на ревью

• Какие executor/worker/fallback сценарии войдут в первый Q6 coverage PR?
• Нужны ли browser/mobile matrix и visual snapshots до coverage thresholds? Решено: matrix — Q6f.3, coverage — Q6f.4, visual snapshots отложены с обоснованием в Q6f.5.
• Какие unused design tokens можно удалить, а какие должны остаться? Решено в Q7a: удалены все четыре, audit чист.
• Какие browser/e2e проверки должны быть обязательными для PR, а какие — отдельным ночным прогоном?

Отложенное решение: условия matrix и blocking e2e

Окончательное решение про e2e в CI принимается не сейчас, а после пересмотра условий тестов. К этому моменту нужно вернуться и решить одним шагом:

1. Пересмотреть условия matrix: какие спецификации обязаны идти в browserContractTests и mobileTests, нужен ли png-fixtures вне Chromium и что делать с engine-специфичными расхождениями декодеров.
2. Накопить стабильные прогоны e2e на раннере (сейчас ориентир — 276 тестов, ~3 мин на job) без падений по таймингу.
3. Только после этого решать, делать ли e2e blocking, и если да — снимать continue-on-error, иначе общий conclusion прогона останется зелёным при красном e2e (проверено на run 36225579363).

До этого решения e2e остаётся non-blocking baseline, а его фактический статус проверяется по отдельному job, а не по conclusion прогона.