VibeEngineering-LLC incident-log — фиксировать инциденты и учиться на них
Инцидент, о котором не сделана запись, повторяется. Инцидент, записанный без разбора причины и без меры, повторяется тоже — запись превращается в мемориал вместо защиты.
Скилл задаёт: что считать инцидентом, куда писать (два раздельных журнала), какие поля обязательны, и главное — как превратить запись в меру, которая не даст повториться.
Два класса — разделять физически, не полем в одном файле
РАБОЧИЙ (work-incidents.md) |
ПРОЕКТНЫЙ (project-incidents.md) |
|
|---|---|---|
| Что это | Сбой МОЕЙ работы как агента | Дефект ПРОДУКТА |
| Примеры | Поверил exit-коду, не проверил результат; не делегировал машинерию; сорвал §-правило; false-green субагента; отчитался «готово» непроверенным | Баг прошивки; неверный расчёт; сломанный парсер; протухший конфиг; регрессия после правки |
| Где лежит | <папка контура>\audit\work-incidents.md |
<папка проекта>\audit\project-incidents.md |
| Кто адресат меры | Доктрина: CLAUDE.md / references/* / хук / гейт |
Код: правка + тест |
| Судьба | Остаётся у агента; урок уровня доктрины поднимается ВСЕМ контурам | Уезжает вместе с проектом (публикация, передача, архив) |
| Номер | W-NNN |
P-NNN |
Почему физически раздельно, а не полем Class:. Проект передаётся, публикуется, архивируется —
и утаскивает с собой всё, что лежит в его папке. Мои процессные провалы наружу не идут: они про
меня, не про продукт. Обратно: рабочий урок «stdin форсировать симметрично stdout» касается ВСЕХ
контуров, а не одного проекта, — в проектном журнале он бы там и умер.
Пограничный случай: сбой продукта, вызванный моей же процессной ошибкой (написал код, не
проверил, выкатил) — две записи: P-NNN про дефект кода и W-NNN про то, почему он ушёл
непроверенным. Мера у них разная: одна правит код, вторая — гейт.
Что считать инцидентом (порог)
Инцидент — если выполнено любое:
- Что-то сломалось молча (успешный код возврата / отсутствие ошибки при нулевом результате).
- Пришлось переделывать уже объявленное готовым.
- Оператор поправил меня по существу — фактом, а не стилистикой.
- Правило нарушено (§-правило доктрины, IRON MODE, граница зон §12).
- Сбой инфраструктуры с потерей работы (краш Ollama, потеря watcher, OOM, CI red).
- Расхождение заявленного и фактического (отчитался N, по факту M).
НЕ инцидент: обычная итерация по задаче, отладка в процессе разработки до объявления результата, правка по вкусу оператора, найденный и сразу исправленный дефект внутри своего же рабочего прохода (если он не ушёл наружу и ничего не сорвал).
Когда писать — молча, не дожидаясь команды
Запись делается сразу после починки, в том же ходе, до доклада оператору. Не «потом», не «накоплю и запишу» — отложенная запись теряет verbatim ошибки и точную причину.
Команда оператора («запиши инцидент», «прими меры») — не единственный триггер, а подтверждение того, что и так обязано было произойти.
Обязательные поля записи
Полный шаблон с плейсхолдерами — references/template.md. Минимум, без которого запись не годна:
- Номер и однострочный заголовок —
W-007 — Silent-fail: …. Заголовок читается отдельно от тела и уже сообщает суть. - Дата / контур / проект.
- Класс и подкласс (см. таблицу выше + список подклассов в
references/taxonomy.md). - Симптом ВНЕШНИЙ — что было видно до разбора. Именно он потом опознаётся в будущем.
- Error verbatim — точный текст ошибки/расхождения, не пересказ. Нет текста — так и писать «текста ошибки не было, симптом молчаливый» (это само по себе диагноз).
- Root cause — почему, а не что. «Скрипт упал» — не причина. «stdin не форсирован на UTF-8, кириллица стала суррогатами» — причина.
- Как пойман — чем именно обнаружен. Отдельное поле, потому что «поймано случайно» и «поймано штатной проверкой» требуют разных мер: первое означает дыру в контроле.
- Корректирующая мера — конкретная, проверяемая, с указанием файла. «Быть внимательнее» — не мера. Мера = правило + место, где оно записано, + (по возможности) механическое подкрепление.
- Проверка меры — чем подтверждено, что мера работает. Прогон, тест, чтение файла.
- Сканирование класса — проверил ли я ОСТАЛЬНЫЕ места с тем же дефектом. Обязательное поле: дефект такого класса редко бывает одиночным.
- Owner / status —
OPEN/CLOSED-fixed/CLOSED-analyzed/WONTFIX+ причина.
Лестница мер — от слабой к сильной
Мера «запомнить» не работает. Выбирать САМУЮ СИЛЬНУЮ из доступных:
| Сила | Мера | Когда |
|---|---|---|
| Слабая | Запись в журнал | всегда, это база, но сама по себе не защищает |
| Средняя | Правило в CLAUDE.md / references/* / SKILL.md |
урок формулируется словами и применим впредь |
| Сильная | Хук / гейт / скрипт-проверка | нарушение можно обнаружить механически |
| Максимальная | Устранение самой возможности | переписать так, чтобы ошибка стала невозможной |
Написал только запись в журнал — спросить себя: почему нельзя подняться на ступень выше? Ответ «лень» не принимается; ответ «механически не детектируется» — принимается и записывается в поле меры.
Разбор: превратить инцидент в урок
После записи — три вопроса, ответы идут в саму запись:
- Это одиночный дефект или класс? Если класс — просканировать все аналогичные места (поле «Сканирование класса»). Пример: после починки одного хука нашлось ещё пять с тем же багом.
- Почему не поймалось раньше? Дыра в контроле важнее самого дефекта: дефект чинится один раз, дыра пропустит следующий.
- Кому ещё это касается? Урок уровня доктрины (не проектный) — поднять в глобальный
CLAUDE.md/referencesи, если контуров это касается прямо, написать промпты владельцам зон (§12: сам в чужую зону не хожу).
Периодический разбор паттернов
Раз в ~10 записей журнала — секция «Сводный анализ» в конце файла: какие классы повторяются, какая системная причина за ними. Три записи одного класса — сигнал, что мера была слишком слабой; поднять на ступень выше по лестнице мер.
Границы с соседними скиллами
six-corner-audit— независимый аудит готового артефакта (найти дефекты). Здесь — что делать ПОСЛЕ того, как дефект найден и починен.session-handoff— состояние для продолжения работы. Инцидент в хендофф не пишется, пишется ссылка на журнал.- §31 IRON MODE — как не допустить (самоаудит стерильными проходами). Здесь — что делать, когда всё-таки допустил. IRON MODE предотвращает, incident-log учит.
- §4 (краш Ollama) — частный случай: отчёт супервайзеру ОБЯЗАТЕЛЕН и не заменяет запись сюда.
Anti-patterns
- ❌ Записать «сломалось, починил» без root cause — запись бесполезна, повторится.
- ❌ Мера «быть внимательнее» / «учту» — не мера, ничего не меняет.
- ❌ Починить один файл, не проверив класс — самый частый способ оставить мину.
- ❌ Отложить запись «на потом» — verbatim ошибки теряется в тот же ход.
- ❌ Смешать рабочие и проектные в одном файле — уедут вместе с проектом либо урок не разойдётся.
- ❌ Журнал как changelog («переименовал файлы, обновил индекс») — сюда только сбои.
- ❌ Записать инцидент и не подняться по лестнице мер там, где хук был возможен.
История
Создан 2026-08-15 по требованию оператора: «есть у всех жёсткое правило фиксации
инцидентов и обучения на них? Инциденты нужно разделять на рабочие (при собственной работе
агента) и проектные (баги продукта)». Проверка фактом показала: журнал был только у Цензора
(audit/failure-register.md, 6 записей), у остальных 9 контуров — ни одного; разделения на
рабочие/проектные не было нигде, в самом реестре Цензора они были свалены вместе. Триггером стал
инцидент FR-006 (silent-fail хука из-за не форсированного UTF-8 на stdin): рабочий урок был
записан в журнал одного контура, хотя правило касается всех.