# Strict Audit

> Жёсткий No-Go аудит для safety-critical архитектуры, кода и PR: выдаёт PASS/FAIL, блокирующие замечания и обязательные доказательства по таймингам, измерениям и fault-injection. Использовать перед включением силовой части и для спорных safety/timing-изменений; не использовать как обычное обзорное ревью по умолчанию.

- Skill: `aibot88/strict-audit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aibot88/strict-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aibot88/strict-audit/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: aibot88 (https://skillmd.com/u/aibot88)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/aibot88/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](../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): что улучшить без блокировки.