Плановый hand-off ломается, когда в него передают итог вместо вопроса: «изменение безопасно», «ошибка обработана», «можно продолжать». Получатель не видит, на чём держится фраза, и вынужден либо поверить, либо начинать разбор заново. Для contract migration цена особенно заметна: missing consumer или rollback note исчезает в дружелюбном summary, а будущая работа получает иллюзию закрытой границы.
Ниже не полевой отчёт и не реконструкция настоящего review. На 31.07.2026 октябрь ещё впереди, поэтому это bounded synthetic scenario: fixed literals, заранее названные stops и один положительный исход — bounded-review-handoff. Он не читает PR, CI, diff, repository, сеть, файлы или secrets; не означает approval, merge, release, deploy, publication и не утверждает, что какая-либо команда уже изменила код.
Карточка hand-off должна сохранять неопределённость
Минимальная карточка содержит ID учебного change, risk class, decision, список evidence, текущий статус, следующий вопрос и явную границу. В нашем literal ID fixed-nullable-discount-contract — не имя продукта и не ссылка на задачу. Он нужен, чтобы в одном сценарии не перепутать форму изменения с другим примером. Такие искусственные имена полезнее реалистичных псевдо-артефактов: они не создают впечатление, будто перед нами настоящий pull request или incident.
Статус говорит не «плохо» и не «хорошо», а какая операция доступна для модели. stop-insufficient-evidence означает: конкретный input не содержит named позиции, поэтому сильный вывод запрещён. bounded-review-handoff означает: минимальная карточка полна по собственному fixed rule и может быть передана дальше как плановый вопрос. Ни один статус не подтверждает реализацию, тесты, доступность сервиса или результат будущего обсуждения.
| Поле | Пример fixed literal | Зачем нужно | Чего не доказывает |
|---|---|---|---|
| change | fixed-nullable-discount-contract | удерживает один учебный предмет | наличие кода или diff |
| risk | contract-migration | выбирает набор вопросов | severity или ущерб |
| evidence | schema delta; consumer map; rollback note | делает пробел видимым | совместимость consumers |
| status | stop / synthetic hand-off | ограничивает следующий шаг | approval или merge |
| boundary | in-memory fixed literal | исключает внешний эффект | результат production проверки |
Один bounded scenario без имитации истории
Представим только учебную конструкцию: поле скидки становится nullable, и мы хотим подготовить вопрос о contract migration. Это не сообщение о том, что такая миграция существует или запланирована. fixed-schema-delta называет форму вопроса; fixed-consumer-map и fixed-rollback-note удерживают два обязательных пробела. Литерал не содержит автора, дату PR, ссылку на CI, номер задачи, клиента, длительность или результат — именно чтобы не спутать модель с историческим фактом.
Если consumer map отсутствует, hand-off не должен дорисовывать потребителя «по опыту». Правильный ответ — назвать missing item и вернуть его владельцу будущего обсуждения. Если есть карта, но conclusion содержит approval word, validator тоже останавливается. Это важно: полнота учебной карточки даёт право сформулировать следующий вопрос, но не право принимать решение за организацию. Положительный статус намеренно менее впечатляющий, чем «готово», зато его граница воспроизводима.
Literal, который допускает только hand-off
import { createFixedReviewCase, createFixedReviewHandOff } from './upgrade-2026-10.mjs';
const planned = createFixedReviewCase('approval-word-v1');
const result = createFixedReviewHandOff(planned);
console.log({ status: result.status, reason: result.reason, next: result.nextAction });
// { status: 'stop-disallowed-positive-conclusion', reason: 'positive-branch-is-hand-off-only', next: 'use-bounded-review-handoff' }Этот пример специально берёт literal с недопустимой фразой approve-and-merge. Он не проверяет существование merge и не пытается что-либо отменить. JSON clone создаётся в памяти, рекурсивный freeze не даёт сменить input через shared reference, а validator возвращает deterministic stop. Так текст можно проверить буквально: даже при полном наборе evidence код не допускает глагол, который притворяется решением о будущем change.
Почему карточка короче review-резюме
Резюме часто становится складом контекста: туда попадают ссылки, даты, фрагменты обсуждения и пересказ решений. Для bounded hand-off это вредно. Чем больше неразмеченного материала, тем проще принять его за evidence, хотя он не отвечает ни на один точный вопрос. Карточка намеренно хранит только минимальную связку: named change, risk, required evidence, current status, next question и boundary. Остальное либо относится к будущей реальной работе, либо должно получить собственный тип и владельца.
Краткость не означает, что ответ можно написать без причин. Вместо «нужна карта consumers» hand-off должен сказать, что без неё нельзя определить охват изменения формы. Вместо «не approve» — что положительный исход сценария ограничен передачей вопроса. Так получатель получает не длинную запись журнала, а воспроизводимую причинную цепочку. Если он не согласен, можно оспорить одно звено: risk class, evidence requirement или границу вывода. Это лучше, чем спорить с общим ощущением «review был строгим».
Контроль формулировок до передачи
Полезно отдельно искать глаголы, которые повышают силу вывода: approve, merge, release, deploy, publish, verified, safe. В настоящем процессе отдельное слово может быть допустимо при наличии полномочий и фактов. В synthetic сценарии оно запрещено, потому что создаёт ложную историю будущего. Validator показывает это на fixed input: даже полный набор contract evidence останавливается, если conclusion пытается назвать approval. Такая проверка не редактирует текст автоматически; она удерживает semantic boundary заметной.
Тем же способом надо проверять слова о внешнем наблюдении. «Лог показал», «CI прошёл», «клиент получил» выглядят как конкретика, но в октябрьской модели они были бы выдуманными production facts. Вместо них корректны конструкции «сценарий потребовал бы evidence», «будущий владелец уточнит», «fixed literal возвращает stop». Читатель не теряет практичность: он получает способ сформулировать вопрос, не делая вид, что доступ к данным уже существовал.
Что останется после hand-off
Даже успешный synthetic hand-off оставляет работу. Нужно определить, какой реальный артефакт мог бы стать evidence, кто имеет право его читать, как он хранится и что делает команда при противоречивых данных. Нужно также решить, какие consumers существенны, а какой rollback возможен. Эти вопросы не дефект сценария. Они и есть граница между обучающей моделью и будущим процессом. Попытка заполнить её правдоподобными деталями сделала бы текст похожим на report, но менее честным.
Передача вопроса другому владельцу
Хороший hand-off короток, но не телеграфен. Он говорит: «Рассматривается fixed contract scenario; риск — совместимость формы; присутствуют эти named evidence; вывод ограничен synthetic hand-off; нужен владелец, который уточнит consumer boundary». Он не говорит: «исправьте срочно», потому что urgency не следует из fixed literal. Он не говорит: «всё проверено», потому что проверка мира не выполнялась. Он не скрывает недостаток за ссылкой на внутренний процесс, которого читатель не видит.
Разделение ролей особенно важно в зрелой команде. Reviewer удерживает связь между риском и evidence. Автор будущего change уточняет намерение и границы. Владелец контракта решает, какие потребители существенны. Владелец эксплуатации отвечает на наблюдаемость поведения, а не на смысл schema. Такая декомпозиция не отменяет сотрудничество; она снижает цену ситуации, где каждый считает, что другой уже сделал необходимый вывод.
Почему источник не превращается в policy
NIST SSDF описывает рекомендации для снижения риска уязвимостей в жизненном цикле разработки и подчёркивает интеграцию практик в разные SDLC. Для этого сценария его роль ограничена: он оправдывает разговор о системном risk vocabulary, а не конкретный состав карточки. RFC 2119 объясняет, почему слова MUST и SHOULD требуют объявленного контекста. Ни один из документов не выдает наш fixed hand-off за обязательную корпоративную процедуру и не подтверждает качество будущего code review.
Эта граница нужна и для обучения. Когда external source используют как печать «правильно», команда перестаёт видеть собственные допущения: какие contracts у неё есть, кто владеет rollback и что вообще может быть evidence. Более честная практика — назвать, какую терминологию источник даёт, а затем отдельно зафиксировать проектное правило. Если правило меняется, меняется сценарий и его fixture, а не смысл старого документа.
Порядок для октябрьского synthetic hand-off
- Выбрать один anonymized fixed scenario без реального ID, diff или истории.
- Сформулировать риск как границу смысла, а не как оценку автора.
- Приложить минимальные named evidence и назвать отсутствующие позиции.
- Пропустить literal через fail-closed validator; не исправлять результат вручную.
- Отправить следующий вопрос владельцу границы, не включив слова approval, merge, release или deploy.
- Оставить boundary в карточке, чтобы читатель не принял модель за факт работы системы.
Границы field-сценария и следующий шаг
Этот сценарий не заменяет review tool, policy, audit trail, change management или security assessment. Он не отвечает, сколько reviewers нужно, какой срок реакции разумен и когда допустима публикация. Не следует применять его как шаблон для настоящего потока без отдельного решения о данных, доступах и владельцах. Его единственная практическая проверка — может ли формулировка пережить отсутствие реального контекста, не начав выдавать предположение за доказательство.
Следующий шаг — в октябрьском плане обсудить карточку с командой на полностью synthetic case и попытаться намеренно сломать её: убрать consumer map, подменить risk style note, добавить approval word. Если каждый случай останавливается предсказуемо, можно отдельно решить, какие реальные артефакты вообще допустимо включать в будущий процесс. До такого решения остаёмся в границе планирования, а не имитируем field report.
Проверяемые источники
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1 — версия: February 2022, NIST SP 800-218, DOI 10.6028/NIST.SP.800-218. NIST SSDF используется только как источник терминов о практиках secure software development в жизненном цикле. Граница: Он не является policy этой команды и не подтверждает ни один hand-off или review result.
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels — версия: BCP 14, March 1997, DOI 10.17487/RFC2119. RFC объясняет смысл нормативных слов в спецификационном контексте. Граница: Он не делает synthetic status фактом approval, merge или публикации.
- RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words — версия: BCP 14, May 2017, DOI 10.17487/RFC8174. RFC фиксирует уточнение BCP 14 для прописных ключевых слов. Граница: Источник не определяет реальный процесс code review или полномочия его участников.