Будущая передача инженерного кейса часто терпит сбой ещё до работы: получателю отдают фразу «доказательства собраны», хотя существует только план обсудить evidence. Цена — потеря времени на поиск несуществующих ADR, метрик, тестов, инцидентов и rollout-записей. Затем команда спорит не о следующем вопросе, а о том, кто должен подтвердить красивый итог, который никогда не был разрешённым входом.
Вторая проблема — назвать такую передачу field report и тем самым добавить ей вес реального наблюдения. Цена — ложная операционная память: future reader может считать, что change уже произошёл и residual risk закрыт. Ничего подобного не заявляется. Это план/сценарий на 2026-12 с source boundary 2026-07-31; декабрь ещё не наступил. Ни проектный кейс, ни ADR, ни benchmark, ни метрика, ни тест, ни инцидент, ни change, ни rollout, ни результат не произошли в этом материале.
Field здесь означает адресата hand-off, а не полевое наблюдение
Слово field в названии удобно прочитать как «практический опыт». Здесь оно обозначает только форму передачи между будущими ролями. У отправителя есть fixed synthetic literal, у получателя — граница того, чего ещё нет. Между ними нет реальной системы, задачи в трекере, человека с назначенным дедлайном или production доступа. Это намеренная конструкция: если бы hand-off выглядел как рабочее поручение, он сам стал бы недоказанным событием.
Безопасная карточка передаёт не ответ, а структуру отсутствия. В ней есть дата плана, source boundary, контекст, два варианта, rejected option, сила входа, состояние unavailable-in-example, residual risk, status и nextAction. В ней нет ссылки на dashboard, номера ADR, результата теста, графика метрики, текста incident review или обещания rollout. Получатель не обязан верить автору на слово: он может открыть literal и увидеть, что положительная ветка не шире safe synthetic hand-off.
| Поле | Значение fixed scenario | Чего получатель не должен выводить | Следующее допустимое действие |
|---|---|---|---|
| Время | scenarioDate 2026-12; cutoff 2026-07-31 | что работа уже шла в декабре | сохранить future boundary |
| Варианты | narrow и expanded note; один rejected | что был реальный дизайн-review | уточнить только структуру question |
| Evidence | scenario-only; unavailable-in-example | что есть benchmark, test или metric | при необходимости предложить отдельный contract |
| Output | handoff либо stop; no-system-change | что rollout, change или результат разрешён | передать boundary без исполнения |
Передача начинается с того, что явно отсутствует
Обычная карточка статуса часто перечисляет сделанное. Для будущего synthetic case полезнее начать с отсутствующего: нет production inputs, нет наблюдения, нет решения, нет owner с полномочием на изменение. Это не пустота в документе, а его главный сигнал. Читатель должен увидеть отсутствие раньше, чем увидит красивую схему. Иначе даже аккуратные слова «план» и «сценарий» потеряются рядом с убедительными деталями, которые похожи на реальный кейс.
В fixed literal boundary перечисляет запрещённые поверхности: network, browser, file, environment, clock, secret, telemetry, external tool, customer и production system. Это не обещание изоляции всей редакционной среды. Это контракт конкретного runnable example: функция не обращается к этим поверхностям. По той же причине модель не создаёт ручку очереди и не отправляет уведомление. Safe hand-off — возвращаемый объект в памяти, а не операция над чужим процессом.
Provenance позволяет не путать модель с доказательством
Provenance этой карточки короткий: named fixed case, JSON clone, deep freeze, scenarioDate, cutoff и state evidence. Каждый элемент отвечает на свой вопрос. Имя говорит, что объект можно соотнести с ограниченным набором literals. Clone отделяет выданный экземпляр от константы. Freeze удерживает вложенные поля в текущем запуске. Дата и cutoff держат временную границу. State сообщает, что наблюдение не собрано. Вместе они не доказывают мир; они делают модель честно читаемой.
Не стоит превращать provenance в искусственный audit trail. Не нужны даты, похожие на время инцидента, не нужен ID change, не нужен автор с реальным именем и не нужен снимок якобы существующей панели. Такие детали не дают воспроизводимости, если не было источника. Они дают только поверхность для ложной ссылки. Здесь источники ограничены официальными pinned документами до cutoff и отделены от собственных literals в разделе внизу. Они объясняют слова, но не подтверждают карточку.
Stop должен быть удобнее, чем скрытая эскалация
У сценария четыре опасные границы. stop-undated-scenario-or-cutoff возникает, когда дата плана или cutoff не совпадают с P106. stop-missing-rejected-option не позволяет сделать narrative одновариантным после факта. stop-evidence-stronger-than-input блокирует benchmark claim поверх scenario-only. stop-disallowed-positive-result не пропускает completed case, ADR, metric, test, incident, change или rollout под видом результата. Каждый status содержит nextAction и всегда effect: no-system-change.
Это fail-closed поведение важно для hand-off. Если поле отсутствует, функция не заполняет его удобным дефолтом; если evidence выглядит правдоподобно, функция не присваивает ему доверие; если requested result звучит позитивно, функция не интерпретирует его как план. Статус не эскалирует вопрос во внешний мир. Он возвращает текстовую причину и следующий безопасный шаг. Получатель может исправить literal или оставить работу до появления отдельной власти и источников.
Runnable example передаёт stop, а не притворный результат
import { createFixedPortfolioCase as prepareHandoff, assessFixedPortfolioCase as gateHandoff } from './upgrade-2026-12.mjs';
const incompleteStory = prepareHandoff('missing-rejected-option-v1');
const reply = gateHandoff(incompleteStory);
console.log({ status: reply.status, action: reply.nextAction, production: reply.effect });
// { status: 'stop-missing-rejected-option', action: 'name-the-option-not-carried-forward', production: 'no-system-change' }Этот пример выбирает опасный fixed literal, а не изменяет разрешённый объект на лету. JSON clone создаётся в памяти, после чего deep freeze защищает форму вложенных полей от mutation в процессе. Evaluator не читает реальные варианты и не пытается узнать, почему что-то отвергли. Он проверяет более скромное свойство: у передаваемого narrative должен быть явно назван rejected option. При его отсутствии он возвращает stop, а не домысливает историю.
Вызов не создаёт ADR, не собирает metric, не запускает test, не расследует incident, не вносит change и не инициирует rollout. Он не подключается к network, browser, file system, environment, clock, secrets, telemetry или внешнему инструменту. Это literal runnable example, а не эмулятор production. Его результат можно использовать как проверяемую демонстрацию boundary, но нельзя ссылаться на него как на evidence будущего кейса.
Как передавать synthetic evidence boundary
Получателю полезно получить одну короткую фразу: «Вот fixed scenario на 2026-12; у него source boundary 2026-07-31; evidence только scenario-only и unavailable-in-example; любое усиление claim вернёт stop; положительный исход не шире bounded-review-handoff». Затем нужно приложить concrete nextAction, а не пожелание «провести исследование». В P106 nextAction адресует будущего evidence owner, но не назначает его и не создаёт ему задачу. Разница защищает boundary от скрытого внешнего действия.
Отправитель также должен оставить residual risk рядом с hand-off. Здесь он говорит, что будущему владельцу может понадобиться отдельный evidence contract. Нельзя писать, что контракт уже согласован, что данные будут доступны или что change безопасен. Эти предположения особенно быстро становятся «известным фактом» после нескольких пересказов. Полезнее сохранить риск как открытое условие и дать следующему читателю возможность не продолжать историю, пока он не может легально и технически уточнить входы.
Граница hand-off не является очередью работ
Есть соблазн сделать карточку полезнее, сразу добавив исполнителя, срок и ожидаемый артефакт. Для P106 это был бы незаметный переход от модели к внешней координации. Фраза «владелец подготовит ADR» уже предполагает владельца, будущий ADR и запущенную работу; фраза «проверим метрику после change» предполагает change и набор метрик. Ни одно из этих предположений не находится в fixed input. Поэтому nextAction здесь описывает только класс будущего вопроса, а не чей-то назначенный action.
Такая граница защищает и получателя. Он может увидеть hand-off, не принимая на себя молчаливую обязанность. Он вправе остановиться, запросить полномочия или решить, что отдельный evidence contract не нужен. Документ не считает любой stop задержкой и не измеряет скорость закрытия. Его задача — не продавить продолжение правдоподобием narrative, а оставить выбор будущего пути открытым. Для безопасного planning hand-off это часто более полезно, чем список работ с фиктивной уверенностью.
Нужно различать также техническую возможность и разрешение. Модуль мог бы быть расширен файловым reader или API client, но наличие такой возможности не даёт права читать production данные. Аналогично, будущая команда могла бы создать тест, но это не означает, что тест уже запланирован, согласован или нужен. Текущий literal не хранит этих прав и не делает внешних вызовов. Ровно поэтому его положительный status остаётся передачей boundary, а не переходом к исполнению.
Нумерованные действия перед передачей
- Проверить, что заголовок и первая часть карточки называют план/сценарий на 2026-12 и source boundary 2026-07-31.
- Сверить caseName с named fixed synthetic literal; не подставлять произвольный объект.
- Убедиться, что options содержат два имени и rejected option записан явно.
- Оставить evidence как scenario-only и unavailable-in-example; не добавлять похожие на реальные records.
- Отклонить любой requested positive result, кроме bounded-review-handoff с effect: no-system-change.
- Передать status, reason, boundary, residual risk и nextAction без создания задачи, change или rollout.
Ограничения и следующий шаг
Карточка не заменяет реальный evidence hand-off, потому что в ней нет реального evidence. Она не подтверждает качество будущего решения, безопасность изменения, совместимость вариантов или итог для пользователя. Нельзя использовать её как аргумент в security review, архитектурном совете или release decision. Первичные NIST и RFC в ссылках ниже ограничены терминологией: они опубликованы до cutoff, но не имеют отношения к данному fictional case и не снимают его residual risk.
Следующий шаг — не «довести кейс до результата», а в будущем отдельно решить, нужен ли и возможен ли evidence contract. До этого hand-off безопасно заканчивается в памяти функции. Положительная ветка не меняет мир и прямо несёт effect: no-system-change. Это важнее привлекательного поля «результат»: документ остаётся usable для подготовки, но не производит фиктивную историю о том, что уже было сделано.
Проверяемые источники
- NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments — версия: Revision 1, September 2012, DOI 10.6028/NIST.SP.800-30r1. Первичный источник использован только для словаря риска и ограничения утверждений. Граница: Не является evidence для карточки и не подтверждает реальный hand-off.
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels — версия: BCP 14, March 1997, DOI 10.17487/RFC2119. Первичный RFC использован для аккуратной модальности требований. Граница: Не назначает владельца, action или production change.
- RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words — версия: BCP 14, May 2017, DOI 10.17487/RFC8174. Первичный RFC уточняет применение BCP 14. Граница: Не разрешает называть synthetic status фактом эксплуатации.