diff --git a/editorial/agent-rewrites/077.json b/editorial/agent-rewrites/077.json
index d64b87a..f98f217 100644
--- a/editorial/agent-rewrites/077.json
+++ b/editorial/agent-rewrites/077.json
@@ -2,6 +2,6 @@
   "index": 77,
   "slug": "editorial-2025-11-mechanism-research-method",
   "title": "Как проверить источник до того, как он повлияет на решение",
-  "excerpt": "ETag, дата публикации и цифровая подпись подтверждают разные свойства документа. Разбираем границы этих сигналов и собираем проверку, которая останавливает слишком сильный вывод.",
-  "contentHtml": "<p>Команда находит страницу с нужным API, видит свежую дату и сразу переносит совет в интеграцию. Через месяц endpoint ведёт себя иначе. Оказывается, страница описывала другой режим, а заголовок <code>ETag</code> приняли за номер релиза. Ошибка стоит дороже, чем время на чтение: меняется код, растёт число обходов, а причину трудно восстановить после инцидента.</p>\n<p>Тезис статьи прост: источник не равен доказательству решения. Проверка должна разделять публикацию, конкретное представление документа, наблюдаемый факт и действие, которое из него следует. Каждый переход требует своей опоры. Если опоры нет, проверка должна остановиться и показать, чего не хватает.</p>\n<h2>Четыре уровня, которые нельзя смешивать</h2>\n<p>Публикация — RFC, стандарт, релиз или датированная рекомендация. Она задаёт документ и его область. Представление — именно тот HTML, PDF или HTTP-ответ, который прочитал инженер. Оно может зависеть от языка, заголовков запроса, авторизации и времени.</p>\n<p>Наблюдение — короткая фраза, которую можно проверить в представлении: «в разделе указано условие X» или «ответ содержит заголовок ETag». Утверждение — уже интерпретация наблюдения. Решение — изменение кода, конфигурации или процесса. Страница может подтвердить наблюдение, но не обязана подтверждать решение для любого продукта.</p>\n<figure><img src=\"/assets/editorial/2025/research-method-2025-claim-status-matrix.svg\" alt=\"Матрица проверки утверждения: от версии публикации и конкретного представления к наблюдению и решению\" loading=\"lazy\" /><figcaption>Проверка движется от адресуемого представления к наблюдению, затем к ограниченному утверждению и только после этого к решению.</figcaption></figure>\n<p>Удобно хранить эти уровни раздельно. Для публикации нужен идентификатор и дата. Для представления — URL, версия, commit или снимок. Для наблюдения — точный раздел, строка или заголовок ответа. Для решения — условия применимости, риск и способ проверки.</p>\n<h2>Почему ETag не заменяет версию</h2>\n<p>В HTTP заголовок <code>ETag</code> служит validator выбранного представления ресурса. Клиент сравнивает значение при условных запросах. Сервер может вычислить его по содержимому, назначить внутренний идентификатор или учитывать согласование формата. Само значение не обязано раскрывать эту схему.</p>\n<p>Из <code>ETag: \"a81c\"</code> нельзя вывести, что документ относится к релизу 8.1, что он был опубликован в конкретную дату или что смысл каждого абзаца сохранится для другого endpoint. <code>Last-Modified</code> также говорит о времени изменения представления, а не о полном жизненном цикле продукта.</p>\n<p>Для исторической проверки нужен более сильный якорь: датированный RFC, тег релиза, commit, опубликованный PDF или сохранённый снимок. Validator полезно записать дополнительно. Он помогает повторить протокольную проверку, но не превращается в семантическую версию.</p>\n<h2>Что подтверждает цифровая подпись</h2>\n<p>Подпись помогает проверить целостность защищённого объекта и связь с подписантом. Она не превращает каждое утверждение внутри объекта в доказанный факт. Документ может быть подлинным и одновременно описывать ограниченный сценарий, старую конфигурацию или другой объект.</p>\n<p>Поэтому у записи проверки нужны две разные строки: <code>integrity</code> и <code>claimEvidence</code>. Первая отвечает на вопрос «документ не изменили после подписи?». Вторая — «есть ли в нём наблюдение, которое поддерживает именно нашу фразу?». Подмена одной строки другой создаёт ложную уверенность.</p>\n<h2>Учебный пример: остановить слишком сильный вывод</h2>\n<pre><code>const record = {\n  source: {\n    url: 'https://example.test/api-guide',\n    etag: '\"a81c\"',\n    signature: 'valid'\n  },\n  observation: 'Документ описывает режим read-only для версии 2.',\n  claim: 'API безопасен для записи в любой версии.'\n};\n\nconst canRecommend =\n  Boolean(record.source.url) &&\n  Boolean(record.source.etag) &&\n  record.source.signature === 'valid' &&\n  record.claim.includes('версии 2') &&\n  record.observation.includes('версии 2');\n\nconsole.log(canRecommend); // false</code></pre>\n<p>Это учебный пример, а не проверка реальной подписи и не production-код. У записи есть адрес, validator и валидная подпись. Но наблюдение ограничивает вывод версией 2 и режимом read-only, а утверждение расширяет его до записи и любой версии. Проверка возвращает отказ. Правильное действие — сузить утверждение или найти отдельное наблюдение для записи и нужной версии.</p>\n<p>Отрицательный путь важен не меньше успешного. Если система продолжает работу со статусом «достаточно» после отсутствия версии, locator или области применимости, она маскирует неизвестное. Средний балл доверия не исправит отсутствие конкретного факта.</p>\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>ETag выглядит как номер версии</td><td>Протокольный validator смешали с релизом</td><td>Открыть правила версий издателя и сравнить с RFC</td><td>Сохранить ETag отдельно, найти release pin</td></tr><tr><td>Ссылка открывается, но текст уже другой</td><td>Зафиксирован только текущий URL</td><td>Проверить дату, commit, PDF или архивный снимок</td><td>Сузить исторический вывод или сменить источник</td></tr><tr><td>Подписанный документ подтверждает всё сразу</td><td>Целостность приняли за истинность тезиса</td><td>Разделить signature и claim evidence</td><td>Оставить только вывод об авторстве либо добавить факт</td></tr><tr><td>Документ верен, но совет не работает</td><td>Scope документа не совпал с продуктом</td><td>Сопоставить endpoint, версию, права и режим</td><td>Добавить условие применимости и отдельный тест</td></tr><tr><td>В отчёте нет причины остановки</td><td>Отказ заменили общим статусом доверия</td><td>Проверить обязательные поля и отрицательные ветки</td><td>Вернуть статус hold с конкретным недостающим полем</td></tr></tbody></table></div>\n<h2>Порядок проверки</h2>\n<ol><li>Сформулируйте решение одним предложением. Укажите действие, объект, версию и режим.</li><li>Назовите уровень каждого утверждения: публикация, представление, наблюдение или решение.</li><li>Закрепите представление. Используйте release, commit, датированный документ или снимок. Текущий URL оставьте только как навигацию.</li><li>Запишите точный locator: раздел, строку, заголовок ответа или другой повторяемый фрагмент.</li><li>Сверьте scope. Проверьте endpoint, версию, метод, права, язык, формат и условия, при которых сделано наблюдение.</li><li>Сравните силу формулировки с фактом. Уберите слова «всегда», «безопасно», «поддерживает» и «для всех», если источник их не подтверждает.</li><li>Проверьте отрицательный путь: уберите версию, измените режим или подставьте другой объект. Система должна остановиться, а не выдать прежний совет.</li><li>Только после этого выберите действие и добавьте проверяемый критерий результата.</li></ol>\n<h2>Ограничения метода</h2>\n<p>Эта модель не делает веб неизменяемым. Она не устанавливает истинность заявления одной ссылкой и не заменяет предметного эксперта. Официальный стандарт может не описывать operational-ограничение конкретного сервиса. Подпись может быть корректной, но относиться не к тому представлению. Архивный снимок фиксирует текст, но не доказывает, что система в тот день работала по нему.</p>\n<p>Метод также не требует сохранять весь интернет. Для дорогих решений достаточно закрепить минимальный набор: первичный документ, конкретное представление, наблюдение, область применимости и способ проверки. Если какой-то элемент нельзя получить, вывод должен стать уже. Отказ — нормальный результат, когда данных недостаточно.</p>\n<h2>Критерий готовности</h2>\n<p>Проверка готова, когда другой инженер может открыть тот же документ или его закреплённое представление, найти указанный locator, увидеть наблюдение и понять, почему оно поддерживает решение именно в заданном scope. Если он меняет версию, режим или объект, отрицательный путь возвращает остановку с понятной причиной. Ни один из этих результатов не требует доверять интонации автора.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110: HTTP Semantics</a> — раздел 8.8 описывает <code>ETag</code> и <code>Last-Modified</code> как validator fields для выбранного представления. Документ не назначает ETag номером релиза.</li><li><a href=\"https://www.w3.org/TR/vc-data-model-2.0/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C Verifiable Credentials Data Model v2.0</a> — раздел о verification отделяет проверку credential от оценки истинности закодированных claims. Рекомендация не заменяет независимое доказательство конкретной интеграции.</li><li><a href=\"https://www.w3.org/TR/prov-dm/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C PROV-DM: The PROV Data Model</a> — различает entity и activity, что помогает отдельно хранить документ и действие его проверки. Модель не задаёт автоматическую шкалу доверия.</li></ul>"
+  "excerpt": "Дата, версия, HTTP-валидатор и цифровая подпись отвечают на разные вопросы. Разбираем, как связать источник с наблюдаемым фактом, не расширить его смысл и остановить неподтверждённое решение.",
+  "contentHtml": "<p>Команда находит страницу с нужным API и сразу переносит совет в интеграцию. В адресе есть знакомый номер, в ответе — <code>ETag</code>, внизу — свежая дата. Через месяц обновлённый endpoint ведёт себя иначе: номер был частью адреса документа, а <code>ETag</code> оказался валидатором представления, а не номером релиза. Ошибка уже превратилась в код, обходы и спор о том, какую страницу читали.</p>\n<p>Источник полезен только тогда, когда понятно, что именно он подтверждает. Для инженерного решения нужно разделить публикацию, конкретное представление, наблюдение, утверждение и действие. У каждого уровня своя граница. Если версия, локатор или область применимости неизвестны, правильный результат проверки — остановка и точное описание недостающего факта.</p>\n<h2>Источник не равен доказательству</h2>\n<p>Начинайте с формулировки решения, которое может измениться. «Документация про кеш» слишком широко. «Для GET-запроса к ресурсу X можно повторить условный запрос, если сервер прислал тот же валидатор» уже указывает объект, метод и условие. Теперь ясно, какой факт искать и какой результат нельзя обещать без отдельного теста.</p>\n<p>Полезно различать пять уровней:</p>\n<ul><li><strong>Публикация</strong> — RFC, спецификация, релиз или страница владельца продукта.</li><li><strong>Представление</strong> — конкретный HTML, PDF, commit или HTTP-ответ, который был прочитан.</li><li><strong>Наблюдение</strong> — короткий фрагмент, видимый в этом представлении: раздел, строка, поле или заголовок.</li><li><strong>Утверждение</strong> — вывод о нашем объекте, версии и режиме работы.</li><li><strong>Решение</strong> — изменение кода, конфигурации, теста или процесса.</li></ul>\n<p>RFC может подтвердить смысл поля протокола, но не совместимость нашего SDK. Commit может подтвердить содержимое файла, но не успешность запуска в другой среде. Отчёт теста может подтвердить один сценарий, но не «работает всегда». Скачок от наблюдения к решению и есть место, где чаще всего появляется лишняя уверенность.</p>\n<figure><img src=\"/assets/editorial/2025/research-method-2025-claim-status-matrix.svg\" alt=\"Матрица проверки источника: наличие версии и наблюдаемого артефакта переводит утверждение в ограниченный статус, а слишком широкий вывод останавливается\" loading=\"lazy\" /><figcaption>Сначала закрепляем представление и читаемый артефакт, затем ограничиваем утверждение областью применения. Статус выбирает следующее действие, а не оценивает авторитет сайта.</figcaption></figure>\n<h2>Что на самом деле показывают дата и ETag</h2>\n<p>HTTP передаёт не сам ресурс, а его представление — данные и метаданные, выбранные для конкретного запроса. Поэтому один URL может давать разные представления из-за языка, формата, кодировки или других условий согласования. В RFC 9110 поле <code>ETag</code> определено как непрозрачный валидатор выбранного представления. Сервер сам выбирает способ его формирования; клиенту нужно сравнивать значение по правилам HTTP, а не расшифровывать его.</p>\n<p>Из <code>ETag: \"8.1\"</code> нельзя заключить, что перед нами релиз 8.1, документ опубликован в августе или другой endpoint поддерживает тот же контракт. Это может быть хеш, внутренний идентификатор или другое значение, различающее представления. Слабый валидатор с префиксом <code>W/</code> дополнительно имеет иные правила сравнения.</p>\n<p><code>Last-Modified</code> сообщает дату последнего изменения представления в смысле HTTP-валидатора. Она не обязана совпадать с датой выпуска продукта, датой утверждения API или временем, когда команда впервые прочитала документ. Заголовок <code>Vary</code> может указать, какие поля запроса участвуют в выборе представления. Ни один из этих заголовков не заменяет pin релиза, commit или датированный документ.</p>\n<p>Практическая запись должна хранить их раздельно:</p>\n<pre><code>sourceUrl: https://api.example.test/docs\nsourcePin: vendor-api-2.4.1\nlocator: \"GET /reports, section Conditional requests\"\nobservedAt: 2025-11-15T10:00:00Z\netag: \"8.1\"\nlastModified: Sat, 15 Nov 2025 10:00:00 GMT</code></pre>\n<p>Значения в примере учебные. <code>sourcePin</code> отвечает на вопрос «какую версию документа закрепили», а <code>etag</code> — «какой валидатор сообщил сервер для выбранного представления». Сохранять оба полезно, но подменять одно другим нельзя.</p>\n<h2>Целостность документа и смысл утверждения</h2>\n<p>Цифровая подпись решает криптографическую задачу: при корректной проверке она даёт сведения о происхождении и целостности подписанных данных, а также поддерживает неотказуемость подписанта в заданной инфраструктуре. Это не означает, что каждый тезис документа подходит нашему продукту или что авторский прогноз стал измеренным результатом.</p>\n<p>Например, подписанный файл может описывать старую версию, другой метод или условие, которого нет в нашей системе. Подпись защищает связь с конкретными данными; область применимости и смысл нужно проверять отдельно. У записи исследования поэтому должны быть как минимум две независимые строки: <code>integrity</code> и <code>claimEvidence</code>.</p>\n<p>Эту же границу помогает увидеть модель происхождения W3C PROV. В ней документ — сущность, чтение или преобразование — действие, а человек, сервис или программа — участник, связанный с ответственностью. Время, версия и связь между редакциями делают историю проверяемой. PROV описывает происхождение, но не выдаёт автоматический рейтинг качества и не доказывает деловую пригодность решения.</p>\n<h2>Воспроизводимый пример с отрицательной веткой</h2>\n<p>Ниже — самостоятельный скрипт без сети, базы данных и настоящей криптографии. Он проверяет только структуру записи и не притворяется проверкой внешнего мира. Сохраните фрагмент в файл <code>claim-check.mjs</code>, затем выполните команды:</p>\n<pre><code>node --version\nnode claim-check.mjs</code></pre>\n<pre><code>const record = {\n  sourceUrl: 'https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.3',\n  sourcePin: 'RFC 9110',\n  locator: 'section 8.8.3',\n  scope: 'HTTP response; selected representation',\n  observation: 'ETag is an opaque validator for differentiating representations',\n  claim: 'ETag is the software release number'\n};\n\nfunction assess(item) {\n  const required = ['sourceUrl', 'sourcePin', 'locator', 'scope', 'observation', 'claim'];\n  const missing = required.filter((field) =&gt; !item[field]);\n\n  if (missing.length &gt; 0) {\n    return { status: 'hold', reason: 'missing-field', missing };\n  }\n\n  if (item.claim === 'ETag is the software release number') {\n    return { status: 'hold', reason: 'observation-does-not-support-claim' };\n  }\n\n  return { status: 'ready-for-scoped-use', reason: 'record-is-addressable' };\n}\n\nconsole.log(assess(record));\n// { status: 'hold', reason: 'observation-does-not-support-claim' }</code></pre>\n<p>На обычном Node.js скрипт напечатает отказ: запись адресуемая, но наблюдение говорит о валидаторе представления, а утверждение называет его номером релиза. Если заменить <code>claim</code> на «ETag различает представления в данном HTTP-контексте», локальная проверка пройдёт. Это всё ещё не доказывает поведение конкретного сервера: для него нужен отдельный запрос с зафиксированными входами.</p>\n<p>Отрицательная ветка важнее красивого статуса <code>ready</code>. Удалите <code>sourcePin</code>, измените метод или расширьте утверждение с одного ресурса на весь API — запись должна перейти в <code>hold</code> либо потребовать нового наблюдения. Список обязательных полей защищает журнал от пустой ссылки, но не превращает заполненную карточку в эксперимент.</p>\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>Номер RFC, релиз или commit</td><td>К какому закреплённому материалу относится цитата</td><td>Что система внедрила этот контракт</td><td>Сверить локатор и версию клиента/сервера</td></tr><tr><td><code>ETag</code></td><td>Валидатор выбранного HTTP-представления</td><td>Номер релиза и бизнес-смысл ресурса</td><td>Проверить условный запрос и правила сравнения</td></tr><tr><td><code>Last-Modified</code></td><td>Дату изменения представления по правилам HTTP</td><td>Дату выпуска продукта или дату утверждения API</td><td>Найти официальный release note или тег</td></tr><tr><td>Цифровая подпись</td><td>Целостность и происхождение подписанных данных при корректной проверке</td><td>Истинность каждого тезиса и совместимость с нашим кодом</td><td>Проверить scope, ключ, политику и независимый факт</td></tr><tr><td>Текущий URL</td><td>Куда можно перейти сейчас</td><td>Как выглядел документ в момент решения</td><td>Закрепить версию, commit, PDF или архивный снимок</td></tr><tr><td>Результат теста</td><td>Поведение в указанных входах и среде</td><td>Поведение во всех версиях, ролях и нагрузках</td><td>Повторить сценарий и перечислить ограничения</td></tr></tbody></table></div>\n<h2>Порядок проверки перед решением</h2>\n<ol><li><strong>Назовите действие.</strong> Запишите, что именно хотите изменить: метод, endpoint, зависимость, конфигурацию или текст инструкции.</li><li><strong>Ограничьте объект.</strong> Укажите версию, среду, права, метод HTTP, формат данных и другие признаки, от которых зависит результат.</li><li><strong>Выберите первичный источник.</strong> Для протокола используйте нормативный документ, для библиотеки — официальный релиз и документацию владельца, для кода — конкретный commit.</li><li><strong>Закрепите представление.</strong> Сохраните pin, дату чтения и, если это HTTP-ответ, безопасные для публикации заголовки. Текущий URL оставьте как навигацию.</li><li><strong>Запишите локатор.</strong> Это раздел RFC, страница PDF, путь к файлу, endpoint или точное поле. Ссылка на главную страницу недостаточна.</li><li><strong>Перепишите наблюдение без вывода.</strong> Оставьте то, что можно увидеть или повторить. Не заменяйте «сервер прислал ETag» фразой «версия совместима».</li><li><strong>Сопоставьте силу утверждения.</strong> Сверьте субъект, метод, версию и условие. Слова «всегда», «безопасно» и «для любого клиента» требуют отдельного доказательства.</li><li><strong>Проверьте отрицательный путь.</strong> Уберите pin, измените scope или подставьте другой режим. Проверка должна остановиться с понятной причиной, а не сохранить прежний совет.</li><li><strong>Выберите следующее действие.</strong> Это может быть scoped use, новый запрос, тест, запрос к владельцу документа или отказ от решения. Запишите критерий, по которому вернётесь к карточке.</li></ol>\n<h2>Когда нужно остановиться</h2>\n<p>Остановитесь, если документ нельзя однозначно закрепить, локатор ведёт в другой раздел, текущая страница изменилась, а исторического представления нет, или подпись относится не к тому файлу. Точно так же остановитесь, если в тексте есть только рекламное обещание, а решение требует измерения производительности, безопасности или совместимости.</p>\n<p>Не заменяйте остановку усреднённым баллом доверия. Две ссылки на разные версии не становятся сильнее от сложения. Подписанный документ другой области не подтверждает наш endpoint. Пустое поле «дата» не компенсируется свежим впечатлением от страницы. Полезный результат в таких случаях — список: какого факта не хватает, где его получить и какой вывод пока запрещён.</p>\n<h2>Ограничения применимости</h2>\n<p>Метод не делает интернет неизменяемым и не превращает ссылку в лабораторный результат. Он не измеряет задержку, не проверяет нагрузку, не выполняет цифровую подпись и не устанавливает, что конкретный сервис соблюдает документ. Для этого нужны реальные входы, разрешённая среда, измерительный инструмент и отдельный критерий успеха.</p>\n<p>RFC описывает семантику HTTP, но не знает, как владелец API строит ETag. NIST описывает свойства цифровой подписи, но не проверяет доверенную цепочку ключей в вашем проекте. W3C PROV задаёт vocabulary для происхождения, но не требует конкретного формата журнала и не решает конфликт двух корректных источников. Эти границы нужно переносить в карточку решения, а не прятать в примечании.</p>\n<p>Учебный скрипт намеренно не обращается к сети. Его зелёный результат означает лишь, что локальная запись заполнена и не содержит известного слишком сильного вывода. Перед изменением production-кода дополнительно проверьте конкретную версию, права, данные, обратимость и влияние на пользователей.</p>\n<h2>Критерий готовности</h2>\n<p>Запись готова к использованию, когда другой инженер может без устного пояснения открыть закреплённый источник, перейти к локатору, увидеть наблюдение, назвать область применения и воспроизвести следующий шаг. При изменении версии, метода или объекта проверка должна показать, почему старый вывод больше не действует.</p>\n<p>Минимальная форма результата выглядит так: «В RFC 9110, разделе 8.8.3, <code>ETag</code> назван непрозрачным валидатором выбранного представления. Для GET ресурса X в версии Y проверяем условный запрос. Это не доказывает номер релиза, совместимость записи или поведение другого endpoint». Такая формулировка уже не обещает лишнего и оставляет команде проверяемое действие.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html#section-3.2\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110, раздел 3.2: Representations</a> — объясняет, что HTTP передаёт представления состояния ресурса, выбранные в контексте запроса.</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110, раздел 8.8: Validator Fields</a> — описывает валидаторы, включая дату изменения и entity tag; <a href=\"https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.3\" target=\"_blank\" rel=\"noopener noreferrer\">раздел 8.8.3</a> определяет <code>ETag</code> как непрозрачный валидатор.</li><li><a href=\"https://csrc.nist.gov/glossary/term/digital_signature\" target=\"_blank\" rel=\"noopener noreferrer\">NIST CSRC: Digital signature</a> — фиксирует свойства цифровой подписи: аутентификацию происхождения, целостность данных и поддержку неотказуемости при корректной реализации.</li><li><a href=\"https://www.w3.org/TR/prov-primer/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C PROV Model Primer</a> — вводит сущности, действия, участников, происхождение, редакции и время как элементы описания истории данных.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/078.json b/editorial/agent-rewrites/078.json
index f3ec28b..c8bc82c 100644
--- a/editorial/agent-rewrites/078.json
+++ b/editorial/agent-rewrites/078.json
@@ -3,5 +3,5 @@
   "slug": "editorial-2025-11-practice-research-method",
   "title": "Как превратить ссылку в проверяемое техническое утверждение",
   "excerpt": "Ссылка сама по себе не доказывает решение. Разбираем журнал утверждений: как зафиксировать версию источника, область применимости, наблюдение, отрицательный путь и следующий проверяемый шаг.",
-  "contentHtml": "<p>Ошибка в исследовании источников обычно обнаруживается поздно. В тексте стоит ссылка на документацию, но читатель не знает, какую версию открывал автор, где находится нужный факт и при каком условии он перестаёт работать. В коде такой совет превращается в неверный запрос, несовместимую настройку или лишнюю переделку. Цена ошибки — часы на повторную проверку и решение, которое нельзя уверенно объяснить после обновления документа.</p>\n<p>Ссылка — это адрес. Утверждение — это ограниченная фраза, которую можно проверить. Между ними нужен короткий журнал: statement, scope, source pin, locator, observation и status. Такая запись не делает источник истинным. Она показывает, какой факт прочитан, где он находится и какое действие он разрешает.</p>\n<h2>Что именно нужно зафиксировать</h2>\n<p>Начинайте с одного предложения. «ETag ускоряет кеширование» слишком широко: здесь не названы протокол, представление, условие запроса и ожидаемый результат. «Для выбранного HTTP-представления сильное сравнение ETag позволяет проверить условие If-None-Match» уже имеет границу. Его можно сопоставить с разделом спецификации и с наблюдаемым запросом.</p>\n<p>У утверждения есть шесть полей. <code>statement</code> хранит фразу. <code>scope</code> описывает, где она действует. <code>sourcePin</code> фиксирует версию первичного материала: RFC, tagged release или датированный PDF. <code>locator</code> указывает раздел, таблицу или endpoint. <code>observation</code> записывает минимальный факт без расширения смысла. <code>status</code> управляет следующим шагом: можно передавать запись дальше или нужно остановиться.</p>\n<figure><img src=\"/assets/editorial/2025/research-method-2025-evidence-ladder.svg\" alt=\"Лестница проверки: источник, версия, локатор, наблюдение, ограниченное утверждение и действие\"><figcaption>Доказательство усиливается не числом ссылок, а связью между версией, локатором и наблюдаемым фактом.</figcaption></figure>\n<h2>Механизм: отделить источник от наблюдения</h2>\n<p>URL без версии ведёт на текущую страницу. Он не доказывает, что документ выглядел так же в момент чтения. Поэтому журнал хранит pin отдельно. Датированный RFC или commit отвечает на вопрос «какой материал открыт». Locator отвечает на вопрос «где искать». Observation отвечает на вопрос «что там написано или возвращено».</p>\n<p>Это разделение не формальность. Заголовок <code>ETag</code> — непрозрачный валидатор выбранного представления. Он помогает отличать представления ресурса, но сам по себе не описывает бизнес-смысл данных и не обещает совместимость конкретного SDK. Из факта о протоколе нельзя автоматически вывести факт о продукте.</p>\n<p>Полезно также различать целостность и смысл. Подписанный документ подтверждает происхождение или неизменность представления, если проверка подписи прошла. Это не доказывает, что интерпретация автора подходит другому endpoint, региону, праву доступа или версии клиента. Если источник сообщает только «подпись действительна», журнал должен остановить более сильное утверждение.</p>\n<h2>Минимальный пример</h2>\n<p>Ниже учебный пример. Он не обращается к сети и не имитирует результат production-сервиса. Функция проверяет только полноту локальной записи: pin, область, locator и наблюдение. Такой код полезен для демонстрации границы метода, а не для оценки качества реального источника.</p>\n<pre><code>const claim = {\n  statement: 'If-None-Match compares the selected representation',\n  scope: 'HTTP conditional GET',\n  sourcePin: 'RFC-9110',\n  locator: 'section 8.8.3',\n  observation: 'ETag is an opaque validator for a selected representation',\n};\n\nfunction assess(record) {\n  const required = ['statement', 'scope', 'sourcePin', 'locator', 'observation'];\n  const missing = required.filter((field) =&gt; !record[field]);\n\n  if (missing.length) {\n    return { status: 'hold', nextAction: 'repair-record', missing };\n  }\n\n  return { status: 'ready-for-scoped-handoff', nextAction: 'use-with-scope' };\n}\n\nconsole.log(assess(claim));\n// { status: 'ready-for-scoped-handoff', nextAction: 'use-with-scope' }</code></pre>\n<p>Статус <code>ready-for-scoped-handoff</code> означает только одно: запись адресуемая и содержит наблюдение. Он не означает, что измерена производительность, проверена совместимость или доказан эффект для продукта. Чтобы не потерять эту границу, следующий шаг хранится рядом со статусом.</p>\n<p>Отрицательная ветка обязательна. Если удалить <code>sourcePin</code>, функция вернёт <code>hold</code>. Добавление ещё одной цитаты вокруг текущей страницы не исправит отсутствие версии. Нужно найти неизменяемый первичный материал, открыть locator заново и записать новый observation. Если источник содержит маркетинговое обещание, его можно сохранить как наблюдение текста, но нельзя выдавать за измеренный результат.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Ссылка открывается, но факт не находится</td><td>Нет locator или он относится к другой версии</td><td>Открыть pinned material и найти раздел заново</td><td>Добавить точный locator; при несовпадении остановить вывод</td></tr><tr><td>Совет звучит уверенно, но не имеет условия</td><td>Тема заменяет проверяемое утверждение</td><td>Назвать объект, вход, результат и границу</td><td>Сузить statement до одной проверяемой фразы</td></tr><tr><td>Подписанный файл принимают за доказательство поведения</td><td>Целостность смешали с семантической истинностью</td><td>Сверить observation с заявленным выводом</td><td>Оставить только вывод об авторстве или найти независимый факт</td></tr><tr><td>Две ссылки дают «среднюю уверенность»</td><td>Сравнивают разные классы источников</td><td>Проверить одинаковые scope, термин и объект</td><td>Не агрегировать записи до устранения несовместимости</td></tr><tr><td>После обновления API совет ломается</td><td>Зафиксирован только корневой URL</td><td>Сравнить дату, release или commit с датой решения</td><td>Добавить source pin и повторить проверку</td></tr></tbody></table>\n<h2>Порядок проверки</h2>\n<ol><li><strong>Сформулируйте одну фразу.</strong> Уберите слова «лучше», «быстрее» и «надёжнее», если рядом нет объекта, условия и способа измерения.</li><li><strong>Назовите область.</strong> Укажите протокол, версию API, тип документа, права, среду или другой фактор, который ограничивает вывод.</li><li><strong>Зафиксируйте первичный материал.</strong> Используйте RFC, официальную спецификацию, документацию владельца API или tagged release. Сохраните версию, дату или commit.</li><li><strong>Найдите локатор.</strong> Запишите раздел, страницу, таблицу, endpoint или короткий уникальный фрагмент. Корневого URL недостаточно.</li><li><strong>Перепишите наблюдение.</strong> Сохраните только тот факт, который виден в источнике. Не добавляйте к нему обещание о продукте, которого там нет.</li><li><strong>Проверьте отрицательный путь.</strong> Удалите pin, измените scope или подставьте маркетинговую фразу. Запись должна перейти в hold, а не остаться «почти подтверждённой».</li><li><strong>Назначьте действие.</strong> Укажите, что разрешено сделать дальше: использовать с ограничением, найти версию, получить измерение или остановить решение.</li></ol>\n<h2>Ограничения метода</h2>\n<p>Журнал не заменяет эксперимент. Он не измеряет задержку, не проверяет нагрузку и не устанавливает, что API одинаково ведёт себя во всех средах. Он только связывает фразу с источником и наблюдением. Для утверждения о производительности нужен воспроизводимый тест с входами, условиями и метрикой. Для утверждения о безопасности нужны модель угроз, область действия и отдельная проверка.</p>\n<p>Метод также не решает спор между двумя корректными первичными источниками. Если версии или области различаются, журнал должен показать это различие. Решение появится после явного критерия: совместимость, дата поддержки, стоимость миграции или другой измеримый приоритет. Нельзя скрывать отсутствие критерия под статусом «достаточно надёжно».</p>\n<p>Учебный код выше проверяет структуру записи, а не внешний мир. В настоящем исследовании нужно сохранить ссылку на доступный первичный документ, дату чтения и способ воспроизвести observation. Если источник исчез, изменился или не отвечает на нужный вопрос, корректный результат — hold.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Запись готова к использованию, когда другой инженер без устного пояснения может открыть зафиксированный источник, перейти к locator, увидеть observation, назвать scope и понять следующий шаг. Проверка должна пройти и для отрицательной ветки: при отсутствии версии, несовпадении области или подмене факта обещанием статус блокирует передачу.</p>\n<p>Это небольшой критерий, но он защищает решение от самой дорогой подмены: ссылка начинает выглядеть как доказательство только потому, что её никто не перепроверил.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.3\" target=\"_blank\" rel=\"noopener\">RFC 9110, раздел 8.8.3: ETag как валидатор выбранного представления</a></li><li><a href=\"https://www.w3.org/TR/prov-dm/\" target=\"_blank\" rel=\"noopener\">W3C PROV-DM: сущности, действия и происхождение данных</a></li><li><a href=\"https://www.w3.org/TR/vc-data-model/\" target=\"_blank\" rel=\"noopener\">W3C Verifiable Credentials Data Model: claims и verification</a></li></ul>"
+  "contentHtml": "<p>Ошибка в исследовании источников обычно обнаруживается поздно. В тексте стоит ссылка на документацию, но читатель не знает, какую версию открывал автор, где находится нужный факт и при каком условии он перестаёт работать. В коде такой совет превращается в неверный запрос, несовместимую настройку или лишнюю переделку. Цена ошибки — часы на повторную проверку и решение, которое нельзя уверенно объяснить после обновления документа.</p>\n<p>Ссылка — это адрес. Утверждение — ограниченная фраза, которую можно проверить. Между ними нужен короткий журнал: statement, scope, source pin, locator, observation и status. Такая запись не делает источник истинным. Она показывает, какой факт прочитан, где он находится и какое действие он разрешает.</p>\n<h2>Начните с наблюдаемой проблемы</h2>\n<p>Хорошее исследование начинается не с коллекции ссылок, а с вопроса, на который нужно принять решение. Например: «Можно ли включить условный запрос к нашему API, не меняя смысл ответа?» Это лучше, чем «как работает кеширование»: в первом вопросе названы действие, объект и риск.</p>\n<p>Зафиксируйте симптом до чтения документа. Клиент повторно скачивает один и тот же JSON, время ответа растёт, а команда предлагает добавить заголовок из статьи в интернете. Пока неизвестны версия API, поддержка прокси и семантика ответа, это гипотеза, а не план исправления. Следующий шаг — найти первичный контракт и проверить его на нужном представлении.</p>\n<h2>Разделите источник, представление и вывод</h2>\n<p>URL без версии ведёт на текущую страницу. Он не доказывает, что документ выглядел так же в момент чтения. Поэтому журнал хранит pin отдельно: датированный RFC, commit, тег релиза или опубликованный PDF отвечает на вопрос «какой материал открыт». Locator отвечает на вопрос «где искать». Observation отвечает на вопрос «что там написано или возвращено».</p>\n<p>Нужно разделять как минимум три свойства. Происхождение показывает, кто опубликовал документ и к какому объекту он относится. Целостность показывает, не изменилось ли сохранённое представление после захвата. Смысл показывает, поддерживает ли найденный фрагмент именно наше решение. Подписанный файл или совпавший хеш усиливает первые два вывода, но не превращает интерпретацию в доказанный факт.</p>\n<figure><img src=\"/assets/editorial/2025/research-method-2025-evidence-ladder.svg\" alt=\"Лестница проверки: ссылка, версия источника, локатор, наблюдение, ограниченное утверждение и действие\"><figcaption>Ссылка становится основанием решения только после фиксации версии, локатора и наблюдаемого факта.</figcaption></figure>\n<p>В HTTP эта граница хорошо видна на примере <code>ETag</code>. RFC 9110 описывает его как валидатор выбранного представления ресурса. Значение может быть непрозрачным: из <code>ETag: \"a81c\"</code> нельзя вывести релиз 8.1, дату публикации или совместимость любого SDK. Правила сравнения зависят от контекста условного запроса. Поэтому честное утверждение звучит так: «Для выбранного HTTP-представления ETag можно использовать в условном запросе по правилам RFC». Вывод «ETag ускоряет наше приложение на 20%» требует уже измерения.</p>\n<h2>Соберите карточку утверждения</h2>\n<p>Перед тем как писать совет, заполните одну карточку. Для производственного решения в ней стоит хранить и исходный запрос: язык, заголовки, права, параметры и среду. Иначе две команды могут открыть один URL и получить разные представления.</p>\n<pre><code>const claim = {\n  statement: 'ETag can participate in a conditional HTTP request',\n  scope: 'HTTP; selected representation; target service contract',\n  source: {\n    url: 'https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.3',\n    pin: 'RFC 9110, published June 2022',\n    locator: 'section 8.8.3'\n  },\n  observation: 'ETag is a validator for a selected representation',\n  evidence: {\n    capturedAt: '2025-11-07T10:00:00Z',\n    sha256: 'record-the-local-file-hash'\n  },\n  nextCheck: 'send a conditional request to the target service'\n};\n\nfunction assess(record) {\n  const required = [\n    'statement', 'scope', 'source', 'observation', 'evidence', 'nextCheck'\n  ];\n  const missing = required.filter((key) =&gt; !record[key]);\n  const sourceReady = record.source?.url &amp;&amp;\n    record.source.pin &amp;&amp; record.source.locator;\n  const evidenceReady = record.evidence?.capturedAt &amp;&amp;\n    record.evidence.sha256;\n\n  if (missing.length || !sourceReady || !evidenceReady) {\n    return { status: 'hold', missing };\n  }\n  return { status: 'ready-for-scoped-check' };\n}\n\nconsole.log(assess(claim));</code></pre>\n<p>Функция проверяет структуру карточки, а не истинность утверждения. Статус <code>ready-for-scoped-check</code> означает только, что другой инженер может найти источник и понять следующий шаг. Он не означает, что измерена производительность, проверена авторизация или доказан эффект в конкретном продукте.</p>\n<p>Отрицательная ветка обязательна. Если удалить <code>source.pin</code>, изменить <code>scope</code> или оставить пустым хеш, карточка должна перейти в <code>hold</code>. Добавление ещё одной ссылки вокруг текущей страницы не исправит отсутствие версии. Нужно найти неизменяемый первичный материал, открыть locator заново и записать новое наблюдение.</p>\n<h2>Зафиксируйте конкретное представление</h2>\n<p>Сначала сохраните представление, которое собираетесь цитировать. Команда ниже фиксирует ответ и его хеш, чтобы позднее обнаружить изменение файла. Она не доказывает, что страница навсегда неизменна, и не заменяет чтение нужного раздела. Каталог создаётся локально: путь следует выбрать по правилам проекта.</p>\n<pre><code>set -eu\nmkdir -p evidence/rfc-9110\ncurl --fail --silent --show-error --location \\\n  --dump-header evidence/rfc-9110/headers.txt \\\n  --output evidence/rfc-9110/body.html \\\n  'https://www.rfc-editor.org/rfc/rfc9110.html'\nshasum -a 256 evidence/rfc-9110/body.html \\\n  | tee evidence/rfc-9110/body.sha256\ngrep -niE '^(HTTP/|etag:|last-modified:|content-type:)' \\\n  evidence/rfc-9110/headers.txt || true</code></pre>\n<p><code>curl --fail</code> останавливает команду на HTTP-ошибке, а <code>--location</code> следует редиректам. <code>shasum -a 256</code> есть в macOS; в Linux его можно заменить на <code>sha256sum</code>. Хеш относится к сохранённому телу, а не к смыслу абзаца и не к версии API. В карточке дополнительно запишите дату, фактический URL после редиректа, заголовки запроса, версию клиента и locator.</p>\n<p>Проверка повтора должна сравнивать тот же артефакт, а не только снова открывать URL:</p>\n<pre><code>shasum -a 256 --check evidence/rfc-9110/body.sha256</code></pre>\n<p>Если команда сообщает о несовпадении, сначала выясните, изменился ли файл, кодировка или путь. Не обновляйте вывод автоматически: повторно откройте locator и решите, осталось ли утверждение применимым. Если документ доступен только после авторизации, публичный читатель не сможет воспроизвести представление; это нужно назвать ограничением, а не замаскировать пересказом.</p>\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>Добавить точный locator; при несовпадении поставить hold</td></tr><tr><td>Совет обещает «быстрее» или «надёжнее»</td><td>Нет объекта, условия и метрики</td><td>Назвать вход, результат и способ измерения</td><td>Сузить фразу или провести отдельный тест</td></tr><tr><td>Совпадение хеша принимают за доказательство поведения</td><td>Целостность смешали со смыслом</td><td>Сопоставить observation и claim буквально</td><td>Оставить вывод о файле; продуктовый вывод проверить отдельно</td></tr><tr><td>Документ доступен только после входа</td><td>Читатель не может воспроизвести представление</td><td>Проверить права, среду и разрешённый способ публикации</td><td>Дать общедоступный первичный источник или описать ограничение</td></tr><tr><td>После обновления API совет ломается</td><td>Сохранён только корневой URL</td><td>Сравнить релиз, commit, дату и контракт endpoint</td><td>Обновить карточку и повторить проверку с новой областью</td></tr></tbody></table>\n<h2>Порядок проверки от вопроса до решения</h2>\n<ol><li><strong>Сформулируйте вопрос.</strong> Не «как работает кеш», а «при каком условии этот клиент может отправить If-None-Match для выбранного представления».</li><li><strong>Запишите ограниченное утверждение.</strong> Уберите «всегда», «любой» и «безопасно», если нет отдельного доказательства для такого охвата.</li><li><strong>Назовите область.</strong> Укажите протокол, версию API, тип документа, права, среду и входные параметры.</li><li><strong>Выберите первичный источник.</strong> Для протокола используйте стандарт; для API — документацию владельца и контракт нужной версии; для кода — конкретный commit или tagged release.</li><li><strong>Закрепите представление.</strong> Сохраните URL, дату, редирект, хеш, заголовки запроса и неизменяемый pin, если он существует.</li><li><strong>Добавьте locator и observation.</strong> Другой инженер должен увидеть тот же фрагмент и отличить дословный факт от вашей интерпретации.</li><li><strong>Проверьте отрицательную ветку.</strong> Удалите pin, измените scope или подставьте маркетинговую фразу. Карточка должна перейти в hold, а не остаться «почти подтверждённой».</li><li><strong>Назначьте проверяемое действие.</strong> Это может быть условный запрос, тест совместимости, нагрузочное измерение или отказ от внедрения. Результат действия запишите отдельным наблюдением.</li></ol>\n<h2>Переход от факта к рекомендации</h2>\n<p>Держите несколько уровней, чтобы не выдавать гипотезу за факт. <strong>Наблюдение</strong> — то, что видно в документе или ответе. <strong>Ограниченное утверждение</strong> — интерпретация с явно указанной областью. <strong>Рекомендация</strong> — действие для конкретной системы после проверки входов и рисков. <strong>Результат</strong> — наблюдаемое изменение в этой системе с методикой измерения.</p>\n<p>Например, из RFC можно получить наблюдение о валидаторе выбранного представления и утверждение о семантике условного HTTP-запроса. Нельзя из него сразу получить результат «наша CDN экономит 20% трафика». Для такого вывода нужны URL, размеры представлений, политика кеша, доля условных запросов и повторяемое измерение до и после изменения.</p>\n<p>Цифровая подпись или хеш усиливают цепочку происхождения, но не расширяют scope. Если подписанный документ описывает режим read-only для версии 2, подпись не подтверждает запись в версии 3. Если официальный источник отвечает на другой вопрос, чем тот, который стоит перед командой, его авторитетность не устраняет несовпадение.</p>\n<h2>Границы метода</h2>\n<p>Журнал источников не заменяет эксперимент, ревью угроз или контрактную проверку. Он не измеряет задержку, не проверяет нагрузку и не устанавливает, что API одинаково ведёт себя во всех регионах и ролях. Для производительности нужны входы, условия, число повторов и метрика. Для безопасности нужны модель угроз, права, негативные сценарии и проверка фактической реализации.</p>\n<p>Хеш не защищает от неверного первоисточника, устаревшей спецификации или ошибки копирования. ETag не является универсальным идентификатором релиза. Дата публикации не говорит, что ваш клиент поддерживает описанный режим. Даже официальный документ может быть неполным для конкретной интеграции.</p>\n<p>Метод также не разрешает конфликт двух корректных источников автоматически. Если версии или области различаются, карточки должны показать различие. Решение появляется после явного критерия: совместимость, дата поддержки, стоимость миграции, риск или измеримый эффект. Нельзя скрывать отсутствие критерия под словом «надёжно».</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Карточка готова к передаче, когда инженер без устного пояснения может открыть зафиксированный материал, перейти к locator, увидеть observation, назвать scope и выполнить next check. Проверка должна пройти и для отрицательного пути: при отсутствии версии, несовпадении области, изменившемся хеше или подмене факта обещанием статус блокирует рекомендацию.</p>\n<p>Для практического ревью достаточно задать пять вопросов: какой именно файл или ответ мы проверили; где расположен факт; что подтверждает хеш; какое утверждение разрешено в этой области; какое наблюдение подтвердит действие в нашей системе. Если на последний вопрос отвечают ссылкой, работа ещё не закончена: ссылка даёт исходный материал, а результат должен появиться в отдельном воспроизводимом тесте.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.3\" target=\"_blank\" rel=\"noopener noreferrer\">IETF RFC 9110, раздел 8.8.3: ETag и валидаторы представления</a> — нормативное описание семантики ETag и правил, которые нельзя заменять догадкой о номере релиза.</li><li><a href=\"https://www.w3.org/TR/prov-dm/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C PROV-DM: The PROV Data Model</a> — модель сущностей, действий и происхождения, полезная для разделения артефакта, операции захвата и вывода.</li><li><a href=\"https://git-scm.com/docs/git-hash-object\" target=\"_blank\" rel=\"noopener noreferrer\">Git documentation: git-hash-object</a> — официальное описание вычисления идентификатора содержимого; хеш следует трактовать как признак конкретного артефакта, а не как доказательство его смысла.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/079.json b/editorial/agent-rewrites/079.json
index 3c0167d..fd52ed8 100644
--- a/editorial/agent-rewrites/079.json
+++ b/editorial/agent-rewrites/079.json
@@ -1,7 +1,7 @@
 {
   "index": 79,
   "slug": "editorial-2025-10-field-teaching-engineering",
-  "title": "Promise.all не отменяет работу: как объяснить границу на рабочем примере",
-  "excerpt": "После первой ошибки Promise.all возвращает rejected promise, но уже начатая работа входов не исчезает сама. Разбираем модель, контрпример и проверку, которые не дают перенести рецепт за пределы его условий.",
-  "contentHtml": "<p>Симптом появляется в момент первой ошибки. Код ждёт несколько операций через <code>await Promise.all(tasks)</code>, одна операция отклоняется, обработчик сразу переходит в <code>catch</code>, а автор считает остальные операции остановленными. Позже выясняется, что один запрос всё ещё пишет данные, таймер всё ещё выполняется, а зависимая логика уже очистила состояние. Цена ошибки — повторные записи, лишние запросы и расследование, в котором приходится восстанавливать границу ответственности по логам.</p>\n<p>Тезис простой: <code>Promise.all</code> объединяет наблюдаемые исходы promises, но не является протоколом отмены работы. Он сообщает результат aggregate promise. Он не получает автоматически право остановить операцию, которая создала входной promise. Чтобы объяснить такой код без ложной гарантии, нужно разделить три объекта: входной promise, aggregate promise и внешнюю работу.</p>\n<h2>Сначала назовите задачу</h2>\n<p>Рецепт становится опасным, когда его показывают раньше задачи. Возьмём учебный сценарий: нужно получить профиль и настройки, а затем построить экран. Если любой результат недоступен, экран строить нельзя. Здесь <code>Promise.all</code> подходит как условие для зависимого шага: зависимый код запускается только после успешного исхода двух входов.</p>\n<p>Но это условие не отвечает на другой вопрос: что делать с операцией, которая уже началась и ещё не завершилась? Объединение результатов и остановка работы относятся к разным контрактам. Первый задаёт JavaScript. Второй должен задавать приложение, библиотека или владелец ресурса.</p>\n<figure><img src=\"/assets/editorial/2025/teaching-engineering-2025-feedback-loop.svg\" alt=\"Цикл проверки объяснения Promise.all: задача, модель aggregate, контрпример с оставшимся входом, проверка границы и следующий шаг\" loading=\"lazy\" /><figcaption>Правильное объяснение ведёт от задачи к модели, затем показывает оставшийся вход после reject и только после этого говорит о следующем действии. Схема учебная: она не показывает реальный сетевой trace и не доказывает поведение конкретного сервиса.</figcaption></figure>\n<h2>Механизм: два исхода вместо одного</h2>\n<p>Пусть в <code>Promise.all</code> переданы <code>profilePromise</code> и <code>settingsPromise</code>. JavaScript создаёт новый aggregate promise. Он выполнится успешно, если все входы выполнятся. Значения попадут в массив в порядке входного iterable, а не в порядке завершения. Если один вход отклонится, aggregate promise отклонится с первой причиной отказа.</p>\n<p>Это не означает, что второй вход получил команду отмены. Второй promise может уже завершиться, продолжить ожидание или скрывать за собой работу, которую можно прервать только отдельным API. Вызов <code>catch</code> наблюдает отказ aggregate. Сам по себе он не меняет жизненный цикл запроса, чтения файла, вычисления или записи.</p>\n<p>Отсюда следует отрицательный путь. Если профиль отклонился, нельзя выводить «настройки отменены». Можно вывести только «общий результат недоступен с такой причиной». Дальше код обязан использовать собственный контракт: сигнал отмены, закрытие ресурса, остановку очереди, компенсацию или безопасное ожидание остатка. Если такого контракта нет, честный ответ — отмена не определена.</p>\n<h2>Минимальный контрпример</h2>\n<p>Ниже намеренно узкий пример. Он не обращается к сети, диску, часам или данным пользователей. Один вход отклоняется сразу. Второй вход удерживается до явного вызова <code>finishRemaining</code>. Это позволяет увидеть порядок событий и не приписывать JavaScript поведение, которого в коде нет.</p>\n<pre><code>let finishRemaining;\nconst remaining = new Promise((resolve) =&gt; {\n  finishRemaining = () =&gt; resolve('settings');\n});\n\nconst combined = Promise.all([\n  Promise.reject(new Error('profile failed')),\n  remaining,\n]).catch(() =&gt; 'aggregate handled');\n\nawait combined;\nconsole.log('aggregate rejected');\nfinishRemaining();\nconsole.log(await remaining);\n// aggregate rejected\n// settings</code></pre>\n<p>После первой строки вывода aggregate уже обработал отказ. Но второй promise ещё существует. Функция <code>finishRemaining</code> завершает его позже. Пример доказывает только это: rejected aggregate не равен отмене каждого входа. Он не доказывает, как поведёт себя HTTP-клиент, база данных или очередь сообщений. Для каждого такого ресурса нужна отдельная документация и отдельный тест.</p>\n<p>Контрпример полезнее общей фразы «promises выполняются параллельно». Это слово слишком широкое. В JavaScript promise представляет состояние будущего результата; он не является универсальным дескриптором процесса, который можно остановить одним методом. Операции могут стартовать до создания aggregate, а их остановка может быть невозможна или требовать согласия внешнего владельца.</p>\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><code>catch</code> сработал, но запрос продолжился</td><td>Aggregate наблюдает отказ, а клиент запроса не получил сигнал отмены</td><td>Посмотреть API запроса и его обработчик сигнала</td><td>Добавить явный cancel-контракт или признать работу неотменяемой</td></tr><tr><td>Результаты приходят в неожиданном порядке</td><td>Порядок завершения перепутан с порядком iterable</td><td>Сравнить индексы входов и trace завершения</td><td>Читать массив по исходным индексам, а не по времени</td></tr><tr><td>После одной ошибки обработчик пишет частичный результат</td><td>Зависимый шаг запускается не только после fulfilled aggregate</td><td>Проверить место вызова и ветки после <code>catch</code></td><td>Разделить partial result и готовый aggregate</td></tr><tr><td>Заменили <code>all</code> на <code>allSettled</code>, но проблема осталась</td><td>Нужен был протокол остановки, а изменили только форму отчёта</td><td>Назвать требование: все исходы или остановка работы</td><td>Выбрать combinator для отчёта и отдельно спроектировать отмену</td></tr><tr><td>Текст обещает «остановить всё»</td><td>Рецепт подменил причинную модель</td><td>Попросить показать объект, который посылает cancel</td><td>Сузить утверждение до aggregate и добавить отрицательный путь</td></tr></tbody></table>\n<h2>Как объяснить код без лишней теории</h2>\n<p>Начните с одной проверяемой фразы: «Экран строится только после двух успешных результатов». Затем назовите aggregate promise и покажите, где читается его результат. После этого добавьте отказ одного входа. Читатель должен увидеть, что зависимый шаг не запускается. Только теперь задайте вопрос о втором входе.</p>\n<p>Ответ должен быть конкретным. Если второй вход уже создан, у него есть собственное состояние. <code>Promise.all</code> не предоставляет в этом вызове метода <code>cancel</code>. Если вход связан с <code>fetch</code>, автор может передать <code>AbortSignal</code> и вызвать <code>AbortController.abort()</code>. Но это уже договор Fetch и конкретного кода приложения, а не свойство <code>Promise.all</code>. Даже сигнал не превращает любую серверную операцию в гарантированно отменённую: сервер мог принять запрос, а клиент мог лишь прекратить ожидание ответа.</p>\n<p>Такой ответ не должен звучать как универсальный рецепт отмены. Для учебного фрагмента достаточно показать место ответственности. В production нужно проверить, что делает клиент после abort, что происходит на сервере, как закрывается ресурс и допустима ли повторная попытка. Если эти условия не описаны, статья должна остановиться на границе знания.</p>\n<h2>Когда нужен другой combinator</h2>\n<p><code>Promise.all</code> выбирают, когда нужен общий успех всех входов и ранний отказ aggregate при первой ошибке. <code>Promise.allSettled</code> выбирают, когда нужно дождаться и сохранить статус каждого входа. Это разные требования. Переключение на <code>allSettled</code> не отменяет операции и не исправляет частичную запись.</p>\n<p>Например, экран может показывать независимые виджеты. Тогда полезно получить массив состояний и отрисовать ошибку только у одного виджета. Но платёжный сценарий, в котором нельзя продолжать без обязательного ответа, требует другой проверки: dependent action не должна начаться после rejected aggregate. Если же один вызов уже создал побочный эффект, combinator не решает вопрос компенсации. Его должен решить доменный контракт.</p>\n<p>Не стоит заменять <code>Promise.all</code> на последовательный <code>await</code> только ради иллюзии контроля. Последовательный запуск уменьшает число одновременно начатых операций, но не отменяет первую операцию при ошибке второй. Он также меняет задержку и нагрузку. Сначала зафиксируйте требование, затем выбирайте форму ожидания.</p>\n<h2>Проверяемый порядок действий</h2>\n<ol><li>Запишите исходную задачу одним предложением: какие результаты нужны и какой шаг зависит от них.</li><li>Назовите каждый входной promise и работу, которая стоит за ним. Не называйте promise самой работой.</li><li>Покажите fulfilled-путь: все входы завершились, aggregate вернул значения в порядке iterable, зависимый шаг получил полный набор.</li><li>Покажите отрицательный путь: один вход отклонился, aggregate отклонился, зависимый шаг не стартовал.</li><li>Проверьте оставшийся вход отдельным наблюдением. Ответьте, может ли он завершиться после reject и кто имеет право его остановить.</li><li>Если нужна отмена, найдите реальный контракт ресурса: сигнал, close, cancel, rollback или другой механизм подтверждения.</li><li>Проверьте частичные результаты и побочные эффекты. Отдельно решите, допустимы ли повтор, компенсация и повторный запуск.</li><li>Сформулируйте готовность одной проверяемой фразой и приложите тест для положительной и отрицательной ветки.</li></ol>\n<h2>Ограничения учебного примера</h2>\n<p>Пример выше фиксирует порядок наблюдений в памяти. Он не моделирует latency, сетевые разрывы, retry, таймауты, серверную обработку, блокировки базы, очередь или пользовательскую сессию. Нельзя переносить его вывод как готовую архитектуру. Его задача уже: показать, почему aggregate rejection не доказывает отмену входа.</p>\n<p>Есть и другой отрицательный путь: остановка может быть технически доступна, но логически запрещена. Например, сервер уже принял команду, и отмена клиентского ожидания не должна приводить к повторной команде без idempotency key. В таком случае «прервать ожидание» и «отменить побочный эффект» — два разных решения. Текст, который объединяет их одним словом «cancel», скрывает риск.</p>\n<p>Не заявляйте результат обучения или production-эффект по одному примеру. Можно проверить, что читатель назвал aggregate, вход и отдельный cancel-контракт. Нельзя из этого вывести, что он безопасно спроектирует любой асинхронный pipeline. Для такого вывода нужна другая проверка, привязанная к конкретной системе.</p>\n<h2>Критерий готовности</h2>\n<p>Объяснение готово, если независимый читатель может без подсказки ответить на четыре вопроса: какой результат объединяет <code>Promise.all</code>; что происходит при первом reject; может ли оставшийся вход закончиться позже; кто именно останавливает внешнюю работу. Код должен проходить тесты для fulfilled-пути и для отказа, а текст — не обещать отмену там, где в API нет такого контракта.</p>\n<p>Практическая финальная проверка короткая. Уберите названия методов и попросите восстановить модель по событиям. Затем верните код и сравните каждое утверждение с наблюдаемым результатом. Если для фразы «всё остановилось» нельзя назвать объект, который отправил сигнал остановки, замените её на точное утверждение об aggregate. Такая редактура сохраняет полезный рецепт и не переносит его за пределы условий задачи.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://tc39.es/ecma262/\" target=\"_blank\" rel=\"noopener noreferrer\">ECMAScript Language Specification: Promise.all</a> — актуальная спецификация ECMAScript и алгоритм combinator. Источник описывает aggregate-результат, но не задаёт отмену внешней работы.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: Promise.all()</a> — официальная справочная документация с условиями fulfilled/rejected, порядком результатов и сравнением с <code>Promise.allSettled()</code>. Она не обещает автоматическую отмену входов.</li></ul>"
+  "title": "Promise.all не отменяет работу: как не потерять второй запрос",
+  "excerpt": "Promise.all объединяет результаты, но не останавливает уже начатые операции. На коротком примере разберём first rejection, порядок значений, allSettled и явную отмену через AbortController.",
+  "contentHtml": "<p>Симптом появляется в момент первой ошибки. Код ждёт несколько операций через <code>await Promise.all(tasks)</code>, одна операция отклоняется, обработчик сразу переходит в <code>catch</code>, а автор считает остальные операции остановленными. Позже выясняется, что один запрос всё ещё пишет данные, таймер всё ещё выполняется, а зависимая логика уже очистила состояние. Цена ошибки — повторные записи, лишние запросы и расследование, в котором приходится восстанавливать границу ответственности по логам.</p>\n<p>Тезис простой: <code>Promise.all</code> объединяет наблюдаемые исходы promises, но не является протоколом отмены работы. Он сообщает результат aggregate promise. Он не получает автоматически право остановить операцию, которая создала входной promise. Чтобы объяснить такой код без ложной гарантии, нужно разделить три объекта: входной promise, aggregate promise и внешнюю работу.</p>\n<h2>Сначала назовите задачу</h2>\n<p>Рецепт становится опасным, когда его показывают раньше задачи. Возьмём учебный сценарий: нужно получить профиль и настройки, а затем построить экран. Если любой результат недоступен, экран строить нельзя. Здесь <code>Promise.all</code> подходит как условие для зависимого шага: зависимый код запускается только после успешного исхода двух входов.</p>\n<p>Но это условие не отвечает на другой вопрос: что делать с операцией, которая уже началась и ещё не завершилась? Объединение результатов и остановка работы относятся к разным контрактам. Первый задаёт JavaScript. Второй должен задавать приложение, библиотека или владелец ресурса.</p>\n<figure><img src=\"/assets/editorial/2019/event-loop-trace-2019.svg\" alt=\"Схема диагностики порядка асинхронных callback: от отметок времени и номера запуска к разделению sync, microtask и task и проверке trace\" loading=\"lazy\" /><figcaption>Для расследования разделяйте события aggregate и каждого входа: запись об ошибке общего ожидания ещё не показывает, что внешняя операция остановилась. Рисунок помогает найти источник и порядок callback, но не заменяет проверку API отмены.</figcaption></figure>\n<h2>Механизм: два исхода вместо одного</h2>\n<p>Пусть в <code>Promise.all</code> переданы <code>profilePromise</code> и <code>settingsPromise</code>. JavaScript создаёт новый aggregate promise. Он выполнится успешно, если все входы выполнятся. Значения попадут в массив в порядке входного iterable, а не в порядке завершения. Если один вход отклонится, aggregate promise отклонится с первой причиной отказа.</p>\n<p>Это не означает, что второй вход получил команду отмены. Второй promise может уже завершиться, продолжить ожидание или скрывать за собой работу, которую можно прервать только отдельным API. Вызов <code>catch</code> наблюдает отказ aggregate. Сам по себе он не меняет жизненный цикл запроса, чтения файла, вычисления или записи.</p>\n<p>Отсюда следует отрицательный путь. Если профиль отклонился, нельзя выводить «настройки отменены». Можно вывести только «общий результат недоступен с такой причиной». Дальше код обязан использовать собственный контракт: сигнал отмены, закрытие ресурса, остановку очереди, компенсацию или безопасное ожидание остатка. Если такого контракта нет, честный ответ — отмена не определена.</p>\n<h2>Минимальный контрпример</h2>\n<p>Ниже намеренно узкий пример. Он не обращается к сети, диску, часам или данным пользователей. Один вход отклоняется сразу. Второй вход удерживается до явного вызова <code>finishRemaining</code>. Это позволяет увидеть порядок событий и не приписывать JavaScript поведение, которого в коде нет.</p>\n<pre><code>let finishRemaining;\nconst remaining = new Promise((resolve) =&gt; {\n  finishRemaining = () =&gt; resolve('settings');\n});\n\nconst combined = Promise.all([\n  Promise.reject(new Error('profile failed')),\n  remaining,\n]).catch(() =&gt; 'aggregate handled');\n\nawait combined;\nconsole.log('aggregate rejected');\nfinishRemaining();\nconsole.log(await remaining);\n// aggregate rejected\n// settings</code></pre>\n<p>После первой строки вывода aggregate уже обработал отказ. Но второй promise ещё существует. Функция <code>finishRemaining</code> завершает его позже. Пример доказывает только это: rejected aggregate не равен отмене каждого входа. Он не доказывает, как поведёт себя HTTP-клиент, база данных или очередь сообщений. Для каждого такого ресурса нужна отдельная документация и отдельный тест.</p>\n<p>Контрпример полезнее общей фразы «promises выполняются параллельно». Это слово слишком широкое. В JavaScript promise представляет состояние будущего результата; он не является универсальным дескриптором процесса, который можно остановить одним методом. Операции могут стартовать до создания aggregate, а их остановка может быть невозможна или требовать согласия внешнего владельца.</p>\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><code>catch</code> сработал, но запрос продолжился</td><td>Aggregate наблюдает отказ, а клиент запроса не получил сигнал отмены</td><td>Посмотреть API запроса и его обработчик сигнала</td><td>Добавить явный cancel-контракт или признать работу неотменяемой</td></tr><tr><td>Результаты приходят в неожиданном порядке</td><td>Порядок завершения перепутан с порядком iterable</td><td>Сравнить индексы входов и trace завершения</td><td>Читать массив по исходным индексам, а не по времени</td></tr><tr><td>После одной ошибки обработчик пишет частичный результат</td><td>Зависимый шаг запускается не только после fulfilled aggregate</td><td>Проверить место вызова и ветки после <code>catch</code></td><td>Разделить partial result и готовый aggregate</td></tr><tr><td>Заменили <code>all</code> на <code>allSettled</code>, но проблема осталась</td><td>Нужен был протокол остановки, а изменили только форму отчёта</td><td>Назвать требование: все исходы или остановка работы</td><td>Выбрать combinator для отчёта и отдельно спроектировать отмену</td></tr><tr><td>Текст обещает «остановить всё»</td><td>Рецепт подменил причинную модель</td><td>Попросить показать объект, который посылает cancel</td><td>Сузить утверждение до aggregate и добавить отрицательный путь</td></tr></tbody></table>\n<h2>Как объяснить код без лишней теории</h2>\n<p>Начните с одной проверяемой фразы: «Экран строится только после двух успешных результатов». Затем назовите aggregate promise и покажите, где читается его результат. После этого добавьте отказ одного входа. Читатель должен увидеть, что зависимый шаг не запускается. Только теперь задайте вопрос о втором входе.</p>\n<p>Ответ должен быть конкретным. Если второй вход уже создан, у него есть собственное состояние. <code>Promise.all</code> не предоставляет в этом вызове метода <code>cancel</code>. Если вход связан с <code>fetch</code>, автор может передать <code>AbortSignal</code> и вызвать <code>AbortController.abort()</code>. Но это уже договор Fetch и конкретного кода приложения, а не свойство <code>Promise.all</code>. Даже сигнал не превращает любую серверную операцию в гарантированно отменённую: сервер мог принять запрос, а клиент мог лишь прекратить ожидание ответа.</p>\n<p>Такой ответ не должен звучать как универсальный рецепт отмены. Для учебного фрагмента достаточно показать место ответственности. В production нужно проверить, что делает клиент после abort, что происходит на сервере, как закрывается ресурс и допустима ли повторная попытка. Если эти условия не описаны, статья должна остановиться на границе знания.</p>\n<h2>Проверяемый пример с AbortController</h2>\n<p>Если входами являются <code>fetch</code>-запросы, общий сигнал делает отмену явной. Сохраните следующий фрагмент как <code>load-pages.mjs</code> и запустите на Node.js 18 или новее командой <code>node load-pages.mjs</code>. URL-ы должны быть доступны вашему тестовому серверу: один endpoint верните с ошибкой, другой задержите.</p>\n<pre><code>async function loadPages(urls) {\n  const controller = new AbortController();\n  const { signal } = controller;\n\n  try {\n    return await Promise.all(\n      urls.map(async (url) =&gt; {\n        const response = await fetch(url, { signal });\n        if (!response.ok) {\n          throw new Error(`HTTP ${response.status}: ${url}`);\n        }\n        return response.json();\n      }),\n    );\n  } catch (error) {\n    controller.abort();\n    throw error;\n  }\n}</code></pre>\n<p>Этот код отменяет только pending <code>fetch</code>, которым передан тот же сигнал. Он не откатывает данные, которые сервер уже принял, и не влияет на операцию, игнорирующую <code>signal</code>. Поэтому тест должен проверять две вещи: второй клиентский запрос получил abort, а серверная команда не требует повторения без идемпотентного ключа.</p>\n<p>Для полностью детерминированной проверки границы сети не нужно симулировать production-сервис. Поднимите тестовый endpoint с управляемой задержкой, добавьте в лог request id и сравните время <code>abort()</code> с серверным trace. Если сервер успел выполнить побочный эффект, результатом проверки будет не «всё отменено», а зафиксированное правило компенсации или сверки.</p>\n<h2>Когда нужен другой combinator</h2>\n<p><code>Promise.all</code> выбирают, когда нужен общий успех всех входов и ранний отказ aggregate при первой ошибке. <code>Promise.allSettled</code> выбирают, когда нужно дождаться и сохранить статус каждого входа. Это разные требования. Переключение на <code>allSettled</code> не отменяет операции и не исправляет частичную запись.</p>\n<p>Например, экран может показывать независимые виджеты. Тогда полезно получить массив состояний и отрисовать ошибку только у одного виджета. Но платёжный сценарий, в котором нельзя продолжать без обязательного ответа, требует другой проверки: dependent action не должна начаться после rejected aggregate. Если же один вызов уже создал побочный эффект, combinator не решает вопрос компенсации. Его должен решить доменный контракт.</p>\n<p>Не стоит заменять <code>Promise.all</code> на последовательный <code>await</code> только ради иллюзии контроля. Последовательный запуск уменьшает число одновременно начатых операций, но не отменяет первую операцию при ошибке второй. Он также меняет задержку и нагрузку. Сначала зафиксируйте требование, затем выбирайте форму ожидания.</p>\n<h2>Проверяемый порядок действий</h2>\n<ol><li>Запишите исходную задачу одним предложением: какие результаты нужны и какой шаг зависит от них.</li><li>Назовите каждый входной promise и работу, которая стоит за ним. Не называйте promise самой работой.</li><li>Покажите fulfilled-путь: все входы завершились, aggregate вернул значения в порядке iterable, зависимый шаг получил полный набор.</li><li>Покажите отрицательный путь: один вход отклонился, aggregate отклонился, зависимый шаг не стартовал.</li><li>Проверьте оставшийся вход отдельным наблюдением. Ответьте, может ли он завершиться после reject и кто имеет право его остановить.</li><li>Если нужна отмена, найдите реальный контракт ресурса: сигнал, close, cancel, rollback или другой механизм подтверждения.</li><li>Проверьте частичные результаты и побочные эффекты. Отдельно решите, допустимы ли повтор, компенсация и повторный запуск.</li><li>Сформулируйте готовность одной проверяемой фразой и приложите тест для положительной и отрицательной ветки.</li></ol>\n<h2>Ограничения учебного примера</h2>\n<p>Пример выше фиксирует порядок наблюдений в памяти. Он не моделирует latency, сетевые разрывы, retry, таймауты, серверную обработку, блокировки базы, очередь или пользовательскую сессию. Нельзя переносить его вывод как готовую архитектуру. Его задача уже: показать, почему aggregate rejection не доказывает отмену входа.</p>\n<p>Есть и другой отрицательный путь: остановка может быть технически доступна, но логически запрещена. Например, сервер уже принял команду, и отмена клиентского ожидания не должна приводить к повторной команде без idempotency key. В таком случае «прервать ожидание» и «отменить побочный эффект» — два разных решения. Текст, который объединяет их одним словом «cancel», скрывает риск.</p>\n<p>Не заявляйте production-эффект по одному примеру. Проверка должна установить, что aggregate, входной promise и cancel-контракт связаны наблюдаемыми событиями. Она не доказывает безопасность любого асинхронного pipeline; для этого нужен отдельный тест конкретной системы.</p>\n<h2>Критерий готовности</h2>\n<p>Объяснение готово, если независимый читатель может без подсказки ответить на четыре вопроса: какой результат объединяет <code>Promise.all</code>; что происходит при первом reject; может ли оставшийся вход закончиться позже; кто именно останавливает внешнюю работу. Код должен проходить тесты для fulfilled-пути и для отказа, а текст — не обещать отмену там, где в API нет такого контракта.</p>\n<p>Практическая финальная проверка короткая. Уберите названия методов и попросите восстановить модель по событиям. Затем верните код и сравните каждое утверждение с наблюдаемым результатом. Если для фразы «всё остановилось» нельзя назвать объект, который отправил сигнал остановки, замените её на точное утверждение об aggregate. Такой порядок сохраняет полезный рецепт и не переносит его за пределы условий задачи.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://ecma-international.org/wp-content/uploads/ECMA-262_16th_edition_june_2025.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Ecma International: ECMAScript 2025, 16th edition, June 2025</a> — нормативная спецификация; алгоритм <code>Promise.all</code> описывает aggregate outcome, входной iterable и обработку отказа, но не задаёт отмену внешних ресурсов.</li><li><a href=\"https://github.com/mdn/content/blob/3fad0447b4901e28fe88769976787d8d8b87d66d/files/en-us/web/javascript/reference/global_objects/promise/all/index.md?plain=1\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: Promise.all()</a> — справка о fulfilled/rejected, порядке значений, fail-fast, обработанных входах и различии с <code>Promise.allSettled()</code>.</li><li><a href=\"https://github.com/mdn/content/blob/3fad0447b4901e28fe88769976787d8d8b87d66d/files/en-us/web/api/abortcontroller/index.md?plain=1\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: AbortSignal</a> — контракт передачи сигнала в поддерживающую операцию, вызова <code>AbortController.abort()</code> и результата abort для Fetch.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/080.json b/editorial/agent-rewrites/080.json
index 8dfed48..1944bac 100644
--- a/editorial/agent-rewrites/080.json
+++ b/editorial/agent-rewrites/080.json
@@ -1,7 +1,7 @@
 {
   "index": 80,
   "slug": "editorial-2025-10-mechanism-teaching-engineering",
-  "title": "Promise.all: почему первая ошибка не останавливает остальные операции",
-  "excerpt": "Promise.all управляет итогом набора промисов, но не владеет внешней работой. Разбираем порядок результатов, ранний reject, отдельную отмену и безопасную проверку на небольшом примере.",
-  "contentHtml": "<p>Сервис собирает профиль пользователя из трёх запросов: настройки, лимиты и историю операций. Один запрос завершается ошибкой. Обработчик сразу попадает в <code>catch</code> и возвращает ответ об ошибке. Через секунду другой запрос всё ещё пишет в лог, держит соединение или меняет локальное состояние.</p>\n<p>Симптом — разработчик видит отклонённый <code>Promise.all</code> и говорит: «набор остановился». Цена ошибки — лишняя нагрузка, гонка за общим состоянием и неверная очистка ресурсов. Код может повторить операцию, пока первый запуск ещё работает. Расследование усложняется: aggregate уже отклонён, а позднее событие живёт в другом promise.</p>\n<p>Тезис простой: <code>Promise.all</code> сообщает исход группы. Он не является командой отмены для входных promise и не знает, какая внешняя операция их породила. Ранний <code>reject</code> останавливает ожидание успешного aggregate, но не доказывает остановку работы. Для остановки нужен отдельный контракт: владелец сигнала, способ передать его операции и подтверждение результата.</p>\n<h2>Механизм: три разных объекта</h2>\n<p>Первый объект — входной promise. Он представляет один будущий исход: значение или ошибку. Второй — aggregate promise, который возвращает <code>Promise.all(iterable)</code>. Он собирает значения по позиции входного iterable и принимает решение о собственном исходе. Третий — внешняя операция: HTTP-запрос, чтение файла, запрос к базе или вычисление. Она может существовать за пределами promise-модели.</p>\n<p>Связь направлена только в одну сторону. Вход сообщает aggregate, что он fulfilled или rejected. Aggregate сообщает вызывающему коду свой исход. Такая связь не содержит команды «остановись» для другого входа. Даже после reject aggregate другой вход может позже fulfilled или rejected.</p>\n<pre><code>const left = Promise.reject(new Error('parse failed'));\nconst right = new Promise((resolve) =&gt; {\n  setTimeout(() =&gt; resolve('right is done'), 100);\n});\n\ntry {\n  await Promise.all([left, right]);\n} catch (error) {\n  console.log('aggregate rejected:', error.message);\n}\n\n// Это не команда отмены для right.</code></pre>\n<p>Здесь <code>Promise.all</code> отклоняется из-за <code>left</code>. Ожидание текущей функции заканчивается. Но таймер получил отдельное право завершить <code>right</code>. Никакой код не передал ему сигнал отмены. Поэтому позднее значение появится, даже если вызывающий код больше его не читает.</p>\n<p>Это учебный пример с фиксированными promise и таймером. Он не измеряет задержку сети, поведение браузера или расход ресурсов в production. Он проверяет только границу между исходом aggregate и исходом другого входа.</p>\n<figure><img src='/assets/editorial/2025/teaching-engineering-2025-misconception-matrix.svg' alt='Три уровня Promise.all: входной promise, aggregate promise и внешняя операция' loading='lazy' /><figcaption>Aggregate фиксирует свой исход. Из этого факта нельзя автоматически вывести отмену входа или внешней операции.</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><code>catch</code> сработал, но поздний лог продолжился</td><td>Другой вход завершает собственную работу</td><td>Добавить trace для каждого входа</td><td>Не называть aggregate отменой; найти владельца</td></tr><tr><td>Значения пришли в неожиданном порядке</td><td>Ожидалась скорость, а не позиция iterable</td><td>Сравнить индексы и порядок событий</td><td>Читать результат по позиции или хранить ключ</td></tr><tr><td>Нужно увидеть каждую ошибку, но видна одна</td><td><code>Promise.all</code> завершает aggregate на первом reject</td><td>Проверить требование к полному отчёту</td><td>Рассмотреть <code>Promise.allSettled</code></td></tr><tr><td>После ошибки запросы продолжаются</td><td>Операции не получили общий сигнал</td><td>Проверить API и обработчик сигнала</td><td>Передать <code>AbortSignal</code> или другой cancel contract</td></tr><tr><td>Остановка считается доказанной по reject</td><td>Смешаны исход результата и управление ресурсом</td><td>Назвать реальное действие прерывания</td><td>Разделить зависимую логику и протокол остановки</td></tr></tbody></table>\n<h2>Порядок результатов и первая ошибка</h2>\n<p>При успешном исходе массив значений сохраняет порядок входного iterable, а не порядок завершения. Быстрый второй promise всё равно окажется во второй позиции. Это удобно для сопоставления, пока массив не меняется между запуском и чтением.</p>\n<p>При reject aggregate получает ошибку входа, который первым сообщил отклонение в рамках алгоритма наблюдения. Это не отчёт обо всех ошибках и не журнал времени завершения. <code>Promise.allSettled</code> решает другую задачу: ждёт завершения всех входов и возвращает статус каждого. Он тоже не добавляет отмену.</p>\n<h2>Отмена живёт рядом, но отдельно</h2>\n<p>Для операции, которая умеет принимать сигнал, отмену можно связать с обработкой aggregate. В браузерном или серверном коде это часто <code>AbortController</code> и его <code>signal</code>. Контроллер создаёт вызывающий код. Операции получают сигнал. При ошибке вызывающий код вызывает <code>abort()</code>. Конкретный API должен обработать сигнал по своему контракту.</p>\n<pre><code>async function loadPages(urls) {\n  const controller = new AbortController();\n  const signal = controller.signal;\n\n  try {\n    return await Promise.all(\n      urls.map((url) =&gt; fetch(url, { signal }).then((response) =&gt; {\n        if (!response.ok) throw new Error('HTTP ' + response.status);\n        return response.json();\n      })),\n    );\n  } catch (error) {\n    controller.abort();\n    throw error;\n  }\n}</code></pre>\n<p>Фрагмент ограничен операциями <code>fetch</code>, которые получили сигнал. Он не отменяет синхронную функцию, уже записанную транзакцию или promise, который игнорирует <code>signal</code>. <code>abort()</code> означает запрос на остановку поддерживаемой операции, а не откат каждого побочного эффекта.</p>\n<h2>Проверка на маленькой трассировке</h2>\n<p>Запишите события каждого уровня. Первый promise отклоняет aggregate. Затем ручной владелец второго promise вызывает сохранённый <code>resolve</code>. Ожидаемая последовательность показывает два факта: aggregate rejected, а другой вход позже fulfilled.</p>\n<pre><code>const trace = [];\nlet finishRight;\n\nconst left = Promise.reject(new Error('left failed'));\nconst right = new Promise((resolve) =&gt; {\n  finishRight = () =&gt; {\n    trace.push('right fulfilled');\n    resolve('ok');\n  };\n});\n\nawait Promise.all([left, right]).catch(() =&gt; trace.push('aggregate rejected'));\nfinishRight();\nawait right;\n\nconsole.log(trace);\n// ['aggregate rejected', 'right fulfilled']</code></pre>\n<p>Трассировка не доказывает, что реальный запрос продолжился: в ней нет запроса. Она доказывает более узкое утверждение о promise, которым мы управляем вручную. Для сетевой отмены нужен отдельный тест API, который принимает сигнал, и проверка его наблюдаемого завершения.</p>\n<h2>Порядок действий</h2>\n<ol><li>Назовите каждый вход и внешнюю операцию, которая его создаёт.</li><li>Запишите нужный результат: все значения, первый успешный, все статусы или раннее завершение зависимой логики.</li><li>Снимите отдельный trace для входов и aggregate.</li><li>Проверьте отрицательный путь: после первого reject другой вход может завершиться позже.</li><li>Если нужна остановка, найдите API отмены и его владельца. Передайте сигнал до запуска.</li><li>Проверьте, что обработчик сигнала меняет состояние нужной операции.</li><li>Только затем выбирайте <code>Promise.all</code>, <code>Promise.allSettled</code> или другой способ композиции.</li></ol>\n<h2>Ограничения модели</h2>\n<p><code>Promise.all</code> не обещает параллельное выполнение в смысле потоков. JavaScript может передать управление между асинхронными продолжениями, а конкретный API сам определяет выполнение. Нельзя выводить пропускную способность, порядок сетевых пакетов или освобождение ресурса из одного вызова combinator.</p>\n<p>Нельзя считать <code>abort()</code> универсальным откатом. Он не возвращает отправленные данные, не отменяет побочный эффект на сервере и не исправляет уже завершённую запись. Он также не заменяет дедупликацию, идемпотентность и таймаут.</p>\n<p>Нельзя выбирать <code>allSettled</code> только потому, что первая ошибка неудобна. Если следующий шаг требует всех значений, ранний reject не даёт начать неполный расчёт. Если нужен отчёт о каждом независимом входе, подходит all-settled-семантика. Решение зависит от зависимости между работами.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Разбор готов, когда команда отвечает на четыре вопроса: какой promise отклоняет aggregate; какой вход может завершиться позже; какое действие останавливает внешнюю работу; какое наблюдение подтверждает остановку. Учебный код готов, если trace показывает независимые исходы. Код с реальными операциями готов, если тест проверяет поддержку сигнала и отрицательный путь, где один вход отвергнут, а другой ещё выполняется.</p>\n<p>Если на вопрос об остановке отвечают «<code>Promise.all</code>», модель не готова. Добавьте владельца отмены или честно зафиксируйте, что операция не поддерживает остановку.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://262.ecma-international.org/16.0/#sec-promise.all' target='_blank' rel='noopener noreferrer'>ECMA-262, ECMAScript 2025: Promise.all</a> — нормативный алгоритм композиции promise; он описывает исход aggregate и не задаёт отмену внешних ресурсов.</li><li><a href='https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all' target='_blank' rel='noopener noreferrer'>MDN: Promise.all()</a> — порядок значений и отклонение aggregate при ошибке входа.</li><li><a href='https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Resource_management#automatically_cancelling_in-progress_requests' target='_blank' rel='noopener noreferrer'>MDN: Automatically cancelling in-progress requests</a> — пример отдельного <code>AbortController</code> для отмены поддерживаемых <code>fetch</code>-запросов.</li></ul>"
-}
\ No newline at end of file
+  "title": "Promise.all не отменяет работу: как разделить результат и управление",
+  "excerpt": "Разбираем на трассировке, что именно отклоняет Promise.all, почему соседние операции продолжаются и как связать отмену с AbortController, не выдавая запрос на остановку за откат побочных эффектов.",
+  "contentHtml": "<p>Сервис собирает профиль из настроек, лимитов и истории операций. Код запускает три запроса через <code>Promise.all</code>. Если настройки отвечают ошибкой, обработчик сразу получает отказ и возвращает клиенту ошибку. В это время история может ещё выполняться: соединение занято, лог продолжает поступать, а завершившийся запрос может попытаться обновить общее состояние.</p>\n<p>Такой симптом часто описывают словами «<code>Promise.all</code> остановил набор». Это неточное объяснение. Если его принять за контракт отмены, команда начнёт повторять сбор профиля поверх ещё работающего запуска или решит, что серверный побочный эффект уже невозможен. Правильный вопрос звучит иначе: какой объект сообщил об ошибке и каким механизмом владелец работы может остановить саму работу?</p>\n<h2>Сначала разделим три уровня</h2>\n<p>В этой ситуации есть три разных объекта. Входной promise представляет один будущий исход: значение или ошибку. Aggregate promise, который вернул <code>Promise.all</code>, представляет решение о всей группе. Внешняя операция — сетевой запрос, чтение файла, обращение к базе или вычисление — создаётся конкретным API и может иметь собственный жизненный цикл.</p>\n<p><code>Promise.all</code> связывает исходы первых двух уровней. Он подписывается на входы, ждёт их успешного завершения и кладёт значения в массив по позиции входного iterable. Первый отказ переводит aggregate в состояние <code>rejected</code>. В этом алгоритме нет универсальной команды, которая должна остановить остальные входы или ресурс, породивший их.</p>\n<figure><img src='/assets/editorial/2025/teaching-engineering-2025-misconception-matrix.svg' alt='Матрица Promise.all: aggregate отклонён, отдельный вход имеет собственный исход, а внешняя операция требует отдельного контракта отмены' loading='lazy' /><figcaption>Отклонённый aggregate — наблюдаемый исход композиции. Он не доказывает ни остановку входных promise, ни отмену внешней операции.</figcaption></figure>\n<h2>Что гарантирует Promise.all</h2>\n<p>У метода есть две полезные и проверяемые гарантии. При успехе он возвращает массив значений в порядке входного iterable, даже если второй запрос завершился раньше первого. При отказе он отклоняет возвращённый promise с причиной отказа входа, который первым отклонился. После этого ожидание aggregate заканчивается, но остальные входы всё ещё могут перейти в свой исход.</p>\n<p>Слово «первым» относится к моменту, когда отказ наблюдён для aggregate, а не к позиции элемента и не к полному отчёту о всех ошибках. Последующие входы всё равно получают обработчики через внутреннюю композицию. Поэтому поздний отказ не обязан превращаться в отдельное необработанное исключение, а позднее выполнение не исчезает только потому, что вызывающий код перестал ждать aggregate.</p>\n<pre><code>const trace = [];\nconst task = (name, delay, shouldReject = false) =&gt; new Promise((resolve, reject) =&gt; {\n  setTimeout(() =&gt; {\n    trace.push(name + ': finished');\n    if (shouldReject) {\n      reject(new Error(name + ': failed'));\n      return;\n    }\n    resolve(name);\n  }, delay);\n});\n\nconst tasks = [\n  task('settings', 10, true),\n  task('limits', 40),\n  task('history', 70),\n];\n\nawait Promise.all(tasks).catch((error) =&gt; {\n  trace.push('aggregate: ' + error.message);\n});\n\nconsole.log(trace);\n// ['settings: finished', 'aggregate: settings: failed']\n\nawait Promise.allSettled(tasks);\nconsole.log(trace);\n// ['settings: finished', 'aggregate: settings: failed',\n//  'limits: finished', 'history: finished']</code></pre>\n<p>Сохраните фрагмент в <code>promise-all-trace.mjs</code> и запустите командой <code>node promise-all-trace.mjs</code> в Node.js с поддержкой ES-модулей. Первый вывод появляется примерно через 10 мс, второй — после окончания всех таймеров. Точные интервалы зависят от планировщика, но порядок событий задаётся задержками: aggregate уже отклонён, когда два других входа ещё не завершились.</p>\n<p>Это намеренно маленький тест. Таймер не моделирует TCP-соединение, запрос к базе или отмену на сервере. Он воспроизводит только границу между состоянием aggregate и состояниями уже запущенных входов.</p>\n<h2>Порядок значений не равен порядку завершения</h2>\n<p>Результат успешного вызова сопоставляется с исходным массивом, а не со скоростью задач. Вызов <code>Promise.all([loadSettings(), loadHistory()])</code> вернёт настройки в позиции <code>0</code>, историю в позиции <code>1</code>, даже если история пришла раньше. Это делает композицию удобной, пока список входов не меняется между запуском и чтением.</p>\n<p>Если нужны статусы всех независимых операций, выбирайте <code>Promise.allSettled</code>. Он ждёт завершения каждого входа и возвращает элементы вида <code>{ status: 'fulfilled', value }</code> или <code>{ status: 'rejected', reason }</code>. Этот метод меняет форму отчёта, но не добавляет отмену: ни <code>all</code>, ни <code>allSettled</code> не знают, как остановить произвольную работу.</p>\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><code>Promise.all</code></td><td>Нужны все значения, и один отказ делает результат непригодным</td><td>Массив значений по позициям или первая причина отказа aggregate</td><td>Не отменяет остальные операции</td></tr><tr><td><code>Promise.allSettled</code></td><td>Каждый вход нужно учесть независимо от его исхода</td><td>Массив статусов всех входов после их завершения</td><td>Не отменяет и не исправляет побочные эффекты</td></tr><tr><td><code>Promise.race</code></td><td>Нужен первый завершившийся исход, например гонка с таймером</td><td>Значение или ошибка первого settled promise</td><td>Таймером нельзя отменить проигравшую работу</td></tr><tr><td><code>Promise.any</code></td><td>Достаточно первого успешного результата</td><td>Первое fulfilled-значение или <code>AggregateError</code>, если все отказали</td><td>Не останавливает остальные попытки</td></tr></tbody></table>\n<p>Например, таймаут через <code>Promise.race</code> меняет то, что увидит вызывающий код, но сам по себе не выключает медленный запрос. Если запрос дорогой или меняет данные, таймаут должен идти вместе с реальным контрактом отмены либо с отдельной защитой от повторной операции.</p>\n<h2>Как добавить отмену для fetch</h2>\n<p>Отмена должна иметь владельца и канал связи. В браузерном Fetch API таким каналом служит <code>AbortSignal</code>: вызывающий код создаёт <code>AbortController</code>, передаёт его сигнал каждой поддерживаемой операции и вызывает <code>abort()</code>, когда группа больше не нужна. Сам <code>Promise.all</code> при этом остаётся только агрегатором.</p>\n<pre><code>async function fetchJson(url, signal) {\n  const response = await fetch(url, { signal });\n  if (!response.ok) {\n    throw new Error(url + ': HTTP ' + response.status);\n  }\n  return response.json();\n}\n\nasync function loadProfile(urls) {\n  const controller = new AbortController();\n  const requests = urls.map((url) =&gt; fetchJson(url, controller.signal));\n\n  try {\n    return await Promise.all(requests);\n  } catch (error) {\n    controller.abort();\n    throw error;\n  }\n}\n\ntry {\n  const [settings, limits, history] = await loadProfile([\n    'https://api.example.test/settings',\n    'https://api.example.test/limits',\n    'https://api.example.test/history',\n  ]);\n  console.log({ settings, limits, history });\n} catch (error) {\n  console.error('profile failed:', error.message);\n}</code></pre>\n<p>В примере ошибка одного <code>fetch</code> попадает в <code>catch</code>, после чего контроллер посылает сигнал всем трём запросам. Поддерживаемый браузером запрос обычно завершается отказом, связанным с abort. Между исходной ошибкой и вызовом <code>abort()</code> есть короткая гонка: операция могла уже завершиться, поэтому код не должен обещать, что каждый запрос будет остановлен.</p>\n<p>В прикладном коде контроллер часто принадлежит экрану, обработчику запроса или задаче верхнего уровня. Тогда функция принимает внешний <code>signal</code>, а не создаёт скрытый контроллер, чтобы закрытие страницы или отмена родительской задачи тоже дошли до <code>fetch</code>. Контракт следует описать явно: кто вызывает <code>abort()</code>, какие API принимают сигнал и какое состояние видит вызывающий код после отмены.</p>\n<h2>Где AbortController не спасает</h2>\n<p><code>AbortController</code> работает только там, где операция действительно слушает переданный сигнал. Он не прерывает синхронный цикл, обычный promise с игнорируемым аргументом, уже отправленную сервером команду или запись, которая успела зафиксироваться до отмены. Для базы данных, очереди и внешнего сервиса нужен их собственный протокол: отмена запроса, дедлайн, идемпотентный ключ или компенсационное действие.</p>\n<p>Отмена также не равна откату. Клиент может прекратить ждать тело ответа, а сервер уже успеть списать деньги, создать задачу или записать событие. Поэтому границу побочных эффектов проверяют на стороне исполнителя. Для повторных запусков добавляют идемпотентность и корреляционный идентификатор; для диагностики логируют начало, отмену, успешное завершение и причину отказа каждой операции.</p>\n<pre><code>async function cancellableStep(signal) {\n  if (signal.aborted) {\n    throw signal.reason ?? new Error('cancelled before start');\n  }\n\n  return new Promise((resolve, reject) =&gt; {\n    const timer = setTimeout(() =&gt; resolve('done'), 100);\n    signal.addEventListener('abort', () =&gt; {\n      clearTimeout(timer);\n      reject(signal.reason ?? new Error('cancelled'));\n    }, { once: true });\n  });\n}\n\nconst controller = new AbortController();\nconst work = cancellableStep(controller.signal);\ncontroller.abort(new Error('caller no longer needs the result'));\n\nawait work.catch((error) =&gt; console.log(error.message));\n// caller no longer needs the result</code></pre>\n<p>Этот фрагмент показывает минимальный контракт для собственной операции: она проверяет сигнал до старта, слушает событие во время ожидания и освобождает таймер при отмене. Для реальной работы нужно также снять обработчик после обычного завершения, закрыть ресурс и отдельно решить, что делать с уже выполненным побочным эффектом.</p>\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>Общий <code>catch</code> сработал, но поздний лог продолжается</td><td>Другой вход ещё выполняется</td><td>Добавить <code>started</code>, <code>fulfilled</code>, <code>rejected</code> и <code>cancelled</code> с request id</td><td>Разделить исход aggregate и жизненный цикл операции</td></tr><tr><td>Результаты «перепутались»</td><td>Сопоставили скорость завершения с позицией массива</td><td>Вывести имя входа и его индекс</td><td>Читать массив по позиции или возвращать объект с ключом</td></tr><tr><td>Видна только одна ошибка</td><td>Выбран fail-fast отчёт</td><td>Проверить, нужен ли полный список статусов</td><td>Для независимых входов рассмотреть <code>allSettled</code></td></tr><tr><td>После отказа лишние запросы расходуют ресурс</td><td>Операции не получили общий сигнал</td><td>Проверить сигнатуру API и тест отмены</td><td>Передать <code>AbortSignal</code> или реализовать собственный cancel contract</td></tr><tr><td>После abort данные всё равно изменились</td><td>Серверный эффект уже произошёл</td><td>Сверить корреляционный id с журналом исполнителя</td><td>Добавить идемпотентность или компенсацию, а не обещать откат</td></tr></tbody></table>\n<h2>Воспроизводимая проверка перед изменением кода</h2>\n<ol><li>Перечислите входные promise и реальную операцию за каждым из них.</li><li>Зафиксируйте требование: нужны все значения, все статусы, первый успех или только ограничение времени ожидания.</li><li>Запустите детерминированную трассировку с одной ранней ошибкой и двумя поздними завершениями.</li><li>Проверьте порядок массива отдельно от порядка логов: эти последовательности отвечают на разные вопросы.</li><li>Если требуется остановка, найдите API отмены и передайте сигнал до старта операции.</li><li>Напишите отрицательный тест: один вход отклоняется, а остальные либо получают отмену, либо честно продолжают работу по задокументированному контракту.</li><li>Проверьте побочный эффект на стороне исполнителя. Клиентский отказ promise не доказывает, что сервер забыл уже принятую команду.</li><li>Только после этого выберите <code>Promise.all</code>, <code>Promise.allSettled</code>, <code>race</code> или <code>any</code>.</li></ol>\n<h2>Границы применимости</h2>\n<p>Promise — это модель будущего значения и его исхода, а не поток и не диспетчер ресурсов. Из самого факта совместного запуска нельзя вывести число потоков, порядок сетевых пакетов, освобождение соединения или нагрузку на сервер. Эти свойства определяются средой исполнения и конкретным API.</p>\n<p>Ранний отказ aggregate подходит, когда зависимый следующий шаг больше нельзя выполнять с неполным набором данных. Он не подходит как единственный механизм остановки дорогих независимых задач. <code>allSettled</code> полезен для отчёта о независимых результатах, но не превращает ошибки в успех и не скрывает необходимость очистки.</p>\n<p>Пример с <code>fetch</code> применим к операциям, которые принимают <code>AbortSignal</code>. Пример с собственной функцией применим только после того, как операция реально проверяет сигнал и освобождает свой ресурс. Для CPU-bound вычисления, транзакции и внешней очереди нужны отдельные ограничения и тесты.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://tc39.es/ecma262/2025/multipage/control-abstraction-objects.html#sec-promise.all' target='_blank' rel='noopener noreferrer'>ECMAScript 2025 Language Specification: Promise.all</a> — нормативное описание успешного результата по позициям и отказа aggregate при отказе входа.</li><li><a href='https://tc39.es/ecma262/2025/multipage/control-abstraction-objects.html#sec-promise.allsettled' target='_blank' rel='noopener noreferrer'>ECMAScript 2025 Language Specification: Promise.allSettled</a> — нормативное описание ожидания всех входов и массива статусов.</li><li><a href='https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all' target='_blank' rel='noopener noreferrer'>MDN: Promise.all()</a> — практическое описание порядка значений, fail-fast поведения и отличия от <code>allSettled</code>.</li><li><a href='https://developer.mozilla.org/en-US/docs/Web/API/AbortController' target='_blank' rel='noopener noreferrer'>MDN: AbortController</a> — контракт контроллера и сигнала для отмены поддерживаемых асинхронных операций.</li><li><a href='https://fetch.spec.whatwg.org/#abortcontroller-abort' target='_blank' rel='noopener noreferrer'>WHATWG Fetch Standard: abort()</a> — спецификация поведения abort в Fetch API.</li></ul>\n<p>Итоговая проверка проста: назовите promise, который отклоняет aggregate; назовите работу, которая может продолжиться; назовите владельца сигнала; покажите тест, подтверждающий остановку или её отсутствие. Если на последний вопрос отвечают только «сработал <code>catch</code>», в коде смешаны два разных контракта.</p>"
+}
diff --git a/editorial/agent-rewrites/081.json b/editorial/agent-rewrites/081.json
index 3141d1f..62766dd 100644
--- a/editorial/agent-rewrites/081.json
+++ b/editorial/agent-rewrites/081.json
@@ -2,6 +2,6 @@
   "index": 81,
   "slug": "editorial-2025-10-practice-teaching-engineering",
   "title": "Promise.all не отменяет работу: как объяснить границу и проверить её",
-  "excerpt": "Promise.all объединяет результаты асинхронных операций, но не управляет их остановкой. Разбираем модель, контрпример, проверку и отдельный контракт отмены.",
-  "contentHtml": "<p>Симптом появляется после первой же ошибки: один запрос отклонился, обработчик получил исключение, а соседние запросы продолжают выполняться. В логах уже виден общий отказ, но база данных, сетевой клиент или внешний сервис ещё получают работу. Цена ошибки — лишний трафик, ненужные записи, гонки при очистке и неверное сообщение пользователю. Если эту границу объяснить неточно, команда начнёт искать отмену в месте, которое умеет только ждать.</p>\n<p>Тезис простой: <code>Promise.all</code> описывает исход группы promises, а не жизненный цикл операций, которые за ними стоят. Aggregate promise может отклониться на первой ошибке. Остальные входы при этом не получают приказ остановиться. Значит, ожидание и отмена — два разных контракта. Их нужно проектировать и проверять раздельно.</p>\n<h2>Модель: что именно объединяет Promise.all</h2>\n<p>Представьте два входа: <code>left</code> и <code>right</code>. Каждый из них обещает значение в будущем. Вызов <code>Promise.all([left, right])</code> создаёт третий promise. Он становится успешным, когда все входы успешны, и отклоняется, когда один вход отклоняется. При успехе значения идут в том же порядке, что и входы.</p>\n<p>Третий promise не владеет внутренней работой <code>left</code> и <code>right</code>. Он наблюдает их состояния и сообщает общий результат. Если <code>left</code> завершился ошибкой, aggregate promise может завершиться сразу. Уже начатый <code>right</code> не обязан завершаться в тот же момент. Если <code>right</code> сам изменяет состояние внешней системы, наблюдение за ним не откатывает это изменение.</p>\n<figure><img src='/assets/editorial/2025/teaching-engineering-2025-model-exercise-check.svg' alt='Схема: два входных promise сходятся в общий результат, а отмена остаётся отдельным контрактом' loading='lazy' /><figcaption>Общий promise сообщает результат группы. Отдельный сигнал отмены управляет конкретной операцией, если такой сигнал предусмотрен её API.</figcaption></figure>\n<h2>Минимальный пример с видимым порядком событий</h2>\n<p>Учебный пример ниже не обращается к сети, файлам или базе. Он вручную завершает второй promise после того, как общий promise уже отклонился. Так видна только семантика ожидания. Пример не доказывает, что какой-либо реальный клиент продолжит работу именно с такой задержкой.</p>\n<pre><code>let finishRight;\n\nconst right = new Promise((resolve) =&gt; {\n  finishRight = () =&gt; {\n    console.log('right finished');\n    resolve('cache value');\n  };\n});\n\nconst combined = Promise.all([\n  Promise.reject(new Error('left failed')),\n  right,\n]).catch(() =&gt; {\n  console.log('combined rejected');\n});\n\nawait combined;\nfinishRight();\nawait right;</code></pre>\n<p>Сначала появится <code>combined rejected</code>. Затем появится <code>right finished</code>. Это не означает, что aggregate promise «забыл» второй вход. Он уже сообщил общий отказ, но второй вход всё ещё может перейти в состояние fulfilled. Ожидание результата группы не стало командой отмены.</p>\n<p>Важна и другая деталь. <code>Promise.all</code> не создаёт сами операции. К моменту вызова promises часто уже запущены: функция вернула promise, сетевой запрос уже отправлен, чтение уже поставлено в очередь. Обёртка видит результат этой работы, но не получает универсального доступа к её внутренним ресурсам.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class='table-scroll'><table><caption>Диагностика ошибок вокруг Promise.all</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>Aggregate promise сообщает отказ, но не отменяет вход</td><td>Добавить отдельные метки старта и завершения каждой операции</td><td>Решить, нужна ли отмена, и передать сигнал в API операции</td></tr><tr><td>Код ловит общий отказ и считает работу законченной</td><td>Смешаны состояние aggregate promise и состояние ресурсов</td><td>Проверить, что происходит с каждым входом после <code>catch</code></td><td>Дождаться нужных cleanup-действий или описать их отдельный контракт</td></tr><tr><td>Пользователь нажал «отмена», но запрос продолжился</td><td>Кнопка меняет интерфейс, а сигнал не дошёл до транспорта</td><td>Проверить прохождение <code>AbortSignal</code> до вызова API</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></div>\n<h2>Как выглядит отдельная отмена</h2>\n<p>Отмена появляется только там, где её поддерживает исполнитель. Для браузерного <code>fetch</code> обычно передают <code>AbortSignal</code>, полученный от <code>AbortController</code>. Контроллер не превращает любой promise в отменяемый. Он передаёт сигнал в конкретный API, а API решает, как остановить или прервать свою работу.</p>\n<pre><code>const controller = new AbortController();\n\nconst requests = [\n  fetch('/api/profile', { signal: controller.signal }),\n  fetch('/api/limits', { signal: controller.signal }),\n];\n\ntry {\n  const responses = await Promise.all(requests);\n  // Обрабатываем ответы только после успеха всей группы.\n} catch (error) {\n  if (error.name === 'AbortError') {\n    // Это отдельный путь отмены, а не обычная ошибка данных.\n  }\n  throw error;\n}\n\n// Вызывается по явному решению приложения, например по кнопке.\ncontroller.abort();</code></pre>\n<p>В этом фрагменте есть важное ограничение: вызов <code>abort()</code> стоит после <code>try</code> только для наглядности механизма. В рабочем коде его вызывают из отдельного события или политики таймаута. Если один <code>fetch</code> уже успел изменить серверное состояние, прекращение ожидания ответа не отменит это изменение. Для серверной операции нужен серверный контракт: ключ идемпотентности, отмена задания, транзакция или компенсационное действие.</p>\n<p>Не следует использовать контроллер как универсальный откат. Он помогает остановить поддерживаемую передачу данных. Он не возвращает уже отправленный платёж, не удаляет запись и не отменяет произвольную функцию, которая просто вернула promise.</p>\n<h2>Положительный и отрицательный пути</h2>\n<p>Положительный путь начинается с успешных входов. Тогда aggregate promise возвращает массив значений в порядке входного массива. Это удобно, когда зависимый код может начать работу только после получения всех значений. Проверка должна подтвердить не только наличие двух ответов, но и соответствие позиции: первый результат относится к первому входу.</p>\n<p>Отрицательный путь начинается с отклонения одного входа. Aggregate promise сообщает ошибку, но у приложения остаются вопросы. Нужно ли дождаться остальных результатов? Нужно ли отменить их? Можно ли показать частичные данные? Нужна ли компенсация побочного эффекта? На эти вопросы <code>Promise.all</code> не отвечает. Если нужен итог каждого входа, включая ошибки, применяют <code>Promise.allSettled</code>. Если нужна остановка, добавляют API отмены. Если нужна повторная попытка, описывают её лимит и область действия отдельно.</p>\n<p>Отдельно проверяйте поздние события. Отмена может прийти после ответа сервера. Таймаут может сработать после записи на сервере. Первый отказ может появиться раньше, чем второй запрос заметит закрытый сигнал. Обработчик должен различать «мы перестали ждать», «транспорт получил отмену» и «внешняя операция действительно прекратилась». Это три разных наблюдения.</p>\n<h2>Порядок проверки</h2>\n<ol><li>Опишите каждую операцию отдельно: что она читает, что меняет и какой ресурс должен остановиться.</li><li>Зафиксируйте ожидаемый общий результат: все значения, первая ошибка или полный набор исходов.</li><li>Запустите два входа с разными задержками и запишите отдельные события старта, отказа, завершения и отмены.</li><li>Проверьте сценарий, в котором первый вход отклоняется, а второй завершается позже.</li><li>Если нужна отмена, передайте поддерживаемый сигнал в каждый исполнитель и проверьте его получение.</li><li>Проверьте поздний ответ после отмены: он не должен менять UI или состояние, если операция уже устарела.</li><li>Проверьте побочные эффекты отдельно: отмена ожидания не должна называться откатом без подтверждения внешней системы.</li></ol>\n<h2>Ограничения модели</h2>\n<p>Эта модель объясняет семантику группы promises, но не задаёт политику приложения. Она не решает, какой запрос важнее, как долго ждать, сколько раз повторять и как сообщать частичный результат. Для этих решений нужны отдельные правила и наблюдаемые сигналы.</p>\n<p>Она также не заменяет документацию конкретной библиотеки. Один клиент может поддерживать <code>AbortSignal</code>, другой — собственный метод отмены, третий — только закрытие соединения. Нельзя переносить поведение одного транспорта на другой по одному имени promise.</p>\n<p>Учебный код с ручным <code>finishRight</code> показывает порядок переходов в памяти. Он не является нагрузочным тестом, не измеряет задержки и не подтверждает поведение production-системы. В реальном сервисе проверяйте контракт библиотеки, логи транспорта и состояние внешнего ресурса.</p>\n<h2>Критерий готовности</h2>\n<p>Объяснение и код готовы, если читатель может ответить на четыре вопроса без догадки: какой promise сообщает общий результат, что происходит с остальными входами после первой ошибки, какой объект или API действительно принимает отмену и что происходит с уже выполненным побочным эффектом. В проверочном запуске должны быть видны отдельные события для aggregate promise и каждой операции. Для сценария отмены нужно подтвердить получение сигнала исполнителем, а для серверного изменения — отдельное подтверждение остановки или компенсации.</p>\n<p>Если на вопрос об остановке отвечают только названием <code>Promise.all</code>, объяснение не готово. Добавьте контрпример и укажите владельца отмены. Если такого владельца нет, честный результат звучит так: общий promise отклонился, а начатая работа может продолжиться.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://ecma-international.org/wp-content/uploads/ECMA-262_16th_edition_june_2025.pdf' target='_blank' rel='noopener noreferrer'>ECMA-262, 16th edition, §27.2.4.1 Promise.all</a> — спецификация описывает общий promise, обработку входного iterable и отклонение через reject capability. Она не задаёт отмену внешней работы.</li><li><a href='https://raw.githubusercontent.com/mdn/content/3fad0447b4901e28fe88769976787d8d8b87d66d/files/en-us/web/javascript/reference/global_objects/promise/all/index.md' target='_blank' rel='noopener noreferrer'>MDN Web Docs: Promise.all(), commit 3fad0447</a> — справочное описание успешного результата, первой ошибки и отличия от <code>Promise.allSettled()</code>.</li></ul>"
+  "excerpt": "Promise.all объединяет исходы асинхронных операций, но не управляет их остановкой. Разбираем порядок результатов, контрпример, AbortSignal и проверку, которую можно воспроизвести локально.",
+  "contentHtml": "<p>Симптом появляется после первой же ошибки: один запрос отклонился, обработчик попал в <code>catch</code>, а соседний запрос продолжил выполняться. В логах уже виден общий отказ, но сетевой клиент, чтение файла или внешний сервис ещё получает работу. Цена ошибки — лишний трафик, гонка за общим состоянием и сообщение пользователю, которое не совпадает с реальным состоянием ресурсов.</p>\n<p>Главная граница такова: <code>Promise.all</code> сообщает исход группы promises, но не является командой остановки. Aggregate promise отклоняется при первом отклонении входа, однако остальные входы не получают от этого сигнала отмены. Поэтому в объяснении нужно разделять три вещи: исход aggregate, исход каждого входного promise и состояние внешней операции, которая за ним стоит.</p>\n<h2>Что именно объединяет Promise.all</h2>\n<p>Вызов <code>Promise.all(iterable)</code> создаёт новый promise. Если каждый элемент iterable успешно завершился, новый promise получает массив значений. Позиции массива соответствуют позициям входов, а не скорости их завершения. Если один вход отклоняется, aggregate отклоняется с причиной этого отклонения и больше не ждёт успешного результата группы.</p>\n<p>При этом <code>Promise.all</code> не запускает отмену и не откатывает побочные эффекты. К моменту вызова функции вроде <code>fetchProfile()</code> или <code>readFile()</code> работа обычно уже началась. Комбинатор добавляет обработчики к полученным promises и собирает их исходы; у него нет универсального доступа к сокету, таймеру, файловому дескриптору или транзакции.</p>\n<figure><img src='/assets/editorial/2025/teaching-engineering-2025-misconception-matrix.svg' alt='Матрица: aggregate promise отклонён, оставшийся вход имеет собственный исход, а внешняя операция требует отдельного контракта отмены' loading='lazy' /><figcaption>Схема разделяет уровень aggregate, оставшийся вход и внешнюю операцию. Из красной колонки нельзя делать вывод об остановке без отдельного API.</figcaption></figure>\n<h2>Контрпример с воспроизводимым порядком</h2>\n<p>Сначала проверим только семантику promises, без сети и базы данных. Первый вход отклоняется сразу, второй вручную завершается позднее. Запустите фрагмент в Node.js с поддержкой ES-модулей: команда не требует пакетов и показывает два независимых события.</p>\n<pre><code>node --input-type=module &lt;&lt;'EOF'\nlet finishRight;\n\nconst right = new Promise((resolve) =&gt; {\n  finishRight = () =&gt; {\n    console.log('right fulfilled');\n    resolve('cache value');\n  };\n});\n\nconst combined = Promise.all([\n  Promise.reject(new Error('left failed')),\n  right,\n]).catch(() =&gt; {\n  console.log('aggregate rejected');\n});\n\nawait combined;\nfinishRight();\nawait right;\nEOF</code></pre>\n<p>Ожидаемый вывод: сначала <code>aggregate rejected</code>, затем <code>right fulfilled</code>. Второй promise не «забыт»: у него остаётся собственный обработчик и возможность перейти из pending в fulfilled. Пример не имитирует поведение сетевого транспорта и не измеряет освобождение ресурсов. Он доказывает более узкую границу: отклонение результата группы не меняет состояние другого promise.</p>\n<p>Порядок значений проверяется отдельно. Если быстрый запрос стоит вторым, он всё равно попадёт во вторую позицию успешного массива. Поэтому при деструктуризации вроде <code>const [profile, limits] = await Promise.all([...])</code> порядок массива должен быть закреплён тестом или заменён явными ключами.</p>\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><code>catch</code> сработал, а поздний лог продолжился</td><td>Aggregate уже отклонён, другой вход ещё выполняется</td><td>Добавить метки старта и завершения для каждого входа</td><td>Не называть общий отказ отменой; найти API остановки</td></tr><tr><td>Результаты перепутались</td><td>Порядок входного iterable принят за порядок завершения</td><td>Записать имя операции рядом с индексом результата</td><td>Закрепить порядок или возвращать объект с ключами</td></tr><tr><td>Видна только одна ошибка</td><td><code>Promise.all</code> сообщает первый отказ, а не полный отчёт</td><td>Проверить, нужен ли исход каждого входа</td><td>Для полного отчёта рассмотреть <code>Promise.allSettled</code></td></tr><tr><td>После ошибки соседний <code>fetch</code> продолжился</td><td>Запрос не получил сигнал или исполнитель его не поддерживает</td><td>Проверить передачу <code>signal</code> до транспорта</td><td>Передать общий <code>AbortSignal</code> и проверить событие отмены</td></tr><tr><td>После отмены серверная запись осталась</td><td>Остановлено ожидание ответа, а не уже выполненный побочный эффект</td><td>Проверить состояние на сервере отдельным запросом</td><td>Использовать идемпотентность, транзакцию или компенсацию</td></tr></tbody></table></div>\n<h2>Положительный путь и полный отчёт</h2>\n<p>Для независимых чтений <code>Promise.all</code> подходит, когда следующий шаг требует всех значений. Например, экран можно построить только после получения профиля и лимитов. Вызовы функций ставят работу в очередь до ожидания aggregate: <code>Promise.all([loadProfile(), loadLimits()])</code>. Передача самих функций — ошибка: <code>Promise.all([loadProfile, loadLimits])</code> передаст обычные значения-функции, а не результаты их вызова.</p>\n<p>Если нужны все исходы, включая ошибки, выбирайте другой контракт. <code>Promise.allSettled</code> ждёт, пока каждый вход завершится, и возвращает для каждого статус <code>fulfilled</code> или <code>rejected</code>. Это не добавляет отмену и не делает операции безопаснее; метод лишь меняет то, когда и в каком виде приложение получает отчёт.</p>\n<p>Если работы зависят друг от друга, не следует искусственно объединять их в один массив. Последовательный код с отдельными проверками может быть понятнее и дешевле: сначала получить идентификатор, затем запросить данные по нему. Параллельный запуск оправдан только для действительно независимых операций и при принятом риске их одновременного выполнения.</p>\n<h2>Отмена живёт у исполнителя</h2>\n<p>Отмена появляется там, где конкретный исполнитель принимает сигнал. Для браузерного <code>fetch</code> это обычно <code>AbortController</code> и его <code>signal</code>. Один контроллер можно передать нескольким запросам. Вызов <code>abort()</code> отправит сигнал каждому поддерживаемому запросу, но не превратит произвольную функцию, таймер или уже выполненную запись в отменяемую операцию.</p>\n<pre><code>async function loadDashboard() {\n  const controller = new AbortController();\n  const { signal } = controller;\n\n  const json = (url) =&gt; fetch(url, { signal }).then((response) =&gt; {\n    if (!response.ok) {\n      throw new Error(url + ': HTTP ' + response.status);\n    }\n    return response.json();\n  });\n\n  try {\n    return await Promise.all([\n      json('/api/profile'),\n      json('/api/limits'),\n    ]);\n  } catch (error) {\n    controller.abort();\n    throw error;\n  }\n}</code></pre>\n<p>Здесь вторая проверка намеренная. <code>fetch</code> обычно выполняется успешно на уровне promise даже при HTTP 404 или 500: сервер ответил, поэтому нужно самостоятельно проверить <code>response.ok</code> или <code>response.status</code>. Если проверка обнаружит HTTP-ошибку, <code>catch</code> вызовет <code>abort()</code> для ещё работающего соседа.</p>\n<p>Фрагмент гарантирует только контракт поддерживаемых <code>fetch</code>-запросов. Успевший запрос может уже получить ответ до вызова <code>abort()</code>. Сервер мог принять данные до отмены клиента. Поэтому «клиент перестал ждать» и «сервер отменил действие» — разные результаты, которые проверяются разными наблюдениями.</p>\n<p>Сигнал нельзя повторно использовать как возобновляемый ресурс: после отмены он остаётся aborted, а новый запрос с ним будет отклонён. Для нового запуска создайте новый контроллер. Таймаут можно выразить через <code>AbortSignal.timeout(milliseconds)</code>, но проверьте поддержку в целевых браузерах и отдельно обработайте причину таймаута, если интерфейсу нужно отличать её от действия пользователя.</p>\n<h2>Как проверить границу в своём коде</h2>\n<p>Проверка должна наблюдать не только состояние aggregate. Для каждого входа запишите имя операции, время старта, время завершения, причину отказа и факт получения сигнала. Если операция меняет внешний ресурс, добавьте проверку состояния ресурса после отказа. Лог «<code>Promise.all</code> отклонён» сам по себе доказывает только исход aggregate.</p>\n<ol><li>Назовите каждую операцию и запишите, читает ли она данные, меняет состояние или делает и то и другое.</li><li>Определите ожидаемый контракт: все успешные значения, первый отказ, полный набор статусов или отмена оставшихся операций.</li><li>Запустите два входа с разными задержками и сохраните отдельные события старта, отказа и завершения.</li><li>Проверьте отрицательный путь: первый вход отклоняется, второй завершается позже и не получает автоматической команды остановиться.</li><li>Если нужна отмена, передайте сигнал в каждый поддерживаемый исполнитель до запуска и вызовите <code>abort()</code> из явной политики: кнопки, таймаута или обработчика ошибки.</li><li>Проверьте, что обработчик отличает обычную ошибку, <code>AbortError</code> и таймаут, если среда предоставляет разные причины.</li><li>Проверьте поздний результат: устаревший ответ не должен перезаписывать новый экран или новое состояние.</li><li>Для побочного эффекта запросите подтверждение внешней системы; не заменяйте его фактом отмены клиентского ожидания.</li></ol>\n<h2>Ограничения применимости</h2>\n<p>Эта модель описывает стандартный combinator, а не политику приложения. Она не решает, сколько запросов можно выполнять одновременно, сколько раз повторять ошибку, что показывать при частичных данных и кто владеет отменой. Эти правила должны быть явными в коде и тестах.</p>\n<p><code>Promise.all</code> не означает параллельные потоки. JavaScript-движок и конкретный API сами определяют, как выполняется работа. Из успешного aggregate нельзя вывести пропускную способность, порядок сетевых пакетов или момент освобождения соединения. Для таких утверждений нужны метрики и документация транспорта.</p>\n<p>Отмена не равна откату. Она может прекратить поддерживаемый <code>fetch</code>, чтение тела ответа или поток, но не возвращает уже отправленный платёж, не удаляет запись и не отменяет произвольную синхронную функцию. Серверную операцию защищают отдельные механизмы: идемпотентный ключ, транзакция, отменяемое задание или компенсационное действие.</p>\n<p>Пример с ручным <code>finishRight</code> проверяет переходы promises в памяти. Пример с <code>fetch</code> проверяет передачу сигнала клиентскому API, но не гарантирует поведение конкретного прокси или сервера. Для старого браузера, Node.js или библиотеки с собственным клиентом сверяйте документацию именно этой версии.</p>\n<h2>Критерий готовности объяснения</h2>\n<p>Материал и реализация готовы, если читатель может ответить на четыре вопроса: какой promise сообщает общий результат; что делает другой вход после первой ошибки; какой объект или API реально принимает отмену; что происходит с уже выполненным побочным эффектом. В тестовом запуске должны быть видны отдельные события aggregate и каждой операции.</p>\n<p>Минимальный набор проверок содержит положительный сценарий с массивом значений, отрицательный сценарий с поздним входом и сценарий с поддерживаемым <code>AbortSignal</code>. Если доказательством остановки служит только <code>catch</code>, проверка неполна. Честный вывод в таком случае: aggregate отклонён, а начатая работа может продолжиться.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise.all' target='_blank' rel='noopener noreferrer'>ECMAScript Language Specification: Promise.all</a> — нормативный алгоритм создания aggregate promise, успешного массива значений и отклонения с причиной первого отказа.</li><li><a href='https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all' target='_blank' rel='noopener noreferrer'>MDN Web Docs: Promise.all()</a> — порядок значений, fail-fast-поведение, отличие от <code>Promise.allSettled()</code> и прямое указание, что отклонение не отменяет оставшиеся операции.</li><li><a href='https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal' target='_blank' rel='noopener noreferrer'>MDN Web Docs: AbortSignal</a> — передача сигнала в <code>fetch</code>, одноразовость сигнала, <code>AbortSignal.timeout()</code> и обработка причин отмены.</li><li><a href='https://developer.mozilla.org/en-US/docs/Web/API/Window/fetch' target='_blank' rel='noopener noreferrer'>MDN Web Docs: Window.fetch()</a> — promise <code>fetch</code> не отклоняется из-за HTTP-статуса сам по себе; статус нужно проверять через <code>Response.ok</code> или <code>Response.status</code>.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/082.json b/editorial/agent-rewrites/082.json
index 9da236c..8ca3794 100644
--- a/editorial/agent-rewrites/082.json
+++ b/editorial/agent-rewrites/082.json
@@ -2,6 +2,6 @@
   "index": 82,
   "slug": "editorial-2025-09-field-engineering-interviews",
   "title": "Как калибровать техническое интервью по фактам, а не по впечатлению",
-  "excerpt": "Два reviewer-а могут прочитать один технический ответ по-разному. Разбираем, как найти первую точку расхождения на synthetic-пробе, проверить её и остановить опасный переход от учебной записи к выводу о человеке.",
-  "contentHtml": "<p>Два reviewer-а читают один технический ответ. Один видит аккуратную гипотезу. Другой — недостаток глубины. Через пять минут спор уже идёт о впечатлении, а не о тексте. В журнале нет ссылки на строку, где началось расхождение.</p>\n<p>Цена ошибки высока. Команда меняет rubric после самого громкого мнения. Кандидат или сотрудник получает вывод, который нельзя проверить. Следующий review повторяет тот же спор. Калибровка не исправляет это обсуждением в конце встречи. Она должна сначала зафиксировать одинаковый вход, независимые факты и границу того, чего проба не показывает.</p>\n<p><strong>Тезис:</strong> технический review калибруется через цепочку «наблюдение → неизвестное → интерпретация → следующий запрос». Reviewer-ы не обязаны прийти к одинаковой интерпретации. Они обязаны показать, на каких фактах она стоит и где заканчивается evidence. Если в записи появляется score, ranking или вывод о личности, процесс должен остановиться.</p>\n<h2>Механизм: разделить факт и объяснение</h2>\n<p>Возьмём учебную карточку с ответом на вопрос об устаревшем API-ответе. В тексте есть <code>max-age=0</code>, маршрут <code>/v1/report</code> и описание симптома. Правило origin-сервера не указано. Это намеренный пробел. Он позволяет проверить, умеет ли reviewer отделить видимое от неизвестного.</p>\n<p>Observation отвечает только на вопрос «что видно в sample?». Например: «В заголовке указан <code>max-age=0</code>». Unknown отвечает на вопрос «чего здесь нет?»: «Правило, по которому origin формирует cache-control, не показано». Interpretation связывает эти записи: «Нужен запрос правила origin; изменение cache policy пока не доказано». Такой порядок не запрещает гипотезы. Он не даёт гипотезе притвориться фактом.</p>\n<table><thead><tr><th>Слой</th><th>Допустимая запись</th><th>Запрещённый скачок</th></tr></thead><tbody><tr><td>Observation</td><td>В sample есть <code>max-age=0</code>.</td><td>«Сервис неправильно настроен».</td></tr><tr><td>Unknown</td><td>Origin rule не показано.</td><td>«Автор не понимает кеширование».</td></tr><tr><td>Interpretation</td><td>Нужно запросить правило origin.</td><td>«Reviewer B глубже разобрался».</td></tr><tr><td>Hand-off</td><td>Запросить один отсутствующий факт.</td><td>Создать score, ranking или hiring outcome.</td></tr></tbody></table>\n<p>Независимость нужна до обсуждения. Каждый reviewer получает тот же <code>sampleId</code>, ту же role rubric и те же критерии. Он сначала пишет факты и неизвестные, затем интерпретацию. Если начать с общей беседы, участники быстро выровняют формулировки, но потеряют момент, где они увидели разное.</p>\n<h2>Конкретный пример: безопасный hand-off</h2>\n<p>Ниже — учебный TypeScript-подобный код. Он работает с объектом в памяти. Он не обращается к сети, не пишет файл и не создаёт оценку человека. В production этот пример ничего не доказывает.</p>\n<pre><code>type ReviewRecord = {\n  sampleId: string;\n  criterionId: string;\n  evidenceRef: string;\n  kind: 'observation' | 'unknown' | 'interpretation' | 'hand-off';\n  text: string;\n};\n\nfunction acceptHandOff(record: ReviewRecord) {\n  const safePrefix = 'hand-off:';\n  const forbidden = /score|ranking|hiring|person|candidate/i;\n\n  if (record.kind !== 'hand-off' || !record.text.startsWith(safePrefix)) {\n    return { accepted: false, action: 'stop-and-repair-boundary' };\n  }\n  if (forbidden.test(record.text)) {\n    return { accepted: false, action: 'stop-and-repair-boundary' };\n  }\n  return { accepted: true, action: 'request-missing-evidence' };\n}\n\nconst next = acceptHandOff({\n  sampleId: 'api-cache-fixed-v1',\n  criterionId: 'evidence-boundary',\n  evidenceRef: 'sample.headers.cache-control',\n  kind: 'hand-off',\n  text: 'hand-off: request the origin cache rule',\n});</code></pre>\n<p>Вызов возвращает учебный запрос недостающего evidence. Он не разрешает менять конфигурацию. Ветка с текстом <code>hiring: reject</code> должна вернуть <code>stop-and-repair-boundary</code>. Это отрицательный путь, а не дополнительная функция: он показывает, что процесс заметил незаконное расширение задачи.</p>\n<p>Проверять нужно не только результат функции. Сверьте четыре поля: один <code>sampleId</code>, существующий <code>evidenceRef</code>, применимый <code>criterionId</code> и допустимый тип hand-off. Пустая ссылка, общий ярлык или другой sample делают запись непроверяемой. В таком случае правильное действие — остановка, а не попытка угадать недостающий факт.</p>\n<figure><img src=\"/assets/editorial/2025/engineering-interviews-2025-evidence-review-loop.svg\" alt=\"Цикл калибровки synthetic-пробы: независимые observation, interpretation, журнал расхождений и ограниченный hand-off\"><figcaption>Учебный цикл возвращает неопределённость в проверяемый запрос. Стрелка stop блокирует personal outcome и production effect.</figcaption></figure>\n<h2>Симптомы и действия</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Reviewer-ы спорят о «глубине».</td><td>Критерий не описывает наблюдаемое поведение.</td><td>Найдите строку sample, на которую ссылается каждый.</td><td>Сузьте criterion до проверяемого признака.</td></tr><tr><td>Оба reviewer-а используют одинаковые слова, но делают разные выводы.</td><td>Они смешали observation и interpretation.</td><td>Перепишите записи в два отдельных поля.</td><td>Запросите недостающий факт вместо решения.</td></tr><tr><td>В hand-off появляется score или ranking.</td><td>Учебная проба пересекла границу оценки человека.</td><td>Проверьте текст и допустимые типы записи.</td><td>Верните <code>stop-and-repair-boundary</code>; не сохраняйте outcome.</td></tr><tr><td>После калибровки меняют сразу sample, rubric и инструкцию.</td><td>Нельзя понять, что исправило расхождение.</td><td>Сопоставьте первую непарную запись с изменённым артефактом.</td><td>Измените один артефакт и повторите тот же sample.</td></tr><tr><td>Reviewer просит данные из сети или реального разговора.</td><td>Проба не содержит нужного evidence и маскирует это.</td><td>Проверьте boundary и список разрешённых источников.</td><td>Остановите прогон или замените sample на явно новый учебный кейс.</td></tr></tbody></table>\n<h2>Порядок короткой calibration session</h2>\n<ol><li><strong>Заморозьте вход.</strong> Создайте synthetic sample с идентификатором, фиксированными литералами и описанием того, чего в нём нет.</li><li><strong>Опишите критерий.</strong> Запишите observable behaviour и исключённые измерения. Слова «сильный», «слабый» и «системный» без признака не подходят.</li><li><strong>Раздайте одинаковые условия.</strong> Передайте reviewer-ам один sample, одну rubric и одинаковый порядок чтения. Не начинайте с общей дискуссии.</li><li><strong>Соберите независимые записи.</strong> Каждый reviewer фиксирует observation, unknown и interpretation с ссылками на evidence.</li><li><strong>Найдите первую развилку.</strong> Сначала сравните sample id и факты. Затем сравните criterion. Только после этого обсуждайте interpretation.</li><li><strong>Классифицируйте расхождение.</strong> Разные факты указывают на проблему sample или чтения. Одинаковые факты и разные трактовки указывают на rubric. Разные hand-off указывают на неясную границу действия.</li><li><strong>Измените один артефакт.</strong> Исправьте sample, criterion или инструкцию, но не все сразу. Старую версию оставьте как учебный контрпример без связи с человеком.</li><li><strong>Повторите тот же прогон.</strong> Убедитесь, что прежняя развилка стала видимой, а hand-off по-прежнему не создаёт score, ranking, personal record или production effect.</li></ol>\n<h2>Когда этот метод не подходит</h2>\n<p>Synthetic-проба проверяет процесс чтения и границу доказательства. Она не измеряет производительность инженера, качество найма, способность работать в команде или результат реального проекта. Нельзя переносить её вывод на человека. Нельзя называть отсутствие расхождения доказательством валидности rubric.</p>\n<p>Один fixed sample быстро устаревает. Изменился API, критерий или рабочая задача — изменился и смысл пробы. Набор из нескольких sample требует отдельного дизайна: иначе команда начнёт сравнивать разные задачи как одну шкалу. Если нужен реальный отбор, его должны спроектировать владельцы процесса с учётом применимых требований. Учебный журнал не заменяет такую процедуру.</p>\n<p>Метод также не спасает от плохого критерия. Если criterion требует «понять намерение автора», его нельзя проверить ссылкой на текст. Если sample скрывает несколько причин, reviewer-ы будут расходиться по делу, а не из-за плохого review. Сначала уменьшите область утверждения. Потом добавляйте сложность.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Сессия готова, если независимые записи можно открыть без устного пояснения и ответить на четыре вопроса: какой sample читали; какой факт увидели; какое неизвестное осталось; почему hand-off разрешён или остановлен. Для каждого расхождения указан один артефакт, который изменили. Повторный прогон использует тот же идентификатор пробы и не создаёт score, ranking, personal outcome, сетевой запрос или production effect.</p>\n<p>Минимальная проверка — прогнать положительную и отрицательную ветки. Положительная ветка принимает только hand-off с ссылкой на существующий evidence и запросом одного недостающего факта. Отрицательная ветка отклоняет текст с оценкой человека, невалидную ссылку и неизвестный критерий. Если хотя бы одна ветка проходит без явного результата, материал не готов к использованию даже как учебный пример.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.opm.gov/policy-data-oversight/assessment-and-selection/structured-interviews\" target=\"_blank\" rel=\"noopener\">U.S. Office of Personnel Management: Structured Interviews</a> — официальное описание одинаковых вопросов, шкалы и стандартов оценки; источник не подтверждает эту учебную модель и не заменяет требования конкретной организации.</li><li><a href=\"https://www.eeoc.gov/regulations-and-guidelines\" target=\"_blank\" rel=\"noopener\">U.S. Equal Employment Opportunity Commission: Regulations and Guidelines</a> — официальный каталог, в котором размещены Uniform Guidelines on Employee Selection Procedures; применимость зависит от юрисдикции и процесса.</li></ul>"
+  "excerpt": "Практический разбор калибровки технического интервью: как разделить наблюдение, неизвестное и трактовку, найти первую точку расхождения и не превратить учебную пробу в необоснованный вывод о человеке.",
+  "contentHtml": "<p>Два инженера разбирают один и тот же ответ о протухшем API-кеше. Один пишет: «в заголовке есть <code>max-age=0</code>». Второй сразу заключает: «автор не умеет работать с кешированием». Спор начинается не с текста и не с проверяемого критерия, а с впечатления. Через пять минут команда уже обсуждает, кто из рецензентов «глубже понял» ответ.</p>\n<p>Такая ошибка ломает сам объект калибровки. Учебная проба должна показать, одинаково ли рецензенты читают заданный признак и одинаково ли понимают рубрику. Она не должна тайком превращаться в рейтинг человека. Поэтому сначала фиксируем один вход, затем отделяем наблюдение от неизвестного и только после этого разрешаем трактовку. Любой переход к личностному выводу или решению по человеку — стоп-сигнал.</p>\n<p><strong>Главный вопрос статьи:</strong> как обнаружить первую точку расхождения и вернуть разговор к evidence — конкретному фрагменту, который можно открыть и проверить. Ниже — учебный контракт записи, запускаемый пример на Node.js, таблица диагностики и границы применимости.</p>\n<h2>Симптом: рецензенты спорят не о строке, а о «глубине»</h2>\n<p>Начните с маленькой фиксированной пробы. В ней есть ответ на вопрос об API, один фрагмент заголовка и явно пропущенное правило сервера. Например, в sample указано <code>cache-control: max-age=0</code>, но не показано, кто и по какой конфигурации сформировал этот заголовок. Отсутствующий факт — часть входа, а не приглашение его додумывать.</p>\n<p>Запись первого рецензента может выглядеть так: «<code>sample.headers.cache-control</code> содержит <code>max-age=0</code>; правило origin не представлено; нужно запросить его». Это наблюдение, неизвестное и следующий запрос. Запись «сервис неправильно настроен» уже выходит за пределы пробы: заголовок виден, причина его появления — нет.</p>\n<p>До общей встречи сохраните идентификатор пробы, версию рубрики и ссылки на evidence. Рецензенты читают один и тот же набор и пишут независимо. Если обсуждение начнётся раньше фиксации записей, участники синхронизируют формулировки и сотрут сам момент расхождения.</p>\n<h2>Механизм: четыре разных типа записи</h2>\n<p>Калибровка становится проверяемой, когда у записи есть один тип и одна функция. <em>Observation</em> описывает то, что можно открыть в sample. <em>Unknown</em> называет отсутствующее условие. <em>Interpretation</em> связывает факт с гипотезой, но помечает её как гипотезу. <em>Hand-off</em> передаёт ровно один безопасный запрос на следующий факт.</p>\n<table><thead><tr><th>Тип</th><th>Что хранит</th><th>Пример</th><th>Что нельзя выводить</th></tr></thead><tbody><tr><td>Observation</td><td>Точное наблюдение со ссылкой</td><td><code>sample.headers.cache-control</code> равно <code>max-age=0</code></td><td>Сервис настроен неверно</td></tr><tr><td>Unknown</td><td>Недостающий факт или условие</td><td>Правило origin не показано</td><td>Автор не знает кеширование</td></tr><tr><td>Interpretation</td><td>Гипотеза, привязанная к фактам</td><td>Нужно проверить источник заголовка</td><td>Рецензент умнее другого</td></tr><tr><td>Hand-off</td><td>Один следующий запрос</td><td><code>request: origin cache rule</code></td><td>Score, ranking или решение по человеку</td></tr></tbody></table>\n<p>Здесь «ссылка» — не обязательно URL. Это стабильный путь к полю фикстуры, номер строки ответа или идентификатор артефакта. Ссылка должна приводить к существующему объекту. Пустой ярлык вроде <code>ответ кандидата</code> не позволяет повторить проверку и потому не является evidence.</p>\n<p>Не смешивайте калибровку с оценкой качества самого критерия. Фраза «проверяет системное мышление» недостаточна, пока не описано наблюдаемое действие: например, «называет отсутствующее условие и формулирует следующий безопасный запрос». Сначала проверяем, можно ли увидеть признак в тексте. Потом обсуждаем, нужен ли этот признак для конкретной роли.</p>\n<h2>Контракт hand-off: что разрешено передать дальше</h2>\n<p>Безопасный hand-off имеет четыре обязательных поля: <code>sampleId</code>, <code>criterionId</code>, <code>evidenceRef</code> и короткий текст запроса. Валидатор обязан сверить их со справочниками текущей пробы. Одного префикса <code>hand-off:</code> недостаточно: такой префикс может стоять у любой строки, включая запрещённое решение.</p>\n<p>В этом примере разрешены только два критерия и две ссылки, заранее перечисленные в фикстуре. Проверка возвращает причину отказа, а не бросает её в общий лог. Это позволяет увидеть, почему запись остановилась: неизвестный критерий, отсутствующий evidence или попытка передать личный outcome.</p>\n<figure><img src='/assets/editorial/2025/engineering-interviews-2025-evidence-review-loop.svg' alt='Схема калибровки фиксированной пробы: одинаковый sample проходит независимые наблюдения, затем журнал расхождений и ограниченный hand-off; личностный вывод блокируется' /><figcaption>Сначала фиксируется общий вход, затем сравниваются независимые записи. Неизвестное превращается в запрос доказательства, а выход к решению по человеку блокируется.</figcaption></figure>\n<h2>Воспроизводимый пример на Node.js</h2>\n<p>Скопируйте код в файл <code>calibration.mjs</code> и запустите на Node.js 18 или новее. Пример не обращается к сети, не читает персональные данные и не оценивает реального человека. Он проверяет только форму записи в памяти; это полезная защита границы, но не доказательство валидности интервью.</p>\n<pre><code>const allowedCriteria = new Set(['evidence-boundary', 'next-check']);\nconst allowedEvidence = new Set([\n  'sample.headers.cache-control',\n  'sample.response.api-version',\n]);\nconst forbiddenWords = ['score', 'ranking', 'hiring', 'candidate', 'person'];\n\nfunction validateHandOff(record) {\n  const errors = [];\n  const text = typeof record?.text === 'string' ? record.text : '';\n\n  if (record?.kind !== 'hand-off') errors.push('kind');\n  if (!record?.sampleId) errors.push('sampleId');\n  if (!allowedCriteria.has(record?.criterionId)) errors.push('criterionId');\n  if (!allowedEvidence.has(record?.evidenceRef)) errors.push('evidenceRef');\n  if (!text.startsWith('request: ')) errors.push('request-prefix');\n  if (forbiddenWords.some((word) =&gt; text.toLowerCase().includes(word))) {\n    errors.push('personal-or-decision-outcome');\n  }\n\n  return errors.length === 0\n    ? { accepted: true, action: 'request-missing-evidence', errors: [] }\n    : { accepted: false, action: 'stop-and-repair-boundary', errors };\n}\n\nconst cases = [\n  {\n    name: 'valid request',\n    record: {\n      sampleId: 'api-cache-fixed-v1',\n      criterionId: 'evidence-boundary',\n      evidenceRef: 'sample.headers.cache-control',\n      kind: 'hand-off',\n      text: 'request: origin cache rule',\n    },\n    accepted: true,\n  },\n  {\n    name: 'unknown evidence',\n    record: {\n      sampleId: 'api-cache-fixed-v1',\n      criterionId: 'evidence-boundary',\n      evidenceRef: 'sample.guess.about-author',\n      kind: 'hand-off',\n      text: 'request: origin cache rule',\n    },\n    accepted: false,\n  },\n  {\n    name: 'personal outcome',\n    record: {\n      sampleId: 'api-cache-fixed-v1',\n      criterionId: 'next-check',\n      evidenceRef: 'sample.response.api-version',\n      kind: 'hand-off',\n      text: 'request: candidate ranking',\n    },\n    accepted: false,\n  },\n];\n\nconst results = cases.map(({ name, record, accepted }) =&gt; {\n  const result = validateHandOff(record);\n  return { name, expected: accepted, actual: result.accepted, result };\n});\n\nconsole.log(JSON.stringify(results, null, 2));\nif (results.some(({ expected, actual }) =&gt; expected !== actual)) {\n  process.exitCode = 1;\n}</code></pre>\n<p>Проверка запуска:</p>\n<pre><code>node --check calibration.mjs\nnode calibration.mjs</code></pre>\n<p>Ожидаемый результат — первая запись принята с действием <code>request-missing-evidence</code>, две следующие отклонены с действием <code>stop-and-repair-boundary</code>. Ключевой отрицательный тест — <code>candidate ranking</code>: даже существующие идентификаторы не разрешают передать личный outcome. Если убрать проверку <code>evidenceRef</code> или список запрещённых слов, тесты перестанут охранять заявленную границу.</p>\n<p>В реальном сервисе справочники должны быть частью версии конкретной пробы, а не глобальными константами. Полезно также валидировать типы, длину текста, владельца артефакта и права доступа. Эти поля намеренно не реализованы здесь: добавление их без контракта проекта создало бы видимость универсального решения.</p>\n<h2>Как найти первую точку расхождения</h2>\n<p>Сравнивайте записи слева направо, от менее интерпретируемого к более интерпретируемому. Сначала убедитесь, что совпали <code>sampleId</code> и версия рубрики. Затем откройте каждую ссылку evidence и выпишите наблюдение дословно. После этого сравните unknown. Только при совпадающих фактах переходите к interpretation и hand-off.</p>\n<table><thead><tr><th>Первая разница</th><th>Вероятная причина</th><th>Проверка</th><th>Исправление</th></tr></thead><tbody><tr><td><code>sampleId</code> или версия rubric</td><td>Рецензенты получили разные входы</td><td>Сверить идентификаторы и хеши фикстуры</td><td>Повторить прогон на одном входе</td></tr><tr><td>Observation</td><td>В тексте неоднозначный фрагмент или его по-разному прочитали</td><td>Открыть одну и ту же ссылку и записать видимые символы</td><td>Уточнить sample или инструкцию чтения</td></tr><tr><td>Unknown</td><td>Критерий скрывает недостающее условие</td><td>Проверить, названо ли отсутствие явно</td><td>Добавить поле unknown и не заполнять его догадкой</td></tr><tr><td>Interpretation</td><td>Одинаковые факты связывают с разными гипотезами</td><td>Найти предложение, где появляется причинный вывод</td><td>Записать гипотезу и один тест, не менять сразу всю rubric</td></tr><tr><td>Hand-off</td><td>Граница действия не описана</td><td>Прогнать положительный и запрещённый текст через валидатор</td><td>Оставить только запрос evidence или остановку</td></tr></tbody></table>\n<p>Один цикл должен менять один артефакт. Если одновременно переписать sample, rubric и инструкцию рецензента, следующий результат не объяснит, что устранило расхождение. Старую версию сохраняйте как обезличенную учебную фикстуру с понятным статусом, а не как запись о конкретном собеседнике.</p>\n<h2>Короткая процедура калибровочной сессии</h2>\n<ol><li><strong>Опишите границу.</strong> Запишите, что проба проверяет: например, поиск отсутствующего условия в API-ответе. Отдельно запишите, чего она не измеряет.</li><li><strong>Заморозьте вход.</strong> Дайте всем один <code>sampleId</code>, одну версию текста и одну версию рубрики. Зафиксируйте отсутствие нужных фактов.</li><li><strong>Соберите независимые записи.</strong> До встречи каждый рецензент указывает observation, unknown и interpretation со ссылками на поля или строки.</li><li><strong>Сравните факты.</strong> Проверьте идентификаторы, ссылки и буквальное содержимое evidence. Не обсуждайте личные качества и общий «уровень» ответа.</li><li><strong>Назовите первую развилку.</strong> Отметьте, на каком поле записи впервые расходятся. Это рабочая единица исправления.</li><li><strong>Выберите один следующий тест.</strong> Если не хватает правила origin, запросите правило origin. Не подменяйте этот запрос изменением конфигурации или выводом о человеке.</li><li><strong>Измените один артефакт.</strong> Исправьте только sample, критерий или инструкцию. Свяжите новую версию с причиной изменения.</li><li><strong>Повторите прогон.</strong> Используйте тот же идентификатор и проверьте обе ветки: разрешённый запрос evidence и запрещённый личный outcome.</li></ol>\n<h2>Когда метод не подходит</h2>\n<p>Фиксированная проба проверяет согласованность чтения и качество границы evidence. Она не измеряет производительность инженера, будущую работу в команде, результат реального проекта или вероятность успеха на должности. Отсутствие расхождения на одном sample не доказывает, что rubric валидна для всех задач.</p>\n<p>Для реального отбора нужны отдельные решения владельцев процесса: анализ работы, набор релевантных критериев, одинаковые условия, правила хранения записей и проверка применимых требований. OPM описывает structured interview как метод с заранее заданными одинаковыми вопросами и общей шкалой; это полезная опорная идея, но не готовый регламент для частной команды и не совет по законодательству конкретной страны.</p>\n<p>Юридическая применимость особенно зависит от юрисдикции и способа использования результата. Страница EEOC перечисляет федеральные правила США, включая 29 CFR 1607 — Uniform Guidelines on Employee Selection Procedures. Российская, европейская или другая процедура требует собственной правовой проверки. Учебный валидатор из этой статьи не заменяет юриста, HR-политику, оценку доступности или требования к защите персональных данных.</p>\n<p>Метод также не исправляет плохой вопрос. Если ответ можно получить случайным угадыванием, если отсутствуют ключевые входы или если критерий требует «понять намерение автора», рецензенты будут расходиться по содержательной причине. Сначала уменьшите утверждение до наблюдаемого действия, затем добавляйте сложность и новые пробы.</p>\n<h2>Критерий готовности</h2>\n<p>Калибровка готова к повторному использованию, если независимая запись отвечает на четыре вопроса без устного пояснения: какой вход читали; какой факт открыт по ссылке; что осталось неизвестным; почему следующий hand-off принят или остановлен. Для каждого расхождения назван один изменённый артефакт. Положительный запуск возвращает только запрос недостающего evidence. Отрицательные запуски отклоняют несуществующую ссылку, неизвестный критерий и попытку создать личное решение.</p>\n<p>Храните рядом версию sample, версию rubric и результаты отрицательных тестов. Тогда следующий рецензент сможет воспроизвести не только успешный путь, но и причину остановки. Это делает калибровку техническим процессом с проверяемыми границами, а не голосованием за самое убедительное впечатление.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href='https://www.opm.gov/policy-data-oversight/assessment-and-selection/structured-interviews' target='_blank' rel='noopener'>U.S. Office of Personnel Management: Structured Interviews</a> — официальное описание метода: job-related competencies, одинаковые заранее заданные вопросы, единая шкала и стандарты приемлемого ответа. Это источник по федеральному контексту США, а не универсальный шаблон найма.</li><li><a href='https://www.eeoc.gov/regulations-and-guidelines' target='_blank' rel='noopener'>U.S. Equal Employment Opportunity Commission: Regulations and Guidelines</a> — официальный каталог правил EEOC; на странице отдельно указаны 29 CFR 1607 и Uniform Guidelines on Employee Selection Procedures. Применимость зависит от юрисдикции и конкретного процесса.</li></ul>"
 }