diff --git a/editorial/agent-rewrites/182.json b/editorial/agent-rewrites/182.json
index 7db339a..4658c09 100644
--- a/editorial/agent-rewrites/182.json
+++ b/editorial/agent-rewrites/182.json
@@ -1,7 +1,7 @@
 {
   "index": 182,
   "slug": "editorial-2022-12-mechanism-user-research",
-  "title": "Как не принять догадку о пользователе за основание для интерфейса",
-  "excerpt": "Практический контракт для user research: отделяем наблюдение от его смысла, проверяем гипотезу и откладываем UI-решение, пока цепочка evidence не выдержит проверку.",
-  "contentHtml": "<p>Команда получает задачу: «сделать кнопку заметнее, потому что пользователи её не видят». Макет уже приложен, оценка разработки готова, а источник утверждения никто не может открыть. После релиза кнопка меняется, но команда не знает, исчезла ли трудность: люди могли не понимать термин, не иметь права на действие, потерять данные в форме или вообще не доходить до этого экрана. Цена ошибки — не только один спринт. В продукте закрепляется решение без критерия, а следующий спор снова начинается с мнений.</p>\n<p>Решение нельзя использовать как доказательство проблемы. Сначала разделите четыре уровня: наблюдение, источник, интерпретацию и гипотезу. Только после этого выбирайте следующий опыт или небольшое обратимое изменение. Граница показывает, что команда знает, а чего пока не знает.</p>\n<h2>Механизм: четыре уровня одной записи</h2>\n<p><strong>Наблюдение</strong> описывает то, что можно увидеть в конкретном контексте: человек оставил обязательное поле пустым, прервал действие после сообщения об ошибке, спросил о назначении элемента. Наблюдение не содержит мотива. Фраза «человек не понял поле» уже объясняет поведение и потому не является чистым наблюдением.</p>\n<p><strong>Источник</strong> позволяет другому человеку сверить наблюдение. Это может быть запись исследовательской сессии, заметка поддержки, согласованный лог или другой доступный артефакт. Само наличие источника не доказывает частотность, репрезентативность или причину. Оно отвечает только на вопрос: откуда взялась строка и в каких границах её можно читать.</p>\n<p><strong>Интерпретация</strong> связывает наблюдение с возможным объяснением. Она должна сохранять неопределённость: «пустое поле может быть связано с термином, порядком полей или отсутствием нужных данных». Хорошая интерпретация допускает альтернативы. Если она сразу называет мотив установленным, команда теряет часть проверки.</p>\n<p><strong>Гипотеза</strong> превращает интерпретацию в условие, которое можно подтвердить или опровергнуть. Например: «если люди не понимают назначение поля, то на прототипе без подсказки они будут задавать вопрос или выбирать неверный вариант». Гипотеза не равна задаче «добавить tooltip». Она задаёт, что нужно узнать и какое наблюдение изменит решение.</p>\n<table><caption>Границы между evidence и решением</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>Конкретное действие в контексте</td><td>Причину и частотность</td><td>Добавить источник</td></tr><tr><td>Источник</td><td>Где это зафиксировано</td><td>Что так ведут себя все</td><td>Проверить границы</td></tr><tr><td>Интерпретация</td><td>Осторожное объяснение</td><td>Установленный мотив</td><td>Сформулировать вопрос</td></tr><tr><td>Гипотеза</td><td>Условие и ожидаемый сигнал</td><td>Готовый UI и production-эффект</td><td>Выбрать опыт</td></tr><tr><td>Решение</td><td>Обратимое изменение</td><td>Подтверждённую пользу</td><td>Проверить outcome</td></tr></tbody></table>\n<h2>Пример: решение не перепрыгивает через гипотезу</h2>\n<p>Ниже — учебная модель переходов. Она не проводит интервью, не подключается к аналитике и не создаёт данные о реальных людях. Её задача — не дать функции записать план эксперимента до появления интерпретации и гипотезы. В production этот код нельзя считать системой хранения исследований.</p>\n<pre><code>function planExperiment(record, nextExperiment) { if (!record.interpretation || !record.hypothesis) return { kind: 'decision-rejected' }; return { kind: 'experiment-planned', decision: 'defer-solution', nextExperiment }; }</code></pre>\n<p>Если <code>source</code> пуст, запись наблюдения должна завершиться отказом, а не созданием карточки с неизвестным происхождением. Если вызвать <code>planExperiment</code> раньше гипотезы, результатом должен быть <code>decision-rejected</code>. После добавления интерпретации и гипотезы модель может вернуть <code>defer-solution</code> с описанием следующего опыта. Это всё ещё план. Он не означает, что опыт проведён.</p>\n<p>В записи должны различаться статусы «хотим узнать», «проверили», «получили сигнал» и «приняли решение». Смешивание статусов создаёт ложную уверенность. Локальная проверка контракта полезна только для порядка переходов. Она не оценивает качество исследования.</p>\n<figure><img src='/assets/editorial/2022/user-research-2022-evidence-contract.svg' alt='Контракт учебной evidence-модели: observation требует source, interpretation требует записи, hypothesis требует interpretation, experiment требует hypothesis, rollback возвращает предыдущее состояние' loading='lazy' /><figcaption>Схема показывает учебные переходы записи. Она не изображает реальных участников, исследовательскую сессию или product analytics.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\n<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>Наблюдение смешали с мотивом</td><td>Найти действие и источник</td><td>Переписать как наблюдение</td></tr><tr><td>«Добавим подсказку»</td><td>Решение появилось раньше вопроса</td><td>Назвать ожидаемое изменение поведения</td><td>Отложить UI и написать гипотезу</td></tr><tr><td>«Так просили»</td><td>Мнение приняли за evidence</td><td>Уточнить контекст высказывания</td><td>Назвать источник и ограничение</td></tr><tr><td>«Проверим макет»</td><td>Метод выбран раньше цели</td><td>Сформулировать вопрос</td><td>Выбрать метод под вопрос</td></tr><tr><td>«Тест прошёл»</td><td>План приняли за результат</td><td>Проверить участников и сигнал</td><td>Разделить план и outcome</td></tr><tr><td>«Данных мало»</td><td>Неопределённость скрыли</td><td>Проверить обратимость и цену ошибки</td><td>Уменьшить изменение или сделать rollback</td></tr></tbody></table>\n<h2>Порядок работы</h2>\n<ol><li>Возьмите утверждение из задачи и уберите готовое решение. Оставьте проблему, которую нужно подтвердить.</li><li>Запишите наблюдаемое действие без объяснения мотива. Укажите экран, сценарий, данные и момент сбоя.</li><li>Прикрепите источник, который другой человек может открыть или проверить. Запишите, чего источник не показывает.</li><li>Добавьте альтернативную интерпретацию. Не выбирайте одну только потому, что она ведёт к удобному компоненту.</li><li>Сформулируйте гипотезу как условие с ожидаемым наблюдением. Не используйте «точно» и «всегда» без подтверждения.</li><li>Выберите небольшой опыт, который отвечает на вопрос, а не просит оценить выбранный макет. Запишите, какой результат изменит решение.</li><li>Проверьте отрицательный путь: нет source, нет interpretation, нет гипотезы, источник недоступен или опыт проверяет только вкус.</li><li>Если связка не выдерживает проверку, верните статус <code>defer-solution</code>. Сохраните вопрос и источник, отмените необоснованный переход к интерфейсу.</li></ol>\n<h2>Rollback и границы</h2>\n<p>Rollback не стирает неудобное evidence. Он отменяет решение, которое не связано с наблюдением проверяемой гипотезы. Снимок состояния возвращает запись к моменту до синтетического изменения: можно снять ошибочный план или убрать UI-вариант. Исходный источник остаётся доступным, если правила хранения позволяют его сохранять.</p>\n<p>Контракт не спасает от слабого источника. Одно наблюдение может оказаться случайным. Гипотеза может проверять не ту группу людей. Локальный тест не оценивает recruitment, доступность интерфейса, размер выборки, смещение исследователя или юридические требования. Эти вопросы требуют отдельного процесса и владельца.</p>\n<p>Не превращайте поля записи в бюрократию для каждого изменения. Низкорисковый текстовый патч и дорогая перестройка сервиса имеют разную цену ошибки. Но чем дороже откат, тем опаснее фраза без источника. Если выпуск обязателен по операционной или правовой причине, назовите это ограничением. Не выдавайте вынужденный выпуск за подтверждённую пользовательскую пользу.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Переход к решению готов, если проверяющий без автора может ответить: что наблюдали; где это зафиксировано; какие объяснения рассматриваются; какая гипотеза будет опровергнута конкретным сигналом; что команда сделает при каждом исходе. Должно быть понятно и то, какой результат ещё не получен. Если в карточке есть только макет и слово «понятнее», готовности нет.</p>\n<p>Удалите из записи решение и проверьте, остаётся ли понятна исходная проблема. Затем уберите гипотезу и спросите, может ли команда назвать следующий опыт без выбора компонента. Если смысл исчезает после удаления одного поля, уровни склеены. Вернитесь к наблюдению, зафиксируйте неизвестное и не увеличивайте точность искусственно.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href='https://www.gov.uk/service-manual/user-research/plan-user-research-for-your-service' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: Plan user research for your service</a> — рекомендует начинать с исследовательских вопросов и превращать непроверенные предположения в вопросы.</li><li><a href='https://www.gov.uk/service-manual/user-research/how-user-research-improves-service-design' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: User research for government services</a> — описывает работу с потребностями, исходами и ограничениями пользователей, а не только с предпочтениями.</li><li><a href='https://www.gov.uk/service-manual/user-research/plan-round-of-user-research' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: Plan a round of user research</a> — связывает каждую активность с конкретными целями и вопросами.</li></ul>"
+  "title": "Как проверить пользовательскую проблему до изменения интерфейса",
+  "excerpt": "Разбираем цепочку от наблюдения до решения: как отделить факт от объяснения, выбрать проверку под вопрос и не принять готовый UI за доказательство проблемы.",
+  "contentHtml": "<p>Типичная задача звучит так: «сделать кнопку заметнее, потому что пользователи её не видят». Макет уже приложен, оценка разработки готова, а исходное утверждение никто не может открыть. После релиза кнопку меняют, но команда не знает, исчезла ли трудность: люди могли не понимать термин, не иметь права на действие, потерять данные в форме или вообще не доходить до экрана. Цена ошибки — не только один спринт. В продукте закрепляется решение без критерия, а следующий спор снова начинается с мнений.</p>\n<p>Начните не с компонента, а с проверяемого вопроса. Разделите наблюдение, источник, интерпретацию, гипотезу и решение. Такой порядок не доказывает, что интерфейс станет лучше, но не даёт выдать догадку за пользовательский факт. Следующий шаг должен уменьшать конкретную неизвестность и оставаться обратимым, пока доказательств мало.</p>\n<h2>Механизм: пять уровней одной записи</h2>\n<p><strong>Наблюдение</strong> описывает действие в контексте: человек оставил обязательное поле пустым, прервал действие после сообщения об ошибке или спросил о назначении элемента. Наблюдение не содержит мотива. Фраза «человек не понял поле» уже объясняет поведение и потому не является чистым наблюдением.</p>\n<p><strong>Источник</strong> позволяет другому члену команды сверить запись: это может быть заметка исследовательской сессии, обращение в поддержку, согласованный лог или другой доступный артефакт. Наличие источника не доказывает частотность, репрезентативность или причину. Оно отвечает только на вопросы «откуда взялась запись?» и «в каком контексте её можно читать?».</p>\n<p><strong>Интерпретация</strong> связывает наблюдение с возможным объяснением. Она должна сохранять неопределённость: «пустое поле может быть связано с термином, порядком полей или отсутствием нужных данных». Альтернативы важны: если сразу назвать мотив установленным, команда потеряет часть проверки.</p>\n<p><strong>Гипотеза</strong> превращает интерпретацию в условие с ожидаемым сигналом. Например: «если подпись поля мешает понять его назначение, то в варианте с новой подписью участники чаще правильно объяснят, что произойдёт после отправки». Это ещё не результат. Гипотеза не равна задаче «добавить подсказку».</p>\n<p><strong>Решение</strong> выбирает следующий опыт или изменение только после первых четырёх уровней. Оно должно содержать критерий отката: какой сигнал подтвердит гипотезу, какой её ослабит и что команда сделает в обоих случаях. Метод исследования выбирают под вопрос, а не под уже выбранный макет. Именно такой порядок рекомендует Service Manual GOV.UK: сначала согласовать вопросы и предположения, затем определить подход и исследовательские активности.</p>\n<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>Конкретное действие и контекст</td><td>Причину и частотность</td><td>Добавить источник</td></tr><tr><td>Источник</td><td>Где и кем зафиксировано</td><td>Что так ведут себя все</td><td>Проверить границы записи</td></tr><tr><td>Интерпретация</td><td>Возможное объяснение</td><td>Установленный мотив</td><td>Сформулировать вопрос</td></tr><tr><td>Гипотеза</td><td>Условие и ожидаемый сигнал</td><td>Готовый UI и эффект выпуска</td><td>Выбрать опыт</td></tr><tr><td>Решение</td><td>Обратимый следующий шаг</td><td>Подтверждённую пользу</td><td>Проверить исход</td></tr></tbody></table>\n<h2>Пример: контракт не пропускает раннее решение</h2>\n<p>Ниже — учебная модель записи на JavaScript. Она не проводит интервью, не подключается к аналитике и не создаёт данные о реальных людях. Её задача — сделать порядок переходов видимым: без наблюдения и источника запись отклоняется, без интерпретации и гипотезы план не появляется.</p>\n<pre><code>function planNextStep(record) {\n  if (!record.observation || !record.source) {\n    return { kind: 'rejected', reason: 'observation-needs-source' };\n  }\n\n  if (!record.interpretation || !record.hypothesis || !record.nextCheck) {\n    return { kind: 'rejected', reason: 'hypothesis-is-incomplete' };\n  }\n\n  return {\n    kind: 'planned',\n    decision: 'defer-solution',\n    nextCheck: record.nextCheck,\n  };\n}\n\nconst card = {\n  observation: 'Обязательное поле осталось пустым',\n  source: 'session-note-17',\n  interpretation: 'Причина пока не установлена',\n  hypothesis: 'Новая подпись изменит понимание назначения поля',\n  nextCheck: 'Сравнить объяснение поля в двух вариантах прототипа',\n};\n\nconsole.log(planNextStep(card).decision); // defer-solution\nconsole.log(planNextStep({ ...card, source: '' }).reason); // observation-needs-source\nconsole.log(planNextStep({ ...card, hypothesis: '' }).reason); // hypothesis-is-incomplete</code></pre>\n<p>Фикстура возвращает <code>defer-solution</code>, потому что команда пока планирует проверку, а не объявляет подсказку правильным ответом. Последние две строки показывают отрицательные пути. Пустой <code>source</code> не превращается в карточку с неизвестным происхождением. Пустая <code>hypothesis</code> не позволяет перепрыгнуть от наблюдения к UI.</p>\n<p>Для рабочей системы понадобятся схема хранения, права доступа, журнал изменений и правила удаления данных. В примере их нет намеренно: локальный контракт проверяет только порядок полей и не оценивает качество рекрутинга, формулировок или результатов исследования.</p>\n<figure><img src='/assets/editorial/2022/user-research-2022-evidence-contract.svg' alt='Учебная схема: observation требует source, interpretation уточняет возможные причины, hypothesis задаёт ожидаемый сигнал, experiment следует после hypothesis, rollback возвращает решение к исходному вопросу' loading='lazy' /><figcaption>Схема показывает порядок учебной записи. Она не изображает реальных участников, исследовательскую сессию или данные продукта.</figcaption></figure>\n<h2>Симптом → причина → проверка → действие</h2>\n<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>Наблюдение смешали с мотивом</td><td>Найти действие и источник</td><td>Переписать как наблюдение</td></tr><tr><td>«Добавим подсказку»</td><td>Решение появилось раньше вопроса</td><td>Назвать ожидаемое изменение поведения</td><td>Отложить UI и написать гипотезу</td></tr><tr><td>«Так просили»</td><td>Мнение приняли за доказательство</td><td>Уточнить контекст высказывания</td><td>Назвать источник и ограничение</td></tr><tr><td>«Проверим макет»</td><td>Метод выбран раньше цели</td><td>Сформулировать вопрос</td><td>Выбрать метод под вопрос</td></tr><tr><td>«Тест прошёл»</td><td>План приняли за результат</td><td>Проверить участников и сигнал</td><td>Разделить план и исход</td></tr><tr><td>«Данных мало»</td><td>Неопределённость скрыли</td><td>Проверить цену ошибки</td><td>Уменьшить изменение или подготовить откат</td></tr></tbody></table>\n<p>Эта карта отделяет проблему метода от проблемы интерфейса. Если команда говорит «пользователь путается», сначала найдите буквальное действие. Если есть только просьба «сделать проще», зафиксируйте, кто её высказал и в каком сценарии. Если вопрос требует понять причину, одного клика по прототипу может быть недостаточно; выберите исследовательскую активность, которая действительно даст нужный сигнал.</p>\n<h2>Порядок работы</h2>\n<ol><li>Возьмите утверждение из задачи и уберите готовое решение. Оставьте проблему, которую нужно подтвердить.</li><li>Запишите наблюдаемое действие без объяснения мотива: что произошло, на каком экране, в каком сценарии и в какой момент.</li><li>Прикрепите источник, который другой член команды может открыть и проверить. Укажите, чего источник не показывает.</li><li>Запишите минимум две возможные интерпретации. Не выбирайте первую только потому, что она ведёт к удобному компоненту.</li><li>Сформулируйте гипотезу как условие с ожидаемым наблюдением и способом её ослабить.</li><li>Выберите небольшой опыт под вопрос. В GOV.UK Service Manual отдельная исследовательская итерация должна иметь ясные цели, проблематику, предположения и решение, которое нужно принять после результата.</li><li>Проверьте отрицательный путь: нет источника, источник недоступен, нет гипотезы, выбранный метод проверяет только вкус или решение необратимо.</li><li>До результата оставьте изменение обратимым. После проверки сохраните наблюдение, сигнал, границы вывода и решение, которое действительно следует из записи.</li></ol>\n<h2>Откат и границы метода</h2>\n<p>Откат отменяет решение, а не удаляет неудобное доказательство. Если команда уже выбрала подсказку, но не может связать её с проверяемой проблемой, снимите UI-вариант и вернитесь к карточке. Не переписывайте наблюдение так, чтобы оно оправдывало компонент: иначе процесс создаёт красивую историю вместо знания.</p>\n<p>Контракт не спасает от слабого источника. Одно наблюдение может оказаться случайным. Гипотеза может проверять не ту группу людей. Локальная проверка не оценивает доступность интерфейса, размер выборки, смещение исследователя, согласие участников или правила хранения персональных данных. Эти вопросы требуют отдельного метода, владельца и проверки.</p>\n<p>Не превращайте поля записи в бюрократию для каждого текстового изменения. Небольшой обратимый патч и перестройка сервиса имеют разную цену ошибки. Но чем дороже откат, тем опаснее фраза без источника. Если выпуск обязателен по операционной или правовой причине, назовите это ограничением. Вынужденное изменение не становится результатом исследования.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Запись готова к обсуждению изменения, если проверяющий без автора может ответить: что наблюдали; где это зафиксировано; какие объяснения рассматриваются; какой сигнал ослабит гипотезу; какой следующий опыт даст этот сигнал; что команда сделает при каждом исходе. Должно быть понятно и то, какой результат ещё не получен.</p>\n<p>Сделайте контрольный проход по ближайшей задаче с готовым UI-ответом. Уберите решение из первой строки. Найдите наблюдение и источник. Если их нет, зафиксируйте, что проблема пока не подтверждена. Если они есть, добавьте альтернативу и обратимый следующий шаг. Готовность измеряется не уверенностью формулировки, а тем, можно ли повторить переход от наблюдения к действию.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href='https://www.gov.uk/service-manual/user-research/plan-user-research-for-your-service' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: Plan user research for your service</a> — предлагает сначала согласовать исследовательские вопросы, превратить необоснованные предположения и мнения в вопросы, а затем выбрать подход и активности.</li><li><a href='https://www.gov.uk/service-manual/user-research/plan-round-of-user-research' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: Plan a round of user research</a> — связывает каждую итерацию с целями, проблемами, предположениями и решением, которое нужно принять после исследования.</li><li><a href='https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs' target='_blank' rel='noopener noreferrer'>GOV.UK Service Manual: Learning about users and their needs</a> — отделяет пользовательскую потребность и проблему от возможного решения и требует проверять предположения исследованием.</li></ul>"
 }