Add optional CodeGraph structural context tool

[GenjiCy]

Problem

OpenCodeReview currently has text-oriented context tools such as code_search, file_read, and file_read_diff. These work well for literal lookup, but they do not expose structural relationships such as symbol definitions, callers, callees, or impact radius.

That makes it harder for the review agent to reason about changes like:

• public function or method signature changes
• interface / type / data model changes
• shared utility behavior changes
• route handler, auth, security, concurrency, or lifecycle logic changes
• cross-file impact where the risk depends on callers or callees

Proposal

Add an optional CodeGraph-backed context tool that is only exposed when CodeGraph is actually available for the checked-out repository.

Important constraints:

• The tool must be hidden when .codegraph/codegraph.db is missing.
• The tool must be hidden when the codegraph executable is not installed in the CI/job environment.
• The tool must be hidden for incompatible CodeGraph versions.
• In range/commit review modes, the CodeGraph index must correspond to the same checkout as --to / --commit; otherwise structural context may describe a different revision than the diff being reviewed.

CI/CD note

The current GitHub Actions and GitLab CI examples install OpenCodeReview, but they do not install CodeGraph or build a .codegraph index. In those default CI/CD setups, the CodeGraph tool should therefore remain unavailable and should not affect existing review behavior.

Teams that want this in CI can opt in by using a runner image that includes CodeGraph and by building/syncing the index after checkout, before running ocr review.

[lizhengfeng101]

Thank you for the great suggestion! This aligns well with our thinking.

We've actually already implemented this feature internally and it's currently queued for evaluation. The main development bottleneck right now is that any change that could affect Agent effectiveness requires running evaluations against 200 real PRs, which involves significant LLM consumption. This evaluation resource is currently only available during off-peak hours (nighttime), so the pipeline takes some time to cycle through.

Stay tuned — we're looking forward to releasing this soon!

[GenjiCy]

Thanks for the update — the MCP-based direction makes sense to me, and I agree it is a better long-term extension point than a dedicated CodeGraph-only integration.

I will keep #211 as a reference implementation for now. The main edge cases I tried to cover there may still be useful for the MCP implementation:

• hide optional structural tools when the server/index is unavailable, especially in default CI/CD jobs;
• avoid using structural context when the current checkout does not match the review target ref;
• keep third-party tool version/compatibility boundaries explicit.

Happy to help review #212 when it is ready.