edge-hunt

Edge Hunt

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

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

1. Зафиксировать нормальный контракт

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

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

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

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

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

2. Выделить измерения именно этой задачи

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

• состояние до действия;
• способ входа и вариант действия;
• порядок, повтор, отмена и прерывание;
• форма, объём и свежесть данных;
• роль, права и смена доступа;
• этап жизненного цикла: первый случай, следующий, спустя время, после restart, update, миграции или отзыва доступа;
• время ответа, retry и поздний результат;
• устройство, вкладка, процесс или внешняя интеграция;
• параллельное действие другого участника или воркера.

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

3. Породить корнеры

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

1. Пересечение. Скрестить пары условий. Для потери данных, прав, платежей, синхронизации и необратимых действий проверить также тройки.
2. Перестановка. Поменять порядок связанных действий; повторить действие; вставить отмену, возврат, перезапуск или продолжение после паузы.
3. Нарушение инварианта. Попытаться потерять то, что должно сохраняться: основную работу, идентичность, выбор, данные, права или возможность вернуться.
4. Разрез сбоя. Поместить ошибку до эффекта, во время частичного эффекта и после эффекта, но до подтверждения пользователю.
5. Сдвиг по жизненному циклу. Повторить сценарий не только сразу, но для второго и последующего объекта, после истечения времени, перезапуска, обновления, миграции или отзыва внешнего права.

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

Подробный механизм и примеры — references/generation-methods.md.

4. Отобрать важное

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

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

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

5. 将发现转化为决策

为每个剩余的边界情况确定一个状态：

• 现在支持 — 缺少它，任务就无法履行其契约；
• 保留现状 — 新决策不应改变现有场景；
• 留在范围之外 — 这种情况确实存在，但处理成本不属于本任务；
• 需要新事实 — 先获取观察结果、日志、人工决策或进行实际检查。

不要把可逆的本地决策推给用户。根据现有契约推荐行为；只有当选择会改变产品、数据、权限或范围时才提问。

6. 验证，而不只是列举

如果可以访问代码或实际产品，在实现前安全地验证 1–3 个风险最高的场景，或将它们纳入验证计划。优先选择能够推翻假设的测试：复现、状态机测试、基于属性的测试、故障注入或最小事件序列。

选择能直接观察到故障层的信号：在实际界面中检查视觉行为，通过重新读取存储中的数据检查数据是否保留，以所需角色发起请求检查权限，通过实际重启检查恢复能力。如果验证无法发现缺陷，就不能将通过视为确认。

不要把虚构的场景说成已发现的缺陷。分别标注：代码已证实、已复现、由契约推知，或仍是假设。

结果

从最危险的遗漏开始。对每个边界情况简要说明：

情况	预期行为	为什么容易遗漏	状态	验证

最后说明哪些维度已验证、哪些被有意排除，以及哪一个未知因素最限制信心。不要把回答变成例行检查清单，也不要在不说明的情况下扩大任务范围。