docs: update plans

docs/plan-codebase-quality.md

@@ -1,9 +1,9 @@
 # План: линтеры, тесты и качество кодовой базы
 
-> Статус: **draft — Q0–Q5 и Q6a–Q6f.3 готовы к ревью; Q6f.4 — следующий этап**.
+> Статус: **draft — Q0–Q5 и Q6a–Q6f.5 готовы к ревью; Q7 — следующий этап**.
 >
 > Источник: `docs/backlog.md`, аудит конфигурации `web/`, e2e-тестов и
-> инфраструктурных скриптов. Q0–Q5 и Q6a–Q6f.3 выполнены; Q6f.4–Q8 выполняются
+> инфраструктурных скриптов. Q0–Q5 и Q6a–Q6f.5 выполнены; Q7–Q8 выполняются
 > отдельными атомарными шагами.
 >
 > Цель: сделать качество кодовой базы воспроизводимым, убрать ложную «зелёность»
@@ -355,13 +355,37 @@ Firefox и WebKit для browser-critical спецификаций и mobile Chr
 - Порог functions самый слабый (74.31% против 91.77%): добавление инструмента с
   непокрытым `run` быстрее всего опускает именно его. Это ожидаемо, порог держит
   запас.
-- DOM-тесты `SchemaToolView`/controls и visual snapshots не начаты: браузерные
+- DOM-тесты `SchemaToolView`/controls не начаты: браузерные модули исключены из
-  модули исключены сознательно, а baselines snapshots платформенные и должны
+  coverage сознательно, а их перенос в scope — отдельное решение вместе с visual
-  рождаться на Linux.
+  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.
@@ -518,6 +542,8 @@ refactor, новые i18n-правила и исправление продук
 
 - Какие 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 можно удалить, а какие должны остаться?
 - Какие browser/e2e проверки должны быть обязательными для PR, а какие —
   отдельным ночным прогоном?

docs/testing-strategy.md

@@ -156,5 +156,8 @@ non-blocking E2E не считается заменой локальному smo
   тесты падают без ошибок. Локальный matrix поэтому медленный, но не нагружает
   компьютер.
 - Локальный baseline: 276 тестов, 276 passed, 0 skipped, 0 failed.
-- Visual snapshots и coverage thresholds не часть matrix; они вынесены в
+- Visual snapshots сознательно не используются: baseline платформенный, а
-  `docs/plan-codebase-quality.md` (Q6f.4).
+  визуальный язык сейчас активно меняется. Причина и условие возврата — в
+  `docs/plan-codebase-quality.md` (Q6f.5).
+- Visual snapshots и coverage thresholds вынесены в
+  `docs/plan-codebase-quality.md` (Q6f.4, Q6f.5).