kodu 2.2.0 → 3.0.2

package/skills/audit/stacks/java.md

@@ -1,44 +0,0 @@
-# Stack Profile: Java / JVM   (id: java)
-Tier: general
-
-Профиль уровня general: нейтральные идиомы + ориентиры по инструментам без
-гарантий их наличия. Стек-специфичные находки без однозначного evidence
-помечай `🔍 UNVERIFIED`.
-
-## 1. Detection signals
-- `pom.xml` (Maven) / `build.gradle*` / `settings.gradle*` (Gradle)
-
-## 2. Tooling by category
-| Категория | Команда | Как читать вывод |
-|-----------|---------|------------------|
-| unused-code | SpotBugs / IDE-инспекции | неиспользуемое → YAGNI-02 (часто `🔍 UNVERIFIED` без инструмента) |
-| clone-detection | `pmd cpd --minimum-tokens 50 --dir . 2>/dev/null \|\| true` | дубли → REINV-03 |
-| dep-audit | `mvn org.owasp:dependency-check-maven:check 2>/dev/null \|\| true` | CVE в зависимостях |
-| env-extraction | `grep -rEoh 'System\.getenv\("[A-Z0-9_]+"\)' . 2>/dev/null \| sort -u` | env из кода → DOC-02 (учти `@Value`/`application.yml`) |
-| arch-lint | ArchUnit-тесты | слои/зависимости |
-| lint/format | `mvn checkstyle:check 2>/dev/null \|\| true`; SpotBugs | — |
-| type-check | `mvn compile 2>/dev/null \|\| ./gradlew compileJava 2>/dev/null \|\| true` | компиляция |
-| test-run | `mvn test 2>/dev/null \|\| ./gradlew test 2>/dev/null \|\| true` | — |
-| secret-scan | `gitleaks detect --no-banner 2>/dev/null \|\| true` | стек-нейтрально |
-
-## 3. Idioms
-- **Errors:** конкретные исключения; try-with-resources для ресурсов; нет пустых `catch`.
-- **Concurrency:** `ExecutorService`/`CompletableFuture`; отмена через `Future.cancel`/interruption; иммутабельность или `synchronized`/`java.util.concurrent`.
-- **Env/config:** Spring `@Value`/`application.yml` или `System.getenv`, централизованно.
-- **Logging:** SLF4J/Logback со структурой; нет `System.out.println` в production.
-- **Null-safety:** `Optional<T>`; аннотации `@Nullable`/`@NonNull`; проверки null.
-- **Lifecycle:** `@Transactional` для read-modify-write; graceful shutdown через lifecycle-хуки.
-- **Deps:** проверенные библиотеки экосистемы вместо самописного.
-
-## 4. Anti-patterns
-- Пустой `catch (Exception e) {}`.
-- `System.out.println`/`printStackTrace` в production.
-- Shared mutable state без синхронизации.
-- Разбросанный `System.getenv` без централизации.
-
-## 5. Check-ID hints
-- `LOG-01` → `System.out.println`/`printStackTrace` вместо SLF4J.
-- `ERR-01` → пустой `catch`.
-- `CON-02` → read-modify-write без `@Transactional`.
-- `ARC-05` → `System.getenv` вразброс.
-- Прочие стек-специфичные → при нехватке evidence `🔍 UNVERIFIED`.

package/skills/audit/stacks/node.md

@@ -1,57 +0,0 @@
-# Stack Profile: Node / TypeScript   (id: node)
-Tier: first-class
-
-Покрывает и бэкенд (Node), и фронтенд (браузер/Vite). Это профиль рантайма, а не
-фреймворка — конкретные фреймворки (Express/Fastify/NestJS, React/Vite) упоминаются
-лишь как примеры идиом.
-
-## 1. Detection signals
-- `package.json` (основной маркер)
-- доп.: `tsconfig.json`, `package-lock.json` / `pnpm-lock.yaml` / `yarn.lock`
-
-## 2. Tooling by category
-| Категория | Команда | Как читать вывод |
-|-----------|---------|------------------|
-| unused-code | `npx knip --reporter json 2>/dev/null \| head -200 \|\| true` | неиспользуемые экспорты/зависимости/файлы → YAGNI-02, NAM-06 |
-| clone-detection | `npx jscpd --min-lines 8 --min-tokens 50 --reporters json --silent --output ./.jscpd ./src 2>/dev/null \|\| true` | дубли блоков → REINV-03 |
-| dep-audit | `npm audit --json 2>/dev/null \| head -100 \|\| pnpm audit --json 2>/dev/null \|\| true` | CVE в зависимостях (вне чеклиста — справочно) |
-| env-extraction | `grep -rEoh 'process\.env\.[A-Z0-9_]+\|import\.meta\.env\.[A-Z0-9_]+' ./src 2>/dev/null \| sed -E 's/.*env\.//' \| sort -u` | имена env-переменных из кода → DOC-02 |
-| arch-lint | `npx dependency-cruiser --validate 2>/dev/null \|\| true`; FSD: `npx steiger ./src 2>/dev/null \|\| true` | circular deps → ARC-03; нарушения слоёв FSD |
-| lint/format | `npx biome check 2>/dev/null \|\| npx eslint . 2>/dev/null \|\| true` | — |
-| type-check | `npx tsc --noEmit 2>/dev/null \|\| true` | — |
-| test-run | `npm test 2>/dev/null \|\| true` | — |
-| secret-scan | `gitleaks detect --no-banner 2>/dev/null \|\| trufflehog filesystem . 2>/dev/null \|\| true` | стек-нейтрально |
-
-Всегда верифицируй вывод инструмента вручную (`file:line`) перед `❌ FAIL`.
-
-## 3. Idioms (как выглядит «правильно» → PASS)
-- **Error handling:** `try/catch` вокруг `await`; типизированные ошибки; промисы либо `await`-ятся, либо явно `.catch`. Express 5 / `asyncHandler` пробрасывает rejection в error-middleware.
-- **Concurrency:** `Promise.all`/`allSettled` для независимых задач; `AbortController`/`AbortSignal` для отмены и таймаутов; `process.on('SIGTERM')` для graceful shutdown.
-- **Env/config:** `process.env` (бэкенд) / `import.meta.env` (Vite-фронтенд), валидируется при старте (zod/envalid) и изолируется в config-модуле.
-- **Logging:** структурный логгер (pino/winston) с request/correlation ID; в production нет `console.*`.
-- **Null-safety:** optional chaining `?.`, nullish coalescing `??`; строгие проверки `undefined`/`null`.
-- **Type coercion:** `parseInt(x, 10)` с radix; строгое `===`; явные `Number()`/`String()`.
-- **DI / абстракции:** зависимости инжектируются (конструктор/параметры), не создаются внутри функций; интерфейс оправдан >1 реализацией или тестами.
-- **Deps / reinvention:** предпочитать stdlib (`structuredClone`, `crypto.randomUUID`, `[...new Set()]`, `Array.flat`) и уже установленные библиотеки самописным аналогам.
-- **Build/deploy:** multi-stage Dockerfile; `npm ci` по `package-lock.json`; `NODE_ENV=production`; `USER node`/nonroot; `.dockerignore` исключает `node_modules`/`.git`/`.env`.
-
-## 4. Anti-patterns (как выглядит FAIL)
-- **Errors:** пустой `catch (e) {}`; промис без `await`/`.catch`; `if (asyncFn())` (всегда truthy).
-- **Concurrency:** `async` callback в `Array.forEach`/`map` (потерянные промисы); `await` в последовательном цикле для независимых задач; module-level mutable singleton без инвалидации.
-- **Logging:** `console.log`/`console.error` в production-коде; `[object Object]` в логах.
-- **Type coercion:** `parseInt(x)` без radix; `==` вместо `===`; сравнение float через `===`.
-- **Build/deploy:** `npm install` вместо `npm ci`; нет `NODE_ENV=production`; `node_modules` в build-контексте Docker.
-
-## 5. Check-ID hints
-- `LOG-01` → `console.log`/`console.error`/`console.*` в production.
-- `BUG-01` → `parseInt` без radix, `NaN`-проверки, `==`-coercion.
-- `BUG-02` / `CON-01` → `async` в `forEach`/`map`, потерянные промисы.
-- `BUG-10` → катастрофический backtracking в `RegExp` на user input (ReDoS реален).
-- `DEP-04` → `node_modules`/`.git`/`.env` в build-контексте.
-- `DEP-09` → `NODE_ENV` не выставлен в `production`.
-- `DEP-10` → `npm install` вместо `npm ci`; нет `package-lock.json`.
-- `ERR-04` → нет `process.on('unhandledRejection')`/`uncaughtException`.
-- `ERR-06` → нет `process.on('SIGTERM')` для graceful shutdown.
-- `ERR-09` → `AbortSignal` не пробрасывается во внешние вызовы.
-- `ARC-05` → `process.env.X` разбросан вместо config-модуля.
-- `TST-01` → `tsconfig.json` без `strict: true`.

package/skills/audit/stacks/python.md

@@ -1,45 +0,0 @@
-# Stack Profile: Python   (id: python)
-Tier: general
-
-Профиль уровня general: даёт нейтральные идиомы и ориентиры по инструментам, но
-без гарантий их наличия. Стек-специфичные находки без однозначного evidence
-помечай `🔍 UNVERIFIED`.
-
-## 1. Detection signals
-- `pyproject.toml` / `requirements.txt` / `setup.py`
-- доп.: `Pipfile`, `poetry.lock`, `tox.ini`
-
-## 2. Tooling by category
-| Категория | Команда | Как читать вывод |
-|-----------|---------|------------------|
-| unused-code | `vulture . 2>/dev/null \|\| true` | мёртвый код → YAGNI-02 |
-| clone-detection | `pylint --disable=all --enable=duplicate-code . 2>/dev/null \|\| true` | дубли → REINV-03 |
-| dep-audit | `pip-audit 2>/dev/null \|\| safety check 2>/dev/null \|\| true` | CVE в зависимостях |
-| env-extraction | `grep -rEoh 'os\.environ(\.get)?\(?\["'\'']?[A-Z0-9_]+' . 2>/dev/null \| sort -u` | env из кода → DOC-02 |
-| arch-lint | `import-linter 2>/dev/null \|\| true` | слои/циклы |
-| lint/format | `ruff check . 2>/dev/null \|\| flake8 2>/dev/null \|\| true` | — |
-| type-check | `mypy . 2>/dev/null \|\| pyright 2>/dev/null \|\| true` | — |
-| test-run | `pytest 2>/dev/null \|\| true` | — |
-| secret-scan | `gitleaks detect --no-banner 2>/dev/null \|\| true` | стек-нейтрально |
-
-## 3. Idioms
-- **Errors:** конкретные исключения, не голый `except:`; `finally`/context managers (`with`) для ресурсов.
-- **Concurrency:** `asyncio` с `async/await`; отмена через `asyncio.CancelledError`/`asyncio.timeout`; `concurrent.futures` для CPU.
-- **Env/config:** `os.environ`/pydantic-settings, валидация при старте; изоляция в config-модуле.
-- **Logging:** модуль `logging` со структурой; нет `print()` в production.
-- **Null-safety:** явные проверки `is None`; `Optional[...]`.
-- **Type coercion:** явные `int()`/`str()` с обработкой `ValueError`.
-- **Deps:** stdlib (`itertools`, `functools`, `collections`, `datetime`, `secrets`); `pydantic` для валидации.
-
-## 4. Anti-patterns
-- Голый `except:` / `except Exception: pass`.
-- `print()` для логирования в production.
-- Изменяемые аргументы по умолчанию (`def f(x=[])`).
-- Разбросанный `os.environ[...]` без централизации.
-
-## 5. Check-ID hints
-- `LOG-01` → `print()` вместо `logging`.
-- `ERR-01` → `except: pass` (проглатывание).
-- `BUG-04` → mutable default argument.
-- `ARC-05` → `os.environ` вразброс.
-- Прочие стек-специфичные → при нехватке evidence `🔍 UNVERIFIED`.

package/skills/audit/stacks/rust.md

@@ -1,44 +0,0 @@
-# Stack Profile: Rust   (id: rust)
-Tier: general
-
-Профиль уровня general: нейтральные идиомы + ориентиры по инструментам без
-гарантий их наличия. Стек-специфичные находки без однозначного evidence
-помечай `🔍 UNVERIFIED`.
-
-## 1. Detection signals
-- `Cargo.toml`
-- доп.: `Cargo.lock`, `rust-toolchain.toml`
-
-## 2. Tooling by category
-| Категория | Команда | Как читать вывод |
-|-----------|---------|------------------|
-| unused-code | `cargo +nightly udeps 2>/dev/null \|\| true`; warnings `cargo build` | неиспользуемое → YAGNI-02 |
-| clone-detection | — (нет стандартного инструмента) | grep повторов → `🔍 UNVERIFIED` |
-| dep-audit | `cargo audit 2>/dev/null \|\| true` | CVE в crates |
-| env-extraction | `grep -rEoh '(std::)?env::var\(?"[A-Z0-9_]+"' . 2>/dev/null \| sort -u` | env из кода → DOC-02 |
-| arch-lint | — | ручной разбор слоёв → `🔍 UNVERIFIED` |
-| lint/format | `cargo clippy 2>/dev/null \|\| true`; `cargo fmt --check 2>/dev/null` | — |
-| type-check | `cargo check 2>/dev/null \|\| true` | компиляция = проверка типов |
-| test-run | `cargo test 2>/dev/null \|\| true` | — |
-| secret-scan | `gitleaks detect --no-banner 2>/dev/null \|\| true` | стек-нейтрально |
-
-## 3. Idioms
-- **Errors:** `Result<T, E>` + `?`; `thiserror`/`anyhow`; нет `.unwrap()`/`.expect()` в production-путях.
-- **Concurrency:** `tokio`/`async`; отмена через drop/`CancellationToken`; shared state через `Arc<Mutex<...>>`/каналы.
-- **Env/config:** `std::env::var` с обработкой `Result`; централизованный config (`serde`/`config`).
-- **Logging:** `tracing`/`log` со структурой; нет `println!` в production.
-- **Null-safety:** `Option<T>` + сопоставление с образцом; компилятор гарантирует отсутствие null.
-- **Deps:** crates экосистемы (`serde`, `itertools`, `tokio`); stdlib-итераторы.
-
-## 4. Anti-patterns
-- `.unwrap()`/`.expect()` на пути, где ошибка возможна.
-- `println!`/`eprintln!` для логирования в production.
-- `unsafe` без обоснования.
-- Игнор `Result` (`let _ = ...`) там, где ошибку нужно обработать.
-
-## 5. Check-ID hints
-- `LOG-01` → `println!`/`eprintln!` вместо `tracing`/`log`.
-- `ERR-01` → `.unwrap()`/`.expect()`/проигнорированный `Result`.
-- `BUG-03` → в основном **N/A** (нет null; `Option` проверяется компилятором).
-- `BUG-10` → ReDoS обычно **N/A** (crate `regex` без catastrophic backtracking).
-- Прочие стек-специфичные → при нехватке evidence `🔍 UNVERIFIED`.

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

@@ -1,201 +0,0 @@
----
-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

@@ -1,200 +0,0 @@
----
-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>
-<таблица>
-```