kodu 2.1.2 → 2.2.0

package/skills/audit-reinvention/SKILL.md

@@ -0,0 +1,214 @@
+---
+name: audit-reinvention
+description: >
+  Аудит переизобретения велосипедов: ручная реализация того, что уже есть в stdlib/языке,
+  в установленных зависимостях или дублируется внутри проекта; предлагает зрелое готовое решение.
+  Запускай при /audit-reinvention или запросе найти переизобретённые велосипеды.
+---
+
+## Правило применимости (Relevance Rule)
+
+Применим к любому production-коду, где есть прикладная логика. Для тонких клеевых модулей (конфиги, чистые типы, сгенерированный код) — пропускай. Цель — найти код, который руками делает то, что уже умеет язык, рантайм, установленная библиотека или другая часть этого же проекта.
+
+**Не путать с соседними аудитами** (граница ответственности, чтобы не дублировать находки):
+- `audit-yagni` — про **лишнее**: ненужные абстракции, dead code, преждевременная оптимизация. Здесь — про **переизобретённое**: нужная функциональность, но написанная руками вместо готового решения.
+- `audit-architecture` (ARC-04 god-объекты) — про размер/ответственность модулей. REINV-03 — про **смысловое дублирование** одинаковой логики в разных местах.
+- Если нарушение лучше описывается соседним аудитом — отдай его туда и не дублируй.
+
+## Runtime Detection & Stack Profile
+
+Этот аудит стек-агностичен: проверки сформулированы нейтрально, а конкретика
+(stdlib-аналоги, идиомы, анти-паттерны, примеры) берётся из профиля стека.
+
+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`).
+
+Дальше: stdlib-аналоги и инструменты — из секций «Idioms»/«Tooling by category»
+профиля; формулировки FAIL — из «Anti-patterns»; точечные подсказки — из «Check-ID
+hints» по префиксу `REINV-`. Для `tier: general`/`generic` рекомендации без
+уверенности в наличии аналога помечай `🔍 UNVERIFIED`.
+
+**Важно:** что считать «готовым решением», определяй ТОЛЬКО по манифесту
+зависимостей/lock-файлу и stdlib рантайма (см. профиль). Не предполагай наличие
+библиотеки без её записи в зависимостях.
+
+## Severity Guide
+
+| Severity | Критерий назначения |
+|----------|---------------------|
+| 🔴 Critical | Самописная **безопасность**-примитива: своё хеширование паролей, своя крипта, свой JWT-парсер, своё SQL-экранирование, свой HTML-санитайзер. Ручная реализация почти всегда содержит уязвимость. |
+| 🟠 High | Переизобретение, дающее реальные баги в проде: самописный retry/таймаут без jitter, самописный парсер дат/таймзон, ручная конкурентная очередь, ручной деньги/decimal-арифметик на float. |
+| 🟡 Medium | Поддерживаемость: руками написано то, что есть в stdlib или установленной либе, но работает корректно (dedup, deepClone, debounce, groupBy). |
+| 🟢 Low | Мелочь: тривиальный однострочный аналог stdlib, читаемость не страдает. |
+
+Правило: severity = impact × exploitability × blast radius. **Безопасность-примитивы всегда эскалируются** минимум до 🟠, чаще 🔴 — даже если «вроде работает». Одинаковый паттерн → одинаковый severity между аудитами.
+
+## Чеклист
+
+| Check ID | Проверка |
+|----------|----------|
+| REINV-01 | Нет ручной реализации того, что есть в stdlib/языке/рантайме |
+| REINV-02 | Нет ручной реализации того, что уже умеет установленная зависимость |
+| REINV-03 | Нет смыслового дублирования: одинаковая логика не переписана в ≥2 местах вместо общей утилиты |
+| REINV-04 | Крупные механизмы (ORM, DI, scheduler, logger, job queue, валидатор) не написаны с нуля при наличии зрелого стандартного решения |
+
+## Правила верификации
+
+1. **Только чеклист**: оценивай ТОЛЬКО проверки выше. Не добавляй новые.
+2. **Явная верификация = PASS**: ставь `✅ PASS` только если просмотрел ключевые модули (utils, helpers, lib, core, services) и подтвердил отсутствие переизобретения — укажи что именно проверено.
+3. **Нет доказательства = UNVERIFIED**: не можешь указать `файл:строка` для самописной реализации И подтвердить наличие готового аналога — ставь `🔍 UNVERIFIED`.
+4. **Аналог обязан существовать**: `❌ FAIL` для REINV-01/02/04 валиден ТОЛЬКО если ты назвал конкретный готовый аналог (stdlib-API, пакет из `package.json`, или зрелую библиотеку) — иначе это не велосипед, а просто код.
+5. **Baseline приоритетен**: check_id есть в `docs/audit-baseline.yml` → `⏸ ACCEPTED`.
+6. **Только 🔴/🟠 FAIL требуют решения**: 🟡/🟢 — решение необязательно.
+
+## Evidence Quality Rules
+
+Любой `❌ FAIL` обязан содержать:
+- Точный `file:line` самописной реализации
+- Минимальный код-фрагмент (1–3 строки)
+- **Имя готового аналога**: `crypto.randomUUID()`, `structuredClone`, `zod` (есть в deps), `date-fns` и т.п.
+- Causal chain: почему это велосипед → какой риск (баг/уязвимость/стоимость поддержки)
+
+Запрещено:
+- Помечать как велосипед код, для которого ты НЕ назвал конкретный готовый аналог
+- Предполагать наличие библиотеки без записи в манифесте зависимостей/lock
+- Считать «велосипедом» намеренно тонкую обёртку вокруг библиотеки (это адаптер, а не переизобретение)
+- Если вывод основан на предположении — только `🔍 UNVERIFIED`
+
+## Language Rule
+
+Результаты аудита должны быть написаны простым и понятным языком. Избегай сложных терминов, жаргона и абстрактных понятий без необходимости. Общепринятые технические термины (Docker, HTTP, API, JSON, URL) допустимы. Описывай проблемы так, чтобы они были понятны разработчику любого уровня, а не только узкому специалисту в данной области.
+
+## Baseline
+
+До анализа:
+```bash
+if [ ! -f ./docs/audit-baseline.yml ]; then
+  mkdir -p ./docs
+  cp ./skills/audit/audit-baseline-template.yml ./docs/audit-baseline.yml 2>/dev/null || \
+    printf "accepted: []\n" > ./docs/audit-baseline.yml
+fi
+cat ./docs/audit-baseline.yml
+```
+
+## Контекст анализа
+
+> Примеры ниже — иллюстративные (Node/TS). Конкретные stdlib-аналоги и
+> установленные библиотеки для текущего рантайма бери из загруженного профиля
+> (`stacks/<runtime>.md`, секции Idioms/Anti-patterns/Check-ID hints). Например
+> для Go: `[...new Set()]` → `slices`/`maps`, самописный query builder →
+> `database/sql`/sqlc, ручная отмена → `context.Context`.
+
+**REINV-01 — Ре-имплементация stdlib/языка/рантайма:**
+- Дедупликация массива руками вместо `[...new Set(arr)]`
+- Самописный deep clone вместо `structuredClone()`
+- Генерация UUID руками вместо `crypto.randomUUID()`
+- Ручной base64 вместо `Buffer`/`btoa`/`atob`
+- Самописные `debounce`/`throttle`/`groupBy`/`flatten`, когда есть `Array.flat`, `Object.groupBy`, либо они уже в установленной либе (тогда это скорее REINV-02)
+- Цикл с аккумулятором вместо `Promise.all`/`Promise.allSettled` для независимых задач
+- Ручной парсинг query string вместо `URLSearchParams`
+- Самописное сравнение/сортировка дат вместо `Intl`/установленной date-либы
+
+**REINV-02 — Дублирование установленной зависимости:**
+- Самописный HTTP retry/backoff при наличии `axios-retry`/`p-retry`/`got` (retry встроен)
+- Ручная валидация полей при наличии `zod`/`yup`/`joi`/`class-validator`/`pydantic`
+- Самописный `deepEqual`/`cloneDeep`/`pick`/`omit` при наличии `lodash`/`ramda`
+- Ручная арифметика дат при наличии `date-fns`/`dayjs`/`luxon`
+- Своя реализация того, что уже даёт фреймворк (свой body-parser/роутер/CORS при наличии встроенного)
+- Свой in-memory кэш с TTL при наличии `lru-cache`/`node-cache` в deps
+
+**REINV-03 — Внутренние смысловые дубликаты:**
+- Одинаковая по смыслу функция скопирована в ≥2 файлах вместо общей утилиты
+- Два хелпера под разными именами делают одно и то же
+- Повторяющийся inline-блок (форматирование, маппинг, guard), который должен быть единой функцией
+- Граница: если это про размер модуля — отдать в `audit-architecture` (ARC-04); если про мёртвый код — в `audit-yagni`
+
+**REINV-04 — Самописный крупный механизм при наличии зрелого решения:**
+- Свой ORM/query builder, свой DI-контейнер, свой scheduler/cron, свой logger, своя job queue, свой state machine, свой event bus
+- Самописный механизм, для которого в экосистеме рантайма есть зрелое стандартное решение, ещё НЕ установленное в проект
+- Для такого FAIL обязательна **оценка стоимости миграции** в решении (реалистичная, без «переписать всё»)
+
+## Правила рекомендаций (политика новых зависимостей)
+
+Рекомендации **стек-агностичны**: опирайся на Runtime Detection, не привязывайся к конкретным шаблонам проекта.
+
+Приоритет вариантов решения, сверху вниз:
+1. **stdlib/язык/рантайм** — всегда предпочтительнее, если аналог есть (нулевая стоимость).
+2. **Уже установленная зависимость** — если в манифесте зависимостей (см. профиль) есть подходящая либа, используй её.
+3. **Новая зависимость — осторожно**: предлагать ТОЛЬКО для зрелых/популярных библиотек (активная поддержка, высокая распространённость) И с обязательной оценкой стоимости миграции. Для мелочей (dedup, clone) новую либу НЕ предлагать — там хватает stdlib.
+
+Для безопасности-примитивов (REINV-01/04 с severity 🔴): «оставить самописное» **не может** быть валидным вариантом — только переход на проверенное решение.
+
+## Инструментальная поддержка
+
+Для REINV-03 используй инструмент категории **clone-detection** из профиля стека
+(секция «Tooling by category»): он находит дублирующиеся блоки кода. Верифицируй
+каждое совпадение вручную перед занесением в FAIL (бывают ложные: сгенерированный
+код, похожие, но не идентичные по смыслу блоки). Если ячейка категории пустая
+(`tier: general`/`generic`) — ищи повторы вручную и помечай находки `🔍 UNVERIFIED`.
+
+Для REINV-02 сверяй найденные самописные реализации со списком установленных
+зависимостей (манифест/lock из профиля) — что реально доступно в проекте.
+
+## Формат вывода
+
+| Check ID | Проверка | Статус | Уверенность | Доказательство | Решение | Исправлено |
+|----------|----------|--------|-------------|----------------|---------|------------|
+| REINV-01 | Нет ручной реализации того, что есть в stdlib/языке/рантайме | ❌ FAIL 🟡 | High | `src/utils/array.ts:12` — ручной dedup циклом; есть `[...new Set()]` | **1. Заменить на `[...new Set(arr)]`** \\ 2. Вынести в общий хелпер `unique()` \\ 3. Оставить, если важен порядок и кастомный компаратор — задокументировать | Нет |
+| REINV-02 | Нет ручной реализации того, что уже умеет установленная зависимость | ❌ FAIL 🟠 | High | `src/http/client.ts:40` — самописный retry-цикл; в deps есть `axios-retry` | **1. Подключить `axios-retry` с exponential backoff + jitter** \\ 2. Заменить на `p-retry` (уже в deps) \\ 3. Оставить, добавив jitter и тесты — обосновать | Нет |
+| REINV-04 | Крупные механизмы не написаны с нуля при наличии зрелого решения | ✅ PASS | Medium | `src/` — самописных ORM/DI/scheduler не найдено | — | — |
+| REINV-03 | Нет смыслового дублирования логики | ⏸ ACCEPTED | Medium | `src/a.ts`, `src/b.ts` | В baseline: дубли в legacy-модуле, трекается в Jira PROJ-456 | — |
+
+Статусы: `✅ PASS` / `❌ FAIL 🔴` / `❌ FAIL 🟠` / `❌ FAIL 🟡` / `❌ FAIL 🟢` / `⏸ ACCEPTED` / `🔍 UNVERIFIED`
+
+Уверенность: `High` — нашёл самописную реализацию и подтвердил наличие аналога / `Medium` — паттерн вероятен, аналог есть, но контекст использования проверен выборочно / `Low` — ограниченный контекст, полная уверенность невозможна
+
+Для `❌ FAIL`: ровно 3 варианта решения, разделитель `\\`, вариант 1 жирным.
+
+`Исправлено`: FAIL → `Нет` (разработчик меняет на `✅ Да` вручную после фикса). PASS / ACCEPTED / UNVERIFIED → `—`.
+
+Требования к решениям:
+- Каждый вариант называет **конкретный** готовый аналог (API stdlib или имя пакета)
+- Взаимно исключающие (не перефразировки одного и того же)
+- Соответствуют текущему рантайму и политике зависимостей выше
+- Не требуют переписать всю систему — realistic migration cost
+- Вариант 3 может быть «оставить, задокументировать причину» — НО запрещён для безопасности-примитивов (🔴)
+
+В конце отчёта добавь раздел покрытия:
+```
+## Audit Coverage
+Проверено: src/utils/**, src/services/**, src/http/**
+Пропущено: scripts/**, migrations/**, tests/**, generated/**
+Файлов проверено: 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-reinvention.md`
+
+```
+# Audit Report: Reinventing the Wheel — <YYYY-MM-DD HH:MM>
+<таблица>
+```

package/skills/audit-secrets/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: audit-secrets
+description: >
+  Аудит утечки секретов: поиск захардкоженных ключей, паролей, токенов, credentials в коде.
+  Запускай когда пользователь просит проверить код на наличие секретов, утечки credentials,
+  hardcoded паролей или при инвоке /audit-secrets.
+---
+
+## Правило применимости (Relevance Rule)
+
+Перед анализом оцени: содержит ли код конфигурации, строки подключения, токены, ключи шифрования, credentials или работу с внешними API? Если анализируемый файл/модуль не содержит ни одного из перечисленных паттернов — верни пустой ответ без таблицы.
+
+## 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» по префиксу `SEC-`.
+- Если профиль `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 | Проверка |
+|----------|----------|
+| 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) |
+
+## Правила верификации
+
+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
+```
+
+## Контекст анализа
+
+**SEC-01 — Нет hardcoded credentials в коде:**
+- Пароли, токены, API-ключи в строковых литералах
+- Строки подключения к БД с credentials (`postgres://user:pass@host`)
+- Private keys, certificates, JWT secrets в коде
+- Base64-encoded credentials в коде
+- Тестовые/дев credentials, которые могут попасть в прод
+- Паттерны: `password = "..."`, `token = "..."`, `key = "..."`, `secret = "..."`
+
+**SEC-02 — Файлы с секретами исключены из VCS:**
+- `.env`, `.env.local`, `.env.production` не в `.gitignore`
+- Закоммиченные `.env`-файлы с реальными данными в репозитории
+- Certificate и key файлы (`*.pem`, `*.key`, `*.p12`) не исключены из VCS
+
+**SEC-03 — Секреты не в URL:**
+- API-ключи или токены в query params (`?api_key=...`)
+- Basic Auth credentials в URL (`https://user:pass@host`)
+- Секреты в redirect_uri или callback URL параметрах
+
+**SEC-04 — .env.example без реальных данных:**
+- `.env.example` содержит реальные значения вместо placeholders (`DB_PASS=realpassword`)
+- Placeholder-значения не описывают ожидаемый формат (`DB_URL=` без пояснения)
+
+**SEC-05 — Dockerfile без секретов в ENV:**
+- Секреты в `ENV` директивах Dockerfile (видны в docker inspect и слоях образа)
+- Credentials в `ARG` без использования build secrets
+- Секреты в LABEL или COPY-командах
+
+**SEC-06 — Комментарии без credentials:**
+- Пароли или токены в закомментированном коде
+- TODO-комментарии с примерами реальных credentials
+- Инструкции по настройке с реальными значениями
+
+**Автоматическое сканирование (SEC-07):**
+- Инструмент бери из категории **secret-scan** профиля стека (кросс-стек: `gitleaks` / `trufflehog`; также detect-secrets) — он стек-нейтрален.
+- Отсутствие такого сканера в git-хуках (lefthook / pre-commit / husky) — нет автопроверки при коммите
+- Отсутствие secret scanning в CI/таск-раннере (Taskfile/Makefile-цель, GitHub Actions secret scanning, GitLab SAST)
+- `.gitleaks.toml` / `.secrets.baseline` не настроен
+- При наличии любого из инструментов в хуках или CI → `✅ PASS`
+
+## Граница с другими аудитами
+
+- **Secrets в коде** — этот скилл первичный. `audit-logging` (LOG-03) и `audit-deployment` (DEP-06) ссылаются сюда.
+- **Secrets в логах** — первичный: `audit-logging` (LOG-03). Здесь не дублируй.
+- **Secrets в Dockerfile ENV** — дублирован намеренно (DEP-06 + SEC-05): критичность оправдывает двойную проверку.
+
+## Формат вывода
+
+| Check ID | Проверка | Статус | Уверенность | Доказательство | Решение | Исправлено |
+|----------|----------|--------|-------------|----------------|---------|------------|
+| SEC-01 | Нет hardcoded credentials в коде (пароли, токены, API-ключи, приватные ключи) | ✅ PASS | High | `.gitignore`, `src/` проверены — паттернов не найдено | — | — |
+| SEC-02 | Файлы с секретами исключены из VCS (.env* в .gitignore) | ❌ FAIL 🔴 | High | `.gitignore:1` | **1. Добавить .env в .gitignore** \\ 2. Использовать git-crypt \\ 3. Удалить .env из истории через git-filter-repo | Нет |
+| SEC-03 | Секреты не передаются через URL (query params, Basic Auth в URL) | ⏸ ACCEPTED | Medium | `config.ts:9` | В baseline: legacy-интеграция, планируется замена | — |
+| SEC-07 | Автоматическое сканирование секретов настроено (pre-commit или CI) | 🔍 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-secrets.md`
+
+```
+# Audit Report: Secrets Leak — <YYYY-MM-DD HH:MM>
+<таблица>
+```

package/skills/audit-tests/SKILL.md

@@ -0,0 +1,210 @@
+---
+name: audit-tests
+description: >
+  Аудит тестов и линтеров: конфигурации тестов, линтеров, TypeScript, покрытие критических путей,
+  false-positive тесты. Запускай при /audit-tests или запросе проверить тесты/конфигурацию.
+---
+
+## Правило применимости (Relevance Rule)
+
+Применим при наличии файлов тестов (`*.test.*`, `*.spec.*`), конфигов (`jest.config.*`, `eslint*`, `tsconfig*`, `.eslintrc`, `vitest.config.*`). Для кода без тестов и конфигов — верни пустой ответ.
+
+## 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» по префиксу `TST-`.
+- Если профиль `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 | Проверка |
+|----------|----------|
+| TST-01 | Строгий статический анализ включён и обязателен (компилятор/линтер не пропускает небезопасные конструкции) |
+| TST-02 | Пороги покрытия настроены и применяются |
+| TST-03 | Хуки/CI запускают проверки (тесты, линт, типы) |
+| TST-04 | Критические пути покрыты тестами (auth, validation, error handling) |
+| TST-05 | Тесты изолированы — нет shared mutable state между тестами |
+| TST-06 | Нет отключённых/сфокусированных тестов без обоснования |
+| TST-07 | Тесты проверяют поведение, а не детали реализации |
+| TST-08 | Источники недетерминизма мокаются/инъектируются [⚡ dynamic] |
+| TST-09 | Golden/snapshot-тесты охватывают значимое, не весь объект целиком |
+
+## Правила верификации
+
+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
+```
+
+## Контекст анализа
+
+> Примеры ниже — иллюстративные. Конкретные инструменты строгого анализа, идиомы
+> и анти-паттерны для текущего рантайма бери из загруженного профиля
+> (`stacks/<runtime>.md`, секции Idioms/Anti-patterns/Tooling by category/Check-ID
+> hints по префиксу `TST-`). Node: tsconfig `strict`, jest/vitest, husky/lefthook.
+> Go: `go vet`/`staticcheck`/`golangci-lint`, `go test -cover`, Taskfile/lefthook.
+
+**TST-01 — Строгий статический анализ включён и обязателен:**
+- Node: `tsconfig.json` с `strict: false` или отключёнными важными флагами (`noImplicitAny`, `strictNullChecks`); `ts-ignore`/`@ts-expect-error` без объяснений; `any` в публичных API
+- Go: `go vet` + `staticcheck` + `golangci-lint` (включая `errcheck`/`nilness`/`gosec`) не настроены или не обязательны в CI
+- Отключённые важные правила линтера/анализатора без обоснования
+
+**TST-02 — Пороги покрытия настроены и применяются:**
+- Node: `jest.config`/`vitest.config` без `coverageThreshold`
+- Go: нет `go test -cover -coverprofile`; порог не задан и не проверяется в CI/Taskfile (встроенного флага порога нет — проверка должна быть явной)
+- Пороги настроены, но не применяются в pipeline; либо заданы слишком низко (0% / не заданы)
+
+**TST-03 — Хуки/CI запускают проверки (тесты, линт, типы):**
+- Отсутствие git hooks (lefthook — кросс-стек, husky — Node) или эквивалентных CI-шагов
+- Хуки/цели не запускают статический анализ / линт / тесты (npm-scripts ↔ цели Taskfile)
+- Хуки настроены, но отключены или обходятся через `--no-verify`
+
+**TST-04 — Критические пути покрыты:**
+- Auth пути (login, logout, token refresh) без тестов
+- Validation logic без тестов для невалидных входных данных
+- Error handling пути (что происходит при сбое DB, внешнего API) не протестированы
+- Edge cases (пустой список, максимальное значение, null) не покрыты
+
+**TST-05 — Тесты изолированы:**
+- Глобальные моки, влияющие на изоляцию других тестов
+- Shared mutable state между тест-кейсами в одном suite
+- Тесты, зависящие от порядка выполнения
+- Отсутствие setup/teardown для интеграционных тестов
+- Go: `t.Parallel()` при общем мутируемом состоянии без синхронизации
+
+**TST-06 — Нет отключённых/сфокусированных тестов без обоснования:**
+- Сфокусированный тест глушит остальные (Node: `.only`)
+- Тест отключён без причины (Node: `.skip`; Go: `t.Skip()` без объяснения, скрытие за build-тегами)
+- Закомментированные тесты без объяснения
+
+**TST-07 — Тесты проверяют поведение:**
+- Tautology-тесты (Node: `expect(true).toBe(true)`)
+- Тесты без assertions (всегда зелёные)
+- Тесты, проверяющие implementation details (внутренние переменные, приватные методы/неэкспортируемые функции) вместо behavior
+- Один огромный тест вместо нескольких изолированных по сценарию
+
+**TST-08 — Источники недетерминизма мокаются/инъектируются:**
+- Случайность без контроля (Node: `Math.random()` без mock; Go: `math/rand` без фиксированного seed)
+- Реальное время вместо инъекции (Node: `new Date()`/`Date.now()` без `useFakeTimers`; Go: прямой `time.Now()` вместо инъекции `Clock`)
+- Синхронизация через задержку вместо ожидания события (Node: `setTimeout`/`sleep(N)`; Go: `time.Sleep` для синхронизации горутин вместо канала/`WaitGroup`)
+- Тесты, зависящие от порядка выполнения (shared state)
+
+**TST-09 — Golden/snapshot-тесты охватывают значимое:**
+- Снимок всего объекта/компонента (500+ строк) — изменение одной строки ломает всё (Node: snapshot, Go: `testdata/*.golden`)
+- Снимок объектов с динамическими полями (id, createdAt) без маскировки
+- Обновление golden/snapshot без ревью изменений
+
+## Формат вывода
+
+| Check ID | Проверка | Статус | Уверенность | Доказательство | Решение | Исправлено |
+|----------|----------|--------|-------------|----------------|---------|------------|
+| TST-01 | Строгий статический анализ включён и обязателен (компилятор/линтер не пропускает небезопасные конструкции) | ✅ PASS | High | `tsconfig.json:5` — strict: true | — | — |
+| TST-02 | Пороги покрытия настроены и применяются | ❌ FAIL 🟠 | High | `jest.config.ts:1` | **1. Добавить `coverageThreshold: { global: { lines: 80 } }`** \\ 2. Настроить thresholds только для критических модулей \\ 3. Добавить coverage check в CI без блокировки | Нет |
+| TST-06 | Нет отключённых/сфокусированных тестов без обоснования | ⏸ ACCEPTED | Medium | `tests/auth.test.ts:45` | В baseline: временно для дебага, будет убрано | — |
+
+Статусы: `✅ 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-tests.md`
+
+```
+# Audit Report: Test & Linter Integrity — <YYYY-MM-DD HH:MM>
+<таблица>
+```