ci: update docs, verify on push

.github/workflows/quality.yml

@@ -1,6 +1,9 @@
 name: Quality
 
 on:
+  push:
+    branches:
+      - main
   pull_request:
   workflow_dispatch:
 

AGENTS.md

@@ -18,12 +18,11 @@
   (docs) + `pnpm --dir web exec prettier --check .` (код).
 - Полный быстрый gate: `pnpm verify`; подробная матрица команд и CI —
   `docs/quality-gates.md`.
-- После пуша результат CI проверяется явно: смотреть и blocking `verify`, и
-  non-blocking `e2e` — если тот job вообще запускался. `Quality` workflow живёт
-  на `pull_request` и `workflow_dispatch`, поэтому при прямом пуше в `main`
-  выполняется только `Deploy to GitHub Pages` со своим `verify`, а browser
-  matrix проверяется на PR или ручным запуском. Красный `e2e` не блокирует PR,
-  но остаётся падением — сообщать его фактический статус.
+- После пуша результат CI проверяется явно: смотреть статусы отдельных job, а не
+  общий conclusion прогона. У `e2e` стоит `continue-on-error`, поэтому прогон с
+  упавшим e2e помечается как `success`. `Quality` workflow запускается на каждом
+  пуше в `main` и на `pull_request`, поэтому browser matrix проверяется сама;
+  ручной запуск нужен только для старого коммита.
 - Линтинг: `pnpm --dir web lint` (ESLint). Полный прогон дизайн-проверок:
   `pnpm --dir web lint:all` (ESLint + stylelint + токен-аудит). Каждый шаг
   выполняется, даже если предыдущий упал. Новые изменения не должны добавлять

docs/agent-workflow.md

@@ -123,8 +123,8 @@ E2E запускается отдельно от быстрых проверок
 
 Коммит и пуш делает разработчик. После пуша агент проверяет результат CI и
 сообщает его вместе с локальными проверками, включая случай, когда нужный job не
-запускался: `Quality` workflow с browser matrix живёт на `pull_request` и
-`workflow_dispatch`, поэтому прямой пуш в `main` проверяет только быстрый gate.
-Процедура описана в `docs/quality-gates.md`.
+запускался: статусы смотрятся по отдельным job, потому что общий conclusion
+прогона с `continue-on-error` у `e2e` остаётся зелёным. Процедура описана в
+`docs/quality-gates.md`.
 
 Следующий шаг начинается только после ревью текущего изменения.

docs/plan-codebase-quality.md

@@ -112,7 +112,8 @@ pnpm --dir web test:e2e
 - Добавить отдельный workflow для pull request: typecheck, unit, rule-тесты,
   lint, format и build.
 - E2E сначала запускать отдельным job; сделать его blocking после закрытия
-  известных ошибок и стабилизации baseline.
+  известных ошибок и стабилизации baseline. Решение отложено: условия matrix
+  пересматриваются после Q6f.3, см. раздел 7 «Отложенное решение».
 
 **Готово, когда:** одна команда воспроизводит все быстрые проверки, а deploy не
 может пройти при type/unit/lint/build-ошибке.
@@ -498,3 +499,20 @@ refactor, новые i18n-правила и исправление продук
 - Какие unused design tokens можно удалить, а какие должны остаться?
 - Какие 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 прогона.

docs/quality-gates.md

@@ -84,13 +84,16 @@ per-project лимит воркеров, а browser matrix упирается в
 ### Что и когда запускается
 
 | Workflow                 | Триггер                                 | Jobs                        |
-| ------------------------ | ------------------------ | --------------------------- |
+| ------------------------ | --------------------------------------- | --------------------------- |
 | `Deploy to GitHub Pages` | push в `main`, dispatch                 | `verify`, `build`, `deploy` |
-| `Quality`                | `pull_request`, dispatch | `verify`, `e2e`             |
+| `Quality`                | push в `main`, `pull_request`, dispatch | `verify`, `e2e`             |
 
-Следствие: при прямом пуше в `main` выполняется только быстрый gate — `verify`
-внутри deploy-workflow. Browser matrix из четырёх проектов на этом прогоне не
-запускается вообще, поэтому зелёный deploy-run нельзя читать как «e2e прошёл».
+Пуш в `main` запускает оба workflow: deploy проверяет быстрый gate и собирает
+сайт, `Quality` прогоняет тот же `verify` и browser matrix. Дублирование
+`verify` (~1 мин) сознательное: matrix на каждый пуш стоит ~3 мин, и условные
+job-и ради минуты не окупаются. Browser matrix проверяется на каждом пуше, а
+ручной `gh workflow run quality.yml` нужен только для перепрогона старого
+коммита.
 
 ### Проверка результатов CI после пуша
 
@@ -99,15 +102,15 @@ per-project лимит воркеров, а browser matrix упирается в
 память Linux-раннера отличаются. Поэтому после пуша разработчика:
 
 1. дождаться завершения workflow и посмотреть, какие job вообще запустились;
-2. отдельно открыть non-blocking `e2e`, если он был в прогоне: его красный
-   статус не блокирует PR, но остаётся падением, и его нельзя выдавать за
-   «зелёный по умолчанию»;
-3. если `e2e` не запускался (прямой пуш в `main`), сказать это прямо: matrix на
-   раннере ещё не проверена, и её можно прогнать через PR или
-   `gh workflow run quality.yml`;
-4. сообщить фактический результат (passed, failed, skipped) в отчёте агента.
-
-Красный `e2e` только из-за ресурсов раннера фиксируется как ограничение
+2. смотреть статусы **отдельных job**, а не общий conclusion прогона: у `e2e`
+   стоит `continue-on-error: true`, поэтому прогон с упавшим e2e целиком
+   помечается как `success` — проверено на run `36225579363` (`E2E: failure` при
+   `conclusion: success`);
+3. если `e2e` запускался и зелёный — сообщить фактические числа passed, failed,
+   skipped;
+4. если `e2e` не запускался, сказать это прямо: matrix на раннере не проверена,
+   и её можно прогнать через `gh workflow run quality.yml`;
+5. красный `e2e` только из-за ресурсов раннера фиксируется как ограничение
    окружения: сначала проверяется один проект и один spec, а не увеличиваются
    таймауты под конкретную машину.