ci: update docs, verify on push

docs/quality-gates.md

@@ -83,14 +83,17 @@ per-project лимит воркеров, а browser matrix упирается в
 
 ### Что и когда запускается
 
-| Workflow                 | Триггер                  | Jobs                        |
-| ------------------------ | ------------------------ | --------------------------- |
-| `Deploy to GitHub Pages` | push в `main`, dispatch  | `verify`, `build`, `deploy` |
-| `Quality`                | `pull_request`, dispatch | `verify`, `e2e`             |
+| Workflow                 | Триггер                                 | Jobs                        |
+| ------------------------ | --------------------------------------- | --------------------------- |
+| `Deploy to GitHub Pages` | push в `main`, dispatch                 | `verify`, `build`, `deploy` |
+| `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,17 +102,17 @@ 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` только из-за ресурсов раннера фиксируется как ограничение
-окружения: сначала проверяется один проект и один spec, а не увеличиваются
-таймауты под конкретную машину.
+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, а не увеличиваются
+   таймауты под конкретную машину.
 
 ### Измеренная стоимость прогона