diff --git a/editorial/agent-rewrites/192.json b/editorial/agent-rewrites/192.json
index 91fce62..bcc85ab 100644
--- a/editorial/agent-rewrites/192.json
+++ b/editorial/agent-rewrites/192.json
@@ -1,7 +1,7 @@
 {
   "index": 192,
   "slug": "editorial-2022-09-practice-mobile-ux",
-  "title": "Мобильное действие без скрытого шага: как убрать зависимость от hover",
-  "excerpt": "Если главное действие исчезает на узком экране, ищите не «неправильный breakpoint», а потерянный маршрут. Разбираем явный mobile-путь, отрицательную ветку и проверку, которую можно повторить.",
-  "contentHtml": "<p>На телефоне пользователь открывает экран заказа, видит сумму, но не находит переход к подтверждению. На десктопе переход появляется при наведении на строку таблицы. В другом варианте кнопка остаётся в последней колонке и уезжает за горизонтальный scroll. Симптом один: человек не может завершить действие, хотя данные уже введены.</p>\n<p>Цена ошибки не сводится к плохому впечатлению. Незавершённая форма создаёт обращение в поддержку. Скрытая команда провоцирует повторный ввод. Если команда временно увеличивает кнопку, но теряет детали перед подтверждением, пользователь получает новый путь с другим риском. Релиз при этом трудно проверить: непонятно, какой элемент владел переходом и при каком состоянии он исчезал.</p>\n<p>Тезис статьи простой: мобильный сценарий нужно проверять как маршрут, а не как набор размеров. У основного действия должны быть видимый контекст, явный переход к деталям и отдельное подтверждение. Hover может улучшать обзор, но не должен оставаться единственным способом добраться до операции. Это правило не доказывает удобство интерфейса. Оно задаёт минимальный контракт, который можно проверить в коде и затем подтвердить в браузере.</p>\n<h2>Сначала восстановите маршрут</h2>\n<p>Возьмём одно действие: проверить данные заказа и подтвердить его. Не переделываем весь экран. Сначала описываем три состояния. <code>summary</code> показывает предмет операции и краткий контекст. <code>details</code> открывает данные, которые нужно проверить до необратимого шага. <code>confirm</code> содержит явный control с понятной меткой.</p>\n<p>Такое разбиение отделяет содержание от раскладки. В узком контейнере строки могут перейти в столбец, а детали — открываться во вкладке или disclosure. Но порядок решения сохраняется. Человек сначала понимает, что изменится, потом смотрит данные и только затем подтверждает. Если компонент пропускает первый или второй шаг, изменение CSS не исправит потерю смысла.</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>summary</td><td>название операции и краткий контекст</td><td>состояние существует первым</td><td>что любой перевод поместится в одну строку</td></tr><tr><td>details</td><td>явный переход к данным</td><td>переход не требует hover</td><td>что выбранный accordion удобен всем</td></tr><tr><td>confirm</td><td>видимая метка основного действия</td><td>control достижим явным вводом</td><td>размер зоны нажатия и качество текста</td></tr><tr><td>rollback</td><td>сохранённый рабочий путь</td><td>непринятый маршрут не вытесняет текущий</td><td>автоматический откат серверного состояния</td></tr></tbody></table></div>\n<p>Слово «видимый» здесь означает часть проверяемого договора. Оно не означает, что элемент уже имеет правильный размер, цвет, фокус или положение. Эти свойства требуют отдельной проверки разметки и рендера. Контракт не заменяет accessibility review и usability study.</p>\n<h2>Механизм: почему hover ломает действие</h2>\n<p>Hover описывает возможность среды указателя, а не намерение человека. Один пользователь может подключить мышь к узкому экрану. Другой может использовать клавиатуру, экранную лупу или другой способ ввода. Поэтому условие <code>hover: none</code> не равно утверждению «здесь есть только touch». Оно лишь сообщает характеристику pointing device, которую браузер определил для среды.</p>\n<p>Проблема появляется, когда команда превращает эту характеристику в единственный путь. Иконка показывает tooltip только при наведении. Строка становится ссылкой только в <code>:hover</code>. Действие раскрывается по перемещению указателя, но не имеет кнопки и не получает фокус. На экране телефона этот путь может исчезнуть, а на клавиатуре — остаться недостижимым.</p>\n<p>Безопаснее разделить основной control и подсказку. Основной control присутствует в DOM и имеет текстовую метку. Hover может показать дополнительные сведения или подсветить область. Если hover недоступен, сведения остаются достижимыми через явную кнопку или ссылку. Такой механизм работает и на широкой странице: desktop получает ускоренное обнаружение, но не теряет базовый маршрут.</p>\n<h2>Учебный пример с отрицательной веткой</h2>\n<p>Ниже — маленькая модель маршрута. Она принимает три проектных значения: ширина контекста, характеристику основного указателя и доступность hover. Эти строки задаёт тест, а не браузер. Модель не читает <code>matchMedia</code>, не создаёт DOM, не отправляет pointer events и не измеряет людей. Поэтому её результат ограничен проверкой порядка шагов и отказа от hover-only.</p>\n<pre><code>function planMobilePath(profile, action) {\n  const empty = {\n    platform: 'not-observed',\n    usability: 'not-measured',\n    steps: [],\n  };\n\n  const validProfile = profile\n    &amp;&amp; ['narrow', 'wide'].includes(profile.viewport)\n    &amp;&amp; ['coarse', 'fine'].includes(profile.primaryPointer)\n    &amp;&amp; ['available', 'unavailable'].includes(profile.hover);\n\n  if (!validProfile || !action?.id || !action?.label) {\n    return { ...empty, accepted: false, reason: 'invalid-contract' };\n  }\n\n  const explicit = profile.viewport === 'narrow'\n    || profile.primaryPointer === 'coarse'\n    || profile.hover === 'unavailable';\n\n  const steps = ['summary', 'details', 'confirm'];\n\n  if (action.activation === 'hover-only' &amp;&amp; explicit) {\n    return {\n      ...empty,\n      accepted: false,\n      reason: 'hover-only-blocked',\n      steps,\n      rollback: 'keep-current-path',\n    };\n  }\n\n  return {\n    ...empty,\n    accepted: true,\n    reason: 'explicit-route',\n    steps,\n    rollback: 'replace-route-only',\n  };\n}\n\nconst route = planMobilePath(\n  { viewport: 'narrow', primaryPointer: 'coarse', hover: 'unavailable' },\n  { id: 'confirm-order', label: 'Подтвердить заказ', activation: 'explicit' },\n);\n\nconsole.log(route.accepted); // true\nconsole.log(route.steps); // summary, details, confirm\n\nconst rejected = planMobilePath(\n  { viewport: 'narrow', primaryPointer: 'coarse', hover: 'unavailable' },\n  { id: 'open-details', label: 'Открыть итог', activation: 'hover-only' },\n);\n\nconsole.log(rejected.reason); // hover-only-blocked</code></pre>\n<p>Положительная ветка подтверждает только три вещи: входной контракт корректен, шаги идут в заданном порядке, явное действие принято. Отрицательная ветка важнее для ревью. Она запрещает объявить маршрут принятым, если на выбранном профиле единственный переход зависит от hover. Значение <code>keep-current-path</code> не откатывает приложение само по себе. Оно говорит, что текущий путь пока нельзя заменять этим учебным маршрутом.</p>\n<figure><img src=\"/assets/editorial/2022/mobile-ux-2022-route.svg\" alt=\"Схема мобильного маршрута: summary ведёт к details, затем к явному confirm; hover-only на узком профиле блокируется и сохраняет текущий путь.\" loading=\"lazy\" /><figcaption>Иллюстрация показывает границу контракта. Это схема переходов, а не снимок браузера и не результат теста пользователей.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\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>Команда видна только при наведении</td><td>hover владеет переходом</td><td>найти DOM-элемент, focus state и visibility rules</td><td>добавить явный button или link</td></tr><tr><td>Кнопка находится в последней колонке</td><td>таблица требует ширины, которой нет</td><td>проверить overflow и порядок данных на узком контейнере</td><td>вынести основное действие из таблицы, детали оставить отдельно</td></tr><tr><td>После раскрытия нет понятного подтверждения</td><td>details и commit смешаны в одном control</td><td>проверить состояния до и после раскрытия</td><td>разделить просмотр и необратимое действие</td></tr><tr><td>Новый путь вызывает сомнение</td><td>замена сделана без безопасной границы</td><td>описать старый route и условия возврата</td><td>сохранить current path до отдельной проверки</td></tr><tr><td>«Мобильный» тест зелёный, UI не проверен</td><td>учебную модель приняли за browser test</td><td>посмотреть, какие данные реально создаёт тест</td><td>добавить отдельную проверку браузера с фиксированными условиями</td></tr></tbody></table></div>\n<p>Таблица нужна для смены уровня разговора. Запись «на телефоне неудобно» не объясняет, что наблюдалось. Запись «в состоянии A переход к details появляется только после hover» уже задаёт проверку. В реальном отчёте добавьте URL или экран, браузер, viewport, масштаб, локаль, способ ввода, начальное состояние и тестовые данные. Не заполняйте неизвестные поля догадками.</p>\n<h2>Порядок исправления</h2>\n<ol><li><strong>Зафиксируйте симптом.</strong> Назовите одно состояние, в котором основное действие не видно или достижимо только через hover. Отделите наблюдение от предположения о пользователях.</li><li><strong>Найдите владельца перехода.</strong> Проверьте DOM, состояние компонента, правила видимости, overflow и обработчики. Не меняйте breakpoint, пока не ясно, какой элемент должен вести дальше.</li><li><strong>Опишите контракт.</strong> Запишите summary, details и confirm. Для каждого шага укажите видимую метку, ожидаемый результат и способ отмены.</li><li><strong>Проверьте отрицательный путь.</strong> Передайте модели narrow/coarse/unavailable и действие с <code>hover-only</code>. Ожидайте отказ с причиной <code>hover-only-blocked</code>. Если тест принимает путь, контракт ослаблен.</li><li><strong>Добавьте явный control.</strong> Оставьте контекст перед подтверждением. Не прячьте ошибку, отмену или важные данные в другом hover-меню.</li><li><strong>Проверьте реализацию в браузере.</strong> Зафиксируйте viewport, zoom, шрифты, локаль, данные, клавиатуру и способ указателя. Проверьте render, focus, keyboard path, раскрытие details и состояние ошибки.</li><li><strong>Определите откат.</strong> До выпуска сохраните способ вернуть текущий путь: флаг, отдельная ветка, revert или ограниченный rollout. Учебная модель не меняет сервер и не выполняет откат за команду.</li></ol>\n<h2>Ограничения и критерий готовности</h2>\n<p>Контракт не выбирает breakpoint и не задаёт универсальный размер зоны нажатия. Он не описывает экранную клавиатуру, поворот экрана, длинные локализованные строки, screen reader, ошибку сети или конкурирующее обновление данных. Он также не доказывает, что человеку понятна метка «Продолжить». Эти вопросы относятся к реализации, доступности и исследованию.</p>\n<p>Нельзя объявлять production-эффектом число успешных assertion. В примере нет пользователей, реального устройства, телеметрии и замера времени. Нельзя называть строку <code>narrow</code> конкретным viewport в CSS pixels. Нельзя трактовать <code>hover: none</code> как запрет мыши. Нельзя использовать учебный отказ как автоматическое решение для серверной операции.</p>\n<p>Сценарий готов к следующей проверке, если выполнены четыре условия. Для основного действия существует видимый control с предметной меткой. До confirm доступен отдельный summary и путь к details. На заданном учебном профиле hover-only отклоняется, а на реализацию не распространяется обещание usability. В браузере другой инженер может повторить описанное состояние по зафиксированным входам и увидеть тот же порядок: summary → details → confirm.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.w3.org/TR/2021/CRD-mediaqueries-4-20211225/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C: Media Queries Level 4, Candidate Recommendation Draft</a> — описывает media features <code>pointer</code>, <code>hover</code>, <code>any-pointer</code> и <code>any-hover</code>; это свойства среды, а не измерение удобства.</li><li><a href=\"https://www.w3.org/TR/2019/REC-pointerevents2-20190404/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C: Pointer Events Level 2, Recommendation</a> — задаёт модель событий указателя и типы ввода, но не гарантирует достижимость конкретного действия.</li><li><a href=\"https://www.w3.org/TR/2018/REC-WCAG21-20180605/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C: Web Content Accessibility Guidelines 2.1, Recommendation</a> — содержит критерии для pointer gestures, ориентации и reflow; соответствие конкретного интерфейса требует отдельной оценки.</li></ul>"
+  "title": "Мобильное действие без скрытого шага: маршрут, который не зависит от hover",
+  "excerpt": "Если главное действие исчезает на узком экране, ищите не только breakpoint, а потерянный маршрут. Разбираем явный mobile-путь, fail-closed проверку и границу между учебной моделью и браузером.",
+  "contentHtml": "<p>На телефоне пользователь открывает экран заказа, видит сумму, но не находит переход к подтверждению. На десктопе переход появляется при наведении на строку таблицы. В другом варианте кнопка остаётся в последней колонке и уезжает за горизонтальную прокрутку. Симптом один: человек не может завершить действие, хотя данные уже введены.</p><p>Цена ошибки — не только плохое впечатление. Незавершённая форма создаёт обращение в поддержку и провоцирует повторный ввод. Если команда временно увеличивает кнопку, но теряет детали перед подтверждением, новый путь приносит другой риск. Релиз тоже трудно проверить: непонятно, какой элемент владел переходом и при каком состоянии он исчезал.</p><p>Мобильный сценарий нужно проверять как маршрут, а не как набор размеров. У основного действия должны быть видимый контекст, явный переход к деталям и отдельное подтверждение. Hover может ускорять обзор, но не должен оставаться единственным способом добраться до операции. Это правило не доказывает удобство интерфейса. Оно задаёт минимальный контракт, который можно проверить в коде, а затем подтвердить в браузере.</p><h2>Сначала восстановите маршрут</h2><p>Возьмём одно действие: проверить данные заказа и подтвердить его. Не переделываем весь экран. Сначала описываем три состояния. <code>summary</code> показывает предмет операции и краткий контекст. <code>details</code> открывает данные, которые нужно проверить до необратимого шага. <code>confirm</code> содержит явный элемент управления с понятной меткой.</p><p>Такое разбиение отделяет содержание от раскладки. В узком контейнере строки могут перейти в столбец, а детали — открываться во вкладке или disclosure. Но порядок решения сохраняется: человек сначала понимает, что изменится, потом смотрит данные и только затем подтверждает. Если компонент пропускает первый или второй шаг, изменение CSS не исправит потерю смысла.</p><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>summary</td><td>название операции и краткий контекст</td><td>состояние существует первым</td><td>что любой текст поместится в одну строку</td></tr><tr><td>details</td><td>явный переход к данным</td><td>переход не требует hover</td><td>что выбранный accordion удобен всем</td></tr><tr><td>confirm</td><td>видимая метка основного действия</td><td>элемент достижим явным вводом</td><td>размер зоны нажатия и качество текста</td></tr><tr><td>rollback</td><td>сохранённый рабочий путь</td><td>непринятый маршрут не вытесняет текущий</td><td>автоматический откат серверного состояния</td></tr></tbody></table></div><p>Слово «видимый» здесь означает часть проверяемого договора. Оно не означает, что элемент уже имеет правильный размер, цвет, фокус или положение. Эти свойства требуют отдельной проверки разметки и рендера. Контракт не заменяет проверку доступности и исследование удобства.</p><h2>Механизм: почему hover ломает действие</h2><p>Media Queries Level 4 определяет <code>hover</code> как способность наводить указатель на элементы с помощью основного pointing device. При нескольких устройствах значение выбирает user agent. Поэтому <code>hover: none</code> не означает «в системе никогда не будет hover» и не доказывает, что доступен только touch. Дополнительная мышь может изменить фактическое поведение псевдокласса <code>:hover</code>, хотя основной профиль останется без hover.</p><p>Это media feature не сообщает о клавиатуре или screen reader. <code>pointer: coarse</code> описывает ограниченную точность основного pointing device, но не навык человека и не запрет точного клика. Для всех доступных pointing devices существуют <code>any-pointer</code> и <code>any-hover</code>; они также не учитывают непоинтерные способы ввода. Эти значения помогают выбрать presentation, но не дают разрешения сделать обязательную операцию hover-only.</p><p>Сбой появляется, когда команда превращает характеристику среды в единственный маршрут. Иконка показывает tooltip только при наведении. Строка становится ссылкой только в <code>:hover</code>. Действие раскрывается движением указателя, но не имеет кнопки и не получает фокус. На телефоне такой путь может исчезнуть, а на клавиатуре — остаться недостижимым.</p><p>Безопаснее разделить основной элемент управления и подсказку. Основной control присутствует в DOM и имеет текстовую метку. Hover может показать дополнительные сведения или подсветить область. Если hover недоступен, сведения остаются достижимыми через явную кнопку или ссылку. На широкой странице desktop получает ускоренное обнаружение, но не теряет базовый маршрут.</p><h2>Учебный пример с отрицательной веткой</h2><p>Ниже — маленькая модель маршрута. Она принимает проектные значения: условную ширину контекста, характеристику основного указателя и capability hover. Эти строки задаёт тест, а не браузер. Модель не читает <code>matchMedia</code>, не создаёт DOM, не отправляет pointer events и не измеряет людей. Её граница — проверка формы входа, порядка шагов и отказа от hover-only в профиле, для которого нужен явный маршрут.</p><pre><code>function planMobilePath(profile, action) {\n  const empty = {\n    platform: 'not-observed',\n    usability: 'not-measured',\n    steps: [],\n  };\n\n  const validProfile = profile\n    &amp;&amp; ['narrow', 'wide'].includes(profile.viewport)\n    &amp;&amp; ['none', 'coarse', 'fine'].includes(profile.primaryPointer)\n    &amp;&amp; ['none', 'hover'].includes(profile.hover);\n\n  const validActivation =\n    action?.activation === 'explicit'\n    || action?.activation === 'hover-only';\n\n  if (!validProfile || !action?.id || !action?.label || !validActivation) {\n    return { ...empty, accepted: false, reason: 'invalid-contract' };\n  }\n\n  const requiresExplicit = profile.viewport === 'narrow'\n    || profile.primaryPointer !== 'fine'\n    || profile.hover === 'none';\n  const steps = ['summary', 'details', 'confirm'];\n\n  if (action.activation === 'hover-only' &amp;&amp; requiresExplicit) {\n    return {\n      ...empty,\n      accepted: false,\n      reason: 'hover-only-blocked',\n      steps,\n      rollback: 'keep-current-path',\n    };\n  }\n\n  return {\n    ...empty,\n    accepted: true,\n    reason: 'explicit-route',\n    steps,\n    rollback: 'replace-route-only',\n  };\n}\n\nconst mobile = {\n  viewport: 'narrow',\n  primaryPointer: 'coarse',\n  hover: 'none',\n};\n\nconst route = planMobilePath(mobile, {\n  id: 'confirm-order',\n  label: 'Подтвердить заказ',\n  activation: 'explicit',\n});\nconsole.log(route.accepted); // true\nconsole.log(route.steps); // summary, details, confirm\n\nconst rejected = planMobilePath(mobile, {\n  id: 'open-details',\n  label: 'Открыть итог',\n  activation: 'hover-only',\n});\nconsole.log(rejected.reason); // hover-only-blocked\n\nconst malformed = planMobilePath(mobile, {\n  id: 'confirm-order',\n  label: 'Подтвердить заказ',\n});\nconsole.log(malformed.reason); // invalid-contract</code></pre><p>Положительная ветка подтверждает только три вещи: профиль и действие соответствуют входному контракту, шаги идут в заданном порядке, явное действие принято. Отрицательная ветка важнее зелёной: для <code>narrow/coarse/none</code> она запрещает объявить hover-only маршрутом. Неизвестная активация также отклоняется, поэтому случайно добавленный тип не становится разрешённым по умолчанию.</p><p>В профиле <code>wide/fine/hover</code> модель не блокирует hover-only, потому что это учебная проверка именно мобильной развилки. Это не разрешение сделать обязательную операцию зависимой от hover в продукте: для неё всё равно нужен явный control и отдельная проверка клавиатурного пути. Значение <code>keep-current-path</code> не откатывает приложение. Оно запрещает заменять текущий маршрут этим учебным вариантом.</p><figure><img src='/assets/editorial/2022/mobile-ux-2022-route.svg' alt='Схема мобильного маршрута: summary ведёт к details, затем к явному confirm; hover-only на профиле narrow, coarse, none блокируется и сохраняет текущий путь.' loading='lazy' /><figcaption>Иллюстрация показывает границу контракта. Это схема переходов для учебного mobile-профиля, а не снимок браузера и не результат теста пользователей.</figcaption></figure><h2>Симптом → причина → проверка → действие</h2><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>Команда видна только при наведении</td><td>hover владеет переходом</td><td>найти DOM-элемент, focus state и visibility rules</td><td>добавить явный button или link</td></tr><tr><td>Кнопка находится в последней колонке</td><td>таблица требует ширины, которой нет</td><td>проверить overflow и порядок данных в узком контейнере</td><td>вынести основное действие из таблицы, детали оставить отдельно</td></tr><tr><td>После раскрытия нет понятного подтверждения</td><td>details и commit смешаны в одном control</td><td>проверить состояния до и после раскрытия</td><td>разделить просмотр и необратимое действие</td></tr><tr><td>Новый путь вызывает сомнение</td><td>замена сделана без безопасной границы</td><td>описать старый route и условия возврата</td><td>сохранить current path до отдельной проверки</td></tr><tr><td>«Мобильный» тест зелёный, UI не проверен</td><td>учебную модель приняли за browser test</td><td>посмотреть, какие данные реально создаёт тест</td><td>добавить отдельную проверку браузера с фиксированными условиями</td></tr></tbody></table></div><p>Таблица меняет уровень разговора. Запись «на телефоне неудобно» не объясняет, что наблюдалось. Запись «в состоянии A переход к details появляется только после hover» уже задаёт проверку. В реальном отчёте добавьте URL или экран, браузер, viewport, масштаб, локаль, способ ввода, начальное состояние и тестовые данные. Не заполняйте неизвестные поля догадками.</p><h2>Порядок исправления</h2><ol><li><strong>Зафиксируйте симптом.</strong> Назовите одно состояние, в котором основное действие не видно или достижимо только через hover. Отделите наблюдение от предположения о пользователях.</li><li><strong>Зафиксируйте условия.</strong> Укажите экран, данные, локаль, viewport, масштаб, способ ввода и состояние компонента. Не подставляйте значения, которых никто не наблюдал.</li><li><strong>Найдите владельца перехода.</strong> Проверьте DOM, состояние компонента, правила видимости, overflow и обработчики. Не меняйте breakpoint, пока не ясно, какой элемент должен вести дальше.</li><li><strong>Опишите контракт.</strong> Запишите summary, details и confirm. Для каждого шага укажите видимую метку, ожидаемый результат и способ отмены.</li><li><strong>Проверьте отрицательную ветку.</strong> Передайте модели <code>narrow/coarse/none</code> и действие с <code>hover-only</code>. Ожидайте отказ с причиной <code>hover-only-blocked</code>. Отдельно передайте действие без <code>activation</code> и ожидайте <code>invalid-contract</code>.</li><li><strong>Добавьте явный control.</strong> Оставьте контекст перед подтверждением. Не прячьте ошибку, отмену или важные данные в другом hover-меню.</li><li><strong>Проверьте реализацию в браузере.</strong> Зафиксируйте viewport, zoom, шрифты, локаль, данные, клавиатуру и способ указателя. Проверьте render, focus, keyboard path, раскрытие details и состояние ошибки.</li><li><strong>Определите откат.</strong> До выпуска сохраните способ вернуть текущий путь: флаг, отдельная ветка, revert или ограниченный rollout. Учебная модель не меняет сервер и не выполняет откат за команду.</li></ol><h2>Ограничения и критерий готовности</h2><p>Контракт не выбирает breakpoint и не задаёт универсальный размер зоны нажатия. Он не описывает экранную клавиатуру, поворот экрана, длинные локализованные строки, screen reader, ошибку сети или конкурирующее обновление данных. Он также не доказывает, что человеку понятна метка «Продолжить». Эти вопросы относятся к реализации, доступности и исследованию.</p><p>Нельзя объявлять production-эффектом число успешных assertion. В примере нет пользователей, реального устройства, телеметрии и замера времени. Нельзя называть строку <code>narrow</code> конкретным viewport в CSS pixels. Нельзя трактовать <code>hover: none</code> как запрет мыши. Нельзя использовать учебный отказ как автоматическое решение для серверной операции.</p><p>Сценарий готов к следующей проверке, если выполнены четыре условия. Для основного действия существует видимый control с предметной меткой. До confirm доступен отдельный summary и путь к details. На заданном учебном профиле hover-only отклоняется, а неизвестная активация не проходит fail-closed проверку. В браузере другой инженер может повторить описанное состояние по зафиксированным входам и увидеть тот же порядок: summary → details → confirm.</p><h2>Проверяемые источники</h2><ul><li><a href='https://www.w3.org/TR/2021/CRD-mediaqueries-4-20211225/' target='_blank' rel='noopener noreferrer'>W3C: Media Queries Level 4, Candidate Recommendation Draft</a> — датированная редакция от 25 декабря 2021 года. Она описывает media features <code>pointer</code>, <code>hover</code>, <code>any-pointer</code> и <code>any-hover</code>, включая границу между primary и всеми доступными pointing devices. Это draft, а не доказательство удобства конкретного интерфейса.</li><li><a href='https://www.w3.org/TR/2019/REC-pointerevents2-20190404/' target='_blank' rel='noopener noreferrer'>W3C: Pointer Events Level 2, Recommendation</a> — датированная Recommendation от 4 апреля 2019 года. Она задаёт модель событий указателя и типы ввода, но не гарантирует заметность или достижимость конкретного действия.</li><li><a href='https://www.w3.org/TR/2018/REC-WCAG21-20180605/' target='_blank' rel='noopener noreferrer'>W3C: Web Content Accessibility Guidelines 2.1, Recommendation</a> — Recommendation от 5 июня 2018 года с критериями для pointer gestures, reflow и content on hover or focus. Соответствие конкретной страницы требует отдельной оценки реализации.</li></ul>"
 }