diff --git a/editorial/agent-rewrites/101.json b/editorial/agent-rewrites/101.json
index fb57da3..e5bbf05 100644
--- a/editorial/agent-rewrites/101.json
+++ b/editorial/agent-rewrites/101.json
@@ -2,6 +2,6 @@
   "index": 101,
   "slug": "editorial-2025-03-mechanism-knowledge-retrieval",
   "title": "Почему высокий vector score не доказывает ответ",
-  "excerpt": "Retrieval находит похожие фрагменты, но не подтверждает их свежесть, доступность и смысл. Разбираем границу между ranking и проверяемым источником.",
-  "contentHtml": "<p><strong>Проблема.</strong> Поиск по инженерной базе возвращает первый фрагмент с высоким vector score. Фрагмент похож на вопрос, поэтому ответ выглядит уверенно. Через несколько дней выясняется, что документ описывает старый контракт, закрыт для автора запроса или не содержит точного правила, на которое ссылается ответ.</p>\n<p><strong>Симптом.</strong> В результате есть title, excerpt и число вроде <code>0.98</code>, но нет версии источника, срока действия, access decision и anchor. Инженер меняет код по старой инструкции. <strong>Цена ошибки.</strong> Команда тратит время на повторное расследование: нужно найти нужную редакцию, выяснить права и отделить цитату от пересказа. Ошибка также подрывает доверие к базе знаний. Следующий хороший фрагмент начинают игнорировать вместе с плохим.</p>\n<p><strong>Тезис.</strong> Vector score решает одну задачу: упорядочивает похожие candidates в выбранной модели поиска. Он не доказывает истинность claim, право читать источник, актуальность документа и полноту найденных материалов. Поэтому retrieval должен завершаться не выбором top-1, а проверяемым решением: candidate допускается к ответу только после проверок access, freshness, provenance и exact citation.</p>\n<h2>Где заканчивается score</h2>\n<p>Nearest-neighbor поиск сравнивает запрос с векторами документов. Его результат помогает сократить очередь чтения. Это полезно, когда корпус велик и человек не может открыть все записи. Но score не знает, кто задаёт вопрос. Он не знает, отозвал ли владелец документ. Он не знает, поддерживает ли найденный абзац именно тот claim, который собирается сделать система.</p>\n<p>Порог похожести не исправляет эту границу. Представим учебный корпус из трёх записей. Просроченная инструкция получила score <code>0.97</code>, закрытое исключение — <code>0.99</code>, а текущая разрешённая инструкция — <code>0.91</code>. Фильтр <code>score &gt;= 0.90</code> оставит все три. Сортировка поставит опасные записи выше нужной. Это не результат реального сервиса, а минимальный пример, который показывает, почему ranking нельзя использовать как authorization или evidence.</p>\n<table><caption>Что сообщает каждый сигнал</caption><thead><tr><th scope=\"col\">Сигнал</th><th scope=\"col\">Вопрос</th><th scope=\"col\">Действие</th><th scope=\"col\">Чего он не доказывает</th></tr></thead><tbody><tr><td>vectorScore</td><td>Насколько candidate похож на query?</td><td>Ставит запись в очередь проверки.</td><td>Что claim верен, свеж и доступен.</td></tr><tr><td>accessLabels</td><td>Разрешён ли класс источника requester scope?</td><td>Отбрасывает закрытый фрагмент.</td><td>Что выполнена вся реальная policy identity.</td></tr><tr><td>publishedAt / expiresAt</td><td>Входит ли запись в объявленное окно свежести?</td><td>Отбрасывает будущие и просроченные записи.</td><td>Что это единственная актуальная редакция.</td></tr><tr><td>citationUri#anchor</td><td>Можно ли открыть точное место в конкретной версии?</td><td>Делает candidate адресуемым.</td><td>Что источник поддерживает более широкий вывод.</td></tr><tr><td>human verification</td><td>Совпадает ли claim с открытым фрагментом?</td><td>Разрешает сформулировать ответ.</td><td>Что одна проверка заменяет владельца policy.</td></tr></tbody></table>\n<h2>Запись индекса должна сохранять происхождение</h2>\n<p>Chunking часто оставляет в индексе только текст и embedding. Заголовок, версия и срок действия остаются в исходном документе. После retrieval система показывает удобный snippet, но не может ответить на простой вопрос: из какой редакции он взят? Одинаковая фраза может встречаться в новой инструкции, старом RFC и закрытом исключении.</p>\n<p>Минимальная запись должна связывать chunk с source record. Source record хранит <code>sourceId</code>, <code>sourceVersion</code>, <code>owner</code>, <code>publishedAt</code> и URI. Chunk хранит <code>sourceId</code>, текстовый фрагмент, <code>citationAnchor</code>, <code>indexedAt</code>, <code>expiresAt</code> и access labels. Retrieval event сохраняет query, момент поиска, список candidates и причины отказа. Система может не передавать все поля в пользовательский интерфейс, но decision должен иметь к ним доступ.</p>\n<p>Если у chunk нет стабильной связи с редакцией, он остаётся подсказкой для поиска. Если у него нет anchor, он не становится точной цитатой. Если у него нет declared policy свежести, приложение не должно молча называть его текущим. Эти ограничения лучше показать явно, чем восстанавливать по смыслу из текста.</p>\n<figure><img src=\"/assets/editorial/2025/knowledge-retrieval-2025-freshness-access-matrix.svg\" alt=\"Матрица retrieval: свежая разрешённая запись проходит проверки, а записи с более высоким score отклоняются из-за срока, доступа или отсутствия anchor\" loading=\"lazy\" /><figcaption>Score сокращает очередь проверки. Матрица не объявляет самый похожий фрагмент доказательством: доступ, срок и адресуемая цитата имеют отдельные границы.</figcaption></figure>\n<h2>Проверяйте источник до составления ответа</h2>\n<p>Надёжный порядок начинается с evidence, а не с готового текста. Сначала система получает candidates и их metadata. Затем она применяет policy к каждому candidate. Только оставшиеся фрагменты передаются человеку или компоненту, который формулирует ответ. Так нельзя незаметно добавить в draft тезис, которого не было в источнике.</p>\n<pre><code>type Candidate = {\n  id: string;\n  score: number;\n  sourceVersion?: string;\n  accessLabels: string[];\n  publishedAt?: string;\n  expiresAt?: string;\n  citationUri?: string;\n  citationAnchor?: string;\n};\n\nfunction admissible(candidate, requesterLabel, retrievalAt) {\n  const allowed = candidate.accessLabels.includes(requesterLabel);\n  const fresh = candidate.publishedAt &lt;= retrievalAt &amp;&amp;\n    (!candidate.expiresAt || retrievalAt &lt; candidate.expiresAt);\n  const citable = Boolean(\n    candidate.sourceVersion &amp;&amp;\n    candidate.citationUri &amp;&amp;\n    candidate.citationAnchor\n  );\n\n  return { allowed, fresh, citable, ok: allowed &amp;&amp; fresh &amp;&amp; citable };\n}\n\n// Учебный код: локальные значения, без реального corpus и identity provider.</code></pre>\n<p>Код показывает контракт, а не готовую систему доступа. Проверка <code>accessLabels.includes</code> не заменяет authentication, authorization policy и аудит. Сравнение дат работает только после фиксации формата и часового пояса. Human verification всё равно нужен: технически доступный anchor может содержать исключение, которое не подтверждает общий claim.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><caption>Диагностика retrieval без смешения сигналов</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Top-1 отвечает на вопрос, но описывает старый контракт.</td><td>Ranking не учитывает срок действия или version policy.</td><td>Сравнить <code>publishedAt</code> и <code>expiresAt</code> с зафиксированным <code>retrievalAt</code>.</td><td>Отклонить просроченный candidate и показать актуальную редакцию либо остановить ответ.</td></tr><tr><td>Фрагмент релевантен, но его нельзя открыть.</td><td>Индекс получил текст без согласованной access boundary.</td><td>Проверить requester scope, labels и решение владельца ресурса.</td><td>Убрать candidate из answer path; не маскировать отказ новым пересказом.</td></tr><tr><td>Ссылка ведёт на страницу, но не на правило.</td><td>Сохранён URI без версии и anchor.</td><td>Открыть ссылку на том же snapshot и найти точный фрагмент.</td><td>Оставить запись кандидатом, пока источник не станет адресуемым.</td></tr><tr><td>Ответ звучит шире цитаты.</td><td>Генератор обобщил локальное исключение.</td><td>Сопоставить каждое предложение claim с одним или несколькими фрагментами.</td><td>Сузить формулировку, добавить limitation или отправить вопрос на ручную проверку.</td></tr><tr><td>После пустого результата система всё равно отвечает.</td><td>Fallback подменяет отсутствие evidence вероятным текстом.</td><td>Проверить negative path: все candidates expired, закрыты или без anchor.</td><td>Вернуть stop status с причиной и запросить источник или решение владельца.</td></tr></tbody></table>\n<h2>Отрицательный путь важнее удачного top-1</h2>\n<p>Проверять нужно не только случай, где нашлась хорошая запись. Система должна остановиться, если все candidates просрочены, закрыты или не имеют точного locator. Пустой результат честнее уверенного ответа без основания. Его можно объяснить и исправить: обновить документ, выдать доступ, добавить anchor или уточнить вопрос.</p>\n<p>Не смешивайте причины в один статус вроде <code>relevance_low</code>. <code>access_denied</code> ведёт к владельцу policy. <code>expired_at_retrieval</code> ведёт к владельцу документа. <code>missing_citation_anchor</code> ведёт к ingestion или структуре источника. Такое разделение экономит время и не толкает команду сразу менять embedding model.</p>\n<h2>Порядок внедрения проверки</h2>\n<ol><li>Зафиксируйте query, requester scope и <code>retrievalAt</code>. Один и тот же запрос должен иметь воспроизводимый срез времени.</li><li>Сохраните для каждого candidate id, score, source version и все причины будущего отказа. Не передавайте дальше только текстовый snippet.</li><li>Проверьте access до раскрытия фрагмента в answer path. Техническая доступность записи не равна праву показать её requester.</li><li>Примените freshness policy. Запишите, какое поле и какой срок считаются обязательными для operational question.</li><li>Проверьте provenance и citation. URI должен вести к нужной редакции, anchor — к месту, где действительно находится утверждение.</li><li>Сопоставьте claim с источником. Если источник поддерживает только условие или исключение, сузьте ответ до этой границы.</li><li>Если пересечение пусто, остановите ответ, верните понятный reason code и предложите следующий безопасный шаг.</li><li>Закрепите проверки на отрицательных примерах: высокий score у expired, закрытый record и candidate без anchor не должны попасть в citations.</li></ol>\n<h2>Ограничения</h2>\n<p>Эта схема не обещает, что vector search найдёт полный корпус. Она не сравнивает качество embedding-моделей и не утверждает, что keyword search всегда лучше. Она также не превращает metadata в доказательство смысла. Свежая доступная цитата может быть двусмысленной или слишком узкой для вопроса.</p>\n<p>Учебный код использует локальные значения и упрощённые labels. Он не проверяет реальную личность, RBAC, ABAC, SSO, журнал аудита, конкурентное обновление документа или кэш. Применять его как готовую authorization implementation нельзя. В реальной системе policy должен иметь владельца, а source version и правила expiry должны быть частью явного контракта.</p>\n<p>Ограничение есть и у даты. HTTP-поле <code>Last-Modified</code> сообщает время, когда origin считает представление изменённым. Оно не доказывает, что инженерное правило всё ещё применимо. Документ может не меняться и устареть из-за миграции. Поэтому freshness policy должна учитывать смысл вопроса, а не только HTTP timestamp.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Механизм готов к ограниченному применению, когда для одного зафиксированного query можно показать полный decision trace: candidates с score, source version, access result, freshness result, citation URI с anchor и итоговый human verification. На учебном отрицательном наборе expired, closed и no-anchor записи получают отдельные причины и не попадают в answer.</p>\n<p>Дополнительный критерий — повторный запуск с тем же <code>retrievalAt</code> даёт тот же набор допущенных записей, если corpus и policy не менялись. При пустом пересечении система возвращает stop status, а не догадку. Только после этого можно измерять top-k, reranking и стоимость запросов: эти настройки ускоряют поиск кандидатов, но не заменяют границу доказательства.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://raw.githubusercontent.com/opensearch-project/k-NN/150c589849a8ec3bc442d830b43a3eaf4e25fa0c/README.md\" target=\"_blank\" rel=\"noopener noreferrer\">OpenSearch k-NN README, immutable commit 150c589</a> — официальное описание nearest-neighbor similarity search и фильтров. Источник подтверждает механику поиска кандидатов, но не право доступа, свежесть или истинность claim.</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.2\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110, раздел 8.8.2 Last-Modified</a> — стандартное описание времени изменения выбранного HTTP-представления. Поле не является доказательством семантической актуальности документа.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/207/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-207: Zero Trust Architecture</a> — официальный принцип отсутствия неявного доверия и отдельной проверки authorization перед доступом к ресурсу. Документ не задаёт схему vector index или формат citation.</li></ul>"
+  "excerpt": "Vector search ранжирует похожие фрагменты, но не подтверждает их смысл, свежесть и право показа. Разбираем decision trace, отрицательный путь и проверку источника до ответа.",
+  "contentHtml": "<p><strong>Проблема.</strong> Поиск по инженерной базе возвращает фрагмент с vector score <code>0.98</code>, и система сразу строит из него ответ. Через несколько дней выясняется, что фрагмент относится к старой редакции API, закрыт для автора запроса или содержит исключение, а не общее правило.</p>\n<p><strong>Симптом.</strong> В интерфейсе есть title, excerpt и число похожести, но нет версии источника, результата проверки доступа, срока действия и точного места цитаты. Инженер меняет код по устаревшей инструкции. Цена ошибки — повторное расследование и потеря доверия к базе знаний: после нескольких ложных попаданий команда начинает игнорировать и полезные результаты.</p>\n<p><strong>Вывод.</strong> Vector score решает задачу ranking: ставит candidates в порядок по выбранной моделью поиска мере близости. Он не является вероятностью истины и не доказывает, что claim (утверждение в ответе) поддержан источником. Перед генерацией нужно получить отдельное решение по доступу, свежести и происхождению. Если пересечение условий пусто, система должна остановиться, а не заполнять пробел правдоподобным текстом.</p>\n<h2>Что именно измеряет score</h2>\n<p>Vector query сравнивает вектор запроса с векторами документов и возвращает ближайшие результаты по настроенной similarity metric. Такая сортировка сокращает объём чтения: вместо тысячи документов инженер получает несколько candidates. Это полезный этап поиска, но не этап доказательства.</p>\n<p>Само число зависит от реализации. При cosine similarity, dot product и L2 distance используются разные шкалы и преобразования. Даже один движок может считать итоговый score по-разному для разных типов полей и запросов. Поэтому порог <code>score &gt;= 0.90</code> нельзя переносить между моделями, индексами и метриками без размеченного набора проверок. Значения <code>0.98</code>, <code>0.91</code> и другие числа ниже — учебные, не измерение качества конкретного сервиса.</p>\n<p>Score также не знает контекст requester. Он не видит, отозвал ли владелец документ, и не умеет определить, что цитата отвечает только на частный случай. Эти свойства должны приходить из источника и policy, а не угадываться из текста фрагмента.</p>\n<table><caption>Сигналы в retrieval-решении</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>vectorScore</code></td><td>Насколько candidate близок к query по выбранной метрике?</td><td>Отсортировать очередь чтения.</td><td>Истинность claim, право доступа и актуальность.</td></tr><tr><td><code>sourceVersion</code></td><td>Из какой редакции получен chunk?</td><td>Сопоставить результат с известным snapshot.</td><td>Что редакция подходит к данному вопросу.</td></tr><tr><td><code>accessDecision</code></td><td>Может ли этот requester увидеть ресурс?</td><td>Исключить закрытый candidate из answer path.</td><td>Что открытый текст подтверждает claim.</td></tr><tr><td><code>expiresAt</code></td><td>Не вышел ли source за объявленный срок?</td><td>Отклонить устаревшую запись или направить к владельцу.</td><td>Что документ семантически полон и верен.</td></tr><tr><td><code>citationAnchor</code></td><td>Можно ли открыть точное место в нужной версии?</td><td>Показать адресуемую цитату.</td><td>Что узкий фрагмент поддерживает более широкий вывод.</td></tr></tbody></table>\n<h2>Происхождение нужно сохранить рядом с chunk</h2>\n<p>При индексации документ обычно разбивают на chunks. Если сохранить только текст и embedding, после поиска останется удобный snippet без ответа на вопрос «из какой редакции он взят?». Одинаковая фраза может встретиться в текущем руководстве, старом RFC и закрытом исключении.</p>\n<p>Минимальный контракт связывает каждую запись с исходным документом. У source record есть <code>sourceId</code>, <code>sourceVersion</code>, владелец, статус публикации и URI. У chunk есть тот же <code>sourceId</code>, текст, anchor, время индексации и access labels. У retrieval event есть зафиксированные query, requester scope, <code>retrievalAt</code>, список candidates и причины отказа. Пользовательскому интерфейсу не обязательно показывать всё, но компонент, принимающий решение, должен иметь эти поля.</p>\n<p>Не стоит восстанавливать происхождение по заголовку или совпадению текста. При обновлении документа старый chunk должен быть выведен из индекса или помечен как недопустимый для текущего вопроса. Иначе высокий score может быть честным результатом поиска по неправильному snapshot.</p>\n<figure><img src=\"/assets/editorial/2025/knowledge-retrieval-2025-freshness-access-matrix.svg\" alt=\"Матрица допуска к ответу: запись с score 0.91 проходит при разрешённом доступе, действующем сроке и точном anchor, а записи с более высоким score отклоняются\" loading=\"lazy\" /><figcaption>В учебной матрице score 0.98 у закрытой записи и score 0.96 у просроченной записи не меняют вердикт: answer path допускает только пересечение access, freshness и exact citation.</figcaption></figure>\n<h2>Воспроизводимый decision trace</h2>\n<p>Решение полезно представлять не флагом <code>relevant: true</code>, а набором проверяемых полей. Ниже — самостоятельный пример на Node.js без внешних пакетов. Он фиксирует момент поиска, применяет одну policy к четырём синтетическим candidates и печатает причины отказа. Команда не моделирует identity provider или настоящую БД; она воспроизводит именно порядок принятия решения.</p>\n<pre><code>node &lt;&lt;'NODE'\nconst retrievalAt = new Date('2025-03-18T12:00:00Z');\nconst requester = 'engineering';\nconst candidates = [\n  { id: 'fresh-v3', score: 0.91, access: ['engineering'],\n    publishedAt: '2025-03-01T00:00:00Z', expiresAt: '2025-04-01T00:00:00Z',\n    sourceVersion: 'v3', citation: 'https://docs.example.test/runbook/v3#rollback' },\n  { id: 'expired-v1', score: 0.96, access: ['engineering'],\n    publishedAt: '2024-01-01T00:00:00Z', expiresAt: '2025-01-01T00:00:00Z',\n    sourceVersion: 'v1', citation: 'https://docs.example.test/runbook/v1#rollback' },\n  { id: 'closed-v2', score: 0.98, access: ['security'],\n    publishedAt: '2025-02-01T00:00:00Z', expiresAt: '2025-04-01T00:00:00Z',\n    sourceVersion: 'v2', citation: 'https://docs.example.test/runbook/v2#rollback' },\n  { id: 'no-anchor', score: 0.89, access: ['engineering'],\n    publishedAt: '2025-03-01T00:00:00Z', expiresAt: '2025-04-01T00:00:00Z',\n    sourceVersion: 'v3', citation: null },\n];\n\nfunction decide(candidate) {\n  const accessOk = candidate.access.includes(requester);\n  const date = retrievalAt.getTime();\n  const fresh = Date.parse(candidate.publishedAt) &lt;= date &amp;&amp;\n    (!candidate.expiresAt || date &lt; Date.parse(candidate.expiresAt));\n  const citable = Boolean(candidate.sourceVersion &amp;&amp; candidate.citation);\n  const reasons = [];\n  if (!accessOk) reasons.push('access_denied');\n  if (!fresh) reasons.push('expired_at_retrieval');\n  if (!citable) reasons.push('missing_citation');\n  return { id: candidate.id, score: candidate.score,\n    ok: reasons.length === 0, reasons };\n}\n\nconsole.table(candidates.sort((a, b) =&gt; b.score - a.score).map(decide));\nNODE</code></pre>\n<p>Ожидаемый результат: <code>closed-v2</code> окажется первым по score, но получит <code>access_denied</code>; <code>expired-v1</code> — <code>expired_at_retrieval</code>; <code>no-anchor</code> — <code>missing_citation</code>. В answer path попадёт только <code>fresh-v3</code>. Если убрать его из массива, код не должен выбирать следующий candidate: приложение должно вернуть stop-статус с причиной <code>no_admissible_evidence</code>.</p>\n<h2>Проверяйте три независимые границы</h2>\n<p><strong>Доступ.</strong> Проверяйте requester scope до передачи фрагмента генератору. Даже если индекс технически вернул закрытый текст, это не разрешает показать его пользователю или пересказать его содержание. Проверка массива labels в примере — только замена policy для демонстрации. В реальном сервисе authorization должен опираться на подтверждённую identity и правила владельца ресурса.</p>\n<p><strong>Свежесть.</strong> Сравнивайте фиксированный <code>retrievalAt</code> с правилами домена: сроком действия, статусом публикации и версией контракта. HTTP <code>Last-Modified</code> сообщает время, когда origin считает выбранное представление изменённым. Он не говорит, что правило всё ещё подходит к эксплуатационному вопросу. Документ может не меняться, но стать неприменимым после миграции.</p>\n<p><strong>Происхождение и смысл.</strong> Открываем URI в той же редакции и проверяем anchor. Затем сопоставляем каждое предложение ответа с фрагментом. Доступная ссылка может вести на исключение, а не на общее правило; наличие anchor не превращает локальное условие в универсальный вывод.</p>\n<table><caption>Диагностика по наблюдаемому симптому</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Гипотеза</th><th scope=\"col\">Проверка</th><th scope=\"col\">Следующее действие</th></tr></thead><tbody><tr><td>Top-1 описывает старый API-контракт.</td><td>Ranking не учитывает version или expiry policy.</td><td>Сравнить source version, опубликованный статус и <code>retrievalAt</code>.</td><td>Отклонить candidate и вернуть текущую редакцию либо stop.</td></tr><tr><td>Релевантный текст нельзя открыть.</td><td>Индекс и answer path используют разные access boundaries.</td><td>Сверить requester scope с policy владельца ресурса.</td><td>Не раскрывать фрагмент и записать <code>access_denied</code>.</td></tr><tr><td>Ссылка открывается, но правило не находится.</td><td>Сохранён URI без версии или стабильного anchor.</td><td>Открыть тот же snapshot и проверить точное место.</td><td>Оставить candidate вне citations до исправления ingestion.</td></tr><tr><td>Ответ шире приведённой цитаты.</td><td>Генератор обобщил условие или исключение.</td><td>Разметить claim-to-source mapping по предложениям.</td><td>Сузить ответ, добавить ограничение или передать вопрос человеку.</td></tr><tr><td>Все candidates отфильтрованы, но ответ всё равно есть.</td><td>Fallback подменяет отсутствие evidence вероятным текстом.</td><td>Запустить negative case с expired, закрытым и no-anchor набором.</td><td>Вернуть <code>no_admissible_evidence</code>, а не догадку.</td></tr></tbody></table>\n<h2>Почему отрицательный путь обязателен</h2>\n<p>Удачный top-1 показывает лишь, что поиск нашёл похожий текст. Надёжность видна в обратной ситуации: все candidates просрочены, закрыты или не имеют точного locator. Пустой ответ можно объяснить и исправить — обновить документ, запросить доступ, добавить anchor или уточнить вопрос. Уверенный ответ без основания скрывает причину сбоя.</p>\n<p>Разделяйте reason codes. <code>access_denied</code> направляет к владельцу policy, <code>expired_at_retrieval</code> — к владельцу документа, <code>missing_citation</code> — к ingestion или разметке источника, а <code>relevance_low</code> — к качеству retrieval. Такая диагностика не заставляет команду менять embedding model, когда проблема находится в правах или жизненном цикле документа.</p>\n<h2>Порядок внедрения</h2>\n<ol><li>Зафиксируйте query, requester scope и <code>retrievalAt</code>. Без момента проверки нельзя воспроизвести решение по сроку.</li><li>Сохраните у candidate id, score, source version, URI, anchor и исходные metadata. Не передавайте дальше только snippet.</li><li>Примените access policy до раскрытия текста генератору или пользователю. Ошибка индекса не должна становиться утечкой.</li><li>Примените freshness policy и явно назовите владельца срока. Если срок не определён, не называйте документ текущим молча.</li><li>Проверьте provenance: URI должен вести к нужной редакции, а anchor — к месту, подтверждающему claim.</li><li>Сопоставьте claim с источником. Условие и исключение должны остаться условием и исключением в ответе.</li><li>При пустом пересечении верните stop-статус и конкретный reason code. Не запускайте скрытый fallback на «наиболее похожий» текст.</li><li>Закрепите тесты на отрицательных данных и повторите запуск с тем же <code>retrievalAt</code> при неизменных corpus и policy.</li></ol>\n<h2>Границы применимости</h2>\n<p>Эта схема не доказывает полноту поиска, не выбирает лучшую embedding model и не заменяет оценку retrieval на размеченных вопросах. Она также не утверждает, что keyword search всегда лучше vector search. Score помогает ранжировать candidates; качество покрытия корпуса, reranking и стоимость запроса нужно измерять отдельно.</p>\n<p>Учебный код не реализует authentication, RBAC, ABAC, SSO, аудит, отзыв сессий, конкурентное обновление документов или защиту кэша. В нём намеренно используются домен <code>example.test</code>, четыре записи и упрощённый массив access labels. Перед применением в сервисе нужно описать policy, владельцев полей, формат дат и поведение при отсутствии версии или anchor.</p>\n<p>Критерий готовности ограниченного запуска — полный decision trace для фиксированного запроса: candidates со score, access result, freshness result, source version, citation URI с anchor и результат проверки claim. В отрицательном наборе expired, closed и no-anchor записи должны получать разные причины и не попадать в citations.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.elastic.co/guide/en/elasticsearch/reference/current/vector-queries.html\" target=\"_blank\" rel=\"noopener noreferrer\">Elastic: Vector queries</a> — официальное описание поиска ближайших векторов по similarity metric. Источник подтверждает роль vector query как поиска и ранжирования, но не задаёт правила доступа к документу.</li><li><a href=\"https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-dense-vector-query\" target=\"_blank\" rel=\"noopener noreferrer\">Elastic: Dense vector query</a> — показывает, что similarity function и способ подсчёта score задаются контрактом поля и запроса. Поэтому учебные числа нельзя сравнивать между разными конфигурациями без проверки.</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.2\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110, section 8.8.2 Last-Modified</a> — определяет поле как timestamp, отражающий мнение origin о времени изменения выбранного представления. Это не стандарт семантической свежести инженерного правила.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/207/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-207: Zero Trust Architecture</a> — разделяет authentication и authorization и не предполагает доверие только из-за расположения ресурса или аккаунта. Документ не задаёт формат vector index или citation.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/102.json b/editorial/agent-rewrites/102.json
index 74bb1cc..edadb9d 100644
--- a/editorial/agent-rewrites/102.json
+++ b/editorial/agent-rewrites/102.json
@@ -3,5 +3,5 @@
   "slug": "editorial-2025-03-practice-knowledge-retrieval",
   "title": "Поиск по инженерной базе: как не превратить похожий текст в доказательство",
   "excerpt": "Практический маршрут для retrieval по инженерной документации: сначала проверить версию, срок, права и точную цитату, а затем решать, можно ли отвечать.",
-  "contentHtml": "<p>Инженер задаёт вопрос по внутренней документации. Поиск возвращает фрагмент с высоким score. Заголовок совпадает, формулировка выглядит знакомой, ответ можно написать за минуту. Потом выясняется, что фрагмент описывает старый контракт, закрыт для этого читателя или ведёт на страницу без точного места в тексте. Ошибка уже повлияла на решение: изменился адаптер, в ответ попал закрытый материал, а reviewer не может быстро проверить источник.</p><p>Цена такой ошибки складывается из отката, повторного расследования и потери доверия к базе знаний. Пустой результат заметен. Уверенный пересказ устаревшего правила — нет. Поэтому поисковый ответ должен сначала доказать право на использование конкретной записи, её применимость на момент запроса и адресуемость цитаты. Только после этого можно формулировать вывод.</p><h2>Тезис: score выбирает кандидата, но не подтверждает утверждение</h2><p>Similarity search решает узкую задачу: он упорядочивает похожие документы или фрагменты. В score нет ответа на вопросы «кто может читать запись», «действует ли правило сейчас» и «подтверждает ли этот абзац конкретный claim». Эти вопросы требуют других данных и других проверок. Если объединить их в одно число, система перестанет объяснять, почему кандидат отклонён.</p><p>Рабочая граница выглядит так: <strong>query → candidates → access check → freshness check → exact citation → human verification</strong>. Retrieval сокращает очередь чтения. Metadata задают условия допуска. Человек сопоставляет утверждение с источником. Если пересечение условий пусто, система останавливается и сообщает причину. Она не заменяет недостающий evidence правдоподобной фразой.</p><h2>Симптом → причина → проверка → действие</h2><div class='table-scroll'><table><caption>Диагностика результата поиска по инженерной базе</caption><thead><tr><th scope='col'>Симптом</th><th scope='col'>Причина</th><th scope='col'>Проверка</th><th scope='col'>Действие</th></tr></thead><tbody><tr><td>Первый кандидат имеет высокий score, но у него нет версии</td><td>Индекс хранит chunk и embedding без связи с редакцией источника</td><td>Найти stable recordId, sourceVersion и URI исходного документа</td><td>Оставить кандидата для поиска, но не использовать как цитату</td></tr><tr><td>Фрагмент точно отвечает на вопрос, но expiresAt уже прошёл</td><td>Ранжирование не учитывает локальную политику актуальности</td><td>Сравнить expiresAt и зафиксированный retrievedAt</td><td>Отклонить запись и запросить действующую редакцию</td></tr><tr><td>Кандидат закрыт для requester</td><td>Access policy проверяется после генерации или не проверяется</td><td>Сопоставить accessLabels записи и scope запроса до показа excerpt</td><td>Скрыть закрытый текст, сохранить безопасную причину отказа</td></tr><tr><td>Ссылка ведёт на документ, но не на нужный абзац</td><td>В индексе нет citationAnchor</td><td>Открыть URI и проверить точный раздел, строку или якорь</td><td>Остановить ответ до появления адресуемого фрагмента</td></tr><tr><td>Ответ написан, ссылки добавлены позже</td><td>Текст успел включить выводы, которых нет в evidence</td><td>Сравнить каждый claim с источником до публикации</td><td>Сначала собрать допущенные citations, затем писать ответ</td></tr></tbody></table></div><h2>Механизм: запись индекса должна нести provenance</h2><p>Голый фрагмент удобен для векторного поиска, но плох для проверки. Минимальная запись связывает chunk с источником и сохраняет границы его использования. Нужны устойчивый <code>recordId</code>, <code>sourceVersion</code>, <code>publishedAt</code>, <code>indexedAt</code>, <code>expiresAt</code>, класс доступа, <code>citationUri</code> и <code>citationAnchor</code>. Поле <code>vectorScore</code> тоже полезно, но только для порядка кандидатов.</p><p><code>publishedAt</code> отвечает на вопрос, существовала ли редакция к моменту поиска. <code>indexedAt</code> показывает задержку между публикацией и попаданием в индекс. <code>expiresAt</code> выражает локальное правило применимости. <code>retrievedAt</code> фиксирует срез, на котором система приняла решение. Ни одна из этих дат сама по себе не доказывает смысл утверждения. Вместе они позволяют воспроизвести проверку.</p><p>Такая схема важна после chunking. Когда документ режут на части, title и текст часто сохраняют, а версию, владельца и раздел оставляют в исходном хранилище. Затем в ответ попадает удобный snippet, который нельзя связать с конкретной редакцией. Metadata должны наследоваться каждым chunk или однозначно находиться по stable source id. Иначе retrieval создаёт видимость точности, а не проверяемую provenance.</p><figure><img src='/assets/editorial/2025/knowledge-retrieval-2025-query-retrieval-citation.svg' alt='Схема пути от запроса и retrieval через проверки прав и свежести к точной цитате и human verification; при отсутствии условий ответ останавливается.' loading='lazy' /><figcaption>Score сокращает список кандидатов. Ответ появляется только после проверки свежего, разрешённого и адресуемого источника.</figcaption></figure><h2>Пример: фильтр допуска перед формированием ответа</h2><p>Ниже — учебный пример на фиксированных синтетических записях. Он показывает порядок решения и отрицательный путь. Он не обращается к реальной базе, identity provider, часам, production или сети. Синтетические значения нужны только для проверки контракта обработки.</p><pre><code>const retrievedAt = '2025-03-17T10:00:00Z';\nconst requesterLabels = ['engineering-read'];\n\nconst candidates = [\n  {\n    recordId: 'adapter-v1',\n    sourceVersion: 'v1',\n    expiresAt: '2025-03-01T00:00:00Z',\n    accessLabels: ['engineering-read'],\n    citationUri: 'https://docs.example.test/adapter',\n    citationAnchor: '#old-field',\n    vectorScore: 0.97,\n  },\n  {\n    recordId: 'adapter-v3',\n    sourceVersion: 'v3',\n    expiresAt: '2025-04-01T00:00:00Z',\n    accessLabels: ['engineering-read'],\n    citationUri: 'https://docs.example.test/adapter',\n    citationAnchor: '#schema-upgrade',\n    vectorScore: 0.91,\n  },\n];\n\nconst allowed = candidates.filter((item) =>\n  item.expiresAt > retrievedAt &&\n  item.accessLabels.some((label) => requesterLabels.includes(label)) &&\n  item.citationUri && item.citationAnchor,\n);\n\nif (!allowed.length) {\n  throw new Error('stop-no-fresh-authorized-citable-source');\n}\n\n// Учебный результат: v1 имеет больший score, но истёк.\n// v3 остаётся кандидатом для human verification.</code></pre><p>Здесь высокий score у <code>adapter-v1</code> не отменяет истечение срока. <code>adapter-v3</code> проходит технический фильтр, но это ещё не автоматическое доказательство ответа. Reviewer должен открыть <code>citationUri#schema-upgrade</code> и проверить, что фрагмент действительно говорит о нужной замене. Если у всех записей истёк срок, нет доступа или отсутствует anchor, функция должна вернуть stop condition. Скрытый fallback на старый текст создаёт именно ту ошибку, от которой защищает схема.</p><h2>Проверка должна идти до генерации текста</h2><p>Безопасный порядок начинается с вопроса и времени retrieval. Затем система сохраняет candidates вместе с score и metadata. После этого она проверяет права, срок и citation. В ответ проходит только допущенная запись. Generator или автор получают ограниченный набор evidence, а не абстрактное «знание базы». Для каждого отклонённого кандидата остаётся причина: <code>access-label-not-granted</code>, <code>expired-at-retrieval-time</code> или <code>missing-exact-citation-anchor</code>.</p><p>Ссылка в конце готового текста не исправляет неверный порядок. Draft уже мог добавить условие, которого нет в документе, или смешать две версии. Citation должна появиться в момент выбора evidence. Тогда reviewer видит claim, sourceVersion, дату и точный fragment, а не пытается восстановить происхождение ответа по памяти.</p><p>HTTP-метаданные помогают, но не заменяют внутреннюю политику. В RFC 9110 <code>Last-Modified</code> описывает время, когда origin server считает изменённым выбранное представление. Это полезный сигнал о представлении, но не вся политика актуальности инженерного правила. Документ может иметь собственный срок пересмотра, дату deprecation или область действия. В ответе нужно назвать, какое условие применялось.</p><h2>Порядок действий</h2><ol><li>Зафиксируйте точный query, requester scope и <code>retrievedAt</code>. Не меняйте эти значения в середине проверки.</li><li>Получите top-k candidates и сохраните для каждого recordId, score, sourceVersion и все поля допуска. Не оставляйте только текстовый snippet.</li><li>Проверьте access до показа excerpt. Неподходящий label превращает запись в diagnostic result, а не в материал для ответа.</li><li>Сравните publishedAt и expiresAt с retrievedAt по заранее объявленной policy. Не используйте «выглядит свежим» как критерий.</li><li>Проверьте citationUri и citationAnchor. Они должны вести к конкретной редакции и месту, которое можно открыть и сопоставить с claim.</li><li>Откройте источник и проверьте смысл утверждения. Зафиксируйте короткое подтверждение или точную границу применимости.</li><li>Если хотя бы одно обязательное свойство отсутствует у всех candidates, верните stop condition с reject reasons и владельцем следующего действия.</li></ol><h2>Что показывать читателю</h2><p>Проверяемый ответ не обязан раскрывать внутренний record целиком. Читателю достаточно названия источника, версии, citation, дат публикации и retrieval, а также краткого ограничения. Конкретные роли, токены и закрытые поля не нужно включать в provenance карточку. Класс доступа можно показать только тогда, когда это разрешает сама policy.</p><p>Отдельно храните result decision и human verification. Статус <code>candidate-found</code> означает, что поиск нашёл похожий материал. Статус <code>citation-accepted</code> означает, что запись прошла технические условия. Это всё ещё не равно «утверждение истинно», пока человек не сопоставил claim с фрагментом. Такое разделение делает интерфейс честнее: пользователь видит, что уже проверено, а что ещё нет.</p><h2>Ограничения и отрицательный путь</h2><p>Эта схема не доказывает полноту корпуса, качество embeddings, корректность access policy или семантическую истинность ответа. Она не говорит, что vector search лучше keyword search. Она задаёт более узкую границу: score не заменяет version, freshness, authorization и citation. Учебный код не является benchmark и не сообщает production-результаты.</p><p>Если источник закрыт, просрочен или не имеет точного anchor, система не должна пересказывать его «для справки». Безопасное действие — показать безопасную причину, сохранить recordId без restricted excerpt и направить вопрос владельцу документа или policy. Если policy неизвестна, нельзя молча выбрать allow или deny как окончательное решение: нужен owner и явное правило. Отрицательный путь входит в контракт наравне с успешным.</p><h2>Проверяемый критерий готовности</h2><p>Один вопрос должен проходить тестовый набор из четырёх случаев: свежая разрешённая запись с anchor, просроченная запись с высоким score, закрытая запись с высоким score и запись без anchor. В первом случае результат содержит citation и требует human verification. В трёх остальных случаях citation не появляется, а decision содержит конкретную причину отказа. Повторный запуск с теми же query, retrievedAt и входными записями даёт тот же decision. Это проверяемый критерий готовности маршрута.</p><p>После этого можно отдельно измерять recall, latency и качество ранжирования. Такие метрики улучшают поиск кандидатов, но не отменяют проверку допуска. Если команда не может показать, почему выбран конкретный fragment и почему отклонены остальные, retrieval ещё не стал надёжным источником ответа.</p><h2>Проверяемые источники</h2><ul><li><a href='https://raw.githubusercontent.com/opensearch-project/k-NN/150c589849a8ec3bc442d830b43a3eaf4e25fa0c/README.md' target='_blank' rel='noopener noreferrer'>OpenSearch k-NN README, immutable commit 150c589</a> — официальное описание nearest-neighbor similarity search и фильтров; источник подтверждает механику поиска кандидатов, но не истинность claim, права или свежесть.</li><li><a href='https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.2' target='_blank' rel='noopener noreferrer'>IETF RFC 9110, section 8.8.2 Last-Modified</a> — определение HTTP-метаданных изменения представления; источник не задаёт внутреннюю policy актуальности документации.</li><li><a href='https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf' target='_blank' rel='noopener noreferrer'>NIST SP 800-207, Zero Trust Architecture</a> — принцип явной проверки доступа к ресурсу; документ не задаёт формат vector index, labels или citation.</li></ul>"
-}
\ No newline at end of file
+  "contentHtml": "<p>Инженер задаёт вопрос по внутренней документации. Поиск возвращает фрагмент с высоким score: заголовок совпадает, формулировка знакома, ответ можно написать за минуту. Позже выясняется, что фрагмент относится к старой редакции контракта, закрыт для этого читателя или ведёт только на страницу без нужного абзаца. Решение уже принято: изменён адаптер, в ответ попал закрытый материал, а reviewer не может быстро восстановить источник.</p><p>Цена ошибки — откат, повторное расследование и потеря доверия к базе знаний. Пустой результат виден сразу. Уверенный пересказ устаревшего правила — нет. Поэтому результат поиска должен пройти три независимых вопроса: имеет ли читатель право использовать запись, применима ли она в зафиксированный момент и можно ли открыть точное место, подтверждающее claim. Score помогает выбрать, что читать первым, но сам по себе ничего из этого не доказывает.</p>\n<h2>Граница задачи: кандидат — ещё не источник</h2>\n<p>Семантический или векторный поиск упорядочивает документы по близости представлений. В OpenSearch, например, запрос возвращает ближайшие векторы и параметр <code>k</code> задаёт число кандидатов. Это полезный механизм retrieval: он сокращает очередь чтения. Но score зависит от модели, метрики и индекса; это не вероятность истинности и не разрешение раскрыть текст.</p>\n<p>Надёжный маршрут выглядит так: <strong>query → candidates → policy checks → exact citation → human verification</strong>. Поиск отвечает на вопрос «что может быть связано с запросом». Политика отвечает на вопрос «что разрешено использовать». Проверка источника отвечает на вопрос «подтверждает ли этот фрагмент конкретное утверждение». Если обязательные условия не выполняются, результатом должен быть остановленный ответ с причиной, а не правдоподобный fallback.</p>\n<h2>Контракт записи индекса</h2>\n<p>Для проверки недостаточно сохранить chunk, embedding и score. Каждый фрагмент должен быть связан с устойчивой записью источника. Минимальный контракт может содержать <code>recordId</code>, <code>sourceRevision</code>, <code>sourceUri</code>, <code>citationAnchor</code>, <code>publishedAt</code>, <code>indexedAt</code>, <code>retrievedAt</code>, область доступа и <code>vectorScore</code>. Время следует хранить в RFC 3339 и сравнивать в одной временной шкале.</p>\n<p><code>publishedAt</code> говорит, когда редакция была опубликована. <code>indexedAt</code> позволяет измерить задержку доставки в индекс. <code>retrievedAt</code> фиксирует срез, на котором принято решение. <code>expiresAt</code>, если он используется, — это внутренняя политика пересмотра, а не универсальное свойство документа. Ссылка и anchor должны вести к конкретной редакции и месту, которое reviewer может открыть.</p>\n<p>После chunking метаданные не должны теряться. Если версия и права лежат только в исходном хранилище, а индекс отдаёт независимый snippet, сервис обязан однозначно разрешать <code>recordId</code> обратно в source record и повторно проверять авторизацию. Индекс может ускорять поиск, но не должен становиться неявной копией security boundary. Отклонённые записи полезно сохранять в диагностике по идентификатору и причине, не показывая закрытый excerpt.</p>\n<div class='table-scroll'><table><caption>Диагностика результата retrieval до генерации ответа</caption><thead><tr><th scope='col'>Наблюдение</th><th scope='col'>Что это означает</th><th scope='col'>Проверка</th><th scope='col'>Решение</th></tr></thead><tbody><tr><td>Высокий score, но нет sourceRevision</td><td>Есть похожий chunk без доказуемой редакции</td><td>Разрешить recordId в хранилище источника и проверить provenance</td><td>Оставить только кандидатом, не цитировать</td></tr><tr><td>expiresAt раньше retrievedAt</td><td>Фрагмент не проходит объявленную policy свежести</td><td>Сравнить даты в UTC и проверить часовой срез</td><td>Отклонить, запросить действующую редакцию</td></tr><tr><td>Scope читателя не пересекается с accessLabels</td><td>Найденный текст не разрешён этому requester</td><td>Проверить policy до раскрытия excerpt</td><td>Не показывать текст, вернуть безопасную причину</td></tr><tr><td>Есть sourceUri, но нет citationAnchor</td><td>Ссылку нельзя сопоставить с claim</td><td>Открыть источник и найти стабильный раздел или якорь</td><td>Остановить ответ до адресуемой цитаты</td></tr><tr><td>Все проверки пройдены, но claim не совпадает по смыслу</td><td>Технический допуск не равен семантическому подтверждению</td><td>Сопоставить формулировку claim с точным фрагментом</td><td>Изменить claim, найти другой источник или остановиться</td></tr></tbody></table></div>\n<h2>Воспроизводимый пример: допуск до генерации</h2>\n<p>Ниже — полностью синтетический пример на JavaScript. В нём нет сети, часов операционной системы, реального identity provider или production-данных. Функция сортирует кандидатов только после фильтрации и возвращает явную причину отказа. В настоящем сервисе <code>accessLabels</code> должны приходить из доверенной policy, а не из пользовательского запроса.</p>\n<pre><code>const retrievedAt = '2025-03-17T10:00:00Z';\nconst requesterLabels = new Set(['engineering-read']);\n\nconst candidates = [\n  {\n    recordId: 'adapter-v1',\n    sourceRevision: 'v1',\n    publishedAt: '2025-02-01T09:00:00Z',\n    expiresAt: '2025-03-01T00:00:00Z',\n    accessLabels: ['engineering-read'],\n    citationUri: 'https://docs.example.test/adapter',\n    citationAnchor: '#old-field',\n    vectorScore: 0.97,\n  },\n  {\n    recordId: 'adapter-v3',\n    sourceRevision: 'v3',\n    publishedAt: '2025-03-10T09:00:00Z',\n    expiresAt: '2025-04-01T00:00:00Z',\n    accessLabels: ['engineering-read'],\n    citationUri: 'https://docs.example.test/adapter',\n    citationAnchor: '#schema-upgrade',\n    vectorScore: 0.91,\n  },\n];\n\nfunction admitCandidate(item) {\n  if (!item.sourceRevision) return { ok: false, reason: 'missing-revision' };\n  if (Date.parse(item.expiresAt) &lt;= Date.parse(retrievedAt)) {\n    return { ok: false, reason: 'expired-at-retrieval-time' };\n  }\n  if (!item.accessLabels.some((label) =&gt; requesterLabels.has(label))) {\n    return { ok: false, reason: 'access-label-not-granted' };\n  }\n  if (!item.citationUri || !item.citationAnchor) {\n    return { ok: false, reason: 'missing-exact-citation' };\n  }\n  return { ok: true, item };\n}\n\nconst checked = candidates.map(admitCandidate);\nconst allowed = checked\n  .filter((result) =&gt; result.ok)\n  .map((result) =&gt; result.item)\n  .sort((a, b) =&gt; b.vectorScore - a.vectorScore);\n\nconst decision = allowed.length\n  ? { status: 'needs-human-verification', evidence: allowed[0] }\n  : { status: 'stop', reasons: checked.filter((x) =&gt; !x.ok).map((x) =&gt; x.reason) };\n\nconsole.log(decision);</code></pre>\n<p>У <code>adapter-v1</code> score выше, но редакция истекла до <code>retrievedAt</code>, поэтому первым допустимым evidence становится <code>adapter-v3</code>. Это ещё не автоматическое подтверждение ответа: reviewer должен открыть <code>citationUri#schema-upgrade</code> и убедиться, что фрагмент действительно подтверждает нужную замену. Если разрешённых и адресуемых записей нет, система получает <code>stop</code>. Она не должна возвращаться к старой версии только потому, что та лучше ранжирована.</p>\n<h2>Freshness: дата индекса не делает правило действующим</h2>\n<p>Своевременность нужно определить до внедрения поиска. Для части документации достаточно версии источника и даты публикации. Для быстро меняющегося контракта может понадобиться срок пересмотра, статус deprecation, effective date или проверка владельца. Важно записать policy словами и тестами: например, «после expiresAt запись не участвует в генерации».</p>\n<p>HTTP-метаданные могут быть дополнительным сигналом. RFC 9110 описывает <code>Last-Modified</code> как время, когда origin считает изменённым выбранное представление. Это не равно дате вступления инженерного правила в силу, не описывает права читателя и не доказывает смысл claim. Не следует подменять внутреннюю version документа заголовком ответа CDN или датой попадания chunk в индекс.</p>\n<p>Для воспроизводимости сохраняйте входной <code>retrievedAt</code> и фактически применённую policy. Тогда повторная проверка может ответить, почему вчерашний кандидат был допущен, а сегодняшняя редакция — нет. Если сервис использует eventual consistency и источник читается с реплики, это отдельное ограничение: нужно назвать возможное окно рассогласования и не обещать строгую свежесть без соответствующей гарантии хранилища.</p>\n<h2>Доступ: фильтровать нужно до раскрытия фрагмента</h2>\n<p>Проверку прав нельзя оставлять генератору. Генератор получает только evidence, которые уже прошли authoritative authorization для конкретного requester. Фильтр по метке в поисковом индексе может быть оптимизацией, но не заменяет проверку в системе, владеющей политикой доступа. Иначе ошибка индекса или устаревшая роль может раскрыть excerpt ещё до того, как сервис вернёт отказ.</p>\n<p>Разделяйте безопасный ответ и диагностическую информацию. Пользователю можно сообщить, что подходящий источник недоступен или требует другого доступа. Внутреннему журналу можно записать <code>recordId</code>, policy version и код причины. Не кладите в журнал сам закрытый фрагмент без отдельного основания: диагностический канал тоже имеет владельца и срок хранения.</p>\n<h2>Цитата — это связь claim и места в редакции</h2>\n<p>Ссылка на главную страницу не является точной цитатой. Минимальная citation должна позволять восстановить source revision, URI и anchor; для Markdown или HTML это может быть стабильный заголовок, номер раздела или диапазон строк в immutable-документе. Если источник перемещается, храните идентификатор редакции и проверяйте, что anchor по-прежнему разрешается.</p>\n<p>Пишите ответ только после отбора evidence. Удобный формат — таблица claims: для каждого утверждения указать ссылку, фрагмент, ограничение и статус human verification. Если один фрагмент подтверждает только часть предложения, разделите claim или ослабьте формулировку. Citation, добавленная в конце уже готового текста, не исправляет вывод, который возник без источника.</p>\n<figure><img src='/assets/editorial/2025/knowledge-retrieval-2025-query-retrieval-citation.svg' alt='Схема маршрута от запроса через поиск кандидатов и проверки доступа и свежести к точной цитате; при отсутствии условия ответ останавливается.' loading='lazy' /><figcaption>Score сокращает список для чтения. До ответа доходят только свежая, разрешённая и адресуемая запись, после чего человек проверяет её смысл.</figcaption></figure>\n<h2>Порядок проверки в проекте</h2>\n<ol><li><strong>Опишите scope.</strong> Зафиксируйте query, requester, область документации, источник времени и ожидаемый claim. Не меняйте эти входы во время расследования.</li><li><strong>Сохраните retrieval trace.</strong> Запишите top-k, score, recordId и полный набор metadata. Один текстовый snippet без provenance не подходит для аудита.</li><li><strong>Разрешите источник.</strong> По recordId получите authoritative revision, владельца и статус. Если связь не восстанавливается, остановите использование кандидата.</li><li><strong>Проверьте доступ.</strong> Примените policy к requester до показа excerpt. Отдельно проверьте, что индекс не стал единственным местом принятия решения о правах.</li><li><strong>Проверьте свежесть.</strong> Сравните version и даты с retrievedAt по заранее объявленной policy. Зафиксируйте eventual-consistency window, если он существует.</li><li><strong>Проверьте цитату.</strong> Откройте URI и anchor именно в нужной редакции. Убедитесь, что фрагмент подтверждает claim, а не просто содержит похожие слова.</li><li><strong>Сформируйте ответ.</strong> Передайте генератору только допущенные evidence и их ограничения. Для каждого claim сохраните citation и статус human verification.</li><li><strong>Проверьте отрицательные cases.</strong> Прогоните устаревший high-score, закрытый, безверсийный и без-anchor кандидаты. В каждом случае ответ не должен раскрывать запрещённый текст.</li></ol>\n<h2>Тестовый критерий готовности</h2>\n<p>Маршрут можно считать проверенным на базовом уровне, если один и тот же набор входов даёт четыре предсказуемых исхода: свежая разрешённая запись с anchor проходит технический допуск и помечается как <code>needs-human-verification</code>; просроченная запись получает <code>expired-at-retrieval-time</code>; закрытая — <code>access-label-not-granted</code>; запись без anchor — <code>missing-exact-citation</code>. В последних трёх случаях excerpt не попадает в генерацию.</p>\n<p>Повторный запуск с теми же query, <code>retrievedAt</code>, policy и записями должен дать тот же decision. После этого отдельно измеряйте recall, latency и качество ранжирования. Эти метрики улучшают очередь кандидатов, но не превращают score в доказательство и не заменяют проверку claim.</p>\n<h2>Ограничения применимости</h2>\n<p>Описанный маршрут не доказывает полноту корпуса, качество embeddings, корректность модели, истинность утверждения или отсутствие всех уязвимостей. Он не говорит, что vector search лучше keyword search. Он задаёт более узкую гарантию: система не использует найденный фрагмент как evidence, пока не проверены его provenance, доступ, локальная свежесть и адресуемая цитата.</p>\n<p>Синтетический код не является production-библиотекой: в нём нет транзакций, конкурентного обновления policy, ревокации ролей, подписи источника, кешей и сетевых ошибок. В реальном проекте нужно отдельно проверить escaping, изоляцию tenant, права на логи, версионирование policy и поведение при недоступности authoritative source. Если policy неизвестна, нельзя молча выбрать allow или deny как доказанный результат: нужно назначить владельца правила и вернуть stop condition.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href='https://docs.opensearch.org/latest/vector-search/' target='_blank' rel='noopener noreferrer'>OpenSearch Documentation: Vector search</a> — официальная документация показывает хранение embeddings, поиск ближайших векторов, параметр <code>k</code> и отдельные этапы индексации и поиска. Она подтверждает механику retrieval, но не истинность claim и не права читателя.</li><li><a href='https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.2' target='_blank' rel='noopener noreferrer'>IETF RFC 9110, section 8.8.2: Last-Modified</a> — нормативное описание HTTP-поля, связанного с изменением выбранного представления. RFC не задаёт внутренний срок действия инженерной документации.</li><li><a href='https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf' target='_blank' rel='noopener noreferrer'>NIST SP 800-207: Zero Trust Architecture</a> — официальный документ NIST о явной проверке доступа к ресурсам и отказе от неявного доверия. Он не задаёт конкретный формат vector index или citation.</li></ul>"
+}
diff --git a/editorial/agent-rewrites/103.json b/editorial/agent-rewrites/103.json
index 492152d..df9800e 100644
--- a/editorial/agent-rewrites/103.json
+++ b/editorial/agent-rewrites/103.json
@@ -2,6 +2,6 @@
   "index": 103,
   "slug": "editorial-2025-02-field-ai-code-verification",
   "title": "Как проверить AI-предложение кода до merge",
-  "excerpt": "Зелёный основной сценарий не доказывает сохранность API, входного состояния и правил доступа. Разбираем три границы, отрицательные проверки и критерий готовности изменения.",
-  "contentHtml": "<p>Проблема: основной тест проходит, но изменение возвращает не то поле, меняет входной объект или пропускает запрос без роли; цена ошибки — повторная отладка, задержка релиза и риск отказа пользователю.</p>\\n<p>Тезис простой: проверяйте не убедительность AI-предложения и не число зелёных статусов, а границы контракта. Для каждой границы нужна короткая цепочка доказательств: что обещает код, что наблюдает проверка, какой отрицательный путь рассмотрен и какое действие следует из результата. Если сигналы относятся к разным контрактам, merge нельзя считать готовым.</p>\\n<h2>Механизм: один сигнал закрывает только свой вопрос</h2>\\n<p>Контракт описывает неизменяемое условие. Это форма результата, сохранность аргумента или список разрешённых ролей. Статический анализ показывает структуру кода. Позитивный тест показывает разрешённый путь. Негативный тест показывает отказ. Review связывает эти наблюдения с контекстом вызова. Ручной сценарий проверяет эффект на границе системы.</p>\\n<p>Ни один сигнал не даёт общего вердикта. Линтер не знает, какое имя поля ждёт потребитель. Тест строки не видит мутацию объекта. Успешный сценарий редактора не доказывает запрет для пустой роли. Поэтому сначала назовите риск как наблюдаемый разрыв, затем выберите проверку, которая может его опровергнуть.</p>\\n<h2>Пример 1. Значение верно, форма API нарушена</h2>\\n<p>Mapper получает <code>subtotalCents</code> и <code>taxCents</code>. Он правильно складывает их. Потребитель ожидает объект с полем <code>amountCents</code>, но предложенный код возвращает <code>total</code>. Тест арифметики остаётся зелёным: число не изменилось. Ошибка появляется на границе потребителя.</p>\\n<p>Проверка должна сравнить не только значение, но и публичную форму. Нужны assertion на ключи результата и тест, который читает объект так же, как реальный потребитель. Если переименование действительно нужно, его оформляет владелец API. Нельзя переписать тест под новое поле и объявить проблему решённой: так тест закрепит решение, которого ещё никто не принял.</p>\\n<h2>Пример 2. Preview выдаёт правильный текст, но меняет состояние</h2>\\n<p>Функция с именем <code>preview</code> должна вычислить результат и вернуть его. Внутри она выполняет <code>draft.status = 'normalized'</code>. Caller передал свой объект и ожидает, что после preview он останется прежним. Проверка ответа не замечает побочный эффект, потому что строка выглядит правильно.</p>\\n<p>Здесь нужен снимок входа до вызова и сравнение после вызова. Статическое правило может искать присваивание аргументу, но оно не заменяет проверку владения данными. Исправление — создать производное значение без мутации или вынести изменение в отдельную явно названную операцию. Название функции не является доказательством поведения.</p>\\n<h2>Пример 3. Позитивный путь не защищает правило доступа</h2>\\n<p>Контракт разрешает только роль <code>editor</code>. Условие <code>actorRole !== 'viewer'</code> блокирует <code>viewer</code>, но пропускает запрос без роли. Тест для editor сообщает только один факт: разрешённый путь работает. Даже тест для viewer не подтверждает, что отсутствие значения отклоняется.</p>\\n<p>Явный allow-list делает правило проверяемым:</p>\\n<pre><code>function canEdit(actorRole) {\\n  const allowedRoles = new Set(['editor']);\\n  return allowedRoles.has(actorRole);\\n}\\n\\nexpect(canEdit('editor')).toBe(true);\\nexpect(canEdit('viewer')).toBe(false);\\nexpect(canEdit()).toBe(false);</code></pre>\\n<p>Это учебный пример малого контракта. Он не проверяет токены, identity provider, tenant boundary, сессии или threat model реального приложения. Он показывает другое: разрешённое значение задано явно, а отрицательная ветка входит в контракт. Для production нужны отдельные проверки всей цепочки авторизации.</p>\\n<figure><img src=\"/assets/editorial/2025/ai-code-verification-2025-evidence-chain.svg\" alt=\"Цепочка проверки AI-предложения кода от контракта до решения\" /><figcaption>Цепочка связывает контракт, статический анализ, позитивный и негативный тесты, review и ручной сценарий. Каждый этап отвечает только за свою границу.</figcaption></figure>\\n<h2>Симптом → причина → проверка → действие</h2>\\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Число верно, потребитель не находит поле</td><td>Проверили значение, но не форму результата</td><td>Сравнить ключи и выполнить тест через потребитель</td><td>Вернуть имя поля или принять отдельное решение о совместимости</td></tr><tr><td>Preview меняет draft</td><td>Вычисление смешано с мутацией входа</td><td>Сравнить объект до и после; проверить присваивания аргументу</td><td>Создать производное значение или назвать мутацию отдельной операцией</td></tr><tr><td>Запрос без роли проходит</td><td>Условие перечисляет исключение, а не разрешённые роли</td><td>Добавить проверку отсутствующей роли и прочитать ветви от allow</td><td>Оставить явный allow-list и default-deny</td></tr><tr><td>Все статусы зелёные, но scope различается</td><td>Проверки относятся к разным контрактам</td><td>Сопоставить вход, выход и границу каждого сигнала</td><td>Заблокировать merge до единого scope или решения владельца</td></tr></tbody></table>\\n<h2>Порядок проверки перед merge</h2>\\n<ol><li><strong>Зафиксируйте контракт.</strong> Запишите форму результата, инвариант входа или точный allow-list. Формулировка «код должен быть качественным» не подходит для проверки.</li><li><strong>Определите scope.</strong> Укажите вход, выход, потребителя и границу изменения. Сверьте, что статический анализ, тест и review смотрят на один scope.</li><li><strong>Проверьте основной путь.</strong> Убедитесь, что разрешённый сценарий даёт ожидаемый результат и не меняет состояние сверх контракта.</li><li><strong>Проверьте отрицательный путь.</strong> Добавьте отказ, пустое значение, неверный тип или запрещённую роль — тот случай, который может опровергнуть исходное предположение.</li><li><strong>Проверьте побочные эффекты.</strong> Сравните входное состояние до и после. Для функций <code>preview</code>, <code>format</code> и <code>calculate</code> отдельно подтвердите отсутствие мутации.</li><li><strong>Сработайте stop при расхождении.</strong> Сохраните наблюдение и не продолжайте подготовку merge. Не подменяйте этот шаг автоматическим revert или rollback.</li><li><strong>Сформулируйте вопрос владельцу.</strong> Назовите выбор, недостающее доказательство, полномочие принимающего решение и условие снятия блокировки.</li><li><strong>Повторите проверки после правки.</strong> Новый diff должен пройти тот же контракт, отрицательные сценарии и проверку побочных эффектов.</li></ol>\\n<h2>Что означает stop, а что — revert и rollback</h2>\\n<p>Stop означает только одно: не продолжать подготовку merge, пока доказательства расходятся. Он не меняет историю системы и не восстанавливает доставленное состояние. Revert отменяет конкретное изменение в истории версий. Rollback возвращает уже работающую систему к прежнему состоянию и требует отдельной проверки данных, scope и полномочий. Называть любой block rollback нельзя: это создаёт видимость готового пути восстановления.</p>\\n<p>Human approval нужен после ясной формулировки выбора. Например, владелец может сохранить старое поле ради совместимости, принять переименование с обновлением потребителей или потребовать исправить правило доступа. Approval не закрывает пробел в доказательствах. Если reviewer не может назвать контракт, границу пользователя и остаточный риск, вопрос ещё не готов.</p>\\n<h2>Ограничения</h2>\\n<p>Примеры в статье учебные. В них нет настоящего репозитория, CI, токенов, пользователей, telemetry или production-нагрузки. Имена полей, ролей и функций подобраны для объяснения механизма. Из зелёного учебного теста нельзя вывести отсутствие уязвимости в реальной авторизации. Из одной цепочки доказательств нельзя вывести готовность релиза.</p>\\n<p>Официальная документация инструментов тоже имеет границы. GitHub описывает code review как комментарии и рекомендации, а обязательное решение об изменении остаётся за процессом команды. NIST задаёт практики безопасной разработки, но не выбирает ваши контракты и владельцев риска. OWASP подчёркивает пользу ручной проверки там, где автоматические средства не видят бизнес-логику и контекст. Эти источники поддерживают многослойную проверку, но не подтверждают конкретный учебный пример.</p>\\n<h2>Проверяемый критерий готовности</h2>\\n<p>Изменение готово к approval, если для каждой затронутой границы выполнены четыре условия: контракт записан; основной и отрицательный пути проверены; входное состояние не меняется без явного разрешения; каждый сигнал относится к тому же scope, что и diff. В записи есть вердикт <code>merge</code>, <code>revise</code> или <code>block</code>. Для merge указан владелец решения. Для block указано доказательство, которое снимет блокировку. Если хотя бы одно условие не выполнено, готовность не доказана.</p>\\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review\" target=\"_blank\" rel=\"noopener\">GitHub Docs: Using GitHub Copilot code review</a></li><li><a href=\"https://www.nist.gov/publications/secure-software-development-framework-ssdf-version-11-recommendations-mitigating-risk\" target=\"_blank\" rel=\"noopener\">NIST: Secure Software Development Framework (SSDF) Version 1.1</a></li><li><a href=\"https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener\">OWASP: Secure Code Review Cheat Sheet</a></li></ul>"
+  "excerpt": "Зелёный happy path не доказывает сохранность API и правил доступа. На примере трёх границ разбираем отрицательные тесты, команды проверки и критерий готовности изменения.",
+  "contentHtml": "<p>AI-ассистент предложил короткое исправление: основной тест прошёл, diff выглядел аккуратно, а запрос без роли всё равно получил доступ к операции. Такой дефект легко пропустить, потому что проверка ответа и проверка права отвечают на разные вопросы. Цена ошибки — не только повторная отладка: при неверной авторизации пользователь может прочитать или изменить чужой ресурс.</p>\n<p>Надёжный вопрос перед merge звучит так: какой контракт меняется, где находится граница доверия и каким наблюдением можно опровергнуть предложение? AI не является доказательством. Он ускоряет перебор вариантов, но каждое принятое утверждение нужно проверить в коде, тесте и контексте системы.</p>\n<h2>Сначала зафиксируйте границу изменения</h2>\n<p>Начните с diff, а не с объяснения ассистента. Запишите вход, выход, потребителя и правило, которое нельзя нарушить. Для функции доступа это субъект, действие и ресурс; для mapper — форма результата; для функции <code>preview</code> — неизменность входного состояния. Одно предложение может затронуть сразу несколько границ, даже если изменена одна строка.</p>\n<pre><code>git diff --check\ngit diff --unified=80 -- src/auth/can-edit.ts\nrg -n 'canEdit|authorize|role|tenant|owner' src test</code></pre>\n<p>Первые две команды показывают пробельные ошибки и полный локальный контекст. Третья помогает найти параллельные точки входа, но не доказывает, что найден полный граф вызовов. Имена каталогов здесь примерны: в конкретном репозитории подставьте фактические пути, а результат поиска сопоставьте с маршрутом запроса.</p>\n<h2>Граница API: правильное число не спасает неправильную форму</h2>\n<p>Представим mapper, который получает <code>subtotalCents</code> и <code>taxCents</code>. AI заменил поле ответа на <code>total</code>. Арифметика осталась верной, поэтому тест, сравнивающий только число, зелёный. Потребитель читает <code>amountCents</code> и получает <code>undefined</code>. Это не «мелкое переименование»: форма ответа — часть контракта.</p>\n<p>Проверяйте ключи и способ чтения результата тем же кодом, который использует приложение. Если изменение имени действительно нужно, сначала меняется контракт и все потребители, а затем тесты. Переписать assertion под новый ключ — не исправление, пока владелец API не принял несовместимое изменение.</p>\n<pre><code>function toAmount({ subtotalCents, taxCents }) {\n  return { amountCents: subtotalCents + taxCents };\n}\n\nconst result = toAmount({ subtotalCents: 1000, taxCents: 180 });\nif (JSON.stringify(Object.keys(result)) !== JSON.stringify(['amountCents'])) {\n  throw new Error('response shape changed');\n}\nif (result.amountCents !== 1180) {\n  throw new Error('amount calculation changed');\n}</code></pre>\n<p>Этот фрагмент проверяет учебный объект и порядок ключей, заданный самим примером. В production контракт лучше закрепить схемой или типом и тестом реального потребителя; здесь намеренно показана минимальная проверка, которую можно запустить без фреймворка.</p>\n<h2>Граница состояния: preview не должен незаметно мутировать вход</h2>\n<p>Вторая ловушка — побочный эффект под безобидным именем. Функция <code>preview</code> должна построить представление, но предложенная реализация присваивает <code>draft.status = 'normalized'</code>. Caller передал собственный объект и после preview ожидает исходный статус. Проверка только строки ответа этого не увидит.</p>\n<p>Снимите состояние до вызова и сравните его после. Для простого плоского объекта пример выглядит так:</p>\n<pre><code>function preview(draft) {\n  return { ...draft, status: 'normalized' };\n}\n\nconst draft = { id: 'd-17', status: 'new' };\nconst before = JSON.stringify(draft);\nconst view = preview(draft);\n\nif (JSON.stringify(draft) !== before) {\n  throw new Error('preview mutated input');\n}\nif (view.status !== 'normalized' || draft.status !== 'new') {\n  throw new Error('preview contract failed');\n}</code></pre>\n<p>Поверхностная копия не защищает вложенные массивы и объекты: если функция меняет <code>draft.items[0]</code>, понадобится глубокая копия, иммутабельная структура или отдельный тест на каждый изменяемый уровень. Поэтому нельзя автоматически заменить любой <code>Object.assign</code> на знак качества. Сначала определите владение данными и разрешённые мутации.</p>\n<h2>Граница доступа: allow-list сильнее списка исключений</h2>\n<p>Третий пример — проверка роли. Условие <code>actorRole !== 'viewer'</code> блокирует viewer, но пропускает <code>undefined</code>, опечатку и любую новую строку. Happy path для editor и даже отрицательный тест только для viewer не закрывают эту дыру.</p>\n<p>Если в учебном контракте разрешена ровно одна роль, разрешённое множество должно быть явным, а неизвестное значение — отклоняться:</p>\n<pre><code>function canEdit(actorRole) {\n  const allowedRoles = new Set(['editor']);\n  return allowedRoles.has(actorRole);\n}\n\nfor (const [role, expected] of [\n  ['editor', true],\n  ['viewer', false],\n  [undefined, false],\n  ['edtiro', false],\n]) {\n  if (canEdit(role) !== expected) {\n    throw new Error('unexpected decision for ' + String(role));\n  }\n}</code></pre>\n<p>Это тест чистой функции, а не всей авторизации. В реальном запросе нужно проверить, откуда взялась identity, кто выбирает tenant и ресурс, где сервер принимает решение и что происходит при отказе. Проверка роли в браузере может улучшить интерфейс, но не должна выдавать доступ: решающий контроль находится на сервере, шлюзе или серверной функции.</p>\n<h2>Почему зелёные сигналы расходятся</h2>\n<table><thead><tr><th>Сигнал</th><th>Что он доказывает</th><th>Чего не доказывает</th><th>Следующее действие</th></tr></thead><tbody><tr><td>Unit-тест happy path</td><td>Разрешённый вход даёт ожидаемый результат</td><td>Отказ, форма ответа, побочные эффекты и соседний ресурс</td><td>Добавить отрицательный и contract-тест</td></tr><tr><td>Линтер или SAST</td><td>Найден или не найден известный шаблон</td><td>Бизнес-правило и смысл конкретного ресурса</td><td>Разобрать finding вручную по data flow</td></tr><tr><td>AI code review</td><td>Ассистент сформулировал комментарии в scope review</td><td>Полноту находок и обязательное решение владельца</td><td>Проверить комментарии и повторить review после нового diff</td></tr><tr><td>Ручной сценарий</td><td>Наблюдаемое поведение на выбранном окружении</td><td>Другие входы, окружения и параллельные entry point</td><td>Закрепить сценарий автоматическим тестом</td></tr><tr><td>Approval</td><td>Уполномоченный принял решение по известному scope</td><td>Отсутствие неизвестных рисков</td><td>Записать остаточный риск и условия отката</td></tr></tbody></table>\n<p>Разные статусы не складываются в магическое «всё безопасно». У каждого сигнала есть scope и слепая зона. Например, GitHub описывает Copilot code review как источник комментариев; по умолчанию это не approval, а автоматическая оценка готовности сама по себе не считается обязательным подтверждением. Это важное различие между подсказкой инструмента и полномочием на merge.</p>\n<h2>Воспроизводимая последовательность перед merge</h2>\n<ol><li><strong>Опишите инвариант.</strong> Запишите точную форму ответа, условие неизменности или пару «субъект — действие — ресурс». Слово «качественно» нельзя проверить.</li><li><strong>Определите scope.</strong> Перечислите изменённые файлы, входы, выходы, потребителей и серверные точки доступа. Для security-изменения отдельно отметьте trust boundary.</li><li><strong>Запустите базовые проверки.</strong> Выполните форматтер, typecheck, unit-тесты и <code>git diff --check</code>. Сохраните команды и версии инструментов.</li><li><strong>Проверьте разрешённый путь.</strong> Сравните значение, тип, форму ответа и побочные эффекты. Тест должен читать результат как реальный потребитель.</li><li><strong>Добавьте отрицательные входы.</strong> Используйте отсутствующее значение, неверную роль, чужой tenant, другой идентификатор ресурса и отказ downstream — только те варианты, которые входят в модель угроз.</li><li><strong>Проследите поток данных.</strong> Найдите источник identity, место авторизационного решения и обработку отказа. Не считайте клиентский флаг или скрытую кнопку защитой.</li><li><strong>Повторите review по новому diff.</strong> После исправления проверяется не старый комментарий, а обновлённый scope. Если сигнал относится к другой версии кода, он не подтверждает текущий merge.</li><li><strong>Выберите вердикт.</strong> <code>merge</code> означает, что заявленные проверки пройдены; <code>revise</code> — известен следующий фикс; <code>block</code> — есть расхождение, которое должен снять владелец риска.</li></ol>\n<p>Минимальный журнал проверки может быть обычным текстом в описании изменения:</p>\n<pre><code>scope: src/auth/can-edit.ts, test/auth/can-edit.test.ts\ncontract: only editor may edit a resource in the actor's tenant\npositive: editor + own tenant -> allow\nnegative: viewer, missing role, other tenant -> deny\nside_effects: request context unchanged\nchecks: npm test -- can-edit && git diff --check\nowner: team-auth\nverdict: revise</code></pre>\n<p>Строка <code>verdict: revise</code> здесь не формальность: если не проверен чужой tenant, честный результат — не merge. Журнал не заменяет тест и не делает проект безопасным, но оставляет проверяемую связь между риском, наблюдением и решением.</p>\n<h2>Что делать при расхождении evidence</h2>\n<p>Если форма API не совпала с потребителем, остановите подготовку merge и найдите владельца контракта. Если preview мутирует данные, зафиксируйте вход до и после, затем выберите иммутабельный результат или явно названную мутацию. Если запрос без роли или с чужим tenant получает доступ, блокируйте изменение до серверной проверки и негативного теста.</p>\n<p>Stop, revert и rollback — разные действия. Stop не меняет историю и лишь запрещает продолжать merge. Revert создаёт новое изменение, отменяющее конкретный коммит. Rollback возвращает уже доставленную систему к прежнему состоянию и требует отдельного плана для данных, миграций, флагов и совместимости. Не называйте блокировку rollback: это создаёт ложное ощущение, что восстановление уже подготовлено.</p>\n<h2>Ограничения применимости</h2>\n<p>Примеры выше — небольшие чистые функции, а не доказательство безопасности приложения. Они не проверяют токены, identity provider, срок сессии, CSRF, rate limit, кеши, гонки, multi-tenant запросы, базу данных, конфигурацию шлюза или эксплуатационные права. Даже полный набор unit-тестов не исключает дефект в маршруте, middleware или другом entry point.</p>\n<p>Allow-list подходит для показанного правила с одной ролью, но не заменяет policy engine для сложных правил, где важны атрибуты ресурса, отношения владельца, время и состояние. Для таких систем тестируйте таблицу разрешений и отказов на уровне API и интеграции. Секреты, персональные данные и production-токены нельзя помещать в prompt или учебный репозиторий; используйте обезличенные фикстуры.</p>\n<p>Официальные рекомендации также не являются сертификатом. OWASP говорит, что ручной security-review дополняет автоматические инструменты и особенно нужен для бизнес-логики, потоков данных и контекстных уязвимостей. NIST SSDF задаёт общий набор практик безопасной разработки и общий словарь, но не выбирает контракт конкретного сервиса. Эти документы помогают построить процесс, а границы и остаточный риск всё равно определяет команда.</p>\n<h2>Критерий готовности</h2>\n<p>AI-предложение готово к merge, когда можно независимо ответить на четыре вопроса: какой контракт оно меняет; какой позитивный и какой отрицательный путь проверены; где выполняется окончательная проверка доступа; какой владелец принял остаточный риск. К ответам приложены текущий diff, воспроизводимые команды и результат тестов.</p>\n<p>Если хотя бы один вопрос остаётся без наблюдаемого ответа, меняйте статус на <code>revise</code> или <code>block</code>. Такой вердикт не обвиняет инструмент и не требует отказаться от AI. Он просто оставляет merge только для изменения, чья граница, проверка и ответственность видны.</p>\n<figure><img src=\"/assets/editorial/2025/ai-code-verification-2025-evidence-chain.svg\" alt=\"Схема проверки AI-изменения: diff проходит через контракт, статический анализ, позитивный и негативный тесты, review и ручной сценарий\" /><figcaption>Каждый этап отвечает на свой вопрос. При расхождении scope подготовку merge останавливают и формулируют вопрос владельцу риска; сама подсказка AI не становится разрешением на доставку.</figcaption></figure>\\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review\" target=\"_blank\" rel=\"noopener\">GitHub Docs: Using GitHub Copilot code review</a> — scope review, комментарии и ограничения approval assessment.</li><li><a href=\"https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener\">OWASP: Secure Code Review Cheat Sheet</a> — diff-based review, trust boundaries, автоматические инструменты и ручной анализ.</li><li><a href=\"https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener\">OWASP: Authorization Cheat Sheet</a> — deny by default, проверка каждого запроса и серверное enforcement.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/218/final\" target=\"_blank\" rel=\"noopener\">NIST SP 800-218: Secure Software Development Framework (SSDF) 1.1</a> — рамка практик для снижения риска уязвимостей и общий язык процесса.</li></ul>\n"
 }
diff --git a/editorial/agent-rewrites/104.json b/editorial/agent-rewrites/104.json
index 378b120..2605e83 100644
--- a/editorial/agent-rewrites/104.json
+++ b/editorial/agent-rewrites/104.json
@@ -1,7 +1,7 @@
 {
   "index": 104,
   "slug": "editorial-2025-02-mechanism-ai-code-verification",
-  "title": "Как проверить сгенерированный код, когда зелёных сигналов недостаточно",
-  "excerpt": "Сгенерированный diff может пройти линтер и happy path, но нарушить контракт, изменить чужое состояние или пропустить отрицательную ветку. Разбираем, как связать риск с независимой проверкой и когда остановить merge.",
-  "contentHtml": "<p>Сгенерированный diff может пройти линтер и unit test, но сломать следующего потребителя. Mapper вернул число, хотя API требует поле <code>amountCents</code>. Функция <code>preview</code> показала правильную строку, но изменила объект, который передал вызывающий код. Проверка роли пропустила редактора, но не проверила отсутствие роли.</p>\n<p>Цена ошибки начинается не с плохого ответа модели. Она начинается с ложной уверенности. Команда видит несколько зелёных статусов, считает риск закрытым и узнаёт о нарушенной границе в следующем consumer, review или релизном сценарии. По числу зелёных индикаторов нельзя вывести размер ущерба. Но можно заранее не принять их за одно доказательство.</p>\n<p>Тезис статьи простой: проверка должна связывать наблюдаемый риск с конкретным свидетельством. Контракт проверяет форму и инварианты. Статический анализ ищет формальный паттерн. Узкий тест проверяет названную ветку. Человек проверяет намерение и контекст. Ручной сценарий смотрит на путь потребителя. Эти способы пересекаются, но не заменяют друг друга.</p>\n<h2>Механизм: риск → свидетельство → граница</h2>\n<p>Начните не с инструмента, а с разрыва. «AI ошибся» не помогает выбрать проверку. «Публичное поле переименовано», «входной объект изменился после вызова» и «пустая роль получила доступ» уже задают наблюдаемые вопросы.</p>\n<p>Затем выберите свидетельство, которое может опровергнуть именно этот разрыв. Для формы результата подойдёт assertion на схему и тест реального consumer. Для ownership нужен снимок входа до и после вызова. Для доступа нужен allow-list и отрицательный тест для неизвестного значения. Если check не способен увидеть риск, его зелёный результат ничего о риске не говорит.</p>\n<p>Последняя часть — граница. Контракт не доказывает безопасность всей системы. Линтер не понимает смысл каждого вызова. Тест не проверяет ветку, которую в него не внесли. Review зависит от контекста и внимания. Ручное воспроизведение не становится регрессионным тестом само по себе.</p>\n<figure><img src=\"/assets/editorial/2025/ai-code-verification-2025-risk-detection-matrix.svg\" alt=\"Матрица риска и проверок для сгенерированного diff\"><figcaption>Матрица связывает классы риска с проверками. Зелёная клетка означает релевантное свидетельство, а не гарантию отсутствия ошибки.</figcaption></figure>\n<h2>Три учебных примера</h2>\n<p>Ниже приведены фиксированные учебные случаи. Они не читают репозиторий, не вызывают модель и не показывают результат реального проекта. Их задача — показать форму рассуждения: наблюдение, причина, проверка и действие.</p>\n<h3>1. Число верно, форма API неверна</h3>\n<p>Контракт mapper требует объект <code>{ amountCents: number }</code>. Сгенерированный код складывает <code>subtotalCents</code> и <code>taxCents</code>, но возвращает <code>{ total: 1234 }</code>. Happy-path test проверяет только значение суммы. Он зелёный: арифметика правильная.</p>\n<p>Потребитель читает <code>result.amountCents</code> и получает <code>undefined</code>. Симптом — зелёный тест рядом с неверной формой результата. Причина — тест описывает значение, а не публичный shape. Проверка — сравнить assertion контракта, тест consumer и вопрос reviewer: «Переименование поля принято отдельно?». Действие — вернуть <code>amountCents</code> или оформить совместимость как отдельное решение. Нельзя переписать тест на <code>total</code> только ради зелёного статуса.</p>\n<h3>2. Preview меняет входной объект</h3>\n<p>Helper с именем <code>preview</code> получает объект заявки и возвращает правильный текст. Внутри он выполняет <code>draft.status = 'normalized'</code>. Если объект принадлежит caller, после preview следующий код видит изменённое состояние. Результат на экране правильный, но операция имеет побочный эффект.</p>\n<pre><code>function preview(draft) {\\n  draft.status = 'normalized'; // скрыто меняет объект caller\\n  return render(draft);\\n}\\n\\nconst draft = { status: 'raw' };\\nconst text = preview(draft);\\n\\n// text выглядит правильно, но draft.status уже равен 'normalized'</code></pre>\n<p>Симптом — output совпал, а state изменился. Причина — контракт не разделяет производное значение и владение входом. Проверка — сравнить вход до и после вызова и отдельно просмотреть записи в аргумент. Действие — создать производный объект, оставить аргумент неизменным или назвать мутацию отдельной операцией. Проверка результата строки здесь недостаточна.</p>\n<h3>3. Accept-case не доказывает default-deny</h3>\n<p>Учебный контракт разрешает роль <code>editor</code> и отклоняет <code>viewer</code> и отсутствие роли. Условие <code>actorRole !== 'viewer'</code> пропускает редактора, отклоняет viewer, но также пропускает <code>undefined</code>. Если suite содержит только тест редактора, она доказывает один accept path и ничего не говорит о неизвестном значении.</p>\n<p>Это не доказанная уязвимость реальной авторизации: в примере нет токенов, tenant boundary, identity provider и threat model. Но конкретный контракт уже нарушен. Проверка должна включить viewer и missing-role, а reviewer должен прочитать условие как allow-list. Для доступа отрицательная ветка — часть правила, а не дополнительный тест «на всякий случай».</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Тест проверяет число, consumer не находит поле</td><td>Значение приняли за форму API</td><td>Contract assertion и consumer test</td><td>Сохранить поле или принять отдельное compatibility decision</td></tr><tr><td>Preview возвращает правильный текст, вход изменился</td><td>Не определено владение аргументом</td><td>Сравнить input до/после и найти запись в аргумент</td><td>Вернуть derived value без мутации или назвать мутацию явно</td></tr><tr><td>Редактор проходит, пустая роль тоже</td><td>Accept-case заменил allow-list</td><td>Проверить viewer и missing-role</td><td>Явно разрешить роли и отклонять неизвестные</td></tr><tr><td>Линтер зелёный, риск не назван</td><td>Для риска нет формального правила</td><td>Сверить scope правила с contract boundary</td><td>Добавить assertion, тест или вопрос reviewer</td></tr></tbody></table>\n<h2>Почему независимость важнее количества</h2>\n<p>Два свидетельства независимы не потому, что их назвали разными словами. Они независимы, когда могут опровергнуть разные предпосылки. Contract check и consumer test частично пересекаются: один смотрит на declared shape, другой — на использование поля. Это полезное пересечение. Ошибка в одном тесте не должна автоматически скрыть ошибку в другом.</p>\n<p>Опаснее повторить одну неверную модель. Сгенерированный код и сгенерированный тест могут вместе решить, что отсутствие роли означает «не viewer». Второй зелёный статус тогда только усиливает доверие к ошибке. Добавьте проверку, которая получает другое основание: allow-list, внешний контракт или вопрос владельцу политики.</p>\n<p>Не нужно складывать статусы в процент корректности. Static check быстро ловит формальный паттерн, но требует правила. Focused test делает один сценарий воспроизводимым, но не видит неназванную ветку. Human review замечает скрытую границу, но не заменяет точный expected result. Manual reproduction показывает путь потребителя, но плохо масштабируется. Выбирайте самый дешёвый способ, который способен оспорить текущую гипотезу.</p>\n<h2>Минимальный учебный прогон</h2>\n<p>В этом примере report собирает пять видов свидетельств. При расхождении он не превращает результат в «почти готово». Он возвращает решение остановить подготовку merge до выяснения контракта.</p>\n<pre><code>const report = inspectGeneratedDiff({\\n  risk: 'public-field-renamed',\\n  contract: { amountCents: 'number' },\\n  result: { total: 1234 },\\n  checks: ['static', 'focused-test', 'review', 'manual']\\n});\\n\\nif (report.contractAgrees === false) {\\n  return { merge: 'blocked', reason: 'evidence-disagrees' };\\n}</code></pre>\n<p>Код выше — учебная схема, а не готовый пакет и не production-рецепт. Она показывает важное свойство: решение опирается на конкретное расхождение, а не на число пройденных команд. В реальном проекте названия полей, правила и тестовые входы должны соответствовать фактическому контракту.</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Сузьте scope.</strong> Назовите один diff, одну границу контракта и один ожидаемый эффект.</li><li><strong>Запишите риск наблюдаемым разрывом.</strong> Укажите поле, состояние, роль или побочный эффект, который может нарушиться.</li><li><strong>Выберите прямое свидетельство.</strong> Добавьте contract assertion, статическое правило, positive/negative test или consumer scenario по смыслу риска.</li><li><strong>Проверьте повтор предпосылки.</strong> Спросите, не повторяют ли code и test одно ошибочное правило.</li><li><strong>Запишите stop condition.</strong> Например: «contract и consumer test требуют разные поля» или «input boundary не доказана».</li><li><strong>Передайте вопрос владельцу.</strong> После сбора фактов попросите выбрать revise, compatibility decision или approval остаточного риска.</li></ol>\n<h2>Ограничения</h2>\n<p>Эта схема не доказывает корректность кода, безопасность, отсутствие дефектов или готовность релиза. Она не заменяет threat model, анализ зависимостей, интеграционные тесты, наблюдение и правила доступа. Один учебный отрицательный тест не покрывает все реальные роли и переходы состояний.</p>\n<p>Stop означает только «не продолжать подготовку merge при расхождении evidence». Он не означает revert или rollback. Revert требует решения о конкретном изменении в истории VCS. Rollback относится к уже доставленному состоянию и требует подтверждённого пути восстановления. Не подменяйте отсутствие решения словом rollback.</p>\n<p>Источники тоже не дают готового verdict. Они поддерживают практику, но не выбирают порог для вашего репозитория. GitHub описывает Copilot code review как комментарий, который не заменяет required approval. NIST связывает review и analysis с процессом разработки и triage findings. OWASP подчёркивает, что автоматизированные инструменты дополняют ручной анализ там, где нужен бизнес-контекст.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review\" target=\"_blank\" rel=\"noopener\">GitHub Docs: Using GitHub Copilot code review</a> — статус комментария и границы approval.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/218/final\" target=\"_blank\" rel=\"noopener\">NIST SP 800-218 SSDF 1.1</a> — review, analysis и обработка findings в процессе разработки.</li><li><a href=\"https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener\">OWASP Secure Code Review Cheat Sheet</a> — сочетание автоматизированных инструментов и ручной проверки.</li></ul>\n<h2>Проверяемый критерий готовности</h2>\n<p>Diff готов к передаче на human approval только тогда, когда для каждого заявленного риска записаны scope, прямое свидетельство, отрицательный путь и граница того, чего проверка не доказывает. Contract, test и reviewer rationale не должны противоречить друг другу. Если противоречие осталось, готовый результат — не зелёный статус, а понятный stop с вопросом владельцу.</p>"
+  "title": "Почему зелёный тест не доказывает корректность сгенерированного кода",
+  "excerpt": "Разбираем, как проверять сгенерированный diff по контракту, состоянию, отрицательной ветке и пути потребителя — и когда расхождение доказательств должно остановить merge.",
+  "contentHtml": "<p>Проблема начинается там, где зелёный unit-тест отвечает только на тот вопрос, который в него записали. Он может подтвердить сумму, но не имя публичного поля; правильную строку — но не отсутствие мутации; доступ редактора — но не отказ неизвестной роли. Поэтому сгенерированный diff принимают не по числу зелёных статусов, а по совпадению контракта, наблюдаемого поведения и решения владельца границы.</p>\n<p>Ниже — учебный разбор небольшого JavaScript-изменения. Он не читает репозиторий, не запускает модель и не описывает реальный инцидент. Все входы фиксированы, а код можно выполнить локально штатным Node.js. Это позволяет проверить сам способ рассуждения и не приписывать примеру доказательств, которых он не собирает.</p>\n<h2>Сначала определите, что должно остаться неизменным</h2>\n<p>Контракт — это не фраза «функция работает правильно». Для проверки diff запишите вход, форму результата и запрещённое побочное действие. Если функция участвует в авторизации, добавьте правило отказа для неизвестного значения. Такой список превращает размытый риск в наблюдаемый вопрос.</p>\n<pre><code>const contract = {\n  input: { subtotalCents: 900, taxCents: 100 },\n  output: { amountCents: 1000 },\n  invariant: 'input remains unchanged',\n  deny: [undefined, 'viewer']\n};</code></pre>\n<p>В этом контракте четыре разных утверждения. <code>amountCents</code> задаёт публичную форму ответа, сумма — его значение, <code>input remains unchanged</code> — границу владения состоянием, а <code>deny</code> — отрицательные варианты политики. Один assertion не способен подтвердить их все.</p>\n<p>Официальный Secure Software Development Framework NIST описывает безопасную разработку как набор практик, который встраивается в жизненный цикл продукта. Это полезная рамка для процесса, но не автоматический сертификат корректности конкретного diff. Для локальной проверки всё равно нужно назвать инвариант и способ его опровергнуть.</p>\n<figure><img src=\"/assets/editorial/2025/ai-code-verification-2025-risk-detection-matrix.svg\" alt=\"Матрица связывает четыре риска с контрактной, статической, тестовой, ручной и экспертной проверкой\"><figcaption>Один риск может иметь несколько релевантных способов проверки. Знак в матрице означает подходящее свидетельство, а не гарантию безопасности или корректности.</figcaption></figure>\n<h2>Учебный diff: арифметика верна, контракт нарушен</h2>\n<p>Представим mapper, который готовит данные для счёта. Его контракт требует <code>amountCents</code>, а consumer читает именно это поле. Ассистент сгенерировал короткую функцию и тест, проверяющий только итоговое число:</p>\n<pre><code>function toInvoice(input) {\n  return {\n    total: input.subtotalCents + input.taxCents\n  };\n}\n\nconst result = toInvoice({ subtotalCents: 900, taxCents: 100 });\nconsole.assert(result.total === 1000);</code></pre>\n<p>Тест зелёный, потому что арифметика действительно даёт 1000. Но следующий consumer делает <code>result.amountCents</code> и получает <code>undefined</code>. Ошибка находится на границе формы ответа, а не в вычислении. Если заменить контракт в тесте на фактическое поведение функции, можно получить ещё один зелёный статус и сохранить дефект.</p>\n<p>Проверка должна смотреть на потребителя и на ключ результата:</p>\n<pre><code>const input = { subtotalCents: 900, taxCents: 100 };\nconst result = toInvoice(input);\n\nconsole.assert(result.amountCents === 1000);\nconsole.assert(Object.hasOwn(result, 'amountCents'));\nconsole.assert(!Object.hasOwn(result, 'total'));\nconsole.assert(input.subtotalCents === 900);\nconsole.assert(input.taxCents === 100);</code></pre>\n<p>После такого теста причина видна сразу: первая функция вернёт ошибку на assertion для <code>amountCents</code>. При этом проверка не доказывает, что все consumers, сериализаторы и реальные ответы системы используют ту же схему. Она доказывает только перечисленные свойства фиксированного вызова.</p>\n<h2>Воспроизводимый прогон без внешних пакетов</h2>\n<p>Чтобы не спорить о слове «прошло», запустите минимальный независимый скрипт. Он проверяет три свойства: публичное поле, отсутствие мутации входа и default-deny для ролей. Команда использует только встроенный Node.js; версия Node должна поддерживать <code>Object.hasOwn</code> (Node.js 16.9 и новее).</p>\n<pre><code>node --input-type=module &lt;&lt;'NODE'\nfunction toInvoice(input) {\n  return { amountCents: input.subtotalCents + input.taxCents };\n}\n\nfunction canEdit(role) {\n  return role === 'editor';\n}\n\nconst input = { subtotalCents: 900, taxCents: 100 };\nconst result = toInvoice(input);\nconst checks = {\n  shape: result.amountCents === 1000 &amp;&amp; !Object.hasOwn(result, 'total'),\n  noMutation: input.subtotalCents === 900 &amp;&amp; input.taxCents === 100,\n  defaultDeny: canEdit('editor') &amp;&amp; !canEdit('viewer') &amp;&amp; !canEdit(undefined)\n};\n\nfor (const [name, ok] of Object.entries(checks)) {\n  console.log((ok ? 'PASS ' : 'FAIL ') + name);\n}\nif (Object.values(checks).some((ok) =&gt; !ok)) process.exitCode = 1;\nNODE</code></pre>\n<p>Ожидаемый вывод — три строки <code>PASS</code>. Если изменить возвращаемое поле на <code>total</code>, заменить <code>role === 'editor'</code> на проверку «не viewer» или присвоить что-либо в <code>input</code>, соответствующая строка станет <code>FAIL</code>, а процесс завершится с ненулевым кодом. Это воспроизводимое наблюдение, не измерение «процента качества AI».</p>\n<h2>Сопоставьте риск с прямым свидетельством</h2>\n<table><caption>Какая проверка отвечает на какой вопрос</caption><thead><tr><th>Риск</th><th>Прямое свидетельство</th><th>Что остаётся вне проверки</th><th>Следующее действие</th></tr></thead><tbody><tr><td>Публичное поле переименовано</td><td>Assertion схемы и тест consumer</td><td>Другие consumers и совместимость API</td><td>Сверить контракт всех затронутых границ</td></tr><tr><td>Preview меняет входной объект</td><td>Снимок input до и после вызова</td><td>Мутации глубоко вложенных или внешних объектов</td><td>Уточнить ownership и проверить нужную глубину</td></tr><tr><td>Неизвестная роль получает доступ</td><td>Allow-list плюс тесты viewer и missing role</td><td>Проверка identity, tenant и серверного enforcement</td><td>Подключить владельца политики и threat model</td></tr><tr><td>Секрет или данные уходят в AI-инструмент</td><td>Проверка отправляемого контекста и правил исключения</td><td>Практики конкретного провайдера и конфигурация организации</td><td>Проверить настройки и журнал фактического обмена</td></tr><tr><td>Линтер не видит бизнес-ошибку</td><td>Предметный review и тест правила</td><td>Неназванные сценарии и неверный бизнес-контекст</td><td>Записать invariant и отрицательный путь</td></tr></tbody></table>\n<p>Матрица не складывает свидетельства в одну оценку. У каждого способа есть область действия. Static analysis хорошо находит формальный паттерн, если для него есть правило. Узкий тест делает конкретный вход воспроизводимым. Review проверяет смысл и границы, но зависит от контекста. Ручной сценарий повторяет маршрут потребителя, но покрывает только выбранный путь.</p>\n<h2>Почему независимость важнее количества запусков</h2>\n<p>Два теста независимы, когда способны обнаружить разные нарушения. Тест на сумму и screenshot с отображённой суммой могут повторять одну и ту же предпосылку: «полученное значение достаточно». Ни один из них не обязан заметить, что API ждёт другое имя поля. Тест consumer задаёт уже другой вопрос — может ли следующий участник прочитать результат.</p>\n<p>Генерация кода и теста одним инструментом создаёт дополнительный риск: оба фрагмента могут повторить неверное толкование требования. Поэтому для security-критичных правил нужен источник, не скопированный из того же предположения: явный allow-list, контракт владельца, независимый тестовый вход или проверка специалистом. OWASP описывает ручной code review как дополнение к автоматизированным инструментам там, где нужны бизнес-контекст и анализ логики.</p>\n<p>Документация GitHub отдельно оговаривает границу Copilot code review: такой review оставляет комментарии и не считается обязательным approval для pull request. Для других AI-инструментов правила могут отличаться, поэтому название продукта нельзя превращать в универсальное утверждение. Общий вывод уже: автоматический комментарий не заменяет решение человека, которому принадлежит риск.</p>\n<h2>Проверьте отрицательный путь, а не только happy path</h2>\n<p>Отрицательный тест выводится из правила. Для доступа безопаснее перечислить разрешённые роли, чем разрешать всё, что не равно одной запрещённой роли. Для mapper нужно проверить форму и отсутствие старого ключа. Для функции без побочных эффектов — сравнить состояние после вызова. В каждом случае вопрос звучит как «что должно быть отвергнуто?», а не только «что должно сработать?».</p>\n<pre><code>function canEdit(role) {\n  return role === 'editor';\n}\n\nconsole.assert(canEdit('editor') === true);\nconsole.assert(canEdit('viewer') === false);\nconsole.assert(canEdit(undefined) === false);\nconsole.assert(canEdit('admin') === false);</code></pre>\n<p>Этот пример проверяет только функцию для четырёх строковых входов. Он не доказывает авторизацию приложения: здесь нет identity provider, проверки владельца ресурса, tenant boundary, токена, серверного маршрута и журнала событий. Переносить его verdict в production можно только после добавления фактических условий политики.</p>\n<h2>Порядок ревью одного небольшого diff</h2>\n<ol><li><strong>Сузьте область.</strong> Назовите изменённый компонент, consumer и границу, которую нельзя нарушить.</li><li><strong>Запишите контракт.</strong> Укажите вход, выход, допустимое состояние после вызова и условие отказа.</li><li><strong>Составьте карту рисков.</strong> Отдельно отметьте shape, побочные эффекты, доступ, данные и ошибки внешних зависимостей.</li><li><strong>Выберите прямую проверку.</strong> Используйте assertion, статическое правило, focused test или ручной сценарий только там, где он способен увидеть риск.</li><li><strong>Добавьте отрицательный вход.</strong> Проверьте отсутствующее поле, неизвестную роль, старый формат, повторный вызов или отказ зависимости — согласно контракту.</li><li><strong>Сравните независимые основания.</strong> Убедитесь, что generated code и test не подтверждают одну и ту же ошибочную предпосылку.</li><li><strong>Зафиксируйте blind spot.</strong> Запишите, чего выбранная проверка не доказывает и кто принимает остаточный риск.</li><li><strong>Остановите подготовку merge при расхождении.</strong> Сначала исправьте код, явно измените контракт или получите решение владельца; не подгоняйте assertion под фактический дефект.</li></ol>\n<h2>Когда зелёный статус не даёт права на merge</h2>\n<p>Практический stop condition появляется, если контракт и observed behavior требуют разных результатов, если отрицательная ветка не проверена, если consumer не входит в scope или если единственное evidence сгенерировал тот же источник, что и код. Stop здесь означает прекратить подготовку merge до выяснения границы. Это не команда <code>git revert</code> и не rollback уже доставленной версии.</p>\n<p>Решение можно вернуть в рабочее состояние тремя способами: привести реализацию к существующему контракту; оформить изменение контракта и проверить совместимость потребителей; или собрать недостающее evidence и явно принять остаточный риск. Если после ревью нельзя одним предложением ответить, какой инвариант доказан, статус следует оставить «не готово» независимо от количества зелёных job.</p>\n<h2>Ограничения применимости</h2>\n<p>Схема подходит для небольшого diff, у которого можно назвать границу и фиксированные входы. Она не заменяет интеграционные и end-to-end тесты, анализ зависимостей, threat model, проверку конфигурации, нагрузочное испытание, наблюдение после доставки или аварийный план. Для конкурентного кода одного сравнения input до и после может быть мало: понадобится проверка гонки и конечного состояния.</p>\n<p>Примеры намеренно используют чистые функции и встроенный Node.js. В реальном проекте результаты зависят от версии runtime, схемы API, сериализатора, прав процесса и конкретной конфигурации CI. Команда из статьи не проверяет сеть, секреты и production. Если diff меняет такие границы, расширьте план проверки, а не объявляйте его доказанным по локальному прогону.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://csrc.nist.gov/pubs/sp/800/218/final\" target=\"_blank\" rel=\"noopener\">NIST SP 800-218 SSDF 1.1</a> — рамка практик безопасной разработки, которую встраивают в жизненный цикл продукта.</li><li><a href=\"https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener\">OWASP Secure Code Review Cheat Sheet</a> — границы ручного review, автоматизированных инструментов и проверки бизнес-логики.</li><li><a href=\"https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review\" target=\"_blank\" rel=\"noopener\">GitHub Docs: Using GitHub Copilot code review</a> — конкретное ограничение статуса AI-review в pull request.</li></ul>\n<h2>Критерий готовности</h2>\n<p>Diff можно передавать владельцу на approval, когда для каждого заявленного риска записаны инвариант, прямое свидетельство, отрицательный вход и blind spot. Код, тест и consumer должны описывать один контракт. Если они расходятся, результат проверки — не «почти зелёный», а конкретный вопрос владельцу границы и остановка merge до ответа.</p>"
 }
diff --git a/editorial/agent-rewrites/105.json b/editorial/agent-rewrites/105.json
index ab4eb6c..feb4f4b 100644
--- a/editorial/agent-rewrites/105.json
+++ b/editorial/agent-rewrites/105.json
@@ -2,6 +2,6 @@
   "index": 105,
   "slug": "editorial-2025-02-practice-ai-code-verification",
   "title": "Зелёный тест не доказывает корректность AI-изменения",
-  "excerpt": "Как проверить сгенерированный diff по контракту, отрицательной ветке, побочным эффектам и независимому review — и когда остановить merge.",
-  "contentHtml": "<p>Сгенерированный diff может пройти линтер и один unit-тест, но сломать потребителя. Типичный симптом — тест проверяет значение, а публичный контракт требует другое имя поля. Другой симптом — preview возвращает правильный текст, но меняет входной объект. Третий — роль editor проходит, а пустая роль тоже получает доступ. Цена ошибки начинается с повторного разбора и задержки merge. В реальной системе она может включать неверные данные, отказ функции или нарушение политики доступа. По одному зелёному статусу цену не определить.</p>\n<p>Тезис простой: результат AI-инструмента — это материал для проверки, а не доказательство. Корректность появляется только тогда, когда заявленный контракт, наблюдаемое поведение и решение ревьюера совпадают. Каждый сигнал должен отвечать на свой вопрос. Тест проверяет названный сценарий. Статический анализ ищет известный паттерн. Review проверяет намерение и границы. Ручное воспроизведение смотрит на путь потребителя.</p>\n<h2>Сначала назовите границу изменения</h2>\n<p>До запуска тестов запишите, что именно нельзя нарушить. Для mapper это форма результата и имена полей. Для функции preview — владение входным объектом и запрет на скрытую мутацию. Для проверки роли — список разрешённых значений и поведение при отсутствии роли. Для обработчика ошибки — статус, формат ответа и отсутствие утечки деталей.</p>\n<p>Фраза «функция должна вернуть итог» слишком широкая. Рабочая формулировка выглядит так: «при входе с <code>subtotalCents</code> и <code>taxCents</code> вернуть объект <code>{ amountCents: number }</code>; вход не менять». В ней есть вход, выход и инвариант. По ней можно написать проверку и понять, где заканчивается её область действия.</p>\n<pre><code>contract = {\n  input: { subtotalCents: 900, taxCents: 100 },\n  output: { amountCents: 1000 },\n  invariant: 'input remains unchanged'\n}</code></pre>\n<p>Этот фрагмент — учебный пример. Он не обращается к репозиторию, базе, CI или production. Его задача — показать форму контракта, а не предсказать поведение конкретной модели.</p>\n<figure><img src=\"/assets/editorial/2025/ai-code-verification-2025-verification-funnel.svg\" alt=\"Воронка проверки AI-изменения: контракт, статический анализ, узкий тест, review и ручное воспроизведение\"><figcaption>Проверка сужает вопрос по шагам. Ни один шаг не превращается в универсальную гарантию.</figcaption></figure>\n<h2>Как один зелёный тест пропускает ошибку</h2>\n<p>Представим учебную функцию, которую изменил ассистент:</p>\n<pre><code>function toInvoice(input) {\n  return {\n    total: input.subtotalCents + input.taxCents\n  };\n}\n\nconst result = toInvoice({ subtotalCents: 900, taxCents: 100 });\nconsole.assert(result.total === 1000);</code></pre>\n<p>Тест зелёный. Арифметика верна. Но контракт требует <code>amountCents</code>, а consumer читает <code>result.amountCents</code>. Значение становится <code>undefined</code>. Ошибка возникла не в сложной математике. Тест задал слишком узкий вопрос и не проверил форму публичного результата.</p>\n<p>Исправленная проверка должна смотреть на поле, доступное потребителю:</p>\n<pre><code>const input = { subtotalCents: 900, taxCents: 100 };\nconst result = toInvoice(input);\n\nconsole.assert(result.amountCents === 1000);\nconsole.assert(!('total' in result));\nconsole.assert(input.subtotalCents === 900);\nconsole.assert(input.taxCents === 100);</code></pre>\n<p>Второй пример тоже учебный. Он не доказывает безопасность функции и не заменяет тесты всех реальных потребителей. Он показывает, как превратить контракт в наблюдаемое утверждение.</p>\n<h2>Симптомы и действия</h2>\n<table><caption>Диагностика небольшого AI-generated diff</caption><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Тест проверяет число, consumer не находит поле</td><td>Проверили значение, но не shape</td><td>Сравнить ожидаемые ключи и чтение consumer</td><td>Вернуть контрактное поле или отдельно принять изменение API</td></tr><tr><td>Preview выдаёт верный текст, вход изменился</td><td>Не зафиксировано владение input</td><td>Сравнить объект до и после вызова</td><td>Создать derived value или назвать мутацию отдельной операцией</td></tr><tr><td>Editor проходит, missing role тоже проходит</td><td>Есть accept case, но нет default-deny</td><td>Проверить viewer и отсутствие значения</td><td>Записать allow-list и добавить отрицательные тесты</td></tr><tr><td>Линтер чистый, смысл изменения неясен</td><td>Паттерн проверен вместо намерения</td><td>Сопоставить diff с контрактом и owner boundary</td><td>Уменьшить scope и запросить предметный review</td></tr><tr><td>Ручной сценарий расходится с unit-тестом</td><td>Тест не повторяет путь потребителя</td><td>Воспроизвести тот же вход от API или UI до результата</td><td>Остановить merge до объяснения расхождения</td></tr></tbody></table>\n<h2>Почему независимые проверки не складываются в одну гарантию</h2>\n<p>Статический анализ видит то, для чего у него есть правило. Он может найти присваивание аргументу или подозрительный вызов. Он не знает, разрешена ли мутация в конкретном API. Unit-тест видит только входы и ожидания, которые записал автор. Он не проверяет незаписанный путь. Review видит контекст, но зависит от размера diff, ясности требования и времени ревьюера. Ручная проверка видит один маршрут пользователя и может не охватить редкий вариант.</p>\n<p>Поэтому пять зелёных сигналов могут повторять одну предпосылку. Например, линтер, unit-тест и screenshot подтверждают, что экран получил число. Ни один из них не подтверждает, что имя публичного поля осталось прежним. Независимость означает не количество инструментов, а разные вопросы и разные способы обнаружить нарушение.</p>\n<p>Нужно заранее написать blind spot каждого шага. Контракт не доказывает реализацию. Тест не доказывает покрытие всех consumers. Review не доказывает отсутствие runtime-ошибки. Такой список не делает систему безопасной сам по себе. Он не даёт зелёному статусу большего смысла, чем тот, который реально проверен.</p>\n<h2>Порядок проверки одного небольшого diff</h2>\n<ol><li><strong>Сузьте scope.</strong> Назовите изменённый файл, одну границу и один ожидаемый эффект. Если описание требует нескольких страниц, diff уже не подходит для короткой проверки.</li><li><strong>Запишите контракт.</strong> Укажите вход, выход, запрещённый side effect и условие отказа. Не заменяйте их словами «работает правильно».</li><li><strong>Добавьте отрицательный путь.</strong> Проверьте старое поле, отсутствие значения, чужую роль, неверный формат или отказ внешней зависимости — тот случай, который реально относится к границе.</li><li><strong>Сравните output и state.</strong> Для mapper проверьте shape. Для preview сравните input до и после. Для access rule проверьте не только ответ 200, но и условие допуска.</li><li><strong>Проведите предметный review.</strong> Ревьюер должен назвать контракт, остаточный риск и владельца решения. Просьба «посмотреть AI-код» не задаёт проверяемый вопрос.</li><li><strong>Повторите короткий маршрут потребителя.</strong> Используйте фиксированный учебный вход или безопасный тестовый объект. Сопоставьте результат с тем, что увидит consumer.</li><li><strong>Остановите подготовку merge при расхождении.</strong> Не подгоняйте тест под код и не добавляйте случайный запуск ради зелёного статуса. Сначала объясните конфликт или измените контракт явно.</li></ol>\n<h2>Отрицательный путь важнее ещё одного happy path</h2>\n<p>Отрицательная ветка должна следовать из контракта. Если неизвестная роль не должна получать доступ, проверяйте и <code>viewer</code>, и отсутствие роли. Если preview не меняет вход, проверяйте равенство объекта после вызова. Если поле нельзя переименовывать без совместимости, проверяйте ключ результата и чтение старого consumer.</p>\n<pre><code>function canEdit(actorRole) {\n  return actorRole === 'editor';\n}\n\nconsole.assert(canEdit('editor') === true);\nconsole.assert(canEdit('viewer') === false);\nconsole.assert(canEdit(undefined) === false);</code></pre>\n<p>Это не threat model и не доказательство безопасности авторизации. В примере нет identity provider, tenant boundary, токена или реального хранилища прав. Он проверяет только заявленное правило для трёх фиксированных входов. Если production-контракт шире, пример нужно расширить фактическими условиями, а не переносить его verdict.</p>\n<h2>Когда нужно остановиться</h2>\n<p>Практический stop condition таков: contract, отрицательный тест и rationale ревьюера описывают разные результаты. Тогда merge preparation блокируется. Это не автоматический revert и не rollback. Ничего доставленного система не меняет. Команда только прекращает движение спорного diff, пока владелец границы не выберет одно из действий: вернуть код к контракту, оформить совместимое изменение или собрать недостающее свидетельство.</p>\n<p>Если расхождение нельзя объяснить одним предложением, не передавайте diff на approval. Approval должен отвечать на конкретный вопрос: можно ли принять переименование поля, кто владеет совместимостью, почему мутация разрешена или какое правило действует для отсутствующей роли. Человек утверждает осознанное исключение, а не пустоту в проверке.</p>\n<h2>Ограничения</h2>\n<p>AI-проверка не заменяет знание домена, threat model, тесты реальных интеграций и ответственность владельца. Ассистент может придумать несуществующий API, пропустить условие, удалить падающий тест или предложить зависимость с неподходящей лицензией. Статический инструмент может не понимать бизнес-правило. Ручной review тоже может пропустить ошибку.</p>\n<p>Все функции и данные в примерах вымышлены и предназначены только для обучения. В статье нет production-измерений, утверждений о качестве конкретной модели и обещания, что описанный набор шагов обнаружит любой дефект. Перед применением нужно заменить учебный контракт фактическим API, входами, ролями и условиями доставки.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Небольшой diff готов к следующему решению, когда выполнены четыре условия: контракт записан; позитивный и отрицательный сценарии проходят на одних и тех же входных данных; побочный эффект либо запрещён и проверен, либо назван частью контракта; ревьюер может объяснить, что проверено и что осталось вне scope. Если хотя бы одно условие не выполнено, статус «зелёный» описывает запуск инструмента, а не готовность изменения.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://docs.github.com/en/copilot/tutorials/review-ai-generated-code\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Review AI-generated code</a> — функциональные проверки, контекст, зависимости, AI-специфические ошибки и совместный review.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/218/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-218 SSDF</a> — практики безопасной разработки, проверки и работы с найденными проблемами.</li><li><a href=\"https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener noreferrer\">OWASP Secure Code Review Cheat Sheet</a> — граница между автоматизированным анализом и ручной проверкой контекста.</li></ul>"
+  "excerpt": "Пошаговый способ проверить сгенерированный diff: от контракта и отрицательных сценариев до потребителя, зависимостей и решения о merge.",
+  "contentHtml": "<p>Зелёный тест отвечает только на тот вопрос, который в него записали. Если тест проверяет сумму, а потребитель ждёт другое имя поля, изменение может пройти CI и сломать следующий вызов. Если preview возвращает правильный текст, но меняет входной объект, ошибка проявится у другого обработчика. Если проверка роли знает только <code>editor</code>, пустая роль может случайно получить доступ.</p>\n<p>Разберём учебный diff, похожий на тот, который способен предложить AI-ассистент. Цель не в том, чтобы измерить качество конкретной модели, а в том, чтобы сделать решение проверяемым: сначала назвать контракт, затем увидеть контрпример, повторить путь потребителя и только после этого обсуждать merge.</p>\n<figure><img src='/assets/editorial/2025/ai-code-verification-2025-verification-funnel.svg' alt='Последовательность проверки AI-изменения: контракт, статический анализ, тест, review и путь потребителя'><figcaption>Каждый шаг проверяет отдельное свойство diff. Совокупность сигналов не становится гарантией, если они задают один и тот же вопрос.</figcaption></figure>\n<h2>Симптом: тест зелёный, потребитель сломан</h2>\n<p>Представим функцию расчёта счёта. Контракт старого кода прост: на входе два целых значения в копейках, на выходе объект с полем <code>amountCents</code>. Входной объект остаётся неизменным. Потребитель использует именно это имя:</p>\n<pre><code>function renderTotal(invoice) {\n  return `${invoice.amountCents} коп.`;\n}\n\nconst invoice = toInvoice({ subtotalCents: 900, taxCents: 100 });\nrenderTotal(invoice);</code></pre>\n<p>Сгенерированная реализация может выглядеть убедительно:</p>\n<pre><code>function toInvoice(input) {\n  return {\n    total: input.subtotalCents + input.taxCents\n  };\n}\n\nconst result = toInvoice({ subtotalCents: 900, taxCents: 100 });\nconsole.assert(result.total === 1000);</code></pre>\n<p>Этот assert проходит: арифметика верна. Но <code>renderTotal</code> читает <code>amountCents</code>, которого нет. Ошибка не в том, что тест написан на JavaScript. Он проверяет внутреннее промежуточное решение, а не публичную границу. Вторая ловушка — название результата: одно переименованное поле может затронуть несколько consumers, даже если функция изолированно выглядит исправной.</p>\n<h2>Контракт нужно записать до запуска тестов</h2>\n<p>Контракт — это короткое описание наблюдаемого поведения, а не просьба «сделать правильно». Для нашего примера достаточно четырёх условий: форма входа, форма результата, запрет на мутацию и реакция на недопустимые числа. Последнее условие нельзя додумывать: если проект не определил отрицательные значения, сначала нужно решить, допускаются ли они.</p>\n<table><caption>Минимальный контракт учебного mapper</caption><thead><tr><th>Граница</th><th>Условие</th><th>Как увидеть нарушение</th><th>Ограничение</th></tr></thead><tbody><tr><td>Вход</td><td><code>subtotalCents</code> и <code>taxCents</code> — целые числа</td><td>Проверить тип и пример с дробным значением</td><td>Не покрывает валидацию внешнего API</td></tr><tr><td>Результат</td><td>Есть только контрактное поле <code>amountCents</code></td><td>Проверить ключи и вызвать consumer</td><td>Совместимость старого API нужно решать отдельно</td></tr><tr><td>Состояние</td><td>Входной объект не меняется</td><td>Сравнить снимок до и после вызова</td><td>Глубокая мутация вложенных данных требует отдельного теста</td></tr><tr><td>Отказ</td><td>Неверный тип или диапазон отклоняется явно</td><td>Проверить исключение или согласованный результат ошибки</td><td>Точная ошибка зависит от публичного API</td></tr></tbody></table>\n<p>Такая таблица отделяет проверенный факт от решения, которое ещё должен принять владелец API. Не стоит молча добавлять «удобную» нормализацию, округление или обратную совместимость: это новые свойства, а не бесплатное исправление.</p>\n<h2>Сначала получить RED, затем чинить узко</h2>\n<p>Ниже — самодостаточная проверка для Node.js 20 или новее. Встроенный модуль <code>node:test</code> стабилен начиная с Node.js 20. Сохраните реализацию в <code>invoice.mjs</code>, тест — в <code>invoice.test.mjs</code>, затем выполните команды:</p>\n<pre><code>node --version\nnode --check invoice.mjs\nnode --test invoice.test.mjs</code></pre>\n<p>Первый вариант реализации намеренно показывает дефект shape:</p>\n<pre><code>// invoice.mjs\nexport function toInvoice(input) {\n  return {\n    total: input.subtotalCents + input.taxCents\n  };\n}</code></pre>\n<pre><code>// invoice.test.mjs\nimport test from 'node:test';\nimport assert from 'node:assert/strict';\nimport { toInvoice } from './invoice.mjs';\n\ntest('возвращает контрактную форму и не меняет вход', () =&gt; {\n  const input = { subtotalCents: 900, taxCents: 100 };\n  const before = JSON.stringify(input);\n  const result = toInvoice(input);\n\n  assert.deepEqual(result, { amountCents: 1000 });\n  assert.equal(JSON.stringify(input), before);\n});</code></pre>\n<p>Тест должен упасть на неправильной реализации. Это полезный RED: он показывает конкретное расхождение, а не сообщает, что «AI ошибся». После исправления ожидаемый результат такой:</p>\n<pre><code>// invoice.mjs\nexport function toInvoice(input) {\n  if (!Number.isInteger(input.subtotalCents) || !Number.isInteger(input.taxCents)) {\n    throw new TypeError('amounts must be integers');\n  }\n\n  return {\n    amountCents: input.subtotalCents + input.taxCents\n  };\n}</code></pre>\n<p>Команда <code>node --test invoice.test.mjs</code> проверяет только этот модуль и один заданный контракт. Она не доказывает корректность округления, работу базы, права пользователя или совместимость всех вызовов. Эти границы должны появиться в следующих тестах, если они есть в настоящем API.</p>\n<h2>Позитивного сценария недостаточно</h2>\n<p>Отрицательный сценарий выбирают из риска, а не добавляют для количества. Для mapper это может быть дробная сумма, отсутствующее поле и неизменность входа. Для проверки доступа — неизвестная роль и отсутствие роли. Для зависимости — пакет с неверным именем, неожиданная версия или новый транзитивный компонент. Сначала задайте ожидаемое поведение, иначе тест закрепит случайное решение.</p>\n<pre><code>export function canEdit(role) {\n  return role === 'editor';\n}\n\nconsole.assert(canEdit('editor') === true);\nconsole.assert(canEdit('viewer') === false);\nconsole.assert(canEdit(undefined) === false);\nconsole.assert(canEdit('admin') === false);</code></pre>\n<p>Здесь действует правило «разрешено только явно названному значению». Но это не полноценная авторизация: пример не проверяет identity provider, tenant, токен, срок действия сессии или серверную границу. Нельзя переносить его как готовый security control. Он лишь фиксирует поведение одной чистой функции, если такая функция действительно является частью вашего контракта.</p>\n<h2>Разные инструменты отвечают на разные вопросы</h2>\n<p>Линтер ищет правила, которые ему известны. Компилятор проверяет синтаксис и типы в пределах настроенной системы. Unit-тест повторяет записанные входы. Интеграционный тест смотрит на соединение компонентов. Review проверяет смысл, архитектуру и стоимость изменения. Ручной путь потребителя показывает то, что реально вызывается дальше. Screenshot может подтвердить отображение, но не форму данных и не разрешение операции.</p>\n<table><caption>Карта свидетельств для небольшого diff</caption><thead><tr><th>Сигнал</th><th>Подтверждает</th><th>Не подтверждает</th><th>Следующий вопрос</th></tr></thead><tbody><tr><td><code>node --check</code> или компилятор</td><td>Код разбирается в выбранной среде</td><td>Бизнес-правило и runtime-данные</td><td>Какие входы нарушают контракт?</td></tr><tr><td>Unit-тест</td><td>Названный пример и его ожидание</td><td>Незаписанные ветки и consumers</td><td>Есть ли отрицательный путь?</td></tr><tr><td>Статический анализ</td><td>Известные паттерны и часть уязвимостей</td><td>Намерение команды и все зависимости</td><td>Какая проверка требует человека?</td></tr><tr><td>Review владельца</td><td>Соответствие задаче и границам</td><td>Полное отсутствие runtime-дефектов</td><td>Что осталось вне scope?</td></tr><tr><td>Путь потребителя</td><td>Совместимость конкретного вызова</td><td>Другие маршруты и нагрузку</td><td>Какие ещё consumers нужно найти?</td></tr></tbody></table>\n<p>Пять зелёных строк в CI не превращаются в математическое доказательство. У них могут быть общие фикстуры, одинаковые предположения и один пропущенный consumer. Ценность проверки растёт, когда инструменты независимы по вопросу: shape, состояние, отказ, безопасность и путь доставки нельзя заменить пятью вариантами happy path.</p>\n<h2>Проверить AI-специфические риски до review</h2>\n<p>У сгенерированного кода есть обычные дефекты и дополнительные источники риска. Ассистент может сослаться на несуществующий API, принять устаревшую сигнатуру, удалить падающий тест вместо исправления причины или добавить правдоподобную, но лишнюю зависимость. Поэтому перед предметным review полезно сравнить diff с документацией проекта и отдельно посмотреть новые пакеты.</p>\n<ol><li><strong>Ограничьте diff.</strong> Запишите изменённые файлы, ожидаемый эффект и владельца границы. Если для проверки нужно пересказывать полсистемы, разделите изменение.</li><li><strong>Сверьте публичный контракт.</strong> Найдите типы, схему, вызывающий код и обратную совместимость. Проверьте не только значение, но и имя поля, форму ошибки и порядок побочных эффектов.</li><li><strong>Запустите дешёвые проверки.</strong> Выполните проверку синтаксиса, узкие тесты и статический анализ на той версии среды, которая указана проектом. Зафиксируйте команду и результат.</li><li><strong>Добавьте контрпример.</strong> Выберите отсутствующее поле, неверный тип, чужую роль, повторный вызов или отказ зависимости — конкретный случай, который относится к границе.</li><li><strong>Проверьте зависимости.</strong> Убедитесь, что пакет существует, его версия и лицензия подходят проекту, а lockfile изменён ожидаемо. Не принимайте название из ответа модели без самостоятельного поиска.</li><li><strong>Повторите маршрут потребителя.</strong> Возьмите безопасный тестовый вход и вызовите следующий слой. Если результат расходится с unit-тестом, остановите merge и объясните расхождение.</li><li><strong>Попросите предметный review.</strong> Вопрос должен звучать как «сохраняется ли форма ответа для consumer X?» или «какое поведение нужно для отсутствующей роли?», а не как «посмотрите AI-код».</li></ol>\n<h2>Когда зелёный статус не даёт права на merge</h2>\n<p>Merge следует остановить, если контракт и код описывают разные формы, отрицательный сценарий не определён, тест удалён или пропущен ради зелёного CI, новая зависимость не подтверждена, либо ручной путь потребителя расходится с unit-тестом. Это не означает автоматический rollback и не доказывает наличие инцидента. Это граница принятия решения: владелец должен либо вернуть код к контракту, либо оформить совместимое изменение, либо добавить недостающее свидетельство.</p>\n<p>Полезная запись решения занимает несколько строк: что изменилось, какой риск проверен, какой риск остался, кто его принимает и каким условием можно закрыть остаток. Если ответ невозможно сформулировать без слов «должно работать», проверка ещё не закончена.</p>\n<h2>Ограничения применимости</h2>\n<p>Описанный маршрут подходит для небольшого локального изменения с понятным входом и выходом. Он не заменяет threat model, тестирование распределённой системы, нагрузочные испытания, аудит лицензий, проверку секретов или ручное решение для регулируемого домена. Для миграции схемы, платежей, авторизации и работы с персональными данными нужны дополнительные владельцы и контрольные точки.</p>\n<p>Примеры вымышлены и не сообщают о production-результате. Они не измеряют вероятность ошибки AI и не доказывают, что любой дефект будет найден. Поведение <code>Number.isInteger</code>, встроенного test runner и команд зависит от версии Node.js; используйте версию проекта и проверяйте её через <code>node --version</code>. Для другого языка замените команды, но сохраните те же вопросы к контракту.</p>\n<h2>Итоговый критерий готовности</h2>\n<p>Небольшое AI-изменение готово к обсуждению merge, когда у него есть проверяемый контракт, проходящий позитивный и отрицательный сценарии, явная проверка побочного эффекта, просмотр потребителя и зафиксированные ограничения. Review должен отделять факт запуска теста от решения о корректности. Такой порядок не делает код безошибочным, зато не позволяет одному зелёному assert выдать локальное совпадение за доказательство всей цепочки.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://docs.github.com/en/copilot/tutorials/review-ai-generated-code' target='_blank' rel='noopener noreferrer'>GitHub Docs: Review AI-generated code</a> — официальная последовательность функциональных проверок, проверки контекста и намерения, анализа зависимостей, AI-специфических ошибок, совместного review и автоматизации. Страница продукта может обновляться.</li><li><a href='https://csrc.nist.gov/pubs/sp/800/218/a/final' target='_blank' rel='noopener noreferrer'>NIST SP 800-218A</a> — профиль безопасной разработки для генеративного AI и dual-use foundation models; опубликован в июле 2024 года и применяется вместе с SSDF 1.1.</li><li><a href='https://doi.org/10.6028/NIST.AI.600-1' target='_blank' rel='noopener noreferrer'>NIST AI 600-1: Generative AI Profile</a> — добровольная рамка управления рисками, которая связывает оценку с конкретным сценарием, стадией жизненного цикла и допустимыми последствиями.</li><li><a href='https://nodejs.org/docs/latest-v20.x/api/test.html' target='_blank' rel='noopener noreferrer'>Node.js 20 documentation: Test runner</a> — официальный контракт встроенного <code>node:test</code> и команда запуска тестов; пример требует Node.js 20+.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/106.json b/editorial/agent-rewrites/106.json
index 952003e..52d42b2 100644
--- a/editorial/agent-rewrites/106.json
+++ b/editorial/agent-rewrites/106.json
@@ -1,7 +1,7 @@
 {
   "index": 106,
   "slug": "editorial-2025-01-field-ai-coding-assistant",
-  "title": "AI-помощник перед merge: как проверить diff, а не впечатление",
-  "excerpt": "Сгенерированный diff может пройти happy path и всё равно выйти за scope, изменить контракт или не иметь теста для изменённой ветки. Разбираем проверяемый gate перед merge: граница задачи, отрицательный путь, evidence и критерий готовности.",
-  "contentHtml": "<p>Перед merge лежит небольшой сгенерированный diff. Он исправляет видимый симптом, тест рядом зелёный, а код выглядит аккуратно. Через час выясняется, что правка изменила ветку отказа, добавила доступ к данным или превратила ошибочный вход в допустимый. Цена ошибки — не только откат. Нужно найти затронутый контракт, остановить выпуск, проверить уже собранные артефакты и вернуть доверие к проверке.</p>\n<p>Тезис простой: ответ AI-помощника — кандидат на изменение, а не доказательство корректности. Перед merge нужно проверить три границы: diff меняет только разрешённый scope, сохраняет контракт и имеет evidence для каждой изменённой ветки. Линтер и успешный happy path закрывают лишь часть вопросов.</p>\n<h2>Что именно проверяет gate</h2>\n<p>Verification gate отделяет candidate diff от решения человека. Он не одобряет pull request автоматически и не обещает безопасность. Он собирает четыре наблюдаемых поля: задачу, разрешённые пути, условия контракта и проверку результата. Если поле не заполнено, verdict должен остановиться на <code>stop</code>, а не превращаться в «скорее всего, всё хорошо».</p>\n<pre><code>const review = {\n  task: 'normalize invoice key',\n  allowedPaths: ['src/invoice/normalizeKey.ts'],\n  forbiddenEffects: ['change authorization', 'write on invalid input'],\n  evidence: [\n    { input: 'valid-key', expected: 'valid-key', writes: 0 },\n    { input: 'invalid-key', expected: 'error', writes: 0 },\n  ],\n};\n\nfunction canMerge(candidate, contract) {\n  const pathsOk = candidate.paths.every((path) =&gt; contract.allowedPaths.includes(path));\n  const behaviorOk = candidate.invalidInput.writes === 0;\n  return pathsOk &amp;&amp; behaviorOk;\n}\n\n// Учебный пример: он не запускает CI и не проверяет реальный репозиторий.\n// false означает остановку, а не разрешение исправить scope молча.</code></pre>\n<p>В примере <code>canMerge</code> показывает только форму решения. Реальный проект должен связать каждое условие с тестом, ревьюером и фактическим diff. Нельзя считать этот фрагмент защитой доступа, транзакций или всех потребителей API.</p>\n<h2>Три способа принять неверный diff</h2>\n<h3>Scope mismatch</h3>\n<p>Задача просит нормализовать ключ счёта. Помощник меняет parser и соседний <code>accessDecision</code>. Изменение авторизации может быть технически небольшим, но его риск не равен риску форматирования строки. Если path не назван в задаче, его нельзя включать в тот же merge под видом удобного сопутствующего исправления.</p>\n<p>Правильный отрицательный путь — остановить diff и удалить лишний hunk либо вынести его в отдельный запрос. Не нужно объяснять расширение scope красивым комментарием. Сначала возвращают границу, затем отдельно обсуждают новую задачу и её владельца.</p>\n<h3>Contract mismatch</h3>\n<p>Контракт различает три входа: непустой ключ, пустую строку и недопустимый маркер. Первый нужно нормализовать. Второй означает отсутствие значения. Третий возвращает ошибку. Сгенерированный код может свести последние два случая к пустой строке. Такой код короче и проходит happy path, но теряет смысл ошибки.</p>\n<p>Проверка должна сравнивать не только типы и снимки ответа. Для каждого входа нужно назвать ожидаемый результат и запрещённый побочный эффект. Если invalid input не должен писать в базу, это условие обязано появиться в тесте. Иначе тест докажет лишь то, что функция что-то вернула.</p>\n<h3>Test-evidence mismatch</h3>\n<p>Тест может быть зелёным и не относиться к изменённой ветке. Например, он проверяет уникальный ключ, а diff добавляет запись до того, как обработает duplicate key. На duplicate-ветке результат должен быть ошибкой, а write helper не должен вызываться. Наличие файла с тестом не доказывает эту связь.</p>\n<p>Для каждой changed branch запишите три значения: input, expected output и forbidden side effect. Если ветка не имеет отдельного наблюдаемого условия, её следует считать непроверенной. Это правило действует и для кода, написанного человеком.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Типовые ошибки перед merge</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>В diff появился файл, которого нет в задаче</td><td>Помощник расширил scope по соседнему контексту</td><td>Сопоставить каждый changed path с карточкой задачи</td><td>Остановить merge и вынести лишний hunk в отдельную задачу</td></tr><tr><td>Happy path зелёный, invalid input принят</td><td>Код изменил смысл ошибки или absence</td><td>Прогнать фиксированные valid, absent и invalid входы</td><td>Вернуть различие в контракт и добавить negative test</td></tr><tr><td>Тест есть, но побочный эффект не проверен</td><td>Тест видит output, но не вызовы write helper</td><td>Проверить число вызовов и порядок до error</td><td>Зафиксировать forbidden side effect и повторить тест</td></tr><tr><td>Линтер прошёл, поведение неизвестно</td><td>Правило стиля не видит доменный контракт</td><td>Сверить ветки, статус, данные и права отдельно</td><td>Не считать lint verdict доказательством correctness</td></tr><tr><td>Исправление выглядит локальным, но меняет доступ</td><td>Соседний security-sensitive код попал в контекст</td><td>Показать владельцу access path и отрицательные случаи</td><td>Остановить merge до отдельного security review</td></tr></tbody></table></div>\n<h2>Иллюстрация границы</h2>\n<figure><img src=\"/assets/editorial/2025/ai-coding-assistant-2025-verification-gate.svg\" alt=\"Схема проверки AI-assisted diff: prompt-card, bounded diff, contract rows и focused tests проходят три проверки и только затем ведут к решению человека\" loading=\"lazy\" /><figcaption>Gate проверяет scope, контракт и evidence. Красная ветка означает stop до merge. Схема учебная: она не запускает CI, не выполняет rollback и не доказывает свойства production-системы.</figcaption></figure>\n<p>Схема полезна как напоминание о порядке. Сначала фиксируют границу задачи. Затем читают diff. После этого проверяют контракт и тест. Решение человека появляется в конце. Если начать с впечатления от кода, предыдущие вопросы легко пропустить.</p>\n<h2>Порядок проверки перед merge</h2>\n<ol><li><strong>Сформулируйте задачу.</strong> Запишите цель, разрешённые файлы, запреты, владельца решения и ожидаемые evidence. Уберите секреты и персональные данные из контекста помощника.</li><li><strong>Прочитайте весь diff.</strong> Проверьте каждый path, импорт, условие, изменение схемы и вызов внешнего сервиса. Не ограничивайтесь hunk, который объясняет исходный симптом.</li><li><strong>Сверьте контракт.</strong> Назовите valid, absent и invalid входы. Для каждого укажите результат, статус или исключение и запрещённые побочные эффекты.</li><li><strong>Привяжите тест к ветке.</strong> Найдите тест, который действительно выполняет изменённое условие. Проверьте output, вызовы helper, права и состояние после ошибки.</li><li><strong>Прогоните отрицательный путь.</strong> Передайте неизвестное значение, пропущенное поле, неверный тип, duplicate или отказ в доступе — в зависимости от контракта. Ожидайте точный отказ, а не только отсутствие падения.</li><li><strong>Проверьте неизвестные.</strong> Отдельно запишите, чего не видно: всех ли потребителей нашли, совпадает ли runtime-конфигурация, проверены ли миграции, права и конкурентные вызовы. Unknown не равен pass.</li><li><strong>Примите ограниченное решение.</strong> Если всё доказано, человек одобряет конкретный diff. Если нет, reviewer запрашивает изменения, сужает scope или открывает отдельный риск. Не расширяйте разрешение молча.</li></ol>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Ни один слой не гарантирует correctness для всей системы. Модель может не знать скрытый consumer. Unit test может не увидеть реальный сериализатор. Линтер не знает, что <code>403</code> нельзя превращать в повторяемый <code>400</code>. CI подтверждает только запущенные сценарии и окружение, в котором они запустились.</p>\n<p>Учебный код выше не заменяет review, contract test, security analysis, интеграционный запуск и процедуру отката. Он также не измеряет качество модели и не подтверждает экономию времени. В статье нет production-метрик и результатов реального внедрения. Примеры нужны только для проверки границы: что изменилось, какой вход это наблюдает и какой эффект запрещён.</p>\n<p>Если помощник удалил тест, ослабил проверку прав, изменил миграцию или добавил неизвестную зависимость, остановка важнее скорости. Верните diff к минимальному scope. Сохраните причину отказа. Повторно запросите только тот фрагмент, который можно проверить отдельным контрактом.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Diff готов к решению о merge, когда reviewer может показать: каждый изменённый path разрешён задачей; для каждой изменённой ветки есть вход, ожидаемый результат и проверка запрещённого эффекта; отрицательные случаи возвращают согласованный отказ; lint и тесты выполнены в заявленном окружении; неизвестные записаны отдельно и не выданы за pass. Для изменения доступа, схемы или внешнего контракта нужен отдельный владелец соответствующего риска.</p>\n<p>Проверяемый результат — не фраза «код выглядит правильно». Это короткий набор ссылок на diff, contract rows и focused tests. Если хотя бы одна changed branch не связана с evidence, merge не готов. Такой критерий одинаково применим к ручному и AI-assisted коду.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://docs.github.com/en/copilot/tutorials/review-ai-generated-code\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Review AI-generated code</a> — официальная рекомендация проверять AI-generated code, его контекст и тесты; источник не подтверждает результаты этого учебного материала.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/218/a/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models</a> — официальный профиль практик безопасной разработки для AI-контекста; он задаёт рекомендации, а не доказательство конкретного production-эффекта.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/218/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-218: Secure Software Development Framework</a> — официальная рамка secure-development practices и общего языка риска; она не заменяет проверку доменного контракта.</li></ul>"
+  "title": "AI-помощник в задаче: как проверить diff перед merge",
+  "excerpt": "Сгенерированный код может пройти happy path и всё равно выйти за границу задачи, изменить контракт или добавить непроверенную зависимость. Разбираем практический gate перед merge: scope, отрицательные ветки, evidence и ограничения человеческого решения.",
+  "contentHtml": "<p>На ревью приходит небольшой diff, который подготовил AI-помощник. Основной тест зелёный, названия аккуратные, объяснение звучит уверенно. При чтении полного изменения обнаруживается второй файл с правами доступа, новый пакет в lock-файле или ветка ошибки, в которой запись выполняется до проверки входа. Такой diff выглядит локальным только в окне редактора. Цена пропуска — сломанный контракт, утечка данных или откат, который придётся готовить уже после merge.</p>\n<p>Разберём учебный сценарий: помощник должен нормализовать входящее событие, но предложил изменить ещё и вызывающий код. Главный вывод не зависит от конкретного инструмента: ответ модели — кандидат на изменение, а не доказательство корректности. Перед merge человек должен связать каждый изменённый путь с задачей, каждую изменённую ветку — с контрактом, а каждое существенное утверждение — с воспроизводимой проверкой.</p>\n<h2>Что считается готовым diff</h2>\n<p>Готовность здесь означает не «код выглядит правильно», а возможность показать короткую цепочку evidence. Сначала есть формулировка задачи и список разрешённых областей. Затем — diff, который не вышел за эти области. Для изменённого поведения записаны вход, ожидаемый результат и запрещённый побочный эффект. Наконец, тест или другой запуск действительно проходит через эту ветку в окружении, которое указано в результате проверки.</p>\n<p>У gate есть три исхода. <code>approve</code> означает, что reviewer готов принять конкретный diff. <code>request-changes</code> означает, что проблему можно исправить в той же задаче. <code>stop</code> означает, что обнаружена неизвестная граница, security-sensitive изменение или несоответствие контракта; такой случай сначала возвращают владельцу риска.</p>\n<figure><img src=\"/assets/editorial/2025/ai-coding-assistant-2025-verification-gate.svg\" alt=\"Схема проверки сгенерированного diff: карточка задачи, ограниченный diff, строки контракта и целевой тест сходятся в gate; несоответствие ведёт к остановке, а решение принимает человек\" loading=\"lazy\" /><figcaption>Gate не оценивает убедительность ответа модели. Он сопоставляет scope, контракт и evidence. Красная ветка означает остановку до merge; схема не запускает CI и не доказывает безопасность production-системы.</figcaption></figure>\n<h2>Сначала проверьте границу изменения</h2>\n<p>Первый вопрос к diff — не «хорошо ли написан код», а «имеет ли он право здесь находиться». Для pull request можно получить список изменённых путей и отдельную проверку пробелов или конфликтных маркеров:</p>\n<pre><code>git diff --name-status origin/main...HEAD\ngit diff --check origin/main...HEAD\ngit diff --stat origin/main...HEAD</code></pre>\n<p>Эти команды показывают состав изменения и базовые технические дефекты, но не знают смысла задачи. Сопоставьте каждый путь с карточкой: исходный модуль, тест, схема, миграция, lock-файл и конфигурация — это разные виды риска. Если помощник добавил пакет «для удобства», изменил генератор или затронул авторизацию, не прячьте это в общий diff. Уточните границу либо вынесите изменение в отдельную задачу с отдельным владельцем.</p>\n<p>Особенно легко пропустить сгенерированные файлы. Они могут появиться после команды сборки, хотя не были частью замысла. Проверьте статус репозитория до и после запуска инструментов, а также правила, по которым артефакты попадают в commit. Для rename и удаления смотрите не только имя нового файла: контракт мог переехать, а тест — остаться привязанным к старому пути.</p>\n<h2>Затем разложите контракт по веткам</h2>\n<p>Небольшая функция часто имеет больше одного смысла входа. В учебном обработчике события есть валидное сообщение, отсутствие обязательного поля и неизвестный статус. Если все три случая свести к пустому объекту, вызывающий код может принять ошибку за отсутствие данных и продолжить обработку. Это не косметическая разница: меняется решение на границе системы.</p>\n<div class=\"table-scroll\"><table><caption>Минимальная матрица проверки для обработчика события</caption><thead><tr><th scope=\"col\">Вход</th><th scope=\"col\">Ожидаемый результат</th><th scope=\"col\">Запрещённый эффект</th><th scope=\"col\">Evidence</th></tr></thead><tbody><tr><td>Поле <code>type</code> известно, payload полный</td><td>Нормализованный объект передан дальше</td><td>Не создавать запись дважды</td><td>Unit test и проверка вызова downstream</td></tr><tr><td>Нет <code>type</code></td><td><code>invalid-input</code></td><td>Не вызывать запись и повторную доставку</td><td>Negative test с проверкой числа вызовов</td></tr><tr><td><code>type</code> неизвестен</td><td><code>unsupported-type</code></td><td>Не угадывать обработчик по похожему имени</td><td>Тест на неизвестное значение и лог причины</td></tr><tr><td>Payload содержит лишнее поле</td><td>Результат зависит от версии контракта</td><td>Не молча терять данные, если контракт их запрещает</td><td>Сверка схемы и тест сериализации</td></tr></tbody></table></div>\n<p>Таблица не заменяет спецификацию API. Она делает видимым место, где тест должен отличать результат от побочного эффекта. Проектные значения — имена статусов, политика лишних полей и способ дедупликации — нельзя переносить в другой сервис без сверки его контракта.</p>\n<h2>Положительный тест без отрицательного пути недостаточен</h2>\n<p>Минимальный воспроизводимый пример можно выполнить обычным Node.js без внешних пакетов. Он проверяет три входа и отдельно фиксирует, что downstream не вызывается при ошибке:</p>\n<pre><code>const calls = [];\n\nfunction normalizeEvent(event) {\n  if (!event?.type) return { status: 'invalid-input' };\n  if (event.type !== 'invoice.created') return { status: 'unsupported-type' };\n  return { status: 'ok', type: event.type, invoiceId: event.invoiceId };\n}\n\nfunction handle(event) {\n  const result = normalizeEvent(event);\n  if (result.status !== 'ok') return result;\n  calls.push(result.invoiceId); // downstream: только после проверки\n  return result;\n}\n\nconsole.log(handle({ type: 'invoice.created', invoiceId: 'inv-7' }));\nconsole.log(handle({ invoiceId: 'inv-8' }));\nconsole.log(handle({ type: 'invoice.deleted', invoiceId: 'inv-9' }));\nconsole.log({ calls });\n\n// Ожидается: два отказа и calls только с ['inv-7'].</code></pre>\n<p>Запустите этот фрагмент как <code>node example.mjs</code> или вставьте его в Node REPL. Важно не само число строк, а наблюдаемый инвариант: ошибки возвращаются до побочного действия. Если сгенерированный вариант вызывает <code>calls.push</code> до проверки статуса, happy path останется зелёным, а отрицательный тест покажет нарушение.</p>\n<p>Тест должен быть связан с изменённой веткой, а не просто лежать рядом по имени. Прочитайте assertion: он проверяет значение, тип ошибки, количество вызовов и состояние после отказа? Если проверяется только непустой ответ, неизвестно, что произойдёт с записью, повторной доставкой или метрикой.</p>\n<h2>Проверьте зависимости и границы данных</h2>\n<p>AI-помощник может предложить несуществующий пакет, устаревший API или библиотеку с неподходящей лицензией. Может также перенести в prompt секрет, персональный идентификатор или фрагмент закрытого кода. Поэтому просмотр diff должен включать не только строки программы.</p>\n<ol><li><strong>Зависимости.</strong> Сверьте имя пакета с реестром и документацией, версию — с поддерживаемым runtime, а лицензию и транзитивные зависимости — с правилами проекта.</li><li><strong>Секреты.</strong> Уберите токены, cookies, персональные данные и закрытый исходный код из контекста помощника. Проверьте diff, логи и артефакты на случайное попадание таких данных.</li><li><strong>Права.</strong> Если изменение касается авторизации, фильтрации данных, SQL, файловой системы или внешнего вызова, назначьте ревьюера с соответствующей ответственностью. Статический анализ не заменяет такой review.</li><li><strong>Схема и сериализация.</strong> Сравните фактический JSON, заголовки, коды ошибок и обязательность полей с владельцем API. Компилируемый тип не доказывает совместимость с потребителем.</li><li><strong>Окружение.</strong> Запишите версии Node.js, команды и набор тестов. Результат локального запуска нельзя расширять до гарантии другой ОС, базы или feature flag.</li></ol>\n<p>GitHub в руководстве по проверке AI-generated code отдельно выделяет функциональные проверки, контекст и намерение, зависимости, AI-специфичные ошибки и человеческое ревью. Это полезная карта вопросов, но не сертификат качества конкретного diff. NIST SSDF и профиль для generative AI задают практики безопасной разработки и управления рисками; они не подтверждают, что учебный код или конкретная модель безопасны.</p>\n<h2>Что делать при несоответствии</h2>\n<p>При mismatch не исправляйте сразу весь diff новым широким запросом к помощнику. Сначала зафиксируйте наблюдение: какой path лишний, какая строка контракта нарушена, какая проверка отсутствует и какой эффект запрещён. Затем выберите узкое действие.</p>\n<ul><li>Лишний путь — удалить из текущей задачи или открыть отдельный change с новой границей.</li><li>Неверная ветка ошибки — вернуть различие статусов и добавить negative test до повторного ревью.</li><li>Непроверенная зависимость — остановить изменение, проверить пакет и согласовать лицензию.</li><li>Security-sensitive diff — передать его владельцу риска, не объявляя результат безопасным по зелёному lint.</li><li>Неизвестный consumer или runtime — собрать evidence, а до этого оставить решение в статусе <code>stop</code>.</li></ul>\n<p>Остановка не означает автоматический rollback. До merge обычно достаточно сузить кандидат и запросить изменения. После поставки нужна отдельная процедура инцидента и отката, зависящая от системы. Не смешивайте эти решения: gate отвечает на вопрос «можно ли принимать этот diff сейчас», а не «как восстановить production после уже случившегося эффекта».</p>\n<h2>Порядок проверки перед merge</h2>\n<ol><li>Сформулируйте одно решение: принять diff, запросить правки или остановить работу.</li><li>Запишите разрешённые пути, запреты, владельца задачи и чувствительные области.</li><li>Снимите <code>git diff --name-status</code>, прочитайте весь diff и проверьте незапланированные артефакты.</li><li>Для каждой изменённой ветки заполните вход, результат, статус или исключение и запрещённый эффект.</li><li>Найдите тест, который выполняет ветку, и добавьте отрицательный случай для неверного входа, отсутствующего поля или отказа в доступе.</li><li>Проверьте зависимости, схему, сериализацию, права, секреты и окружение.</li><li>Запустите заявленные тесты и <code>git diff --check</code>; сохраните команды и фактический результат.</li><li>Отдельно перечислите неизвестные. Не превращайте отсутствие evidence в pass и не расширяйте доказательство за пределы выполненного запуска.</li></ol>\n<h2>Ограничения применимости</h2>\n<p>Этот gate снижает риск пропустить очевидное несоответствие, но не доказывает полноту поиска потребителей, отсутствие уязвимостей или корректность бизнес-решения. Unit test может не увидеть реальный сериализатор, конкурентный вызов, миграцию или конфигурацию в другом окружении. Static analysis может найти подозрительный путь, но не понять, что конкретный статус запрещено менять в этом продукте.</p>\n<p>Пример с <code>invoice.created</code> синтетический: он не подключён к очереди, базе и системе прав. Значения статусов, формат идентификатора и правило дедупликации — иллюстрация, а не универсальный API-контракт. Для платежей, персональных данных, авторизации и миграций нужен профильный владелец, проверка реального окружения и принятый в проекте план отката.</p>\n<p>Не следует приписывать модели результат, которого не измеряли. Без сравнимых задач и заранее заданной метрики этот процесс не доказывает экономию времени, рост качества или отсутствие дефектов. Он лишь делает решение о конкретном diff проверяемым и оставляет явное место для остановки.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Diff можно передавать на решение о merge, когда reviewer показывает: каждый path разрешён задачей; каждая изменённая ветка связана с тестом или другим воспроизводимым evidence; valid, absent и invalid входы не смешаны; запрещённые побочные эффекты проверены; зависимости, данные и права просмотрены; команды и окружение записаны; неизвестные не выданы за доказанный факт. Если хотя бы один пункт не выполнен, корректный результат — запросить конкретную проверку или остановить merge.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://docs.github.com/en/copilot/tutorials/review-ai-generated-code\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Review AI-generated code</a> — официальное руководство рекомендует начинать с тестов и статического анализа, сверять контекст и намерение, проверять зависимости, AI-специфичные ошибки и сохранять человеческое ревью. Руководство не подтверждает качество конкретного diff.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/218/a/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models</a> — официальный профиль дополняет SSDF практиками для AI-моделей и AI-систем на протяжении жизненного цикла. Это рамка управления рисками, а не проверка учебного кода.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/218/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1</a> — официальный набор высокоуровневых практик secure development и общий язык для обсуждения рисков. Он не заменяет доменный контракт, тесты и review владельца системы.</li></ul>"
 }