Сценарий на декабрь 2026 начинается с неприятной редакторской проблемы: инженерный кейс часто пишут после того, как нужен убедительный вывод, и тогда контекст подгоняют под финал. Цена такой записи — не только неточный текст. Читатель может принять отобранные детали за историю проекта, решить, что ADR, тест, benchmark или rollout уже были, и опереться на несуществующее основание для следующего действия.
Вторая проблема — заменить путь «проблема → варианты → решение → доказательство → residual risk» гладким рассказом о победе. Цена подмены выше, чем спор о формулировке: пропадает отвергнутый вариант, причина выбора становится недоступной, а отсутствие evidence маскируется словом «результат». Материал не описывает внедрение. Это прямо обозначенный план/сценарий на 2026-12 с source boundary 2026-07-31, не отчёт о проекте. В нём не происходили ни кейс, ни ADR, ни метрика, ни тест, ни инцидент, ни change, ни rollout.
Case narrative — это маршрут проверки, а не жанр саморекламы
Здесь используется один named fixed synthetic case: named-fixed-synthetic-portfolio-case. Он существует только как literal в памяти модуля. Имена narrow-evidence-note и expanded-evidence-note не обозначают репозитории, команды, сервисы или реальные документы. Они нужны, чтобы у структуры были различимые варианты. Такая бедная модель полезнее правдоподобной декорации: она не позволяет читателю достроить отсутствующую производственную историю.
Структура case narrative не обязана вести к успеху. Контекст отвечает, какая именно проблема рассматривается и какую цену ошибки надо удержать. Варианты показывают пространство до сужения. Решение в будущем плане — лишь правило, по которому кто-то позже сможет выбрать форму работы; это не принятое решение. Evidence описывает силу входа и допустимую силу утверждения. Residual risk фиксирует остаток, который нельзя стереть хорошим изложением. Если один слой пропущен, текст не становится короче и яснее: он начинает притворяться тем, чего в нём нет.
| Поле | Что допустимо в сценарии | Что запрещено заявлять | Проверка границы |
|---|---|---|---|
| Контекст | одна редакторская проблема и цена её ошибки | существование конкретного проекта или инцидента | пометка synthetic и будущая дата |
| Варианты | два named literals и один явно rejected option | что варианты реально оценивали | rejected option должен быть назван |
| Решение | planned-structure-only | утверждённый ADR или выбор | результат не шире hand-off |
| Evidence | scenario-only, fixed-plan-brief, unavailable-in-example | benchmark, metric, test или наблюдение | claimStrength равен inputStrength |
| Residual risk | следующий открытый риск и будущий владелец evidence | что риск снят или rollout разрешён | effect остаётся no-system-change |
Контекст начинается с цены, но не с легенды
Контекст должен быть узким. В synthetic модели проблема не «команда плохо документирует решения», а «будущий читатель может принять плановую форму narrative за доказательство уже состоявшегося результата». Цена — ложная память: позднее появляется ссылка на якобы выполненный тест или на якобы принятую архитектурную запись, а её нельзя предъявить. Такая формулировка не требует придумать пользователей, сроки, бюджет и технику. Она даёт проверяемую границу именно для текста.
Полезно отделять цену ошибки от размера выгоды. Цена отвечает, что будет испорчено, если утверждение окажется лишним: доверие к источнику, возможность пересмотреть решение, время следующего владельца. Она не сообщает, что будущая работа окупится, ускорится или снизит число ошибок. Пока нет реальных входов, такие обещания сильнее модели. Поэтому в первом абзаце этой статьи названа цена ложного основания, а не прогноз эффекта.
Варианты нужны, чтобы решение было обратимым
В сценарии имеются два варианта формы: narrow-evidence-note и expanded-evidence-note. Первый оставляет только границу входов и следующий вопрос. Второй добавил бы правдоподобные детали, которые нечем проверить. Literal заранее помечает второй как rejectedOption, но не потому, что он хуже в реальной редакции. Это учебное правило модели: если rejected option не назван, evaluator возвращает stop-missing-rejected-option. Он не подставляет вариант по умолчанию.
Отклонённый вариант важен не для драматургии. Он показывает, какой соблазн сознательно не был превращён в факт. В реальном будущем кейсе варианты могут быть другими, их число может вырасти, а основания потребуют отдельных источников. Этого сейчас нет. Нельзя написать, что expanded note отвергли на review, потому что review не происходил. Корректнее сказать: фиксированный literal задаёт такую ветку, чтобы проверить, что структура не потеряет альтернативу при передаче.
Решение в плане — это только форма будущего вопроса
Слово «решение» особенно опасно: оно легко звучит как готовый ADR. Здесь decision: planned-structure-only означает ровно обратное. Модель предлагает порядок полей, который можно передать будущему владельцу evidence. Она не выбирает технологию, не меняет код, не назначает автора и не подтверждает приоритет. При желании назвать это decision нужно одновременно назвать отсутствие полномочий и отсутствующие inputs; без этих слов читатель увидит утверждение, которого literal не содержит.
Такое ограничение не обесценивает narrative. Напротив, оно даёт будущему обсуждению место для изменения. Если появится другой вариант, его можно добавить до отдельного разрешённого evidence contract. Если риск окажется важнее, его можно вынести в критерий. Если источник не относится к вопросу, его можно убрать без переписывания легенды о результате. Обратимость исчезает, когда рассказ уже пообещал, что «мы решили и доказали».
Evidence должен быть слабым ровно настолько, насколько слаб вход
У synthetic case вход имеет силу scenario-only. Единственная запись — fixed-plan-brief, состояние — unavailable-in-example. Поэтому claimStrength обязан быть тем же scenario-only. Это не шкала качества и не оценка вероятности. Это предохранитель от ретроспективной подмены: текст, основанный на плановом literal, не может вдруг получить статус «benchmark confirmed» только потому, что такой вывод выглядит убедительнее.
Evaluator сравнивает эти поля до разрешения положительной ветки. При несоответствии он возвращает stop-evidence-stronger-than-input. Stop не сообщает, что будущий benchmark невозможен; он сообщает, что его нельзя утверждать на основании этого входа. Иными словами, это проверка происхождения claim, а не измерение самой системы. В коде нет сборщика метрик, клиента тестов, доступа к папке, сети или календарю. Есть только фиксированная схема, которую можно прочитать целиком.
Runnable literal показывает форму, не исполняет проект
import { createFixedPortfolioCase as makePlan, assessFixedPortfolioCase as assessPlan } from './upgrade-2026-12.mjs';
const decemberPlan = makePlan('portfolio-case-plan-v1');
const handoff = assessPlan(decemberPlan);
console.log({ state: handoff.status, effect: handoff.effect, next: handoff.nextAction });
// { state: 'bounded-review-handoff', effect: 'no-system-change', next: 'hand-the-synthetic-boundary-to-a-future-evidence-owner' }Пример запускается локально как импорт этого модуля и работает лишь с named fixed in-memory literal. Factory делает JSON clone, затем deep freeze рекурсивно замораживает объект; это предотвращает незаметную замену вложенного evidence после получения экземпляра. Freeze не является защитой production-системы и не доказывает истинность текста. Он нужен для узкого свойства примера: одни и те же literals дают один и тот же ограниченный status.
Ни положительная, ни stop-ветка не имеют побочного эффекта. Они не открывают browser, не читают файл, не используют environment, часы, секреты, telemetry или внешние инструменты. В частности, нет вызова, который создаёт ADR, запускает benchmark, собирает метрику, исполняет тест или меняет rollout. У единственной разрешённой положительной ветки status: bounded-review-handoff и effect: no-system-change. Это safe hand-off будущего вопроса, не результат.
Residual risk нельзя прятать в финальном абзаце
В fixed case residual risk назван явно: будущему владельцу может понадобиться отдельный evidence contract. Это не риск конкретной инфраструктуры и не прогноз инцидента. Он указывает на незакрытую логическую работу: определить допустимые реальные inputs, метод получения и правило интерпретации. Пока такого контракта нет, никакая аккуратная проза не превращает scenario-only в observed proof. Поэтому residual risk расположен в данных, а не оставлен как настроение автора.
Не следует компенсировать этот пробел очередью вымышленных артефактов. Нельзя приписать плану будущий ADR, обещанный benchmark, тестовый протокол, метрику или incident review. Даже фраза «после rollout проверим» делает rollout частью истории, хотя он не начинался. Допустимый следующий шаг скромнее: передать boundary владельцу, который в будущем и при отдельном разрешении сможет решить, нужен ли evidence contract. Сам владелец здесь не назначается.
Нумерованный маршрут для будущего сценария
- В первой строке пометить материал как план/сценарий на 2026-12 и указать source boundary 2026-07-31.
- Сформулировать один synthetic контекст и цену неверного утверждения без названий реальных систем.
- Назвать как минимум два fixed варианта и явно отметить вариант, который не переносится дальше.
- Записать planned structure вместо решения, ADR или рекомендации.
- Сопоставить силу каждого claim с силой входа; при усилении вернуть stop, а не красивый вывод.
- Оставить residual risk и передать только safe hand-off с effect: no-system-change.
Ограничения и следующий шаг
Эта статья не даёт шаблон для публикации реального postmortem и не заменяет архитектурное, правовое, security или эксплуатационное рассмотрение. NIST и RFC ниже используются лишь как pinned первичные источники терминологии риска и силы нормативных слов. Они не подтверждают существование этого synthetic case, не задают его варианты и не разрешают считать plan фактом. Все поля модели — редакционные literals, действующие только в границе P106.
Следующий шаг возможен только в будущем: получатель safe hand-off может сформулировать отдельный evidence contract и получить необходимые полномочия. До этого корректный результат не расширяется. Нельзя переименовать hand-off в completed case задним числом, потому что это уничтожит provenance. Для декабря 2026 честная точка остановки уже полезна: она оставляет карту вопроса, но не изображает путь, который ещё не пройден.
Проверяемые источники
- NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments — версия: Revision 1, September 2012, DOI 10.6028/NIST.SP.800-30r1. Первичный источник использован только для терминов риска и неопределённости. Граница: Не подтверждает synthetic case, результат, ADR, benchmark или rollout.
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels — версия: BCP 14, March 1997, DOI 10.17487/RFC2119. Первичный RFC использован для различения силы требований в формулировках. Граница: Не создаёт решение и не делает сценарий проектным фактом.
- RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words — версия: BCP 14, May 2017, DOI 10.17487/RFC8174. Первичный RFC уточняет контекст BCP 14. Граница: Не доказывает evidence и не разрешает положительный production outcome.