perf: make review scope and ceremony fit the size of the task

The owner's report: the process works but every stage takes a long time even on
simple bugs. Two causes, and neither was the one that first comes to mind.

The reviewer ran everything regardless. On #89 it installed Chromium, ran all 127
smoke files and a full golden capture — right for a task rated 10/10 for
complexity, absurd for a bug about a room divider. Full suites are the pre-beta
gate; the review now runs typecheck, unit and build always, and smokes, golden,
pytest or performance only where the diff and the AC call for them. The price of
narrowing it is honesty: the reviewer must list which gates it ran, which it did
not, and why, so a skipped gate is a visible decision rather than a silent one.

The reviewer also built its own environment out of model turns, with no npm cache
and no browser cache, paid for from the same forty-five minutes. The workflow now
installs dependencies and Chromium as ordinary cached steps, after switching to
the task branch so the lockfile is the branch's own.

Second, ceremony did not scale down. The light track makes a spec cheap; the new
trivial track does without one — S2-analysis straight to S5-ready, no spec review,
AC in the issue body. It is deliberately hard to qualify for: a bug on one surface,
no new UX contract, no migration, no i18n, no perf or touch effect, three checkable
AC at most, and expected behaviour already on record. Nothing left to decide is the
criterion that holds the whole thing up, and it cannot be met by feeling sure.

Code review is never skipped on either track. It is what stands in for testing
here, so it is the one stage speed may not buy.

Issue: #127
Issue: #128
User-Visible: no

PROCESS.md

@@ -70,7 +70,8 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
        → S6-in-progress → S7-code-review ⟲ → S8-merged → закрыт при выпуске беты
 
 служебные:  blocked (поверх статуса)   rejected (закрыт)
-⟲ — возврат на правки, не более 4 циклов (§4), на лёгком треке 2
+⟲ — возврат на правки, не более 4 циклов (§4), на лёгком и коротком треке 2
+короткий трек (`trivial`, §5.1) идёт S2-analysis → S5-ready, минуя S3 и S4
 ```
 
 Переходы `S4-spec-review` и `S7-code-review` выполняются **автоматически**: метка
@@ -294,6 +295,42 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
 модуль) — метка `small` снимается, issue возвращается в `S3-spec` и получает
 нормальный файл ТЗ. Это не провал, это ранняя диагностика.
 
+### 5.1 Короткий трек (метка `trivial`)
+
+Решение владельца 2026-08-13, issue #128. Лёгкий трек делает ТЗ дешёвым; короткий
+обходится без него совсем.
+
+**Маршрут:** `S1-new` → `S2-analysis` → `S5-ready` → `S6-in-progress` →
+`S7-code-review` → `S8-merged`. Стадии `S3-spec` и `S4-spec-review` пропускаются.
+
+`S2-analysis` остаётся: это комментарий, а не прогон CI, и именно там владелец
+решает приоритет и ценность. AC пишет автор в теле issue при переводе в
+`S5-ready` — до перехода, иначе ревьюеру нечего будет сверять.
+
+**Критерии, все обязательны:**
+
+- тип `bug`;
+- правка ограничена одной поверхностью, нового UX-контракта нет;
+- нет миграции конфига, новых ключей i18n, влияния на перф и touch;
+- AC выражаются тремя проверяемыми утверждениями или меньше;
+- **ожидаемое поведение уже зафиксировано** — в `docs/USER-GUIDE.ru.md`, в
+  каноническом документе подсистемы либо однозначно в самом отчёте. Решать нечего.
+  Если есть что решать, это `S3-spec`, и никакая экономия этого не отменяет.
+
+Метка ставится в `S2-analysis` вместе с остальными оценками, одним комментарием,
+где владелец утверждает и приоритет.
+
+**Что не упрощается:** issue, оценка, статусы, трейлеры, changelog и **код-ревью**.
+Лимит циклов код-ревью — 2, как на лёгком треке.
+
+Если по ходу выясняется, что критерий нарушен, метка снимается и issue уходит в
+`S3-spec` за нормальным ТЗ. Как и на лёгком треке, это не провал, а ранняя
+диагностика.
+
+**Чем этот трек опасен.** Он убирает единственное место, где решение проверялось
+до написания кода. Признак «решать нечего» держит всю конструкцию, и его нельзя
+подтверждать ощущением — только ссылкой на уже зафиксированное поведение.
+
 ---
 
 ## 6. Роли
@@ -431,6 +468,17 @@ npm run golden:verify                 # если менялся визуал
 python -m pytest tests_backend -q     # py3.13, если менялся бэкенд
 ```
 
+**Объём гейтов на код-ревью соразмерен задаче** (issue #127). Всегда:
+`typecheck`, `npm test`, `npm run build` со сверкой трёх копий бандла. По
+необходимости, определяемой diff'ом и AC: браузерные смоки (их 127 — прогон всех
+уместен только когда задача задевает всё), `golden:verify` при изменении видимого
+результата, `pytest tests_backend` при правках в Python, performance-профили при
+названном в AC влиянии. **Полные наборы — предрелизный гейт, а не гейт ревью.**
+
+Условие честности такого сужения: ревьюер обязан перечислить, какие гейты прогнал,
+какие нет и почему. Непрогнанный гейт становится видимым решением, а не молчаливым
+пропуском.
+
 **Гейт беты** (условие закрытия issue): CI Validate зелёный на точном SHA тега.
 
 Часть гейтов запускается только здесь, то есть **после** пройденного код-ревью.
@@ -464,8 +512,8 @@ Project v2 остаётся человеческим представление
 | `blocked` | Ждём внешнего или владельца, **поверх** статусной метки |
 | `rejected` | Отклонено, issue закрыт |
 
-Модификаторы: `small` (лёгкий трек, сложность ≤3), `hotfix`, `process`,
-`review-4`; приоритет `P1`/`P2`/`P3`; тип `bug`/`feature`/`tech-debt`.
+Модификаторы: `small` (лёгкий трек, сложность ≤3), `trivial` (короткий трек,
+§5.1), `hotfix`, `process`, `review-4`; приоритет `P1`/`P2`/`P3`; тип `bug`/`feature`/`tech-debt`.
 Тематические метки (`polish`, `infra`, `tests`, `docs`, `security`, `vacuum`)
 ортогональны процессу.