kodu 2.1.3 → 2.2.0

package/skills/audit-api-contracts/SKILL.md

@@ -0,0 +1,201 @@
+---
+name: audit-api-contracts
+description: >
+  Аудит API-контрактов: консистентность форм ответов, HTTP-коды, версионирование,
+  документация vs реализация, GraphQL/REST конвенции. Запускай при /audit-api-contracts.
+---
+
+## Правило применимости (Relevance Rule)
+
+Применим к коду с HTTP-роутингом, REST/GraphQL API, контроллерами, схемами запросов/ответов, OpenAPI/Swagger спецификациями. Для CLI-инструментов и internal-only функций без HTTP-интерфейса — верни пустой ответ.
+
+## Runtime Detection & Stack Profile
+
+Этот аудит стек-агностичен: проверки сформулированы нейтрально, а конкретика
+(инструменты, идиомы, анти-паттерны, примеры) берётся из профиля стека.
+
+1. **Профиль передан контекстом?** Если оркестратор `/audit` передал
+   `runtime=<id>` и/или содержимое профиля — используй его, шаги 2–3 пропусти.
+
+2. **Иначе определи РОВНО ОДИН рантайм** этого каталога:
+   ```bash
+   if   [ -f package.json ]; then echo "runtime=node"
+   elif [ -f go.mod ]; then echo "runtime=go"
+   elif [ -f pyproject.toml ] || [ -f requirements.txt ] || [ -f setup.py ]; then echo "runtime=python"
+   elif [ -f Cargo.toml ]; then echo "runtime=rust"
+   elif [ -f pom.xml ] || ls build.gradle* settings.gradle* >/dev/null 2>&1; then echo "runtime=java"
+   else echo "runtime=generic"; fi
+   ```
+   Один запуск = один рантайм; не миксуй backend и frontend. Если найдено
+   несколько маркеров (монорепо) — выбери соответствующий текущему scope/анализируемым
+   файлам и зафиксируй выбор в разделе Audit Coverage.
+
+3. **Загрузи профиль** через Read: `./skills/audit/stacks/<runtime>.md`
+   (fallback `./skills/audit/stacks/_generic.md`, если файл не найден).
+
+Дальше используй профиль:
+- **Инструменты** — из секции «Tooling by category» профиля (раздел
+  «Инструментальная поддержка» ниже ссылается на категории, а не на команды).
+- **Ожидания PASS** — из «Idioms»; **формулировки FAIL** — из «Anti-patterns».
+- **Точечные подсказки** — из «Check-ID hints» по префиксу `API-`.
+- Если профиль `tier: general` или `runtime=generic` → стек-специфичные находки
+  без однозначного evidence помечай `🔍 UNVERIFIED`, а не `❌ FAIL`. Проверки,
+  чей механизм в рантайме отсутствует, помечай `N/A`.
+
+## Severity Guide
+
+| Severity | Критерий назначения |
+|----------|---------------------|
+| 🔴 Critical | RCE, auth bypass, data corruption, необратимый финансовый риск |
+| 🟠 High | Падение production, privilege escalation, утечка данных |
+| 🟡 Medium | Деградация производительности или поддерживаемости без immediate outage |
+| 🟢 Low | Стиль, читаемость, слабое нарушение конвенции |
+
+Правило: severity = impact × exploitability × blast radius. Одинаковый паттерн → одинаковый severity между аудитами.
+
+## Чеклист
+
+| Check ID | Проверка |
+|----------|----------|
+| API-01 | Форма ответов консистентна — единый envelope или его отсутствие по всему API |
+| API-02 | HTTP статус-коды семантически корректны (201 при создании, 4xx для client errors) |
+| API-03 | Error responses машиночитаемы и консистентны по структуре |
+| API-04 | Именование полей консистентно (camelCase или snake_case, не смешано) |
+| API-05 | Stack trace и внутренние детали не попадают в error responses |
+| API-06 | Пагинация включает метаданные (total/hasNext) где применима |
+| API-07 | Публичный API имеет стратегию версионирования |
+
+## Правила верификации
+
+1. **Только чеклист**: оценивай ТОЛЬКО проверки выше. Не добавляй новые.
+2. **Явная верификация = PASS**: ставь `✅ PASS` только если явно проверил механизм (нашёл схему, конфиг, guard) и подтвердил отсутствие нарушения — укажи что именно проверено.
+3. **Нет доказательства = UNVERIFIED**: не можешь указать `файл:строка` ни для нарушения, ни для подтверждения — ставь `🔍 UNVERIFIED`.
+4. **Baseline приоритетен**: check_id есть в `docs/audit-baseline.yml` → `⏸ ACCEPTED`.
+5. **Только 🔴/🟠 FAIL требуют решения**: 🟡/🟢 — решение необязательно.
+
+## Evidence Quality Rules
+
+Любой `❌ FAIL` обязан содержать:
+- Точный `file:line`
+- Минимальный код-фрагмент (1–3 строки)
+- Causal chain: почему именно это нарушение → какой риск возникает
+
+Запрещено:
+- Предполагать runtime behavior без evidence в коде
+- Предполагать prod-конфигурацию по dev-конфигу
+- Предполагать отсутствие middleware без проверки всей router chain
+- Если вывод основан на предположении — только `🔍 UNVERIFIED`
+
+## Language Rule
+
+Результаты аудита должны быть написаны простым и понятным языком. Избегай сложных терминов, жаргона и абстрактных понятий без необходимости. Общепринятые технические термины (Docker, HTTP, API, JSON, URL) допустимы. Описывай проблемы так, чтобы они были понятны разработчику любого уровня, а не только узкому специалисту в данной области.
+
+## Baseline
+
+До анализа:
+```bash
+if [ ! -f ./docs/audit-baseline.yml ]; then
+  mkdir -p ./docs
+  cp ./skills/audit/audit-baseline-template.yml ./docs/audit-baseline.yml 2>/dev/null || \
+    printf "accepted: []\n" > ./docs/audit-baseline.yml
+fi
+cat ./docs/audit-baseline.yml
+```
+
+## Контекст анализа
+
+> Примеры в этом разделе и в таблице вывода (Express-style middleware, `HttpException`)
+> иллюстративны. Контракт может быть REST (Node: Express/Fastify; Go: chi-роуты)
+> или GraphQL (Node: Apollo/Yoga; Go: gqlgen-резолверы). Check ID и их смысл
+> одинаковы для любого транспорта — конкретику бери из загруженного профиля.
+
+**API-01 — Консистентная форма ответов:**
+- Одна сущность возвращается с разными наборами полей в разных endpoint'ах
+- Envelope-паттерн применяется непоследовательно (`{ data: ... }` в одних, прямой объект в других)
+- Разная структура success-ответов для схожих операций
+
+**API-02 — Семантически корректные HTTP-коды:**
+- 200 возвращается при ошибке (тело содержит `{ error: "..." }` но статус 200)
+- 500 возвращается для пользовательских ошибок (должен быть 4xx)
+- 201 не используется при создании ресурса (POST → 200 вместо 201)
+- 204 возвращается с телом ответа (No Content не должен иметь body)
+- GET-запрос с побочными эффектами (изменение состояния)
+
+**API-03 — Machine-readable и консистентные error responses:**
+- Разный формат ошибок в разных endpoint'ах
+- Отсутствие machine-readable error code (только human-readable message)
+- Разная структура ошибок для validation vs auth vs server errors
+
+**API-04 — Консистентное именование полей:**
+- Разные имена для одного поля (`userId` vs `user_id` vs `id`)
+- Смешение camelCase и snake_case в одном API
+- Непоследовательные аббревиатуры (`orgId` vs `organisationId`)
+
+**API-05 — Нет технических деталей в responses:**
+- Stack trace в ответе в production
+- Внутренние пути файловой системы в error messages
+- SQL-ошибки или DB-специфичные сообщения в API responses
+- Версии библиотек/фреймворка в заголовках или телах ответов
+
+**API-06 — Пагинация с метаданными:**
+- Разные паттерны пагинации в одном API (offset + cursor смешаны)
+- Отсутствие метаданных пагинации (total, hasNext) при наличии пагинации
+- Нет максимального лимита страницы (клиент может запросить всё)
+
+**API-07 — Стратегия версионирования:**
+- Поле удалено или переименовано без версионирования API
+- Тип поля изменён (string → number) без версионирования
+- Нет стратегии версионирования при наличии публичного API (URL versioning, header versioning)
+
+## Граница с другими аудитами
+
+- **Stack trace в ответах** (API-05) — первичный: `audit-errors` (ERR-02). Если обнаружено здесь — добавь cross-ref «*см. ERR-02*» в доказательство, не создавай дублирующий `❌ FAIL`.
+- **Валидация входных данных** (отсутствие проверки полей) → `audit-validation`
+- **OWASP-уязвимости** (injection, auth) → `audit-owasp`
+- **Производительность** (N+1 без DataLoader) → `audit-performance`
+
+## Формат вывода
+
+| Check ID | Проверка | Статус | Уверенность | Доказательство | Решение | Исправлено |
+|----------|----------|--------|-------------|----------------|---------|------------|
+| API-01 | Форма ответов консистентна — единый envelope или его отсутствие по всему API | ✅ PASS | High | `routes/` — все ответы используют единый `{ data, error }` envelope | — | — |
+| API-02 | HTTP статус-коды семантически корректны (201 при создании, 4xx для client errors) | ❌ FAIL 🟠 | High | `routes/auth.ts:78` | **1. Заменить res.status(200) на res.status(400) для ошибок валидации** \\ 2. Добавить централизованный error middleware \\ 3. Использовать HTTP Exception классы (HttpException) | Нет |
+| API-07 | Публичный API имеет стратегию версионирования | ⏸ ACCEPTED | Medium | — | В baseline: внутренний API без внешних клиентов | — |
+
+Статусы: `✅ PASS` / `❌ FAIL 🔴` / `❌ FAIL 🟠` / `❌ FAIL 🟡` / `❌ FAIL 🟢` / `⏸ ACCEPTED` / `🔍 UNVERIFIED`
+
+Уверенность: `High` — проверил несколько ключевых файлов, паттерн очевиден / `Medium` — проверил выборочно, паттерн вероятен / `Low` — ограниченный контекст, полная уверенность невозможна
+
+Для `❌ FAIL`: ровно 3 варианта решения, разделитель `\\`, вариант 1 жирным.
+
+`Исправлено`: FAIL → `Нет` (разработчик меняет на `✅ Да` вручную после фикса). PASS / ACCEPTED / UNVERIFIED → `—`.
+
+Требования к решениям:
+- Взаимно исключающие (не перефразировки одного и того же)
+- Соответствуют текущему стеку проекта (не предлагать смену фреймворка)
+- Не требуют переписать всю систему — realistic migration cost
+- Вариант 3 может быть «оставить, задокументировать причину» при наличии обоснования
+
+В конце отчёта добавь раздел покрытия:
+```
+## Audit Coverage
+Проверено: src/module1/**, src/module2/**
+Пропущено: scripts/**, migrations/**, tests/**
+Файлов проверено: N | Пропущено: N
+```
+
+Если все PASS — выведи: `✅ API-контракты консистентны.`
+
+## Сохранение результатов
+
+1. Найди папку сессии:
+   ```bash
+   ls -dt ./docs/audits/[0-9]*/ 2>/dev/null | head -1 | sed 's|/$||'
+   ```
+   Если пусто — создай: `mkdir -p ./docs/audits/$(date +"%Y-%m-%d_%H-%M")`
+2. Сохрани через Write: `<AUDIT_DIR>/audit-api-contracts.md`
+
+```
+# Audit Report: API Contracts — <YYYY-MM-DD HH:MM>
+<таблица>
+```

package/skills/audit-architecture/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: audit-architecture
+description: >
+  Аудит архитектуры и файловой структуры: корректность связей между слоями, нарушения
+  dependency rules, структура папок, circular dependencies. Запускай при /audit-architecture.
+---
+
+## Правило применимости (Relevance Rule)
+
+Применим к проектам с выраженной слоистой архитектурой (MVC, Clean Architecture, DDD, Hexagonal). Для single-file скриптов или утилит без архитектурного деления — верни пустой ответ.
+
+## Runtime Detection & Stack Profile
+
+Этот аудит стек-агностичен: проверки сформулированы нейтрально, а конкретика
+(инструменты, идиомы, анти-паттерны, примеры) берётся из профиля стека.
+
+1. **Профиль передан контекстом?** Если оркестратор `/audit` передал
+   `runtime=<id>` и/или содержимое профиля — используй его, шаги 2–3 пропусти.
+
+2. **Иначе определи РОВНО ОДИН рантайм** этого каталога:
+   ```bash
+   if   [ -f package.json ]; then echo "runtime=node"
+   elif [ -f go.mod ]; then echo "runtime=go"
+   elif [ -f pyproject.toml ] || [ -f requirements.txt ] || [ -f setup.py ]; then echo "runtime=python"
+   elif [ -f Cargo.toml ]; then echo "runtime=rust"
+   elif [ -f pom.xml ] || ls build.gradle* settings.gradle* >/dev/null 2>&1; then echo "runtime=java"
+   else echo "runtime=generic"; fi
+   ```
+   Один запуск = один рантайм; не миксуй backend и frontend. Если найдено
+   несколько маркеров (монорепо) — выбери соответствующий текущему scope/анализируемым
+   файлам и зафиксируй выбор в разделе Audit Coverage.
+
+3. **Загрузи профиль** через Read: `./skills/audit/stacks/<runtime>.md`
+   (fallback `./skills/audit/stacks/_generic.md`, если файл не найден).
+
+Дальше используй профиль:
+- **Инструменты** — из секции «Tooling by category» профиля (раздел
+  «Инструментальная поддержка» ниже ссылается на категории, а не на команды).
+- **Ожидания PASS** — из «Idioms»; **формулировки FAIL** — из «Anti-patterns».
+- **Точечные подсказки** — из «Check-ID hints» по префиксу `ARC-`.
+- Если профиль `tier: general` или `runtime=generic` → стек-специфичные находки
+  без однозначного evidence помечай `🔍 UNVERIFIED`, а не `❌ FAIL`. Проверки,
+  чей механизм в рантайме отсутствует, помечай `N/A`.
+
+## Severity Guide
+
+| Severity | Критерий назначения |
+|----------|---------------------|
+| 🔴 Critical | RCE, auth bypass, data corruption, необратимый финансовый риск |
+| 🟠 High | Падение production, privilege escalation, утечка данных |
+| 🟡 Medium | Деградация производительности или поддерживаемости без immediate outage |
+| 🟢 Low | Стиль, читаемость, слабое нарушение конвенции |
+
+Правило: severity = impact × exploitability × blast radius. Одинаковый паттерн → одинаковый severity между аудитами.
+
+## Чеклист
+
+| Check ID | Проверка |
+|----------|----------|
+| ARC-01 | Бизнес-логика вынесена из route handlers в service/domain слой |
+| ARC-02 | Presentation layer не взаимодействует с БД напрямую |
+| ARC-03 | Нет circular dependencies между модулями |
+| ARC-04 | Нет god-объектов: файлы и классы имеют единственную ответственность |
+| ARC-05 | Конфигурация и env-переменные изолированы в config-модуле |
+| ARC-06 | Внешние зависимости инжектируются (DI), не импортируются напрямую |
+| ARC-07 | Доменный слой не импортирует инфраструктурные модули |
+
+## Правила верификации
+
+1. **Только чеклист**: оценивай ТОЛЬКО проверки выше. Не добавляй новые.
+2. **Явная верификация = PASS**: ставь `✅ PASS` только если явно проверил механизм (нашёл схему, конфиг, guard) и подтвердил отсутствие нарушения — укажи что именно проверено.
+3. **Нет доказательства = UNVERIFIED**: не можешь указать `файл:строка` ни для нарушения, ни для подтверждения — ставь `🔍 UNVERIFIED`.
+4. **Baseline приоритетен**: check_id есть в `docs/audit-baseline.yml` → `⏸ ACCEPTED`.
+5. **Только 🔴/🟠 FAIL требуют решения**: 🟡/🟢 — решение необязательно.
+
+## Evidence Quality Rules
+
+Любой `❌ FAIL` обязан содержать:
+- Точный `file:line`
+- Минимальный код-фрагмент (1–3 строки)
+- Causal chain: почему именно это нарушение → какой риск возникает
+
+Запрещено:
+- Предполагать runtime behavior без evidence в коде
+- Предполагать prod-конфигурацию по dev-конфигу
+- Предполагать отсутствие middleware без проверки всей router chain
+- Если вывод основан на предположении — только `🔍 UNVERIFIED`
+
+## Language Rule
+
+Результаты аудита должны быть написаны простым и понятным языком. Избегай сложных терминов, жаргона и абстрактных понятий без необходимости. Общепринятые технические термины (Docker, HTTP, API, JSON, URL) допустимы. Описывай проблемы так, чтобы они были понятны разработчику любого уровня, а не только узкому специалисту в данной области.
+
+## Baseline
+
+До анализа:
+```bash
+if [ ! -f ./docs/audit-baseline.yml ]; then
+  mkdir -p ./docs
+  cp ./skills/audit/audit-baseline-template.yml ./docs/audit-baseline.yml 2>/dev/null || \
+    printf "accepted: []\n" > ./docs/audit-baseline.yml
+fi
+cat ./docs/audit-baseline.yml
+```
+
+## Контекст анализа
+
+**ARC-01 — Бизнес-логика в service/domain слое:**
+- Бизнес-правила и вычисления прямо в route handler / controller
+- Сложные условия и трансформации данных в middleware вместо сервиса
+- Операции с несколькими сущностями выполняются в handler без сервиса
+
+**ARC-02 — Presentation layer без прямых DB-вызовов:**
+- Прямые обращения к ORM/query builder из роутеров/контроллеров
+- Импорт репозиториев или DB-клиента непосредственно в слой представления
+- SQL / Prisma / Mongoose вызовы в middleware (примеры иллюстративны — Node; конкретные ORM/драйверы текущего рантайма см. в профиле, секции Idioms/Anti-patterns)
+
+**ARC-03 — Нет circular dependencies:**
+- Модуль A импортирует модуль B, который импортирует модуль A
+- Circular deps через несколько уровней (A→B→C→A)
+- Прямые импорты между feature-модулями (должны идти через shared)
+
+**ARC-04 — Нет god-объектов:**
+- Файлы >500 строк с несвязанной логикой (несколько разных ответственностей)
+- Классы с методами из разных доменных областей
+- Модуль делает несвязанные вещи (low cohesion)
+
+**ARC-05 — Конфигурация изолирована:**
+- Доступ к конфигурации/env централизован в одном модуле; чтение env вразброс вне config-модуля — нарушение (профиль уточняет механизм: `process.env` в Node / `os.Getenv` в Go / `caarlos0/env`-теги и т.п.)
+- Магические строки с именами env-переменных разбросаны по коду
+- Нет единой точки валидации конфигурации при старте приложения
+
+**ARC-06 — Внешние зависимости инжектируются:**
+- HTTP-клиенты, email-сервисы, БД-клиенты создаются внутри функций (не инжектируются)
+- Зависимость от конкретных реализаций вместо интерфейсов/абстракций
+- Отсутствие dependency injection делает код нетестируемым (нельзя подменить в тестах)
+
+**Направление зависимостей (Dependency Rule):**
+> Примеры ниже иллюстративны (Node); конкретные ORM/типы инфраструктуры текущего рантайма см. в профиле (секции Idioms/Anti-patterns/Check-ID hints, ARC-07).
+- Domain/service слой импортирует типы Prisma напрямую (должен через repository interface)
+- Бизнес-логика зависит от Express Request/Response типов
+- Domain entity содержит ORM-декораторы (TypeORM @Entity в domain классе)
+- Нарушение: `domain/ → infrastructure/` (правильно: `infrastructure/ → domain/`)
+
+## Инструментальная поддержка
+
+Для ARC-03 (circular dependencies) и нарушений слоёв используй инструмент
+категории **arch-lint** из профиля стека (секция «Tooling by category»). Используй
+вывод как подсказку и верифицируй каждую находку вручную (`file:line`) перед
+занесением в FAIL. Если ячейка пустая (tier general/generic) — проверяй вручную и
+помечай находки `🔍 UNVERIFIED`.
+
+Примечание: в Go циклы импортов запрещены компилятором, поэтому ARC-03 на уровне
+пакетов — авто-PASS / N/A; проверять нужно только логические слои (см. Check-ID
+hints профиля go).
+
+## Формат вывода
+
+| Check ID | Проверка | Статус | Уверенность | Доказательство | Решение | Исправлено |
+|----------|----------|--------|-------------|----------------|---------|------------|
+| ARC-01 | Бизнес-логика вынесена из route handlers в service/domain слой | ✅ PASS | High | `routes/` — handlers делегируют в services | — | — |
+| ARC-03 | Нет circular dependencies между модулями | ❌ FAIL 🟠 | High | `modules/order/index.ts:3` | **1. Вынести общий код в shared модуль** \\ 2. Применить dependency inversion \\ 3. Разбить модуль на независимые части | Нет |
+| ARC-06 | Внешние зависимости инжектируются (DI), не импортируются напрямую | ⏸ ACCEPTED | Medium | `services/payment.ts:1` | В baseline: refactor запланирован в Q3 | — |
+
+Статусы: `✅ PASS` / `❌ FAIL 🔴` / `❌ FAIL 🟠` / `❌ FAIL 🟡` / `❌ FAIL 🟢` / `⏸ ACCEPTED` / `🔍 UNVERIFIED`
+
+Уверенность: `High` — проверил несколько ключевых файлов, паттерн очевиден / `Medium` — проверил выборочно, паттерн вероятен / `Low` — ограниченный контекст, полная уверенность невозможна
+
+Для `❌ FAIL`: ровно 3 варианта решения, разделитель `\\`, вариант 1 жирным.
+
+`Исправлено`: FAIL → `Нет` (разработчик меняет на `✅ Да` вручную после фикса). PASS / ACCEPTED / UNVERIFIED → `—`.
+
+Требования к решениям:
+- Взаимно исключающие (не перефразировки одного и того же)
+- Соответствуют текущему стеку проекта (не предлагать смену фреймворка)
+- Не требуют переписать всю систему — realistic migration cost
+- Вариант 3 может быть «оставить, задокументировать причину» при наличии обоснования
+
+В конце отчёта добавь раздел покрытия:
+```
+## Audit Coverage
+Проверено: src/module1/**, src/module2/**
+Пропущено: scripts/**, migrations/**, tests/**
+Файлов проверено: N | Пропущено: N
+```
+
+Если все PASS — выведи: `✅ Архитектурные принципы соблюдены.`
+
+## Сохранение результатов
+
+1. Найди папку сессии:
+   ```bash
+   ls -dt ./docs/audits/[0-9]*/ 2>/dev/null | head -1 | sed 's|/$||'
+   ```
+   Если пусто — создай: `mkdir -p ./docs/audits/$(date +"%Y-%m-%d_%H-%M")`
+2. Сохрани через Write: `<AUDIT_DIR>/audit-architecture.md`
+
+```
+# Audit Report: Architecture & File Structure — <YYYY-MM-DD HH:MM>
+<таблица>
+```

package/skills/audit-bugs/SKILL.md

@@ -0,0 +1,226 @@
+---
+name: audit-bugs
+description: >
+  Аудит прямых багов и логических ошибок: неверные условия, off-by-one, null dereference,
+  забытый await, unreachable code, type coercion, мутация аргументов. Запускай при /audit-bugs.
+---
+
+## Правило применимости (Relevance Rule)
+
+Применим к любому коду с бизнес-логикой. Пропускай только автогенерированные файлы (миграции, protobuf-generated, build output) и чисто декларативные конфиги (JSON, YAML без логики).
+
+## Runtime Detection & Stack Profile
+
+Этот аудит стек-агностичен: проверки сформулированы нейтрально, а конкретика
+(инструменты, идиомы, анти-паттерны, примеры) берётся из профиля стека.
+
+1. **Профиль передан контекстом?** Если оркестратор `/audit` передал
+   `runtime=<id>` и/или содержимое профиля — используй его, шаги 2–3 пропусти.
+
+2. **Иначе определи РОВНО ОДИН рантайм** этого каталога:
+   ```bash
+   if   [ -f package.json ]; then echo "runtime=node"
+   elif [ -f go.mod ]; then echo "runtime=go"
+   elif [ -f pyproject.toml ] || [ -f requirements.txt ] || [ -f setup.py ]; then echo "runtime=python"
+   elif [ -f Cargo.toml ]; then echo "runtime=rust"
+   elif [ -f pom.xml ] || ls build.gradle* settings.gradle* >/dev/null 2>&1; then echo "runtime=java"
+   else echo "runtime=generic"; fi
+   ```
+   Один запуск = один рантайм; не миксуй backend и frontend. Если найдено
+   несколько маркеров (монорепо) — выбери соответствующий текущему scope/анализируемым
+   файлам и зафиксируй выбор в разделе Audit Coverage.
+
+3. **Загрузи профиль** через Read: `./skills/audit/stacks/<runtime>.md`
+   (fallback `./skills/audit/stacks/_generic.md`, если файл не найден).
+
+Дальше используй профиль:
+- **Инструменты** — из секции «Tooling by category» профиля (раздел
+  «Инструментальная поддержка» ниже ссылается на категории, а не на команды).
+- **Ожидания PASS** — из «Idioms»; **формулировки FAIL** — из «Anti-patterns».
+- **Точечные подсказки** — из «Check-ID hints» по префиксу `BUG-`.
+- Если профиль `tier: general` или `runtime=generic` → стек-специфичные находки
+  без однозначного evidence помечай `🔍 UNVERIFIED`, а не `❌ FAIL`. Проверки,
+  чей механизм в рантайме отсутствует, помечай `N/A`.
+
+## Severity Guide
+
+| Severity | Критерий назначения |
+|----------|---------------------|
+| 🔴 Critical | RCE, auth bypass, data corruption, необратимый финансовый риск |
+| 🟠 High | Падение production, privilege escalation, утечка данных |
+| 🟡 Medium | Деградация производительности или поддерживаемости без immediate outage |
+| 🟢 Low | Стиль, читаемость, слабое нарушение конвенции |
+
+Правило: severity = impact × exploitability × blast radius. Одинаковый паттерн → одинаковый severity между аудитами.
+
+## Чеклист
+
+| Check ID | Проверка |
+|----------|----------|
+| BUG-01 | Преобразования типов безопасны: ошибки парсинга обрабатываются, нет небезопасного приведения |
+| BUG-02 | Асинхронные/конкурентные вызовы ожидаются корректно, результат не теряется |
+| BUG-03 | Null-safety соблюдается — обращения к свойствам защищены от undefined/null |
+| BUG-04 | Функции не мутируют входные аргументы (sort, splice, object spread) |
+| BUG-05 | Exhaustive handling — все enum/union-ветки обработаны |
+| BUG-06 | Математические guard-условия (деление на ноль, граничные значения) |
+| BUG-07 | Off-by-one: границы диапазонов корректны (`<` vs `<=`, индексы массивов, slice) |
+| BUG-08 | Float comparison не использует `===` для проверки равенства (используется epsilon или toFixed) |
+| BUG-09 | Дата/время хранятся и обрабатываются в UTC, не локальном времени |
+| BUG-10 | RegExp с user input не содержит катастрофического backtracking (ReDoS) |
+
+## Правила верификации
+
+1. **Только чеклист**: оценивай ТОЛЬКО проверки выше. Не добавляй новые.
+2. **Явная верификация = PASS**: ставь `✅ PASS` только если явно проверил механизм (нашёл схему, конфиг, guard) и подтвердил отсутствие нарушения — укажи что именно проверено.
+3. **Нет доказательства = UNVERIFIED**: не можешь указать `файл:строка` ни для нарушения, ни для подтверждения — ставь `🔍 UNVERIFIED`.
+4. **Baseline приоритетен**: check_id есть в `docs/audit-baseline.yml` → `⏸ ACCEPTED`.
+5. **Только 🔴/🟠 FAIL требуют решения**: 🟡/🟢 — решение необязательно.
+
+## Evidence Quality Rules
+
+Любой `❌ FAIL` обязан содержать:
+- Точный `file:line`
+- Минимальный код-фрагмент (1–3 строки)
+- Causal chain: почему именно это нарушение → какой риск возникает
+
+Запрещено:
+- Предполагать runtime behavior без evidence в коде
+- Предполагать prod-конфигурацию по dev-конфигу
+- Предполагать отсутствие middleware без проверки всей router chain
+- Если вывод основан на предположении — только `🔍 UNVERIFIED`
+
+## Language Rule
+
+Результаты аудита должны быть написаны простым и понятным языком. Избегай сложных терминов, жаргона и абстрактных понятий без необходимости. Общепринятые технические термины (Docker, HTTP, API, JSON, URL) допустимы. Описывай проблемы так, чтобы они были понятны разработчику любого уровня, а не только узкому специалисту в данной области.
+
+## Baseline
+
+До анализа:
+```bash
+if [ ! -f ./docs/audit-baseline.yml ]; then
+  mkdir -p ./docs
+  cp ./skills/audit/audit-baseline-template.yml ./docs/audit-baseline.yml 2>/dev/null || \
+    printf "accepted: []\n" > ./docs/audit-baseline.yml
+fi
+cat ./docs/audit-baseline.yml
+```
+
+## Контекст анализа
+
+> Примеры ниже — иллюстративные (Node/TS). Конкретику текущего рантайма бери из
+> загруженного профиля (`stacks/<runtime>.md`, секции Idioms/Anti-patterns/Check-ID hints).
+
+**BUG-01 — Преобразования типов безопасны:**
+- Парсинг строки в число без обработки ошибки/результата
+- Небезопасное приведение типа без проверки успешности
+- Неявное приведение типов с неожиданным результатом
+- Сравнение значений разных типов с неявным coercion
+- В Go это проигнорированная ошибка `strconv` (`v, _ := strconv.Atoi(...)`) или type assertion `x.(T)` без comma-ok; radix/`==`-coercion — **N/A** при отсутствии парсинга строк (см. Check-ID hints профиля).
+
+**BUG-02 — Асинхронные/конкурентные вызовы ожидаются корректно:**
+- Асинхронный вызов запущен, но его результат/ошибка не дожидается
+- Условие на необёрнутом отложенном результате (всегда truthy)
+- Параллельный вызов теряется, потому что не синхронизирован
+- В Node: `await` внутри `forEach` (итерация не ждёт промисов), `if (asyncFn())` вместо `if (await asyncFn())`, async-вызов без `await`, `Promise` без обработки ошибки. В Go синтаксис forEach отсутствует (**N/A**), аналогичный риск — в CON-01.
+
+**BUG-03 — Null-safety соблюдается:**
+- Обращение к свойству без проверки на null/undefined
+- Опциональная цепочка пропущена (`obj.a.b` там где `obj.a` может быть undefined)
+- Деструктуризация без дефолтного значения при возможном undefined
+- В Go: разыменование nil-указателя/интерфейса; обращение к nil-map; запись в nil-map = паника; map-доступ без `v, ok := m[k]`
+
+**BUG-04 — Функции не мутируют входные аргументы:**
+- `Array.sort()` на переданном массиве без предварительного `.slice()`
+- `Array.splice()` изменяет оригинальный массив-аргумент
+- Прямое присваивание свойств объекта-аргумента вместо создания копии через spread
+- В Go: `sort.Slice` мутирует переданный слайс на месте; запись в slice/map-аргумент видна вызывающему
+
+**BUG-05 — Exhaustive handling:**
+- `switch` без `default` на enum-значении — новое значение enum пройдёт незамеченным
+- Union type без обработки всех вариантов в if/else цепочке
+- Отсутствие never-проверки для исчерпывающего TypeScript switch
+- В Go: `switch` по значению без ветки `default`
+
+**BUG-06 — Математические guard-условия:**
+- Деление на ноль без guard-проверки знаменателя
+- `Number()` / `parseInt()` без проверки результата на NaN перед использованием
+- Граничные значения не проверяются (отрицательный индекс, пустой массив)
+
+**BUG-07 — Off-by-one:**
+- `for (i = 0; i <= arr.length; i++)` — выход за границы массива
+- `slice(0, n)` / `slice(0, n-1)` — потеря или дублирование последнего элемента
+- Сравнение `index < arr.length - 1` там где нужно `index < arr.length`
+- Пагинация: `offset * limit` vs `(offset - 1) * limit` при 1-based страницах
+
+**BUG-08 — Float comparison:**
+- `a === b` где a и b — результаты float-арифметики (0.1 + 0.2 !== 0.3)
+- Сравнение денежных сумм через float вместо integer cents / BigDecimal
+- Условие `if (parseFloat(x) === 1.0)` вместо `Math.abs(x - 1.0) < epsilon`
+- В Go: сравнение `float64` через `==`; деньги — в `int64` (центы) или `shopspring/decimal`
+
+**BUG-09 — Дата/время в UTC:**
+- `new Date()` без явной UTC-обработки — результат зависит от timezone сервера
+- Сравнение дат через `toLocaleDateString()` — зависит от локали
+- Хранение timestamp как local datetime строки вместо ISO 8601 с `Z`
+- `new Date('2024-01-01')` парсится как UTC, `new Date('2024-01-01 00:00')` — как local
+- В Go: `time.Now()` вместо `time.Now().UTC()` — результат зависит от часового пояса сервера
+
+**BUG-10 — ReDoS:**
+- `new RegExp(userInput)` — пользователь контролирует регулярное выражение
+- Вложенные quantifiers на перекрывающихся классах: `(a+)+`, `(a*)*`, `([a-zA-Z]+\s?)+`
+- Проверка: `'a'.repeat(50000) + 'x'` на подозрительном regex вешает event loop
+- Особо опасно в middleware (auth, routing), где regex применяется к каждому запросу
+- В Go движок `regexp` (RE2) не имеет backtracking → ReDoS практически невозможен; помечай `N/A` или `Low` (см. профиль)
+
+## Граница с другими аудитами
+
+- **Обработка ошибок** (timeout, retry, circuit breaker) → `audit-errors`
+- **Race conditions, транзакции** → `audit-concurrency`
+- **Валидация входных данных** → `audit-validation`
+- **Безопасность (injection, XSS)** → `audit-owasp`
+
+## Формат вывода
+
+| Check ID | Проверка | Статус | Уверенность | Доказательство | Решение | Исправлено |
+|----------|----------|--------|-------------|----------------|---------|------------|
+| BUG-01 | Преобразования типов безопасны: ошибки парсинга обрабатываются, нет небезопасного приведения | ✅ PASS | High | `src/` — parseInt всегда с radix | — | — |
+| BUG-03 | Null-safety соблюдается — обращения к свойствам защищены от undefined/null | ❌ FAIL 🟠 | High | `services/order.ts:55` | **1. Добавить опциональную цепочку: `user?.address?.city`** \\ 2. Добавить guard-проверку перед обращением \\ 3. Использовать nullish coalescing с дефолтом | Нет |
+| BUG-05 | Exhaustive handling — все enum/union-ветки обработаны | ⏸ ACCEPTED | Medium | `handlers/event.ts:23` | В baseline: exhaustive check через TypeScript never | — |
+
+Статусы: `✅ PASS` / `❌ FAIL 🔴` / `❌ FAIL 🟠` / `❌ FAIL 🟡` / `❌ FAIL 🟢` / `⏸ ACCEPTED` / `🔍 UNVERIFIED`
+
+Уверенность: `High` — проверил несколько ключевых файлов, паттерн очевиден / `Medium` — проверил выборочно, паттерн вероятен / `Low` — ограниченный контекст, полная уверенность невозможна
+
+Для `❌ FAIL`: ровно 3 варианта решения, разделитель `\\`, вариант 1 жирным.
+
+`Исправлено`: FAIL → `Нет` (разработчик меняет на `✅ Да` вручную после фикса). PASS / ACCEPTED / UNVERIFIED → `—`.
+
+Требования к решениям:
+- Взаимно исключающие (не перефразировки одного и того же)
+- Соответствуют текущему стеку проекта (не предлагать смену фреймворка)
+- Не требуют переписать всю систему — realistic migration cost
+- Вариант 3 может быть «оставить, задокументировать причину» при наличии обоснования
+
+В конце отчёта добавь раздел покрытия:
+```
+## Audit Coverage
+Проверено: src/module1/**, src/module2/**
+Пропущено: scripts/**, migrations/**, tests/**
+Файлов проверено: N | Пропущено: N
+```
+
+Если все PASS — выведи: `✅ Явных логических ошибок не обнаружено.`
+
+## Сохранение результатов
+
+1. Найди папку сессии:
+   ```bash
+   ls -dt ./docs/audits/[0-9]*/ 2>/dev/null | head -1 | sed 's|/$||'
+   ```
+   Если пусто — создай: `mkdir -p ./docs/audits/$(date +"%Y-%m-%d_%H-%M")`
+2. Сохрани через Write: `<AUDIT_DIR>/audit-bugs.md`
+
+```
+# Audit Report: Bugs & Logic Errors — <YYYY-MM-DD HH:MM>
+<таблица>
+```