docs: a failed pre-release gate does not send the issue back to review

The implementation loop runs typecheck, unit and build. Golden, browser smokes,
performance and the full HA harness run before a beta — after the code review has
passed and the issue already sits in S8-merged. Some defects cannot surface any
earlier, and until now the process had nothing to say about them, so the honest
reading was a second full review cycle at the most expensive possible moment.

The owner's decision: fix it, re-run what failed, and a green run carries the
release on. The gate named the defect precisely and the same gate proves the fix,
so the check is objective and depends on nobody's judgement.

The boundary is written down with it, because "the gate found something" could
otherwise absorb an arbitrary amount of new work. A fix that changes a behaviour
contract, reaches an untouched subsystem or rivals the task in size goes through
the normal flow. Editing a test so it stops failing is concealment rather than
repair — the exception is a defect proven to be in the fixture, as on #89.

The rule also records what it costs: the author judges his own work here, which
the process refuses everywhere else. That is the price of speed at the one point
where a review cycle is dearest, and the compensation is that the re-run command
and its result are written into the issue where the release manager reads them.

Issue: #114
User-Visible: no

AGENTS.md

@@ -190,6 +190,29 @@ What the new label means:
 **After a review run the label always changes.** If it did not, the run itself
 failed rather than the work — say so to the owner instead of polling on.
 
+**A failed pre-release gate does not send the issue back to review.** The
+implementation loop runs only typecheck, unit and build; golden, browser smokes,
+performance and the full HA harness run before a beta, which is after the code
+review has passed and the issue sits in `S8-merged`. Some defects cannot surface
+any earlier.
+
+Fix it, re-run what failed, and a green run is enough for the release to continue.
+The issue stays in `S8-merged`. Record the **exact command and its result** in the
+issue — "verified" without a command proves nothing. Trailers as usual, and
+`User-Visible: yes` still means both changelogs in the same commit.
+
+The exception covers repairing the defect the gate named, not carrying on
+development under the name of a repair. It goes through the normal flow — a new
+issue, or back to `S6-in-progress` — if the fix changes a behaviour contract, gives
+the user something new, reaches a subsystem the task never touched, or is
+comparable in size to the task itself. And editing the gate so it stops failing is
+concealment, not repair; the exception is a defect proven to be **in the fixture**,
+as on #89, where the sun sat at azimuth 180° and the only window faced north, so no
+ray was ever built.
+
+Baselines are still accepted only via `npm run golden:accept -- --reviewed` on a
+complete Linux CI artefact. "So the gate goes green" is not a reason.
+
 The exchange happens in **issue comments** — there is no local message bus. Verdict
 format:
 

PROCESS.md

@@ -287,7 +287,8 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
 
 **Что не упрощается:** issue, оценка, статусы, трейлеры коммитов, changelog,
 **код-ревью и его документ**, закрытие после беты. Код-ревью не пропускается
-никогда — именно оно в этом процессе заменяет тестирование.
+никогда — именно оно в этом процессе заменяет тестирование. Единственное
+исключение — починка упавшего предрелизного гейта, §11.4.
 
 Если по ходу выясняется, что критерий нарушен (появилась миграция, задело второй
 модуль) — метка `small` снимается, issue возвращается в `S3-spec` и получает
@@ -432,6 +433,10 @@ python -m pytest tests_backend -q     # py3.13, если менялся бэке
 
 **Гейт беты** (условие закрытия issue): CI Validate зелёный на точном SHA тега.
 
+Часть гейтов запускается только здесь, то есть **после** пройденного код-ревью.
+Упавший предрелизный гейт автор чинит и повторно прогоняет; зелёный прогон
+достаточен для продолжения релиза, повторное код-ревью не требуется — §11.4.
+
 **Гейт стабильного релиза:** полный локальный прогон плюс Validate и Full
 Performance зелёные на точном SHA; статусов issue не касается.
 
@@ -660,6 +665,53 @@ Medium-находку, кладёт документ в `docs/reviews/` ветк
 идут под квартальный umbrella-issue «Гигиена репозитория»; каждый коммит
 ссылается на него. Трассируемость 1:1 сохраняется.
 
+### 11.4 Починка предрелизных гейтов без повторного код-ревью
+
+Решение владельца 2026-08-13.
+
+В цикле реализации гоняется только лёгкий набор — typecheck, unit, build (§8).
+Golden, браузерные смоки, performance и полный HA-харнесс запускаются перед бетой,
+то есть **после** того, как код-ревью пройдено и issue в `S8-merged`. Часть
+проблем физически не может быть найдена раньше.
+
+**Если предрелизный гейт упал, автор правит, повторно прогоняет упавшее, и
+зелёного прогона достаточно, чтобы релиз продолжился.** Issue остаётся в
+`S8-merged` и на повторное код-ревью не отправляется.
+
+Причина: полный цикл ревью в момент выпуска стоит дороже, чем риск, который он
+здесь снимает. Гейт уже назвал дефект точно, а исправление проверяется тем же
+гейтом — то есть проверка объективна и не зависит от чьего-либо суждения.
+
+**Что при этом обязательно:**
+
+- прогон упавшего гейта записан в issue: **точная команда и её результат**.
+  «Verified» без команды доказательством не является (§8);
+- трейлеры на коммите как обычно, `Issue: #NN` того же issue;
+- при `User-Visible: yes` — правки в оба changelog в том же коммите;
+- эталоны golden принимаются только через `npm run golden:accept -- --reviewed`
+  на полном артефакте Linux CI. «Чтобы гейт позеленел» основанием не является.
+
+**Границы, за которыми исключение не действует.** Оно про починку названного
+гейтом дефекта, а не про продолжение разработки под видом починки. Правка идёт
+обычным путём — новым issue либо возвратом в `S6-in-progress` — если она:
+
+- меняет контракт поведения или добавляет пользователю что-то новое;
+- задевает подсистему, которой в исходной задаче не было;
+- по объёму сопоставима с самой задачей;
+- меняет сам гейт вместо кода — правка теста, чтобы он перестал падать, это не
+  починка, а сокрытие. Исключение — когда дефект **в фикстуре** и это доказано
+  разбором, как на #89: солнце на азимуте 180° и единственное окно на северной
+  стене, поэтому луч честно не строился.
+
+Границу определяет автор, и здесь процесс сознательно отдаёт ему то, что в
+остальных местах не доверяет — оценку собственной работы. Плата за скорость в
+единственной точке, где цикл ревью стоит дороже всего. Компенсируется тем, что
+запись в issue публична и релиз-менеджер видит, что именно было сделано перед
+выпуском.
+
+Это исключение из правила «код-ревью не пропускается никогда» (§5, §7.1) —
+единственное, и относится только к окну между `S8-merged` и выпуском.
+
 ---
 
 ## 12. Запрещено