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

Сначала убедиться, что задача и масштаб уже выбраны. Этот скилл укрепляет края решения, но не доказывает, что выбрано правильное решение. Если направление ещё обсуждается, вернуться к или .

Одной короткой цепочкой записать:

исходное состояние → действие → видимый результат → что обязано сохраниться

Последний элемент обязателен. Неявные гарантии вроде «закрыл временную панель — вернулся к прежней работе» чаще выпадают из постановки, чем основной результат.

Не изобретать контракт только по тикету. Проверить релевантные код, тесты, документацию, историю решений и соседние сценарии. Разделить:

Выбрать только те оси, которые физически участвуют в изменении:

Для каждой выбранной оси назвать 2–5 различающихся классов, а не перечислять все возможные значения. Отметить невозможные сочетания и основание, которое их исключает.

Применить к выбранным осям пять операций:

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

Подробный механизм и примеры —

references/generation-methods.md

.

Оставить обычно 5–10 сценариев. Поднимать выше случаи, где:

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

Для каждого оставшегося корнера определить один статус:

Не перекладывать на пользователя обратимые локальные решения. Рекомендовать поведение по существующему контракту; спрашивать только там, где выбор меняет продукт, данные, права или скоуп.

Если доступны код или живой продукт, безопасно проверить 1–3 самых рискованных сценария до реализации либо включить их в план проверки. Предпочитать пробу, которая может опровергнуть гипотезу: воспроизведение, state-machine test, property-based test, fault injection или минимальную последовательность событий.

Выбрать сигнал, который физически наблюдает сломанный слой: визуальное поведение проверять в живом интерфейсе, сохранность данных — повторным чтением из хранилища, права — запросом с нужной ролью, восстановление — реальным restart. Зелёная проверка не считается подтверждением, если она не могла увидеть дефект.

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

Начать с самого опасного пропуска. Для каждого корнера кратко дать:

В конце назвать, какие измерения проверены, какие сознательно исключены и какое одно неизвестное сильнее всего ограничивает уверенность. Не превращать ответ в ритуальный чеклист и не расширять задачу молча.