На встрече по итогам года легко собрать гладкую историю: сначала было решение, потом появился хороший сигнал, значит надо повторить путь. Проблема в том, что такой рассказ прячет неудобные альтернативы, цену и неизвестные. Цена ошибки — следующий цикл получает не материал для выбора, а подтверждение уже любимого объяснения; спор вспыхивает, когда старый рецепт сталкивается с новой границей.
Полевой review должен быть короче презентации и строже пересказа. Он не ищет виноватого и не ранжирует людей. Его задача — пройти одну запись по кругу: прочитать decision, найти альтернативу, назвать cost, отделить observation, сформулировать unknown и проверить comparison boundary. Если хотя бы один узел пуст, итогом является repair request. Если все заполнены, допускается только synthetic review hand-off, а не production decision.
Полевой контекст без реального поля
Ниже «полевой» означает упражнение над fixed literals, а не доступ к настоящим системам. Мы не читаем логи, ticket, ADR, метрики, документы, чаты или incident record. Тем самым модель не может случайно сделать вывод о реальной компании, команде или человеке. Она проверяет лишь форму отчёта: оставил ли автор путь от выбора к наблюдению и признал ли границу знания.
Такая искусственная среда полезна для репетиции review. В ней можно безопасно увидеть типичную ошибку: удобный факт после изменения превращается в эффект. Но учебный результат нельзя переносить в отчёт о производстве. Фиксированный hand-off означает только, что карточку допустимо обсудить человеком по её ограниченному содержанию.
| Проверяемый узел | Что спрашивает reviewer | Допустимый ответ | Маршрут |
|---|---|---|---|
| Decision | какой путь выбран? | конкретное действие в записи | дальше к alternatives |
| Alternatives | что не выбрали? | два реальных для literal варианта | дальше к cost |
| Cost | чем заплатили? | явный расход или риск | дальше к observation |
| Observation | какой факт увидели? | описание без causal verb | дальше к unknown |
| Unknown | чего ещё не знаем? | первый непокрытый вопрос | дальше к boundary |
| Boundary | что сравнили? | точное ограничение набора | hand-off или repair |
Исполняемая карточка review
import {
createFixedYearSynthesisInput,
inspectYearSynthesis,
prepareSyntheticYearReviewHandOff,
} from './upgrade-2025-12.mjs';
const draft = createFixedYearSynthesisInput('missing-traceability-v1');
const report = inspectYearSynthesis(draft);
console.log(report.handoff);
// 'stop-and-repair-boundary'
console.log(prepareSyntheticYearReviewHandOff(report).status);
// 'stop-and-repair-boundary'В этом случае отсутствуют decision, cost, observation, unknown и boundary; timestamp не проходит ограниченный RFC 3339 UTC-pattern. Функция не исправляет карточку за автора и не выводит вероятную причину. Она возвращает набор конкретных gaps. Второй вызов сохраняет остановку: статус нельзя превратить в положительный hand-off только потому, что код был запущен без ошибки.
Как провести review за двадцать минут
- Выберите одну fixed карточку. Не открывайте рядом календарь успехов и не пытайтесь покрыть весь год за один проход.
- Прочитайте decision вслух. Если фраза описывает только результат, а не выбор, верните её на переписывание.
- Попросите альтернативы. Сравнивайте только варианты, доступные в момент записи; не добавляйте невозможный идеал задним числом.
- Проверьте cost. Найдите, что стало длиннее, сложнее, рискованнее или осталось непокрытым.
- Заморозьте observation. Замените оценочные глаголы на наблюдаемый факт и зафиксируйте окно чтения.
- Спросите «что могло быть иначе?» Ответ формирует unknown и comparison boundary; без них оформите repair request.
- Передайте узкий исход. В synthetic модели это только hand-off для human review; никаких запусков, оценок или решений вне памяти.
Counterfactual вопрос не требует придумать другой год
Частая защита гладкой истории: «нельзя же узнать, что было бы иначе». Именно поэтому годовой текст не должен обещать, что знает. Counterfactual review не заставляет строить альтернативную реальность. Он проверяет, есть ли граница у фразы. Если границы нет, неизвестное записывают как unknown; если нужен ответ, для него проектируют отдельное сравнение, а не добавляют уверенности в ретроспективный абзац.
В fixed карточке вопрос звучит скромно: «какой внешний фактор мог бы дать то же observation?» В реальной работе он может потребовать владельца методики, этической оценки данных, окна измерения и времени. Этот пакет ничего из этого не предоставляет. Он тренирует дисциплину не объявлять отсутствующий контрфакт скрытым доказательством.
Почему review не является судом
Если reviewer начинает искать автора ошибки, поля быстро становятся декоративными. Alternative превращается в оправдание, cost скрывается, unknown воспринимают как слабость. У полевого прохода другая единица анализа — сама запись. Мы спрашиваем, какое поле не позволяет повторить reasoning, и возвращаем только его. Это снижает риск спорить о мотивах вместо того, чтобы проверить технический след решения.
Публичный RFC 7282 здесь полезен ограниченно: он показывает, что инженерный выбор живёт среди trade-off, а возражение может содержать реальную техническую проблему. Мы не переносим правила IETF в другую среду. Мы берём более малое правило: если alternative или cost нельзя сформулировать, текст не готов к итоговому утверждению.
Наблюдение должно привести к следующему вопросу
NIST SP 800-61r3 связывает lessons learned с анализом, приоритизацией и последующим улучшением. В нашем review это не шаблон incident response и не заявка на security-процесс. Аналогия только в направлении движения: observation возвращается в вопрос, который можно проверить позже. Например, «какой фактор за пределами literal не учтён?» — это следующий запрос; «решение дало эффект» — уже результат, которого запись не умеет обосновать.
Удобная карточка имеет ровно один следующий запрос. Если их десять, значит timeline пытается заменить исследование. Если запросов нет, скорее всего unknown был вырезан ради финала. В обоих случаях редактору полезнее сократить историю до одной точки, чем добавлять ещё один список достижений.
Как вернуть карточку без пустого замечания
Комментарий «не хватает контекста» не помогает исправить запись: непонятно, нужно ли вернуть альтернативу, цену, окно observation или сравнение. Repair request должен называть один разрыв и ожидаемое дополнение. Например: «оставь в строке отвергнутый вариант, который был доступен в момент выбора»; «замени вывод об эффекте на факт и добавь unknown»; «опиши, какие именно два fixed состояния сопоставлены».
Такой маршрут не требует соглашаться с выбранным решением. Reviewer может считать альтернативу сильнее, но сначала обязан проверить, что сама карточка различает choice и result. Только затем начинается предметный спор о требованиях. Это делает несогласие техническим: участники обсуждают пропущенное поле, уровень утверждения или границу сравнения, а не характер автора годового текста.
Два вида несогласия не стоит смешивать
Первый вид — несогласие с данными записи. Например, observation неточно описан или comparison boundary шире, чем позволяет набор. Такой случай возвращает карточку на исправление. Второй — несогласие с trade-off: все поля есть, но другой вариант кажется приемлемее. Его не надо маскировать как ошибку в фактах. Он остаётся отдельной заметкой рядом с alternatives и может стать темой следующего решения.
Разделение экономит время в review. Когда сначала чинят traceability, спор о стратегии не разрастается вокруг неверно названного эффекта. Когда запись полна, стратегическое возражение можно сохранить без требования переписать прошлое. В обоих случаях annual synthesis остаётся инструментом чтения решений, а не сценой для окончательного вердикта.
Стоимость самого review
У review тоже есть cost: нужно время на чтение, неудобно оставлять часть выводов открытыми, а карточка с alternatives длиннее красивого тезиса. Этот расход оправдан не обещанием эффективности, а качеством следующего разговора. Участники обсуждают конкретное поле: какой вариант не назван, где потеряна граница, какой факт ещё не наблюдался. Это намного дешевле, чем спорить о том, кто помнит год правильнее.
Не нужно проводить такой проход для каждого мелкого изменения. Подходите к нему там, где годовой текст пытается связать решение с результатом или предлагает повторить путь. Для коротких заметок достаточно decision и границы. Полный круг с alternatives, cost и unknown нужен ровно там, где риск ложного причинного вывода дороже времени reviewer-а.
Граница и следующий шаг
Фабрика и fixture существуют только в памяти процесса. В данных нет реальных идентификаторов, организаций, имён, интеграций, производственных значений или claims об эффекте. Все timestamps, ADR-подобные решения, observations и costs — fixed synthetic literals. После проверки не создаётся файл, HTTP request, задача, метрика, Git-изменение или external message.
Проверьте на своей учебной карточке последний абзац. Есть ли там observation, который вы уже назвали причиной? Верните рядом alternatives, cost, unknown и comparison boundary. Если одно поле честно пустое, оставьте stop-and-repair-boundary. Если заполнены все шесть, отправьте только synthetic hand-off на человеческое чтение; реальный вывод требует отдельного контекста и метода, которого здесь нет.
Проверяемые источники
- RFC 3339, Date and Time on the Internet: Timestamps — версия: RFC 3339, July 2002, immutable RFC text. Раздел 5.6 задаёт форму date-time как full-date, букву T и full-time с часовым offset. В fixed модели это даёт проверяемый синтаксис временной отметки записи. Граница: RFC описывает формат времени, а не причинность решения, смысл метрики или правила годового review.
- RFC 7282, On Consensus — версия: RFC 7282, June 2014, immutable RFC text. Документ называет trade-off неустранимой частью инженерного выбора и отделяет техническое рассмотрение возражения от простого подсчёта голосов. Граница: Это контекст инженерного компромисса в IETF, не готовая процедура для другой организации и не доказательство результата synthetic модели.
- NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management — версия: NIST SP 800-61r3, April 2025, immutable published PDF. В модели документа lessons learned анализируются, приоритизируются и возвращаются в Improvement. Это узкий пример цикла наблюдение → разбор → изменение процесса. Граница: Публикация посвящена cybersecurity incident response; она не предписывает наш формат ADR, не валидирует causal claim и не делает годовой текст доказательством эффекта.