Superpowers Verify - Проверка результата перед отчётом

Когда звать

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

Сначала подтверждение, потом сообщение

Verification-before-completion из Superpowers нужен в момент, когда агент собирается написать «готово», «исправлено» или «все тесты проходят». Основной файл связывает такую фразу со свежим результатом проверки. Прежний удачный запуск, уверенность в маленькой правке или положительный ответ другого агента не подходят. Проверять нужно тот результат, о котором пойдёт речь в отчёте, на текущем состоянии файлов.

Автор задаёт последовательность из пяти действий. Сначала агент определяет команду, которая доказывает конкретное утверждение. Затем запускает её полностью, читает весь вывод, проверяет код выхода и число отказов. После этого сравнивает результат с заявлением. Если подтверждения нет, следует сообщить фактическое состояние с найденными ошибками, а не подбирать более осторожный синоним слова «успех».

Разные утверждения требуют разных проверок

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

Для тестов требуется вывод команды без отказов. Для сборки нужен её собственный успешный запуск. Если проверялся только участок проекта, отчёт должен сохранить эту границу. Формулировка «должно работать» в инструкции относится к сигналам преждевременного завершения: она описывает ожидание автора, а не наблюдаемый результат. Даже радостная оценка до запуска проверки считается способом создать у человека неверное впечатление.

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

Что делать с отчётом другого агента

При делегировании инструкция предлагает сверить изменения в системе контроля версий и выполнить проверки самостоятельно. Сообщение исполнителя остаётся входной информацией. Оно не подменяет чтение изменённых файлов и реальный запуск. Это особенно полезно там, где отдельный агент мог неверно понять границы поручения или проверить лишь свой новый тест.

Карточка не утверждает, что сам этот скилл уже обеспечивает честный отчёт в любой среде. Мы прочитали закреплённый файл и лицензию MIT, но не проводили поведенческого испытания. Для применения заранее перечислите ожидаемые результаты и способы их проверки. В связке с systematic-debugging получится отделить поиск причины от доказательства того, что исправление действительно устранило исходную проблему.