firmware-stability — от «код работает» до «продукт готов»

Подскилл code-audit-core. Аудит отвечает на вопрос «что не так в тексте программы»; этот скилл — на вопрос «что не так в работающей системе и чего ей не хватает до выпуска». Написан для любой встроенной платформы; платформенное вынесено в references/.

Главный закон: сначала наблюдаемость, потом нагрузка

Прогон, который не оставляет следов, — потраченное время, а не эксперимент. Типовая история: устройство встало на три часа, само ожило, в логах ничего. Событие произошло — разбирать нечего, и всё повторится. Поэтому порядок жёсткий: сначала сделать отказ наблюдаемым, и только потом нагружать. До запуска ответить письменно на три вопроса:

1. Если задача зависнет — что останется в доказательство? (сторожевой таймер: он перезагружает или только пишет предупреждение? — см. references/esp-idf-diagnostics.md)
2. Если система перезагрузится — сохранится ли посмертный дамп, и есть ли куда его класть?
3. Если деградация будет плавной — какие счётчики её покажут, и пишутся ли они уже сейчас?

Нет ответа хотя бы на один — прогон откладывается, чинится наблюдаемость. Это не бюрократия: без неё редкий отказ придётся ловить заново, а он редкий.

Разметка достоверности — обязательна во всех документах скилла

Смешивать запрещено. «Наверное, из-за флеша» — это [Г], и обязано быть помечено как [Г], пока нет замера. Непомеченная гипотеза в отчёте читается как факт и отравляет решения.

Лестница фаз

Порядок обусловлен ценой ошибки и ценой самого шага: дешёвое и воспроизводимое — раньше.

Пропускать фазы можно, но осознанно и с записью причины. Чаще всего пропуск фазы 3 оборачивается возвратом к ней после первого же необъяснённого прогона.

Классы отказов и где их искать

Приём: бюджет времени против таймаута

Класс дефектов, который статический аудит не ловит, а замер ловит сразу: в коде стоит таймаут, физически меньший, чем время операции, которую он ждёт.

Метод, три шага:

1. [Ф] Выписать из кода все таймауты и окна ожидания — с файл:строка.
2. [В] Найти в документации и паспортах компонентов физическое время операций, которых эти таймауты ждут: стирание и запись памяти, обмен по шине, установление соединения.
3. Сопоставить арифметикой, а не на глаз: объём разделить на гранулярность, умножить на время операции, взять типовое и предельное значения. Расхождение на порядок — находка.

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

Типовые источники «физики» — references/flash-storage.md.

Приём: что система делает МОЛЧА

Отдельно проверяется не поведение, а его отсутствие:

• Возвращаемые значения, которые никто не смотрит: удаление, запись, освобождение.
• Лог об успехе, стоящий до проверки результата или без неё вовсе.
• Флаг «сделано», сбрасываемый раньше, чем действие подтверждено, — повтора не будет никогда, временный сбой превращается в постоянное состояние.
• Ветки ошибок без освобождения захваченного ресурса — каждая утечка одноразова, но повторяется при каждой ошибке.
• Счётчики потерь, которые считаются, но никуда не выводятся.

Это самый урожайный проход по чужой прошивке и самый неприятный по последствиям: такие дефекты не падают, а тихо портят данные.

Кто исполняет проверки и откуда берётся стерильность

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

Стерильность — свойство контекста, а не модели. Проверяющий проход не должен видеть ни работы, ни выводов проверяемого: названный ответ подтверждают, а не проверяют. В бриф идут задача, метод и критерий приёмки — и никогда ожидаемые числа. Числа проверяются пересчётом от первичных величин, а не сверкой с уже напечатанным: сверка ловит опечатку, но подтверждает ошибку в самом расчёте. Состояние — чтением результата командой, а не памятью о том, что команда вызывалась.

Необратимое и критичное — два прохода, не видящих друг друга. При расхождении побеждает предъявивший файл:строка, вывод команды или число замера, а не более уверенный.

Дробить проверку на короткие шаги. Единственный длинный фоновый проход не переживает перезапуск инструмента и теряет результат целиком; скриптовые проверки живучее прочих и идут первыми. Тело правила, таблицы ступеней и разбор — references/execution-and-sterility.md.

Границы и дисциплина

Необратимое — только оператор. Снятие питания на живой записи, стирание разделов, перепрошивка без пути отката, любые деструктивные команды прибору — предлагаются, но не выполняются. Отдельно: если пути отката нет физически (нет резервной копии прошивки, корпус неразборный) — это стоп, а не «аккуратно попробуем».

Диагностическая сборка ≠ релизная. Всё, что включено ради наблюдаемости, помечается и в выпуск не уезжает. Обратное тоже верно: измерять надо ту сборку, которую выпускают, иначе меряется не тот объект.

Чужая зона (§ 12). Прошивку чужого контура не правим: находки, доказательства файл:строка, промпт владельцу. Рецензия чужого аудита — профильная работа (actor ≠ verifier), делается по исходному коду, а не по пересказу.

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

Справочники

Тест-план: диагностика незнакомой прошивки

1. Инвентаризация (фаза 0) — карта задач, память, хранилище; отдельно записать, чего в системе нет: это сокращает работу сильнее, чем любая находка.
2. Прочитать её собственные разборы прошлых отказов, если есть, — чтобы не переоткрывать уже починенное, а проверять полноту фиксов.
3. Статика по линзам code-audit-core, приоритет — «размер × риск».
4. Приём «бюджет против таймаута» и приём «что делает молча» — оба дают находки до железа.
5. Наблюдаемость (фаза 3) — до первого длительного прогона, без исключений.
6. Базовые метрики, затем нагрузка, хаос, целостность.
7. Приёмка по references/release-checklist.md; невыполненные пункты — в отчёт как есть, без округления в свою пользу.

Анти-паттерны

Связанные скиллы

• code-audit-core — мастер-скилл: линзы, шкала P0–P3, форма отчёта.
• sci-search — внешние факты и уровни ✅/📗 для меток [В].
• ~/.claude/references/systematic-debugging.md (#DBG-1) — один воспроизводимый баг, а не поиск неизвестных: сначала причина, потом правка; три неудачных фикса — вопрос к архитектуре.
• product-dev-cycle — тест до кода, мутационная приёмка, цикл ветки, приём критики.
• six-corner-audit — гейт перед мержем и публикацией.
• incident-log — фиксация случившегося отказа и уроков из него.
• md-doc — вёрстка отчёта и плана для оператора.