╔═══════════════════════════════════════════════════════════════════════════╗
║                                                                           ║
║             ██████╗  █████╗ ██████╗ ████████╗ ██████╗ ██████╗             ║
║             ██╔══██╗██╔══██╗██╔══██╗╚══██╔══╝██╔═══██╗██╔══██╗            ║
║             ██████╔╝███████║██████╔╝   ██║   ██║   ██║██████╔╝            ║
║             ██╔══██╗██╔══██║██╔═══╝    ██║   ██║   ██║██╔══██╗            ║
║             ██║  ██║██║  ██║██║        ██║   ╚██████╔╝██║  ██║            ║
║             ╚═╝  ╚═╝╚═╝  ╚═╝╚═╝        ╚═╝    ╚═════╝ ╚═╝  ╚═╝            ║
║                                                                           ║
║             Autonomous Offensive/Defensive Research Framework             ║
║             Based on Claude Code (v3.1.0)                                 ║
║                                                                           ║
║             Gadi Evron, Daniel Cuthbert, Thomas Dullien (Halvar Flake)    ║
║             Michael Bargury, John Cartwright                              ║
║                                                                           ║
╚═══════════════════════════════════════════════════════════════════════════╝

⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣤⣤⣀⣀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣾⣿⣿⠿⠿⠟
⠀⠀⠀⠀⠀⠀⠀⠀⢀⣀⣀⣀⣀⣀⣀⣤⣴⣶⣶⣶⣤⣿⡿⠁⠀⠀⠀
⣀⠤⠴⠒⠒⠛⠛⠛⠛⠛⠿⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠟⠁⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠛⣿⣿⣿⡟⠻⢿⡀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣾⢿⣿⠟⠀⠸⣊⡽⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⡇⣿⡁⠀⠀⠀⠉⠁⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠻⠿⣿⣧⠀ Get them bugs.....⠀⠀⠀⠀⠀

Запуск через лаунчер `raptor` — рекомендуемый способ начать сессию, и он работает из любого каталога: он определяет установку RAPTOR, запоминает каталог, из которого вы запустили команду (поэтому такие команды, как `/scan`, по умолчанию используют его), выполняет предварительные проверки доверия и проекта, загружает плагин отслеживания покрытия и очищает окружение перед передачей управления Claude Code. Он также принимает необязательный путь к цели и флаги, такие как `--project`, `--continue` и `--model` — см. `raptor --help`.

Запуск обычного `claude` из каталога репозитория также работает — Claude Code подхватывает конфигурацию RAPTOR из клона — но вы пропускаете всё, что делает лаунчер, описанный выше: никаких предварительных проверок, никакого отслеживания покрытия, и команды, которые по умолчанию используют «каталог, из которого вы запустили команду», не смогут его увидеть.

**Важно:** RAPTOR загружает свою конфигурацию из каталога репозитория. Если вы запустите `claude` из любого другого каталога, вы получите обычный Claude Code, а не RAPTOR. Лаунчер `raptor` полностью исключает этот сценарий отказа.

### Вариант 2: Запуск в контейнере (рекомендуется)

Использование контейнеров — распространённая практика безопасности, позволяющая ограничить доступ агентов к областям вашей файловой системы, к которым вы не хотите их допускать, а также уменьшить радиус поражения любого вредоносного кода, который может выполниться (например, в результате атаки через цепочку поставок). Образ большой (около 6 ГБ). Он основан на devcontainer Microsoft Python 3.12 и дополнен инструментарием для статического анализа, фаззинга и автоматизации браузера.

Вы можете загрузить готовый образ:```bash
docker pull danielcuthbert/raptor:latest

Образ ожидает, что фреймворк RAPTOR (этот репозиторий) будет смонтирован в `/workspaces/raptor` при запуске. При желании вы можете смонтировать целевую папку для локального анализа.

Чтобы запустить контейнер:```bash
docker run -it \
  -v "$(pwd):/workspaces/raptor" \
  raptor:latest

Добавьте `--privileged`, если вам нужен детерминированный отладчик `rr`.

Контейнеры разработки VS Code также поддерживаются. Чтобы смонтировать целевую папку, добавьте её в раздел `mounts` файла `.devcontainer/devcontainer.json`:```jsonc
"mounts": [
  // ...existing entries...
  "source=/path/to/target-folder,target=/workspaces/target,type=bind,consistency=cached"
]

В любом случае, как только вы окажетесь внутри контейнера, запустите `raptor`, чтобы начать работу.

---

## Чего ожидать при первом запуске

Самое простое, что вы можете сделать:```
/scan /path/to/code

Это запускает полный конвейер: сканирование, дедупликация, затем отправка каждой находки через этапы валидации (A-F). Для кодовой базы среднего размера с ~50 находками ожидайте 10-30 минут и $2-8 затрат на LLM на уровне анализа (в зависимости от модели). Лимит стоимости по умолчанию — $10 за запуск; настройте с помощью `--max-cost-usd`.

**Примечание о стоимости:** Оркестрационный слой Claude Code использует вашу подписку Claude. Слой диспетчеризации анализа выполняет отдельные вызовы LLM API, которые тарифицируются за токен. Если вы используете только Claude Code в качестве модели анализа (по умолчанию), дополнительных затрат сверх подписки нет. Если вы настраиваете внешние модели (OpenAI, Gemini и т. д.), эти вызовы API оплачиваются соответствующим провайдерам.

---

## Модель безопасности

RAPTOR запускает код, сгенерированный LLM, и анализирует недоверенные репозитории. Подпроцессы, обрабатывающие недоверенный контент, изолируются с помощью пространств имён Linux, Landlock и seccomp. Песочница блокирует сетевой доступ, ограничивает видимость файловой системы и лимитирует потребление ресурсов. См. `docs/sandbox.md` для полной модели угроз и конфигурации.

Переменные окружения, которые могут внедрить код в цепочку запуска, удаляются при старте (`core/security/_dangerous_env_strip.sh`). Пути к файлам из сканируемых репозиториев никогда не интерполируются в строки shell — все вызовы подпроцессов используют аргументы на основе списков.

---

## Что умеет RAPTOR

| Команда | Что делает | Статус |
|---------|-------------|--------|
| `/agentic` | Полный автономный рабочий процесс: сканирование, валидация, эксплуатация, патчинг | Стабильный |
| `/scan` | Статический анализ с помощью Semgrep и CodeQL | Стабильный |
| `/understand` | Картирование поверхности атаки, трассировка потоков данных, поиск вариантов уязвимостей | Стабильный |
| `/binary` | Чёрный ящик для исследования бинарных файлов, среда выполнения, графовые запросы и передача результатов | Бета |
| `/ghidra` | Мост RE через Ghidra: подключение/импорт проектов `.gpr`, сравнение версий, экспорт находок | Бета |
| `/audit` | Систематический обзор кода на основе гипотез с опорой на инструменты | Бета |
| `/review` | Запрос состояния аудита: находки, пробелы, покрытие, заметки оператора | Стабильный |
| `/annotate` | Прикрепление свободных построчных аннотаций к функциям (заметки оператора при ревью) | Стабильный |
| `/validate` | Многоэтапный конвейер валидации эксплуатируемости (этапы 0-F) | Стабильный |
| `/diagram` | Визуальные карты Mermaid из JSON-выводов `/understand` и `/validate` | Бета |
| `/codeql` | Глубокий анализ только через CodeQL с предварительным отбором потоков данных через SMT | Стабильный |
| `/analyze` | Анализ существующих находок SARIF с помощью LLM без повторного сканирования | Стабильный |
| `/sca` | Анализ состава ПО: зависимости, бюллетени, сигналы цепочки поставок, SBOM и исправления | Бета |
| `/cve-diff` | Поиск и сравнение коммита-исправления для CVE в OSV, NVD, GitHub и GitLab | Бета |
| `/cve-env` | Сборка и проверка Docker-окружения, запускающего уязвимое приложение CVE в версии до патча | Экспериментальный |
| `/exploit` | Генерация кода эксплойта для подтверждения концепции | Бета |
| `/patch` | Генерация безопасных патчей для подтверждённых уязвимостей | Бета |
| `/fuzz` | Фаззинг бинарных файлов с AFL++ и анализ сбоев | Стабильный |
| `/crash-analysis` | Автономный анализ первопричины сбоев C/C++ | Стабильный |
| `/oss-forensics` | Криминалистическое расследование репозиториев GitHub на основе доказательств | Стабильный |
| `/project` | Именованные рабочие пространства для организации запусков и отслеживания находок с течением времени | Стабильный |
| `/describe` | Описание цели: языковой состав, система сборки, пробелы в инструментах, оценка стоимости (только чтение) | Стабильный |
| `/threat-model` | Создание, просмотр и поддержка моделей угроз для каждого проекта | Стабильный |
| `/sage` | Постоянный слой памяти (хранение, извлечение, связывание, подтверждение) | Стабильный |
| `/ask` | Отправка произвольного запроса любой настроенной модели LLM | Стабильный |
| `/scorecard` | Проверка надёжности каждой модели по классам решений | Стабильный |
| `/frida` | Динамическая инструментация через Frida | Альфа |
| `/web` | Сканирование веб-приложений: обход, интеграция ffuf/nuclei, проверенные оракулом инъекции, обратные вызовы слепого SSRF | Бета |

---

## Как работает конвейер

Начните с создания проекта, чтобы все ваши запуски попадали в одно место:```
/project create myapp --target /path/to/code   # create a project first
/project use myapp                             # set it as active
/understand --map                              # map the attack surface
/agentic --threat-model --validate             # map, model, scan, validate
/project findings                              # review everything in one place

`/understand` строит карту контекста из точек входа, границ доверия и стоков ещё до того, как начнётся сканирование. Затем `/agentic` запускает Semgrep и CodeQL, дедуплицирует находки и отправляет каждую на валидацию по методологии exploitation-validator:

С `--threat-model` RAPTOR сначала запускает карту, создаёт `threat-model.json` и `THREAT_MODEL.md`, если их ещё нет в проекте, а затем передаёт компактную версию в `/understand`, автономный анализ и `/validate`. Существующие модели угроз проекта сохраняются, если только вы не передадите `--threat-model-refresh`; устаревшие запасные карты отклоняются, если только вы явно не передадите `--threat-model-use-stale`. Он также превращает отмеченные непроверенные потоки в кандидатные SARIF, чтобы пропуски сканера не останавливали запуск. Это контекст, которым владеет оператор, а не магическое доказательство: находки всё равно требуют подтверждения кодом или подтверждения через оракул. См. `docs/threat-model.md`.

- Этап A: действительно ли паттерн является уязвимостью, или это шум от сопоставления паттернов инструмента?
- Этап B: что нужно атакующему, чтобы достичь её, и что стоит на пути?
- Этап C: действительно ли путь кода существует? можно ли до него добраться извне?
- Этап D: финальное решение — это тестовый код, требуются ли нереалистичные предусловия, не уклоняется ли модель?
- Этап E: осуществимость эксплуатации бинарного файла (когда доступен скомпилированный артефакт)
- Этап F: саморецензия — уклонялся ли или противоречил ли себе какой-либо более ранний этап?

Находки, прошедшие валидацию, получают сгенерированные PoC-эксплойты и патчи. В конце запускается кросс-анализ находок для поиска общих корневых причин и цепочек атак.

`/validate` запускает этот же конвейер как отдельный шаг, если у вас уже есть находки из предыдущего сканирования.

Для скомпилированного артефакта `/binary <path>` теперь запускает расследование, ориентированное на доказательства, а не вываливает кучу сырых артефактов реверс-инжиниринга на оператора. Под капотом он по-прежнему строит манифест, привязанный к SHA-256, реестр доказательств, карту контекста, чек-лист и SQLite-граф из метаданных файла, импортов и xref-ссылок radare2. Для Mach-O-приложений также выполняется инвентаризация срезов, метаданные бандла и селекторы классов Objective-C / Swift; псевдокод высокой ценности сохраняется, а не исчезает внутри запуска. Экспорты PE DLL, диспетчеры Windows-драйверов и обработчики ioctl модулей ядра Linux также обрабатываются как собственные кандидаты входа, при этом архитектура PE считывается из заголовка COFF, а не угадывается. Затем слой расследования запрашивает этот граф, ранжирует внешние входы перед общими подсказками стоков, обнаруживает объявленные вспомогательные/родственные бинарники и пишет компактный отчёт, разделённый на факты, структурные выводы и неподтверждённые гипотезы. Наблюдения Frida, свидетели крашей фаззинга, явные проверки Z3 и бинарные диффы могут позже добавить более сильные доказательства. RAPTOR также сохраняет внутренний граф вызовов, необходимый для восстановления ограниченных кандидатов «вход → парсер», чтобы колбэк приложения можно было сузить до внутренней функции, которая на самом деле вызывает `XML_Parse`, `d2i_X509`, `jpeg_read_header` или другую реальную поверхность парсера, не притворяясь, что это доказательство потока данных. `/binary trace-parser <run-dir>` — это явное динамическое продолжение: он запускает узкий трассировщик парсера Frida, а затем обновляет ту же карту контекста, передачу, граф и отчёт расследования на месте. `/binary investigate --active` сначала строит карту и запускает реальную кампанию фаззинга только тогда, когда существует конкретная граница харнесса; для целей app, DLL и драйвера вместо этого выполняется шаг харнесса или снапшота. `/binary harness` пишет спецификацию харнесса на основе доказательств для выбранного входа и выдаёт исходный код-кандидат только тогда, когда ABI или контракт IOCTL явны. Он не пробивает себе путь от «`memcpy` существует» до «это эксплуатируемо»: импорты, селекторы и рёбра вызовов остаются кандидатами, пока что-то механическое не докажет больше. См. `docs/binary-analysis.md`.

---

## Анализ состава программного обеспечения

`/sca` анализирует сторону зависимостей и цепочки поставок проекта. Это не просто поиск CVE по файлам требований: RAPTOR обнаруживает манифесты, lock-файлы, встроенные команды установки, зависимости рабочих процессов и источники пакетов контейнеров/базовых образов, а затем нормализует их в единое представление зависимостей.

Сканирование обогащает зависимости данными OSV-предупреждений, CISA KEV, EPSS, CISA Vulnrichment/SSVC, достижимости, сигналами доказательств эксплуатации, проверками гигиены, эвристиками цепочки поставок, выводами по лицензионной политике и необязательным LLM-обзором/триажем. Он выдаёт находки в родном формате RAPTOR, а также SBOM и вывод, удобный для CI:

- `findings.json` — канонические находки RAPTOR
- `report.md` — читаемое человеком резюме
- `sbom.cdx.json` — SBOM CycloneDX с данными VEX
- `findings.sarif` — вывод для сканирования кода GitHub/GitLab

Часто используемые команды:```bash
python3 raptor.py sca --repo /path/to/project
python3 raptor.py sca --repo /path/to/project --no-llm
python3 raptor.py sca --repo /path/to/project --fail-on-severity high --fail-on-kev
python3 raptor.py sca --repo /path/to/project fix
python3 raptor.py sca check PyPI django 4.2.10

После заполнения сканер сопоставляет идентификаторы пакетов с локальными файлами, и сетевых вызовов не происходит. Без кэша RAPTOR попытается получить пакеты реестра с semgrep.dev во время сканирования; если соединение отсутствует, он корректно отбрасывает некэшированные пакеты и запускается только с пользовательскими правилами.

CodeQL требует сетевого доступа только во время первоначальной настройки для загрузки CLI и пакетов запросов. После установки он работает офлайн.

---

## Пользовательские правила

RAPTOR включает более 200 пользовательских правил статического анализа, прошедших adversarial-тестирование для устранения ложных срабатываний:

- **Semgrep (145 правил)** — правила отслеживания потоков данных (taint) и шаблонов для Python, Go, Java и JS/TS. Покрывают SQLi, XSS, SSRF, SSTI, внедрение команд, десериализацию, XXE, LDAP/NoSQL-инъекции, обход пути, открытые редиректы, внедрение в логи/заголовки, eval-инъекции, ReDoS, загрязнение прототипов, неверную настройку JWT, слабую криптографию, небезопасный TLS и захардкоженные секреты.
- **Coccinelle (63 правила)** — структурное сопоставление для C/C++. Безопасность памяти (двойное освобождение, use-after-free, освобождение небазового указателя, освобождение стекового массива, mmap-памяти, use-after-close), целочисленные ошибки (переполнение, расширение знака, двойной sizeof), утечки ресурсов (несоответствие popen/fclose, двойное закрытие fdopendir), обработка буферов (strncpy без NUL, несоответствие размера copy_user, off-by-one в malloc/strlen), безопасность обработчиков сигналов, неправильное использование API (домен флагов fcntl, SIGKILL/SIGSTOP, двойная перестановка байтов, статический буфер inet_ntoa), устранение мёртвых хранилищ компилятором, путаница IS_ERR/PTR_ERR в ядре, внедрение строк формата, гонки TOCTOU и другое.
- **CodeQL (8 запросов)** — межпроцедурное отслеживание потоков данных для C++ (внедрение строк формата, усечение целых чисел, use-after-move, инвалидация итераторов) и Java (XXE, небезопасная десериализация, внедрение в логи, Spring SSRF).

Просматривайте правила напрямую: `engine/semgrep/rules/`, `engine/coccinelle/rules/`, `engine/codeql/queries/`. Они дополняют пакеты реестра Semgrep, которые подтягивает RAPTOR (`p/security-audit`, `p/owasp-top-ten`, `p/secrets` всегда; пакеты по группам политик, такие как `p/command-injection`, `p/jwt`, `p/xss`, дополнительно) — пересечение минимально.

---

## Как RAPTOR проверяет себя

RAPTOR в значительной степени использует собственные средства безопасности, но стоит честно сказать, что действительно блокирует PR, а что просто работает в фоне, чтобы держать нас в тонусе. Часть этого — жёсткий шлюз, часть — плановая проверка, а часть — просто бенчмарк, который мы храним, чтобы понимать, когда что-то стало хуже. Более подробная разбивка, включая фактические параметры и способы воспроизведения проверок, приведена в `docs/ci-controls.md`.

| Контроль | Что проверяет | Триггер | Конфигурация / доказательства |
|---|---|---|---|
| Ruff | Линтинг корректности Python (`F401`, `F811`, `F821`, `F841`) | Шлюз по диффам PR, плюс еженедельный аудит всего дерева | `pyproject.toml`, `.github/workflows/lint.yml` |
| Pytest | Быстрые границы модульных/интеграционных тестов, уровни по подсистемам (через диспетчеризацию по графу импортов), аудит оболочки промптов | PR, пуши в `main`, очередь слияния, плановый полный набор | `pytest.ini`, `.github/workflows/tests.yml`, `.github/workflows/nightly.yml` |
| CodeQL Advanced | Сканирование кода Python, C/C++ и GitHub Actions с сужением области по графу импортов | PR, пуши в `main`, очередь слияния, еженедельное расписание | `.github/workflows/codeql.yml`, `.github/codeql/codeql-config.yml` |
| Усиление рабочих процессов | SHA-закреплённые сторонние Actions, разрешения с минимальными привилегиями, линтинг метаданных команд | Каждое изменение рабочего процесса и каждый запуск линта | `.github/workflows/`, `.github/scripts/check_command_metadata.py` |
| Линт меток корпуса | Проверка схемы меток корпуса аудита и проверка вышестоящих закреплений | PR (изменённые метки), еженедельная полная проверка | `.github/workflows/corpus-labels.yml` |
| Шлюз PR SCA RAPTOR | Регрессии зависимостей и цепочки поставок, внесённые PR | Изменения манифеста / lock-файла / рабочего процесса | `.github/workflows/sca-pr-gate.yml` |
| Самообновление SCA RAPTOR | Механическое усиление зависимостей и предложения безопасных обновлений | Еженедельное расписание, ручной запуск | `.github/workflows/sca-self-bump.yml` |
| Корпус компрометации SCA | Срабатывают ли известные компрометации зависимостей на ожидаемый сигнал | Еженедельное расписание, соответствующие изменения PR | `test/data/sca-e2e/compromise-corpus/`, `.github/workflows/sca-compromise-check.yml` |
| Сканирование неправильных подключений | Обнаружение мёртвого кода / неверных вызовов, расхождение документации переменных окружения, защитные ограничения списка словаря, линт необязательных импортов зависимостей | Ежедневное расписание | `.github/workflows/miswiring-scan.yml`, `.github/scripts/*_baseline.json` |
| Калибровка SCA + стресс-корпус | Дрейфуют ли оценка рисков и покрытие парсера со временем | Еженедельные / ежемесячные плановые задания | `packages/sca/data/calibration/`, `.github/workflows/refresh-sca-calibration.yml`, `.github/workflows/sca-stress-sweep.yml` |
| Корпус потоков данных | Отслеживание точности / полноты / категорий ложных срабатываний для поведения валидатора | Бенчмарк для разработчиков и тесты корпуса | `core/dataflow/corpus/`, `core/dataflow/scripts/corpus-metrics` |
| Защита документа CI-контролей | Существование документированных путей, соответствие конфигурации ruff, ссылки README на документ | PR | `.github/tests/test_ci_controls_docs.py` |

В настоящее время не применяется: `mypy` установлен в `requirements-dev.txt`, но ничего не блокирует; форматирование Ruff не применяется; Semgrep является частью поверхности сканера RAPTOR, но у нас пока нет выделенного рабочего процесса «сканировать RAPTOR с помощью RAPTOR» на Semgrep.

---

## Использование другой LLM

У RAPTOR два отдельных слоя моделей, и стоит понять, как работают оба, прежде чем что-либо менять.

**Слой оркестрации** — это всегда Claude Code. CLAUDE.md, навыки и команды выполняются как инструкции Claude Code. Чтобы изменить модель Claude, которая оркестрирует RAPTOR, используйте флаг `--model` Claude Code или команду `/model` внутри сессии.

**Слой диспетчеризации анализа** — это LLM, которая анализирует отдельные находки уязвимостей. Он отделён от слоя оркестрации и может быть любым поддерживаемым провайдером. Настройте его в `~/.config/raptor/models.json`:```json
{
  "models": [
    {
      "provider": "anthropic",
      "model": "claude-opus-4-6",
      "api_key": "sk-ant-...",
      "role": "analysis"
    },
    {
      "provider": "openai",
      "model": "gpt-5.4",
      "api_key": "sk-...",
      "role": "analysis"
    },
    {
      "provider": "anthropic",
      "model": "claude-sonnet-4-6",
      "api_key": "sk-ant-...",
      "role": "aggregate"
    }
  ]
}

| Роль | Что она делает |
|------|-------------|
| `analysis` | Проверяет и анализирует каждую находку (этапы A-F) |
| `code` | Пишет эксплойт-PoC и код патчей |
| `consensus` | Голосование «второго мнения» по истинно положительным результатам |
| `aggregate` | Необязательно. Нарративный синтез, написанный LLM, поверх детерминированной многомодельной корреляции, сохраняется в `aggregation.json` и итоговый `agentic-report.md` |
| `fallback` | Используется, если основная модель выходит из строя или достигает лимитов запросов |

Если роли не заданы, первая модель в списке обрабатывает всё. Для многомодельного
анализа исходного кода настройте две или более модели `analysis` — по умолчанию вы
получите детерминированную корреляцию. Роль `aggregate` необязательна и добавляет
сводку, написанную LLM, поверх:```bash
python3 raptor.py agentic --repo /code \
  --model claude-opus-4-6 \
  --model gpt-5.4 \
  --aggregate claude-sonnet-4-6

Ollama подходит для анализа, но генерирует ненадёжный код эксплойтов и патчей. Для задач генерации кода используйте модель frontier-класса.

### Быстрый уровень с коротким замыканием + карточка оценок моделей

Когда у вашей модели уровня анализа есть более дешёвый аналог от того же провайдера (Anthropic Opus → Haiku, OpenAI 5.x → 4o-mini, Gemini Pro → Flash-Lite, Mistral Large → Small), RAPTOR будет использовать его как предварительный фильтр для потребителей, подключённых к субстрату (сегодня codeql; SCA и другие — по мере появления последующих обновлений). Дешёвая модель всегда срабатывает с коротким замыканием только на **уверенных ложных срабатываниях**; неоднозначные случаи и уверенные истинные срабатывания всегда проходят полный анализ. Доверие накапливается по каждой ячейке `(model, decision_class)` — RAPTOR записывает согласие между дешёвой и полной проверкой и выполняет короткое замыкание только после того, как верхняя граница Уилсона с доверительным интервалом 95% для частоты пропусков ячейки опускается до 5% или ниже.

Чтобы посмотреть, в чём хороши ваши модели, используйте `/scorecard` (или напрямую: `libexec/raptor-llm-scorecard list`). Карточка оценок глобальна (уроки переносятся между проектами) и сохраняется в `out/llm_scorecard.json`.

---

## Проекты

Без проекта каждый запуск получает собственную директорию с отметкой времени в `out/`. С проектом всё попадает в одно место, и вы получаете объединённые результаты, отслеживание покрытия и различия между запусками.```bash
/project create myapp --target /path/to/code -d "Short description"
/project use myapp

/scan
/understand --map
/validate

/project status                # all runs, pass/fail, timestamps
/project findings              # merged findings across all runs
/project findings --detailed   # per-finding detail
/project coverage --detailed   # which files were reviewed
/project diff myapp run1 run2  # compare two runs
/project report                # full merged report
/project clean --keep 3        # remove old runs, keep the last 3
/project export myapp /tmp/myapp.zip
/project none                  # clear active project

Разделение означает, что вы можете запускать Python-слой из конвейера CI (`python3 raptor.py scan --repo ...`) и получать структурированный вывод SARIF без Claude Code, либо запускать его в интерактивном режиме с полным агентным рабочим процессом.

---

## OSS-криминалистика

`/oss-forensics` исследует публичные репозитории GitHub, используя данные из нескольких источников: GitHub API, GH Archive (неизменяемая история событий через BigQuery), Wayback Machine и локальную историю git. Он выполняет структурированный конвейер от сбора доказательств через формирование гипотез до итогового криминалистического отчёта.

Требуется `GOOGLE_APPLICATION_CREDENTIALS` для доступа к BigQuery. Подробности см. в `.claude/commands/oss-forensics.md`.

---

## Экспертные роли

Доступны семь экспертных ролей по запросу. Загрузите одну из них, когда хотите получить иной взгляд на находку или конкретную технику:```
Exploit Developer (Mark Dowd)                  Exploit PoC generation
Crash Analyst (Charlie Miller / Halvar Flake)  Crash analysis and exploitability assessment
Security Researcher                            General adversarial code review
Patch Engineer                                 Secure fix generation
Penetration Tester                             Realistic attack scenario assessment
Fuzzing Strategist                             Corpus design and triage
Binary Exploitation Specialist                 ROP, heap, and memory corruption