# Edge Hunt > Находит неочевидные корнеры задачи через пересечение состояний, данных, порядка действий, сбоев и параллельных изменений; превращает их в ожидаемое поведение и проверяемые сценарии. Использовать перед реализацией или ревью нетривиальной продуктовой, UX- или технической задачи; при изменении stateful/async-поведения, сохранения, синхронизации, прав, интеграций и многошаговых флоу; когда пользователь просит продумать edge cases, corner cases, крайние случаи или проверить полноту постановки. Не использовать для мелких механических правок и до выбора самой задачи или масштаба решения — сначала nodumb. - Skill: `hanumatori/edge-hunt` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add hanumatori/edge-hunt` - Raw SKILL.md: https://api.skillmd.com/api/skills/hanumatori/edge-hunt/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: hanumatori (https://skillmd.com/u/hanumatori) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/hanumatori/edge-hunt --- # Edge Hunt Корнер редко выглядит необычно по частям. Обычно ломается пересечение обычного состояния, обычного действия и неучтённого порядка событий. Не пытаться просто «подумать внимательнее»: построить пространство задачи и системно столкнуть его измерения. Сначала убедиться, что задача и масштаб уже выбраны. Этот скилл укрепляет края решения, но не доказывает, что выбрано правильное решение. Если направление ещё обсуждается, вернуться к `nodumb` или `ask-nodumb`. ## 1. Зафиксировать нормальный контракт Одной короткой цепочкой записать: `исходное состояние → действие → видимый результат → что обязано сохраниться` Последний элемент обязателен. Неявные гарантии вроде «закрыл временную панель — вернулся к прежней работе» чаще выпадают из постановки, чем основной результат. Не изобретать контракт только по тикету. Проверить релевантные код, тесты, документацию, историю решений и соседние сценарии. Разделить: - подтверждённое текущее поведение; - выбранное новое поведение; - предположение без источника; - вопрос, требующий продуктового решения. ## 2. Выделить измерения именно этой задачи Выбрать только те оси, которые физически участвуют в изменении: - состояние до действия; - способ входа и вариант действия; - порядок, повтор, отмена и прерывание; - форма, объём и свежесть данных; - роль, права и смена доступа; - этап жизненного цикла: первый случай, следующий, спустя время, после restart, update, миграции или отзыва доступа; - время ответа, retry и поздний результат; - устройство, вкладка, процесс или внешняя интеграция; - параллельное действие другого участника или воркера. Для каждой выбранной оси назвать 2–5 различающихся классов, а не перечислять все возможные значения. Отметить невозможные сочетания и основание, которое их исключает. ## 3. Породить корнеры Применить к выбранным осям пять операций: 1. **Пересечение.** Скрестить пары условий. Для потери данных, прав, платежей, синхронизации и необратимых действий проверить также тройки. 2. **Перестановка.** Поменять порядок связанных действий; повторить действие; вставить отмену, возврат, перезапуск или продолжение после паузы. 3. **Нарушение инварианта.** Попытаться потерять то, что должно сохраняться: основную работу, идентичность, выбор, данные, права или возможность вернуться. 4. **Разрез сбоя.** Поместить ошибку до эффекта, во время частичного эффекта и после эффекта, но до подтверждения пользователю. 5. **Сдвиг по жизненному циклу.** Повторить сценарий не только сразу, но для второго и последующего объекта, после истечения времени, перезапуска, обновления, миграции или отзыва внешнего права. Не останавливаться на названиях вроде «ошибка сети». Описывать полную ситуацию: что уже произошло, что не произошло, что видит человек и что случится при повторе. Подробный механизм и примеры — [`references/generation-methods.md`](references/generation-methods.md). ## 4. Отобрать важное Оставить обычно 5–10 сценариев. Поднимать выше случаи, где: - несколько обычных условий создают неожиданный результат; - возможны тихая потеря данных, нарушение прав или необратимое действие; - граница проходит между двумя компонентами, устройствами или моментами времени; - поведение существует в продукте, но не записано в постановке; - проверка способна опровергнуть решение, а не только подтвердить реализацию. Не добавлять корнер только потому, что он теоретически возможен. Назвать связь с реальным состоянием, веткой кода, контрактом, прошлым багом или внешней гарантией. Невозможные, уже закрытые нижним слоем и не относящиеся к изменению случаи отбросить. ## 5. Превратить находку в решение Для каждого оставшегося корнера определить один статус: - **поддержать сейчас** — без него задача не выполняет свой контракт; - **сохранить прежнее** — новое решение не должно менять существующий сценарий; - **оставить за границей** — случай реален, но его цена не входит в эту задачу; - **нужен новый факт** — сначала наблюдение, лог, решение человека или живая проверка. Не перекладывать на пользователя обратимые локальные решения. Рекомендовать поведение по существующему контракту; спрашивать только там, где выбор меняет продукт, данные, права или скоуп. ## 6. Проверить, а не только перечислить Если доступны код или живой продукт, безопасно проверить 1–3 самых рискованных сценария до реализации либо включить их в план проверки. Предпочитать пробу, которая может опровергнуть гипотезу: воспроизведение, state-machine test, property-based test, fault injection или минимальную последовательность событий. Выбрать сигнал, который физически наблюдает сломанный слой: визуальное поведение проверять в живом интерфейсе, сохранность данных — повторным чтением из хранилища, права — запросом с нужной ролью, восстановление — реальным restart. Зелёная проверка не считается подтверждением, если она не могла увидеть дефект. Не выдавать придуманный сценарий за найденный дефект. Отдельно помечать: подтверждено кодом, воспроизведено, следует из контракта или остаётся гипотезой. ## Результат Начать с самого опасного пропуска. Для каждого корнера кратко дать: | Ситуация | Ожидаемое поведение | Почему её легко пропустить | Статус | Проверка | |---|---|---|---|---| В конце назвать, какие измерения проверены, какие сознательно исключены и какое одно неизвестное сильнее всего ограничивает уверенность. Не превращать ответ в ритуальный чеклист и не расширять задачу молча.