kodu 2.2.0 → 3.0.1

package/skills/audit-validation/SKILL.md

@@ -1,206 +0,0 @@
----
-name: audit-validation
-description: >
-  Аудит валидации граничных данных: проверка входящих данных на границах системы,
-  отсутствие sanitization, trust boundary нарушения. Запускай при /audit-validation.
----
-
-## Правило применимости (Relevance Rule)
-
-Применим к коду, принимающему внешние данные: HTTP handlers, WebSocket, CLI args, file parsers, event consumers, gRPC endpoints. Для чисто внутреннего кода без внешних входов — верни пустой ответ.
-
-## 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» по префиксу `VAL-`.
-- Если профиль `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 | Проверка |
-|----------|----------|
-| VAL-01 | Все входящие данные (body, params, query) проходят schema-валидацию |
-| VAL-02 | Строки имеют maxLength, числа — диапазон, enum-значения — whitelist |
-| VAL-03 | Парсинг недоверенного ввода обрабатывает ошибки и валидирует структуру результата |
-| VAL-04 | Identity данные берутся из аутентифицированного контекста (не из user input) |
-| VAL-05 | Вложенные структуры и массивы ограничены (глубина, minItems/maxItems) |
-| VAL-06 | Валидатор не выполняет неявный coercion (строка "false" → boolean true) [⚡ dynamic] |
-| VAL-07 | Prototype pollution: merge/assign с user input фильтрует `__proto__`, `constructor`, `prototype` |
-| VAL-08 | Загрузка файлов: MIME тип проверяется по содержимому, имя файла санитизировано, размер ограничен |
-
-## Правила верификации
-
-1. **Только чеклист**: оценивай ТОЛЬКО проверки выше. Не добавляй новые.
-2. **Явная верификация = PASS**: ставь `✅ PASS` только если явно проверил механизм (нашёл схему, конфиг, guard) и подтвердил отсутствие нарушения — укажи что именно проверено.
-3. **Нет доказательства = UNVERIFIED**: не можешь указать `файл:строка` ни для нарушения, ни для подтверждения — ставь `🔍 UNVERIFIED`.
-   - Проверки с `[⚡ dynamic]` нельзя статически подтвердить — только `🔍 UNVERIFIED` или `❌ FAIL` (при явном evidence), но не `✅ PASS`
-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
-```
-
-## Контекст анализа
-
-**VAL-01 — Все входящие данные проходят schema-валидацию:**
-- HTTP request body используется напрямую без schema-валидации (Node: zod/joi/yup/etc; Go: проверка в resolver/handler — go-playground/validator или ручная проверка; gqlgen типизирует вход на уровне схемы, но прикладные инварианты всё равно проверяй)
-- Query params / path params используются без типизации и проверки
-- Отсутствие проверки обязательных полей
-- Нет валидации типов (строка может прийти вместо числа)
-- WebSocket, CLI args, event payloads без валидации входных данных
-
-**VAL-02 — Строки, числа, enum ограничены:**
-- Отсутствие maxLength для строк (DoS через огромную строку)
-- Нет проверки диапазонов чисел (отрицательные ID, огромные offset, NaN)
-- Отсутствие whitelist для enum-полей (принимается любое строковое значение)
-- Нет проверки формата (email, UUID, дата) там где она применима
-
-**VAL-03 — Парсинг недоверенного ввода с защитой:**
-- Node: `JSON.parse` без try/catch — выбросит SyntaxError при невалидном input
-- Go: `json.Unmarshal` / парсинг без проверки возвращаемой ошибки (err проигнорирован)
-- Парсинг без последующей валидации структуры (тип полей не проверен)
-- Доверие структуре распарсенного результата без schema-проверки
-
-**VAL-04 — Identity из аутентифицированного контекста:**
-- JWT claims используются без верификации подписи
-- User ID берётся из тела запроса вместо `req.user` / аутентифицированного контекста
-- Данные о ролях/правах берутся из user-controlled input
-- Массовое присваивание: объект из body напрямую сохраняется в БД без whitelist полей
-
-**Вложенность и коллекции:**
-- Рекурсивные/глубоко вложенные схемы без ограничения глубины → ReDoS / stack overflow
-- Массивы без maxItems → неограниченный рост payload
-- Вложенные объекты без maxProperties
-
-**Coercion:**
-- Zod: `.coerce.boolean()` принимает строку "false" как true
-- Joi: без `.options({ convert: false })` неявно кастует типы
-- express-validator: без explicit type checks принимает "1" как число 1
-
-**VAL-07 — Prototype pollution:**
-- Преимущественно JS-специфично (`__proto__`/`constructor`/`prototype`). В Go prototype pollution неприменим (нет прототипной модели объектов) → для Go-рантайма помечай VAL-07 как `N/A`. Концепт ниже актуален для Node:
-- `Object.assign(target, userInput)` без проверки — ключ `__proto__` загрязняет Object.prototype
-- `_.merge(obj, userInput)` в lodash < 4.17.21 — уязвим к prototype pollution
-- Deep merge из user input без sanitize ключей (`constructor`, `prototype`, `__proto__`)
-- Последствие: `({}).isAdmin === true` для всех объектов после атаки
-
-**VAL-08 — Безопасная загрузка файлов:**
-- Проверка типа только через `file.mimetype` — значение подставлено клиентом, не верифицировано
-- `path.join(uploadDir, file.originalname)` — `originalname` может содержать path traversal (`../../../etc/passwd`)
-- Нет ограничения `maxFileSize` — DoS через огромный файл
-- Разрешённые расширения не ограничены — возможна загрузка исполняемых файлов (.sh, .exe, .php)
-
-## Граница с другими аудитами
-
-- **Validation** — этот скилл первичный. `audit-owasp` и `audit-bugs` ссылаются сюда при находках типа "missing input check".
-- **User ID из auth контекста** — VAL-04 первичный. `audit-owasp` (IDOR) — вторичный.
-
-## Формат вывода
-
-| Check ID | Проверка | Статус | Уверенность | Доказательство | Решение | Исправлено |
-|----------|----------|--------|-------------|----------------|---------|------------|
-| VAL-01 | Все входящие данные (body, params, query) проходят schema-валидацию | ✅ PASS | High | `handlers/` — все routes используют zod-схемы | — | — |
-| VAL-02 | Строки имеют maxLength, числа — диапазон, enum-значения — whitelist | ❌ FAIL 🟠 | High | `handlers/user.ts:22` | **1. Добавить maxLength в zod-схему** \\ 2. Ручная проверка длины в handler \\ 3. Ограничение на уровне БД | Нет |
-| VAL-04 | Identity данные берутся из аутентифицированного контекста (не из user input) | ⏸ ACCEPTED | Medium | `routes/order.ts:9` | В baseline: legacy endpoint, запланирован рефактор | — |
-
-Статусы: `✅ 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-validation.md`
-
-```
-# Audit Report: Boundary Data Validation — <YYYY-MM-DD HH:MM>
-<таблица>
-```

package/skills/audit-verify/SKILL.md

@@ -1,139 +0,0 @@
----
-name: audit-verify
-description: >
-  Финальная верификация всех проведённых аудитов: проверяет соответствие находок реальному коду,
-  устраняет false positives, добавляет пропущенные критические риски, исправляет аудит-документы.
-  Вызывай ПОСЛЕДНИМ после всех аудитов — /audit-verify или в конце /audit.
----
-
-## Задача
-
-Ты — старший инженер по безопасности и качеству, проводящий финальную верификацию результатов аудита. Твоя цель: убедиться, что каждая находка реально существует в коде, а не является галлюцинацией или устаревшим артефактом.
-
-## Шаг 1 — Сбор аудит-документов
-
-1. Найди папку последней сессии через Bash:
-   ```bash
-   ls -dt ./docs/audits/[0-9]*/ 2>/dev/null | head -1 | sed 's|/$||'
-   ```
-2. Прочитай все `*.md` файлы из этой папки через Read.
-
-Если папка не найдена — сообщи пользователю: `⚠️ Аудит-документы не найдены. Сначала выполни аудит.` и завершай работу.
-
-## Шаг 1.5 — Проверка актуальности аудита
-
-```bash
-SESSION_DIR=$(ls -dt ./docs/audits/[0-9]*/ 2>/dev/null | head -1 | sed 's|/$||')
-SESSION_DATE=$(basename "$SESSION_DIR" | cut -c1-10)
-DAYS_OLD=$(( ($(date +%s) - $(date -d "$SESSION_DATE" +%s 2>/dev/null || date -j -f "%Y-%m-%d" "$SESSION_DATE" +%s 2>/dev/null || echo 0)) / 86400 ))
-echo "Audit age: $DAYS_OLD days (stale after 30)"
-```
-
-Если `$DAYS_OLD > 30` — добавь в итоговый отчёт:
-```
-⚠️ STALE AUDIT — отчёт создан N дней назад. Код мог измениться. Рекомендуется повторный аудит.
-```
-
-## Шаг 2 — Верификация каждой находки
-
-Для каждой строки в каждой аудит-таблице выполни следующую проверку:
-
-### 2.1 Проверка существования файла и строки
-
-- Извлеки `файл:строка` из колонки «Сценарий».
-- Открой файл через Read (с указанием offset и limit вокруг строки).
-- Убедись, что указанный код реально существует.
-
-### 2.2 Классификация находки
-
-| Статус | Условие |
-|--------|---------|
-| ✅ **Подтверждено** | Код существует, риск актуален |
-| ❌ **False Positive** | Файл/строка не существует, или код не соответствует описанию |
-| ⚠️ **Устарело** | Код существует, но риск уже устранён (защита добавлена) |
-| 🔍 **Пропущено** | В ходе верификации обнаружен критический риск, не попавший в исходный аудит |
-
-### 2.3 Проверка критических рисков (🔴)
-
-Для каждого 🔴 Критического риска дополнительно:
-- Прочитай весь контекст функции/класса (±30 строк).
-- Убедись, что в ближайшем коде нет существующих мер защиты, которые аудит не учёл.
-- Проверь, нет ли аналогичного паттерна в соседних файлах (grep по директории).
-
-### 2.4 Проверка срока действия baseline
-
-Для каждой `⏸ ACCEPTED` записи в аудит-файлах:
-1. Найди соответствующую запись в `docs/audit-baseline.yml`.
-2. Если поле `expires` заполнено и дата прошла — статус автоматически меняется на `❌ FAIL 🟠` с пометкой `[baseline expired: <дата>]`.
-3. Если поле `expires` отсутствует — оставляй `⏸ ACCEPTED` (бессрочное исключение).
-
-## Шаг 3 — Исправление аудит-документов
-
-Для каждого файла с найденными проблемами:
-
-1. **Удали** строки с `❌ False Positive` — они засоряют отчёт.
-2. **Пометь** строки с `⚠️ Устарело` — добавь в колонку «Статус» значение `[✓ устарело]`.
-3. **Добавь** строки с `🔍 Пропущено` в соответствующий аудит-файл.
-4. Перезапиши файл через Write с исправленным содержимым.
-5. **Истёкшие ACCEPTED** строки — измени статус с `⏸ ACCEPTED` на `❌ FAIL 🟠 [baseline expired: YYYY-MM-DD]` и удали из колонки «Решение» ссылку на baseline.
-6. **Устаревшие ссылки** — если файл или строка из FAIL/ACCEPTED записи больше не существует (рефакторинг), удали запись из отчёта с пометкой в лог: `[removed: <file> not found]`.
-
-Если файл не требует изменений — не перезаписывай его.
-
-## Шаг 4 — Отчёт верификации
-
-Выведи итоговый отчёт верификации:
-
-```
-## Результаты верификации
-
-| Аудит-файл | ✅ Подтверждено | ❌ False Positive | ⚠️ Устарело | 🔍 Пропущено |
-|------------|---------------|-----------------|------------|-------------|
-| audit-secrets | N | N | N | N |
-| audit-owasp   | N | N | N | N |
-| ...           | N | N | N | N |
-| **ИТОГО**     | **N** | **N** | **N** | **N** |
-
-### Исправленные документы
-- `<SESSION>/audit-<name>.md` — удалено N false positives, добавлено N пропущенных
-- ...
-
-### Пропущенные критические риски
-[Список новых 🔴-рисков с файл:строка, если найдены]
-```
-
-## Шаг 5 — Сохранение отчёта верификации
-
-1. Найди папку текущей сессии через Bash:
-   ```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-verify.md`
-
-Структура файла:
-```
-# Audit Verification Report — <YYYY-MM-DD HH:MM>
-
-## Результаты верификации
-<таблица из Шага 4>
-
-### Исправленные документы
-<список>
-
-### Пропущенные критические риски
-<список или "Не обнаружено">
-```
-
-Сообщи пользователю путь к папке сессии и краткое резюме: сколько false positives удалено, сколько рисков добавлено.
-
-## Правила
-
-- Не придумывай новые риски — только подтверждай или опровергай существующие, плюс очевидные пропуски в проверенном коде.
-- Не изменяй уровни риска (🔴/🟠/🟡/🟢) у подтверждённых находок.
-- Не редактируй колонку «Варианты решений» у подтверждённых находок.
-- Если файл аудита содержит только `✅ ... не обнаружено` — верификация для него не нужна, пропусти.
-
-## Language Rule
-
-Результаты аудита должны быть написаны простым и понятным языком. Избегай сложных терминов, жаргона и абстрактных понятий без необходимости. Общепринятые технические термины (Docker, HTTP, API, JSON, URL) допустимы. Описывай проблемы так, чтобы они были понятны разработчику любого уровня, а не только узкому специалисту в данной области.

package/skills/audit-yagni/SKILL.md

@@ -1,188 +0,0 @@
----
-name: audit-yagni
-description: >
-  Аудит over-engineering и YAGNI: лишние абстракции, преждевременная оптимизация,
-  неиспользуемый код. Запускай при /audit-yagni или запросе найти переусложнения.
----
-
-## Правило применимости (Relevance Rule)
-
-Применим к любому production-коду с классами, паттернами проектирования или абстракциями. Для простых скриптов-утилит без архитектуры — применяй только к явным over-engineering паттернам.
-
-## 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» по префиксу `YAGNI-`.
-- Если профиль `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 | Проверка |
-|----------|----------|
-| YAGNI-01 | Нет закомментированного кода |
-| YAGNI-02 | Нет dead code — неиспользуемых экспортов, функций, переменных |
-| YAGNI-03 | Абстракции оправданы: интерфейс/фабрика имеет >1 реализации или требуется тестами |
-| YAGNI-04 | Feature flags не зафиксированы в одном значении |
-| YAGNI-05 | Технический долг актуален — нет заброшенных TODO/FIXME без даты или прогресса |
-
-## Правила верификации
-
-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); анти-паттерны рантайма — в профиле (Anti-patterns).
-
-**YAGNI-01 — Нет закомментированного кода:**
-- Блоки кода закомментированы вместо удаления (git history сохраняет историю)
-- Закомментированные альтернативные реализации без объяснения
-
-**YAGNI-02 — Нет dead code:**
-- Экспортируемые функции/классы/константы без единого импорта
-- Переменные объявлены, но не используются
-- Функции определены, но никогда не вызываются
-- Импорты без использования
-
-**YAGNI-03 — Абстракции оправданы:**
-- Интерфейс/абстрактный класс с единственной реализацией (без тестов, где mock нужен)
-- Factory/Builder/Strategy для объекта с 1-2 вариантами создания
-- Generic-типы с одним конкретным использованием
-- Event bus/pub-sub для прямых вызовов между 2 модулями
-- Repository pattern поверх ORM без необходимости абстракции
-- Service layer, просто проксирующий вызовы без логики
-- DTO для объектов, идентичных entity
-
-**YAGNI-04 — Feature flags не зафиксированы:**
-- Feature flag всегда `true` или всегда `false` в коде (не читается из конфига/env)
-- Конфигурируемость параметров, которые никогда не меняются
-- Опциональные параметры, всегда передаваемые с одним значением
-
-**YAGNI-05 — Технический долг актуален:**
-- TODO/FIXME без даты создания или имени автора
-- TODO/FIXME старше 6 месяцев без признаков прогресса
-- TODO без ссылки на issue/ticket (нет трекинга)
-
-## Инструментальная поддержка
-
-Для YAGNI-02 используй инструмент категории **unused-code** из профиля стека
-(секция «Tooling by category»): он находит неиспользуемые экспорты, функции,
-зависимости и файлы. Используй вывод как подсказку для YAGNI-02 и верифицируй
-каждую находку вручную (`file:line`) перед занесением в FAIL. Если ячейка пустая
-(tier general/generic) — проверяй вручную и помечай находки `🔍 UNVERIFIED`.
-
-## Формат вывода
-
-| Check ID | Проверка | Статус | Уверенность | Доказательство | Решение | Исправлено |
-|----------|----------|--------|-------------|----------------|---------|------------|
-| YAGNI-01 | Нет закомментированного кода | ✅ PASS | High | `src/` — закомментированного кода не найдено | — | — |
-| YAGNI-02 | Нет dead code — неиспользуемых экспортов, функций, переменных | ❌ FAIL 🟡 | High | `lib/formatters.ts:89` | **1. Удалить неиспользуемые экспорты** \\ 2. Добавить ts-prune в CI для автоматического обнаружения \\ 3. Пометить @deprecated и удалить в следующем релизе | Нет |
-| YAGNI-05 | Технический долг актуален — нет заброшенных TODO/FIXME без даты или прогресса | ⏸ ACCEPTED | Medium | `src/auth.ts:34` | В baseline: known tech debt, трекается в Jira PROJ-123 | — |
-
-Статусы: `✅ 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 — выведи: `✅ Over-engineering не обнаружен.`
-
-## Сохранение результатов
-
-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-yagni.md`
-
-```
-# Audit Report: Over-engineering & YAGNI — <YYYY-MM-DD HH:MM>
-<таблица>
-```