╔═══════════════════════════════════════════════════════════════════════════╗
║                                                                           ║
║             ██████╗  █████╗ ██████╗ ████████╗ ██████╗ ██████╗             ║
║             ██╔══██╗██╔══██╗██╔══██╗╚══██╔══╝██╔═══██╗██╔══██╗            ║
║             ██████╔╝███████║██████╔╝   ██║   ██║   ██║██████╔╝            ║
║             ██╔══██╗██╔══██║██╔═══╝    ██║   ██║   ██║██╔══██╗            ║
║             ██║  ██║██║  ██║██║        ██║   ╚██████╔╝██║  ██║            ║
║             ╚═╝  ╚═╝╚═╝  ╚═╝╚═╝        ╚═╝    ╚═════╝ ╚═╝  ╚═╝            ║
║                                                                           ║
║             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 ГБ). Он основан на Microsoft Python 3.12 devcontainer и добавляет инструменты статического анализа, фаззинга и автоматизации браузера.

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

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

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

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

Также поддерживаются devcontainers 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`). Пути к файлам из сканируемых репозиториев никогда не подставляются в строки оболочки — все вызовы подпроцессов используют аргументы в виде списков.

---

## Что умеет RAPTOR

| Команда | Что делает | Статус |
|---------|-------------|--------|
| `/agentic` | Полный автономный рабочий процесс: сканирование, валидация, эксплуатация, патч | Стабильно |
| `/scan` | Статический анализ с помощью Semgrep и CodeQL | Стабильно |
| `/understand` | Картирование поверхности атаки, трассировка потоков данных, поиск вариантов уязвимостей | Стабильно |
| `/binary` | Исследование бинарных файлов методом чёрного ящика, runtime-доказательства, запросы к графу и передача | Бета |
| `/ghidra` | Мост Ghidra RE: подключение/импорт проектов `.gpr`, кросс-версионный diff, экспорт находок | Бета |
| `/audit` | Систематический обзор кода на основе гипотез и инструментов | Бета |
| `/review` | Запрос состояния аудита: находки, пробелы, покрытие, заметки оператора | Стабильно |
| `/annotate` | Прикрепление свободных текстовых аннотаций к каждой функции (заметки оператора) | Стабильно |
| `/validate` | Многоэтапный конвейер валидации эксплуатируемости (этапы 0-F) | Стабильно |
| `/diagram` | Визуальные карты Mermaid из JSON-выводов `/understand` и `/validate` | Бета |
| `/codeql` | Глубокий анализ только с CodeQL с предварительным скринингом потоков данных SMT | Стабильно |
| `/analyze` | Анализ существующих находок SARIF с помощью LLM без повторного сканирования | Стабильно |
| `/openant` | Сканирование исходного кода LLM OpenAnt: анализ AST плюс LLM-рассуждения по каждой функции | Бета |
| `/sca` | Анализ состава ПО: зависимости, рекомендации, сигналы цепочки поставок, SBOM и исправления | Бета |
| `/cve-diff` | Обнаружение и diff фиксирующего коммита для CVE в OSV, NVD, GitHub и GitLab | Бета |
| `/cve-env` | Сборка и проверка окружения Docker, запускающего уязвимое приложение CVE в его предпатчевой версии | Экспериментально |
| `/exploit` | Генерация кода эксплойта proof-of-concept | Бета |
| `/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 из метаданных файла,
импортов и перекрёстных ссылок 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` сначала строит карту и только запускает реальную
кампанию фаззинга, когда существует конкретная граница харнесса; цели приложений, 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

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

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

---

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

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

- **Semgrep (~150 правил)** — правила taint-tracking и pattern-правила для Python, Go, Java и JS/TS. Покрывают SQLi, XSS, SSRF, SSTI, command injection, десериализацию, XXE, LDAP/NoSQL injection, path traversal, open redirect, log/header injection, eval injection, ReDoS, prototype pollution, неверную конфигурацию JWT, слабую криптографию, небезопасный TLS и hardcoded secrets.
- **Coccinelle (68 правил)** — структурное сопоставление для C/C++. Безопасность памяти (double free, use-after-free, free не базового указателя, free стекового массива, mmap'd memory, use-after-close), целочисленные ошибки (overflow, sign extension, double sizeof), утечки ресурсов (несоответствие popen/fclose, двойное закрытие fdopendir), работа с буферами (strncpy без NUL, несоответствие размера copy_user, off-by-one в malloc/strlen), безопасность обработчиков сигналов, неправильное использование API (домен флагов fcntl, SIGKILL/SIGSTOP, двойной byte-swap, статический буфер inet_ntoa), устранение мёртвых сохранений компилятором, путаница IS_ERR/PTR_ERR в ядре, format string injection, гонки TOCTOU и многое другое.
- **CodeQL (8 запросов)** — межпроцедурное taint-tracking для C++ (format string injection, integer truncation, use-after-move, iterator invalidation) и Java (XXE, небезопасная десериализация, log injection, Spring SSRF).

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

---

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

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

| Контроль | Что проверяет | Триггер | Конфигурация / доказательства |
|---|---|---|---|
| Ruff | Линтинг корректности Python (`F401`, `F811`, `F821`, `F841`) | Гейт по diff в PR, плюс еженедельный аудит всего дерева | `pyproject.toml`, `.github/workflows/lint.yml` |
| Pytest | Быстрые границы unit/integration, уровни для конкретных подсистем (через диспетчеризацию по import-graph), аудит prompt-envelope | PR, push в `main`, merge queue, запланированный полный набор тестов | `pytest.ini`, `.github/workflows/tests.yml`, `.github/workflows/nightly.yml` |
| CodeQL Advanced | Сканирование кода Python, C/C++ и GitHub Actions с сужением области по import-graph | PR, push в `main`, merge queue, еженедельное расписание | `.github/workflows/codeql.yml`, `.github/codeql/codeql-config.yml` |
| Усиление workflow | Сторонние Actions, закреплённые по SHA, минимально необходимые разрешения, линтинг метаданных команд | Каждое изменение workflow и каждый запуск линтера | `.github/workflows/`, `.github/scripts/check_command_metadata.py` |
| Линт меток корпуса | Валидация схемы меток аудиторского корпуса и проверка upstream-пинов | PR (изменённые метки), еженедельный полный прогон | `.github/workflows/corpus-labels.yml` |
| Гейт RAPTOR SCA PR | Регрессии зависимостей и цепочки поставок, внесённые PR | Изменения манифестов / lockfile / workflow | `.github/workflows/sca-pr-gate.yml` |
| RAPTOR SCA self-bump | Механическое усиление зависимостей и предложения безопасных обновлений | Еженедельное расписание, ручной запуск | `.github/workflows/sca-self-bump.yml` |
| Корпус компрометаций SCA | Срабатывает ли ожидаемый сигнал при известных компрометациях зависимостей | Еженедельное расписание, соответствующие изменения в PR | `test/data/sca-e2e/compromise-corpus/`, `.github/workflows/sca-compromise-check.yml` |
| Детекторы инвариантов репозитория | Обнаружение мёртвого кода / неверных вызовов, расхождение документации по env-переменным, ограничители списка словаря, байтовые формы канонического JSON, линт импортов опциональных зависимостей | Гейт PR (job `repo-invariants` в `lint.yml`), плюс ежедневный прогон | `.github/workflows/lint.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` |
| Корпус Dataflow | Отслеживание precision / recall / категорий FP для поведения валидатора | Запускаемый разработчиком бенчмарк и тесты корпуса | `core/dataflow/corpus/`, `core/dataflow/scripts/corpus-metrics` |
| Защита документа CI controls | Документированные пути существуют, конфигурация ruff совпадает, README ссылается на документ | PR | `.github/tests/test_ci_controls_docs.py` |

В настоящее время не применяется: `mypy` закреплён в `pyproject.toml`, но ничего не блокирует; форматирование Ruff не применяется; Semgrep является частью поверхности сканера RAPTOR, но у нас пока нет выделенного workflow Semgrep для «сканирования RAPTOR с помощью RAPTOR».

---

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

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

**Слой оркестрации** — это Claude Code, но только для интерактивной оболочки `raptor` (этот разговорный слой со slash-командами). CLAUDE.md, skills и команды выполняются там как инструкции Claude Code. Чтобы изменить, какая модель Claude оркестрирует этот слой, используйте флаг `--model` в Claude Code или команду `/model` внутри сессии. Если этот слой вам вообще не нужен, см. [Запуск полностью автономно](#running-fully-standalone-no-claude-code) ниже.

**Слой диспетчеризации анализа** — это 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 хорошо подходит для анализа; надёжность генерации кода эксплойтов/патчей зависит от масштаба модели и квантования, а не является фиксированным свойством локальных моделей — см. [Quality Tradeoffs](https://github.com/gadievron/raptor/blob/main/llm.md#quality-tradeoffs) в руководстве по LLM и проверьте `/scorecard`, чтобы узнать, что именно измеряет ваша конкретная модель.

### Полностью автономный запуск (без Claude Code)

`bin/raptor` -- интерактивная оболочка с баннером и слеш-командами, то есть этот разговорный слой -- выполняет exec прямо в Claude Code CLI и всегда требует собственного логина. А вот механика под ней — нет: `python3 raptor.py <mode>` — это обычный Python CLI, вообще не зависящий от Claude Code.```bash
# No `claude` process involved at any point
python3 raptor.py doctor                        # status check -- explicitly "no claude needed"
python3 raptor.py agentic --repo /path/to/code   # scan -> dedup -> analysis
python3 raptor.py scan --repo /path/to/code

Направьте `models.json` / `OLLAMA_HOST` на локальный экземпляр Ollama (см. выше), и весь этот путь никогда не будет обращаться к Anthropic — полезно для изолированных машин или оборудования, работающего только локально. Вы теряете слой разговорных slash-команд (этот чат); сам конвейер scan/analysis/exploit при этом не затрагивается.

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

Когда у вашей модели уровня анализа есть более дешёвый собрат от того же провайдера (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
Web Researcher (James Kettle)                  Web endpoint research (smuggling, cache poisoning, SSRF)
Fuzzing Strategist                             Corpus design and triage
Binary Exploitation Specialist                 ROP, heap, and memory corruption

Сохранение `/web`, Z3, SAGE и SDK облачных провайдеров в качестве опциональных дополнений позволяет избежать того, чтобы стандартная установка RAPTOR становилась тяжелее и более хрупкой, чем это необходимо.