diff --git a/PROCESS.md b/PROCESS.md
index 51c346b3..6ae7241a 100644
--- a/PROCESS.md
+++ b/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`)
 ортогональны процессу.