diff --git a/editorial/agent-rewrites/119.json b/editorial/agent-rewrites/119.json
index 2026ba0..a05ea94 100644
--- a/editorial/agent-rewrites/119.json
+++ b/editorial/agent-rewrites/119.json
@@ -1,7 +1,7 @@
 {
   "index": 119,
   "slug": "editorial-2024-09-mechanism-adr-decisions",
-  "title": "ADR без иллюзии выбора: как записать решение, его цену и путь назад",
-  "excerpt": "Архитектурное решение теряет смысл, если в записи виден только победивший вариант. Разбираем, как сравнить альтернативы по одной схеме, проверить отрицательный путь и оставить условие для пересмотра.",
-  "contentHtml": "<p>В review появляется знакомый симптом: команда обсуждает не условие задачи, а вкус. Один вариант называют простым, другой — надёжным, третий — слишком дорогим. В ADR уже записан победитель, но альтернативы сведены к двум словам. Через месяц авторы помнят контекст, а остальные видят только решение. Через год никто не знает, какую проблему оно закрывало и что делать, если исходное условие изменилось.</p>\n<p>Цена ошибки растёт вместе с границей решения. Неудачный выбор может закрепить общий протокол, миграцию, формат данных или операционную обязанность. Тогда быстрый первый merge скрывает дорогой rollback. Ошибка не в том, что команда выбрала неидеальный вариант. Ошибка в том, что запись не показывает принятый компромисс и не даёт проверить, когда его пора пересмотреть.</p>\n<p><strong>Тезис:</strong> хороший ADR не доказывает, что выбранный вариант лучший вообще. Он связывает наблюдаемую проблему с конкретным ограничением, одинаково описывает альтернативы, называет цену выбора и задаёт сигнал для возврата к решению. Числа могут помочь в учебной модели, но не заменяют факты и не превращают мнение в production-метрику.</p>\n<h2>Механизм: от симптома к решению</h2>\n<p>ADR полезен как короткая цепочка причин. Сначала автор отделяет факт от объяснения. Факт можно наблюдать: caller должен получить статус, пока фоновая операция продолжается; данные нельзя отдавать старше заданной границы; изменение должно откатываться без записи нового формата. Гипотеза объясняет, почему текущий путь не подходит. Решение отвечает на ограничение, а не на абстрактную цель вроде «улучшить архитектуру».</p>\n<p>У каждой альтернативы должна быть одна и та же карточка. Запишите, какой constraint она закрывает, где находится её граница, кто владеет дополнительной работой, как выглядит возврат и какое evidence уже есть. Отсутствующее evidence тоже является результатом сравнения. Оно ограничивает уверенность, но не доказывает безопасность или опасность варианта.</p>\n<p>Статус помогает не смешивать обсуждение и историю. <em>Proposed</em> означает, что запись готова к проверке. <em>Accepted</em> фиксирует принятое решение. <em>Superseded</em> означает, что новый ADR заменил старый и объяснил причину. Статус не запускает миграцию, не назначает approval и не проверяет rollback автоматически. Эти действия должны иметь отдельного владельца и отдельный сигнал.</p>\n<pre><code>symptom      = caller не получает понятный status\nconstraint   = acknowledgement не должен зависеть от business completion\nalternatives = direct response | bounded async state | shared workflow\ndecision     = bounded async state у границы сервиса\nprice        = expiry, owner состояния, cleanup и отдельная проверка retry\nreassess     = меняется контракт caller или срок хранения состояния</code></pre>\n<p>Этот фрагмент — учебный пример формы. Он не описывает реальный сервис, трафик, SLO или production-результат. Его задача — показать, как решение связывает симптом, условие, цену и отрицательный путь. В настоящем ADR вместо учебных утверждений нужны ссылки на контракт, issue, тест, threat model или другой разрешённый источник evidence.</p>\n<h2>Как сравнить альтернативы честно</h2>\n<p>Сначала выровняйте уровень вариантов. Нельзя сравнивать «локальный cache» с «переделать платформу»: это разные масштабы и владельцы. Сформулируйте варианты на уровне решения, а затем укажите реализацию как следствие. Для asynchronous boundary это могут быть прямой ответ после завершения работы, bounded state с выдачей статуса и общий workflow с отдельным хранением состояния.</p>\n<p>Constraint fit отвечает на вопрос «закрывает ли вариант обязательное условие». Reversibility описывает не наличие кнопки undo, а область возврата, порядок действий и владельца. Evidence fit показывает, какие факты поддерживают выбор и какой вопрос остался открытым. Operating cost называет долг: expiry, retry, cleanup, миграцию, поддержку контракта или ручной review. Reassessment показывает, что должно измениться, чтобы открыть новый ADR.</p>\n<table><thead><tr><th>Критерий</th><th>Вопрос к каждому варианту</th><th>Проверяемый артефакт</th><th>Чего нельзя утверждать</th></tr></thead><tbody><tr><td>Constraint fit</td><td>Какое объявленное условие выполняется?</td><td>Контракт, problem statement или acceptance question</td><td>Что вариант оптимален для всех целей</td></tr><tr><td>Reversibility</td><td>Какой scope возврата, кто его выполняет и что останавливает change?</td><td>План rollback и граница затронутого состояния</td><td>Что rollback уже проверен в production</td></tr><tr><td>Evidence fit</td><td>Какой факт поддерживает выбор и чего пока не хватает?</td><td>Ссылка на источник, controlled test или явное unknown</td><td>Что отсутствие данных равно безопасному результату</td></tr><tr><td>Operating cost</td><td>Кто поддерживает status, expiry, retry, cleanup или migration?</td><td>Owner и consequence в ADR</td><td>Что стоимость измерена в часах или деньгах</td></tr><tr><td>Reassessment</td><td>Какой сигнал отменяет исходное предположение?</td><td>Review condition, metric question или contract link</td><td>Что дата сама запустит пересмотр</td></tr></tbody></table>\n<p>Таблица не требует единой оценки. Она делает пропуски видимыми. Если у одного варианта есть контракт, а у другого только слово «сложно», сравнение ещё не началось. Если команда всё же применяет score, заранее закрепите шкалу, веса и смысл баллов. Рядом напишите, какие данные модель не учитывает. Итоговый балл может быть tie-breaker для обсуждения, но не доказательством корректности.</p>\n<figure><img src=\"/assets/editorial/2024/adr-decisions-2024-alternatives-matrix.svg\" alt=\"Синтетическая матрица сравнения альтернатив ADR по ограничениям, обратимости, evidence и операционной цене\"><figcaption>Иллюстрация показывает синтетическую матрицу. Значения помогают увидеть форму сравнения и не являются метриками реальной команды или production-системы.</figcaption></figure>\n<h2>Пример записи с отрицательным путём</h2>\n<p>Предположим, synchronous caller ждёт результат долгой операции. Прямой ответ сохраняет простую модель, но не выдерживает границу времени. Shared workflow даёт общий status, но добавляет cross-service owner и отдельный контракт. Bounded state у границы сервиса отделяет acknowledgement от business completion. Это может закрыть исходное условие, если срок хранения, повтор запроса и очистка состояния определены явно.</p>\n<pre><code>## Decision\nВыбираем bounded state у границы сервиса.\n\n## Consequences\nПоложительные: caller получает отдельный status.\nЦена: owner хранит expiry и cleanup; retry должен быть идемпотентным.\n\n## Не делаем\nНе вводим shared workflow и не считаем локальное состояние\nуниверсальным механизмом координации.\n\n## Reassessment\nОткрываем новый ADR, если caller требует общего status между\nсервисами или срок хранения превышает допустимую границу.</code></pre>\n<p>Отрицательный путь защищает запись от незаметного расширения. Без него локальное решение постепенно начинает обслуживать новые callers, а временное поле превращается в общий протокол. Если новое требование действительно появилось, это не повод молча дописывать старый ADR. Нужен successor с новым контекстом, альтернативами и ценой. Старый record остаётся историей прежнего компромисса.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Выбранный вариант подробно описан, остальные названы «сложными»</td><td>Автор сравнил не варианты, а привлекательность собственного решения</td><td>Заполнить одну карточку criteria для каждой альтернативы</td><td>Переписать ADR и назвать explicit downside победителя</td></tr><tr><td>После merge спорят, что на самом деле означал ADR</td><td>В записи смешаны факт, гипотеза и implementation detail</td><td>Пометить источник каждого важного утверждения</td><td>Вынести неизвестное в evidence gap и добавить owner проверки</td></tr><tr><td>Rollback существует только как фраза</td><td>Не определены scope, порядок и stop condition</td><td>Провести dry run на учебной копии или описать точную границу</td><td>Связать ADR с отдельным rollback-планом и не объявлять его проверенным без evidence</td></tr><tr><td>Локальный механизм используют новые callers</td><td>Отрицательный путь и граница применимости не записаны</td><td>Проверить список потребителей и контракт состояния</td><td>Остановить расширение, создать successor ADR при новом требовании</td></tr><tr><td>Дата review прошла, но никто не вернулся к решению</td><td>Дата ошибочно принята за автоматический процесс</td><td>Найти владельца сигнала и фактическое событие пересмотра</td><td>Назначить действие отдельно или заменить дату проверяемым trigger</td></tr></tbody></table>\n<h2>Порядок работы</h2>\n<ol><li><strong>Сузьте вопрос.</strong> Опишите одну границу: какой caller, какое состояние и какое обязательное условие создают проблему.</li><li><strong>Зафиксируйте наблюдаемый симптом и цену.</strong> Отделите факт от гипотезы. Назовите, что станет дороже или опаснее при неверном выборе.</li><li><strong>Соберите три разумные альтернативы.</strong> Приведите их к одному уровню и не добавляйте вариант, который не может закрыть constraint.</li><li><strong>Заполните одинаковые поля.</strong> Укажите constraint fit, reversibility, evidence gap, operating cost, owner и отрицательный путь.</li><li><strong>Сформулируйте decision как компромисс.</strong> Запишите, что реализуем и чего намеренно не делаем.</li><li><strong>Назначьте проверяемый сигнал.</strong> Это может быть изменение контракта, новый потребитель, исчерпание срока хранения или конкретный вопрос к метрике.</li><li><strong>Проверьте запись до implementation.</strong> Reviewer должен суметь назвать выбранный вариант, его цену и условие пересмотра, не открывая код.</li><li><strong>Свяжите запись с реализацией отдельно.</strong> ADR не заменяет тест, threat model, migration plan, benchmark, runbook или incident review.</li></ol>\n<h2>Ограничения и критерий готовности</h2>\n<p>ADR не делает решение истинным и не заменяет исследование. Он не измеряет latency, надёжность, стоимость или безопасность, если рядом нет соответствующего evidence. Он не гарантирует, что команда найдёт все альтернативы. Формат может различаться: важнее сохранить контекст, выбор, статус, последствия, границы и путь пересмотра. Для legal, security, privacy и data boundary нужны отдельные проверки с отдельными владельцами.</p>\n<p>Не добавляйте в учебный пример вымышленные traffic, error rate, savings или outcome. Если число нужно для объяснения score, пометьте его как синтетическое и не переносите вывод за пределы модели. Если production-данных нет, честная формулировка — «данных пока недостаточно», а не «вариант доказанно безопасен».</p>\n<p>Запись готова, когда независимый читатель может ответить на пять вопросов: какой симптом наблюдали; какое constraint обязателен; почему сравнивали именно эти варианты; какую цену принимает выбранный путь; какой сигнал заставит открыть новое решение. Проверка проста: уберите из текста заголовок <em>Decision</em> и попросите коллегу восстановить его из context, alternatives и consequences. Если он не может назвать отрицательный путь или owner, ADR ещё не готов.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://adr.github.io/\" target=\"_blank\" rel=\"noopener noreferrer\">Architectural Decision Records</a> — официальный сайт сообщества ADR с материалами о формате и практике.</li><li><a href=\"https://github.com/adr/madr\" target=\"_blank\" rel=\"noopener noreferrer\">MADR: Markdown Architectural Decision Records</a> — репозиторий шаблонов и документации Markdown-формата.</li><li><a href=\"https://www.gov.uk/government/publications/architectural-decision-record-framework\" target=\"_blank\" rel=\"noopener noreferrer\">Architectural Decision Record Framework</a> — официальный framework Government Digital Service и Department for Science, Innovation and Technology.</li></ul>"
+  "title": "ADR как журнал компромисса: решение, цена и путь назад",
+  "excerpt": "Хороший ADR сохраняет не только выбранный вариант, но и исходное ограничение, отклонённые альтернативы, цену решения и сигнал для пересмотра. Разбираем это на сценарии долгого экспорта.",
+  "contentHtml": "<p>После ревью в репозитории остаётся новый endpoint, очередь или дополнительное хранилище, но исчезает причина выбора. Через несколько месяцев команда видит только реализацию: один caller ждёт ответ, другой опрашивает status, третий уже использует внутреннее поле как публичный контракт. Вопрос «почему здесь так?» снова уходит в поиск по чатам и памяти участников.</p>\n<p>Ошибка не обязательно в самом техническом выборе. Дорого обходится потеря его границ: неизвестно, какое ограничение считалось обязательным, какие варианты сравнивали, кто владеет состоянием и что делать после изменения исходных условий. ADR — Architectural Decision Record, запись архитектурного решения — нужен именно для этой причинной связи. Он не делает решение правильным навсегда и не заменяет тестирование, но оставляет проверяемую историю компромисса.</p>\n<p><strong>Тезис статьи:</strong> ADR готов, когда независимый читатель может восстановить проблему, обязательное условие, выбранный путь, его отрицательные последствия и сигнал пересмотра. Слова «быстрее», «проще» и «надёжнее» становятся полезными только после уточнения: для какого участника, при каком отказе и каким артефактом это проверяется.</p>\n<h2>Что именно фиксирует ADR</h2>\n<p>Официальное сообщество ADR определяет architectural decision как обоснованный выбор, значимый для архитектуры, а ADR — как запись одного такого выбора и его rationale, то есть причины. Коллекция записей образует decision log. Поэтому один ADR отвечает на один связный вопрос, а не пытается стать полной технической документацией системы.</p>\n<p>В шаблоне Michael Nygard минимальная форма состоит из <em>Status</em>, <em>Context</em>, <em>Decision</em> и <em>Consequences</em>. В MADR форма расширяется полями decision drivers, considered options, outcome и confirmation. Это полезные шаблоны, а не универсальный закон: команда может добавить владельца, ссылки на контракт, confidence или условие пересмотра.</p>\n<table><caption>Граница ответственности ADR и соседних артефактов</caption><thead><tr><th scope=\"col\">Артефакт</th><th scope=\"col\">Главный вопрос</th><th scope=\"col\">Что должно остаться внутри</th><th scope=\"col\">Чего он не доказывает</th></tr></thead><tbody><tr><td>ADR</td><td>Почему выбран этот вариант?</td><td>Контекст, ограничения, альтернативы, решение и последствия</td><td>Что код уже корректен во всех средах</td></tr><tr><td>Design document</td><td>Как устроить решение целиком?</td><td>Компоненты, потоки, контракты и детали реализации</td><td>Что выбранный дизайн принят как долгосрочное решение</td></tr><tr><td>Test</td><td>Какое поведение воспроизводится?</td><td>Условия, входы, ожидаемый результат, регрессия</td><td>Почему выбрана именно эта архитектура</td></tr><tr><td>Runbook</td><td>Что делать при операционном событии?</td><td>Команды, роли, stop condition и восстановление</td><td>Что исходный компромисс всё ещё применим</td></tr></tbody></table>\n<p>Ссылка на ticket или commit полезна для навигации, но не заменяет rationale. И наоборот, ADR не должен превращаться в копию implementation guide. Если решение требует детальной схемы, threat model или плана миграции, запишите выбор в ADR и свяжите его с отдельным документом.</p>\n<h2>Сначала зафиксируйте симптом и границу</h2>\n<p>Начинайте с наблюдаемого симптома, а не с названия технологии. Например: «клиент вызывает экспорт, но операция иногда не укладывается в границу HTTP-запроса; при повторе непонятно, создан ли второй экспорт». Это факт и вопрос. Гипотеза «нам нужна очередь» появляется только после проверки длительности операции, повторяемости запроса и требований caller.</p>\n<p>Затем назовите цену ошибки. В этом сценарии неверный выбор может дать дубли экспорта, зависшие записи, неограниченное хранение результатов или расхождение между статусом и фактическим завершением. Цена должна быть привязана к системе: какой ресурс останется, кто его удаляет, какая граница времени действует, какой контракт увидит клиент.</p>\n<p>Полезно записать decision drivers — факторы, по которым варианты будут сравниваться. Для экспорта это могут быть ограничение времени ответа, идемпотентность повторного запроса, наблюдаемость состояния, стоимость хранения и возможность вернуться к синхронному пути для коротких файлов. Если driver нельзя проверить или ему нет владельца, это пока предположение, а не доказательство.</p>\n<pre><code>Проблема: export иногда дольше жизни HTTP-запроса.\nОбязательные условия:\n- клиент получает подтверждение создания операции;\n- повтор запроса не создаёт второй экспорт;\n- состояние имеет срок хранения и владельца очистки.\nЦена ошибки: дубль работы или запись, которую никто не удаляет.\nВопрос решения: где хранить status и кто отвечает за его переходы?</code></pre>\n<p>Фрагмент — учебная заготовка. Он не сообщает реальную длительность, нагрузку или процент ошибок. В рабочей записи эти утверждения должны ссылаться на контракт, trace, тест, incident или другой доступный источник. Если данных нет, оставьте <em>evidence gap</em> и действие по его закрытию.</p>\n<h2>Сравнивайте альтернативы одной меркой</h2>\n<p>Сравнение ломается, когда выбранный вариант описан конкретно, а остальные получают ярлык «сложно». Приведите варианты к одному уровню и задайте одинаковые вопросы: выполняет ли вариант обязательные условия, где хранится состояние, как работает повтор, кто поддерживает очистку, как выглядит возврат и какое 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>Синхронный ответ</td><td>Простая модель для короткой операции</td><td>Не выдерживает временную границу; повтор может повторить работу</td><td>Не требуется отдельное состояние, но граница остаётся нерешённой</td></tr><tr><td>Очередь и status у сервиса экспорта</td><td>Отделяет подтверждение создания от завершения работы</td><td>Нужны idempotency key, срок хранения, cleanup и наблюдение переходов</td><td>Остановить новые async-запуски и вернуть короткие операции на прямой путь</td></tr><tr><td>Общий workflow между сервисами</td><td>Единый статус для нескольких владельцев процесса</td><td>Появляется общий контракт, координатор и cross-service ownership</td><td>Удалить интеграцию нельзя одной заменой; сначала нужен план вывода потребителей</td></tr><tr><td>Ничего не менять</td><td>Не добавляет новый компонент</td><td>Сохраняет таймауты, повторы и неясную ответственность</td><td>Обратимость высокая, но исходный симптом остаётся</td></tr></tbody></table>\n<p>В этой матрице нет итогового балла. Присвоить «3» за надёжность и «2» за стоимость можно только после определения шкалы, веса и источника данных. Без этого score создаёт видимость точности. Для небольшого решения достаточно назвать обязательное условие, показать trade-off и отметить, какие вопросы ещё не проверены.</p>\n<figure><img src=\"/assets/editorial/2024/adr-decisions-2024-alternatives-matrix.svg\" alt=\"Синтетическая матрица ADR: три варианта сравниваются по ограничению, обратимости, evidence и операционной цене\" loading=\"lazy\" /><figcaption>Схема показывает форму сравнения, а не рейтинг реальных архитектур. Значения в иллюстрации синтетические: их нельзя трактовать как измерение production-нагрузки или стоимости.</figcaption></figure>\n<h2>Запишите выбранный компромисс</h2>\n<p>После сравнения решение должно отвечать на вопрос «что меняем и почему именно сейчас». Важно записать не только положительную сторону. Для status-модели положительный эффект — caller не удерживает один долгий запрос. Отрицательная сторона — сервис теперь владеет жизненным циклом операции, а значит, обязан определить повтор, истечение срока, очистку и поведение при падении worker.</p>\n<pre><code># ADR-0042: асинхронный экспорт с локальным status\n\n## Status\nAccepted\n\n## Context and Problem Statement\nЭкспорт может выйти за временную границу HTTP-запроса. Повтор\nзапроса должен быть безопасным, а запись операции — удаляемой.\n\n## Decision Drivers\n- подтверждение создания отдельно от завершения;\n- идемпотентный повтор;\n- явные expiry и owner состояния;\n- возможность ограниченного возврата.\n\n## Considered Options\n1. Синхронный ответ.\n2. Очередь и status у сервиса экспорта.\n3. Общий workflow между сервисами.\n\n## Decision Outcome\nВыбираем очередь и status у сервиса экспорта: граница владения\nостаётся локальной, а caller получает отдельный контракт состояния.\n\n## Consequences\nПлюс: долгую работу можно наблюдать и повторять безопасно.\nМинус: нужны хранение, expiry, cleanup, retry policy и метрики.\nНе делаем: не превращаем локальный status в общий workflow.\n\n## Confirmation\nПроверить контракт повторного запроса, переходы status, expiry,\nудаление результата и возврат короткой операции на direct path.</code></pre>\n<p>Это воспроизводимый формат записи, но не готовая реализация очереди. Поля <em>Accepted</em>, <em>expiry</em> и <em>owner</em> не запускают процессы сами по себе. Их смысл должен быть закреплён в правилах репозитория: кто принимает запись, где она хранится, как связана с кодом и что считается подтверждением.</p>\n<h2>Проверьте отрицательный путь, а не только happy path</h2>\n<p>У решения есть границы «не делаем». Они защищают локальный механизм от незаметного расширения. В нашем примере сервис экспортов отвечает за собственные операции. Он не становится координатором платежей, уведомлений и нескольких downstream-сервисов. Если появился caller, которому нужен общий status процесса, это новое архитектурное условие, а не повод дописать исключение в старом ADR.</p>\n<p>Для каждой границы задайте обратный путь. Что остановит новые записи? Как найти незавершённые операции? Сколько времени хранить status? Что увидит клиент, если worker завершил файл, но не записал финальный статус? Ответы должны быть в контракте и runbook, а в ADR достаточно зафиксировать решение, цену и ссылки на эти проверки.</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>Один idempotency key даёт два задания</td><td>Ключ проверяют после постановки в очередь</td><td>Повторить запрос на тестовом хранилище и сравнить созданные ids</td><td>Перенести дедупликацию к границе создания и добавить регрессионный тест</td></tr><tr><td>Status показывает <code>done</code>, а файл недоступен</td><td>Переход статуса не связан с публикацией результата</td><td>Проверить порядок записи результата и смены status при сбое</td><td>Сделать переход атомарным для контракта или описать промежуточное состояние</td></tr><tr><td>Старые операции растут без ограничения</td><td>Expiry записан в ADR, но нет владельца cleanup</td><td>Найти job, журнал удаления и тест срока хранения</td><td>Назначить owner и не считать retention выполненным без evidence</td></tr><tr><td>Новый сервис использует локальный status</td><td>Граница применимости не стала частью контракта</td><td>Проверить список consumers и требования к общему процессу</td><td>Остановить расширение и создать successor ADR при новом scope</td></tr></tbody></table>\n<h2>Подтвердите связь записи с кодом</h2>\n<p>Confirmation — это не фраза «всё проверено», а конкретный способ сравнить принятое решение с реализацией. Для учебного ADR достаточно проверить наличие ключевых разделов и затем отдельно запустить тесты контракта. Команда ниже не требует стороннего инструмента и возвращает ненулевой код, если в файле пропущен обязательный заголовок.</p>\n<pre><code>set -eu\nadr='docs/decisions/ADR-0042-export-status.md'\ntest -s \"$adr\"\ngrep -q '^## Status$' \"$adr\"\ngrep -q '^## Context and Problem Statement$' \"$adr\"\ngrep -q '^## Decision Drivers$' \"$adr\"\ngrep -q '^## Considered Options$' \"$adr\"\ngrep -q '^## Decision Outcome$' \"$adr\"\ngrep -q '^## Consequences$' \"$adr\"\ngrep -q '^## Confirmation$' \"$adr\"\nprintf '%s\\n' 'ADR structure: OK'</code></pre>\n<p>Запустите эту проверку из корня репозитория после создания файла и замените путь на свой. Она проверяет только структуру Markdown. Она не доказывает идемпотентность, безопасность, latency, корректность миграции или наличие owner. Для этого нужны публичные тесты, review кода, нагрузочная проверка, threat model или операционный dry run — в зависимости от решения.</p>\n<h2>Сохраните историю и условие пересмотра</h2>\n<p>Accepted означает, что команда приняла решение в указанном контексте. Это не обещание, что оно навсегда верно, и не сигнал для автоматического запуска работ. Если предпосылка изменилась, не переписывайте старый record так, будто он изначально описывал новый путь. Создайте новую запись, свяжите её с предыдущей и укажите, какой факт изменил выбор.</p>\n<p>Статусы тоже требуют локального соглашения. <em>Proposed</em> может означать «готово к обсуждению», <em>Accepted</em> — «принято», <em>Rejected</em> — «рассмотрено и отклонено», <em>Superseded</em> — «заменено новой записью». Названия встречаются в официальных шаблонах, но workflow approval, даты и права на изменение задаёт конкретная команда.</p>\n<p>Сигнал пересмотра лучше формулировать как наблюдаемое условие: появился consumer, требующий общего status; retention превысил согласованный предел; contract upstream изменился; worker не укладывается в заданный класс операций. Дата review может напомнить о проверке, но сама по себе не означает, что решение устарело. У сигнала должен быть владелец и действие, иначе это пожелание.</p>\n<pre><code>## Reassessment\nОткрыть ADR-0043, если выполняется хотя бы одно условие:\n- второй сервис требует читать status как общий workflow;\n- изменился контракт повторного запроса;\n- retention больше согласованного срока;\n- cleanup не подтверждён тестом или операционным журналом.\nДействие: сравнить локальный status, общий workflow и прямой путь;\nстарую запись не редактировать.</code></pre>\n<h2>Рабочий порядок для команды</h2>\n<ol><li><strong>Сузьте вопрос.</strong> Назовите один значимый выбор, конкретную границу и затронутый контракт.</li><li><strong>Отделите факт от гипотезы.</strong> Запишите симптом и ссылку на источник; неподтверждённое вынесите в evidence gap.</li><li><strong>Назовите цену ошибки.</strong> Укажите, какие данные, время, права или обязанности будут потеряны при неверном пути.</li><li><strong>Соберите доступные варианты.</strong> Приведите их к одному уровню и добавьте «ничего не менять», если такой путь реален.</li><li><strong>Сравните по одинаковым drivers.</strong> Проверьте constraint fit, обратимость, операционную цену, владельца и остаточные риски.</li><li><strong>Запишите decision и отрицательный путь.</strong> Ясно укажите, что команда делает и чего намеренно не делает.</li><li><strong>Назначьте confirmation.</strong> Свяжите решение с тестом, контрактом, benchmark, threat model, runbook или другим проверяемым артефактом.</li><li><strong>Определите reassessment.</strong> Запишите наблюдаемый сигнал, владельца и действие; не полагайтесь на одну календарную дату.</li><li><strong>Сверьте ADR с реализацией.</strong> Если код выбрал другой вариант, исправьте расхождение или оформите новый decision, не переписывая историю.</li></ol>\n<h2>Ограничения применимости и критерий готовности</h2>\n<p>ADR полезен для значимых решений: границ компонентов, API и data contracts, зависимостей, non-functional requirements, способов миграции и технологических направлений. Для тривиального локального рефакторинга отдельная запись может создать больше шума, чем контекста. Порог значимости определяется командой; важно сделать его явным.</p>\n<p>ADR не является design document, threat model, benchmark, тестовым раннером, runbook или approval-системой. Он не гарантирует, что команда нашла все альтернативы, и не превращает отсутствие данных в доказанную безопасность. Для персональных данных, security, legal и recovery нужны профильные проверки с отдельными владельцами. Не публикуйте в открытом ADR секреты, персональные данные и внутренние ссылки без разрешённого доступа.</p>\n<p>Запись можно считать готовой, если читатель без поиска по переписке отвечает на пять вопросов: какой симптом наблюдали; какое условие нельзя нарушить; почему отклонили альтернативы; какую цену принимает выбранный путь; какой сигнал откроет следующий ADR. Если не назван owner состояния или не существует проверка отрицательного пути, документ ещё фиксирует намерение, а не устойчивое решение.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://adr.github.io/\" target=\"_blank\" rel=\"noopener noreferrer\">Architectural Decision Records — ADR GitHub Organization</a> — официальное определение архитектурного решения, ADR как записи одного выбора и rationale, а также decision log с trade-offs и consequences.</li><li><a href=\"https://github.com/architecture-decision-record/architecture-decision-record/blob/main/locales/en/templates/decision-record-template-by-michael-nygard/index.md\" target=\"_blank\" rel=\"noopener noreferrer\">Template by Michael Nygard — architecture-decision-record</a> — официальный репозиторий с полями Status, Context, Decision и Consequences.</li><li><a href=\"https://github.com/adr/madr/blob/4.0.0/template/adr-template.md\" target=\"_blank\" rel=\"noopener noreferrer\">MADR 4.0.0 ADR template</a> — официальный тегированный шаблон с decision drivers, considered options, decision outcome, consequences и confirmation; структура шаблона не является обязательной политикой каждой команды.</li><li><a href=\"https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html\" target=\"_blank\" rel=\"noopener noreferrer\">AWS Prescriptive Guidance: Architectural decision record process</a> — официальное описание области применения ADR, минимальных разделов и подхода с новой записью, superseding предыдущую при изменении решения.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/120.json b/editorial/agent-rewrites/120.json
index 04592da..d98c6e1 100644
--- a/editorial/agent-rewrites/120.json
+++ b/editorial/agent-rewrites/120.json
@@ -1 +1 @@
-{"index":120,"slug":"editorial-2024-09-practice-adr-decisions","title":"ADR без бюрократии: как сохранить причину технического решения","excerpt":"Практический разбор ADR: от наблюдаемого симптома и цены ошибки до проверяемого решения, отрицательного пути и даты пересмотра.","contentHtml":"<p>После релиза в коде остаётся необычный обходной путь: запрос проходит через отдельный слой, хотя прямой вызов короче. Через полгода обсуждение исчезает из чата, авторы переключаются на другие задачи, а reviewer видит только итоговый diff. Симптом прост: команда снова спорит, зачем существует условие, очередь или дополнительная граница.</p><p>Цена ошибки выше стоимости потерянного контекста. Можно удалить защиту, которая всё ещё нужна для старого ограничения. Можно оставить дорогую схему после того, как ограничение исчезло. Оба решения выглядят разумно, если известен только код. Нужен артефакт, который связывает наблюдаемую проблему с выбором и его последствиями.</p><h2>Тезис: ADR хранит причину, а не оправдание</h2><p>Architecture Decision Record фиксирует один значимый выбор. Он отвечает на пять вопросов: что произошло, какие ограничения действовали, какие варианты сравнили, что выбрали и какую цену приняли. Отдельно записывают владельца, статус и сигнал для пересмотра. ADR не объявляет решение вечным и не доказывает, что реализация корректна.</p><p>Это важная граница. Ticket хранит работу и сроки. Code review хранит обсуждение изменения. Test проверяет поведение. Runbook описывает операционное действие. ADR хранит rationale — причину, по которой команда выбрала один путь среди допустимых. Ссылка на ticket не заменяет rationale, а commit не заменяет сравнение альтернатив.</p><h2>Механизм: от симптома к записи</h2><p>Сначала отделите факт от интерпретации. Факт можно увидеть в логе, контракте, trace, конфигурации или наблюдаемом поведении. Интерпретация объясняет факт, но требует проверки. В ADR полезно явно назвать стоимость ошибки: потеря обратимости, рост задержки, новый владелец данных, риск несовместимости или усложнение отката.</p><p>Затем ограничьте вопрос. «Как устроить export» слишком широко. «Где caller получает status, если synchronous boundary не выполняется» уже задаёт предмет. Один ADR должен описывать один выбор. Если обсуждение меняет два независимых контракта, разделите записи и свяжите их ссылками.</p><p>Варианты сравнивают по одним и тем же критериям. В простом случае достаточно reversibility, соответствия constraint, стоимости эксплуатации и доступного evidence. Не превращайте невыбранные варианты в карикатуры. Если вариант «ничего не менять» не рассматривался, его стоит назвать отдельно: иногда это самый дешёвый и самый обратимый путь.</p><pre><code>Title: bounded cache at the BFF boundary\nStatus: Proposed\nOwner: application owner\nReview by: 2025-03-31\n\nContext: source contract permits bounded freshness.\nOptions: direct read; local cache; shared cache.\nDecision: choose local cache with named expiry.\nConsequences: add freshness check and direct-read rollback.\nEvidence question: does the source contract still permit this cache?</code></pre><p>Пример учебный. Он не создаёт cache, не обращается к repository и не сообщает latency, hit ratio или экономию. Его задача — показать форму записи. В настоящем ADR каждое утверждение о контракте должно ссылаться на доступный артефакт, а владелец должен иметь право проверить его.</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>В review спорят о старом обходном пути</td><td>Контекст остался в переписке</td><td>Найдите исходное ограничение и отделите факт от гипотезы</td><td>Создайте proposed ADR и укажите ссылку на code</td></tr><tr><td>В записи перечислен только выбранный путь</td><td>Альтернативы не стали частью решения</td><td>Проверьте, можно ли сравнить варианты по одним критериям</td><td>Добавьте реально рассмотренные варианты и причины отказа</td></tr><tr><td>Текст обещает «простую поддержку»</td><td>Последствия описаны абстрактно</td><td>Спросите, кто что должен сделать и какой риск остаётся</td><td>Запишите владельца, cost, rollback и signal пересмотра</td></tr><tr><td>ADR принят, но code изменился иначе</td><td>Запись смешана с реализацией</td><td>Сопоставьте decision с контрактом и diff отдельной проверкой</td><td>Исправьте code или обновите ADR новым решением; не переписывайте историю</td></tr><tr><td>Ограничение больше не действует</td><td>У записи нет review boundary</td><td>Проверьте дату, source contract и сигнал изменения</td><td>Создайте successor ADR со статусом superseded для старого</td></tr></tbody></table></div><h2>Как читать короткий ADR</h2><p>Хорошая запись начинается с контекста, но не превращается в историю всей команды. Достаточно назвать границу системы, затронутый контракт, decision drivers и цену неверного выбора. Слова «быстрее», «надёжнее» и «проще» требуют уточнения. Быстрее для какого сценария? Надёжнее при каком отказе? Проще для какого владельца?</p><p>Последствия должны включать отрицательную сторону. Если выбран local cache, положительный эффект может быть ограничен целевым read path. Цена — необходимость хранить expiry, проверять freshness и иметь путь к direct read. Если данные могут быть чувствительными, добавляется отдельная проверка класса данных. Не прячьте эту цену под словом «trade-off»: читателю нужно понимать, что именно он будет поддерживать.</p><p>Запишите две границы: что решение делает и чего оно не делает. В учебном примере мы создаём bounded local state с именованным expiry. Мы не создаём shared invalidation system и не объявляем число запросов измеренным результатом. Такая отрицательная часть защищает от незаметного расширения scope.</p><figure><img src=\"/assets/editorial/2024/adr-decisions-2024-decision-flow.svg\" alt=\"Схема потока ADR: симптом и цена ведут к контексту, вариантам и проверке; затем следуют решение, человеческое принятие, связь с кодом и пересмотр.\" loading=\"lazy\" /><figcaption>Схема показывает порядок работы с решением. Она не описывает конкретную approval-систему, репозиторий, CI или состояние production.</figcaption></figure><h2>Почему запись не заменяет проверку</h2><p>ADR может быть логичным и всё равно ошибочным. Он фиксирует состояние знаний на момент выбора. Контракт источника может измениться. Ограничение по данным может оказаться неверным. Операционная цена может вырасти. Поэтому Accepted означает «решение принято», а не «реализация доказана во всех средах».</p><p>Свяжите ADR с отдельным evidence question. Для cache это вопрос о допустимой freshness и о том, как обнаружить нарушение. Для миграции это вопрос о совместимости схемы и обратном пути. Для security-решения это вопрос о threat model и обязательной проверке. Не подменяйте evidence красивой формулировкой в разделе Consequences.</p><h2>Порядок работы с одной перепиской</h2><ol><li><strong>Ограничьте вопрос.</strong> Сформулируйте один выбор, его границу и затронутый контракт.</li><li><strong>Соберите факты.</strong> Запишите наблюдаемый симптом, дату, источник, owner и цену неверного выбора. Догадки пометьте как гипотезы.</li><li><strong>Назовите варианты.</strong> Добавьте два-три реально доступных пути, включая вариант ничего не менять, если он был возможен.</li><li><strong>Сравните одинаково.</strong> Используйте один набор критериев: constraint fit, обратимость, стоимость эксплуатации и пробел в evidence.</li><li><strong>Зафиксируйте решение.</strong> Укажите выбранный вариант, status, дату и человека, который принимает решение.</li><li><strong>Опишите последствия.</strong> Назовите положительную сторону, цену, отрицательный путь и условие rollback. Не обещайте измерения, которых ещё нет.</li><li><strong>Назначьте пересмотр.</strong> Запишите дату или сигнал: изменение контракта, превышение лимита, новый класс данных или невозможность выполнить проверку.</li><li><strong>Свяжите артефакты.</strong> После реализации добавьте ссылки на code, test, metric question или runbook. Ссылки помогают навигации, но не заменяют чтение этих артефактов.</li><li><strong>Проверьте расхождение.</strong> Сравните ADR с реализацией. Если code ушёл в другой вариант, исправьте code либо оформите новый decision.</li></ol><h2>Ограничения и отрицательный путь</h2><p>ADR не заменяет design document, threat model, migration plan, benchmark, test plan, runbook или incident review. Он не гарантирует полноту альтернатив и не превращает согласие участников в технический факт. Формат нужно подстроить под локальные правила хранения, доступа и approval.</p><p>Не редактируйте старую запись так, чтобы она описывала новое решение. История нужна именно для ответа на вопрос «почему раньше сделали так». Если предпосылка исчезла, старый ADR получает статус superseded, а новый record объясняет следующий компромисс. Это сохраняет причинность и не заставляет будущего читателя угадывать, какая версия текста была действующей.</p><p>Не называйте synthetic пример production-результатом. Не добавляйте вымышленные числа, названия сервисов и ссылки на несуществующие dashboards. Если факт нельзя проверить, напишите, какой артефакт должен его подтвердить. Такой пробел полезнее уверенного, но ложного вывода.</p><h2>Проверяемый критерий готовности</h2><p>ADR готов, когда новый читатель без поиска по чату может назвать симптом, constraint, цену ошибки, выбранный вариант и отклонённые альтернативы. Он видит владельца, статус и дату или сигнал пересмотра. Он понимает отрицательный путь и знает, где проверяется реализация. При сравнении с code не возникает скрытого второго решения. Если хотя бы один пункт требует догадки, запись ещё не готова.</p><h2>Проверяемые источники</h2><ul><li><a href=\"https://adr.github.io/\" target=\"_blank\" rel=\"noopener noreferrer\">Architectural Decision Records</a> — официальный сайт сообщества ADR: record фиксирует решение и rationale, включая trade-offs и consequences.</li><li><a href=\"https://github.com/adr/madr\" target=\"_blank\" rel=\"noopener noreferrer\">MADR: Markdown Architectural Decision Records</a> — официальный репозиторий шаблонов и документации MADR с вариантами обязательных и расширенных разделов.</li></ul>"}
+{"index":120,"slug":"editorial-2024-09-practice-adr-decisions","title":"ADR без бюрократии: как сохранить причину технического решения","excerpt":"Практический разбор ADR на учебном BFF-кейсе: как отделить факт от гипотезы, сравнить альтернативы, записать цену выбора и понять, когда нужен новый decision record.","contentHtml":"<p>После релиза в коде остаётся обходной путь: запрос идёт через отдельный слой, хотя прямой вызов короче. Через полгода обсуждение исчезает из чата, авторы переключаются на другие задачи, а reviewer видит только итоговый diff. Симптом легко узнать: команда снова спорит, зачем существует условие, очередь или дополнительная граница.</p><p>Цена ошибки выше стоимости потерянного контекста. Если удалить защиту слишком рано, вернётся старое ограничение. Если оставить её навсегда, команда продолжит платить за лишнее состояние, тесты и поддержку. По одному коду нельзя восстановить, какой риск когда-то перевешивал. Нужна короткая запись, связывающая наблюдаемую проблему, выбор и принятую цену.</p><p>Такую запись обычно называют ADR (Architecture Decision Record). В этой статье разберём практический маршрут для одного решения на границе BFF (Backend for Frontend): как понять, нужен ли кэш, какие варианты сравнить и как записать результат так, чтобы он не стал ложным разрешением на любую будущую оптимизацию.</p><h2>Что именно сохраняет ADR</h2><p>ADR фиксирует один значимый технический выбор и его rationale — объяснение, почему выбран этот путь. Минимальное содержимое: контекст и проблема, рассмотренные варианты, decision и последствия. Для каждого утверждения полезно оставить источник: контракт, тест, измерение, issue или ссылку на другой документ.</p><p>У записи есть границы ответственности. Ticket описывает работу и срок. Code review хранит обсуждение конкретного изменения. Test проверяет поведение. Runbook описывает операционное действие. ADR отвечает на другой вопрос: почему команда выбрала одну допустимую форму системы вместо других. Ссылка на ticket помогает найти детали, но не заменяет rationale.</p><p>Статус тоже не является переключателем. <em>Proposed</em> означает, что запись подготовлена к обсуждению. <em>Accepted</em> означает, что команда приняла решение. <em>Superseded</em> означает, что новый ADR заменил старый и объяснил изменение. Ни один статус сам по себе не запускает код, миграцию, approval или проверку отката.</p><h2>Учебный симптом на границе BFF</h2><p>Возьмём ограниченный пример. SSR-приложение обращается через BFF к каталогу предложений. Для одного экрана одинаковый справочник читается много раз за короткий интервал. Прямой запрос проще и всегда получает актуальный ответ, но увеличивает число обращений к upstream. Локальный кэш может сократить повторные чтения, однако добавляет TTL, риск устаревшего ответа и обязанность очищать состояние.</p><p>Это не отчёт о конкретной production-системе: в статье нет реальных latency, traffic, hit ratio или экономии. Сценарий нужен, чтобы воспроизвести форму анализа. В своём проекте подставьте контракт источника, допустимую свежесть, класс данных, owner и измерение. Если эти сведения неизвестны, ADR должен назвать их открытым вопросом, а не превращать предположение в факт.</p><p>Сначала запишем наблюдаемое и неизвестное отдельно:</p><pre><code>Наблюдаемый факт: один экран повторяет чтение одного справочника.\nИсточник факта: trace или счётчик запросов, приложенный к задаче.\nГипотеза: часть чтений можно обслужить из bounded local cache.\nОбязательное условие: ответ не старше согласованного TTL.\nНеизвестно: разрешает ли upstream такой уровень устаревания.\nЦена ошибки: устаревшие данные или рост нагрузки на upstream.</code></pre><p>Важна именно последовательность. «Добавим кэш, потому что медленно» — решение без доказанной причины. Сначала нужно подтвердить повторяемость чтений и спросить владельца контракта, допустима ли заданная свежесть. Если upstream требует read-after-write для этого справочника, локальный кэш не проходит constraint fit независимо от удобства реализации.</p><h2>Как сравнивать варианты на одной шкале</h2><p>Сравнивайте решения, а не рекламные формулировки. Для этого задайте одинаковые поля: соответствие обязательному условию, обратимость, evidence gap и стоимость эксплуатации. «Проще» без указания владельца и границы ничего не измеряет. Вариант «ничего не менять» тоже стоит назвать, если он действительно доступен: иногда дополнительное состояние опаснее лишнего запроса.</p><div class=\"table-scroll\"><table><caption>Учебная матрица для решения о кэше на BFF-границе</caption><thead><tr><th scope=\"col\">Вариант</th><th scope=\"col\">Что закрывает</th><th scope=\"col\">Цена и риск</th><th scope=\"col\">Что проверить</th></tr></thead><tbody><tr><td>Прямой запрос</td><td>Актуальность ответа без локального состояния</td><td>Повторная нагрузка на upstream; нет TTL и cleanup</td><td>Лимит запросов, latency и допустимость текущей нагрузки</td></tr><tr><td>Bounded local cache</td><td>Повторное чтение в пределах объявленного TTL</td><td>Устаревший ответ, invalidation, память и владелец кэша</td><td>Контракт freshness, класс данных, hit ratio и путь direct read</td></tr><tr><td>Общий cache-сервис</td><td>Разделяемое состояние для нескольких потребителей</td><td>Новый сервис, сеть, права, отказ и cross-team owner</td><td>Действительно ли нужен общий владелец и как переживается недоступность</td></tr><tr><td>Ничего не менять</td><td>Сохраняет простую модель и отсутствие нового состояния</td><td>Нагрузка остаётся; возможно, проблема не подтверждена</td><td>Повторить измерение и проверить, есть ли пользовательский эффект</td></tr></tbody></table></div><p>Матрица не выдаёт победителя автоматически. Она заставляет привести варианты к сопоставимому масштабу. Если для кэша известен TTL, а для общего сервиса написано только «сложно», данные ещё не симметричны. Если используете баллы и веса, приложите шкалу и объясните, какие риски модель не учитывает. Итоговый score помогает провести разговор, но не доказывает корректность решения.</p><figure><img src=\"/assets/editorial/2024/adr-decisions-2024-decision-flow.svg\" alt=\"Поток ADR от наблюдаемого симптома и цены ошибки через ограничения и альтернативы к принятому решению, проверке реализации и successor ADR при изменении условий.\" loading=\"lazy\" /><figcaption>ADR связывает контекст и выбор, но реализация и evidence проходят отдельную проверку. Ветвь successor ADR сохраняет историю, если исходное условие изменилось.</figcaption></figure><h2>Минимальная запись решения</h2><p>После проверки контракта допустим учебный исход: upstream разрешает ограниченную свежесть, справочник не содержит данных, требующих немедленного read-after-write, а direct read остаётся доступным при промахе или отключении кэша. Тогда можно предложить локальное bounded state. Ниже — запись в формате, который можно положить в каталог decisions. Она не создаёт кэш и не утверждает измеренный результат.</p><pre><code># ADR-0042: bounded cache at the BFF boundary\n\n## Status\nProposed\n\n## Context and problem\nSSR повторяет чтение одного справочника. Upstream разрешает\nответ не старше согласованного TTL. Для критичных изменений\nтребуется direct read.\n\n## Options considered\n- direct read;\n- bounded local cache with explicit TTL;\n- shared cache service.\n\n## Decision\nНачать с bounded local cache только для этого read path.\nПри недоступном кэше читать upstream напрямую.\n\n## Consequences\nПлюс: повторные чтения ограничены TTL.\nЦена: owner состояния, expiry, наблюдение за freshness и cleanup.\n\n## Not in scope\nНе вводим shared cache-сервис и не распространяем решение\nна другие callers без нового ADR.\n\n## Reassessment\nОткрыть successor ADR при изменении контракта freshness,\nпоявлении чувствительных данных или нового потребителя.</code></pre><p>Учебный фрагмент показывает причинность: симптом связан с ограничением, варианты перечислены, цена названа, а отрицательный путь ограничивает scope. В настоящую запись добавьте ссылки на подтверждённый контракт, тест, trace или controlled experiment. Статус <em>Proposed</em> означает, что документ ещё нужно проверить владельцу upstream и участникам, которых затрагивает кэш.</p><h2>Как связать ADR с реализацией и evidence</h2><p>Решение и доказательство нельзя слить в один абзац. После принятия ADR команда отдельно проверяет реализацию: TTL действительно ограничен, ключ кэша не смешивает разные контексты, промах или ошибка не блокируют direct read, а чувствительные данные не попадают в неподходящее хранилище. Это уже область тестов, threat model, ревью и наблюдаемости.</p><p>Полезно сформулировать evidence question до изменения кода. Например: «Для выбранного read path доля повторных запросов превышает порог X, а upstream разрешает TTL Y секунд». Числа X и Y должны прийти из вашего контракта и измерения; в учебной статье их нельзя выдумывать. По итогам controlled test в ADR можно добавить ссылку на артефакт и уточнить последствия. Сам факт наличия ссылки не превращает эксперимент в гарантию для всех нагрузок.</p><p>Связь с кодом должна быть двусторонней и короткой: ADR ссылается на реализацию, тест и метрику; code review ссылается на ADR, чтобы reviewer мог проверить границу решения. Если diff добавляет shared invalidation, новую схему данных или другой срок хранения, это уже не «деталь», а возможное новое решение. Не прячьте его в implementation note.</p><h2>Когда принятый ADR нельзя редактировать</h2><p>Предпосылки решения со временем меняются. Upstream может начать требовать строгую свежесть, появится второй потребитель, изменится класс данных или стоимость shared service станет приемлемой. В такой ситуации старый ADR не следует переписывать задним числом. Иначе исчезнет ответ на вопрос, почему прежний код был разумным при старых условиях.</p><p>Создайте новый record со статусом <em>Proposed</em>, свяжите его с исходным и опишите, что именно изменилось. После принятия нового решения старое получает <em>Superseded</em>. Это не формальность: append-only история отделяет прежний компромисс от нового и помогает безопасно читать старые ссылки в issue, review и runbook.</p><p>Дата пересмотра полезна только вместе с действием и владельцем. Дата сама не откроет документ. Надёжнее написать условие: «пересмотреть, если контракт freshness изменился или список callers вышел за пределы BFF». Для измеримых условий добавьте источник и того, кто должен инициировать review.</p><h2>Симптом → причина → проверка → действие</h2><div class=\"table-scroll\"><table><caption>Типовые ошибки при создании ADR</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Вероятная причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Следующее действие</th></tr></thead><tbody><tr><td>Записан только победитель</td><td>Решение приняли по вкусу, а не по constraint</td><td>Заполнить одинаковые поля для двух-трёх вариантов</td><td>Добавить downside выбранного пути и причины отказа</td></tr><tr><td>В Consequences обещана экономия</td><td>Учебную гипотезу выдали за измерение</td><td>Найти trace, benchmark или метрику с единицей измерения</td><td>Убрать число либо добавить ссылку на evidence</td></tr><tr><td>Кэш расширяется на новых callers</td><td>Граница применения осталась неявной</td><td>Сверить список потребителей и contract freshness</td><td>Остановить расширение и открыть новый ADR</td></tr><tr><td>Флаг выключили, но старый путь удалили</td><td>Rollback смешали с cleanup</td><td>Проверить, может ли система вернуться к direct read</td><td>Разделить изменение поведения и удаление ветки</td></tr><tr><td>Новый ADR переписывает старый</td><td>Историю принимают за текущую конфигурацию</td><td>Проверить ссылки и статусы двух записей</td><td>Оставить старый текст, связать successor и объяснить drift</td></tr></tbody></table></div><p>Эта таблица применима как диагностическая последовательность, а не как чек-лист полноты архитектуры. Например, ошибка кэша может быть не в выборе варианта, а в неверном ключе или cache-control заголовке. ADR помогает увидеть исходный компромисс, но не заменяет проверку конкретной реализации.</p><h2>Практический порядок работы</h2><ol><li><strong>Сузьте вопрос.</strong> Назовите одного caller, одну границу и одно обязательное условие. «Ускорить систему» слишком широко; «ограничить повторные чтения этого справочника при допустимой свежести» проверяемо.</li><li><strong>Соберите факты.</strong> Укажите наблюдаемый симптом, источник, дату наблюдения и цену неверного выбора. Отделите гипотезу от того, что действительно видно в trace, контракте или тесте.</li><li><strong>Проверьте constraint.</strong> Спросите владельца upstream о freshness, лимитах, правах и классе данных. Неподтверждённое условие оставьте evidence gap.</li><li><strong>Перечислите варианты.</strong> Добавьте два-три пути одного масштаба. Включите «ничего не менять», если он не нарушает обязательное условие.</li><li><strong>Сравните одинаково.</strong> Для каждого варианта назовите границу, owner, обратимость, операционную цену, неизвестное и отрицательный путь.</li><li><strong>Запишите decision.</strong> Формулировка должна сказать, что делаем и чего не делаем. Не объявляйте учебный пример результатом production.</li><li><strong>Проведите review.</strong> Участники должны проверить context, alternatives, consequences, status и затронутые контракты до начала реализации.</li><li><strong>Свяжите evidence.</strong> После controlled test или релиза добавьте ссылки на код, тест, trace, метрику или runbook. Ссылка не заменяет саму проверку.</li><li><strong>Проверьте drift.</strong> При новом consumer, изменении контракта или другой цене решения откройте successor ADR, а не дописывайте старый задним числом.</li></ol><h2>Ограничения применимости</h2><p>ADR не заменяет design document, threat model, migration plan, benchmark, test plan, runbook или incident review. Он не измеряет latency, надёжность, стоимость и безопасность без соответствующего evidence. Он также не гарантирует, что команда нашла все варианты: качество зависит от состава участников, доступных фактов и времени на review.</p><p>Не каждую мелкую правку стоит оформлять отдельной архитектурной записью. Кандидатами являются решения, которые меняют структуру, API или другой опубликованный контракт, качество сервиса, зависимости, владение состоянием либо плохо обратимы. Граница «значимости» командная; её лучше закрепить в локальном шаблоне, чтобы не превращать ADR в журнал каждого переименования.</p><p>Локальный кэш из примера нельзя переносить на персональные или чувствительные данные без отдельного анализа хранения, доступа и очистки. BFF не становится владельцем бизнес-истины только потому, что временно хранит ответ. При строгой консистентности direct read или иной контракт может быть единственно допустимым вариантом.</p><p>Форматы ADR различаются. Можно хранить записи в Git, wiki или специальном каталоге, если команда сохраняет версионирование, доступность, единый шаблон и историю статусов. Конкретные поля вроде confidence, stakeholders и review trigger выбираются по риску решения. Источник формата не является разрешением игнорировать требования безопасности, права доступа и отраслевые процессы.</p><h2>Критерий готовности</h2><p>Новый читатель должен без поиска по чату ответить на пять вопросов: какой симптом наблюдали; какое ограничение обязательно; какие варианты сравнивали; какую цену принимает выбранный путь; что заставит открыть новый ADR. Он должен отличать подтверждённый факт от гипотезы и понимать, где проверяется реализация.</p><p>Финальная проверка короткая. Уберите из записи заголовок <em>Decision</em> и попросите коллегу восстановить выбор по Context, Options и Consequences. Если коллега не может назвать owner, отрицательный путь или сигнал пересмотра, ADR ещё не готов. Если запись обещает измеренный эффект без источника, эффект нужно убрать или измерить отдельно.</p><h2>Проверяемые источники</h2><ul><li><a href=\"https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html\" target=\"_blank\" rel=\"noopener noreferrer\">AWS Prescriptive Guidance: Architectural decision record process</a> — описание контекста, decision, consequences, статусов, owner и процесса review; AWS отдельно объясняет, что принятый ADR не переписывают, а новое решение оформляют как successor.</li><li><a href=\"https://learn.microsoft.com/en-us/azure/well-architected/architect-role/architecture-decision-record\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn: Maintain an architecture decision record (ADR)</a> — рекомендации по options, trade-offs, status, append-only истории и границе между ADR и подробным design guide.</li><li><a href=\"https://adr.github.io/madr/\" target=\"_blank\" rel=\"noopener noreferrer\">MADR: Markdown Architectural Decision Records</a> — официальный сайт проекта с lean-шаблонами, rationale, примерами и практикой версионирования решений.</li></ul>"}
diff --git a/editorial/agent-rewrites/121.json b/editorial/agent-rewrites/121.json
index 1bdb86c..f21b286 100644
--- a/editorial/agent-rewrites/121.json
+++ b/editorial/agent-rewrites/121.json
@@ -3,5 +3,5 @@
   "slug": "editorial-2024-08-field-feature-flags",
   "title": "Feature flag после rollout: как отделить rollback от cleanup",
   "excerpt": "Выключенный feature flag прекращает выдачу нового поведения, но не удаляет ветки, конфигурацию и несовместимые данные. Разбираем безопасный rollout, проверяемый rollback и отдельный cleanup gate.",
-  "contentHtml": "<p>Новый экран работает у сотрудников, но часть клиентов внезапно видит его после релиза. Команда ставит feature flag в <code>false</code>. Ошибка исчезает, график успокаивается, change закрывают. Через месяц в коде всё ещё живут две ветки, в конфигурации лежит старый ключ, а тесты проверяют два ответа. Любая случайная смена окружения может вернуть candidate-путь. Цена ошибки — повторный инцидент, долгий поиск владельца и риск для данных, которые новый путь уже успел записать.</p>\n<p>Обратный случай не безопаснее. Rollout достиг 100 процентов, и это объявили завершением. Но 100 процентов означает только текущий результат правила для объявленной аудитории. Это не доказывает совместимость данных, исправность recovery path и право удалить fallback. Feature flag — не одно переключение, а временный контракт: кто получает вариант, кто его вычисляет, что считается остановкой и когда старый путь перестаёт быть нужен.</p>\n<p><strong>Тезис.</strong> Rollout, rollback и cleanup нужно проводить разными изменениями. Rollout расширяет аудиторию. Rollback останавливает candidate и возвращает fallback. Cleanup удаляет лишнюю ветку после выбора итогового поведения. Если смешать эти операции, команда теряет причинную связь и принимает отключение за исправление.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Флаг выключен, но в коде остались две ветки</td><td>Rollback смешали с удалением реализации</td><td>Найти evaluator, branches, config references и тесты по ключу</td><td>Оставить fallback исполняемым, открыть отдельный cleanup change</td></tr><tr><td>100% rollout считают доказательством готовности</td><td>Процент подменяет проверку контракта и данных</td><td>Сверить cohort key, effective config version, stop condition и recovery path</td><td>Заморозить процент и провести решение о final variant</td></tr><tr><td>После возврата к fallback часть запросов получает ошибку</td><td>Candidate записал состояние, которое fallback не читает</td><td>Проверить read/write compatibility и миграционный контракт</td><td>Остановить расширение; исправить совместимость отдельно от flag value</td></tr><tr><td>После удаления ключ снова появляется в UI</td><td>Остался client check, stale cache или старый payload</td><td>Проверить server response, client bundle, cache key и config</td><td>Удалить presentation toggle и оставить только итоговый UI contract</td></tr><tr><td>Никто не может назвать дату удаления</td><td>У флага нет owner, final variant и cleanup gate</td><td>Запросить карточку решения с evidence и списком references</td><td>Не расширять rollout; назначить владельца и новый change</td></tr></tbody></table>\n<h2>Как работает решение</h2>\n<p>Сначала evaluator получает ключ флага и контекст. Контекст должен однозначно описывать subject, окружение и другие поля, которые участвуют в targeting. Для процентного rollout особенно важен стабильный cohort key. Если сегодня используется user id, а завтра случайный request id, один пользователь будет переходить между вариантами. Это уже не gradual rollout, а непредсказуемое распределение.</p>\n<p>Evaluator возвращает выбранный вариант и, если система это поддерживает, детали оценки: key, value, variant, reason и версию конфигурации. Приложение применяет результат в одной точке. Второй слой не должен пересчитывать то же правило с другим контекстом. Иначе сервер отдаст новый ответ, а клиент решит, что пользователь относится к fallback-группе.</p>\n<p>Процент не описывает весь жизненный цикл. Он не говорит, обновился ли client cache, дошёл ли запрос до нового обработчика и можно ли откатить данные. Для каждого этапа нужны вопрос наблюдения и заранее выбранное действие. При остановке меняют одну существенную переменную: аудиторию, правило или код. Одновременная смена процента, evaluator и схемы данных уничтожает полезность сравнения.</p>\n<pre><code>type FlagDecision = {\n  key: string;\n  variant: 'fallback' | 'candidate';\n  cohortKey: string;\n  configVersion: string;\n};\n\nfunction renderCheckout(decision: FlagDecision, order: Order) {\n  if (decision.variant === 'candidate') {\n    return renderNewCheckout(order);\n  }\n\n  return renderLegacyCheckout(order);\n}</code></pre>\n<p>Этот фрагмент — учебный. Он показывает границу между результатом оценки и применением варианта. В нём нет настоящего flag provider, хранилища, телеметрии, миграции или команды rollback. В рабочей системе нужно дополнительно определить формат контекста, источник версии конфигурации, правила кеширования и поведение при ошибке evaluator.</p>\n<h2>Учебная лестница rollout</h2>\n<table><thead><tr><th>Этап</th><th>Вопрос</th><th>Стоп-условие</th><th>Действие</th></tr></thead><tbody><tr><td>0%</td><td>Fallback выполняет согласованный smoke scenario?</td><td>Старый путь уже не работает</td><td>Не включать candidate; исправить базовый контракт</td></tr><tr><td>5%</td><td>Одна стабильная cohort получает candidate в объявленной версии?</td><td>Сигнал нарушает заранее записанную границу</td><td>Вернуть аудиторию к 0%, сохранить конфигурацию и вопрос расследования</td></tr><tr><td>25%</td><td>Candidate можно сопоставить с fallback в одном окне?</td><td>Версия или источник сигнала неизвестны</td><td>Остановить расширение и не менять правило вместе с кодом</td></tr><tr><td>100%</td><td>Вся объявленная аудитория получает выбранный вариант?</td><td>Final variant не утверждён или fallback нужен для recovery</td><td>Не удалять флаг; открыть решение о завершении</td></tr><tr><td>Cleanup gate</td><td>Код и конфигурация больше не требуют alternate branch?</td><td>Осталась runtime reference или зависимость данных</td><td>Вернуть cleanup в доработку</td></tr></tbody></table>\n<p>Значения 0, 5, 25 и 100 процентов в таблице — фиксированный учебный пример. Они не являются рекомендацией, нормативом или результатом измерения. Реальный шаг выбирают по размеру риска, качеству сигнала, обратимости и размеру cohort. Если команда не может назвать population, control, окно и владельца решения, процент не даёт полезной информации.</p>\n<figure><img src=\"/assets/editorial/2024/feature-flags-2024-cleanup-gate.svg\" alt=\"Rollout переходит к rollback и cleanup gate только после отдельного решения о финальном варианте\"><figcaption>Rollout расширяет аудиторию, rollback возвращает fallback, cleanup удаляет alternate branch. Проценты на схеме относятся к учебной модели.</figcaption></figure>\n<h2>Rollback возвращает поведение, но не переписывает историю</h2>\n<p>При stop condition минимальное действие — прекратить дальнейшее расширение candidate. Для этого возвращают аудиторию к fallback или к заранее определённому safe value. Записывают effective config version и причину остановки. Не нужно в тот же момент удалять ветки, менять evaluator и переписывать миграцию. Иначе нельзя будет понять, что именно остановило симптом.</p>\n<p>Rollback значения флага не равен rollback данных. Если candidate уже создал записи, отправил события или изменил схему ответа, старый путь должен уметь прочитать это состояние. Фича-флаг не добавляет backward compatibility автоматически. Если fallback не понимает результат candidate, ответом должен стать отдельный migration contract, а не уверенность, что <code>false</code> решает всё.</p>\n<p>Также не стоит называть rollback мгновенным. Сервис, edge-кеш и браузер могут получить конфигурацию в разное время. В карточке изменения укажите, где вычисляется вариант, сколько живёт кеш и что происходит с активной сессией. Разница версий допустима только тогда, когда она входит в контракт и не ломает recovery path.</p>\n<h2>Cleanup — отдельное решение</h2>\n<p>Cleanup начинается после выбора единственного поведения. Сначала владелец фиксирует final variant. Затем команда перестаёт добавлять новые условия и открывает отдельное изменение удаления. В его области должны быть server branches, client checks, configuration, permissions, tests, документация и миграционные заметки.</p>\n<p>Проверка cleanup строится на отрицательных утверждениях. Runtime больше не вызывает evaluator для ключа. Клиент не переключает UI по старому payload. Конфигурация не содержит targeting rules и environment overrides, нужные только флагу. Тесты проверяют итоговый business contract, а не сохранение двух boolean-веток. Документ объясняет принятое поведение, но не предлагает включить исчезнувший путь.</p>\n<p>Глобальный поиск по имени ключа полезен, но недостаточен. Ключ может быть собран из частей, сохранён в типе, скрыт в конфиге или пришит к кешу. Ищите вызовы evaluator, schema fields, token scopes, generated client types и тестовые данные. Если reference нужна для обратимой миграции, cleanup ещё не завершён: у неё должен быть owner и срок следующей проверки.</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Опишите контракт.</strong> Назовите owner, evaluator, cohort key, fallback, config version и данные, которые меняет candidate.</li><li><strong>Проверьте fallback.</strong> Выполните smoke scenario и убедитесь, что старый путь доступен до включения нового.</li><li><strong>Запишите stop condition.</strong> Свяжите её с конкретным сигналом, окном, источником и действием на остановке.</li><li><strong>Запускайте один этап.</strong> Не меняйте одновременно аудиторию, правило, код и схему данных.</li><li><strong>При проблеме остановите расширение.</strong> Верните cohort к fallback, сохраните effective config version и отделите mitigation от поиска причины.</li><li><strong>Проверьте совместимость данных.</strong> Убедитесь, что fallback читает состояние, которое оставил candidate, либо оформите отдельную миграцию.</li><li><strong>После выбора final variant заморозьте flag policy.</strong> Не добавляйте новые условия и не продлевайте флаг без новой причины.</li><li><strong>Проведите cleanup search.</strong> Проверьте server, client, config, кеши, права, тесты и документацию.</li><li><strong>Удалите артефакты отдельным change.</strong> Сохраните тест итогового поведения и обычный rollback plan для самого cleanup-релиза.</li><li><strong>Закройте решение.</strong> Зафиксируйте final variant, owner, причину удаления и evidence отсутствия runtime-зависимости.</li></ol>\n<h2>Ограничения</h2>\n<p>Этот подход не выбирает конкретный SDK, размер cohort, TTL кеша, SLO или схему миграции. OpenFeature даёт общий API для evaluation context и результата, но не задаёт правила вашей платформы. Kubernetes rollback относится к версии Deployment и его Pod template; он не доказывает обратимость бизнес-данных. Система флагов также не доказывает качество эксперимента: для этого нужны отдельные метрики, контрольная группа и методика измерения.</p>\n<p>Не следует удалять fallback только потому, что candidate получил 100 процентов. Не следует сохранять flag навсегда только потому, что когда-то существовал инцидент. Если данные, кеш или долгоживущий consumer не описаны, это блокер cleanup. Если evaluator недоступен, нужен явный default и проверяемая политика ошибки. Если неизвестно, какой вариант является итоговым, сначала принимают это решение, а потом удаляют код.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Cleanup готов, если независимая проверка отвечает «да» на все вопросы: final variant записан владельцем; fallback больше не нужен для recovery или миграции; runtime не зависит от ключа; client и server не пересчитывают старое правило; configuration и permissions не содержат флаговые остатки; тесты сохраняют итоговое поведение; обычный релизный rollback не требует возвращать удалённый flag.</p>\n<p>До этого момента выключенный флаг нужно считать остановленным, но не удалённым. Такое различие сохраняет причину, границу действия и следующий шаг. Оно также не даёт спокойному графику скрыть технический долг, который снова станет пользовательской ошибкой.</p>\n<h2>Проверяемые источники</h2>\n<p><a href=\"https://openfeature.dev/docs/reference/concepts/evaluation-context/\" target=\"_blank\" rel=\"noopener\">OpenFeature: Evaluation Context</a> — официальный материал о контексте оценки, targeting key и рисках передачи персональных данных.</p>\n<p><a href=\"https://openfeature.dev/docs/reference/concepts/evaluation-api/\" target=\"_blank\" rel=\"noopener\">OpenFeature: Evaluation API</a> — официальное описание результата оценки и его деталей.</p>\n<p><a href=\"https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/\" target=\"_blank\" rel=\"noopener\">Kubernetes: Update a Deployment Without Downtime</a> — официальная документация о проверке обновления и возврате Deployment к предыдущей ревизии.</p>"
+  "contentHtml": "<p>Новый экран работает у сотрудников, но часть клиентов внезапно видит его после релиза. Команда ставит feature flag в <code>false</code>. Ошибка исчезает, график успокаивается, change закрывают. Через месяц в коде всё ещё живут две ветки, в конфигурации лежит старый ключ, а тесты проверяют два ответа. Любая случайная смена окружения может вернуть candidate-путь. Цена ошибки — повторный инцидент, долгий поиск владельца и риск для данных, которые новый путь уже успел записать.</p>\n<p>Обратный случай не безопаснее. Rollout достиг 100 процентов, и это объявили завершением. Но 100 процентов означает только текущий результат правила для объявленной аудитории. Это не доказывает совместимость данных, исправность recovery path и право удалить fallback. Feature flag — не одно переключение, а временный контракт: кто получает вариант, кто его вычисляет, что считается остановкой и когда старый путь перестаёт быть нужен.</p>\n<p><strong>Тезис.</strong> Rollout, rollback и cleanup нужно проводить разными изменениями. Rollout расширяет аудиторию. Rollback останавливает candidate и возвращает fallback. Cleanup удаляет лишнюю ветку после выбора итогового поведения. Если смешать эти операции, команда теряет причинную связь и принимает отключение за исправление.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Флаг выключен, но в коде остались две ветки</td><td>Rollback смешали с удалением реализации</td><td>Найти evaluator, branches, config references и тесты по ключу</td><td>Оставить fallback исполняемым, открыть отдельный cleanup change</td></tr><tr><td>100% rollout считают доказательством готовности</td><td>Процент подменяет проверку контракта и данных</td><td>Сверить cohort key, effective config version, stop condition и recovery path</td><td>Заморозить процент и провести решение о final variant</td></tr><tr><td>После возврата к fallback часть запросов получает ошибку</td><td>Candidate записал состояние, которое fallback не читает</td><td>Проверить read/write compatibility и миграционный контракт</td><td>Остановить расширение; исправить совместимость отдельно от flag value</td></tr><tr><td>После удаления ключ снова появляется в UI</td><td>Остался client check, stale cache или старый payload</td><td>Проверить server response, client bundle, cache key и config</td><td>Удалить presentation toggle и оставить только итоговый UI contract</td></tr><tr><td>Никто не может назвать дату удаления</td><td>У флага нет owner, final variant и cleanup gate</td><td>Запросить карточку решения с evidence и списком references</td><td>Не расширять rollout; назначить владельца и новый change</td></tr></tbody></table>\n<h2>Как работает решение</h2>\n<p>Сначала evaluator получает ключ флага и контекст. Контекст должен однозначно описывать subject, окружение и другие поля, которые участвуют в targeting. Для процентного rollout особенно важен стабильный cohort key. Если сегодня используется user id, а завтра случайный request id, один пользователь будет переходить между вариантами. Это уже не gradual rollout, а непредсказуемое распределение.</p>\n<p>Evaluator возвращает выбранный вариант и, если система это поддерживает, детали оценки: key, value, variant, reason и версию конфигурации. Приложение применяет результат в одной точке. Второй слой не должен пересчитывать то же правило с другим контекстом. Иначе сервер отдаст новый ответ, а клиент решит, что пользователь относится к fallback-группе.</p>\n<p>Процент не описывает весь жизненный цикл. Он не говорит, обновился ли client cache, дошёл ли запрос до нового обработчика и можно ли откатить данные. Для каждого этапа нужны вопрос наблюдения и заранее выбранное действие. При остановке меняют одну существенную переменную: аудиторию, правило или код. Одновременная смена процента, evaluator и схемы данных уничтожает полезность сравнения.</p>\n<pre><code>type FlagDecision = {\n  key: string;\n  variant: 'fallback' | 'candidate';\n  cohortKey: string;\n  configVersion: string;\n};\n\nfunction renderCheckout(decision: FlagDecision, order: Order) {\n  if (decision.variant === 'candidate') {\n    return renderNewCheckout(order);\n  }\n\n  return renderLegacyCheckout(order);\n}</code></pre>\n<p>Этот фрагмент — учебный. Он показывает границу между результатом оценки и применением варианта. В нём нет настоящего flag provider, хранилища, телеметрии, миграции или команды rollback. В рабочей системе нужно дополнительно определить формат контекста, источник версии конфигурации, правила кеширования и поведение при ошибке evaluator.</p>\n<h2>Команды для проверки ревизии</h2>\n<p>Если candidate доставляется отдельным Kubernetes Deployment, сначала проверьте историю и состояние rollout. Эти команды требуют настроенного кластера, namespace и права чтения. Значение <code>7</code> — пример ревизии: его нужно заменить результатом первой команды.</p>\n<pre><code>kubectl rollout history deployment/checkout -n shop\nkubectl rollout status deployment/checkout -n shop --timeout=60s\n\n# Изменение состояния: выполняйте только по утверждённому stop condition\nkubectl rollout undo deployment/checkout -n shop --to-revision=7\nkubectl rollout status deployment/checkout -n shop --timeout=60s</code></pre>\n<p><code>rollout undo</code> меняет состояние Deployment, поэтому это операционная команда, а не безопасная проверка «на всякий случай». Kubernetes откатывает Pod template к выбранной ревизии; он не возвращает записи в базе, события и внешние побочные эффекты. Если команда относится только к конфигурации feature flag, применяйте аналогичный runbook вашего провайдера и сохраняйте effective version.</p>\n<h2>Учебная лестница rollout</h2>\n<table><thead><tr><th>Этап</th><th>Вопрос</th><th>Стоп-условие</th><th>Действие</th></tr></thead><tbody><tr><td>0%</td><td>Fallback выполняет согласованный smoke scenario?</td><td>Старый путь уже не работает</td><td>Не включать candidate; исправить базовый контракт</td></tr><tr><td>5%</td><td>Одна стабильная cohort получает candidate в объявленной версии?</td><td>Сигнал нарушает заранее записанную границу</td><td>Вернуть аудиторию к 0%, сохранить конфигурацию и вопрос расследования</td></tr><tr><td>25%</td><td>Candidate можно сопоставить с fallback в одном окне?</td><td>Версия или источник сигнала неизвестны</td><td>Остановить расширение и не менять правило вместе с кодом</td></tr><tr><td>100%</td><td>Вся объявленная аудитория получает выбранный вариант?</td><td>Final variant не утверждён или fallback нужен для recovery</td><td>Не удалять флаг; открыть решение о завершении</td></tr><tr><td>Cleanup gate</td><td>Код и конфигурация больше не требуют alternate branch?</td><td>Осталась runtime reference или зависимость данных</td><td>Вернуть cleanup в доработку</td></tr></tbody></table>\n<p>Значения 0, 5, 25 и 100 процентов в таблице — фиксированный учебный пример. Они не являются рекомендацией, нормативом или результатом измерения. Реальный шаг выбирают по размеру риска, качеству сигнала, обратимости и размеру cohort. Если команда не может назвать population, control, окно и владельца решения, процент не даёт полезной информации.</p>\n<figure><img src=\"/assets/editorial/2024/feature-flags-2024-cleanup-gate.svg\" alt=\"Rollout переходит к rollback и cleanup gate только после отдельного решения о финальном варианте\"><figcaption>Rollout расширяет аудиторию, rollback возвращает fallback, cleanup удаляет alternate branch. Проценты на схеме относятся к учебной модели.</figcaption></figure>\n<h2>Rollback возвращает поведение, но не переписывает историю</h2>\n<p>При stop condition минимальное действие — прекратить дальнейшее расширение candidate. Для этого возвращают аудиторию к fallback или к заранее определённому safe value. Записывают effective config version и причину остановки. Не нужно в тот же момент удалять ветки, менять evaluator и переписывать миграцию. Иначе нельзя будет понять, что именно остановило симптом.</p>\n<p>Rollback значения флага не равен rollback данных. Если candidate уже создал записи, отправил события или изменил схему ответа, старый путь должен уметь прочитать это состояние. Фича-флаг не добавляет backward compatibility автоматически. Если fallback не понимает результат candidate, ответом должен стать отдельный migration contract, а не уверенность, что <code>false</code> решает всё.</p>\n<p>Также не стоит называть rollback мгновенным. Сервис, edge-кеш и браузер могут получить конфигурацию в разное время. В карточке изменения укажите, где вычисляется вариант, сколько живёт кеш и что происходит с активной сессией. Разница версий допустима только тогда, когда она входит в контракт и не ломает recovery path.</p>\n<h2>Cleanup — отдельное решение</h2>\n<p>Cleanup начинается после выбора единственного поведения. Сначала владелец фиксирует final variant. Затем команда перестаёт добавлять новые условия и открывает отдельное изменение удаления. В его области должны быть server branches, client checks, configuration, permissions, tests, документация и миграционные заметки.</p>\n<p>Проверка cleanup строится на отрицательных утверждениях. Runtime больше не вызывает evaluator для ключа. Клиент не переключает UI по старому payload. Конфигурация не содержит targeting rules и environment overrides, нужные только флагу. Тесты проверяют итоговый business contract, а не сохранение двух boolean-веток. Документ объясняет принятое поведение, но не предлагает включить исчезнувший путь.</p>\n<p>Глобальный поиск по имени ключа полезен, но недостаточен. Ключ может быть собран из частей, сохранён в типе, скрыт в конфиге или пришит к кешу. Ищите вызовы evaluator, schema fields, token scopes, generated client types и тестовые данные. Если reference нужна для обратимой миграции, cleanup ещё не завершён: у неё должен быть owner и срок следующей проверки.</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Опишите контракт.</strong> Назовите owner, evaluator, cohort key, fallback, config version и данные, которые меняет candidate.</li><li><strong>Проверьте fallback.</strong> Выполните smoke scenario и убедитесь, что старый путь доступен до включения нового.</li><li><strong>Запишите stop condition.</strong> Свяжите её с конкретным сигналом, окном, источником и действием на остановке.</li><li><strong>Запускайте один этап.</strong> Не меняйте одновременно аудиторию, правило, код и схему данных.</li><li><strong>При проблеме остановите расширение.</strong> Верните cohort к fallback, сохраните effective config version и отделите mitigation от поиска причины.</li><li><strong>Проверьте совместимость данных.</strong> Убедитесь, что fallback читает состояние, которое оставил candidate, либо оформите отдельную миграцию.</li><li><strong>После выбора final variant заморозьте flag policy.</strong> Не добавляйте новые условия и не продлевайте флаг без новой причины.</li><li><strong>Проведите cleanup search.</strong> Проверьте server, client, config, кеши, права, тесты и документацию.</li><li><strong>Удалите артефакты отдельным change.</strong> Сохраните тест итогового поведения и обычный rollback plan для самого cleanup-релиза.</li><li><strong>Закройте решение.</strong> Зафиксируйте final variant, owner, причину удаления и evidence отсутствия runtime-зависимости.</li></ol>\n<h2>Ограничения</h2>\n<p>Этот подход не выбирает конкретный SDK, размер cohort, TTL кеша, SLO или схему миграции. OpenFeature даёт общий API для evaluation context и результата, но не задаёт правила вашей платформы; при ошибке базовой оценки клиент возвращает переданное default value. Kubernetes rollback относится к версии Deployment и его Pod template; он не доказывает обратимость бизнес-данных. Система флагов также не доказывает качество эксперимента: для этого нужны отдельные метрики, контрольная группа и методика измерения.</p>\n<p>Не следует удалять fallback только потому, что candidate получил 100 процентов. Не следует сохранять flag навсегда только потому, что когда-то существовал инцидент. Если данные, кеш или долгоживущий consumer не описаны, это блокер cleanup. Если evaluator недоступен, нужен явный default и проверяемая политика ошибки. Если неизвестно, какой вариант является итоговым, сначала принимают это решение, а потом удаляют код.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Cleanup готов, если независимая проверка отвечает «да» на все вопросы: final variant записан владельцем; fallback больше не нужен для recovery или миграции; runtime не зависит от ключа; client и server не пересчитывают старое правило; configuration и permissions не содержат флаговые остатки; тесты сохраняют итоговое поведение; обычный релизный rollback не требует возвращать удалённый flag.</p>\n<p>До этого момента выключенный флаг нужно считать остановленным, но не удалённым. Такое различие сохраняет причину, границу действия и следующий шаг. Оно также не даёт спокойному графику скрыть технический долг, который снова станет пользовательской ошибкой.</p>\n<h2>Проверяемые источники</h2>\n<p><a href=\"https://openfeature.dev/docs/reference/concepts/evaluation-context/\" target=\"_blank\" rel=\"noopener\">OpenFeature: Evaluation Context</a> — официальный материал о контексте оценки, targeting key и рисках передачи персональных данных.</p>\n<p><a href=\"https://openfeature.dev/docs/reference/concepts/evaluation-api/\" target=\"_blank\" rel=\"noopener\">OpenFeature: Evaluation API</a> — официальное описание результата оценки и его деталей.</p>\n<p><a href=\"https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/\" target=\"_blank\" rel=\"noopener\">Kubernetes: Update a Deployment Without Downtime</a> — официальная документация о проверке rollout, возврате Deployment к ревизии и ограничении rollback только Pod template.</p>"
 }
diff --git a/editorial/agent-rewrites/122.json b/editorial/agent-rewrites/122.json
index 56737ea..3d68833 100644
--- a/editorial/agent-rewrites/122.json
+++ b/editorial/agent-rewrites/122.json
@@ -3,5 +3,5 @@
   "slug": "editorial-2024-08-mechanism-feature-flags",
   "title": "Feature flags без рассинхрона: где принимать решение и что считать показом",
   "excerpt": "Как разделить серверное решение, клиентское отображение и аналитическое событие, чтобы rollout оставался объяснимым, а временная ветка действительно исчезла.",
-  "contentHtml": "<p>Новый экран включили для десяти процентов пользователей. Часть из них увидела кнопку, но API продолжил выполнять старую ветку. У другой части браузер показал новый вариант после обновления страницы, хотя сервер ещё отдавал старый. В аналитике при этом появился один общий event exposure. По нему нельзя понять, было ли решение вычислено, дошёл ли ответ до браузера и отрендерился ли экран.</p>\n<p>Цена такой ошибки растёт после первого успешного релиза. Команда тратит время на поиск слоя, который изменил вариант. В защищённый клиентский контекст могут попасть лишние сведения. Сегмент получает разные правила на соседних запросах. После эксперимента остаются две ветки кода, старый ключ конфигурации и тесты, которые поддерживают уже несуществующее решение.</p>\n<p>Feature flag — не просто boolean. Это контракт из входов, владельца решения, версии конфигурации, безопасного значения и пути удаления. Главный принцип прост: один слой владеет eligibility, а остальные получают только тот результат, который им нужен. Evaluation, render и business effect нужно считать разными фактами.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><caption>Диагностика рассинхрона feature flag</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>UI показывает новый вариант, API выполняет старый</td><td>Сервер и браузер независимо вычисляют один flag</td><td>Сравнить evaluator, targeting key и config version в одном запросе</td><td>Оставить eligibility на сервере; клиенту передавать verdict и version</td></tr><tr><td>Один пользователь меняет вариант после логина</td><td>До логина используется anonymous ID, после логина — account ID</td><td>Построить timeline ключа для одной сессии</td><td>Описать переход ключа или закрепить вариант на время сессии</td></tr><tr><td>Exposure есть, но экран не показан</td><td>Событие отправляется сразу после evaluation</td><td>Сопоставить событие с точкой рендера и ошибками UI</td><td>Разделить evaluation record и render confirmation</td></tr><tr><td>Отключение флага не меняет всех клиентов сразу</td><td>Клиент держит кэш или обновляет конфигурацию по расписанию</td><td>Проверить effective config version и границу refresh</td><td>Задать допустимое окно устаревания и fallback</td></tr></tbody></table>\n<h2>Сначала разделите входы</h2>\n<p>Оценка флага получает context. В него могут входить идентификатор субъекта, приложение, окружение, локаль и другие признаки. Не каждый такой признак можно передавать в браузер. Право доступа, индивидуальная цена, fraud signal и внутреннее состояние аккаунта должны оставаться за доверенной границей. Клиенту нужен ответ о доступности функции, а не правило, по которому сервер его получил.</p>\n<p>Публичный layout preference или локаль часто подходят для client-side решения. Это верно только тогда, когда они уже доступны клиенту и не скрывают защищённую политику. Если один flag зависит и от локали, и от права доступа, его нельзя безопасно перенести в браузер целиком. Сервер может вычислить eligibility, а клиент — выбрать разрешённое представление внутри полученного контракта.</p>\n<h2>Один authoritative evaluator</h2>\n<p>Evaluator отвечает на вопрос: какой вариант вернуть для данного flag key и context. В архитектуре должен быть один владелец этого ответа. Если сервер и браузер повторяют одно правило, они должны либо использовать один явно согласованный контракт, либо считаться независимыми решениями с отдельными названиями. Скрытая копия правила почти всегда приводит к расхождению.</p>\n<p>Пример ниже учебный. Он не подключается к provider, не читает реальную конфигурацию и не отправляет события. В нём показана граница: сервер принимает защищённый вход, возвращает уже принятое решение и версию, а клиент не переоценивает право доступа.</p>\n<pre><code>type FlagDecision = {\n  variant: 'control' | 'candidate';\n  enabled: boolean;\n  configVersion: string;\n};\n\nfunction resolveCheckoutBanner(input: {\n  accountId: string;\n  hasNewCheckoutAccess: boolean;\n}): FlagDecision {\n  return {\n    variant: input.hasNewCheckoutAccess ? 'candidate' : 'control',\n    enabled: input.hasNewCheckoutAccess,\n    configVersion: 'checkout-banner-v3',\n  };\n}\n\nconst decision = resolveCheckoutBanner({\n  accountId: 'account-42',\n  hasNewCheckoutAccess: false,\n});\n\n// Browser receives the result, not hasNewCheckoutAccess or the rule.\nrenderBanner({ enabled: decision.enabled, variant: decision.variant });</code></pre>\n<p>В реальной системе значение <code>accountId</code> не нужно отправлять в клиент только ради отображения. Поле <code>configVersion</code> помогает объяснить результат и сопоставить его с журналом. Его нельзя считать глобальным доказательством: другой сервис или кэш может работать с другой версией.</p>\n<p>Отрицательный путь важнее счастливого. Если provider недоступен, context не содержит обязательного ключа или версия конфигурации устарела сверх допустимого окна, система должна вернуть явно выбранный fallback. Не следует молча вычислять тот же flag вторым алгоритмом в браузере. Иначе отказ превращается в незаметное изменение аудитории.</p>\n<h2>Когорта начинается с targeting key</h2>\n<p>Процент rollout стабилен только относительно ключа. Сервер может распределять пользователей по account ID, а браузер — по cookie ID. Тогда один человек получит разные варианты. После входа ключ может измениться снова. Это не мелкая деталь хеширования. Это изменение субъекта, которому принадлежит решение.</p>\n<p>Зафиксируйте четыре вещи: кто является subject, когда появляется его ключ, как проходит переход anonymous → authenticated и нужно ли закреплять вариант на активную сессию. Если конфигурация меняется, решите, может ли следующий запрос пересчитать когорту. Для некоторых экранов это допустимо. Для оплаты, миграции данных или последовательного сценария может потребоваться pinning до конца операции.</p>\n<p>Не включайте персональные данные в context без необходимости. Провайдер может сериализовать или сохранять его для таргетинга. Используйте стабильный идентификатор или заранее определённый хеш, если это соответствует модели угроз и правилам хранения. Хеш сам по себе не делает данные безопасными.</p>\n<h2>Evaluation не равно exposure</h2>\n<p>Evaluation означает, что evaluator получил входы и вернул вариант или fallback. Это технический факт вычисления. Exposure candidate означает, что приложение подготовило запись о выбранном варианте. Render confirmation означает, что клиент дошёл до конкретной точки показа. Business effect означает отдельное действие пользователя или доменный результат. Эти события нельзя сливать в одно поле <code>exposure</code>.</p>\n<table><caption>Что означает запись о flag</caption><thead><tr><th scope=\"col\">Факт</th><th scope=\"col\">Минимальные поля</th><th scope=\"col\">Чего он не доказывает</th></tr></thead><tbody><tr><td>Evaluation</td><td>flag key, variant, evaluator, config version</td><td>Что UI отрендерился</td></tr><tr><td>Exposure candidate</td><td>subject boundary, variant, idempotency key</td><td>Что событие доставлено ровно один раз</td></tr><tr><td>Render confirmation</td><td>screen, display point, client timestamp</td><td>Что пользователь прочитал экран</td></tr><tr><td>Business effect</td><td>Доменное действие и его собственный contract</td><td>Что действие вызвал только flag</td></tr></tbody></table>\n<p>Слово exactly-once здесь опасно. Повторная отправка, таймаут, падение consumer и повторный запуск страницы создают разные сценарии. Если аналитике нужна дедупликация, downstream должен получить устойчивый idempotency key и окно хранения ключей. Если нужно знать факт рендера, отправляйте событие в точке рендера. Даже это не доказывает, что пользователь увидел или использовал результат.</p>\n<h2>Сервер, клиент или разделённое решение</h2>\n<p>Серверное решение подходит, когда flag зависит от защищённых данных или должно одинаково влиять на API и UI. Недостаток — сетевой путь и возможность увидеть старый результат из кэша. Его компенсируют явная версия, короткий контракт ответа и проверяемый fallback.</p>\n<p>Клиентское решение подходит для уже публичной конфигурации, например локали или разрешённой темы. Недостаток — контекст и правила становятся частью доверенной границы браузера. Нельзя использовать этот вариант для скрытого entitlement только потому, что так быстрее собрать интерфейс.</p>\n<p>Разделённое решение полезно, когда сервер отвечает за eligibility, а клиент выбирает только presentation. Например, сервер возвращает <code>candidate</code> и версию, а клиент решает, какой из двух разрешённых layout показать. Граница должна быть написана рядом с контрактом. Иначе presentation постепенно начнёт повторять policy.</p>\n<figure><img src=\"/assets/editorial/2024/feature-flags-2024-rollout-timeline.svg\" alt=\"Поток feature flag: сервер получает защищённый контекст, возвращает вариант и версию конфигурации, клиент отображает разрешённое представление и отдельно фиксирует события\" loading=\"lazy\" /><figcaption>Схема разделяет decision, render и event delivery. Она учебная: не показывает реальный трафик, задержки, размер когорты или результаты эксперимента.</figcaption></figure>\n<h2>Изменение конфигурации имеет границу свежести</h2>\n<p>Отключение flag не обязано мгновенно менять каждый клиент. Кэш, refresh interval, service worker, edge и повторная загрузка страницы создают окно устаревшего состояния. Поэтому контракт должен отвечать на вопрос: какая версия вернулась этому evaluator и сколько времени такой результат допустим.</p>\n<p>Если UI получает вариант с сервера, не заставляйте браузер заново применять скрытое targeting rule. Передавайте verdict, variant и config version. Если provider сообщает об изменении конфигурации, это событие помогает запустить refresh или диагностику, но само по себе не является бизнес-exposure. При ошибке обновления используйте заранее выбранное поведение: сохранить последний допустимый вариант, перейти на control или заблокировать опасную операцию. Выбор зависит от риска функции.</p>\n<h2>Порядок проектирования и проверки</h2>\n<ol><li><strong>Назовите изменение.</strong> Запишите старый путь, новый путь, безопасный fallback и доменную цель. Не смешивайте release flag, permission и эксперимент в одном ключе.</li><li><strong>Классифицируйте входы.</strong> Отделите protected facts от client-safe fields. Для каждого поля укажите, кто его видит и зачем он нужен.</li><li><strong>Выберите evaluator.</strong> Назначьте один слой владельцем eligibility. Второй слой может отображать результат, но не пересчитывает скрытое правило.</li><li><strong>Зафиксируйте targeting key.</strong> Опишите subject, переход логина, поведение после logout и политику активной сессии.</li><li><strong>Добавьте версию.</strong> Возвращайте effective config version вместе с решением. Сопоставляйте её с журналом и логами, не называя её глобальной версией системы.</li><li><strong>Разведите события.</strong> Отдельно назовите evaluation, exposure candidate, render confirmation и business effect. Для повторов задайте idempotency key.</li><li><strong>Проверьте отрицательный путь.</strong> Отключите provider, уберите targeting key и предъявите устаревшую конфигурацию. Убедитесь, что система выбирает ожидаемый fallback и не запускает скрытый второй evaluator.</li><li><strong>Откройте удаление.</strong> После выбора варианта удалите ветку, конфигурационный ключ, лишние тесты и документацию одной согласованной change. Продление срока должно иметь новую причину и новую дату review.</li></ol>\n<h2>Ограничения и критерий готовности</h2>\n<p>Эта модель не выбирает конкретный SDK, TTL кэша, транспорт событий или процент rollout. Она не доказывает, что provider доступен, токен клиента ограничен или эксперимент статистически значим. Актуальная документация OpenFeature описывает provider, evaluation context и provider events как части API и жизненного цикла. Она не задаёт вашей команде SLA свежести, политику персональных данных или семантику product exposure.</p>\n<p>Учебный код выше не является production-рецептом. В боевой системе отдельно проверяют авторизацию, валидацию context, обработку ошибок, наблюдаемость и совместимость версий. Не переносите строку <code>checkout-banner-v3</code> в рабочую конфигурацию без определения владельца и пути удаления.</p>\n<p>Критерий готовности проверяемый. Для одного реального flag возьмите один subject и один запрос. По логам и ответу назовите evaluator, targeting key, variant, config version и fallback. Затем покажите, где возникло evaluation, где произошёл render и как consumer обработал повтор события. Если любой ответ требует догадки или поиска правила в двух слоях, контракт ещё не готов.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://openfeature.dev/docs/reference/concepts/evaluation-context/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenFeature: Evaluation Context</a> — официальная документация описывает context, targeting key, слияние контекстов и осторожность с персональными данными. Она не задаёт универсальную политику хранения или свежести конфигурации.</li><li><a href=\"https://openfeature.dev/specification/sections/flag-evaluation/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenFeature Specification: Flag Evaluation API</a> — официальная спецификация разделяет provider и evaluation API, включая default value и resolution details. Учебная архитектура статьи добавляет командные границы поверх этого API.</li><li><a href=\"https://openfeature.dev/docs/reference/concepts/events/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenFeature: Events</a> — официальная документация описывает события готовности, ошибок и изменения состояния provider. Эти события не доказывают показ интерфейса и не дают exactly-once гарантию бизнес-события.</li></ul>"
+  "contentHtml": "<p>Новый экран включили для десяти процентов пользователей. Часть из них увидела кнопку, но API продолжил выполнять старую ветку. У другой части браузер показал новый вариант после обновления страницы, хотя сервер ещё отдавал старый. В аналитике при этом появился один общий event exposure. По нему нельзя понять, было ли решение вычислено, дошёл ли ответ до браузера и отрендерился ли экран.</p>\n<p>Такой сбой появляется, когда один флаг становится сразу тремя вещами: правилом доступа, состоянием интерфейса и событием аналитики. Браузер копирует серверное правило, кэш держит старую конфигурацию, а событие отправляется сразу после вычисления. В итоге один пользователь получает разные варианты на соседних запросах, а команда не может восстановить причину.</p>\n<p>Feature flag — это контракт из входов, владельца решения, версии конфигурации, безопасного значения и пути удаления. В статье разберём границу между evaluation, render и business effect на учебном примере. Пример не подключается к реальному провайдеру и не выдаёт его за production-код: его задача — сделать проверяемым сам механизм.</p>\n<h2>Сначала зафиксируйте симптом и границу</h2>\n<table><caption>Диагностика рассинхрона feature flag</caption><thead><tr><th scope=\"col\">Наблюдение</th><th scope=\"col\">Вероятная причина</th><th scope=\"col\">Что проверить</th><th scope=\"col\">Ограниченное действие</th></tr></thead><tbody><tr><td>UI показывает candidate, API выполняет control</td><td>Два слоя независимо оценивают один ключ</td><td>Сверить evaluator, targeting key, variant и config version в одном trace</td><td>Оставить eligibility на сервере и передавать verdict клиенту</td></tr><tr><td>Вариант меняется после входа в аккаунт</td><td>До логина используется anonymous ID, после — account ID</td><td>Построить последовательность ключей одной сессии</td><td>Описать переход или закрепить вариант на операцию</td></tr><tr><td>Есть exposure, но экран не появился</td><td>Событие отправлено на evaluation</td><td>Сопоставить событие с точкой монтирования и ошибкой рендера</td><td>Развести evaluation и render confirmation</td></tr><tr><td>Отключение флага видно не всем</td><td>Кэш, refresh interval или edge отдают старую версию</td><td>Проверить effective config version и возраст ответа</td><td>Задать допустимое окно устаревания и fallback</td></tr></tbody></table>\n<p>Первый вопрос должен звучать не «почему процент работает неправильно?», а «какой слой принял решение и какой факт мы сейчас наблюдаем?». Если ответ невозможно дать по логам и ответу API, сначала добавьте эти поля в контракт. Измерение процента без идентификатора субъекта и версии конфигурации не объясняет распределение.</p>\n<h2>Один authoritative evaluator</h2>\n<p>Evaluator — компонент, который получает ключ флага и контекст и возвращает значение. Для одного бизнес-решения назначьте одного владельца eligibility (допустимости). Сервер может принять защищённые сведения о правах, тарифе или риске. Клиент после этого выбирает только разрешённое представление. Он не должен повторно решать, имеет ли пользователь право на функцию.</p>\n<p>Это не запрещает client-side flags вообще. Клиентский evaluator подходит для публичной настройки, например выбранной темы, если правило не защищает доступ и не влияет на операцию на сервере. Для смешанного правила сервер сначала возвращает безопасный verdict, а клиент может выбрать один из вариантов presentation внутри этого verdict.</p>\n<p>В ответе полезно различать минимум четыре поля:</p>\n<table><caption>Минимальный контракт решения</caption><thead><tr><th scope=\"col\">Поле</th><th scope=\"col\">Смысл</th><th scope=\"col\">Чего поле не доказывает</th></tr></thead><tbody><tr><td><code>flagKey</code></td><td>Какое решение вычисляли</td><td>Что ключ не изменится завтра</td></tr><tr><td><code>variant</code></td><td>Какой вариант вернул evaluator</td><td>Что пользователь его увидел</td></tr><tr><td><code>configVersion</code></td><td>С какой эффективной версией работал evaluator</td><td>Что все сервисы уже используют эту версию</td></tr><tr><td><code>reason</code></td><td>Почему получено значение: targeting, split, cached, default, error и т. п.</td><td>Что провайдер поддерживает каждую причину одинаково</td></tr><tr><td><code>fallback</code></td><td>Что делать при ошибке или отсутствии обязательного контекста</td><td>Что fallback безопасен для любого домена</td></tr></tbody></table>\n<p>OpenFeature называет provider слоем, который разрешает значение, а подробный результат может содержать variant, reason, error code и metadata. Это удобный общий словарь, но не готовая политика вашей системы. Название <code>configVersion</code> в собственном API также не становится глобальной версией всех сервисов: его нужно сопоставлять с журналом публикации.</p>\n<h2>Воспроизводимый evaluator и безопасный default</h2>\n<p>Ниже — самостоятельный пример для Node.js 18 и новее. Он не зависит от SDK: детерминированно распределяет subject по 100 корзинам и возвращает подробный результат. Запустите его в shell как есть. Хеш нужен только для учебного стабильного распределения; он не заменяет защиту персональных данных и не доказывает статистическую значимость эксперимента.</p>\n<pre><code>node --input-type=module &lt;&lt;'NODE'\nimport { createHash } from 'node:crypto';\n\nconst flagKey = 'checkout-banner';\nconst configVersion = 'checkout-banner-v3';\nconst rolloutPercent = 10;\n\nfunction bucket(targetingKey) {\n  const digest = createHash('sha256')\n    .update(flagKey + ':' + targetingKey)\n    .digest();\n  return digest.readUInt32BE(0) % 100;\n}\n\nfunction evaluate({ targetingKey, providerReady }) {\n  if (!providerReady || !targetingKey) {\n    return {\n      flagKey,\n      variant: 'control',\n      reason: providerReady ? 'missing-targeting-key' : 'error',\n      configVersion,\n      fallback: true,\n    };\n  }\n\n  const inRollout = bucket(targetingKey) &lt; rolloutPercent;\n  return {\n    flagKey,\n    variant: inRollout ? 'candidate' : 'control',\n    reason: 'split',\n    configVersion,\n    fallback: false,\n  };\n}\n\nfor (const input of [\n  { targetingKey: 'user-001', providerReady: true },\n  { targetingKey: 'user-002', providerReady: true },\n  { targetingKey: '', providerReady: true },\n  { targetingKey: 'user-001', providerReady: false },\n]) {\n  console.log(JSON.stringify({ input, result: evaluate(input) }));\n}\nNODE</code></pre>\n<p>Результат содержит два важных свойства. Один и тот же ключ даёт один и тот же bucket при неизменном flag key, а отсутствие ключа или отказ provider не запускает второй алгоритм: система явно возвращает control и помечает fallback. В рабочем коде fallback выбирают по риску операции. Для декоративного баннера обычно безопасен control, для платежа или миграции данных может понадобиться блокировка операции и ручная диагностика.</p>\n<p>Не передавайте в браузер <code>hasNewCheckoutAccess</code>, внутренний fraud signal или правило вычисления только ради рендера. Браузеру достаточно результата, который разрешён для его доверенной границы. Если provider поддерживает подробную оценку, логируйте минимально нужные поля на сервере: не превращайте targeting context в копию профиля пользователя.</p>\n<h2>Targeting key определяет когорту</h2>\n<p>Процент rollout стабилен только относительно ключа субъекта. Сервер, который хеширует account ID, и браузер, который хеширует cookie ID, распределяют одного человека независимо. После логина ключ может измениться ещё раз. Это не «небольшая погрешность»: изменился субъект, которому принадлежит решение.</p>\n<p>Перед запуском запишите четыре правила: кто является subject, когда появляется targeting key, как проходит anonymous → authenticated и может ли вариант измениться в активной операции. Для чтения новостей пересчёт после логина может быть приемлем. Для оформления заказа, миграции или многошаговой формы вариант часто фиксируют до завершения операции.</p>\n<p>OpenFeature описывает targeting key как строковый идентификатор субъекта и предупреждает, что провайдеры могут требовать его для дробного распределения или адресных правил. Там же есть отдельное предупреждение о персональных данных в evaluation context: провайдер может сериализовать или сохранять контекст. Поэтому используйте устойчивый технический идентификатор или согласованный хеш только после проверки модели угроз и политики хранения. Хеш сам по себе не делает значение анонимным.</p>\n<figure><img src=\"/assets/editorial/2024/feature-flags-2024-rollout-timeline.svg\" alt=\"Поток feature flag: сервер принимает защищённый контекст и targeting key, возвращает variant и configVersion, клиент отображает разрешённый вариант, затем отдельно фиксируются render и бизнес-событие\" loading=\"lazy\" /><figcaption>Схема отделяет решение, рендер и доставку событий. Она учебная: не показывает конкретный SDK, реальный трафик, задержки, размер когорты или результаты эксперимента.</figcaption></figure>\n<h2>Evaluation не равно показ</h2>\n<p>Evaluation означает, что система получила входы и вернула значение. Это ещё не exposure. Если сервер оценил флаг, но запрос завершился ошибкой, экран не показан. Если клиент получил HTML, но компонент не смонтировался, показ также не доказан. Даже подтверждённый рендер не говорит, что человек прочитал или использовал экран.</p>\n<p>Разделите жизненный цикл на четыре факта:</p>\n<ol><li><strong>Evaluation.</strong> Запишите flag key, variant, evaluator, config version и reason. Это ответ на вопрос «какое решение вернулось?».</li><li><strong>Render confirmation.</strong> Отправляйте его из точки, где компонент действительно смонтирован или стал видимым по выбранному критерию. Поле screen должно называть конкретную точку показа.</li><li><strong>Business effect.</strong> Отдельно фиксируйте клик, отправку формы или доменный результат. Событие не должно называться exposure, если оно описывает действие.</li><li><strong>Correlation.</strong> Свяжите записи request ID, subject boundary и безопасным variant. Для повтора доставки используйте idempotency key, но не обещайте exactly-once там, где транспорт даёт at-least-once или не даёт гарантии доставки.</li></ol>\n<p>OpenFeature предоставляет tracking API для связывания последующего действия или состояния приложения с контекстом оценки. Это помогает анализировать влияние флага, но tracking-вызов не превращается автоматически в доказательство рендера. Семантику «виден пользователю» задаёт ваше приложение и его критерий видимости.</p>\n<h2>Кэш и версия: задайте окно устаревания</h2>\n<p>Отключение флага не обязано мгновенно менять каждый процесс. Старое состояние может жить в памяти SDK, edge-кэше, service worker или ответе HTTP. Поэтому для каждого флага задайте допустимое окно stale: сколько времени старый verdict приемлем и что происходит после его истечения.</p>\n<p>В HTTP кэш не должен отдавать stale-ответ без разрешения протокола или явного контракта. Но из этого не следует, что бизнес-флаг обновится мгновенно: ваши refresh interval, локальный кэш и аварийный режим всё равно требуют проектного решения. Возвращайте effective config version, а при диагностике сохраняйте возраст значения и источник кэша.</p>\n<p>При сигнале изменения конфигурации можно запустить refresh или мониторинг. OpenFeature перечисляет provider events, включая configuration changed, error и stale. Эти события говорят о состоянии provider, а не о том, что конкретный пользователь увидел новый экран. При ошибке обновления заранее выберите одно из действий: сохранить последний допустимый вариант на короткое окно, перейти в control или остановить рискованную операцию.</p>\n<pre><code># Пример ручной проверки контракта локального сервиса.\n# Ожидайте в JSON flagKey, variant, configVersion, reason и fallback.\nset -eu\ncurl --fail-with-body --silent --show-error \\\n  -H 'X-Debug-Subject: user-001' \\\n  'http://localhost:3000/api/flags/checkout-banner' \\\n  | jq '{flagKey, variant, configVersion, reason, fallback}'</code></pre>\n<p>Команда не предполагает конкретный продуктовый endpoint: URL и заголовок должны существовать в вашем сервисе. Она показывает воспроизводимый минимум ручной проверки. Для двух последовательных запросов одного subject сравните variant и configVersion; затем выключите provider и проверьте, что response явно перешёл в выбранный fallback.</p>\n<h2>Как проверить отрицательные пути</h2>\n<p>Счастливый путь доказывает только то, что candidate когда-то вернулся. Надёжность видна на отказах. Тестируйте не только процент, но и владельца решения, отсутствие контекста, смену версии и повторную доставку события.</p>\n<ol><li>Зафиксируйте один тестовый targeting key и получите evaluation details. В журнале должны совпасть flag key, variant, reason и config version.</li><li>Уберите targeting key. Проверьте, что система не выбирает случайный cookie и не оценивает тот же policy в браузере.</li><li>Сделайте provider недоступным. Проверьте безопасный default, error code или reason и отсутствие необработанного исключения в пользовательском запросе.</li><li>Измените конфигурацию. Убедитесь, что refresh меняет version в пределах согласованного окна, а старый ответ не выдаётся дольше разрешённого срока.</li><li>Смонтируйте компонент с ошибкой и сравните telemetry. Evaluation может существовать, а render confirmation — отсутствовать; это разные результаты, а не потерянное поле.</li><li>Повторите отправку одного business event. Проверьте дедупликацию downstream по idempotency key и отдельно измерьте потери доставки.</li><li>После завершения rollout удалите ветку, ключ, лишние тесты и документацию. Оставшийся flag без срока пересмотра быстро превращается в постоянную сложность.</li></ol>\n<h2>Ограничения и критерий готовности</h2>\n<p>Эта модель не выбирает SDK, транспорт аналитики, TTL, процент rollout или способ статистической проверки эксперимента. OpenFeature — vendor-neutral API: его provider может получать данные из разных источников, а конкретная гарантия свежести, хранения контекста и доставки tracking зависит от реализации. RFC 9111 описывает HTTP-кэширование, но не задаёт вашей бизнес-семантике безопасный fallback.</p>\n<p>Учебный SHA-256 evaluator не является доказательством равномерного эксперимента: он показывает детерминированную корзину, но не проверяет качество выборки, SRM, мощность теста или причинность метрики. Не используйте этот фрагмент как замену провайдеру с управлением конфигурацией. Не считайте <code>render confirmation</code> доказательством внимания пользователя и не называйте доставку exactly-once без подтверждённой семантики транспорта.</p>\n<p>Flag готов к rollout, если для одного реального subject команда может без догадок назвать evaluator, targeting key, variant, config version, reason и fallback; показать точку render; воспроизвести отказ provider; увидеть границу stale; связать бизнес-эффект с evaluation. Если правило приходится искать одновременно в сервере, браузере и конфигурационном файле, сначала сократите число владельцев.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://openfeature.dev/specification/sections/evaluation-context/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenFeature Specification: Evaluation Context</a> — требования к targeting key, пользовательским полям контекста и объединению контекстов.</li><li><a href=\"https://openfeature.dev/specification/sections/flag-evaluation/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenFeature Specification: Flag Evaluation API</a> — typed evaluation, default value и evaluation details с variant, reason и error information.</li><li><a href=\"https://openfeature.dev/specification/sections/events/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenFeature Specification: Events</a> — события готовности, ошибки, изменения конфигурации и stale-состояния provider.</li><li><a href=\"https://openfeature.dev/specification/sections/tracking/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenFeature Specification: Tracking</a> — API для связывания последующего действия или состояния приложения с evaluation context.</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc9111.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9111: HTTP Caching</a> — нормативные правила свежести и выдачи stale-ответов кэшем.</li></ul>"
 }
diff --git a/editorial/agent-rewrites/123.json b/editorial/agent-rewrites/123.json
index 2e7f112..0a278b0 100644
--- a/editorial/agent-rewrites/123.json
+++ b/editorial/agent-rewrites/123.json
@@ -3,5 +3,5 @@
   "slug": "editorial-2024-08-practice-feature-flags",
   "title": "Фича-флаг как контракт выпуска: включить, проверить, удалить",
   "excerpt": "Release-флаг снижает риск только тогда, когда у него есть ограниченная аудитория, безопасный fallback, владелец, срок пересмотра и заранее описанное удаление.",
-  "contentHtml": "<p>В пятницу новый checkout включают для пяти процентов пользователей. В понедельник команда видит ошибки только на части запросов и выключает флаг. Но старый и новый код остаются в репозитории, тесты продолжают покрывать два пути, а конфигурация живёт без владельца. Через месяц никто не знает, можно ли удалить условие: новый путь мог записать данные в другом формате, а клиент мог закешировать старый вариант.</p>\n<p>Цена такой ошибки растёт не вместе с процентом rollout. Она растёт с каждым новым условием, исключением и сервисом, который читает тот же ключ. Выключенный флаг уменьшает аудиторию, но не убирает ветки, не возвращает изменённые данные и не объясняет, почему система выбрала вариант. Тезис статьи простой: release-флаг — это временный контракт выпуска. Он должен описывать границу решения, безопасное значение, наблюдение и момент, когда код исчезнет.</p>\n<h2>Механизм: boolean скрывает решение</h2>\n<p>Значение <code>true</code> или <code>false</code> отвечает только на один вопрос: какой путь выбрать сейчас. Выпуск требует ответов на другие вопросы. Для кого действует правило? Где его вычисляют? Что произойдёт при ошибке провайдера или устаревшей конфигурации? Кто остановит rollout? Как проверить новый путь? Что удалить после выбора варианта?</p>\n<p>Удобно разделить флаг на пять частей. <strong>Owner</strong> принимает решение на review. <strong>Audience</strong> задаёт стабильную когорту и окружение. <strong>Fallback</strong> определяет путь при недоступном или сомнительном решении. <strong>Signals</strong> показывают, что именно произошло. <strong>Cleanup</strong> связывает итоговый вариант с удалением условий, настроек и тестовых исключений.</p>\n<p>Эти части не заменяют flag management system. Они задают контракт вокруг неё. Провайдер может вернуть default value, сообщить об ошибке или показать, что его состояние устарело. Приложение всё равно должно решить, какое значение безопасно для конкретной операции. Для цены, права доступа и другого защищённого решения fallback выбирает сервер. Клиент получает уже вычисленный результат, а не правило с закрытым контекстом.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>«Временный» флаг появляется без даты удаления</td><td>Boolean приняли за весь контракт выпуска</td><td>Найдите owner, review date и список веток</td><td>Оформите карточку и назначьте review до rollout</td></tr><tr><td>После выключения ошибки исчезли, но код не меняется</td><td>Disablement перепутали с cleanup</td><td>Сравните ветки, config keys, тесты и формат записанных данных</td><td>Откройте отдельное удаление и оставьте fallback до его завершения</td></tr><tr><td>Один пользователь видит разные варианты</td><td>Сервисы используют разные targeting keys или версии конфигурации</td><td>Запишите key, effective version и границу сессии в evaluation details</td><td>Назначьте один authoritative evaluator или явно опишите split decision</td></tr><tr><td>Событие exposure есть, а интерфейс не показался</td><td>Evaluation назвали эффектом</td><td>Разделите evaluation, response, render и user action</td><td>Переименуйте сигнал и не делайте вывод о результате по одной записи</td></tr><tr><td>Провайдер недоступен</td><td>Fallback не определён для ошибки или stale state</td><td>Воспроизведите provider error в изолированной проверке</td><td>Верните объявленный safe value и поднимите сигнал оператору</td></tr></tbody></table>\n<h2>Карточка до первой строки кода</h2>\n<p>Сначала сформулируйте один вопрос выпуска. «Включить новый checkout» слишком широко. Лучше: «Показать новую форму checkout синтетической внутренней когорте, оставив прежнюю форму доступной при любом сбое оценки». Такая формулировка задаёт аудиторию, вариант и отрицательный путь.</p>\n<pre><code>const releaseFlagCard = {\n  key: 'synthetic-checkout-copy-v1',\n  class: 'release',\n  owner: 'synthetic-checkout-owner',\n  audience: 'synthetic-internal-beta-cohort',\n  targetingKey: 'synthetic-subject-id',\n  fallback: 'existing-checkout-copy',\n  reviewAt: 'synthetic-2026-09-30',\n  signals: ['evaluation-outcome', 'client-render-error'],\n  cleanup: ['freeze-variant', 'remove-branches', 'remove-config'],\n};\n\n// Учебная запись. Она не создаёт флаг, не читает provider\n// и не отправляет telemetry или данные пользователя.</code></pre>\n<p>В примере все значения synthetic. Дата не запускает таймер, ключ не определяет настоящую когорту, а массив cleanup не удаляет файлы. Он показывает форму review. В реальной системе карточка должна ссылаться на конкретные владельца, окружение, конфигурацию и проверку, но не должна содержать секреты.</p>\n<h2>Где принимать решение</h2>\n<p>Сервер должен владеть решением, если оно зависит от entitlement, цены, account state, fraud signal или другого защищённого входа. Сервер возвращает клиенту presentation value и, при необходимости, effective configuration version. Браузер не должен повторять правило по урезанному контексту: такое дублирование создаёт два источника истины.</p>\n<p>Клиент может вычислять presentation-флаг, если все входы уже публичны: например, доступная локаль, опубликованный вариант оформления или локальная настройка layout. Это сокращает сетевой путь, но не отменяет проверку token, CORS, cache и refresh semantics конкретного провайдера.</p>\n<p>Разделяйте evaluation и exposure. Evaluation означает, что evaluator вернул вариант для заданного контекста. Exposure можно использовать для записи попытки показать вариант, но запись не доказывает успешный render, пользовательское действие или бизнес-эффект. Если событие доставляется повторно или теряется, это нужно учитывать в consumer и в выводах из метрик.</p>\n<figure><img src=\"/assets/editorial/2024/feature-flags-2024-decision-tree.svg\" alt=\"Дерево решения release-флага: проверка владельца, аудитории, fallback и срока review перед включением; затем выбор границы решения и cleanup\" loading=\"lazy\" /><figcaption>Сначала проверяется контракт, затем выбирается граница решения. Схема учебная: она не показывает состояние реального flag-сервиса, rollout или production-метрики.</figcaption></figure>\n<h2>Порядок внедрения</h2>\n<ol><li><strong>Назовите старый и новый путь.</strong> Запишите, какая функция меняется, что остаётся fallback и какие данные каждый путь читает или записывает.</li><li><strong>Выберите класс флага.</strong> Не смешивайте release, эксперимент, миграцию данных и постоянную policy в одном ключе. Для каждого класса нужны разные сроки и проверки.</li><li><strong>Назначьте owner и review date.</strong> Owner должен выбрать итоговый вариант, продлить контракт с причиной или начать cleanup. Продление без новой причины не является нейтральным действием.</li><li><strong>Опишите audience boundary.</strong> Зафиксируйте environment, targeting key, способ удержания когорты и данные, которые не покидают сервер. Проверьте поведение после логина, смены сессии и обновления конфигурации.</li><li><strong>Определите fallback и отрицательный путь.</strong> Проверьте default value, provider error, stale state, таймаут и недоступность сети. Убедитесь, что возврат не скрывает несовместимые данные.</li><li><strong>Назовите сигналы и их пределы.</strong> Разделите evaluation result, render error, API failure и user action. Для каждого напишите, какой вывод он разрешает и какой запрещает.</li><li><strong>Расширяйте аудиторию постепенно.</strong> На каждом шаге проверяйте ошибку, latency, целостность ответа и работу старой ветки. Если сигнал нарушает stop condition, верните объявленный fallback и зафиксируйте причину.</li><li><strong>Зафиксируйте выбранный вариант.</strong> После решения не добавляйте новые rules в старый release-флаг. Создайте cleanup change для кода, конфигурации, тестов, документации и лишних сигналов.</li></ol>\n<h2>Как проверить удаление</h2>\n<p>Выключение и удаление проходят разными проверками. После выключения убедитесь, что новый путь не получает аудиторию и старый путь отвечает за заявленный контракт. Затем проверьте, не остались ли записи нового формата, client cache, server cache, отдельные разрешения и тестовые обходы. Только после этого удаляйте ветки. Иначе «cleanup» может убрать защитное условие раньше, чем система перестанет читать его последствия.</p>\n<p>Простой критерий для pull request: поиск по ключу флага не находит production-условий после удаления, тесты больше не выбирают вариант через старую конфигурацию, а единственный оставшийся путь не зависит от временного default. Если данные менялись, добавьте отдельную проверку совместимости. Не объявляйте cleanup завершённым по одному зелёному unit-тесту.</p>\n<h2>Ограничения</h2>\n<p>Карточка не выбирает безопасный процент rollout и не заменяет threat model, approval, миграцию схемы, SLA или план отката данных. OpenFeature задаёт API evaluation context, targeting key, providers и provider events, но не навязывает поля owner, reviewAt или cleanup. Эти поля — локальная инженерная policy.</p>\n<p>Разные провайдеры по-разному обновляют конфигурацию, кэшируют правила и обрабатывают ошибки. Нельзя переносить интервал refresh или семантику токена одного SDK в другой без проверки его документации. Нельзя считать targeting key доказательством единой когорты во всех сервисах, если они не используют общую версию конфигурации и один authoritative evaluator.</p>\n<p>Учебный объект выше не является результатом production-эксперимента. Он не доказывает latency, delivery rate, безопасность данных или полезный эффект новой формы. Production-вывод требует реальных наблюдений, определённого окна измерения и заранее согласованного stop condition.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://openfeature.dev/specification/sections/evaluation-context/\" target=\"_blank\" rel=\"noopener\">OpenFeature Specification: Evaluation Context</a> — targeting key и контекст для оценки, включая замечания о персональных данных.</li><li><a href=\"https://openfeature.dev/specification/sections/providers/\" target=\"_blank\" rel=\"noopener\">OpenFeature Specification: Providers</a> — контракт провайдера, default value и resolution details.</li><li><a href=\"https://openfeature.dev/specification/sections/events/\" target=\"_blank\" rel=\"noopener\">OpenFeature Specification: Events</a> — готовность, ошибка, изменение конфигурации и stale state.</li></ul>\n<h2>Проверяемая готовность</h2>\n<p>Флаг готов к включению, если другой инженер без устного контекста может назвать его вопрос, owner, audience boundary, authoritative evaluator, safe fallback, signals, stop condition и review date. Флаг готов к удалению, если выбран вариант зафиксирован, поиск не находит временных веток, тесты не зависят от старого ключа, а изменения данных проверены отдельно. Если хотя бы один ответ отсутствует, это не повод добавить ещё один boolean. Это сигнал вернуть контракт на review.</p>"
+  "contentHtml": "<p>Проблема с фича-флагом обычно проявляется не в момент включения. В пятницу новую форму checkout включают для небольшой когорты, а в понедельник после ошибки возвращают старую. Ошибка исчезает, но в репозитории остаются две ветки, конфигурация живёт без владельца, а часть пользователей могла сохранить данные нового формата.</p>\n<p>Выключенный флаг уменьшает аудиторию, но не удаляет код и не откатывает побочные эффекты. Поэтому release-флаг нужно рассматривать как временный контракт выпуска: он отвечает на вопрос, кто получает новый путь, какое значение безопасно при сбое, какие сигналы останавливают rollout и когда исчезнут условие, настройка и лишние тесты.</p>\n<h2>Какая задача решается</h2>\n<p>Фича-флаг отделяет доставку кода от выбора поведения во время работы программы. Команда может выложить совместимый код, проверить его на внутренней когорте и только потом расширять аудиторию. Это полезно для релиза, но само по себе не делает новую функцию безопасной: флаг не заменяет миграцию данных, контроль прав, обратную совместимость или план отката.</p>\n<p>До первой строки кода зафиксируйте один вопрос. Формулировка «включить новый checkout» слишком широкая. Проверяемый вариант звучит так: «Показать новую форму внутренней когорте, а при ошибке оценки или рендера оставить прежнюю форму». В такой фразе уже видны субъект, граница решения и отрицательный путь.</p>\n<table><thead><tr><th>Часть контракта</th><th>Что зафиксировать</th><th>Как проверить</th></tr></thead><tbody><tr><td>Вопрос</td><td>Какое поведение меняется и для кого</td><td>Другой инженер пересказывает условие одним предложением</td></tr><tr><td>Владелец</td><td>Кто остановит rollout и примет итоговый вариант</td><td>Имя или команда указаны в карточке изменения</td></tr><tr><td>Аудитория</td><td>Окружение, targeting key и способ удержания когорты</td><td>Один субъект получает ожидаемый вариант повторно</td></tr><tr><td>Fallback</td><td>Путь при ошибке, таймауте и устаревшем состоянии</td><td>Сбой провайдера воспроизведён в изолированной проверке</td></tr><tr><td>Удаление</td><td>Код, настройка, тесты и сигналы, которые исчезнут</td><td>После cleanup поиск по ключу не находит рабочих веток</td></tr></tbody></table>\n<h2>Что именно возвращает провайдер</h2>\n<p>Boolean скрывает причину выбора. В стандарте OpenFeature провайдер разрешает типизированное значение по ключу, default value и контексту оценки, а результат может содержать причину, вариант, метаданные и код ошибки. Приложение должно сохранить эту информацию там, где она нужна для диагностики, но не выводить в логи персональные поля из контекста.</p>\n<p>Контекст оценки содержит сведения, по которым выбирается вариант. В нём есть необязательный <code>targetingKey</code> — строковый идентификатор субъекта. Он может быть идентификатором пользователя, сервиса или тестового субъекта. Если провайдер использует процентное распределение или адресные правила, отсутствие ключа может сделать результат непредсказуемым. Это свойство провайдера, а не гарантия всех систем фича-флагов.</p>\n<p>Условие применимости здесь важнее названия библиотеки. OpenFeature описывает API и жизненный цикл интеграции, но не назначает владельца, срок удаления, процент rollout или безопасный fallback для бизнеса. Эти поля нужно определить в своей change-карточке и проверить средствами конкретного SDK.</p>\n<pre><code>const flagCard = {&#10;  key: 'checkout-form-v2',&#10;  kind: 'release',&#10;  owner: 'checkout-team',&#10;  environment: 'staging',&#10;  targetingKey: 'test-subject-001',&#10;  defaultValue: false,&#10;  fallbackPath: 'checkout-form-v1',&#10;  stopConditions: ['5xx increase', 'render error', 'latency budget'],&#10;  reviewAfter: '2024-08-30',&#10;  cleanup: ['remove-branch', 'remove-config', 'keep-regression-test'],&#10;};&#10;&#10;if (flagCard.defaultValue !== false || !flagCard.cleanup.length) process.exit(1);&#10;console.log(flagCard.key);</code></pre>\n<p>Сохраните фрагмент в файл <code>flag-card.mjs</code>, затем выполните <code>node flag-card.mjs</code>. Команда проверит, что fallback по умолчанию выключен и список удаления не пуст. Файл не обращается к настоящему провайдеру и не отправляет телеметрию. Поля <code>owner</code>, <code>reviewAfter</code> и <code>cleanup</code> — локальная политика команды, а не часть обязательного API OpenFeature.</p>\n<p>Для рабочего проекта добавьте к такой проверке схему данных и проверку запрещённых значений. Секреты, email и необезличенные атрибуты не должны попадать в карточку или в контекст оценки без отдельного решения о хранении и доступе.</p>\n<h2>Где вычислять решение</h2>\n<p>Решение, зависящее от тарифа, права доступа, состояния счёта, fraud-сигнала или другого защищённого входа, вычисляйте на сервере. Клиент должен получить уже разрешённый presentation value и обработать его как вход, а не повторять правило по урезанному контексту. Иначе сервер и браузер могут выбрать разные варианты.</p>\n<p>Клиентская оценка подходит для публичного оформления, локали или другого решения, для которого все входы уже открыты и потеря точности не меняет права пользователя. Даже в этом случае проверьте семантику кэша, обновления и отсутствие чувствительных данных в evaluation context. Название «client-side» не означает, что конфигурация автоматически безопасна.</p>\n<figure><img src='/assets/editorial/2024/feature-flags-2024-decision-tree.svg' alt='Дерево решения release-флага: от симптома и проверки карточки через границу серверного или клиентского решения к наблюдению и удалению временной ветки' loading='lazy' /><figcaption>Сначала фиксируются владелец, аудитория и fallback, затем выбирается граница оценки. Диаграмма показывает порядок review, а не состояние конкретного сервиса и не обещает результат rollout.</figcaption></figure>\n<h2>Evaluation, exposure и результат — разные события</h2>\n<p>Evaluation означает, что evaluator вернул значение для контекста. Это ещё не показ интерфейса. Между оценкой и результатом могут произойти ошибка API, отказ рендера, закрытие страницы или повторная доставка события.</p>\n<p>Разделите минимум четыре сигнала:</p>\n<ol><li><strong>evaluation.</strong> Запишите ключ флага, вариант или причину, версию конфигурации, окружение и обезличенный идентификатор когорты;</li><li><strong>response.</strong> Проверьте, что сервер вернул допустимый ответ и не скрыл ошибку под успешным HTTP-статусом;</li><li><strong>render.</strong> Зафиксируйте, что выбранный компонент действительно построился без ошибки;</li><li><strong>action.</strong> Отдельно измеряйте действие пользователя или бизнес-результат, если он нужен для решения.</li></ol>\n<p>События провайдера полезны для состояния самого источника: OpenFeature описывает готовность, ошибку, изменение конфигурации и устаревшее состояние. Событие <code>PROVIDER_STALE</code> говорит о свежести кэша, но не доказывает exposure. Аналогично, событие evaluation не доказывает успешный render. В каждом дашборде укажите, какой вывод разрешает сигнал и какой вывод из него делать нельзя.</p>\n<h2>Порядок безопасного rollout</h2>\n<p>Rollout — это последовательность проверяемых шагов, а не одно изменение процента. Сначала убедитесь, что старый путь по-прежнему поддерживается и что оба пути согласованы с форматом данных. Затем расширяйте аудиторию только при выполнении заранее заданных stop conditions.</p>\n<ol><li><strong>Назовите старый и новый путь.</strong> Перечислите чтения, записи, побочные эффекты и совместимость форматов.</li><li><strong>Выберите тип флага.</strong> Не смешивайте release, эксперимент, миграцию данных и постоянную policy в одном ключе: у них разные сроки и критерии успеха.</li><li><strong>Закрепите субъекта.</strong> Используйте стабильный targeting key и проверьте повторную оценку после новой сессии, логина и смены окружения.</li><li><strong>Определите fallback.</strong> Отдельно проверьте default value, ошибку провайдера, таймаут, stale state и частично обновлённую конфигурацию.</li><li><strong>Проведите малый шаг.</strong> Сравните error rate, latency, целостность ответа и ошибки старой ветки с базовым окном. Не приписывайте разницу флагу без одинаковой границы измерения.</li><li><strong>Остановите rollout при нарушении условия.</strong> Верните объявленный fallback, запишите причину и сохраните effective version, чтобы повторить диагностику.</li><li><strong>Зафиксируйте итог.</strong> После выбора варианта заморозьте правило и откройте отдельное изменение cleanup.</li></ol>\n<p>Вариант «внутренняя когорта» не означает автоматически безопасный вариант. Проверьте, что в неё не попадают реальные клиенты, что персональные данные не используются как необязательный targeting input и что оператор может быстро вернуть старое поведение.</p>\n<h2>Отключение не равно удалению</h2>\n<p>После disablement новая аудитория перестаёт получать ветку, но зависимость от флага остаётся. Перед удалением проверьте три слоя: код, конфигурацию и данные. В коде ищите ключ, условные ветки, адаптеры и тестовые обходы. В конфигурации — правила, значения по умолчанию, окружения, кэш и разрешения. В данных — записи нового формата, фоновые задания и потребителей, которые ещё могут их читать.</p>\n<pre><code>rg -n --hidden --glob '!node_modules' 'checkout-form-v2' src test config&#10;rg -n --hidden --glob '!node_modules' 'checkout-form-v1|checkout-form-v2' src test config&#10;git diff --check&#10;pnpm test --filter checkout</code></pre>\n<p>Команды предполагают Unix-подобную оболочку, установленный <code>rg</code>, рабочий скрипт тестов и каталог <code>src</code>. Подставьте имена своего репозитория. Первый поиск показывает остатки ключа, второй помогает найти обе ветки до удаления. Если новая ветка записывала данные, добавьте проверку чтения старого и нового формата; одного поиска и зелёного unit-теста недостаточно.</p>\n<p>Надёжный cleanup оставляет тест поведения выбранного варианта, но удаляет временную развилку и её настройку. Отдельно обновите runbook и мониторинг. Если поиск всё ещё находит production-условие по ключу, удаление не закончено.</p>\n<h2>Ограничения применимости</h2>\n<p>Эта схема рассчитана на release-флаг с обратным выбором поведения. Она не описывает полноценный эксперимент: для него нужны рандомизация, заранее выбранная метрика, длительность окна и статистический план. Она также не является планом отката базы данных и не решает проблему несовместимой схемы.</p>\n<p>Интервалы обновления, поведение при сетевой ошибке, кэш и формат resolution details зависят от провайдера и SDK. Нельзя переносить настройки одного продукта в другой по названию поля. Для OpenFeature гарантии относятся к контракту API; owner, review date, stop condition, redaction и cleanup команда должна определить и протестировать самостоятельно.</p>\n<p>Не передавайте в контекст оценки больше данных, чем нужно правилу. Официальная документация OpenFeature отдельно предупреждает о том, что провайдер может сериализовать или сохранять контекст. Используйте стабильный обезличенный ключ, когда провайдер и требования к аудиту это допускают, и проверьте политику хранения у выбранного сервиса.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href='https://openfeature.dev/specification/sections/evaluation-context/' target='_blank' rel='noopener'>OpenFeature Specification: Evaluation Context</a> — targeting key, пользовательский контекст и порядок объединения контекстов.</li><li><a href='https://openfeature.dev/specification/sections/providers/' target='_blank' rel='noopener'>OpenFeature Specification: Provider</a> — default value, типизированная оценка, resolution details и ошибки провайдера.</li><li><a href='https://openfeature.dev/specification/sections/events/' target='_blank' rel='noopener'>OpenFeature Specification: Events</a> — состояния READY, ERROR, CONFIGURATION_CHANGED и STALE.</li><li><a href='https://openfeature.dev/specification/appendix-d/' target='_blank' rel='noopener'>OpenFeature Specification: Observability</a> — поля результата оценки и границы телеметрии.</li></ul>\n<h2>Критерий готовности</h2>\n<p>Флаг готов к включению, если инженер может без устного контекста назвать вопрос, старый и новый путь, owner, аудиторию, targeting key, серверную или клиентскую границу, fallback, stop conditions, сигналы и дату review. Флаг готов к удалению, если выбранный вариант зафиксирован, совместимость данных проверена, поиск не находит временных веток, а тесты больше не зависят от старого ключа.</p>\n<p>Если не известен хотя бы один из этих ответов, добавление ещё одного boolean не уменьшит риск. Сначала верните изменение на review и заполните контракт.</p>"
 }
diff --git a/editorial/agent-rewrites/124.json b/editorial/agent-rewrites/124.json
index 7a7de62..f2c7425 100644
--- a/editorial/agent-rewrites/124.json
+++ b/editorial/agent-rewrites/124.json
@@ -2,6 +2,6 @@
   "index": 124,
   "slug": "editorial-2024-07-field-release-engineering",
   "title": "Когда версия не доказывает релиз: проверка artifact, migration и rollback",
-  "excerpt": "Один номер релиза может скрывать разные commit, artifact и migration. Разбираем, где остановиться, какие связи проверить и почему возврат образа не отменяет изменения данных.",
-  "contentHtml": "<p>В заявке на выпуск стоит <code>2024.07.0</code>. Такой же номер виден у commit, container image, migration и rollout. После выкладки сервис отвечает кодом старой схемы: новый код ждёт поле, которого в базе нет. Команда повторяет deploy, потому что все карточки выглядят согласованными. Ошибка становится дороже с каждой попыткой: растёт окно недоступности, меняется состояние данных, а точку возврата уже трудно назвать.</p>\n<p>Проблема не в самом номере версии. Проблема в том, что номер заменил связи между объектами. Он не доказывает, что artifact собран из нужного commit, что migration рассчитана на этот contract и что rollout ссылается на тот же digest. Выпуск готов только тогда, когда эти связи можно проверить по точным значениям, а отрицательный результат останавливает действие.</p>\n<h2>Где рвётся цепочка</h2>\n<p>Commit описывает исходный revision. Artifact содержит собранное содержимое и immutable digest. Migration меняет схему или данные и должна назвать целевую версию и совместимость. Rollout intent говорит, какой digest команда собирается отправить. Return point хранит предыдущую версию и digest. Эти записи связаны, но не заменяют друг друга.</p>\n<p>У каждой связи есть проверяемое утверждение. Artifact должен ссылаться на exact commit id. Migration должна называть release version и совместимость с текущей схемой. Rollout должен содержать digest из artifact, а не только tag. Return point должен быть известен до approval. Если одно утверждение ложно или неизвестно, действие заканчивается на gate. Retry не исправляет неправильную запись.</p>\n<figure><img src=\"/assets/editorial/2024/release-engineering-2024-evidence-gate.svg\" alt=\"Схема проверки связей между commit, artifact, migration, rollout и точкой возврата\" loading=\"lazy\" /><figcaption>Учебная схема показывает порядок сверки. Она не является логом CI, registry, кластера или production rollout.</figcaption></figure>\n<h2>Минимальный пример</h2>\n<p>Ниже — ограниченный учебный пример. Значения вымышлены. Код не обращается к Git, registry, CI, Kubernetes API или базе данных. Он только сравнивает заранее заданные записи и возвращает решение для проверки человеком.</p>\n<pre><code>const release={version:'2024.07.0'},commit={id:'commit-7f4a0c1'},artifact={digest:'sha256:release-070-a1',sourceCommitId:'commit-7f4a0c1'},migration={targetReleaseVersion:'2024.07.0',compatibleWith:'2024.06.3'},rollout={requestedArtifactDigest:'sha256:release-070-a1',migrationVersion:'2024.07.0'}; const checks={source:artifact.sourceCommitId===commit.id,migration:migration.targetReleaseVersion===release.version,artifact:rollout.requestedArtifactDigest===artifact.digest,rollout:rollout.migrationVersion===migration.targetReleaseVersion}; const ready=Object.values(checks).every(Boolean); if(!ready) throw new Error('stop: reconcile release records');</code></pre>\n<p>При <code>ready === true</code> пример говорит только о согласованности пяти записей. Он не говорит, что образ существует, подпись действительна, migration выполнена или сервис здоров. Если заменить <code>sourceCommitId</code> на другой id, результат должен стать отрицательным. То же относится к digest и target version. Это и есть полезный отрицательный путь: система не угадывает, какую запись считать правильной.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика расхождений до запуска</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Номер версии совпадает, но artifact указывает на другой commit.</td><td>Tag используют вместо точной связи с исходным revision.</td><td>Сравнить <code>artifact.sourceCommitId</code> и commit id.</td><td>Остановить выпуск. Исправить запись или пересобрать artifact после решения владельца.</td></tr><tr><td>Код можно вернуть, но схема базы уже изменилась.</td><td>Rollback binary ошибочно считают rollback данных.</td><td>Проверить migration target, compatibility и обратную процедуру.</td><td>Вернуть только явно разрешённый artifact; вопрос данных передать отдельному владельцу.</td></tr><tr><td>Rollout прошёл с тем же tag, но другим digest.</td><td>Intent ссылается на mutable label, а не на immutable content.</td><td>Сравнить requested digest с digest artifact.</td><td>Не запускать rollout. Пересоздать intent после сверки.</td></tr><tr><td>После stop команда предлагает повторить deploy.</td><td>Retry используют как замену объяснению расхождения.</td><td>Найти первую ложную связь и назвать её источник.</td><td>Сначала reconcile records, затем повторить только проверку.</td></tr></tbody></table></div>\n<p>Таблица разделяет четыре разных вопроса. Mismatch commit относится к происхождению artifact. Mismatch migration относится к совместимости contract. Mismatch digest относится к содержимому, выбранному для rollout. Повторная попытка без такой классификации стирает причину и оставляет команду без доказуемого решения.</p>\n<h2>Порядок действий перед выпуском</h2>\n<ol><li><strong>Зафиксируйте границу проверки.</strong> Укажите release version, owner и источник каждой записи. Пометьте, что сейчас выполняется review, а не deploy.</li><li><strong>Сверьте commit и artifact.</strong> Проверьте exact source commit и digest. Название ветки, последний merge и короткий tag не заменяют id.</li><li><strong>Опишите migration отдельно.</strong> Назовите target version, совместимость с текущим contract и действие по данным. Не прячьте migration в комментарии к image.</li><li><strong>Сверьте rollout intent.</strong> Он должен повторять immutable digest artifact и migration version. Любое расхождение ведёт в stop.</li><li><strong>Назовите return point.</strong> Запишите предыдущую версию и digest. Отдельно укажите, что произойдёт с данными и кто проверит этот путь.</li><li><strong>Повторите проверки после исправления.</strong> Передайте человеку только записи без ложных связей. Положительный результат открывает review, но не выдаёт автоматическое разрешение на deploy.</li></ol>\n<h2>Почему rollback не возвращает всё</h2>\n<p>Rollback Deployment обычно возвращает предыдущую ревизию Pod template. Это полезно для кода и настроек, которые входят в template. Оно не отменяет произвольный SQL, удалённую запись, заполненное поле или изменение внешнего contract. Если migration уже прошла, старый image может не уметь читать новую схему.</p>\n<p>Return point должен содержать две границы. Первая — какую версию artifact можно запустить. Вторая — что разрешено делать с данными. Возможны обратная migration, совместимый промежуточный код, восстановление из резервной копии или запрет автоматического возврата. Пока путь не проверен, честная формулировка звучит так: «возврат artifact определён; откат данных не доказан».</p>\n<p>То же различие действует для provenance и attestations. Официальная документация SLSA описывает проверку provenance через сравнение с ожиданиями пакета. GitHub описывает artifact attestations как подписанные claims о происхождении и даёт команды для проверки. Ни один из этих механизмов сам по себе не утверждает, что migration совместима, rollout одобрен или production здоров.</p>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Описанный подход ловит расхождения между названными записями. Он не доказывает, что значения правдивы. Он не проверяет историю Git, содержимое image, подпись, policy CI, права на кластер, runtime configuration, состояние базы, трафик, метрики или факт доставки. Для этих вопросов нужны разрешённые источники и отдельные проверки.</p>\n<p>Если commit неизвестен, digest отсутствует, migration не имеет compatibility statement или return point не назван, результат должен быть отрицательным. Не подставляйте «последний main», не ищите image по tag и не объявляйте data rollback по факту отката Pod template. Остановитесь на первой неизвестной границе. Такое поведение медленнее одной зелёной кнопки, но дешевле расследования после повреждения данных.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Материал готов к передаче на human review, если второй инженер без устных пояснений может показать: exact commit id, artifact digest, связь artifact с commit, migration target и compatibility, rollout digest, migration version и return point. Для каждой строки есть источник, владелец и действие при mismatch. Проверка должна дать либо все утверждения <code>true</code>, либо конкретный stop с названием ложной связи. В первом случае разрешение на deploy всё ещё принимает авторизованный процесс. Во втором случае deploy не начинается.</p>\n<p>Учебные значения в примере не являются production-результатами. Их задача — показать форму проверки и сохранить отрицательный путь. Реальную оценку готовности нужно выполнять на доступных и разрешённых записях конкретного выпуска.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://slsa.dev/spec/v1.0/terminology\" target=\"_blank\" rel=\"noopener noreferrer\">SLSA v1.0: Terminology and verification model</a> — объясняет provenance verification и сравнение artifact с ожиданиями пакета.</li><li><a href=\"https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Using artifact attestations to establish provenance for builds</a> — описывает проверку attestations для binary и container image.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes Docs: Deployments</a> — описывает rollout history и rollback Deployment revision.</li></ul>"
+  "excerpt": "Как связать commit, provenance, digest, migration и точку возврата до approval — с воспроизводимым gate, отрицательным тестом и честными границами rollback.",
+  "contentHtml": "<p>В заявке на выпуск стоит <code>2024.07.0</code>. Такое же имя указано у ветки, образа, миграции и выкладки. После запуска сервис отвечает ошибкой схемы: новый код обращается к полю, которого нет в базе. Команда повторяет deploy, потому что все записи выглядят согласованными. Это учебный сценарий, а не отчёт о конкретной production-системе. Его задача — показать, какие факты нужно связать до разрешения релиза.</p>\n<p>Номер версии не доказывает происхождение и содержимое выпуска. Для решения нужны как минимум четыре независимые связи: artifact собран из нужного commit, rollout выбирает тот же digest, migration совместима с текущей схемой, а return point описан отдельно. Если связь неизвестна или ложна, проверка должна остановиться. Повторный deploy не превращает неизвестный факт в доказательство.</p>\n<h2>Что именно проверяет инженер</h2>\n<p><strong>Commit</strong> — точная ревизия исходников. <strong>Artifact</strong> — результат сборки, например контейнерный образ, доступный по digest. <strong>Provenance</strong> — проверяемые сведения о том, где и как собран artifact. <strong>Migration</strong> — изменение схемы или данных с заявленной совместимостью. <strong>Rollout intent</strong> — запись о том, какой artifact и какую migration собираются применить. <strong>Return point</strong> — заранее известный вариант возврата к предыдущему коду и описание границы данных.</p>\n<p>Это не одна сущность с полем <code>version</code>. Для каждого объекта нужен источник и владелец. Поле <code>artifact.sourceCommitId</code> ниже — проектный контракт учебной модели, а не универсальное поле Docker или Kubernetes. Аналогично, <code>migration.compatibleWith</code> требует договорённости команды: инструменты миграций называют такие сведения по-разному.</p>\n<figure><img src=\"/assets/editorial/2024/release-engineering-2024-evidence-gate.svg\" alt=\"Схема сверки commit, provenance, digest образа, migration, rollout и точки возврата перед релизом\" loading=\"lazy\" /><figcaption>Учебная схема показывает порядок сверки и стоп-ветку. Это не лог CI, registry, кластера, базы данных или реально выполненного rollout.</figcaption></figure>\n<h2>Почему одного tag недостаточно</h2>\n<p>Tag удобен для человека, но это изменяемая ссылка. Один и тот же tag может указывать на другой образ после следующей сборки. Digest адресует содержимое образа. Docker документирует загрузку образа по форме <code>name@sha256:...</code> и объясняет, что такой идентификатор фиксирует выбранную версию содержимого. Поэтому в rollout-записи храните digest, а tag оставляйте только как дополнительную подпись для чтения.</p>\n<p>Digest отвечает лишь на вопрос «какое содержимое выбрано». Он не отвечает на вопросы «из какого commit оно собрано», «кто его собрал» и «совместима ли схема». Для этого нужен provenance и политика проверки. В SLSA v1.2 проверка включает сопоставление subject с digest artifact, доверенный builder, подпись и ожидаемые параметры сборки. Это отдельный gate, а не синоним успешной загрузки образа.</p>\n<p>У attestation тоже есть граница. Подписанное утверждение связывает metadata с artifact, но не утверждает, что migration выполнилась, сервис принимает трафик или решение о выкладке одобрил нужный человек. Эти факты должны появиться в собственных системах и проверках.</p>\n<h2>Минимальный воспроизводимый gate</h2>\n<p>Следующая команда запускается в Node.js без зависимостей. Все значения синтетические: она не обращается к Git, registry, CI, Kubernetes API или базе. Код проверяет только заранее подготовленные записи и завершает процесс с ненулевым статусом при расхождении. Сохраните его как команду через heredoc или вставьте в локальный терминал.</p>\n<pre><code>node --input-type=module &lt;&lt;'NODE'\nconst current = { schemaVersion: '2024.06.3' };\nconst release = { version: '2024.07.0' };\nconst commit = { id: 'commit-7f4a0c1' };\nconst artifact = {\n  digest: 'sha256:release-070-a1',\n  sourceCommitId: 'commit-7f4a0c1',\n};\nconst migration = {\n  version: '2024.07.0',\n  targetSchemaVersion: '2024.07.0',\n  compatibleWith: '2024.06.3',\n};\nconst rollout = {\n  artifactDigest: 'sha256:release-070-a1',\n  migrationVersion: '2024.07.0',\n};\nconst returnPoint = {\n  artifactDigest: 'sha256:release-069-z9',\n  schemaVersion: '2024.06.3',\n};\n\nconst checks = {\n  source: artifact.sourceCommitId === commit.id,\n  release: migration.version === release.version,\n  compatibility: migration.compatibleWith === current.schemaVersion,\n  artifact: rollout.artifactDigest === artifact.digest,\n  migration: rollout.migrationVersion === migration.version,\n  returnPoint: Boolean(returnPoint.artifactDigest && returnPoint.schemaVersion),\n};\nconst ready = Object.values(checks).every(Boolean);\n\nconsole.log(JSON.stringify({ checks, ready }, null, 2));\nif (!ready) process.exitCode = 1;\nNODE</code></pre>\n<p>При исходных данных команда печатает <code>\"ready\": true</code> и завершается с кодом 0. Измените <code>rollout.artifactDigest</code> на <code>sha256:release-070-other</code>: поле <code>artifact</code> станет <code>false</code>, а процесс завершится с кодом 1. Такой отрицательный тест важнее красивого положительного fixture: он показывает, что gate не угадывает правильную запись.</p>\n<p>Положительный результат означает только согласованность шести полей в памяти. Он не доказывает, что digest существует в registry, provenance подписан, миграция запущена, а старый artifact умеет работать с новой схемой. Эти вопросы нельзя «досчитать» из примера.</p>\n<h2>Диагностика: симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Классификация расхождения до запуска</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Tag совпадает, а digest другой.</td><td>Rollout использует изменяемую ссылку вместо содержимого.</td><td>Сверить digest в intent с digest из registry и записи сборки.</td><td>Остановить запуск; пересоздать intent после выбора exact artifact.</td></tr><tr><td>Artifact указывает на другой commit.</td><td>Образ собран из другой ревизии, либо provenance неполон.</td><td>Сопоставить commit, provenance subject и ожидаемый source repository.</td><td>Не объявлять образ релизом; пересобрать или исправить запись после расследования.</td></tr><tr><td>Новая схема не совместима со старым кодом.</td><td>Миграцию выполнили как необратимый шаг до перехода reader/writer.</td><td>Проверить порядок expand, переключение читателей и contract-шаг.</td><td>Остановить удаление/изменение данных; привлечь владельца схемы.</td></tr><tr><td>После stop предлагают повторить deploy.</td><td>Retry используют вместо объяснения первой ложной связи.</td><td>Найти первый mismatch и назвать источник каждого значения.</td><td>Сначала reconcile записей, затем повторить только проверку.</td></tr></tbody></table></div>\n<p>Таблица разделяет происхождение, содержимое и совместимость. Это помогает не лечить ошибку схемы заменой образа и не считать зелёный rollout доказательством корректности данных. Если один источник недоступен, статус должен быть «не проверено», а не «вероятно совпадает».</p>\n<h2>Порядок проверки перед approval</h2>\n<ol><li><strong>Определите объект релиза.</strong> Зафиксируйте имя сервиса, среду, release version и владельцев commit, artifact, migration и deploy. Не смешивайте тестовые и production-записи.</li><li><strong>Сверьте исходники и сборку.</strong> Возьмите полный commit id из системы контроля версий. Проверьте source repository, builder и параметры provenance; короткий tag или название ветки их не заменяет.</li><li><strong>Зафиксируйте artifact.</strong> Получите digest из registry или результата push. В deployment-манифесте используйте ссылку с digest, если это поддерживает ваша платформа. Для Docker-пути пример выглядит как <code>registry.example/app@sha256:...</code>.</li><li><strong>Опишите migration.</strong> Назовите текущую и целевую схему, совместимость reader/writer, порядок шагов и отдельное действие для данных. Не прячьте SQL и условия возврата в комментарии к образу.</li><li><strong>Сверьте intent.</strong> Digest artifact и digest rollout должны совпасть, как и версия migration. Несовпадение переводит запись в stop.</li><li><strong>Проверьте return point.</strong> Запишите предыдущий digest, revision, способ переключения и проверку здоровья. Отдельно укажите, можно ли вернуть данные, и кто принимает это решение.</li><li><strong>Повторите gate после исправления.</strong> Положительный результат открывает human approval, но не выдаёт автоматическое право на deploy. Авторизованный процесс всё равно должен проверить свои policy, права и наблюдаемость.</li></ol>\n<h2>Что действительно означает rollback</h2>\n<p>В Kubernetes новая revision Deployment появляется, когда меняется Pod template, например image или labels. Команда <code>kubectl rollout undo</code> возвращает предыдущую ревизию этого шаблона. Значит, такой rollback касается описания Pod: образа, переменных и других полей template. Он не является отменой произвольного SQL, удалённой строки, уже отправленного сообщения или изменения внешней системы.</p>\n<p>Проблема особенно заметна при миграции. Если новая версия добавила поле и старый код его не ожидает, возврат image может вернуть работоспособность. Если новая версия удалила или изменила смысл поля, старый код может не запуститься на текущей схеме. До релиза нужен либо совместимый expand/contract-переход, либо проверенная обратная миграция, либо восстановление из резервной копии. Выбор зависит от базы, инструмента и договора владельцев данных.</p>\n<p>Практичная формулировка return point состоит из двух утверждений: «этот artifact можно снова запустить» и «для этой схемы есть разрешённое действие». Первое не даёт права утверждать второе. Если доказан только возврат Pod template, так и пишите в release record: «rollback кода определён; rollback данных не подтверждён».</p>\n<h2>Границы применимости и безопасный stop</h2>\n<p>Метод подходит как предварительная проверка связей в release record и как шаблон для CI-gate. Он не заменяет security review, проверку подписи, тест совместимости, backup/restore drill, smoke-тест, анализ метрик или approval согласно правилам организации. Названия полей и формат provenance в вашем toolchain могут отличаться; переносите инварианты, а не имена из учебного примера.</p>\n<p>SLSA проверяет provenance относительно заданных ожиданий, но сами ожидания должны быть сформированы и защищены командой. GitHub artifact attestations доступны только при соответствующей настройке workflow и permissions; команда <code>gh attestation verify</code> требует доступного GitHub-контекста и не проверяет вашу migration. Kubernetes хранит историю Deployment с ограничениями revision history, поэтому старый Pod template может быть недоступен, если историю сократили или образ удалён.</p>\n<p>Статус должен быть отрицательным, если отсутствует полный commit id, digest, источник provenance, compatibility statement или return point. Не подставляйте «последний main», не ищите образ по tag и не объявляйте rollback данных по факту <code>kubectl rollout undo</code>. Остановка на первой неизвестной границе дешевле расследования после повреждения данных.</p>\n<h2>Критерий готовности</h2>\n<p>Перед human approval второй инженер без устных пояснений должен найти exact commit id, source repository, artifact digest, связь artifact с commit, результат provenance verification, текущую и целевую схему, compatibility statement, rollout digest, migration version и return point. Для каждого значения указаны источник, владелец и действие при mismatch.</p>\n<p>Готовность здесь — не одно зелёное число. Это воспроизводимый набор утверждений: все обязательные связи истинны, неизвестные значения не замаскированы, а возврат коду не выдан за возврат данным. Если хотя бы одно утверждение нельзя показать, релиз остаётся на проверке с конкретной причиной остановки.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://slsa.dev/spec/v1.2/verifying-artifacts\" target=\"_blank\" rel=\"noopener noreferrer\">SLSA v1.2: Verifying artifacts</a> — описывает проверку subject digest, подписи, builder identity и ожиданий provenance.</li><li><a href=\"https://slsa.dev/spec/v1.2/build-track-basics\" target=\"_blank\" rel=\"noopener noreferrer\">SLSA v1.2: Build Track Basics</a> — объясняет, зачем provenance связывает artifact с источниками и процессом сборки.</li><li><a href=\"https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Using artifact attestations</a> — содержит настройку attestations и команду проверки binary/container image.</li><li><a href=\"https://docs.docker.com/reference/cli/docker/image/pull/\" target=\"_blank\" rel=\"noopener noreferrer\">Docker Docs: docker image pull</a> — показывает синтаксис pull по digest и границу между tag и immutable identifier.</li><li><a href=\"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes Docs: Deployments</a> — описывает rollout history и то, что rollback возвращает Pod template, а не произвольные изменения данных.</li></ul>"
 }