Skip to main content

Scenario 09: Review a bounded change

Use this scenario for a pull request, commit range, staged change, or named file set. A useful review is tied to an exact base and head revision, puts.

User Guides

Use this scenario for a pull request, commit range, staged change, or named file set. A useful review is tied to an exact base and head revision, puts actionable findings first, and separates verified evidence from degraded or unsupported analysis.

OpenCode workflow

In an installed client, run:

/review

The maintained command performs this portable sequence:

  1. codegraph_project_context_status establishes project and graph readiness.
  2. codegraph_context_session_open opens or reuses the explicit session.
  3. codegraph_context_retrieval_diff_preview binds review to the requested base or files.
  4. Targeted codegraph_context_retrieval_file_read and fused search explain only high-risk findings.
  5. codegraph_digital_employee_code_quality_review_report produces code-quality evidence when that lane is in scope.
  6. codegraph_digital_employee_architecture_impact_review_report produces architecture-impact evidence when that lane is in scope.
  7. codegraph_task_context_used_context_record records the evidence actually used.

Memory commit is a separate mutation. It is attempted only when the task authorizes it and must be checked asynchronously; a read-only review does not imply memory publication.

If the graph is stale or unavailable, the command returns a bounded deferral or an explicitly labelled graph-only review. Record the reduced coverage with the result and refresh the graph before a complete verdict.

CLI review

For a reproducible local report, provide the graph and base explicitly:

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

Alternative scopes supported by the same command are:

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>

Use --output-file for a caller-owned report. --no-security deliberately removes the security scan from the CLI pipeline and must be disclosed in the review evidence.

Review order

  1. Confirm base, head, changed files and task scope.
  2. Check behavior and acceptance-criterion mismatches before style.
  3. Inspect public interfaces, serialization, persistence, authorization and failure paths.
  4. Follow changed symbols to high-risk callers and cross-boundary dependencies.
  5. Check tests for both the intended behavior and important negative paths.
  6. Record each finding with severity, location, evidence, consequence and smallest safe correction.
  7. Re-run focused checks after corrections and keep unresolved items explicit.

An empty report records no findings for the configured scope. Record approval after confirming scope, readiness, enabled checks, and the accountable review decision.

Authority boundary

Structural and code-quality review covers its own findings. AppSec, QA, deployment, and release owners record their decisions in separate evidence; the review report can reference those decisions.

Maintained source contracts

  • OpenCode workflow: .opencode/commands/review.md
  • CLI registration and formats: src/cli/analysis_commands/review_command.py
  • Reviewer scenario policy: src/digital_employees/runtime/scenarios/employee_scenario_invocation.py

This page is the concise scenario. For the full review model, findings and integrations, use the canonical Code Review Guide.

Report a documentation issue