В октябре 2026 я бы начал стандарт review с простой поломки процесса: change меняет nullable поле, порядок миграции или обработку ошибки, а обсуждение застревает на названии переменной и длине функции. Контрактный риск остаётся без вопроса. Цена не эстетическая: потребитель получает новое значение раньше адаптера, rollback не назван, а команда позже спорит не о факте, а о том, «кто должен был заметить».
Вторая цена — ложный положительный исход. Фраза «выглядит хорошо» может звучать как решение, хотя у reviewer нет карты consumers, границы изменения и допустимого вывода. Это не отчёт об октябрьских pull request или CI. Ни один review не проводился. Ниже — плановый сценарий на октябрь 2026, источники ограничены 31.07.2026, а максимум результата fixed literal — bounded-review-handoff.
Матрица сначала ограничивает вопрос
Матрица нужна не для оценки человека и не для механического чеклиста. Она вынуждает назвать четыре вещи до комментария: что именно меняется, какой риск следует из этой границы, какое доказательство способно сузить риск и какой вывод пока запрещён. Если строка не помещается в эти четыре колонки, reviewer не обязан сочинять диагноз. Его корректное действие — stop: изменение недостаточно описано для технического вывода.
У решения есть масштаб. Для style-only change достаточно указать локальную читаемость и предложить отдельный cleanup. Для contract migration этого недостаточно: нужны schema delta, карта consumers и заметка о возврате на старую форму. Для operational behavior нужны состояние, failure mode и граница наблюдения; для security boundary — доверенная сторона, правило входа и последствие злоупотребления. Таблица не утверждает, что эти категории покрывают любой проект. Она не позволяет заменить отсутствующее evidence уверенным тоном.
| Риск | Входное evidence | Допустимый вывод | Stop-the-line |
|---|---|---|---|
| contract migration | schema delta; consumer map; rollback note | передать synthetic hand-off | consumer или возврат не назван |
| operational behavior | state transition; failure mode; observation boundary | запросить точное уточнение | следующая ветка состояния неизвестна |
| security boundary | trust boundary; input rule; abuse consequence | эскалировать вопрос владельцу риска | нет модели нарушителя или последствия |
| style-only | локальный фрагмент и причина читаемости | оставить необязательную заметку | стилем закрывают иной риск |
Evidence — не ссылка на ощущение
Полезное evidence можно проверить в пределах обсуждаемой модели. fixed-schema-delta отвечает, какое поле меняет форму. fixed-consumer-map отвечает, кто предполагается получателем. fixed-rollback-note отвечает, какая старая форма должна пережить отмену сценария. Это не артефакты настоящего репозитория и не доказательство работоспособности. Это именованные минимумы, без которых нельзя даже сформулировать вопрос о совместимости.
Важно отделить evidence от вывода. «Вижу три файла» — наблюдение, но не карта consumers. «Есть тест» — факт о названии, но не объяснение failure mode. «Автор уверен» — не технический аргумент. В октябрьском сценарии reviewer записывает связь в явном виде: риск contract migration требует три конкретные позиции; отсутствие хотя бы одной переводит ответ в stop. Так ожидание не прячется в личном опыте самого громкого участника.
Нормативные слова не заменяют контекст
RFC 2119 определяет MUST, SHOULD и MAY для документов, где заранее оговорён уровень требования. RFC 8174 дополнительно уточняет проблему регистров. Из этого не следует, что любой комментарий к коду получает силу стандарта. В плановой матрице слова «обязательно» появляются только у локально названного stop: например, нельзя выводить совместимость, если нет consumer map. Вне этой рамки лучше написать причину и вариант, а не изображать универсальное правило.
Это разграничение защищает и автора change, и reviewer. Автор видит, что ему требуется не «докажи качество», а три именованные границы. Reviewer не обязан расширять задачу до аудита всего продукта. Когда evidence есть, положительная ветка всё равно не означает approval, merge, release или deployment: она лишь разрешает передать фиксированную карточку следующему владельцу будущего планирования.
Буквально исполнимый validator матрицы
import { createFixedReviewCase, createFixedReviewHandOff } from './upgrade-2026-10.mjs';
const input = createFixedReviewCase('decision-evidence-ready-v1');
const result = createFixedReviewHandOff(input);
console.log({ status: result.status, effect: result.effect, risk: result.evidenceMap.risk });
// { status: 'bounded-review-handoff', effect: 'no-system-change', risk: 'contract-migration' }Snippet читает только JSON-cloned и deeply frozen named literal. Он не открывает pull request, не читает diff, CI, сеть, файловую систему, секреты или часы. Его positive result предельно узок: все три строки synthetic matrix присутствуют, поэтому можно передать сценарий как bounded-review-handoff. Он не оценивает реальную реализацию и не даёт разрешения изменять состояние где-либо вне памяти процесса.
Цена evidence зависит от того, когда его запросили
У каждого доказательства есть стоимость подготовки и стоимость чтения. Schema delta удобно просить в начале: автор ещё помнит, что меняет, и может показать форму без исторического рассказа. Consumer map дороже, потому что она требует назвать предел поиска, а не перечислить все сервисы компании. Rollback note ценна не как обещание отмены, а как проверка направленности изменения: можно ли вообще говорить о возврате, если форма уже ушла за необратимую границу. Матрица делает эту стоимость видимой до того, как обсуждение превратится в длинную очередь мелких замечаний.
Не всякое evidence следует требовать в каждом случае. Если изменение действительно style-only и это явно ограничено, запросы про consumers создадут ритуал без пользы. Но симметричная ошибка опаснее: назвать contract migration косметикой, чтобы не собирать карту. Поэтому scope тоже должен быть evidence. Reviewer не обязан принимать «это только рефакторинг» как факт; он может попросить назвать invariant, который allegedly не меняется. Пока invariant не назван, классификация остаётся гипотезой и не открывает positive branch.
Матрица помогает и с асинхронным review. Вместо пяти параллельных вопросов автор получает один список missing items, каждый с назначением. Вместо ответа «добавил тест» reviewer может спросить, какую конкретно неопределённость тест должен был бы убрать. Это не обесценивает тестирование: оно предотвращает ситуацию, где один знакомый артефакт подставляют на место иной модели. Когда связь между evidence и вопросом ясна, комментарии короче, а stop меньше похож на личное недоверие.
Отделить решение о риске от решения о форме
Внутри одного change обычно смешаны два класса решений. Первое — предметное: можно ли считать контрактный переход описанным. Второе — редакторское: читается ли код, уместно ли имя, нужна ли декомпозиция. Оба класса полезны, но у них разная цена ошибки. Редакторская рекомендация может остаться необязательной. Предметная граница требует evidence или stop. Если их свести в один список без меток, сильная проблема легко утонет среди десяти мелких улучшений и получит такой же приоритет, как запятая в сообщении.
Практическое правило плана: один комментарий несёт один тип действия. request-contract-evidence не маскируется под пожелание «может быть, добавить документацию». style-note не получает формулировку, будто без него система сломается. Это не жесткий формат интерфейса review tool; это дисциплина языка. У получателя остаётся возможность не согласиться с классификацией, зато разногласие становится конкретным: спорим о risk class или о completeness, а не о психологическом подтексте.
Как провести плановую сессию
- Назвать один будущий change и одну границу: contract, behavior, security или style-only.
- Записать цену ошибки одним наблюдаемым следствием, не оценкой автора.
- Выбрать строку матрицы и перечислить только required evidence для неё.
- Для каждой позиции указать, какой вопрос она снимает, а какой оставляет открытым.
- Если хотя бы один required input отсутствует, вернуть precise stop без догадки о причине.
- Если fixed literal полный, сформировать только synthetic hand-off для следующего обсуждения.
Границы стандарта и следующий шаг
Матрица не заменяет дизайн-документ, threat model, тестирование, эксплуатационное наблюдение или полномочия владельца продукта. Она также не назначает единственный набор risks для любой архитектуры. Её ограниченная цель — не позволить style discussion имитировать проверку контракта, миграции и эксплуатации. Если change действительно широк, честный результат — разбить вопрос или остановить его до появления минимальной модели, а не расширять список замечаний.
Следующий шаг для октябрьского плана — выбрать один нейтральный учебный contract scenario, заполнить матрицу без ссылок на настоящие системы и проверить, что каждый positive result остаётся hand-off only. Лишь после отдельного решения команды можно обсуждать реальные инструменты и policy. Пока такого решения нет, отсутствие evidence должно оставаться видимым и не компенсироваться доброжелательной формулировкой.
Проверяемые источники
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels — версия: BCP 14, March 1997, DOI 10.17487/RFC2119. Источник задаёт узкое значение терминов MUST, SHOULD и MAY в документе с оговорёнными правилами интерпретации. Граница: RFC не является политикой review, не создаёт организационную обязанность и не описывает этот сценарий.
- RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words — версия: BCP 14, May 2017, DOI 10.17487/RFC8174. Источник уточняет трактовку прописных ключевых слов BCP 14. Граница: Он не превращает комментарий или fixed literal в нормативное требование проекта.
- 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 используется как внешний vocabulary практик secure software development и рисков уязвимостей. Граница: Документ не подтверждает проверку кода, CI или состояние конкретной организации.