kodu 2.2.0 → 3.0.1

package/skills/audit/SKILL.md

@@ -1,205 +0,0 @@
----
-name: audit
-description: >
-  Мастер-оркестратор комплексного аудита кодовой базы. Запускает все 18 специализированных
-  проверок и группирует результаты по компонентам системы. Вызывай при /audit или
-  запросе "полный аудит", "комплексный аудит кодовой базы".
----
-
-## Задача
-
-Ты — ведущий инженер по качеству и безопасности, проводящий полный аудит кодовой базы.
-
-## Шаг 0 — Runtime resolution (определение стека)
-
-Аудиты стек-агностичны: конкретика берётся из профиля стека. Определи рантайм
-ОДИН раз здесь и передай его всем саб-скиллам, чтобы они не передетектили.
-
-```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
-```
-
-Один запуск `/audit` = ОДИН рантайм. **Полиглот-репозиторий** (например Go-бэкенд
-+ Node-фронтенд в сабмодулях) аудить по подпроектам: запусти `/audit` отдельно
-внутри каждого подкаталога (`backend/`, `frontend/`). Если в текущем каталоге
-несколько маркеров — выбери по scope и сообщи об этом пользователю.
-
-Прочитай профиль один раз через Read: `./skills/audit/stacks/<runtime>.md`
-(fallback `./skills/audit/stacks/_generic.md`). Канон детекта — `./skills/audit/runtime-detect.md`.
-
-Передавай `runtime=<id>` + содержимое профиля как контекст каждому sub-скиллу
-(тем же каналом, что и baseline). Саб-скиллы увидят это и пропустят собственный
-детект; при автономном запуске они детектят сами.
-
-## Шаг 1 — Подготовка сессии
-
-Выполни через Bash:
-
-```bash
-# Удалить старые сессии, оставить 2 последних
-ls -dt ./docs/audits/[0-9]*/ 2>/dev/null | tail -n +3 | xargs rm -rf 2>/dev/null
-# Создать папку новой сессии
-mkdir -p ./docs/audits/$(date +"%Y-%m-%d_%H-%M")
-```
-
-Для incremental-аудита (только изменённые файлы) — определи scope:
-```bash
-git diff --name-only HEAD~1 2>/dev/null | grep -E '\.(ts|js|py|go|rs)$' | head -30
-```
-Если список < 20 файлов — начинай аудит с них, затем критические пути.
-
-## Шаг 2 — Baseline
-
-```bash
-cat ./docs/audit-baseline.yml 2>/dev/null
-```
-
-Если файл не существует — создай:
-
-```bash
-cp ./skills/audit/audit-baseline-template.yml ./docs/audit-baseline.yml 2>/dev/null || \
-  printf "accepted: []\n" > ./docs/audit-baseline.yml
-```
-
-Сообщи: `📋 docs/audit-baseline.yml создан. Заполни для подавления принятых рисков.`
-
-Содержимое baseline передавай как контекст каждому sub-скиллу (вместе с `runtime=<id>` и профилем из Шага 0).
-
-## Шаг 3 — Декомпозиция системы
-
-Перечисли логические компоненты (Аутентификация, API, Фоновые задачи и т.д.) перед запуском аудитов. Используй структуру папок как ориентир.
-
-## Шаг 3.5 — Критические пути (Risk-Based Prioritization)
-
-```bash
-grep -rl "auth\|login\|payment\|billing\|webhook\|cron\|migration" ./src 2>/dev/null | head -20
-```
-
-Перечисли critical paths — файлы/модули с наибольшим blast radius:
-```
-Critical paths (exhaustive depth):
-- Authentication: src/auth/**
-- Payments: src/payments/**
-- Webhooks/Workers: src/workers/**
-
-Standard paths: src/api/**, src/services/**
-Low priority (naming/style): src/utils/**
-```
-
-Передавай список critical paths каждому sub-скиллу — они должны начинать с этих файлов.
-
-## Шаг 4 — Анализ по 18 направлениям
-
-**ОБЯЗАТЕЛЬНО:** Для каждого направления вызови специализированный скилл через `Skill`. Прямой анализ без скилла недопустим.
-
-**Правило пропуска:** направление нерелевантно → пропусти без упоминания.
-
-Скиллы сгруппированы для параллельного запуска. Группы выполняются последовательно — скиллы внутри группы можно запускать параллельно через Agent-вызовы.
-
-**Группа А — Безопасность:**
-| # | Направление | Скилл |
-|---|-------------|-------|
-| 1 | Secrets Leak | `audit-secrets` |
-| 2 | OWASP Security | `audit-owasp` |
-| 3 | Boundary Validation | `audit-validation` |
-
-**Группа Б — Логика:**
-| # | Направление | Скилл |
-|---|-------------|-------|
-| 4 | Bugs & Logic | `audit-bugs` |
-| 5 | Error Handling | `audit-errors` |
-| 6 | Concurrency | `audit-concurrency` |
-
-**Группа В — Качество:**
-| # | Направление | Скилл |
-|---|-------------|-------|
-| 7 | Architecture | `audit-architecture` |
-| 8 | Naming | `audit-naming` |
-| 9 | YAGNI | `audit-yagni` |
-| 10 | Reinventing the Wheel | `audit-reinvention` |
-| 11 | Documentation | `audit-docs` |
-
-**Группа Г — Операции:**
-| # | Направление | Скилл |
-|---|-------------|-------|
-| 12 | Tests & Linters | `audit-tests` |
-| 13 | Logging | `audit-logging` |
-| 14 | Performance | `audit-performance` |
-| 15 | Deployment | `audit-deployment` |
-| 16 | API Contracts | `audit-api-contracts` |
-| 17 | Meta-контроль | `audit-meta` |
-
-**Группа Д — Системный уровень:**
-| # | Направление | Скилл |
-|---|-------------|-------|
-| 18 | Матрица взаимодействий | `audit-matrix` |
-
-**Каждый скилл ОБЯЗАН сохранить файл в папку сессии: `./docs/audits/<SESSION>/audit-<name>.md`**
-
-## Шаг 5 — Сводный отчёт по компонентам
-
-После всех скиллов собери только строки `❌ FAIL` и `⏸ ACCEPTED`:
-
-```
-## Компонент: [Название]
-
-| Check ID | Проверка | Статус | Доказательство | Решение | Исправлено |
-|----------|----------|--------|----------------|---------|------------|
-| OWA-02 | Auth на protected routes | ❌ FAIL 🔴 | `routes/admin.ts:14` | **1. Добавить authMiddleware** \\ 2. ... \\ 3. ... | Нет |
-| OWA-06 | Rate limiting | ⏸ ACCEPTED | `src/app.ts` | В baseline: nginx rate limit | — |
-```
-
-Если все PASS — выведи: `✅ Проблем не обнаружено.`
-
-## Шаг 6 — Итоговая таблица
-
-```
-## Сводка
-
-| Компонент | ❌ FAIL 🔴 | ❌ FAIL 🟠 | ❌ FAIL 🟡🟢 | ⏸ ACCEPTED | Итого FAIL |
-|-----------|-----------|-----------|------------|-----------|------------|
-| [Компонент] | N | N | N | N | N |
-| **ИТОГО** | **N** | **N** | **N** | **N** | **N** |
-```
-
-## Шаг 7 — Разбор FAIL 🔴
-
-Для каждого `❌ FAIL 🔴`:
-
-```
-### 🔴 [Check ID] — [Компонент]
-**Файл:** `path/file.ts:line`
-**Проверка:** [название]
-**Доказательство:** [конкретный код]
-**Решение:** [первый вариант из таблицы]
-```
-
-## Шаг 8 — Финальная верификация
-
-Вызови: `Skill("audit-verify")`
-
-Затем вызови: `Skill("audit-meta")`
-
-## Шаг 9 — Сохранение
-
-Сохрани полный отчёт через Write: `./docs/audits/<SESSION>/audit-report.md`
-
-```
-# Full Audit Report — <YYYY-MM-DD HH:MM>
-## Компоненты системы
-## Компонент: [Название]
-## Сводка
-## Критические риски
-```
-
-Сообщи путь к папке сессии и число FAIL по severity.
-
-## Language Rule
-
-Результаты аудита должны быть написаны простым и понятным языком. Избегай сложных терминов, жаргона и абстрактных понятий без необходимости. Общепринятые технические термины (Docker, HTTP, API, JSON, URL) допустимы. Описывай проблемы так, чтобы они были понятны разработчику любого уровня, а не только узкому специалисту в данной области.
-

package/skills/audit/audit-baseline-template.yml

@@ -1,188 +0,0 @@
-# audit-baseline.yml
-# Принятые/отложенные риски. Совпадение по check_id → статус ⏸ ACCEPTED в отчёте.
-# Скопируй в корень проекта: docs/audit-baseline.yml
-#
-# check_id стек-нейтральны: один и тот же идентификатор применяется к любому
-# рантайму (Node/TS, Go, Python, Rust, Java). Конкретика стека берётся из
-# профилей skills/audit/stacks/<runtime>.md и не влияет на матчинг по check_id.
-
-accepted:
-  # Пример:
-  # - check_id: OWA-06
-  #   file: src/app.ts          # Опционально: ограничить конкретным файлом
-  #   reason: "Rate limiting на nginx уровне"
-  #   type: accepted-risk        # accepted-risk | false-positive | intentional-design
-  #   accepted_by: username
-  #   accepted_date: 2026-01-01
-  #   expires: 2026-12-31       # Опционально: когда пересмотреть
-
-# ─────────────────────────────────────────
-# Ложные срабатывания (инструмент ошибся, нарушения нет)
-false_positives:
-  # - check_id: ARC-03
-  #   reason: "import cycle from prisma-generated client, not real cycle"
-  #   type: false-positive
-
-# Намеренные архитектурные решения (не баги, обоснованный выбор)
-intentional:
-  # - check_id: NAM-06
-  #   reason: "utils.ts contains 3 tightly related helpers, intentional"
-  #   type: intentional-design
-
-# ─────────────────────────────────────────
-# ПОЛНЫЙ СПИСОК check_id
-# ─────────────────────────────────────────
-#
-# audit-secrets:
-#   SEC-01  Нет hardcoded credentials в коде (пароли, токены, API-ключи, приватные ключи)
-#   SEC-02  Файлы с секретами исключены из VCS (.env* в .gitignore)
-#   SEC-03  Секреты не передаются через URL (query params, Basic Auth в URL)
-#   SEC-04  .env.example содержит только placeholder-значения без реальных данных
-#   SEC-05  Dockerfile не содержит секретов в ENV-директивах
-#   SEC-06  Комментарии в коде не содержат credentials
-#   SEC-07  Автоматическое сканирование секретов настроено (pre-commit или CI)
-#
-# audit-owasp:
-#   OWA-01  A03: Все запросы к БД/OS/LDAP параметризованы, нет injection
-#   OWA-02  A01: Все защищённые маршруты имеют auth-middleware
-#   OWA-03  A01: Resource ownership проверяется, нет IDOR
-#   OWA-04  A02: Пароли хранятся безопасно (bcrypt/argon2/scrypt)
-#   OWA-05  A05: Безопасная конфигурация сервера (CORS, security headers, body limits)
-#   OWA-06  A07: Защита от перебора (rate limiting на auth и чувствительных эндпоинтах)
-#   OWA-07  A09: Техническая информация не утекает в ответы (stack trace, внутренние пути)
-#   OWA-08  A10: URL из user input не передаётся в HTTP-клиент без whitelist (SSRF)
-#   OWA-09  A05: CSRF-защита реализована (SameSite cookies или CSRF-токены на state-changing запросах)
-#
-# audit-validation:
-#   VAL-01  Все входящие данные (body, params, query) проходят schema-валидацию
-#   VAL-02  Строки имеют maxLength, числа — диапазон, enum-значения — whitelist
-#   VAL-03  JSON.parse обёрнут в try/catch с последующей валидацией структуры
-#   VAL-04  Identity данные берутся из аутентифицированного контекста (не из user input)
-#   VAL-05  Вложенные структуры и массивы ограничены (глубина, minItems/maxItems)
-#   VAL-06  Валидатор не выполняет неявный coercion
-#   VAL-07  Prototype pollution: merge/assign с user input фильтрует __proto__, constructor, prototype
-#   VAL-08  Загрузка файлов: MIME тип проверяется по содержимому, имя файла санитизировано, размер ограничен
-#
-# audit-errors:
-#   ERR-01  Ошибки не проглатываются — catch-блоки обрабатывают или пробрасывают
-#   ERR-02  Внутренние детали (stack trace, пути, версии) не попадают в ответы
-#   ERR-03  Async handlers корректно пробрасывают исключения в error middleware
-#   ERR-04  Unhandled rejections и uncaught exceptions имеют process-level обработчики
-#   ERR-05  Внешние вызовы (HTTP-клиенты, DB) имеют явные таймауты
-#   ERR-06  Graceful shutdown реализован — SIGTERM обрабатывается
-#   ERR-07  Error responses консистентны по структуре во всём приложении
-#   ERR-08  Retry-стратегии используют exponential backoff с jitter
-#   ERR-09  AbortSignal/CancellationToken пробрасывается во внешние вызовы
-#
-# audit-logging:
-#   LOG-01  Production-код не использует console.log/console.error напрямую
-#   LOG-02  PII не логируется (email, телефон, имена, адреса, финансовые данные)
-#   LOG-03  Секреты и токены не попадают в логи
-#   LOG-04  Запросы трассируются (Request ID или correlation ID сквозной)
-#   LOG-05  Формат логов структурирован (JSON) в production
-#   LOG-06  Критические операции логируются (auth, create, update, delete)
-#   LOG-07  User input санитизируется перед логированием (защита от log injection)
-#   LOG-08  Критические события безопасности логируются: вход, выход, изменение прав, массовая выгрузка данных
-#
-# audit-performance:
-#   PER-01  Нет N+1: DB-запросы не выполняются внутри циклов
-#   PER-02  Выборки из БД ограничены (LIMIT, пагинация)
-#   PER-03  Обработчики запросов не содержат блокирующего I/O
-#   PER-04  CPU-интенсивные операции вынесены из main thread
-#   PER-05  Независимые async-операции выполняются параллельно
-#   PER-06  Кэши ограничены по размеру и времени жизни (TTL + size limit)
-#   PER-07  Event listeners и subscriptions очищаются при завершении
-#   PER-08  Нет утечек памяти: timers и closures не удерживают большие объекты в долгоживущем scope
-#
-# audit-architecture:
-#   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  Доменный слой не импортирует инфраструктурные модули
-#
-# audit-concurrency:
-#   CON-01  async/await не используется в неасинхронных итераторах (forEach, map)
-#   CON-02  Read-modify-write операции выполняются в транзакциях
-#   CON-03  Нет shared mutable state на уровне модуля (синглтоны, кэши без locks)
-#   CON-04  Module-level кэш имеет механизм инвалидации
-#   CON-05  Обработчики событий и webhook-handlers идемпотентны
-#   CON-06  Background async операции имеют механизм отмены (AbortController/signal) и не блокируют graceful shutdown
-#
-# audit-naming:
-#   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  Ключевые сущности названы в соответствии с доменным глоссарием
-#
-# audit-yagni:
-#   YAGNI-01  Нет закомментированного кода
-#   YAGNI-02  Нет dead code — неиспользуемых экспортов, функций, переменных
-#   YAGNI-03  Абстракции оправданы: интерфейс/фабрика имеет >1 реализации или требуется тестами
-#   YAGNI-04  Feature flags не зафиксированы в одном значении
-#   YAGNI-05  Технический долг актуален — нет заброшенных TODO/FIXME без даты или прогресса
-#
-# audit-reinvention:
-#   REINV-01  Нет ручной реализации того, что есть в stdlib/языке/рантайме
-#   REINV-02  Нет ручной реализации того, что уже умеет установленная зависимость
-#   REINV-03  Нет смыслового дублирования логики (одинаковый код в ≥2 местах вместо общей утилиты)
-#   REINV-04  Крупные механизмы (ORM, DI, scheduler, logger, job queue) не написаны с нуля при наличии зрелого решения
-#
-# audit-docs:
-#   DOC-01  README/онбординг документирует install/run/test/build, команды совпадают с package.json scripts
-#   DOC-02  Env-переменные синхронизированы: используемые в коде задокументированы, нет задокументированных но неиспользуемых
-#   DOC-03  Внутренние ссылки и пути в Markdown-документации ведут на существующие файлы и секции
-#   DOC-04  Комментарии и JSDoc/docstring не противоречат коду (сигнатура, параметры, типы, поведение)
-#   DOC-05  Публичная поверхность (экспортируемое API библиотеки/пакета) имеет doc-комментарий
-#   DOC-06  Проектная/архитектурная документация не ссылается на удалённые/переименованные сущности
-#
-# audit-bugs:
-#   BUG-01  Преобразования типов безопасны (NaN, radix, coercion)
-#   BUG-02  async/await используется корректно (нет await в forEach, нет if(asyncFn()))
-#   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 не использует === для проверки равенства
-#   BUG-09  Дата/время хранятся и обрабатываются в UTC, не локальном времени
-#   BUG-10  RegExp с user input не содержит катастрофического backtracking (ReDoS)
-#
-# audit-tests:
-#   TST-01  TypeScript strict mode включён
-#   TST-02  Coverage thresholds настроены и применяются в CI
-#   TST-03  Pre-commit/pre-push хуки запускают проверки (tests, lint, typecheck)
-#   TST-04  Критические пути покрыты тестами (auth, validation, error handling)
-#   TST-05  Тесты изолированы — нет shared mutable state между тестами
-#   TST-06  Нет пропущенных или зафиксированных тестов (.only/.skip без обоснования)
-#   TST-07  Тесты проверяют поведение, а не детали реализации
-#   TST-08  Нет нестабильных тестов (Math.random, Date.now без mock, sleep)
-#   TST-09  Snapshot-тесты охватывают значимые изменения, не весь DOM
-#
-# audit-deployment:
-#   DEP-01  Docker images используют pinned versions (нет :latest)
-#   DEP-02  Контейнеры запускаются от непривилегированного пользователя (USER nonroot)
-#   DEP-03  Multi-stage build разделяет dev и prod зависимости
-#   DEP-04  .dockerignore исключает node_modules, .git, .env
-#   DEP-05  HEALTHCHECK определён в Dockerfile
-#   DEP-06  Секреты не hardcoded в Dockerfile (нет в ENV)
-#   DEP-07  .env исключён из VCS
-#   DEP-08  .env.example документирует все переменные окружения
-#   DEP-09  NODE_ENV корректно устанавливается для production
-#   DEP-10  npm ci используется вместо npm install в Docker
-#   DEP-11  Ограничения ресурсов контейнера определены (CPU limits, Memory limits)
-#   DEP-12  Возможность запуска с read-only root filesystem проверена
-#
-# audit-api-contracts:
-#   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 имеет стратегию версионирования

package/skills/audit/runtime-detect.md

@@ -1,64 +0,0 @@
-# Runtime Detection & Stack Profile (общий канон)
-
-Этот файл — единый источник правды для того, как аудит-скилл определяет рантайм
-проекта и подгружает соответствующий **профиль стека** из `./skills/audit/stacks/`.
-
-Каждый кодовый аудит-скилл содержит инлайн-копию блока ниже (раздел
-«Runtime Detection & Stack Profile»). Инлайн-копия обязательна — она гарантирует,
-что скилл работает автономно (`/audit-<name>`), даже если оркестратор `/audit`
-не запускался. Этот файл — справочник и место для синхронной правки канона.
-
-## Принцип
-
-Один запуск аудита = **ровно один рантайм**. Скилл:
-1. принимает рантайм, инъектированный оркестратором, ЕСЛИ он передан; иначе
-2. определяет ровно один рантайм текущего каталога; затем
-3. читает профиль и использует его инструменты/идиомы/анти-паттерны.
-
-Полиглот-репозитории (например Go-бэкенд + Node-фронтенд в одном дереве)
-аудитятся по подпроектам: запусти аудит отдельно внутри каждого подкаталога.
-
-## Канонический блок (вставляется в каждый кодовый скилл)
-
-```
-## 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» по префиксу этого аудита.
-- Если профиль `tier: general` или `runtime=generic` → стек-специфичные находки
-  без однозначного evidence помечай `🔍 UNVERIFIED`, а не `❌ FAIL`. Проверки,
-  чей механизм в рантайме отсутствует, помечай `N/A`.
-```
-
-## Инъекция из оркестратора
-
-Мастер-скилл `audit/SKILL.md` определяет рантайм один раз (Шаг 0), читает профиль
-один раз и передаёт `runtime=<id>` + содержимое профиля каждому `Skill()` тем же
-каналом, что и baseline. Саб-скиллы видят это в шаге 1 и пропускают собственный
-детект. Автономность при этом не теряется: инлайн-блок отрабатывает сам, если
-инъекции нет.

package/skills/audit/stacks/_generic.md

@@ -1,41 +0,0 @@
-# Stack Profile: Generic (fallback)   (id: generic)
-Tier: fallback
-
-Используется, когда рантайм не определён (нет известного маркер-файла) или нужный
-профиль не найден. Инструментов нет; работают только **стек-нейтральные** проверки.
-
-## 1. Detection signals
-- ничего из известных маркеров (`package.json`, `go.mod`, `pyproject.toml`/`requirements.txt`, `Cargo.toml`, `pom.xml`/`build.gradle`)
-
-## 2. Tooling by category
-| Категория | Команда | Как читать вывод |
-|-----------|---------|------------------|
-| unused-code | — | нет инструмента → ручной скан ссылок на символы → `🔍 UNVERIFIED` |
-| clone-detection | — | grep повторяющихся блоков вручную → `🔍 UNVERIFIED` |
-| dep-audit | — | нет → пометить «аудит зависимостей недоступен» |
-| env-extraction | `grep -rEoh '[A-Z][A-Z0-9_]{2,}' . 2>/dev/null \| sort -u` (грубо) | кандидаты в env-переменные, верифицируй вручную |
-| arch-lint | — | ручной разбор слоёв → `🔍 UNVERIFIED` |
-| lint/format | — | — |
-| type-check | — | — |
-| test-run | — | — |
-| secret-scan | `gitleaks detect --no-banner 2>/dev/null \|\| trufflehog filesystem . 2>/dev/null \|\| true` | стек-нейтрально, работает всегда |
-
-## 3. Idioms
-Стек-нейтральные ожидания (применимы к любому языку):
-- Ошибки обрабатываются или явно пробрасываются, не подавляются молча.
-- Внешние вызовы имеют таймауты и механизм отмены.
-- Секреты не захардкожены; конфигурация изолирована.
-- Логи структурированы, без PII и секретов.
-- Имена описывают назначение; нет дублирования логики.
-- Документация (README, ссылки, env) синхронизирована с кодом.
-
-## 4. Anti-patterns
-- Подавление ошибок без обработки.
-- Захардкоженные секреты, разбросанная конфигурация.
-- Дублирование логики, мёртвый код.
-
-## 5. Check-ID hints
-Для всех стек-специфичных Check ID без однозначного evidence ставь `🔍 UNVERIFIED`.
-Реальные `✅ PASS`/`❌ FAIL` допустимы только для стек-нейтральных направлений:
-secrets (SEC-*), docs (DOC-*), naming-читаемость (NAM-02/03/05), bugs-логика
-(BUG-06/07/09), api-contracts (API-*) при наличии явного evidence.

package/skills/audit/stacks/_registry.md

@@ -1,47 +0,0 @@
-# Stack Profiles — реестр
-
-Таблица соответствия «маркер-файл → id профиля». Используется блоком
-Runtime Detection (см. `../runtime-detect.md`). Порядок проверки — сверху вниз,
-выбирается первый совпавший рантайм (один запуск = один рантайм).
-
-| Приоритет | Маркер-файл(ы) | runtime id | Профиль | Tier |
-|-----------|----------------|------------|---------|------|
-| 1 | `package.json` | `node` | `node.md` | first-class |
-| 2 | `go.mod` | `go` | `go.md` | first-class |
-| 3 | `pyproject.toml` / `requirements.txt` / `setup.py` | `python` | `python.md` | general |
-| 4 | `Cargo.toml` | `rust` | `rust.md` | general |
-| 5 | `pom.xml` / `build.gradle*` / `settings.gradle*` | `java` | `java.md` | general |
-| — | ничего из перечисленного | `generic` | `_generic.md` | fallback |
-
-## Tier — что означает
-
-- **first-class** — профиль содержит конкретные инструменты и идиомы; находки
-  могут быть `❌ FAIL` с точным evidence.
-- **general** — профиль даёт нейтральные формулировки и общие идиомы, но без
-  гарантированных инструментов; стек-специфичные находки без однозначного
-  evidence помечай `🔍 UNVERIFIED`.
-- **fallback** (`generic`) — инструментов нет; работают только стек-нейтральные
-  проверки (docs-ссылки, secrets, naming-читаемость), остальное → `🔍 UNVERIFIED`.
-
-## Категории инструментов (общие для всех профилей)
-
-Секция «Tooling by category» в каждом профиле использует один и тот же набор
-ключей, чтобы скиллы ссылались на категорию, а не на команду:
-
-`unused-code`, `clone-detection`, `dep-audit`, `env-extraction`, `arch-lint`,
-`lint/format`, `type-check`, `test-run`, `secret-scan`.
-
-## Структура профиля
-
-Каждый `stacks/<id>.md` имеет одинаковые секции:
-1. **Detection signals** — маркер-файлы.
-2. **Tooling by category** — таблица по категориям выше.
-3. **Idioms** — как выглядит «правильно» (ожидания PASS).
-4. **Anti-patterns** — как выглядит FAIL (1 строка кода на пункт).
-5. **Check-ID hints** — точечные подсказки по префиксу Check ID.
-
-## Добавление нового стека
-
-1. Создай `stacks/<id>.md` по структуре выше.
-2. Добавь строку в таблицу реестра.
-3. Добавь ветку в bash-детект в `../runtime-detect.md` и в инлайн-блоках скиллов.

package/skills/audit/stacks/go.md

@@ -1,66 +0,0 @@
-# Stack Profile: Go   (id: go)
-Tier: first-class
-
-Профиль рантайма Go. Конкретные библиотеки (chi, gqlgen, sqlc, pgx, asynq, slog,
-go-oidc) упоминаются лишь как примеры идиом, а не как требования.
-
-## 1. Detection signals
-- `go.mod` (основной маркер)
-- доп.: `go.sum`, `Taskfile.yml`/`Makefile`, `.golangci.yml`, `.go-arch-lint.yml`
-
-## 2. Tooling by category
-| Категория | Команда | Как читать вывод |
-|-----------|---------|------------------|
-| unused-code | `deadcode ./... 2>/dev/null \|\| true` (golang.org/x/tools/cmd/deadcode) | недостижимые функции → YAGNI-02; верифицируй перед FAIL |
-| clone-detection | `dupl -threshold 50 ./... 2>/dev/null \|\| true` | дубли токенов → REINV-03 |
-| dep-audit | `govulncheck ./... 2>/dev/null \|\| true` | CVE в модулях (вне чеклиста — справочно) |
-| env-extraction | `grep -rEoh 'os\.Getenv\("[A-Z0-9_]+"\)' . 2>/dev/null \| sed -E 's/.*"(.*)".*/\1/' \| sort -u` | имена env из кода → DOC-02 (учти теги `env:"..."` для caarlos0/env) |
-| arch-lint | `go vet ./... 2>/dev/null`; слои: `go-arch-lint check 2>/dev/null \|\| true` | циклы импортов запрещены компилятором → ARC-03 на уровне пакетов авто-PASS |
-| lint/format | `golangci-lint run 2>/dev/null \|\| true`; `gofmt -l . 2>/dev/null` | включает `errcheck`, `gosec`, `nilness`, `staticcheck` |
-| type-check | `go build ./... 2>/dev/null \|\| true` | компиляция = проверка типов |
-| test-run | `go test ./... 2>/dev/null \|\| true`; гонки: `go test -race ./...` | `-race` обнаруживает data race → CON-03 |
-| secret-scan | `gitleaks detect --no-banner 2>/dev/null \|\| trufflehog filesystem . 2>/dev/null \|\| true` | стек-нейтрально |
-
-Всегда верифицируй вывод инструмента вручную (`file:line`) перед `❌ FAIL`.
-
-## 3. Idioms (как выглядит «правильно» → PASS)
-- **Error handling:** явная проверка `if err != nil`; оборачивание `fmt.Errorf("...: %w", err)`; sentinel-ошибки + `errors.Is`/`errors.As`. Возвращаемая ошибка не игнорируется.
-- **Concurrency:** отмена через `context.Context` (не сигналы); shared state под `sync.Mutex`/каналами; fan-out через `errgroup`/`sync.WaitGroup`; каждая goroutine имеет путь завершения по `ctx.Done()`.
-- **Graceful shutdown:** `signal.NotifyContext(ctx, syscall.SIGTERM, os.Interrupt)`; `server.Shutdown(ctx)`; закрытие пулов (pgx), воркеров (asynq), redis.
-- **Panic safety:** `defer recover()` в HTTP-хендлерах (chi `middleware.Recoverer`), в gqlgen (`RecoverFunc`), в каждой фоновой goroutine и в обёртке job (asynq).
-- **Env/config:** централизованная config-структура (например caarlos0/env), загружается при старте; нет `os.Getenv` вразброс.
-- **Logging:** структурный `log/slog` (JSON в prod) с request/correlation ID через `context`; нет `fmt.Print*`/`log.Print*` в request-путях.
-- **Null-safety:** проверка nil-указателей/интерфейсов перед разыменованием; запись в nil-map не допускается; map-доступ через `v, ok := m[k]`.
-- **Type coercion:** `strconv.Atoi`/`ParseInt` с проверкой ошибки; type assertion через `v, ok := x.(T)` (comma-ok).
-- **Deps / reinvention:** stdlib `slices`/`maps`/`sync`; `database/sql`/sqlc вместо самописного query builder.
-- **Build/deploy:** multi-stage (builder → distroless/`nonroot`); `go.mod`+`go.sum` закоммичены; `GOFLAGS=-mod=readonly`; `CGO_ENABLED=0` для статической линковки; нет `go get` в Dockerfile; нет `net/http/pprof`/debug-роутов в prod.
-
-## 4. Anti-patterns (как выглядит FAIL)
-- **Errors:** игнор ошибки через `_ = f()` или `v, _ := f()`; `panic` для обычного потока управления; потеря wrap-цепочки.
-- **Concurrency:** goroutine без `WaitGroup`/`errgroup`/`ctx` (результат теряется / процесс не ждёт / leak); запись в map из >1 goroutine без lock (data race, ловит `go test -race`); `for ... { go f(loopVar) }` — захват переменной цикла (до Go 1.22); незакрытый канал блокирует получателей.
-- **Panic:** паника в goroutine без `recover()` роняет весь процесс.
-- **Logging:** `fmt.Print*`/`log.Print*`/`println` в production-путях вместо `slog`.
-- **Resources:** `defer` внутри цикла (ресурс держится до конца функции, не итерации).
-- **Build/deploy:** `go get` в Dockerfile; отсутствие `go.sum`; компилятор/тесты в финальном образе.
-
-## 5. Check-ID hints
-- `LOG-01` → `fmt.Print*`, `log.Print*`, `println` вне обёртки `slog`.
-- `BUG-01` → **N/A**, если нет парсинга строк; иначе — type assertion `x.(T)` без comma-ok, проигнорированная ошибка `strconv`.
-- `BUG-02` → **N/A** (нет синтаксиса промисов/forEach); риск переезжает в `CON-01`.
-- `BUG-03` → nil-deref указателя/интерфейса/map; запись в nil-map (паника).
-- `BUG-08` → сравнение float через `==`; деньги — в `int64` (центы) или `shopspring/decimal`.
-- `BUG-10` → **N/A или Low**: `regexp` (RE2) не имеет backtracking, ReDoS практически невозможен.
-- `CON-01` → goroutine без механизма завершения (WaitGroup/errgroup/ctx) → goroutine leak.
-- `CON-03` → конкурентный доступ к map/переменной пакета без `sync.Mutex`/atomic (data race).
-- `CON-06` → фоновая goroutine не слушает `ctx.Done()` → не завершается при shutdown.
-- `ERR-01` → ошибка проигнорирована через `_`.
-- `ERR-03` → нет recover-middleware (паника в хендлере роняет соединение/процесс).
-- `ERR-04` → нет `defer recover()` в фоновых goroutine/asynq-handler.
-- `ERR-06` → нет `signal.NotifyContext`/`server.Shutdown` (graceful shutdown).
-- `ERR-09` → `context.Context` не пробрасывается во внешние вызовы (pgx/HTTP/asynq).
-- `PER-08` → `defer` в цикле/долгой функции держит ресурсы (rows/файлы/locks).
-- `ARC-03` → **N/A на уровне пакетов** (циклы импортов запрещены компилятором); проверять только логические слои через go-arch-lint.
-- `ARC-05` → `os.Getenv` разбросан вместо config-структуры.
-- `DEP-09` → нет переключения в production-режим (debug-роуты/pprof/verbose в prod-образе).
-- `DEP-10` → `go get` в сборке вместо `go mod download` по закоммиченному `go.sum`; нет `-mod=readonly`.
-- `TST-01` → `go vet`/`staticcheck`/`golangci-lint` не включены/не обязательны.