Скил verification-before-completion — доказательства до утверждений
Как скил verification-before-completion применяет одно правило: никаких заявлений о завершении без свежего вывода верификационной команды. Гейт-функция, типичные сбои и почему частичные проверки ничего не доказывают.
Заявлять о завершении работы без запуска верификации — это не эффективность, это ложное утверждение. Скил verification-before-completion кодирует одно правило: никаких заявлений об успехе, выражений удовлетворения, коммитов, пул-реквестов и переходов к следующей задаче без запуска соответствующей команды и чтения её вывода в том же сообщении.
Скил загружается перед любым действием завершения. Его центральный инструмент — гейт-функция: последовательность из пяти шагов, которая должна выполниться по порядку до любого положительного утверждения.
Гейт-функция
Пять шагов: определить, какая команда доказывает утверждение; запустить полную команду заново, полностью; прочитать весь вывод и проверить код возврата; убедиться, что вывод действительно подтверждает утверждение; и только после этого озвучить утверждение с приложенным доказательством. Пропуск любого шага производит ложь, а не верификацию.
Правило применяется к точным фразам и к перефразировкам. «Должно пройти теперь», «выглядит правильно» и «скорее всего нормально» — все это заявления о завершении без доказательств, даже если ни одно из них не произносит слово «готово». Дух правила охватывает любую формулировку, подразумевающую успех без запущенной проверки.
Типичные сбои
Скил содержит таблицу, где каждому типу утверждения сопоставляется то, что реально является верификацией. Заявление о прохождении тестов требует вывода тестовой команды с нулём ошибок — предыдущий запуск или «должно пройти» не подходят. Заявление об успешной сборке требует команды сборки с нулевым кодом возврата — вывод линтера не подходит, потому что линтер не проверяет компиляцию. Заявление об исправлении бага требует воспроизведения исходного симптома и подтверждённого прохождения — изменение кода и предположение об исправлении не подходят. Заявление о завершении задачи агентом требует проверки VCS-диффа на наличие реальных изменений — собственный отчёт агента об успехе не подходит.
Каждый из этих сбоев зафиксирован на практике. Неопределённые функции попадали в производство. Фичи выпускались неполными. Часы тратились на ложное завершение до перенаправления работы.
Регрессионные тесты и TDD
Для регрессионных тестов «написал регрессионный тест» недостаточно. Цикл red-green должен быть завершён: написать тест, запустить и подтвердить прохождение, откатить исправление, запустить снова и подтвердить провал, восстановить исправление, запустить в третий раз и подтвердить прохождение. Тест, который ни разу не видели в состоянии провала, не доказывает, что он поймает баг, для которого написан.
Почему это не подлежит обсуждению
Скил ссылается на 24 задокументированных случая сбоев, которые сформировали правило. Доверие разрушается, когда партнёр-человек видит заявление о завершении, которое не подтверждается. Переработка обходится дороже, чем время, сэкономленное на пропуске верификации. Правило не допускает исключений: ни усталость, ни уверенность, ни частичная проверка, которая «покрывает важные случаи».
Общая картина — в посте что такое Datarim. Смежный материал о требованиях к доказательствам на уровне спецификации — в посте о скиле v-ac-axis-split.