Strict Audit

Skill: Жёсткий аудит (Safety Gate)

Миссия

Нулевая терпимость к рискам. Цель — найти дефекты, которые могут привести к:

• неконтролируемому включению силовой части,
• потере аппаратного пути отключения,
• “варке вслепую” при невалидных измерениях/командах,
• недетерминизму таймингов в критических доменах.

Источники правды

Используй role-based owner priority, а не один линейный список:

• safety policy, fault classes, latch/recovery, fail-closed: docs/SAFETY.md
• hardware/timing/interface facts и safety-линии платы: docs/PROJECT_CONTEXT.md, docs/HW_IO_MAP.md
• каталог уже действующих защитных функций, их детекта, пути реакции и привязки к доказательствам: docs/SAFETY_FUNCTIONS.md
• модульные и временные границы: docs/ARCHITECTURE.md
• термины и точные значения слов: docs/GLOSSARY.md
• wire contract и field semantics: профильный protocol-doc (docs/protocols/PROTOCOL_TK_ETHERCAT.md, docs/protocols/PCCOM4.02.md)
• proof obligations и минимальная регрессия: docs/TEST_PLAN.md
• остальное только как supporting layer через docs/DOCS_INDEX.md

Повторяемая фактическая основа для skills внутри репозитория:

• путь отключения и безопасное состояние: welding-safety-core
• доказательства и измерения: welding-verification-core

Правила аудита

1. No-Go policy
   • Если решение нарушает docs/SAFETY.md или safety-инварианты — выдать [AUDIT FAIL] и указать конкретный пункт нарушения.
2. Тайминги — только с доказательствами
   • Любые утверждения “успеем/быстро/в середине периода” без плана измерений (GPIO/осциллограф/trace) считаются дефектом.
3. Аппаратный путь отключения обязателен
   • Критические аварии должны сохранять базовую схему из welding-safety-core: TIM1 BKIN/BKIN2 + STO, без зависимости от RTOS, задач и EtherCAT.
   • Любая попытка выдать SKYPER_ERRIN или другой вторичный путь запрета за замену базового STO считается No-Go.
4. Никаких “скрытых” допущений
   • Любая неуверенность фиксируется как assumption или как вопрос (но в режиме audit — это обычно FAIL, если влияет на safety).
5. Минимальные исправления
   • Не предлагать большой рефакторинг вместо точечного исправления.

Формат вывода (контракт)

Начинай ответ строго с:

• [AUDIT PASS] или [AUDIT FAIL]

Далее:

1. No-Go пункты (если FAIL): что именно опасно, почему, где в коде/архитектуре, минимальный фикс.
2. Обязательные доказательства: что измерить/какие fault-injection сценарии прогнать.
3. Нефатальные замечания (если PASS): что улучшить без блокировки.