diff --git a/editorial/agent-rewrites/187.json b/editorial/agent-rewrites/187.json
index 74be7c0..868210f 100644
--- a/editorial/agent-rewrites/187.json
+++ b/editorial/agent-rewrites/187.json
@@ -3,5 +3,5 @@
   "slug": "editorial-2022-10-field-ui-tests",
   "title": "UI-тест после клика: ждать состояние, а не время",
   "excerpt": "Как разобрать flaky UI-тест: связать действие с наблюдаемым состоянием, отсеять устаревший ответ и проверить отказ без ложного успеха.",
-  "contentHtml": "<p>UI-тест иногда падает после успешного клика: поле заполнилось, кнопка нажалась, а проверка не нашла сообщение «Сохранено». В коде обычно стоит <code>wait(1000)</code> или увеличенный timeout. На быстрой машине тест успевает увидеть результат. На занятой машине он ждёт слишком мало. После увеличения паузы тот же дефект просто проявляется позже. Цена ошибки — зелёный CI без доверия, медленная диагностика и риск выпустить сценарий, который теряет данные или принимает не тот ответ.</p>\n<p>Причина часто лежит не в скорости. Тест не знает, какое состояние должно наступить после действия. Он ждёт время, исчезновение spinner или случайный текст. Надёжная проверка связывает четыре факта: действие пользователя, переход состояния, видимое подтверждение и ветку отказа. Таймаут ограничивает ожидание. Он не заменяет условие готовности.</p>\n<h2>Сначала опишите наблюдаемый симптом</h2>\n<p>Запишите падение буквально. Какое действие выполнил тест? Что он проверял сразу после действия? Какой элемент искал? Был ли между ними sleep? Не начинайте с гипотезы «сервер медленный». Один timeout может скрывать несколько причин: запрос не отправился, submit сработал дважды, ответ относится к старой попытке, ошибка не попала в интерфейс или assertion ждёт внутренний флаг.</p>\n<p>Полезная граница проходит между переходом и наблюдением. Переход меняет состояние приложения: форма переходит из <code>editing</code> в <code>submitting</code>. Наблюдение сообщает об этом пользователю: статус получает роль <code>status</code> и имя «Отправка ожидает подтверждения». Assertion проверяет наблюдение. Если тест знает только, что после клика прошла секунда, он не проверяет переход.</p>\n<div class=\"table-scroll\"><table><caption>Симптом → причина → проверка → действие</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>sleep после submit</td><td>нет названного pending-состояния</td><td>после submit проверить <code>submitting</code></td><td>добавить видимый status</td></tr><tr><td>успех иногда старый</td><td>ответ не связан с попыткой</td><td>сравнить <code>requestId</code></td><td>игнорировать stale reply</td></tr><tr><td>два клика создают два запроса</td><td>нет guard на переходе</td><td>повторить submit в <code>submitting</code></td><td>заблокировать второй переход</td></tr><tr><td>ошибка заканчивается timeout</td><td>нет recovery-состояния</td><td>передать отказ без подтверждения</td><td>показать alert и сохранить черновик</td></tr><tr><td>тест ждёт private flag</td><td>проверка не видит пользовательский результат</td><td>сопоставить flag и доступное имя</td><td>утверждать public contract</td></tr></tbody></table></div>\n<h2>Механизм: состояние владеет результатом</h2>\n<p>Рассмотрим форму, которая отправляет текст. После submit приложение создаёт идентификатор попытки и переходит в <code>submitting</code>. Пока подтверждение не пришло, повторный submit запрещён. Ответ считается текущим только тогда, когда его <code>requestId</code> совпадает с идентификатором состояния. Успешный ответ переводит форму в <code>saved</code>. Отсутствующий или отрицательный ответ переводит её в <code>recovery-required</code>, а не в ложный успех.</p>\n<p>Идентификатор нужен не для красоты. Пользователь может быстро повторить действие после ошибки. Первый ответ способен прийти после второй попытки. Без корреляции приложение примет старый ответ за новый и закроет форму с неверным результатом. Поэтому проверка должна включать отрицательный путь: stale reply не меняет состояние, а отказ оставляет данные для восстановления.</p>\n<figure><img src=\"/assets/editorial/2022/ui-tests-2022-diagnosis-rollback.svg\" alt=\"Схема UI-проверки: submit переводит форму в submitting, совпавший requestId ведёт в saved, устаревший ответ игнорируется, отсутствие подтверждения ведёт в recovery-required с сохранением черновика.\" loading=\"lazy\" /><figcaption>Состояние формы и ответ сервера разделены идентификатором попытки. Иллюстрация показывает учебную модель, а не trace реального браузера.</figcaption></figure>\n<h2>Конкретный пример</h2>\n<p>Ниже — учебная модель переходов. Она не открывает страницу, не отправляет HTTP-запрос и не доказывает свойства production-кода. В ней оставлены только условия, которые нужно увидеть в настоящем компоненте и затем перенести в browser-тест.</p>\n<pre><code>const pending = { phase: 'submitting', requestId: 'request-01' }; const reply = { requestId: 'request-01', outcome: 'accepted' }; const saved = reply.requestId === pending.requestId && reply.outcome === 'accepted' ? { ...pending, phase: 'saved' } : pending;</code></pre>\n<p>В этой строке <code>saved.phase</code> станет <code>saved</code> только для текущего ответа. Если заменить идентификатор на <code>request-00</code>, состояние останется <code>submitting</code>. В настоящей модели добавьте отдельную ветку <code>recovery-required</code> для отказа и сохраните текст черновика. Значения <code>request-01</code> и <code>accepted</code> — проектные значения учебного примера. Реальное приложение может использовать UUID, серверную версию или другой токен.</p>\n<p>В browser-тесте проверяйте доступный результат, если он составляет часть интерфейсного контракта:</p>\n<pre><code>await page.getByRole('button', { name: 'Сохранить' }).click(); await expect(page.getByRole('status')).toHaveText('Отправка ожидает подтверждения'); // Учебный пример: способ контроля ответа зависит от стенда. await expect(page.getByRole('status')).toHaveText('Изменение сохранено');</code></pre>\n<p>Playwright повторяет web assertion до выполнения условия или истечения timeout. Это помогает пережить нормальную асинхронность. Но инструмент не угадывает правильное условие. <code>toBeVisible()</code> на spinner может пройти, когда работа только началась. Assertion на произвольный текст «Успех» может поймать старое сообщение. В тесте должны совпасть действие, state и наблюдаемая семантика.</p>\n<h2>Порядок исправления</h2>\n<ol><li>Зафиксируйте исходное падение: действие, assertion, locator, timeout и последний видимый статус.</li><li>Нарисуйте короткую шкалу без времени: <code>editing</code> → <code>submitting</code> → <code>saved</code> или <code>recovery-required</code>.</li><li>Назовите публичные наблюдения для pending, успеха и отказа. Выберите роль и имя, которые нужны пользователю, а не только тесту.</li><li>Добавьте проверку переходов рядом с владельцем состояния. Покройте повторный submit, stale reply и возврат к редактированию после отказа.</li><li>Выберите разрешённый способ управлять ответом в тестовом окружении. Учебный пример не означает, что такой контроль подходит каждому стенду.</li><li>Замените sleep на assertion, которое ждёт конкретный condition. Укажите специальный timeout только после того, как условие стало правильным.</li><li>Проверьте отрицательную ветку. Ошибка должна быть видна, черновик — сохранён, а старый ответ — не менять новую попытку.</li><li>Удаляйте новый state и assertion вместе, если согласованный UX не принимает переход. Не оставляйте locator или <code>data-testid</code> без владельца.</li></ol>\n<h2>Ограничения</h2>\n<p>Модель не описывает router, кеш, несколько вкладок, повторную отправку, авторизацию, локализацию, сетевые ретраи и серверную идемпотентность. Она не говорит, что любой stale reply нужно молча отбросить. В некоторых системах нужен повторный read, журнал конфликта или reconciliation с сервером. Эти решения относятся к доменному протоколу, а не к одному UI-тесту.</p>\n<p>Роль <code>status</code> и <code>alert</code> в примере — требование к наблюдаемому контракту. Она не заменяет полноценную проверку доступности. Тест может найти доступное имя и всё равно пропустить плохой фокус, неверный порядок чтения или недоступную ошибку. Для этого нужны отдельные проверки и ручная оценка интерфейса.</p>\n<p>Учебный код не измеряет flake rate, длительность CI или влияние на production. После изменения такие утверждения требуют отдельного отчёта: версия раннера и браузера, окружение, число запусков, результаты и известные исключения. Здесь проверяется только логика переходов и выбранный пользовательский сигнал.</p>\n<h2>Критерий готовности</h2>\n<p>Изменение готово, если любой reviewer может пройти сценарий по состояниям и ответить на четыре вопроса. Какое действие запускает переход? Какой видимый факт подтверждает pending и success? Что происходит при отказе? Почему старый ответ не может подтвердить новую попытку? В коде должны существовать проверки этих веток, а browser-тест должен ждать состояние, а не прошедшее время.</p>\n<p>Формулируйте результат узко: «тест ждёт status с именем “Изменение сохранено” после ответа текущей попытки и проверяет recovery при отказе». Не пишите «флак устранён», если нет повторяемого измерения. Такая формулировка связывает изменение с наблюдаемым условием и оставляет место для следующего дефекта.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://playwright.dev/docs/test-assertions\" target=\"_blank\" rel=\"noopener noreferrer\">Playwright: Assertions</a> — официальная документация описывает web assertions, которые повторяют проверку до выполнения условия или истечения timeout.</li><li><a href=\"https://www.w3.org/TR/webdriver2/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C WebDriver</a> — официальный стандарт описывает протокол удалённого управления браузером; он не определяет смысл прикладного состояния «сохранено».</li><li><a href=\"https://www.w3.org/TR/WCAG22/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C Web Content Accessibility Guidelines 2.2</a> — нормативные требования задают границу для доступности интерфейса; наличие роли в тесте само по себе не доказывает соответствие.</li></ul>"
+  "contentHtml": "<p>На прогоне формы тест заполнял поле и нажимал «Сохранить». Иногда следующий шаг не находил сообщение «Изменение сохранено», хотя клик уже состоялся. В тесте стояла фиксированная пауза: на быстрой машине её хватало, на занятом CI — нет. Увеличение паузы лишь снижало частоту падения и делало прогон дольше. Цена ошибки — недоверие к результату сборки и риск принять старый или неполный ответ за результат текущего сохранения.</p>\n<p>Первое предположение обычно звучит как «сервер медленный». Но тест в этот момент не знает, какого события ждёт. Он может проверять истёкшую секунду, исчезнувший spinner или текст, оставшийся от предыдущей попытки. Надёжный сценарий связывает действие, переход состояния, пользовательское подтверждение и отказ. Таймаут ограничивает поиск результата, но не определяет сам результат.</p>\n<h2>Сцена: что именно упало</h2>\n<p>Начните с одного конкретного падения. Зафиксируйте маршрут, исходные данные, действие, locator и последний видимый статус. Если в trace видно только клик, это ещё не объясняет причину. Запрос мог не уйти, ответ мог прийти от первой попытки, обработчик мог дважды отправить форму, а ошибка могла остаться только в консоли.</p>\n<p>Разделите проверку на два наблюдения. Клик проверяет готовность элемента к действию. После клика нужен отдельный контракт результата: например, область с ролью <code>status</code> меняет текст на «Отправка...», а затем на «Изменение сохранено». Внутреннее поле <code>phase</code> помогает приложению управлять переходом, но не является хорошим единственным объектом для e2e-проверки: пользователь его не видит.</p>\n<div class=\"table-scroll\"><table><caption>От симптома к проверяемой гипотезе</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Гипотеза</th><th scope=\"col\">Минимальная проверка</th><th scope=\"col\">Решение</th></tr></thead><tbody><tr><td>После submit стоит sleep</td><td>Не названо состояние ожидания</td><td>Посмотреть DOM и trace между кликом и ответом</td><td>Добавить pending-сигнал и ждать его</td></tr><tr><td>Старый успех проходит иногда</td><td>Ответ не связан с попыткой</td><td>Сравнить идентификатор ответа с текущим</td><td>Игнорировать stale reply</td></tr><tr><td>Два клика дают два запроса</td><td>Повторный submit не блокируется</td><td>Задержать ответ и повторить клик</td><td>Запретить переход из <code>submitting</code></td></tr><tr><td>Отказ заканчивается timeout</td><td>Нет видимого recovery</td><td>Вернуть из стенда ошибку 500</td><td>Показать ошибку и оставить черновик</td></tr><tr><td>Тест читает private flag</td><td>Проверяется деталь реализации</td><td>Сопоставить результат с UI-контрактом</td><td>Утверждать пользовательское поведение</td></tr></tbody></table></div>\n<h2>Механизм: состояние владеет результатом</h2>\n<p>Для одной попытки достаточно явно разделить четыре состояния: <code>editing</code>, <code>submitting</code>, <code>saved</code> и <code>recovery-required</code>. При submit приложение сохраняет черновик, назначает <code>requestId</code> и переходит в <code>submitting</code>. Пока этот переход не завершён, второй submit не создаёт новую попытку. Ответ разрешено применить только при совпадении его идентификатора с текущим.</p>\n<p>Такой идентификатор — проектное решение, а не требование Playwright или WebDriver. Он нужен там, где ответы могут приходить не по порядку. Если первая попытка завершилась после второй, обработчик без корреляции может показать «Сохранено» для уже неактуального текста. При несовпадении идентификатора состояние не меняется. При отказе оно переходит в recovery, а черновик остаётся доступным для исправления или повторной отправки.</p>\n<figure><img src=\"/assets/editorial/2022/ui-tests-2022-diagnosis-rollback.svg\" alt=\"Схема диагностики UI-теста: после submit форма переходит в submitting, ответ сверяется с request id, совпавший успех ведёт в saved, stale reply игнорируется, а отказ ведёт в recovery с сохранением черновика.\" loading=\"lazy\" /><figcaption>Состояние формы и ответ сервера разделены идентификатором попытки. Это учебная модель для проверки, а не trace реального браузера.</figcaption></figure>\n<h2>Маленькая модель для воспроизведения</h2>\n<p>Сначала проверьте переходы отдельно от браузера. В примере ниже обработчик не зависит от времени: он принимает только ответ для текущего состояния. Тексты сообщений и значения <code>requestId</code> — проектные, поэтому в настоящем приложении их нужно заменить на свои.</p>\n<pre><code>type Phase = 'editing' | 'submitting' | 'saved' | 'recovery-required';\n\ntype State = {\n  phase: Phase;\n  draft: string;\n  requestId?: string;\n  message: string;\n};\n\ntype Reply = {\n  requestId: string;\n  outcome: 'accepted' | 'rejected';\n};\n\nfunction applyReply(state: State, reply: Reply): State {\n  if (state.phase !== 'submitting' || state.requestId !== reply.requestId) {\n    return state;\n  }\n\n  return reply.outcome === 'accepted'\n    ? { ...state, phase: 'saved', message: 'Изменение сохранено' }\n    : {\n        ...state,\n        phase: 'recovery-required',\n        message: 'Не удалось сохранить. Черновик остался в форме',\n      };\n}</code></pre>\n<p>Состояние с <code>requestId: 'request-02'</code> должно проигнорировать ответ с <code>requestId: 'request-01'</code>: фаза останется <code>submitting</code>, а текст черновика не изменится. Ответ <code>accepted</code> для <code>request-02</code> переводит состояние в <code>saved</code>. Ответ <code>rejected</code> для той же попытки переводит его в <code>recovery-required</code>. Это и есть воспроизводимая проверка гонки, а не надежда на случайный порядок сетевых событий.</p>\n<h2>Browser-тест: задержать ответ, а не тест</h2>\n<p>Когда переходы определены, зафиксируйте их через видимый контракт. Playwright ждёт готовность элемента перед действием, а web-first assertion повторяет проверку до совпадения или истечения timeout. Поэтому задержку стоит вводить в контролируемый ответ стенда, чтобы проверить pending и success в известном порядке.</p>\n<pre><code>import { test, expect } from '@playwright/test';\n\ntest('waits for the current save result', async ({ page }) =&gt; {\n  let releaseResponse = () =&gt; {};\n  const responseReleased = new Promise((resolve) =&gt; {\n    releaseResponse = resolve;\n  });\n\n  await page.route('**/api/profile', async (route) =&gt; {\n    await responseReleased;\n    await route.fulfill({\n      status: 200,\n      contentType: 'application/json',\n      body: JSON.stringify({ ok: true }),\n    });\n  });\n\n  await page.goto('/profile');\n  await page.getByLabel('Описание').fill('черновик');\n  await page.getByRole('button', { name: 'Сохранить' }).click();\n  await expect(page.getByRole('status')).toHaveText('Отправка...');\n  releaseResponse();\n  await expect(page.getByRole('status')).toHaveText('Изменение сохранено');\n});</code></pre>\n<p>Маршрут <code>**/api/profile</code>, URL, подпись поля и тексты в этом фрагменте принадлежат учебной форме. Их нужно заменить на контракт своего стенда. Смысл примера в другом: тест сначала задерживает ответ, убеждается в pending, затем разрешает ответ и ждёт success. В нём нет <code>waitForTimeout</code>, а timeout assertion остаётся страховкой для настоящего зависания.</p>\n<h2>Отказ и устаревший ответ</h2>\n<p>Положительный путь не доказывает устойчивость. Отдельным тестом верните из контролируемого endpoint отказ и проверьте две вещи: ошибка доступна пользователю, а введённый текст не потерян. Для сообщения, которое не требует немедленного прерывания работы, подходит <code>status</code>. Существенную и срочную ошибку можно объявить через <code>alert</code>, но роль не должна подменять проектирование фокуса и способ восстановления.</p>\n<pre><code>await page.route('**/api/profile', (route) =&gt; route.fulfill({\n  status: 500,\n  contentType: 'application/json',\n  body: JSON.stringify({ ok: false }),\n}));\n\nawait page.getByRole('button', { name: 'Сохранить' }).click();\nawait expect(page.getByRole('alert')).toHaveText('Не удалось сохранить');\nawait expect(page.getByLabel('Описание')).toHaveValue('черновик');</code></pre>\n<p>Для stale reply нужен контролируемый порядок двух ответов или unit-тест функции перехода из предыдущего раздела. Не подменяйте эту проверку повторным запуском: десять удачных прогонов не создают гонку, если стенд ни разу не поменял порядок ответов. В browser-тесте также проверьте, что второй клик во время <code>submitting</code> не создаёт второй запрос; это отдельное утверждение, а не побочный эффект ожидания.</p>\n<h2>Порядок исправления</h2>\n<ol><li>Запишите исходное падение: маршрут, данные, действие, locator, assertion, timeout и последний видимый статус.</li><li>Включите trace на первом retry и проверьте DOM-снимки, сеть и последовательность действий.</li><li>Нарисуйте переходы <code>editing</code> → <code>submitting</code> → <code>saved</code> или <code>recovery-required</code>.</li><li>Назначьте владельца каждого перехода: компонент формы меняет state, транспорт возвращает outcome, интерфейс показывает status или alert.</li><li>Свяжите ответ с текущей попыткой. При несовпадении идентификатора не закрывайте форму и не показывайте успех.</li><li>Замените фиксированную паузу на web-first assertion, которое ждёт конкретный текст, атрибут или доступное состояние.</li><li>Заморозьте ответы стенда для success, отказа и перестановки ответов. Проверьте повторный submit и сохранение черновика.</li><li>После изменения сравните результат на чистых данных и в том же браузере, где возникло падение.</li></ol>\n<h2>Ограничения и критерий готовности</h2>\n<p>Эта схема не решает серверную идемпотентность, конфликт нескольких вкладок, авторизацию, кеш, ретраи транспорта и reconciliation. Если сервер принял запрос, а клиент потерял ответ, одного <code>recovery-required</code> недостаточно: может потребоваться повторное чтение или журнал операции. Решение о повторе зависит от доменного протокола.</p>\n<p>Роль <code>status</code> имеет смысл только при корректно выбранном сообщении. WAI-ARIA 1.1 описывает её как live region с advisory-информацией и ненавязчивым уведомлением; <code>alert</code> предназначен для важной, обычно срочной информации. Автотест с <code>getByRole</code> проверяет наличие заявленного интерфейсного сигнала, но не заменяет ручную проверку фокуса, клавиатуры, порядка чтения и локализации.</p>\n<p>Изменение готово, если можно воспроизвести задержанный success, отказ, повторный submit и stale reply, а для каждой ветки назвать видимый результат. Формулируйте итог узко: «тест ждёт status текущей попытки и оставляет черновик при отказе». Фраза «flaky-тест исправлен» требует отдельного измерения: версия браузера и runner, окружение, число повторов, доля падений до и после.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://playwright.dev/docs/test-assertions\" target=\"_blank\" rel=\"noopener noreferrer\">Playwright: Assertions</a> — официальная документация описывает web assertions, которые повторяют проверку до выполнения условия или истечения timeout.</li><li><a href=\"https://playwright.dev/docs/best-practices\" target=\"_blank\" rel=\"noopener noreferrer\">Playwright: Best Practices</a> — руководство рекомендует проверять поведение, видимое пользователю, изолировать тесты, использовать пользовательские locators и web-first assertions.</li><li><a href=\"https://www.w3.org/TR/2017/REC-wai-aria-1.1-20171214/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C WAI-ARIA 1.1 Recommendation</a> — нормативная спецификация определяет роли <code>status</code> и <code>alert</code> и их live-region semantics; это источник для выбора доступного сигнала, но не доказательство корректности конкретного интерфейса.</li></ul>"
 }