${text}
`; +const h2 = (text) => `${escapeHtml(text)}| ${cell} | `).join('')}
|---|
| ${cell} | `).join('')}
synthetic-plan-hand-off; вместе с ним всегда остаётся productionEffect: not-attempted.'),
+ h2('Совет начинается с решения, которого ещё нет'),
+ p('Под «карточкой решения» здесь понимается не ADR и не заявка на изменение. Это короткая форма, которая заставляет назвать вопрос, допустимый источник, границу вывода и следующий шаг. В P118 она существует только как named fixed in-memory literal author-manifesto-decision-record-before-advice-v1. Его нельзя принять за файл, запись, шаблон команды или будущий процесс. Literal нужен, чтобы проверить форму рассуждения, а не сообщить о том, что решение когда-либо было принято.'),
+ p('Технический совет без вопроса опасен не потому, что он обязательно неверен. Он опасен тем, что не говорит, что именно опровергнет его применимость. Фраза «добавьте проверку» не указывает вход, требуемое свойство, владельца исключения и цену отказа. В карточке вместо этого сначала появляется один вопрос: какое решение нельзя принять, пока неизвестны границы claim. До ответа на него команда не выбирает библиотеку, не пишет правило и не обещает выпуск.'),
+ p('Такой порядок особенно полезен в долгих текстах. Чем убедительнее объяснение, тем проще читателю забыть, откуда взялась исходная посылка. Короткое поле source boundary возвращает разговор к проверяемому: нормативный документ может объяснить значение слова, но не может доказать факт в чужом проекте. Прошлая заметка могла бы быть историческим материалом, но в этом плановом scope она не является evidence. Поэтому P118 не строит цепочку «архив → правило → успех».'),
+ table('Карточка перед техническим советом', ['Поле', 'Значение в P118', 'Что разрешает', 'Чего не разрешает'], [
+ ['Вопрос', 'author-manifesto-decision-record-before-advice-v1', 'Сохранить предмет будущего решения', 'Принять решение или назвать его владельца'],
+ ['Источник', 'author-manifesto-official-sources-v1', 'Проверить терминологическую границу', 'Считать официальный текст свидетельством локального события'],
+ ['Вход review', 'not-provided', 'Признать отсутствие входа', 'Сказать, что текст был прочитан или оценён'],
+ ['Декларация', 'not-declared', 'Не смешивать форму и результат', 'Объявить качество, pass, публикацию или коррекцию'],
+ ['Выход', 'synthetic-plan-hand-off', 'Передать вопрос дальше', 'Обещать production effect'],
+ ]),
+ h2('Граница между рецептом и утверждением'),
+ p('Рецепт отвечает на вопрос «что попробовать при известном симптоме». Утверждение отвечает на другой вопрос: «почему это действие относится к данной причине». В инженерной статье оба слоя нужны, но их нельзя маскировать один другим. Если указан только рецепт, reader не понимает, когда остановиться. Если указан только вывод, reader не может повторить проверку. Карточка решения заставляет держать слой действия рядом с его ограничением.'),
+ p('Например, совет о логировании не должен начинаться с названия поля. Сначала автор определяет решение: достаточно ли данных, чтобы различить два состояния. Затем называет допустимые входы, чувствительные поля и условие, при котором лог ничего не доказывает. Только после этого возможен пример формата события. P118 не содержит такой реальный event и не предлагает его собрать. Он показывает последовательность вопросов, которую будущий scope обязан сделать явной.'),
+ p('У этой дисциплины есть стоимость: начало статьи становится медленнее, а заголовок не обещает универсальную кнопку. Зато читатель видит, где заканчивается утверждение. Это снижает blast radius советов, которые кажутся мелкими: параметр timeout, признак готовности, правило миграции или формат review могут менять поведение целого контура. Писать «лучше всегда» дешевле, чем назвать границу, но именно эта экономия создаёт дорогую диагностику позже.'),
+ figure('/assets/editorial/2027/author-manifesto-2027-editorial-decision-graph.svg', 'Граф решения: вопрос, источник и граница вывода сходятся в синтетический hand-off; неизвестный источник или заявленный результат ведут к остановке.', 'Схема показывает форму планового решения для P118. Она не сообщает о реальной статье, архиве, редакционном действии, публикации или исправлении.'),
+ h2('Runnable пример оставляет совет неполным'),
+ p('Пример ниже безопасно запускается в Node рядом с модулем. Он не читает файлы, сеть, environment, clock, secrets, telemetry, system или data. Он берёт только зашитый literal и возвращает статус его формы. Поэтому вывод не является оценкой текста и не указывает, какой совет нужно написать. Не добавляйте сюда repository path, issue, автора или реалистичный контекст: такие детали выглядели бы как скрытые входы, которых у P118 нет.'),
+ code("import { inspectDecisionRecordLiteral } from './upgrade-2027-12.mjs';\n\nconst card = inspectDecisionRecordLiteral();\nconsole.log(card.question, card.status, card.productionEffect);\n// author-manifesto-decision-record-before-advice-v1 synthetic-plan-hand-off not-attempted"),
+ h2('Порядок работы до появления текста'),
+ ol(['Назвать одно решение, которое без дополнительного evidence нельзя принять, и оставить его вопросом, а не выводом.', 'Зафиксировать editorial date, planDate и source cutoff; будущий период не даёт права описывать будущие события.', 'Выбрать только проверяемые источники и рядом написать, что каждый из них не может подтвердить.', 'Отделить рецептурный шаг от factual claim: для каждого указать условия применимости и условие остановки.', 'Если требуется review, publication, correction или feedback, перенести их в другой authorised scope с собственными входами.', 'Передать исходный вопрос как synthetic-plan-hand-off, не заменяя его декларацией качества.']),
+ h2('Почему декларация не заменяет решение'),
+ p('Слово «манифест» часто провоцирует обратный порядок: сначала объявить принцип, затем подобрать примеры. Для технического письма это слабая конструкция. Принцип без decision record не показывает, кто должен действовать, какой вход допустим и чем можно опровергнуть правило. P118 использует название выпуска как тему проверки: не лозунг о письме, а разбор того, какую форму должен иметь совет до появления уверенного тона.'),
+ p('Даже аккуратная формула «пишите доказуемо» недостаточна. Неясно, о доказательстве какого типа идёт речь: ссылка на норму, воспроизводимый запуск, наблюдение в среде или вывод из нескольких артефактов. Эти типы нельзя свести к одному слову evidence. Карточка решения сначала фиксирует вид вопроса, а следующий scope выбирает метод. Так future reader не получит ложного разрешения заменить отсутствующий trace ссылкой на стандарт.'),
+ p('Уместный технический язык здесь прямой. Вместо «повысим качество текста» лучше спросить: какое утверждение нельзя проверить без источника, даты или допустимого ввода? Вместо «учтём контекст» — какой контекст меняет выбор действия? Вместо «сформируем культуру» — кому принадлежит решение открыть новый scope? Такие замены не делают прозу холоднее; они возвращают ей объект, действие и проверку.'),
+ p('План не обязан заранее решить, будет ли следующий scope создан. Может оказаться, что вопрос снимается без исследования, потому что изменение не требуется. Может оказаться, что нужный вход нельзя законно или безопасно собрать. Может оказаться, что совет нужно сузить до условия версии. Любой из этих результатов совместим с хорошей карточкой. Несовместимо только одно: описать один из вариантов как уже случившийся в будущем декабре 2027.'),
+ h2('Как карточка удерживает цену решения'),
+ p('Цена решения не сводится к числу часов. У совета есть цена неверного применения, цена объяснения исключения, цена обратимости и цена поддержки следующего читателя. Если автор не называет хотя бы одну из них, рекомендация обычно выглядит дешевле, чем есть. Карточка не обязана рассчитывать стоимость. Ей достаточно обозначить, какое последствие меняет выбор: риск потерять данные, расширить доступ, скрыть деградацию или закрепить неподдерживаемую зависимость.'),
+ p('Такой подход меняет работу с примером. Код в статье не служит знаком компетентности и не должен быть самым убедительным элементом страницы. Он отвечает на узкий вопрос: как выглядит действие после того, как условия названы. Рядом полезно сказать, чего пример не содержит: production configuration, реальный request, секрет, профиль нагрузки и подтверждённый результат. Тогда читатель не переносит литературную компактность кода на свою систему без проверки.'),
+ p('Решение также нуждается в обратимости. Если совет можно отменить только ценой миграции, потери совместимости или ручного восстановления, это не повод отказаться от него, но повод записать границу заранее. В P118 нет конкретного изменения, поэтому нет и обещания rollback. Будущий scope должен отдельно определить, что будет означать отказ от выбранного пути. Нельзя подменять эту работу фразой «при необходимости откатим»: она скрывает owner, данные и порядок восстановления.'),
+ p('Полезная карточка различает адресата текста и владельца решения. Статья может быть написана для инженера, но не назначает ему право менять систему. Совпадение этих ролей нельзя предполагать по должности или тону. В данном сценарии оба поля сознательно отсутствуют: P118 не знает будущей команды. Благодаря этому advice остаётся техническим артефактом, а не неявным приказом тому, кто первым его прочитает.'),
+ p('Наконец, advice должен переживать неизвестность. Если новая версия, другой источник или более узкий риск меняют вывод, текст не считается провалом. Провалом будет скрыть условие и заставить reader обнаружить его в production. Поэтому практическая форма манифеста — не набор правил, а привычка оставлять у утверждения место для опровержения. Она делает следующий разговор короче, потому что участники спорят о названном условии, а не о стиле автора.'),
+ h2('Ограничения и следующий шаг'),
+ p('P118 practice не является editorial policy, ADR, историей публикаций, каталогом статей, review record, evidence package или рекомендацией для конкретной команды. Official sources здесь задают язык границ, но не являются доказательством местного решения. Fixed literals не принимают пользовательский input и не моделируют проект. Fixture проверяет закрытый набор значений; он не проверяет ясность будущей статьи и не измеряет её эффект.'),
+ p('Следующий шаг возможен только в отдельном authorised scope, если конкретный технический вопрос потребует решения. В нём надо назвать допустимые inputs, владельца решения, метод проверки, правила redaction и возможность отрицательного вывода. До этого P118 сохраняет честно ограниченную форму: вопрос остаётся вопросом, а результат — только synthetic-plan-hand-off с productionEffect: not-attempted.')
+], practiceRefs);
+
+const mechanism = revision({ slug: 'editorial-2027-12-mechanism-author-manifesto', title: 'Инженерное письмо: рубрика качества вместо заявленного качества', categories: ['Процесс', 'Техническое письмо'], cover: '/assets/editorial/2027/author-manifesto-2027-quality-rubric-matrix.svg', excerpt: 'План на декабрь 2027: как проверять claims и границы тремя проходами, не объявляя pass и не выдумывая evidence.', readingMinutes: 29 }, [
+ p('P118 — плановый сценарий на 2027-12, составленный 2026-07-31. Механическая проблема качества текста точна: автор ставит ярлык «проверено», хотя не разделил claim, вход для проверки и условие опровержения. Цена ошибки — спор о впечатлении вместо работы с границей. В результате ссылка, пример и уверенная интонация склеиваются в один сигнал, а reader не может понять, какая часть текста относится к факту, а какая к предложенному действию.'),
+ p('Следующая цена — превратить три прохода review в рассказ о трёх прошедших review. У P118 нет будущих reviewer, их входов, оценок, замечаний, pass, публикации, corrections, feedback или outcome. Неизвестные данные не подставляются из local standards, trajectory или существующих неопубликованных artefacts: это vocabulary будущего контракта, а не доказательство будущего события. Единственный accepted positive output — synthetic-plan-hand-off с productionEffect: not-attempted.'),
+ h2('Рубрика измеряет полноту вопроса, не качество автора'),
+ p('Рубрика полезна, когда она не выдаёт балл за стиль. В этой статье она раскладывает фразу на четыре поля: claim, evidence level, falsifier и boundary. Claim — то, что текст предлагает считать верным. Evidence level — происхождение, которое могло бы поддержать claim. Falsifier — наблюдение или условие, после которого claim нельзя оставлять прежним. Boundary — то, чего claim не охватывает. Без этой четвёрки review быстро становится спором о том, «достаточно ли убедительно» написано.'),
+ p('P118 не заполняет эти поля реальным материалом. В named literal review inputs имеют значение not-provided. Это не отрицательная оценка и не скрытый result: input не был передан модулю. Такое различие важно для evidence levels. «Нет данных» не равно «данные слабые», а «источник известен» не равно «источник поддерживает именно этот вывод». Любая будущая рубрика должна сохранять это различие, иначе уровень доказательности станет декоративной шкалой.'),
+ p('Falsifiability в инженерном письме не требует научного эксперимента для каждого предложения. Она требует назвать, что изменило бы решение. Если статья рекомендует ограничить retry, опровергнуть применимость может семантика операции. Если предлагает кэш, опровергнуть её может отсутствие допустимой инвалидации. Если описывает правило review, опровергнуть его может неизвестный тип входа. В P118 эти примеры не говорят о существующей системе; они различают форму условия и утверждение о факте.'),
+ table('Матрица уровней evidence и фальсифицируемости', ['Уровень', 'Допустимая форма', 'Чего недостаточно', 'Вопрос falsifier'], [
+ ['E0 — отсутствует', 'not-provided', 'Уверенная формулировка или правдоподобный пример', 'Какой вход вообще разрешён?'],
+ ['E1 — нормативный', 'Датированный стандарт или спецификация', 'Вывод о локальном поведении', 'Какая реализация или версия меняет чтение нормы?'],
+ ['E2 — воспроизводимый', 'Описанный метод и сохранённый результат в отдельном scope', 'Один пересказ запуска', 'Какая одинаковая проверка даст другой результат?'],
+ ['E3 — контекстный', 'Связанные inputs, метод и ограниченный inference', 'Метрика без условий измерения', 'Какая граница данных ломает перенос вывода?'],
+ ['P118', 'Только форма будущей рубрики', 'Quality/pass/publication/correction/outcome', 'Почему вообще нельзя объявить результат?'],
+ ]),
+ h2('Три прохода идут по разным рискам'),
+ p('Первый проход — evidence. Он не спрашивает, нравится ли источник. Он сопоставляет каждое существенное утверждение с происхождением: норма, версия, метод, наблюдение или неизвестность. Если claim живёт за пределами источника, рядом должна быть boundary. Для планового выпуска этот проход закономерно получает not-provided. Он не может превратить ссылку на RFC или W3C Recommendation в свидетельство будущего редакционного действия.'),
+ p('Второй проход — temporal. Он проверяет, не перескочил ли текст через дату. Здесь dates — не метаданные после публикации, а часть значения. Editorial date 2026-07-31, planDate 2027-12 и source cutoff 2026-07-31 закреплены exact literals. Любая другая дата останавливает evaluator. Тем самым формулировка «будет исправлено» остаётся недопустимой: она незаметно сообщает о том, чего в плановом scope не происходило.'),
+ p('Третий проход — voice. Его задача не угадать личность автора по оборотам. Он проверяет техническую плотность: первые абзацы называют проблему и цену, пример ограничен входом, таблица различает варианты, а финал оставляет следующее действие и ограничение. Local editorial standards и voice trajectory могут быть названы только как vocabulary будущего контракта. Они не доказывают, что голос уже проверялся, что editor видел статью или что какая-либо траектория продолжилась в 2027.'),
+ p('Три прохода нельзя склеивать в общий stamp. Хорошая ссылка не исправляет future tense. Спокойный голос не заменяет falsifier. Удобная таблица не делает недоступный input известным. Когда критерии смешаны, найденная слабость растворяется в общем «выглядит неплохо». Когда они разделены, каждый stop имеет понятную причину и не требует выдумывать среднее качество текста.'),
+ figure('/assets/editorial/2027/author-manifesto-2027-quality-rubric-matrix.svg', 'Матрица рубрики: evidence, temporal и voice проходят отдельно; неизвестный вход и заявленный pass останавливают синтетический evaluator.', 'Рисунок объясняет три независимые проверки формы P118. Он не фиксирует реальный review, качество статьи, редакторский verdict или выпуск.'),
+ h2('Runnable пример показывает отсутствие review'),
+ p('Этот вызов безопасен: функции работают с immutable literals, не принимают ввод, не открывают filesystem и не обращаются к сети. Console output не означает, что evidence, temporal или voice действительно были проверены. Он лишь показывает, что valid plan хранит их как not-provided. Это точнее, чем подставить «pass pending»: pending уже создаёт историю процесса, которой здесь нет.'),
+ code("import { inspectRubricLiteral } from './upgrade-2027-12.mjs';\n\nconst rubric = inspectRubricLiteral();\nconsole.log(rubric.evidence, rubric.temporal, rubric.voice, rubric.status);\n// not-provided not-provided not-provided synthetic-plan-hand-off"),
+ h2('Порядок трёх проходов'),
+ ol(['Выписать отдельные claims и отметить, что является нормативным словом, предположением или действием.', 'Для каждого claim выбрать только известный evidence level; если вход отсутствует, оставить not-provided.', 'Сформулировать falsifier как условие смены решения, а не как обещание будущего теста.', 'Проверить exact temporal boundary: редакторская дата, planDate и cutoff не могут быть заполнены по умолчанию.', 'Прочитать текст в голосовом проходе: убрать лозунг, вернуть предмет, цену, ограничение и следующий шаг.', 'Остановить пакет, если появляется hidden review input либо declared quality, pass, publication, correction или outcome.']),
+ h2('Почему уровни не являются рейтингом'),
+ p('E3 не «лучше» E1 во всех задачах. Нормативный источник может быть достаточен, когда вопрос касается значения обязательного слова. Воспроизводимый метод нужен, когда речь о поведении конкретной версии. Контекстный inference требует ещё больше условий, но не даёт права сделать его универсальным. Рубрика работает, когда показывает соответствие формы вопроса и источника, а не когда стимулирует собирать наиболее эффектные доказательства.'),
+ p('Это также защищает от ложной точности. Число баллов, процент готовности или зелёный badge кажутся удобными, потому что упрощают передачу. Но при отсутствии входов они превращают unknown в красивый verdict. P118 намеренно не содержит шкалу pass/fail для будущей статьи. Его evaluator принимает один fixed literal и возвращает один hand-off; он не умеет повышать quality, выдавать publication status или считать correction завершённой.'),
+ p('Механизм fail closed важнее позитивной ветки. Unknown object не нормализуется до plan. Unknown source set не превращается в «источник позже уточним». Unknown question не получает стандартный текст. Claimed review не становится warning. Любое из этих состояний получает свой stop. Такой дизайн неудобен для демонстрации гладкого процесса, зато не даёт случайно использовать модуль как генератор правдоподобного editorial history.'),
+ p('Техническому лидеру полезно показывать эту неудобную часть. В реальной работе самый дорогой спор часто начинается не с ошибки в коде, а с невидимого перехода от наблюдения к выводу. Рубрика делает переходы явными: источник описывает норму, метод описывает воспроизводимость, reviewer input описывает review, а output описывает только форму hand-off. Если одного звена нет, цепочка не должна притворяться полной.'),
+ h2('Как читать claim без лишней уверенности'),
+ p('Claim полезно писать в проверяемом времени и области. «Этот механизм сокращает ошибки» слишком широк: неизвестны механизм, ошибка, период и способ сравнения. «Для этого входа обработчик отвергает неизвестный literal» уже связывает действие с наблюдаемым контрактом. Второе предложение не делает систему лучше само по себе, но даёт reviewer предмет для проверки. Если поле меняется, claim можно сузить или снять без спора о намерениях автора.'),
+ p('Evidence level не следует прятать в сноске. Когда ключевой вывод поддержан только нормативным текстом, это надо назвать возле вывода. Норма сообщает, как читать требование; она не сообщает, что конкретная реализация следует ему. Когда вывод получен запуском, читателю нужны версия, вход, метод и ограничение результата. Когда этих полей нет, аккуратный текст говорит об отсутствии основания, а не повышает убедительность прилагательными.'),
+ p('Falsifier должен быть доступен тому, кто принимает решение. Формула «проверим все случаи» не годится: она не определяет случаи и может оказаться невыполнимой. Гораздо полезнее назвать один класс входов, который меняет выбор, и признать остальные неизвестными. Это не упрощение ради отчёта. Такая граница определяет, сколько работы действительно нужно до решения и когда следует открыть отдельное исследование вместо бесконечной редактуры.'),
+ p('Temporal проход ловит не только будущие даты. Он также ловит ретроспективную причинность: «после этой статьи команда стала делать X» требует событий и связи между ними. В плановом документе даже нейтральное «позже исправим» может выглядеть как согласованный backlog. P118 избегает такого намёка. Он описывает лишь то, что другой scope мог бы решить после получения разрешённых inputs, и оставляет возможность не предпринимать ничего.'),
+ p('Voice проход имеет техническую цену. Абстрактная фраза заставляет reader достраивать объект; чрезмерный жаргон переносит стоимость расшифровки на менее опытного коллегу; декларация качества снимает вопрос слишком рано. Поэтому хороший поздний голос не становится авторитетнее за счёт громкости. Он становится полезнее, когда прямо называет вход, риск, решение, ограничение и следующую проверку. Рубрика удерживает эту последовательность даже там, где нет права утверждать результат.'),
+ h2('Ограничения и следующий шаг'),
+ p('P118 mechanism не является quality policy, rubric rollout, редакторским протоколом, published checklist, evidence audit или доказательством качества будущего текста. W3C и IETF sources применены к терминологии и модальным границам, не к локальной истории. The fixture не проверяет логику реального review и не делает conclusion об авторе, редакторе, архиве или продукте.'),
+ p('Следующий шаг требует отдельного authorised scope с разрешёнными источниками, датой, owner, способом хранения evidence и правом на отрицательный verdict. Там можно будет определить, какие levels подходят конкретному technical claim. Нельзя перенести в него объявленный результат P118: текущий сценарий заканчивается только synthetic-plan-hand-off, а productionEffect: not-attempted сохраняется на каждой ветке.')
+], mechanismRefs);
+
+const field = revision({ slug: 'editorial-2027-12-field-author-manifesto', title: 'Инженерное письмо: корректирующий hand-off без вымышленной редакционной истории', categories: ['Практика', 'Техническое письмо'], cover: '/assets/editorial/2027/author-manifesto-2027-revision-handoff-loop.svg', excerpt: 'План на декабрь 2027: как передать вопрос о правке и развитии автора, не подделывая feedback, публикацию или эффект.', readingMinutes: 28 }, [
+ p('P118 — план/scenario для 2027-12 с editorial date 2026-07-31 и source cutoff 2026-07-31. Полевая проблема корректирующей передачи начинается, когда незавершённый вопрос оформляют как историю: «получили замечание, поправили, текст стал сильнее». Цена ошибки высока: следующему человеку достаётся не вопрос, а обязательство согласиться с несуществующим feedback и продолжать якобы начатую работу. Так редакционный язык создаёт ложное происхождение решения.'),
+ p('Вторая стоимость — считать развитие автора доказанным по самому факту планирования. У P118 нет автора как объекта оценки, reviewer, комментария, текста будущей статьи, публикации, correction, реакции читателя, команды, метрики или production effect. Также нельзя брать local standards, trajectory, unpublished artifacts или очереди как factual evidence. Они допустимы лишь как имена будущих contract vocabulary. Accepted positive output один: synthetic-plan-hand-off; production effect во всех исходах — not-attempted.'),
+ h2('Коррекция начинается с неизвестного, а не с замечания'),
+ p('Corrective hand-off нужен не для того, чтобы послать человеку список улучшений. В строгом scope он сохраняет вопрос: какой claim потребует пересмотра, если authorised evidence появится позже. Пока evidence нет, нельзя говорить, что claim ошибочен, что редактура обнаружила проблему или что автор изменил подход. В fixed literal это отражено пятью отдельными полями: quality, pass, publication, correction и outcome имеют значение not-declared.'),
+ p('Отрицательное значение имеет происхождение. not-declared не означает «декларация ждёт подтверждения» и не означает «кто-то не заполнил форму». Оно означает, что P118 не создавал такого утверждения. Аналогично not-provided для review inputs не означает потерянный комментарий. Вход не передавался. Такая точность убирает привычное давление: будто следующий scope обязан найти подтверждение, чтобы завершить заранее написанную историю.'),
+ p('Author development требует ещё большей осторожности. Полезно обсуждать практику письма, но небезопасно выводить из текста личную динамику. Формулировки «научился», «перестал ошибаться», «стал самостоятельнее» требуют наблюдаемого, разрешённого и контекстного evidence. В P118 ничего такого нет. Field lens поэтому не моделирует человека. Он моделирует границу передачи: неизвестность можно передать честно, а оценку — только после отдельного решения о допустимых inputs.'),
+ table('Корректирующая передача без ложного происхождения', ['Поле', 'Literal P118', 'Безопасное чтение', 'Запрещённая история'], [
+ ['Review input', 'not-provided', 'P118 не получил вход', 'Редактор увидел и одобрил текст'],
+ ['Quality', 'not-declared', 'Нет verdict', 'Статья качественная или слабая'],
+ ['Publication', 'not-declared', 'Выпуск не заявлен', 'Материал опубликован в декабре 2027'],
+ ['Correction', 'not-declared', 'Правка не заявлена', 'Ошибка найдена и исправлена'],
+ ['Outcome', 'not-declared', 'Эффект не заявлен', 'Автор или production изменились'],
+ ]),
+ h2('Петля hand-off не должна замыкаться сама'),
+ p('В корректирующем процессе обычно рисуют цикл: claim, feedback, revision, release. Для P118 такая схема опасна, если стрелки читаются как произошедшие события. Здесь петля обрывается до первого факта. Она принимает только named question и fixed temporal boundary, затем проверяет отсутствие hidden review inputs и declarations. При любом claimed quality, pass, publication, correction или outcome evaluator выдаёт stop. Он не предлагает исправление и не выбирает адресата.'),
+ p('Это не отказ от ответственности. Наоборот, hand-off сохраняет ответственность на правильной границе. Будущий owner, если он вообще появится в новом scope, должен решить, нужен ли review, какие данные допустимы, кто увидит материалы и что будет считаться корректирующим действием. P118 не называет owner, потому что назначение роли тоже является действием с последствиями. Предсказать его «для полноты» означало бы создать несуществующую обязанность.'),
+ p('В поле особенно легко подменить unknown правдоподобной деталью: вставить короткую цитату reviewer, номер revision, дату публикации или пример комментария. Даже synthetic-looking detail будет работать как evidence, если reader не видит её происхождения. Поэтому visual, таблица и code P118 описывают только статусы формы. Они не содержат заголовка будущей статьи, имени человека, оценки формулировки или примера исправленной фразы.'),
+ figure('/assets/editorial/2027/author-manifesto-2027-revision-handoff-loop.svg', 'Петля корректирующей передачи: временная граница и отсутствие review ведут к hand-off; declared quality, publication, correction или outcome останавливают маршрут.', 'Диаграмма показывает fail-closed форму P118. Она не подтверждает review, feedback, правку, выпуск, развитие автора или производственный эффект.'),
+ h2('Runnable пример не создаёт correction'),
+ p('Запуск ниже не открывает процесс и не меняет запись. Код делает только одно: создаёт копию named in-memory literal, проверяет exact values и возвращает поля declarations. Нет обращения к filesystem, network, environment, clock, secrets, telemetry, system или data. Вывод not-declared не является рекомендацией ничего не исправлять; он показывает, что у этого scope нет права утверждать факт исправления.'),
+ code("import { inspectHandoffLiteral } from './upgrade-2027-12.mjs';\n\nconst handoff = inspectHandoffLiteral();\nconsole.log(handoff.quality, handoff.correction, handoff.outcome, handoff.status);\n// not-declared not-declared not-declared synthetic-plan-hand-off"),
+ h2('Порядок корректирующей передачи'),
+ ol(['Оставить claim вопросом до появления разрешённого evidence; не называть его ошибкой заранее.', 'Зафиксировать даты и cutoff вместе с вопросом, чтобы future tense не стал fabricated history.', 'Проверить, что reviewer input, feedback и publication не спрятаны в метаданных, примере или подписи к визуалу.', 'Сохранить quality, pass, publication, correction и outcome как not-declared; не заменять неизвестное оптимистичным pending.', 'Передать только boundary и условия отдельного scope, не назначая автора, reviewer, owner или получателя.', 'Остановить evaluator на unknown source, unknown date, unknown question, hidden input или declared result.']),
+ h2('Почему развитие автора не является итогом статьи'),
+ p('Техническое письмо влияет на автора только через цепочку конкретных действий и наблюдений, а не через название раздела. Нужно различать: статья может описывать правило; reviewer может дать комментарий; автор может принять или отклонить его; затем возможна новая версия и отдельная проверка. Каждый переход требует своего evidence и права работать с ним. Склеить цепочку в «развитие» удобно для резюме, но бесполезно для инженерного решения.'),
+ p('Будущий scope может вообще отказаться от персонального измерения. Возможно, достаточно поправить технический claim, а вопрос об авторе не относится к задаче. Возможно, feedback содержит чувствительные данные и не должен храниться в редакционном артефакте. Возможно, корректировка окажется не нужна, потому что новый источник изменит interpretation. P118 не выбирает между этими вариантами. Его полезность в том, что варианты остаются открытыми и не получают фальшивый prior.'),
+ p('Такой hand-off также не разрешает задним числом использовать local trajectory как доказательство. Траектория голоса — будущая contract vocabulary: она может подсказать, какие проверки поставить, но не сообщает, что человек уже прошёл эти проверки. Editorial standard — vocabulary критериев, но не timestamp review. Unpublished artefact — не источник подтверждённого эффекта. Каждый из этих объектов может стать входом только после того, как другой scope задаст происхождение, доступ и допустимый вывод.'),
+ p('Видимый stop — часть заботы о читателе. Если evaluator возвращает stop-hidden-review-input, это не ошибка будущего reviewer. Если возвращает stop-declared-quality-pass-publication-correction-or-outcome, это не оценка качества текста. Stop говорит только о несоответствии границе P118. Такое название не даёт оператору «починить» статус добавлением деталей; правильное действие — убрать неподтверждённый claim либо открыть другой authorised scope.'),
+ h2('Что передаётся вместе с неизвестностью'),
+ p('Хорошая передача не оставляет получателю пустой экран. Она даёт точное имя вопроса, даты, source boundary и перечень утверждений, которые пока нельзя делать. Этого достаточно, чтобы будущий scope решил, нужен ли вообще сбор данных. Нельзя добавлять к hand-off предполагаемую причину, потому что она начнёт направлять поиск. Нельзя добавлять готовый verdict, потому что тогда сбор превратится в подтверждение заранее выбранного ответа.'),
+ p('Для корректировки важен разрыв между ошибкой и следствием. Даже если однажды обнаружится неверный claim, из него не следует, что нужно менять текст, публиковать заметку или оценивать автора. Возможно, claim был ограничен версией; возможно, аудитория не может применить исправление; возможно, источник сам неоднозначен. Новый scope обязан выбирать действие по доступному evidence и риску. P118 не создаёт этот выбор и не подменяет его заранее написанной петлёй revision.'),
+ p('Полевой документ должен быть устойчив к смене получателя. Если hand-off зависит от конкретного имени, команды или внутренней очереди, он быстро становится историей о людях и требует дополнительных прав. Здесь получатель не назван. Это не недостаток коммуникации: так вопрос можно передать в надлежащий контекст, не создавая ложного обязательства человеку, который не видел исходных материалов и не соглашался их разбирать.'),
+ p('Отдельно стоит различать correction и deletion. Удаление неподтверждённой фразы может быть правильным действием, но в P118 оно не произошло и не рекомендуется как результат. Пока нет реального текста и входов, нельзя определить, что именно требует изменения. Fixed evaluator охраняет именно эту границу: он не правит строку и не выбирает форму публикации. Его stop — сигнал, что вопрос нельзя завершить данными, которых никто не предоставил.'),
+ p('Такой режим не делает field lens бесполезным. Он снижает стоимость будущего разбирательства: новый owner не тратит время на развенчание вымышленной chronology, не ищет несуществующий feedback и не объясняет, почему promised correction не выпущена. Вместо этого он получает маленький, точный контракт неизвестности. Если работа будет авторизована, этот контракт можно заменить доказательствами; если нет, он остаётся честным и не создаёт долгов перед людьми или production.'),
+ h2('Ограничения и следующий шаг'),
+ p('P118 field не является персональной оценкой, development plan, review log, publication record, correction record, редакционным календарём или production report. Он не утверждает, что текст требует или не требует изменения. Его sources не подтверждают действие конкретного человека. Его SVG не является журналом процесса. The fixture проверяет только известные literals и fail-closed statuses; он не создаёт feedback и не измеряет качественный эффект.'),
+ p('Следующий шаг допустим лишь там, где новый authorised scope назовёт вопрос, owner, разрешённые inputs, правила защиты данных, метод revision и возможный отказ от correction. Этот scope может принять или закрыть вопрос без действия. Он не должен задним числом приписывать P118 review или publishing history. Завершение P118 остаётся ограниченным: synthetic-plan-hand-off и productionEffect: not-attempted.')
+], fieldRefs);
+
+export const revisions = deepFreeze([practice, mechanism, field]);
+export function verifyRevisionsAgainstFixture() {
+ const fixture = runAuthorManifestoFixture();
+ const articleChecks = revisions.map((item) => { const text = bodyText(item.contentHtml); return text.length >= 10000 && text.length <= 13000 && /(цен[аы]|стоимост|дорог)/i.test(text.slice(0, 1500)) && /