incident-log — фиксировать инциденты и учиться на них

Инцидент, о котором не сделана запись, повторяется. Инцидент, записанный без разбора причины и без меры, повторяется тоже — запись превращается в мемориал вместо защиты.

Скилл задаёт: что считать инцидентом, куда писать (два раздельных журнала), какие поля обязательны, и главное — как превратить запись в меру, которая не даст повториться.

Два класса — разделять физически, не полем в одном файле

Почему физически раздельно, а не полем Class:. Проект передаётся, публикуется, архивируется — и утаскивает с собой всё, что лежит в его папке. Мои процессные провалы наружу не идут: они про меня, не про продукт. Обратно: рабочий урок «stdin форсировать симметрично stdout» касается ВСЕХ контуров, а не одного проекта, — в проектном журнале он бы там и умер.

Пограничный случай: сбой продукта, вызванный моей же процессной ошибкой (написал код, не проверил, выкатил) — две записи: P-NNN про дефект кода и W-NNN про то, почему он ушёл непроверенным. Мера у них разная: одна правит код, вторая — гейт.

Что считать инцидентом (порог)

Инцидент — если выполнено любое:

1. Что-то сломалось молча (успешный код возврата / отсутствие ошибки при нулевом результате).
2. Пришлось переделывать уже объявленное готовым.
3. Оператор поправил меня по существу — фактом, а не стилистикой.
4. Правило нарушено (§-правило доктрины, IRON MODE, граница зон §12).
5. Сбой инфраструктуры с потерей работы (краш Ollama, потеря watcher, OOM, CI red).
6. Расхождение заявленного и фактического (отчитался N, по факту M).

НЕ инцидент: обычная итерация по задаче, отладка в процессе разработки до объявления результата, правка по вкусу оператора, найденный и сразу исправленный дефект внутри своего же рабочего прохода (если он не ушёл наружу и ничего не сорвал).

Когда писать — молча, не дожидаясь команды

Запись делается сразу после починки, в том же ходе, до доклада оператору. Не «потом», не «накоплю и запишу» — отложенная запись теряет verbatim ошибки и точную причину.

Команда оператора («запиши инцидент», «прими меры») — не единственный триггер, а подтверждение того, что и так обязано было произойти.

Обязательные поля записи

Полный шаблон с плейсхолдерами — references/template.md. Минимум, без которого запись не годна:

1. Номер и однострочный заголовок — W-007 — Silent-fail: …. Заголовок читается отдельно от тела и уже сообщает суть.
2. Дата / контур / проект.
3. Класс и подкласс (см. таблицу выше + список подклассов в references/taxonomy.md).
4. Симптом ВНЕШНИЙ — что было видно до разбора. Именно он потом опознаётся в будущем.
5. Error verbatim — точный текст ошибки/расхождения, не пересказ. Нет текста — так и писать «текста ошибки не было, симптом молчаливый» (это само по себе диагноз).
6. Root cause — почему, а не что. «Скрипт упал» — не причина. «stdin не форсирован на UTF-8, кириллица стала суррогатами» — причина.
7. Как пойман — чем именно обнаружен. Отдельное поле, потому что «поймано случайно» и «поймано штатной проверкой» требуют разных мер: первое означает дыру в контроле.
8. Корректирующая мера — конкретная, проверяемая, с указанием файла. «Быть внимательнее» — не мера. Мера = правило + место, где оно записано, + (по возможности) механическое подкрепление.
9. Проверка меры — чем подтверждено, что мера работает. Прогон, тест, чтение файла.
10. Сканирование класса — проверил ли я ОСТАЛЬНЫЕ места с тем же дефектом. Обязательное поле: дефект такого класса редко бывает одиночным.
11. Owner / status — OPEN / CLOSED-fixed / CLOSED-analyzed / WONTFIX + причина.

Лестница мер — от слабой к сильной

Мера «запомнить» не работает. Выбирать САМУЮ СИЛЬНУЮ из доступных:

Написал только запись в журнал — спросить себя: почему нельзя подняться на ступень выше? Ответ «лень» не принимается; ответ «механически не детектируется» — принимается и записывается в поле меры.

Разбор: превратить инцидент в урок

После записи — три вопроса, ответы идут в саму запись:

1. Это одиночный дефект или класс? Если класс — просканировать все аналогичные места (поле «Сканирование класса»). Пример: после починки одного хука нашлось ещё пять с тем же багом.
2. Почему не поймалось раньше? Дыра в контроле важнее самого дефекта: дефект чинится один раз, дыра пропустит следующий.
3. Кому ещё это касается? Урок уровня доктрины (не проектный) — поднять в глобальный CLAUDE.md/references и, если контуров это касается прямо, написать промпты владельцам зон (§12: сам в чужую зону не хожу).

Периодический разбор паттернов

Раз в ~10 записей журнала — секция «Сводный анализ» в конце файла: какие классы повторяются, какая системная причина за ними. Три записи одного класса — сигнал, что мера была слишком слабой; поднять на ступень выше по лестнице мер.

Границы с соседними скиллами

• six-corner-audit — независимый аудит готового артефакта (найти дефекты). Здесь — что делать ПОСЛЕ того, как дефект найден и починен.
• session-handoff — состояние для продолжения работы. Инцидент в хендофф не пишется, пишется ссылка на журнал.
• §31 IRON MODE — как не допустить (самоаудит стерильными проходами). Здесь — что делать, когда всё-таки допустил. IRON MODE предотвращает, incident-log учит.
• §4 (краш Ollama) — частный случай: отчёт в СВОЙ журнал и оператору ОБЯЗАТЕЛЕН и не заменяет запись сюда. ⚠ Слово «супервайзер» снято 30.08 как реликт отменённой пошаговой отчётности контуров: надзорному контуру идёт только эскалация «не справляюсь», не рутинный отчёт.

Anti-patterns

• ❌ Записать «сломалось, починил» без root cause — запись бесполезна, повторится.
• ❌ Мера «быть внимательнее» / «учту» — не мера, ничего не меняет.
• ❌ Починить один файл, не проверив класс — самый частый способ оставить мину.
• ❌ Отложить запись «на потом» — verbatim ошибки теряется в тот же ход.
• ❌ Смешать рабочие и проектные в одном файле — уедут вместе с проектом либо урок не разойдётся.
• ❌ Журнал как changelog («переименовал файлы, обновил индекс») — сюда только сбои.
• ❌ Записать инцидент и не подняться по лестнице мер там, где хук был возможен.

История

Создан 2026-08-15 по требованию оператора оператора: «есть у всех жёсткое правило фиксации инцидентов и обучения на них? Инциденты нужно разделять на рабочие (при собственной работе агента) и проектные (баги продукта)». Проверка фактом показала: журнал был только у надзорного контура (audit/failure-register.md, 6 записей), у остальных 9 контуров — ни одного; разделения на рабочие/проектные не было нигде, в самом реестре надзорного контура они были свалены вместе. Триггером стал инцидент FR-006 (silent-fail хука из-за не форсированного UTF-8 на stdin): рабочий урок был записан в журнал одного контура, хотя правило касается всех.