verification-before-completion

Verification Before Completion — это скилл, который превращает заявление «готово», «исправлено» или «проходит» в проверяемое утверждение. Его центральное правило простое: сначала получить свежие свидетельства, затем делать вывод. История запуска, уверенность исполнителя, сообщение другого агента или впечатление от diff не заменяют команду, которая непосредственно доказывает нужное свойство. Такой порядок особенно важен перед commit, созданием pull request и передачей работы пользователю. Для каждого утверждения сначала определяется проверка, которая его доказывает. Если заявляется, что тесты проходят, запускается полный тестовый набор и читается результат с числом ошибок или падений. Если заявляется чистый lint, запускается полный линтер и проверяется код завершения. Для build нужен именно свежий build, а не косвенные признаки вроде успешного lint или запуска приложения. Для исправления бага повторяется исходный сценарий, который раньше ломался. После команды нужно прочитать весь относящийся к результату вывод и сравнить его с требованием: нулевой код сам по себе не оправдывает вывод, если отчёт содержит пропущенные проверки или ошибки внутри результата. Скилл предлагает короткую последовательность из пяти шагов. Сначала формулируется claim и выбирается конкретная команда. Затем выполняется полный, а не частичный вариант проверки. После этого читается stdout и stderr, фиксируются код выхода и количество проблем. Затем результат сверяется с тем, что именно требовалось подтвердить. Только если свидетельство действительно подтверждает утверждение, оно может попасть в итоговый отчёт. Если результат не подтверждает цель, нужно прямо назвать фактический статус — например, частичный результат, блокер или оставшуюся ошибку — вместо более сильного слова «готово». Отдельно отмечены типовые подмены доказательств. Предыдущий успешный запуск не подтверждает текущий код; локальная уверенность не заменяет проверку; один тест не доказывает весь regression suite; сообщение субагента не заменяет самостоятельный просмотр diff и запуск нужной команды. Скилл также запрещает ссылаться на «должно работать», «вероятно исправлено» и похожие формулировки, когда fresh evidence отсутствует. Это не требование собирать отчёты ради отчётов, а ограничение на силу формулировки: можно сообщить только то, что реально показано проверкой. Перед заявлением о завершении полезно пройти требования построчно. Для каждой части задачи указывается наблюдаемый критерий и свежая команда или readback, который его проверяет. Успешная проверка одного слоя не закрывает другой: тесты не являются доказательством линтера, линтер не является доказательством сборки, а build не является доказательством поведения исправленного сценария. Такой разбор помогает не объявить фазу законченной только потому, что одна команда завершилась без ошибок. Workflow применяется всегда, когда сообщение может создать впечатление завершённой работы или исправленного поведения. Он действует до commit и pull request, а также перед обычным пользовательским handoff. Если проверку нельзя выполнить, правильный результат — зафиксировать ограничение и не выдавать предположение за факт. Если команда прошла, итог должен содержать именно свежий результат, его масштаб и оставшиеся ограничения.