Strict Audit

---
name: strict-audit
version: 0.3.0
description: >
  Жёсткий No-Go аудит для safety-critical архитектуры, кода и PR: выдаёт PASS/FAIL,
  блокирующие замечания и обязательные доказательства по таймингам, измерениям и fault-injection.
  Использовать перед включением силовой части и для спорных safety/timing-изменений;
  не использовать как обычное обзорное ревью по умолчанию.
tags: ["audit","safety","no-go","timing","review","embedded"]
project_context: "docs/PROJECT_CONTEXT.md"
glossary: "docs/GLOSSARY.md"
when_to_use:
  - "перед включением силовой части/стендовыми испытаниями"
  - "когда решение/патч затрагивает safety, BKIN/BKIN2, `STO`, вторичный путь запрета, watchdog, тайминги"
  - "когда нужен однозначный вердикт PASS/FAIL с блокирующими пунктами"
outputs:
  - "Статус: [AUDIT PASS] или [AUDIT FAIL]"
  - "Блокирующие замечания (No-Go) + минимальные исправления"
  - "Что измерить/доказать (GPIO/осциллограф/HIL/fault-injection)"
---

# 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](../references/welding-safety-core.md)
- доказательства и измерения: [welding-verification-core](../references/welding-verification-core.md)

## Правила аудита
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): что улучшить без блокировки.