diff --git a/AGENTS.md b/AGENTS.md index 028ab9d6..5a422f52 100644 --- a/AGENTS.md +++ b/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: diff --git a/PROCESS.md b/PROCESS.md index f0d32cf9..940f5ff1 100644 --- a/PROCESS.md +++ b/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. Запрещено