# Протокол 02b: Red Team Review (опционально)

## Цель

Преднамеренно попытаться разрушить спроектированную архитектуру, чтобы найти скрытые проблемы до начала реализации.

## Вход

- `.agent/design-report.md`
- `.agent/layer-1/adr/*.md` (если созданы)
- `.agent/metaagent-request.md` (глубина проработки >= 9)

## Когда выполняется

Только если `config.red_team = yes` (глубина 9-10). Выполняется **после** DESIGN, **до** DECOMPOSITION.

## Шаги

### RT1. Поиск скрытых зависимостей

Проверить каждый модуль на наличие неявных связей:

- Есть ли циклические зависимости между модулями?
- Есть ли модуль, который знает слишком много о других?
- Есть ли скрытый vendor lock-in (БД, облачный провайдер, внешний API)?

### RT2. Точки отказа

Для каждого внешнего интерфейса (API, БД, файловая система):

- Что произойдёт при отказе компонента?
- Есть ли fallback?
- Что произойдёт при невалидных входных данных?

### RT3. Масштабирование

Оценить поведение системы при:

- 10x рост данных
- 100x рост данных
- Добавлении нового пользователя / клиента

### RT4. Security (если применимо)

- Какие данные передаются по сети?
- Есть ли аутентификация?
- Хранятся ли секреты в коде?

### RT5. Consistency

Проверить design-report и ADR на противоречия:

- Одна сущность описана по-разному в двух местах?
- API-контракт не соответствует модели данных?
- Технологический стек противоречит нефункциональным требованиям?

## Выход

`.agent/layer-1/red-team-report.md` с секциями:

```
## Найденные проблемы

| # | Проблема | Серьёзность | Рекомендация |
|---|---|---|---|

## Отклонённые атаки (что пытались сломать — но не сломалось)

| # | Гипотеза | Почему не подтвердилась |
|---|---|---|
```

Обновить risk-register.md (если существует) новыми рисками.

## Критерии завершения

- [ ] Все 5 секций (RT1-RT5) проверены
- [ ] Найденные проблемы записаны в red-team-report.md
- [ ] Если найдены критические проблемы — design-report должен быть исправлен
- [ ] Risk Register дополнен (если существует)