kodu 2.1.2 → 2.2.0

package/skills/audit-matrix/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: audit-matrix
+description: >
+   Строит архитектурную модель системы и анализирует сценарии сбоев
+   для обнаруженных компонентов и их связей. Запускается при /audit-matrix.
+---
+
+## Задача
+
+Верхнеуровневый архитектурный аудит: найти крупные компоненты системы, их связи
+и системные риски (каскадные сбои, узкие места, отсутствие защиты на уровне архитектуры).
+Не ищи мелкие баги — это задача других аудитов.
+
+Не полагайся на предопределённые списки технологий. Адаптируйся к любому стеку.
+
+**Группируй похожие сущности.** Несколько однотипных сервисов, реплик, воркеров — один компонент.
+Пример: 3 реплики payment-worker → компонент «Payment Workers». Не плоди строки ради детализации.
+
+---
+
+## Язык
+
+Пиши так, чтобы понял джун на первой неделе работы.
+Короткие фразы, без канцелярита, без умных терминов.
+
+**Объяснение риска** — как будто рассказываешь коллеге за обедом:
+✅ «Если БД тормозит, сайт ляжет для всех через 5 секунд»
+❌ «Исчерпание пула соединений в условиях конкурентной нагрузки приводит к деградации»
+❌ «Всё сломается»
+
+**Решение** — что сделать и зачем:
+✅ «Ждать ответа от БД не больше 5 секунд (`timeout: 5000` в конфиге)»
+❌ «Сконфигурировать connectionTimeoutMillis»
+❌ «Внедрить service mesh»
+
+Если нужен термин — сразу расшифруй:
+«Circuit breaker (предохранитель: если внешний сервис падает, перестаём его дёргать)».
+
+---
+
+## Шаг 1 — Сессия
+
+```bash
+LATEST=$(ls -dt ./docs/audits/[0-9]*/ 2>/dev/null | head -1)
+SESSION=${LATEST:-./docs/audits/$(date +"%Y-%m-%d_%H-%M")}
+mkdir -p "$SESSION" && echo "Session: $SESSION"
+```
+
+---
+
+## Шаг 2 — Обнаружение компонентов
+
+Для каждого зафиксируй: название, роль, размещение (Docker/облако/SaaS),
+как обнаружен (`файл:строка`).
+
+**Правило группировки.** Объединяй в один компонент:
+- реплики одного сервиса
+- воркеры одной очереди
+- микросервисы одной области, если риски у них одинаковые
+- несколько таблиц/коллекций одной БД → компонент «Database», а не «Users DB», «Orders DB»
+
+Если после группировки осталось >12 компонентов — объединяй ещё смелее.
+
+---
+
+## Шаг 3 — Граф компонентов
+
+Не ищи адреса через grep — **проследи жизненный цикл конфигурации**.
+
+Построй матрицу: строки — кто вызывает, столбцы — кого вызывают.
+В ячейке — **зачем** они связаны, а не протокол. Глагол + объект, до 5 слов.
+
+Пустая ячейка = связи нет.
+
+```
+| Кто \ Кого   | Frontend | Backend | База | Редиска | Платежи |
+|--------------|----------|---------|------|---------|---------|
+| Frontend     |          | шлёт заказы |   |         |         |
+| Backend      |          |         | хранит заказы | кэш сессий | списывает деньги |
+| Воркер       |          |         | читает задачи |      |         |
+| Платежи      |          | шлёт статус |   |         |         |
+```
+
+Если в ячейке не помещается — упрощай. Не «асинхронно публикует событие оплаты в очередь» → «шлёт статус оплаты».
+
+---
+
+## Шаг 4 — Анализ рисков
+
+Сопоставляй **компоненты и их клиенты** (Шаг 2)
+с настройками подключения (Шаг 3).
+Если библиотека умеет таймауты и повторы, а код их не выставляет — это риск.
+
+Подходи как «злой гений»: не доверяй компонентам внутри сети, ищи редкие, но разрушительные сценарии.
+Находи **реальные** риски. Если компонент надёжен — так и напиши:
+«Рисков нет: облачный сервис с авто-восстановлением».
+Не выдумывай проблемы ради количества.
+
+### Как описывать опасность
+
+Столбец **«В чём опасность»** — главная часть таблицы. В одной фразе:
+1. Что ломается (причина)
+2. Что из-за этого происходит (механика)
+3. Что видит пользователь или бизнес (последствие)
+
+✅ «Внешний API тупит → запросы копятся → через 5 секунд сайт падает для всех»
+✅ «Две транзакции одновременно списали деньги → баланс ушёл в минус, найдём только в конце месяца»
+❌ «Отказ сервиса приводит к каскадной деградации» (джун не поймёт)
+❌ «Race condition в биллинге» (термин без расшифровки)
+
+### Как описывать решение
+
+Принцип Парето: одно действие, которое закроет 80% проблемы.
+Формула: **что сделать + зачем + конкретный параметр в скобках**.
+
+✅ «Ждать ответа от БД не больше 5 секунд, чтобы зависшие запросы не копились (`timeout: 5000`)»
+✅ «Добавить предохранитель: если Платежи не отвечают 3 раза подряд, перестать их дёргать на минуту (библиотека opossum)»
+✅ «Завернуть списание и обновление баланса в одну транзакцию (`BEGIN` … `COMMIT`)»
+
+❌ «Переписать сервис на event-sourcing» (рефакторинг, не фикс)
+❌ «Внедрить service mesh» (огромная задача)
+❌ `connectionTimeoutMillis: 5000` (без объяснения, зачем)
+
+Если проблема не чинится точечно — пиши `⚠ нужен рефакторинг` и одну строку, в какую сторону.
+
+### Каскадные сценарии
+
+Описывай отдельно **только** если сценарий:
+- затрагивает **≥3 компонентов**, И
+- имеет свою механику (не сводится к одному риску компонента).
+
+```
+X1: Frontend → Backend → Payments
+В чём опасность: Платежи тупят → бэкенд ждёт → через 10 секунд весь сайт отдаёт 503, хотя сама база и фронт живы
+Решение: ждать ответа от Платежей не больше 3 секунд + предохранитель
+Подтверждение: `src/payment.ts:15` — Stripe без таймаута
+```
+
+---
+
+## Шаг 5 — Вывод
+
+Сохрани `{SESSION}/audit-matrix.md`:
+
+```markdown
+# Матрица — {project} — {date}
+
+## TL;DR
+- **Архитектура:** [монолит / микросервисы / serverless / монорепо]
+- **Компонентов:** N
+- **Критических рисков (🔴/🟠):** N
+- **Главный риск:** [одно предложение]
+
+## Граф компонентов
+
+| Кто \ Кого | Frontend | Backend | База | Редиска | Платежи |
+|------------|----------|---------|------|---------|---------|
+| Frontend   |          | шлёт заказы |   |         |         |
+| Backend    |          |         | хранит заказы | кэш сессий | списывает деньги |
+| Воркер     |          |         | читает задачи |      |         |
+
+Связей: N. Синхронных (ждут ответа): N — это главный источник каскадных падений.
+
+## Критические задачи
+
+Сводка всех 🔴/🟠 — и по компонентам, и каскадных.
+
+| # | В чём опасность | Компонент | Риск | Решение | Файл |
+|---|----------------|-----------|------|---------|------|
+| 1 | БД тупит → запросы копятся → через 5 секунд сайт падает для всех | База | 🔴 | Ждать БД не больше 5 секунд, увеличить пул соединений (`timeout: 5000`, `max: 20`) | `src/db.ts:12` ❌ |
+| 2 | Платежи тупят → бэкенд ждёт → весь сайт отдаёт 503 | Платежи | 🔴 | Таймаут 3 секунды + предохранитель | `src/payment.ts:15` ❌ |
+
+## {Компонент}
+
+**Роль:** … • **Где:** Docker • **Найден:** `file:line`
+
+| # | Сценарий | В чём опасность | Риск | Решение | Файл |
+|---|----------|-----------------|------|---------|------|
+| A1 | БД недоступна | БД тупит → запросы копятся → через 5 секунд сайт падает для всех при 100 запросах/сек | 🔴 | Ждать БД не больше 5 секунд, повторять 3 раза (`timeout: 5000`, `maxRetries: 3`) | `src/db.ts:12` ❌ |
+| Z1 | Обрыв транзакции | Списание и обновление баланса не обёрнуты в транзакцию → деньги списались, баланс не обновился. Найдём только при сверке | 🔴 | Завернуть в одну транзакцию (`BEGIN` … `COMMIT`) | `src/billing.ts:44` ❌ |
+| N1 | Редиска падает | Кэш отваливается → бэкенд идёт напрямую в БД. Медленнее, но работает | 🟡 | Защита уже есть, ничего делать не надо | `src/cache.ts:8` ✅ |
+
+Если рисков нет — пиши одной строкой: «Рисков нет: облачный сервис с авто-восстановлением».
+
+## Каскадные сценарии
+
+| # | Цепочка | В чём опасность | Риск | Решение | Файл |
+|---|---------|-----------------|------|---------|------|
+| X1 | Frontend → Backend → Платежи | Платежи тупят → бэкенд ждёт → через 10 секунд весь сайт отдаёт 503, хотя база и фронт живы | 🔴 | Таймаут 3 секунды + предохранитель (opossum) | `src/payment.ts:15` ❌ |
+```
+
+---
+
+## Правила
+
+1. **Одна проблема = одна строка.** В сводку идут только 🔴/🟠, в таблицу компонента — все.
+2. **Только крупные компоненты.** Не классы, не функции, не отдельные таблицы.
+3. **Похожие сущности — в один компонент.** Реплики, воркеры, таблицы одной БД.
+4. **Каждый сценарий = `файл:строка`.** Иначе `⚠ не проверено — причина`.
+5. **«В чём опасность» самодостаточно.** Причина + механика + последствие в одной фразе, без терминов.
+6. **Нет реального риска — не выдумывай.** Пиши «Рисков нет».
+7. **Решение — по Парето и простыми словами.** Что сделать + зачем + параметр в скобках. Если нужен рефакторинг — `⚠ нужен рефакторинг`.
+8. **Каскад — только при ≥3 компонентах** и уникальной механике.
+9. **Baseline** — помечай `⏸ ACCEPTED` риски, принятые по baseline.
+
+---
+
+## Severity
+
+| 🔴 Критический | Потеря данных, дыра в безопасности, полный отказ без авто-восстановления |
+| 🟠 Высокий | Сайт тормозит или отказ под нагрузкой, второстепенные функции не работают |
+| 🟡 Средний | Редкие ошибки, лечатся перезапуском |
+| 🟢 Низкий | Техдолг, нет мониторинга в некритичных местах |
+
+---
+
+## Bash
+
+Bash — только для навигации. Нашёл файл — открой и читай.
+Нет результата — проверь негативный сценарий (другие имена, закомментировано, другое расширение).
+Не копируй слепо — адаптируй под структуру проекта.
+
+---
+
+## Baseline
+
+```bash
+cat ./docs/audit-baseline.yml 2>/dev/null
+```
+
+---
+
+В конце сообщения одной строкой:
+**Парадигма:** … · **Компонентов:** N · **Сценариев:** N · **🔴/🟠:** N
+
+## Шаг 6 — Верификация
+
+`Skill("audit-verify")`
+
+# Девиз: Найди одну настоящую дыру, а не сто придуманных.
+Четыре принципа аудитора:
+1. Ищи катастрофу, а не опечатку — тебя интересуют каскадные сбои и потеря данных, а не стиль кода
+2. Думай как злой гений — не верь внутренней сети, облакам и «стабильным» API
+3. Пиши как для джуна — если нельзя объяснить простыми словами, ты сам не понял риск
+4. Подтверждай строкой кода — каждое «возможно» = файл:строка, иначе это галлюцинация

package/skills/audit-meta/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: audit-meta
+description: >
+  Мета-контроль качества аудита: проверяет покрытие кодовой базы, актуальность baseline,
+  качество доказательств в отчётах. Вызывай ПОСЛЕ всех аудитов и audit-verify — /audit-meta
+  или автоматически в финале /audit.
+---
+
+## Задача
+
+Ты — координатор процесса аудита. Проверяешь не код, а качество самого аудита: всё ли покрыто, нет ли протухших исключений, достаточно ли доказательств.
+
+## Шаг 1 — Сбор данных
+
+```bash
+# Папка последней сессии
+ls -dt ./docs/audits/[0-9]*/ 2>/dev/null | head -1 | sed 's|/$||'
+```
+
+Прочитай все `*.md` файлы из папки сессии и `docs/audit-baseline.yml`.
+
+## Шаг 2 — Scope Verification
+
+1. Получи список всех исходных файлов проекта:
+   ```bash
+   find ./src -type f \( -name "*.ts" -o -name "*.js" -o -name "*.py" \) 2>/dev/null | head -100
+   ```
+2. Сверь с доказательствами в отчётах: каждый директорий/модуль упомянут хотя бы в одном аудит-файле.
+3. Выведи список директорий, не упомянутых ни в одном отчёте:
+
+```
+### Непокрытые модули
+- `src/module-name/` — ни один аудит не содержит ссылок на файлы этой директории
+```
+
+Если все модули покрыты → `✅ Scope: все модули проверены.`
+
+## Шаг 3 — Baseline Expiry
+
+Для каждой записи в `docs/audit-baseline.yml` с полем `expires`:
+- Сравни дату с текущей (`date +%Y-%m-%d`)
+- Если истекла — выведи предупреждение:
+
+```
+### ⚠️ Истёкшие исключения в baseline
+| check_id | expires | accepted_by | reason |
+|----------|---------|-------------|--------|
+| OWA-06 | 2025-12-31 | username | nginx rate limit |
+```
+
+Если истёкших нет → `✅ Baseline: все исключения актуальны.`
+
+## Шаг 4 — Quality of Evidence
+
+Проверь каждую строку с `❌ FAIL` в отчётах:
+- Есть ли `файл:строка` в колонке «Доказательство»? Если нет → низкое качество доказательства.
+- Есть ли конкретный код/значение или только имя файла?
+
+Выведи:
+```
+### Находки с недостаточными доказательствами
+| Аудит-файл | Check ID | Проблема |
+|------------|----------|----------|
+| audit-owasp | OWA-02 | Нет конкретной строки, только имя файла |
+```
+
+Если все доказательства достаточны → `✅ Evidence: все FAIL подкреплены доказательствами.`
+
+## Шаг 4.5 — False Positive Suppression Audit
+
+Проверь типы записей в `docs/audit-baseline.yml`. Правильный baseline различает:
+- `accepted-risk` — риск известен, намеренно принят
+- `false-positive` — инструмент ошибся, нарушения нет
+- `intentional-design` — архитектурное решение, не баг
+
+Для записей без поля `type` выведи:
+```
+### Записи baseline без типа (требуют уточнения)
+| check_id | reason | Рекомендуемый тип |
+|----------|--------|-------------------|
+| OWA-06 | nginx rate limit | accepted-risk |
+```
+
+Без `type` baseline превращается в свалку — уточнить обязательно.
+
+## Шаг 5 — Отчёт
+
+```
+# Audit Meta Report — <YYYY-MM-DD HH:MM>
+
+## Scope Coverage
+<результат Шага 2>
+
+## Baseline Expiry
+<результат Шага 3>
+
+## Evidence Quality
+<результат Шага 4>
+
+## Итог
+| Проверка | Статус |
+|----------|--------|
+| Scope Coverage | ✅ / ⚠️ N модулей не покрыто |
+| Baseline Expiry | ✅ / ⚠️ N истёкших |
+| Evidence Quality | ✅ / ⚠️ N слабых доказательств |
+| Baseline Types | ✅ / ⚠️ N записей без type |
+```
+
+## Language Rule
+
+Результаты аудита должны быть написаны простым и понятным языком. Избегай сложных терминов, жаргона и абстрактных понятий без необходимости. Общепринятые технические термины (Docker, HTTP, API, JSON, URL) допустимы. Описывай проблемы так, чтобы они были понятны разработчику любого уровня, а не только узкому специалисту в данной области.
+
+## Сохранение
+
+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-meta.md`

package/skills/audit-naming/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: audit-naming
+description: >
+  Аудит именования: читаемость кода, стандарты именования переменных, функций, классов, файлов.
+  Запускай при /audit-naming или запросе проверить code style / naming conventions.
+---
+
+## Правило применимости (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» по префиксу `NAM-`.
+- Если профиль `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 | Проверка |
+|----------|----------|
+| NAM-01 | Соглашение об именовании соблюдается консистентно (camelCase/snake_case) |
+| NAM-02 | Имена переменных, функций и классов описывают назначение, не реализацию |
+| NAM-03 | Boolean-переменные имеют предикативные имена (is/has/can/should) |
+| NAM-04 | Функции-читатели (get*/find*) не имеют side effects |
+| NAM-05 | Magic numbers и magic strings заменены именованными константами |
+| NAM-06 | Утилитные модули не являются свалкой несвязанного кода |
+| NAM-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
+```
+
+## Контекст анализа
+
+**NAM-01 — Консистентность конвенции именования:**
+- Конкретная конвенция определяется рантаймом/профилем (секция Idioms): в Node/JS — camelCase для переменных/функций, в Go — PascalCase для экспортируемых и camelCase для приватных идентификаторов. Примеры ниже иллюстративны (Node).
+- Несоответствие конвенции языка/фреймворка (snake_case в JS, camelCase в Python)
+- Непоследовательное именование одной сущности в разных местах (`userId` vs `user_id` vs `uid`)
+- Смешение стилей в одном файле или модуле
+
+**NAM-02 — Имена описывают назначение:**
+- Однобуквенные переменные вне циклов (`d`, `x`, `tmp`)
+- Аббревиатуры без расшифровки (`mgr`, `proc`, `srv`, `usr`)
+- Слишком общие имена (`data`, `info`, `manager`, `handler`, `util`)
+- Классы без существительного, функции без глагола
+- Имена отражают реализацию, а не назначение (`arrayOfUsers` вместо `users`)
+
+**NAM-03 — Boolean с предикативными именами:**
+- Boolean переменные без is/has/can/should префикса (`enabled`, `valid`, `error`)
+- Отрицательные булевы (`isNotValid`, `notDisabled`) — двойное отрицание в условии
+- Имена, не дающие понять ожидаемое значение при true
+
+**NAM-04 — Функции-читатели без side effects:**
+- Функция `getUser` изменяет данные или имеет побочные эффекты
+- `find*`/`fetch*` методы выполняют запись/обновление
+- Нарушение принципа: читающее имя → чистая операция
+
+**NAM-05 — Именованные константы вместо magic values:**
+- Magic numbers без именованных констант (`timeout = 86400`, `limit = 100`)
+- Magic strings без константы (`status === 'active'` без enum/constant)
+- Повторяющиеся литеральные значения в разных местах кода
+
+**NAM-06 — Утилитные модули не свалка:**
+- `utils.ts`, `helpers.ts` как свалка несвязанного кода
+- `index.ts` с экспортом несвязанных сущностей
+- Файлы с именами, не отражающими содержимое
+
+**Ubiquitous Language:**
+- Если в проекте есть `GLOSSARY.md`, `SPEC.md`, `README.md` с бизнес-терминами — проверь соответствие
+- `client` в коде при `customer` в домене — расхождение ubiquitous language
+- Синонимы для одной сущности в разных слоях (`User` / `Account` / `Member`) без явного обоснования
+- При отсутствии глоссария — ставь `🔍 UNVERIFIED`
+
+## Инструментальная поддержка
+
+Для NAM-06 используй инструмент категории **unused-code** из профиля стека
+(секция «Tooling by category»): он находит неиспользуемые экспорты и мёртвый код
+в утилитных модулях (свалка несвязанного кода). Используй вывод как подсказку и
+верифицируй каждую находку вручную (`file:line`) перед занесением в FAIL. Если
+ячейка пустая (tier general/generic) — проверяй вручную и помечай находки
+`🔍 UNVERIFIED`.
+
+## Формат вывода
+
+| Check ID | Проверка | Статус | Уверенность | Доказательство | Решение | Исправлено |
+|----------|----------|--------|-------------|----------------|---------|------------|
+| NAM-01 | Соглашение об именовании соблюдается консистентно (camelCase/snake_case) | ✅ PASS | High | `src/` — стиль camelCase консистентен | — | — |
+| NAM-05 | Magic numbers и magic strings заменены именованными константами | ❌ FAIL 🟡 | High | `utils/date.ts:18` | **1. Вынести в `const MAX_RETRY_ATTEMPTS = 3`** \\ 2. Добавить объяснение в комментарий рядом \\ 3. Переместить в конфиг | Нет |
+| NAM-06 | Утилитные модули не являются свалкой несвязанного кода | ⏸ ACCEPTED | Medium | `src/utils.ts` | В baseline: рефактор запланирован | — |
+| NAM-07 | Ключевые сущности названы в соответствии с доменным глоссарием проекта | 🔍 UNVERIFIED | Low | — | — | — |
+
+Статусы: `✅ 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-naming.md`
+
+```
+# Audit Report: Naming — <YYYY-MM-DD HH:MM>
+<таблица>
+```