test: update fixtures flow, add different browsers

docs/quality-gates.md

@@ -40,6 +40,12 @@ download, темы или локализации. Изменения runtime fix
 `tests/fixtures/` не входят в `verify`. В текущем CI это отдельный non-blocking
 baseline; после закрытия известных ошибок его можно сделать blocking.
 
+Локально прогон идёт с `workers: 1` и заметно медленнее: это осознанный размен,
+экономит память и оставляет компьютер отзывчивым. Playwright не умеет
+per-project лимит воркеров, а browser matrix упирается в память, а не CPU.
+Тяжёлые прогоны запускаются по команде пользователя — по одному, без фонового
+запуска и циклов повторов; детали в `docs/agent-workflow.md`.
+
 ## Быстрые подмножества
 
 | Изменение                    | Команда                                                 |
@@ -75,6 +81,52 @@ baseline; после закрытия известных ошибок его м
 `.github/workflows/deploy.yml` перед production build запускает тот же
 `pnpm verify`, поэтому deploy не должен проходить при ошибке быстрых проверок.
 
+### Что и когда запускается
+
+| Workflow                 | Триггер                  | Jobs                        |
+| ------------------------ | ------------------------ | --------------------------- |
+| `Deploy to GitHub Pages` | push в `main`, dispatch  | `verify`, `build`, `deploy` |
+| `Quality`                | `pull_request`, dispatch | `verify`, `e2e`             |
+
+Следствие: при прямом пуше в `main` выполняется только быстрый gate — `verify`
+внутри deploy-workflow. Browser matrix из четырёх проектов на этом прогоне не
+запускается вообще, поэтому зелёный deploy-run нельзя читать как «e2e прошёл».
+
+### Проверка результатов CI после пуша
+
+Первый реальный прогон browser matrix происходит на runner, а не на локальной
+машине: локально Firefox и WebKit проходят на 1 воркере, но состав, скорость и
+память Linux-раннера отличаются. Поэтому после пуша разработчика:
+
+1. дождаться завершения workflow и посмотреть, какие job вообще запустились;
+2. отдельно открыть non-blocking `e2e`, если он был в прогоне: его красный
+   статус не блокирует PR, но остаётся падением, и его нельзя выдавать за
+   «зелёный по умолчанию»;
+3. если `e2e` не запускался (прямой пуш в `main`), сказать это прямо: matrix на
+   раннере ещё не проверена, и её можно прогнать через PR или
+   `gh workflow run quality.yml`;
+4. сообщить фактический результат (passed, failed, skipped) в отчёте агента.
+
+Красный `e2e` только из-за ресурсов раннера фиксируется как ограничение
+окружения: сначала проверяется один проект и один spec, а не увеличиваются
+таймауты под конкретную машину.
+
+### Измеренная стоимость прогона
+
+Замер на ручном запуске `quality.yml` (276 e2e-тестов, 4 проекта,
+ubuntu-latest):
+
+| Этап              | Время    |
+| ----------------- | -------- |
+| `verify` job      | ~1 мин   |
+| `e2e` job целиком | ~3.1 мин |
+| из них сами тесты | ~2.2 мин |
+| весь run          | ~4.2 мин |
+
+Browser matrix стоит около трёх минут, поэтому её дешёво держать на каждом PR.
+Полный прогон локально на 1 воркере — заметно дольше (~7 мин), и именно поэтому
+локальные правила нагрузки описаны в `docs/agent-workflow.md`.
+
 ## Локальная диагностика
 
 При медленном полном прогоне сначала запускай минимальную команду из таблицы, а