У проекта может быть полный набор документов и всё равно не быть ответа, который можно безопасно передать разработке.

В Source Map пробелы выглядят менее впечатляюще, чем готовые строки. Например, документация говорит про exponential backoff, но не задаёт параметры retry policy. Формально материал есть. Практического правила, по которому можно написать проверку, нет.

Самая опасная реакция — позволить агенту заполнить пропуск правдоподобным значением. Так появляется спецификация, которая нигде не была принята. Она выглядит лучше, чем UNKNOWN, но хуже работает в эксплуатации: никто не знает, какое решение пересматривать, когда появится уточнение.

Я разделяю три состояния:

1. Известно. Есть источник, владелец и проверяемое решение.
2. Противоречит. Есть несколько источников, и конфликт вынесен отдельным вопросом.
3. UNKNOWN. Нужного правила нет или его нельзя вывести из доступных материалов.

У каждого состояния должен быть следующий шаг. Для UNKNOWN это не «попросить агента подумать ещё». Это указать, кому задать вопрос, какую часть системы он затрагивает и какая проверка появится после ответа.

Такой формат полезен и при приёмке. Пока вопрос открыт, зелёный технический тест не может считаться доказательством требования. После решения проверка получает основание, владельца и границу применимости.

UNKNOWN не означает, что работа остановлена. Он показывает, где работа ещё не стала решением.

Не начинайте требование со слов «система должна».

Сначала ответьте на три вопроса:
— кто действует;
— в какой ситуации;
— что он пытается изменить.

«Система должна показывать статус заявки» почти ничего не объясняет.

«Оператор перед звонком клиенту проверяет, можно ли продолжить обработку заявки» уже показывает участника, момент и решение, которое ему нужно принять.

Техническое поведение можно описать следующим шагом. Сначала нужен смысл действия.

На этой неделе каждый день будем разбирать по одному простому вопросу, который делает требование проверяемым.

CRM показывает APPROVED. Сервис риска — REVIEW_REQUIRED. Какой статус должен увидеть оператор?

Названия поля недостаточно. В требовании нужно зафиксировать две вещи: какой источник имеет право определять решение и как долго его ответ считается актуальным.

В нашем синтетическом примере решение о продолжении обработки приходит из сервиса риска. CRM хранит состояние процесса, но не переопределяет риск. Поэтому оператор видит REVIEW_REQUIRED, даже если в CRM осталось APPROVED.

Есть и вторая граница — свежесть. Допустим, ответ сервиса риска старше 15 минут. Эти 15 минут — учебное значение, не отраслевой норматив и не реальная политика. Правило примера простое: устаревший ответ нельзя показывать как текущий; сначала нужно запросить новый.

Так одно поле превращается в проверяемое требование:
— назван авторитетный источник;
— задан срок актуальности;
— описано поведение при конфликте;
— описано поведение при устаревании.

Если не записать авторитет и свежесть, система всё равно выберет значение. Только это будет технический порядок чтения данных, а не принятое решение.

Позитивный сценарий обычно помещается в одну строку: оператор запускает проверку, сервис риска отвечает, обработка продолжается.

А что произойдёт, если сервис недоступен?

Плохой ответ — молча показать последнее известное решение. Интерфейс будет выглядеть рабочим, но оператор примет старые данные за текущие.

Проверяемый отрицательный путь выглядит иначе:
— обработка остаётся заблокированной;
— оператор видит, что проверка не завершилась;
— прошлый результат не помечается как актуальный;
— повторная попытка возможна, но не превращается в скрытое разрешение продолжить работу.

Такое описание не требует перечислять все будущие ошибки. Достаточно назвать один реалистичный сбой, видимый результат и действие, которое система точно не должна совершать.

Позитивный путь показывает демонстрацию. Отрицательный — границу доверия к результату.

«Показывать статус заявки» — так требование выглядело в начале.

После уточнений оказалось, что важен не любой статус. Решение о продолжении обработки принимает сервис риска, а CRM только хранит состояние процесса. Старый или недоступный ответ нельзя выдавать за текущий.

Финальная формулировка стала другой:

«Показывать оператору актуальное решение сервиса риска. Если ответ недоступен или устарел, блокировать продолжение обработки и показывать причину».

Полезно сохранить рядом четыре записи:
— было: «показывать статус заявки»;
— вопрос: какой источник определяет решение;
— решение: авторитетен сервис риска;
— стало: показывать его актуальный ответ и явно обрабатывать отсутствие данных.

Так видно не только последнюю фразу, но и причину изменения. Если источник или правило свежести поменяются, команда поймёт, какое решение и какие проверки нужно пересмотреть.

Хорошее требование — не текст, который однажды красиво сформулировали. Это короткий след принятых уточнений.

Что на самом деле доказывает зелёный тест?

Он показывает, что реализация соответствует записанному правилу.

Но если само правило неверно, тест может идеально охранять ошибку.

Независимая приёмка начинается не с повторения постановки. Она начинается с ожидаемого пользовательского сценария и решения команды, принятых до оценки реализации.

Проверьте один свой зелёный тест: откуда взялся ожидаемый результат?

return_url не означает payment.succeeded

Возврат пользователя в интерфейс сообщает только о переходе пользователя.

Он не подтверждает, что платёж успешно завершён.

В синтетическом учебном кейсе заказ можно перевести в paid только после валидированного события payment.succeeded. pending, processing и succeeded остаются разными состояниями.

Какое событие в вашей системе действительно имеет право изменить состояние бизнес-объекта?

Промежуточное состояние нужно проектировать, а не скрывать

processing не является неудобной паузой между запросом и успехом.

У него должны быть собственные переходы, разрешённые действия и понятное отображение для пользователя.

Если система показывает только «не оплачено» и «оплачено», команда всё равно будет принимать решения в промежутке. Просто эти решения останутся неявными.

Какое промежуточное состояние ваша система сейчас маскирует спиннером?

Потерянный webhook остаётся открытым решением

Таймаут не сообщает, произошло событие или нет. Повтор запроса может помочь, а может создать второй внешний эффект.

Пока команда не приняла recovery contract, нельзя молча достраивать политику восстановления за владельца.

Нужно явно решить: кто проверяет состояние, когда допустим повтор, как распознаётся дубль и кому принадлежит остаточный риск.

Где в вашем процессе записаны эти решения?

Четыре доклада нельзя строить вокруг одного артефакта

Исследование незнакомой системы требует source map.

Обоснование решения требует decision trace.

Проектирование поведения требует исполняемого системного контракта.

Личный агентный контур требует рабочего workspace.

Темы могут пересекаться, но профессиональные вопросы и доказательства должны различаться.

Какой артефакт лучше всего показывает вклад аналитика в вашей работе?

Работающий артефакт на занятии ещё не доказывает самостоятельное умение

Участник может повторить действия преподавателя и получить правильный результат.

Проверка начинается позже: сможет ли он воспроизвести тот же учебный результат через семь дней без live-подсказок?

Для этого T+7-задание, единица анализа и критерий принятого результата должны быть зафиксированы до занятия.

Как вы проверяете перенос навыка после обучения?