a4e667de10
Single-commit clean baseline after security scrub of niche-tells, project codenames, internal jargon, and contributor-email leaks. Contents: - 100 Rust crates (_primitives/_rust/) - 37 agent manifests (_manifests/) + generated specs (_generated/) - 67 user-invocable skills (skills/) - 33 hooks (hooks/) - Composition blocks (_blocks/) - Documentation (docs/, README.md) - TS adapter packages (_ts_packages/) - Assembler (_assembler/) - Roles (_roles/) - Templates (_templates/) - Forgejo CI (.forgejo/) Author: Denis Parfionovich <info@greendragon.info> License: see LICENSE.
565 lines
24 KiB
Markdown
565 lines
24 KiB
Markdown
---
|
||
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
|
||
|
||
> Один аудитор находит 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
|
||
```
|