Почему воспроизведение багов — ключ к надёжному исправлению

Большинство нестабильных багов заканчиваются либо словами «не воспроизводится», либо патчем, который никто не может доказать, что он решает проблему. Я построил Verdict на более строгой идее: баги считаются невиновными, пока не воспроизведены. Verdict превращает GitHub-issue в ограниченное расследование: он многократно запускает одобренную команду в одобренных условиях, сохраняет каждое наблюдение и отказывается утверждать воспроизведение, если доказательства не пересекают детерминированный порог. Это не автономный генератор патчей, а агентский каркас, производящий доказательства на сложном этапе перед исправлением.

Зачем ещё один инструмент для расследования багов?

LLM может быстро прочитать стек-трейс и предложить правдоподобное объяснение. Но правдоподобность не равна воспроизведению. Для периодического сбоя важны конкретные вопросы:

Какое условие реально его триггерит?
Как часто он падает при этом условии?
Что происходит при контрастном контроле?
Какой диапазон коммитов подтверждают доказательства?
Какой регрессионный тест предотвратит повторение сбоя?

Verdict рассматривает это как эксперимент, а не как разговор.

Трёхактное расследование

Verdict использует три ограниченных субагента:

GitHub issue
    |
    v
Hunter: найти триггер
    |
    v
Surgeon: локализовать изменение
    |
    v
Insurance: сохранить исправление
    |
    v
Ревью мейнтейнера

Hunter: поиск триггера

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

Surgeon: локализация изменения

Surgeon сужает воспроизведённое условие до наименьшего подозрительного диапазона, который поддерживают записи. Статический анализ явно отличается от доказанной границы выполнения. Surgeon не создаёт патч.

Insurance: сохранение исправления

Insurance преобразует воспроизведение в регрессионный план: название теста, фикстура, падающее утверждение и манифест публикации. Черновик pull request может быть создан только через рабочий процесс, который мейнтейнер явно одобрил.

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

Воспроизведение — это запись, а не скриншот

Verdict воспроизвёл TrueForge issue #417, где регистрация снимка может ждать бесконечно, если внешний запрос не завершается. Использовался закреплённый рантайм @truefoundry/trueforge-core@0.1.4#DaytonaSandboxProvider и два условия:

daytona-stalled-endpoint: 10 из 10 запусков совпали, REPRODUCTION_PINNED
daytona-responsive-endpoint: 0 из 10 совпали, NOT_REPRODUCED

Контроль — важная половина. Условие, которое падает каждый раз рядом с тем, которое никогда не падает, — более сильное доказательство, чем двадцать падений без контраста.

Любой может пересчитать запись:

pnpm --filter @verdict/agent verify:runtime-evidence

Верификатор возвращает:

{
  "verdict": "REPRODUCED",
  "stalledRuns": 10,
  "responsiveControls": 10,
  "provider": "@truefoundry/trueforge-core@0.1.4#DaytonaSandboxProvider",
  "canonicalSha256": "a8bb5dd22e083782bd7782fccb0a1343b59fc77ea8525b6358fecc9b5b8baffa"
}

Доказательства связывают наблюдения с сессией TrueForge, потоком Hunter, коммитом репозитория, коммитом npm provenance и общим исходным блобом.

Исследование и доказательство — разные системы

Модель собирает возможные наблюдения. Она не решает, что эти наблюдения доказывают. Контракт доказательств Verdict прост:

Текст issue и содержимое репозитория изначально считаются недоверенными.
Расследование может использовать только одобренные команды, параметры и бюджеты.
Каждое принятое наблюдение должно соответствовать схеме доказательств.
Чистые редукторы решают, какое утверждение поддерживают записи.
Отсутствующие или конфликтующие доказательства дают честный частичный результат.
Мейнтейнер контролирует единственную публичную запись.

Одни и те же записи всегда приводят к одному и тому же вердикту. Это граница между агентом, исследующим проблему, и системой, делающей утверждение.

Что является живым, а что фикстурой

Записанный случай отображает выполненный артефакт. Он включает оба условия, все двадцать запусков и пересчитываемый хэш. Интерактивное рабочее пространство — концептуальная фикстура. Каждое сгенерированное значение помечено. Оно не представлено как живое рантайм-доказательство. Это различие важно для продукта, чей аргумент — что утверждение нуждается в записи.

Одобрение остаётся решением мейнтейнера

Verdict также проверил свою границу публикации против реального GitHub. После явного одобрения рабочий процесс с nonce-bound запустился, проверил внешнюю ссылку на воспроизведение и создал черновик pull request в репозитории Verdict. Репозиторий TrueForge остался read-only.

Доказательство рабочего процесса говорит runtimeReproducedByThisWorkflow: false. Это намеренно. Провайдер воспроизвёл баг. GitHub Actions проверил каркас и опубликовал независимо проверяемое доказательство. Объединение их в один размытый флаг «verified» стёрло бы границу.

Qodo проверил утверждения и код

Каждое существенное изменение прошло через pull request, проверенный Qodo перед слиянием. Самые полезные находки были не драматическими падениями, а несоответствиями между реализацией и тем, что проект утверждал:

Карточка на лендинге всё ещё описывала реальное воспроизведение как симуляцию.
CI доверял записанному вердикту, а не пересчитывал его хэш.
README утверждал покрытие при каждом пуше, тогда как рабочий процесс покрывал main и pull request.
Некорректный CSS-селектор молча падал после очистки.

Эти проверки идеально соответствуют философии продукта: не выпускайте утверждение сильнее, чем поддерживают доказательства.

Текущая проверка

Репозиторий запускает тот же шлюз локально и в CI:

pnpm lint
pnpm typecheck
pnpm test
pnpm build
pnpm --filter @verdict/agent verify:runtime-evidence

Текущий набор содержит 220 тестов в пакетах агента, протокола и веб-интерфейса.

Попробуйте Verdict

Живой продукт, выполненная запись TrueForge #417, интерактивное рабочее пространство и исходный код доступны. Verdict — open source под лицензией MIT и создан для WeMakeDevs x TrueFoundry Agent Harness Hackathon.

Цель — не сделать агента уверенным, а сделать уверенность проверяемой.

Практический вывод: что делать прямо сейчас

Если вы столкнулись с нестабильным багом, не пытайтесь сразу писать патч. Создайте матрицу условий и контрольную группу. Запустите подозрительную команду несколько раз, фиксируя каждый результат. Сравните с контрастным условием. Только когда у вас есть повторяемое воспроизведение, приступайте к исправлению. Используйте Verdict или аналогичный подход — это сэкономит часы и сделает ваш фикс доказуемым.

Воспроизведение багов: как Verdict превращает проблему в доказательство