parallel-debugging

Parallel Debugging — это навык для системного расследования сложных дефектов, когда одной правдоподобной версии недостаточно. Его исходный SKILL.md предлагает использовать метод конкурирующих гипотез (Analysis of Competing Hypotheses, ACH): сначала перечислить возможные причины, затем отдельно собрать для них наблюдаемые доказательства и только после этого провести арбитраж. Такой порядок нужен, чтобы расследование не превратилось в подтверждение первой удобной версии. Навык подходит для случаев, когда у сбоя есть несколько возможных корней, первая попытка отладки не дала ответа, проблема проходит через несколько модулей или нужно организовать параллельное расследование. В источнике прямо перечислены шесть групп отказов, которые стоит покрыть при генерации гипотез. Logic Error включает неверные условия, пропущенные ветки, ошибки границ и неправильную реализацию алгоритма. Data Issue охватывает неожиданные входные данные, несовпадение типов, null или undefined, проблемы кодировки, сериализации, усечение и переполнение. State Problem направляет внимание на гонки, устаревший кэш, неверную инициализацию, мутацию общего состояния и ошибки переходов конечного автомата. Остальные группы помогают не застрять на уровне бизнес-логики. Integration Failure включает нарушение контракта API, несовместимость версий, конфигурационные расхождения, отсутствующие переменные окружения и сетевые тайм-ауты. Resource Issue заставляет проверить утечки памяти, исчерпание пула соединений, файловых дескрипторов, дисковых или квотных ограничений и насыщение CPU. Environment охватывает отсутствующую зависимость, неправильную версию библиотеки или фреймворка, платформенные различия, права доступа и влияние часового пояса или локали. Это не готовый диагностический ответ, а каркас, который помогает последовательно проверить разные классы причин. В разделе Evidence Collection Standards источник различает силу свидетельств. Прямое доказательство — например, конкретная строка кода, показывающая ошибочное условие, — сильнее корреляции вроде изменения частоты ошибок после релиза. Отсутствие ожидаемой проверки имеет переменную силу и требует осторожной интерпретации. Для каждого вывода рекомендуется указывать файл и строку, чтобы другой участник расследования мог воспроизвести проверку, а не принять устное объяснение на веру. Уверенность следует выражать явно: высокий уровень требует нескольких прямых свидетельств и ясной причинной цепочки без противоречий; средний допускает небольшую неоднозначность; низкий означает, что пока преобладают косвенные признаки. Финальный арбитраж классифицирует результаты как подтверждённые, правдоподобные, опровергнутые или неубедительные. Если подтверждены несколько гипотез, их сравнивают по уверенности, числу поддерживающих свидетельств, силе причинной цепочки и отсутствию противоречий. Если одна версия явно доминирует, её можно объявить корневой причиной; если версии равны по силе, источник допускает составную причину. Если подтверждения нет, нужно сформировать новые гипотезы из собранных данных, а не объявлять расследование завершённым. Ограничение навыка следует из его назначения: он организует мышление и сбор доказательств, но не заменяет доступ к логам, коду, метрикам, конфигурации или воспроизводимому сценарию сбоя. После выбора исправления источник требует проверить, что оно действительно устраняет исходную причину, не создаёт новых проблем, закрывает исходный воспроизводимый случай, учитывает связанные крайние случаи и имеет релевантные тесты. Поэтому карточка особенно полезна для incident response, root-cause analysis и сложной отладки, где важны независимые проверки и прозрачный арбитраж, но сама по себе не обещает автоматического исправления дефекта.