---
name: wave-audit
description: 3-wave parallel audit — Wave 1 discovery (4 agents), Wave 2 verification (4 agents), Wave 3 cross-optimization (1 synthesizer). Each wave runs agents in parallel. Combines security review, runtime analysis, quality check, and constructor pattern into one unified workflow with evidence grading and Go/No-Go verdict.
---

# /wave-audit — 3-Wave Parallel Audit

## When to use

- Comprehensive code review: security, runtime analysis, quality, and Constructor Pattern in one 3-wave parallel workflow.
- Before merging a significant branch or shipping a milestone (95%+ finding coverage via cross-verification).
- After `/dev-guard` commit approvals when you need a deeper, cross-dependency audit sweep.

> Один аудитор находит 60%. Два параллельных — 80%. Три волны с перекрёстной проверкой — 95%+.
> Доказано экспериментом 2026-03-24: ни один подход в изоляции не покрыл все findings.

## Команды

- `/wave-audit` → полный review (3 волны, все фокусы)
- `/wave-audit review [focus]` → выборочный review
- `/wave-audit lite` → быстрый режим (2 агента Wave 1, без Wave 2, упрощённый Wave 3)
- `/wave-audit diff` → инкрементальный (только изменённые файлы + их зависимости)
- `/wave-audit apply` → применить фиксы в worktree (после approve)

`focus`: `security | runtime | quality | structure | all` (default: `all`)

---

## Anti-Hallucination Protocol

> AI галлюцинирует. Это не баг, это свойство. Skill ОБЯЗАН это компенсировать.

### Правило CODE_QUOTE
Каждый finding ОБЯЗАН содержать **дословную цитату кода** (3-7 строк), НЕ описание.

```
BAD:  "Функция не верифицирует JWT подпись"
GOOD: "apple.ts:72-74: `const decoded = jwt.decode(idToken, { complete: true });`
       — jwt.decode() НЕ верифицирует подпись, нужен jwt.verify()"
```

Если агент НЕ может процитировать код — finding отклоняется как unverified.

### Правило VERIFY_CMD
Каждый finding ОБЯЗАН содержать команду верификации — как подтвердить без чтения кода:

```
verify: grep -n "jwt.decode" apps/api/src/external/oauth/apple.ts
verify: wc -l apps/api/src/services/auth.service.ts  # expect >200
verify: grep -rn "new AuthService" apps/api/src/  # count instantiations
```

### Правило COVERAGE_LOG
Каждый агент Wave 1 ОБЯЗАН в конце отчёта указать:
```
FILES_READ: [список файлов которые реально открыл через Read tool]
FILES_TOTAL: [общее число source files]
COVERAGE: N% (read/total)
NOT_CHECKED: [список файлов/модулей которые НЕ проверял]
```

### Правило SEVERITY_CALIBRATION
Перед назначением severity, агент ОБЯЗАН ответить на вопрос:
- CRITICAL: "Можно ли эксплуатировать прямо сейчас без аутентификации?" Если нет → max HIGH.
- HIGH: "Приведёт ли это к потере данных или компрометации в production?" Если нет → max MEDIUM.
- MEDIUM: "Заметит ли это пользователь?" Если нет → LOW.

---

## Phase 0 — Baseline Snapshot

**Выполняет lead (не агент).** Обязательно ДО запуска Wave 1.

1. Проверить что это git-репозиторий
2. Определить реальный стек (НЕ из memory — читать package.json / pubspec.yaml / go.mod / Cargo.toml)
3. Снять baseline:
   - `git log --oneline -5` — последние коммиты
   - `git status --short` — текущее состояние
   - `git diff --stat` — незакоммиченные изменения
4. Определить и запустить CI-проверки стека:
   - **JS/TS:** `npm run lint`, `npm run build`, `npm test` (или turbo/nx аналоги)
   - **Flutter:** `flutter analyze`, `flutter test`
   - **Go:** `go vet ./...`, `go build ./...`, `go test ./...`
   - **Python:** `ruff check .`, `pytest`
   - **Rust:** `cargo clippy`, `cargo build`, `cargo test`
5. Зафиксировать baseline-метрики:
   ```
   BASELINE:
   - lint: PASS/FAIL (N warnings, M errors)
   - build: PASS/FAIL
   - tests: PASS/FAIL (N passed, M failed, K skipped)
   - stack: [detected stack]
   - files: [total source files count]
   ```

---

## Wave 1 — Discovery (4 параллельных агента)

**Создать TeamCreate**, запустить 4 агента **ОДНИМ сообщением** (параллельно).
Каждый агент работает независимо, НЕ знает о findings других.

### Agent: `w1-security`

```
Проведи security review проекта [path].
Стек: [из baseline]. НЕ применяй фиксы.

Phase 1 — Risk Classification:
- HIGH: auth, crypto, network, memory, deserialization, FFI
- MEDIUM: input validation, error handling, config, logging, API
- LOW: docs, tests, formatting

Phase 2 — Vulnerability Checklist:
- [ ] Input validation — все входные данные валидируются?
- [ ] Auth/authz bypass — можно обойти?
- [ ] Race condition — shared state без lock? TOCTOU?
- [ ] Injection — SQL, command, path traversal, SSTI?
- [ ] Secrets — hardcoded keys, tokens в логах?
- [ ] Deserialization — untrusted input в unmarshal/decode?
- [ ] Resource exhaustion — unbounded allocations, missing timeouts?
- [ ] Crypto — правильные алгоритмы? верификация подписей?

Phase 3 — Supply Chain:
Для КАЖДОЙ зависимости: maintainers, activity, CVE, transitive deps, dead deps.

Каждый finding ОБЯЗАН содержать:
1. severity (CRITICAL/HIGH/MEDIUM/LOW) — пройди SEVERITY_CALIBRATION
2. файл:строка
3. CODE_QUOTE (3-7 строк дословно)
4. attack scenario
5. VERIFY_CMD (команда для подтверждения)
6. [E1-E6] evidence grade

В конце — COVERAGE_LOG: какие файлы читал, какие нет.
Отдай как structured list.
```

### Agent: `w1-runtime`

```
Проведи runtime/performance review проекта [path].
Стек: [из baseline]. НЕ применяй фиксы.

Checklist:
- [ ] N+1 queries — ORM/DB calls в циклах или per-item resolvers
- [ ] Data joins — merge по индексу вместо ключа? silent corruption?
- [ ] Cache invalidation — JSON.parse теряет типы? stale data?
- [ ] Hot paths — какие функции на критическом пути?
- [ ] Allocations — per-request instantiation? можно singleton?
- [ ] I/O — sync operations на async path? blocking calls?
- [ ] Complexity — O(n²) или хуже в hot loops?
- [ ] Renders/rebuilds — лишние re-renders в UI? missing memo?
- [ ] Timeouts — есть ли на внешних API calls? unbounded waits?
- [ ] Connection pools — DB/Redis connections managed?

Каждый finding ОБЯЗАН содержать:
1. severity — пройди SEVERITY_CALIBRATION
2. файл:строка
3. CODE_QUOTE (3-7 строк дословно)
4. impact estimate (latency/memory/throughput)
5. VERIFY_CMD
6. [E1-E6] evidence grade

В конце — COVERAGE_LOG.
```

### Agent: `w1-quality`

```
Проведи quality review проекта [path].
Стек: [из baseline]. НЕ применяй фиксы.

Checklist:
- [ ] DRY — дублированный код? одинаковая логика в разных файлах?
- [ ] SRP — файл делает больше одного? mixed responsibilities?
- [ ] Naming — нечитаемые имена? inconsistent conventions?
- [ ] Dead code — unreachable branches? unused exports/imports?
- [ ] Edge cases — null/undefined handling? empty arrays? boundary values?
- [ ] Error handling — consistent pattern? fail open vs fail closed?
- [ ] Error messages — информативные? не leakают internal details?
- [ ] Type safety — any/unknown? missing generics? loose types?
- [ ] API boundaries — чёткие контракты между модулями?

Каждый finding ОБЯЗАН содержать:
1. severity — пройди SEVERITY_CALIBRATION
2. файл:строка
3. CODE_QUOTE (3-7 строк дословно)
4. impact
5. VERIFY_CMD
6. [E1-E6] evidence grade

В конце — COVERAGE_LOG.
```

### Agent: `w1-structure`

```
Проведи structural review проекта [path].
Стек: [из baseline]. НЕ применяй фиксы.

Constructor Pattern Checklist:
- [ ] Файлы >200 строк — перечисли ВСЕ с точным LOC
- [ ] Функции >30 строк — перечисли ВСЕ с точным LOC
- [ ] 1 файл = 1 класс = 1 ответственность — нарушения?
- [ ] Types/interfaces определены ДО реализации?
- [ ] SSOT — типы, enum, routes, configs дублируются?

CI/Pipeline Check:
- [ ] Все команды из CI (lint/build/test) проходят?
- [ ] Есть ли пустые stubs/packages ломающие pipeline?
- [ ] Lock-файлы актуальны?

Dependency Health:
- [ ] Unused dependencies (installed but never imported)
- [ ] Outdated deps (major version behind)
- [ ] Conflicting deps (multiple packages для одной задачи)

Каждый finding ОБЯЗАН содержать:
1. severity — пройди SEVERITY_CALIBRATION
2. файл:строка
3. CODE_QUOTE или точные числа (LOC count)
4. VERIFY_CMD (например: `wc -l file.ts`)
5. [E1-E6] evidence grade

В конце — COVERAGE_LOG.
```

### Сбор результатов Wave 1

Lead собирает findings от всех 4 агентов в единый список.
Формат: `W1-{agent}-{N}: [severity] description [evidence grade]`

---

## Wave 2 — Verification (4 параллельных агента)

**Запустить 4 агента ОДНИМ сообщением**, передав КАЖДОМУ полный список findings из Wave 1.

### Agent: `w2-false-positive-filter`

```
Получи ВСЕ findings из Wave 1: [список]
Проект: [path], стек: [стек].

Для КАЖДОГО finding:
1. Прочитай код по указанному файлу:строке
2. Это РЕАЛЬНАЯ проблема или false positive?
3. Если false positive — ПОЧЕМУ (например: "anon key публичный by design Supabase")
4. Если реальная — подтверди severity или скорректируй

Output:
- CONFIRMED: [finding ID] — [подтверждённый severity]
- DOWNGRADED: [finding ID] — [новый severity] — [причина]
- REJECTED: [finding ID] — [причина]
```

### Agent: `w2-gap-hunter`

```
Получи ВСЕ findings из Wave 1: [список]
Проект: [path], стек: [стек].

Задача: найти то, что Wave 1 ПРОПУСТИЛА.

1. Variant analysis: каждый найденный баг = КЛАСС. Проверь аналогичные места:
   - Exact: тот же код в другом файле
   - Structural: тот же паттерн в другом модуле
   - Semantic: та же логическая ошибка с другим синтаксисом

2. Пробелы в покрытии:
   - Какие файлы/модули Wave 1 не проверяла?
   - Есть ли critical paths без findings? (подозрительно — или чисто, или пропущено)

3. Cross-domain gaps:
   - Security нашёл auth issue — runtime проверил performance auth flow?
   - Runtime нашёл N+1 — quality проверил error handling в том же resolver?

Output: список ДОПОЛНИТЕЛЬНЫХ findings с severity + файл:строка + [E1-E6].
```

### Agent: `w2-fix-impact`

```
Получи ВСЕ findings из Wave 1: [список]
Проект: [path], стек: [стек].

Для каждого finding с предложенным фиксом:
1. Какие файлы затронет фикс? (blast radius)
2. Может ли фикс сломать существующий функционал?
3. Нужна ли миграция данных/токенов/состояния?
4. Зависит ли фикс от других фиксов? (порядок применения)
5. Estimated complexity: trivial / moderate / significant

Output:
- [finding ID]: blast_radius=[N files], breaks=[что может сломать], deps=[зависит от], complexity=[level]
```

### Agent: `w2-architecture-guard`

```
Получи ВСЕ findings из Wave 1: [список]
Проект: [path], стек: [стек].

Для каждого предложенного фикса проверь:
1. Не нарушает ли Constructor Pattern? (файл останется <200? функция <30?)
2. Не создаёт ли новое дублирование? (SSOT)
3. Не вводит ли запрещённые паттерны? (миксины, DI-контейнеры, абстрактные фабрики)
4. Сохраняет ли API boundaries между модулями?
5. Совместим ли с текущей архитектурой проекта?

Если фикс нарушает архитектуру — предложи АЛЬТЕРНАТИВНЫЙ фикс.

Output:
- [finding ID]: architecture_safe=YES/NO, conflict=[описание], alternative=[если NO]
```

### Сбор результатов Wave 2

Lead объединяет:
- Confirmed/rejected/downgraded findings
- New findings от gap-hunter
- Impact analysis
- Architecture conflicts

---

## Wave 3 — Cross-Optimization (1 синтезатор)

**Один агент** получает ВСЕ данные из Wave 1 + Wave 2.

### Agent: `w3-synthesizer`

```
Получи ВСЕ данные:
- Wave 1 findings: [список]
- Wave 2 verifications: [confirmed/rejected/downgraded]
- Wave 2 new findings: [от gap-hunter]
- Wave 2 impact analysis: [blast radius, deps]
- Wave 2 architecture conflicts: [список]
Проект: [path], стек: [стек], baseline: [метрики].

Задачи:

1. CROSS-DOMAIN ANALYSIS
   Найди пересечения: security fix ломает performance?
   Runtime optimization создаёт security hole?
   Два фикса трогают один файл — порядок?

2. OPTIMAL SOLUTIONS
   Для каждой группы связанных findings — найди ОДНО решение вместо N патчей.
   Пример: 3 HTTP клиента с дублированным error handling → один base client.
   Пример: N+1 + cache issue в одном resolver → DataLoader + cache fix вместе.

3. PRIORITY MATRIX
   Ранжируй ВСЕ confirmed findings по формуле:
   score = severity_weight × (1 / fix_complexity) × blast_radius_factor
   severity: CRITICAL=10, HIGH=7, MEDIUM=4, LOW=1
   complexity: trivial=1, moderate=0.5, significant=0.3
   blast_radius: 1-3 files=1.0, 4-10=0.8, 10+=0.5

4. EVIDENCE GRADES
   Каждый finding — [E1]-[E6] с обоснованием.

5. GO/NO-GO VERDICT
   - GO: нет CRITICAL, все HIGH имеют простой фикс
   - GO with constraints: есть CRITICAL но workaround возможен
   - NO-GO: CRITICAL без workaround, или >3 HIGH без фиксов

6. APPLY PLAN (если GO/GO with constraints)
   Порядок фиксов: low-risk → medium-risk → high-risk.
   Каждый фикс = отдельный checkpoint commit.
   После каждого — re-run baseline checks.
```

---

## Формат итогового отчёта

```
=== WAVE AUDIT REPORT ===
Project: [name] | Stack: [detected] | Date: [date]

## Baseline
| Check | Status | Details |
|-------|--------|---------|
| lint  | PASS/FAIL | N warnings, M errors |
| build | PASS/FAIL | ... |
| tests | PASS/FAIL | N passed, M failed |

## Wave 1 — Discovery
### Security (w1-security): N findings
### Runtime (w1-runtime): N findings
### Quality (w1-quality): N findings
### Structure (w1-structure): N findings
Total: N findings

## Wave 2 — Verification
### Confirmed: N | Rejected: N | Downgraded: N
### New findings (gap-hunter): N
### Architecture conflicts: N
### High-risk fixes: [list]

## Wave 3 — Optimized Results

### Priority Matrix
| # | Severity | Finding | Fix | Complexity | Blast | Score | [E] |
|---|----------|---------|-----|------------|-------|-------|-----|
| 1 | CRITICAL | ...     | ... | trivial    | 2     | 10.0  | E1  |

### Optimal Solutions (grouped)
- Group A: [related findings] → [one fix]
- Group B: [related findings] → [one fix]

### Cross-Domain Conflicts
- [conflict description + resolution]

## Verdict: GO / GO with constraints / NO-GO
Reason: [explanation]

## Apply Plan
1. checkpoint: before wave-audit fixes
2. [fix #1] — [files] — low risk
3. [fix #2] — [files] — low risk
...
N. re-run baseline → compare with pre-audit
```

---

## Apply Phase (только после approve)

1. `checkpoint:` commit перед началом
2. Создать worktree: `git worktree add .claude/worktrees/wave-audit-fix`
3. Применять фиксы в порядке из apply plan (low-risk → high-risk)
4. Каждый фикс = отдельный commit
5. Re-run baseline checks в worktree
6. Strict mode: если хуже baseline по любому критерию → STOP
7. Hand-off: показать diff, результаты, остаточные риски

---

## Safety Constraints

Запрещено:
- Исправлять что-либо до завершения ВСЕХ 3 волн
- Пропускать Wave 2 ("Wave 1 всё нашла")
- Пропускать Wave 3 ("нет конфликтов") — Wave 3 ВСЕГДА
- `git reset --hard`, удаление файлов/веток без approve
- Менять секреты (`.env`, ключи, токены)
- Объединять findings без маркировки источника (W1/W2/W3)

---

## Стандартный формат Finding (обязателен для ВСЕХ агентов)

> Единый формат предотвращает потерю данных между волнами и упрощает дедупликацию.

```
ID: W{wave}-{agent}-{N}
SEVERITY: CRITICAL|HIGH|MEDIUM|LOW
CALIBRATION: [ответ на вопрос из SEVERITY_CALIBRATION]
FILE: path/to/file.ts:42-48
CODE_QUOTE: |
  const decoded = jwt.decode(idToken, { complete: true });
  // no jwt.verify() call — signature not checked
PROBLEM: [1-2 предложения]
IMPACT: [что произойдёт если не починить]
FIX: [конкретное изменение]
VERIFY_CMD: grep -n "jwt.decode" apps/api/src/external/oauth/apple.ts
EVIDENCE: [E1-E6]
```

Findings БЕЗ CODE_QUOTE или VERIFY_CMD → автоматически помечаются `[UNVERIFIED]` и понижаются на 1 severity.

---

## Deduplication Protocol

> 4 параллельных агента Wave 1 НЕИЗБЕЖНО найдут одно и то же. Без дедупликации — отчёт раздут на 30-40%.

### Lead между Wave 1 и Wave 2:
1. Собрать все findings в единый список
2. Группировать по `FILE` — findings на один и тот же файл:строку = кандидаты на дупликат
3. Для каждой группы:
   - Одинаковая проблема → оставить finding с лучшим CODE_QUOTE, удалить дубли, пометить `[DEDUP: merged W1-security-3 + W1-quality-7]`
   - Разные проблемы на одном файле → оставить оба
4. Пометить каждый finding источником: `SOURCE: w1-security`

### Ожидаемый dedup rate: 15-25%

---

## Lite Mode (`/wave-audit lite`)

> 9 агентов = дорого. Для малых проектов (<30 файлов) или быстрых проверок:

- Wave 1: **2 агента** (security+runtime merged, quality+structure merged)
- Wave 2: **пропуск** (lead делает quick false-positive check сам)
- Wave 3: **упрощённый** — priority list + Go/No-Go, без cross-domain analysis

Ожидаемое покрытие: ~75% от full mode. Стоимость: ~30% от full mode.

---

## Diff Mode (`/wave-audit diff`)

> Изменил 5 файлов — зачем аудитить все 90?

1. `git diff --name-only HEAD~N` → список изменённых файлов
2. Для каждого изменённого файла → найти зависимости (importers, tests)
3. Scope Wave 1 агентов ТОЛЬКО на: changed files + их прямые зависимости
4. Wave 2 gap-hunter дополнительно проверяет: не пропущены ли transitive dependencies

Ожидаемое покрытие: ~90% для changed code. Стоимость: ~40% от full mode.

---

## Lead Automation Protocol

> Lead = bottleneck. Между волнами lead вручную собирает, форматирует, дедуплицирует, передаёт. Минимизируем ручную работу.

### Между Wave 1 → Wave 2:
1. Собрать messages от 4 агентов (автоматически через team inbox)
2. Дедупликация по FILE (см. протокол выше)
3. Подсчитать coverage: объединить COVERAGE_LOG всех агентов
4. Если суммарный coverage <50% — **WARN пользователю**: "Агенты покрыли только N% файлов"
5. Сформировать единый список → передать в промпты Wave 2

### Между Wave 2 → Wave 3:
1. Собрать verifications от 4 агентов
2. Применить решения w2-false-positive-filter (удалить REJECTED)
3. Добавить new findings от w2-gap-hunter
4. Сформировать полный пакет → передать w3-synthesizer

### Если агент не ответил за 10 минут:
- Продолжить без него, пометить `[AGENT_TIMEOUT: w1-runtime]`
- В финальном отчёте указать неполное покрытие

---

## Wave 2 Context Overflow Protection

> Если Wave 1 выдала 30+ findings, Wave 2 агенты теряют фокус на последних.

### Правило: MAX 20 findings per Wave 2 agent
- Если findings >20: разбить на 2 batch по приоритету
- Batch 1 (HIGH+CRITICAL) → Wave 2 агентам
- Batch 2 (MEDIUM+LOW) → Wave 2 агентам вторым проходом ИЛИ lead проверяет сам
- В отчёте пометить: `BATCH_2_REVIEWED_BY: lead` (менее глубокая проверка)

---

## Метрика эффективности

После каждого запуска записать в отчёт:
```
AUDIT METRICS:
- Wave 1 findings: N (raw, before dedup)
- Wave 1 deduplicated: N (after dedup, -N%)
- Wave 1 coverage: N% (union of all agents' COVERAGE_LOGs)
- Wave 1 unverified: N (findings without CODE_QUOTE)
- Wave 2 rejected: N (false positive rate: N%)
- Wave 2 new findings: N (gap rate: N%)
- Wave 2 architecture conflicts: N
- Wave 3 groups: N (optimization rate: N%)
- Total agents: 9 (4+4+1) | lite: 3 (2+0+1)
- Total confirmed: N
- Agent timeouts: N
- Mode: full | lite | diff
```