Сценарий 09: ревью ограниченного изменения

Используйте этот сценарий для pull request, диапазона коммитов, staged-изменения или заданного набора файлов. Полезное ревью привязано к точным базовой и конечной ревизиям, начинает с применимых находок и отделяет проверенные свидетельства от ухудшенного или неподдержанного анализа.

Сценарий OpenCode

В установленном клиенте выполните:

/review

Поддерживаемая команда выполняет переносимую последовательность:

1. codegraph_project_context_status устанавливает готовность проекта и графа.
2. codegraph_context_session_open открывает или повторно использует явную сессию.
3. codegraph_context_retrieval_diff_preview привязывает ревью к запрошенной базе или файлам.
4. Точечный codegraph_context_retrieval_file_read и совмещённый поиск объясняют только находки высокого риска.
5. codegraph_digital_employee_code_quality_review_report создаёт свидетельство качества кода, если эта линия входит в область.
6. codegraph_digital_employee_architecture_impact_review_report создаёт свидетельство архитектурного влияния, если эта линия входит в область.
7. codegraph_task_context_used_context_record фиксирует фактически использованные свидетельства.

Запись в память — отдельная мутация. Она выполняется только при разрешении задачи и проверяется асинхронно; read-only ревью не подразумевает публикацию памяти.

Если граф устарел или недоступен, команда возвращает ограниченную отсрочку либо явно помеченное graph-only ревью. Сокращённое покрытие нельзя выдавать за полный вердикт.

Ревью через CLI

Для воспроизводимого локального отчёта явно передайте граф и базовую ревизию:

python -m src.cli review --db PATH --base-ref <git-ref> --format json

Та же команда поддерживает другие области:

python -m src.cli review --db PATH --staged --format markdown
python -m src.cli review --db PATH --files <file1> <file2> --format sarif --sarif-file <results.sarif>

Используйте --output-file для отчёта в месте, выбранном вызывающей стороной. Флаг --no-security исключает сканирование безопасности из CLI pipeline; укажите состав проверок в свидетельстве ревью.

Порядок проверки

1. Подтвердите базу, конечную ревизию, изменённые файлы и область задачи.
2. До стиля ищите расхождения в поведении и критериях приёмки.
3. Проверьте публичные интерфейсы, сериализацию, хранение, авторизацию и ошибочные пути.
4. Проследите изменённые символы до вызывающего кода высокого риска и зависимостей за границами компонента.
5. Проверьте тесты ожидаемого поведения и важных негативных путей.
6. Для каждой находки укажите серьёзность, место, свидетельство, последствие и минимальную безопасную коррекцию.
7. После исправлений повторите точечные проверки и оставьте нерешённые пункты явными.

Одобрение оформляется при доказанной области, готовности и наборе включённых проверок; пустой отчёт фиксирует отсутствие результатов.

Граница полномочий

Структурное ревью и проверка качества кода покрывают свои находки. Решения AppSec, QA, развёртывания и выпуска фиксируют ответственные линии в отдельных свидетельствах; отчёт ревью ссылается на эти решения.

Поддерживаемые источники контракта

• Сценарий OpenCode: .opencode/commands/review.md
• Регистрация CLI и форматы: src/cli/analysis_commands/review_command.py
• Политика сценария ревьюера: src/digital_employees/runtime/scenarios/employee_scenario_invocation.py

Эта страница — краткий сценарий. Полная модель проверки, находок и интеграций приведена в каноническом руководстве по ревью кода.