---
name: audit
description: One-command project audit. project-status tool + explore subagent (code-standards) → binary verdict → ask user → create-issue for each problem. Read-only (creates issues, NOT fixes). Also when user says "аудит проекта", "проверь проект", "audit", "проверь архитектуру".
---

# Audit

Линейный flow для аудита существующего проекта. В отличие от
`project-template` check flow (который чинит через FIX subagents напрямую),
audit создаёт **GitHub issues** для рефакторинга — дальше юзер запускает
`/run-pipeline` на каждом issue (pipeline-подход: ISSUE → IMPLEMENT → CI →
REVIEW → MERGE).

Источники находок:
- **`project-status` tool** — детерминированные проблемы (нет `conftest.py`,
  нет `ci.yml`, thin routes, centralized models). Agent парсит текстовый
  отчёт (НЕ JSON — `project-status.py` не трогаем).
- **`explore` subagent + `code-standards` skill** — качественные проблемы
  (`project-status` НЕ ловит): schemas смешаны с models, бизнес-логика в
  роутах, нарушение layering, service-слой пропущен.

## ПРОТОКОЛ (ЖЁСТКО)

1. **`project-status({})`** — оркестратор вызывает tool напрямую (read-only
   oracle, ALLOWED — как `pipeline-status` / `spec-status`). Если вернул
   `⚠️ ...failed` → WARN, продолжай без детерминированных находок (explore
   всё равно работает).
2. **Парсит отчёт** (текст): `Итог:` (OK/WARN/FAIL counts) + `Рекомендации:`
   (список FAIL с путями).
3. **`skill({ name: "code-standards" })`** — load skill (НЕ хардкод правил в
   audit skill — `code-standards` источник правды).
4. **Delegate `explore` subagent** (Template EXPLORE) — проверяет структуру
   и код против `code-standards`, возвращает
   `[{category, problem, path, severity}, ...]`.
5. **Комбинирует** находки: FAIL/WARN из `project-status` + качественные из
   explore. **Дедупликация**: если `project-status` FAIL и explore нашли
   одну и ту же проблему → 1 issue (не 2).
6. **Бинарный вердикт**:
   - `≥1 FAIL` ИЛИ `≥1 qualitative finding` → `❌ Найдено N проблем`
   - `0 FAIL` + `0 qualitative` + `0 WARN` → `✅ Проект здоров` → STOP
   - `0 FAIL` + `0 qualitative` + `≥1 WARN` → `⚠️ N замечаний` → вопрос
7. **Список проблем** (сгруппированный: Структура / Качество / Тесты / Infra
   / Code-standards) — покажи юзеру.
8. **Вопрос юзеру**:
   ```
   Найдено N проблем. Создать issues для рефакторинга?
   [1] да — для каждой проблемы create-issue (subagent)
   [2] нет — STOP, отчёт у юзера
   ```
9. Если `да` → для **каждой** проблемы (последовательно, НЕ параллельно —
   Linear Execution из AGENTS.md) — delegate `task(general)` с Template
   ISSUE_CREATE. Если `create-issue` валидация упала → subagent сообщает
   ошибку, continue к следующей. Если gh недоступен → STOP + report.
10. **Финальный репорт**:
    ```
    Audit complete. Создано N issues:
    - #M1: <title> — <url>
    Запусти /run-pipeline на каждом issue для рефакторинга.
    ```

### ЗАПРЕЩЕНО

- Чинить код напрямую (audit = read-only, только issues). FIX flow остаётся
  в `project-template` check flow.
- Параллелить create-issue subagents (Linear Execution).
- Хардкодить правила из `code-standards` — загружай через `skill()`.
- Трогать `project-status.py` (агент парсит текст — JSON не нужен).
- Создавать `audit-status` tool (audit — линейный, не фазный loop).
- Группировать проблемы в один issue (1 проблема = 1 issue для `/run-pipeline`).

## Граничные случаи

- **Репо UNKNOWN типа** → explore всё равно проверяет против
  `code-standards`, вердикт по качественным находкам.
- **Репо без `src/<pkg>/`** (flat layout) → `project-status` WARNs, explore
  проверяет по `code-standards` (если применимо).
- **Только WARN** (0 FAIL, 0 qualitative) → `⚠️ N замечаний`, вопрос (да/нет
  — на усмотрение юзера).
- **Юзер "нет"** → STOP, отчёт у юзера.
- **create-issue валидация упала** → subagent сообщает, continue к следующей.
- **Дублирующие проблемы** → дедупликация оркестратором (1 issue, не 2).

## Prompt templates

### Template EXPLORE (code-standards qualitative audit)

```
Прочитай .opencode/skills/code-standards/SKILL.md.
Проверь структуру и код проекта в <cwd> против правил из skill.
Найди качественные проблемы, которые project-status НЕ ловит:
- schemas смешаны с models (Pydantic DTO в db/models/)
- бизнес-логика в роутах (Tortoise queries в api/)
- нарушение layering (routes импортируют db/models напрямую, минуя services)
- service-слой пропущен (routes → db/models без services/)
- файлы длиннее 200-300 строк (декомпозиция)
- mixing concerns (бизнес-логика ≠ транспорт ≠ представление)

Для каждой находки верни:
{category: "Code-standards", problem: "<name>: <detail>", path: "<file:line>", severity: "warn"|"fail"}

Верни массив находок. Если находок нет — пустой массив [].
НЕ редактируй код — audit read-only. Только отчёт.
```

### Template ISSUE_CREATE (create-issue для одной проблемы)

```
Создай GitHub issue для проблемы из audit.
Категория: <category>
Проблема: <name>: <detail>
Путь: <path>
Источник: <project-status | code-standards explore>
Severity: <warn|fail>

1. Load `issue` skill via `skill({ name: "issue" })`.
2. Сформируй issue body (8 headings: ## Контекст, ## Задача, ## Контракты,
   ## Инварианты, ## Граничные случаи, ## Влияние на связанные компоненты,
   ## Вне scope, ## Критерии приемки).
   - Контекст: проблема из audit (<repo>) — <name>: <detail>. Путь: <path>.
     Источник: <source>. Severity: <severity>.
   - Задача: что починить (конкретно, с путями к файлам).
   - Контракты: конкретные изменения (что должно стать после фикса).
   - Инварианты: что НЕ ломать при фиксе.
   - Граничные случаи: edge cases при фиксе.
   - Влияние на связанные компоненты: зависящие audit-категории/оракулы/промпты; paired updates; «нет связанных компонентов» для тривиальных фиксов.
   - Вне scope: что НЕ делаем в этом issue.
   - Критерии приемки: чек-лист (включая `project-status` проходит эту
     категорию после фикса).
3. `create-issue({ title: "fix(<scope>): <description>", body, labels: ["tech-debt", "from-audit"] })`
   tool (НЕ raw `gh issue create` — заблокирован deny). tool валидирует
   conventional title + 8 headings + Cyrillic.
4. Верни: issue URL (или ошибку валидации для оркестратора).

Если gh недоступен → верни: "gh unavailable: <reason>". НЕ retry, НЕ fallback.
```

## Rules

- Main agent = оркестратор: `project-status` tool + `explore` subagent +
  вопрос юзеру + `task(general)` для create-issue. Не делает
  edit/read/`gh issue create` сам.
- `project-status` — read-only oracle, ALLOWED для оркестратора.
- Audit — read-only (НЕ редактирует код, только создаёт issues).
- FAIL/WARN из `project-status` → issues, НЕ FIX напрямую.
- 1 проблема = 1 issue (для отдельного `/run-pipeline`).
- Issue body self-contained (8 headings, `create-issue` валидация).
- `code-standards` — через `skill()` tool, НЕ хардкод.
- Audit — линейный flow (не `audit-status` tool).
- create-issue subagents — последовательно (Linear Execution).
- Subagent error → 1 retry, потом STOP + report.