feat: inject static analysis context into review prompt (#140)

[ajianaz]

Summary

Reduce cora review false positives by injecting static analysis (clippy) context into the LLM prompt.

Problem: LLM flags intentional changes (dead code removal, match arm merges) as errors because it only sees the diff text — it doesn't know clippy/compiler already verified the change.

Solution: Optional static analysis context injection via two modes:

1. review.static_analysis.auto_clippy: true — automatically run cargo clippy and filter output to changed files
2. review.static_analysis.clippy_output_file: path — read pre-computed clippy output from file

Config example (.cora.yaml):

review:
  static_analysis:
    auto_clippy: true

New files:

• src/engine/static_analysis.rs — clippy runner, file reader, Rust file extraction (5 tests)

Modified:

• src/config/schema.rs — StaticAnalysisConfig, ReviewSection.static_analysis
• src/engine/llm.rs — build_review_prompt accepts static_context param
• src/engine/review.rs — collects static context before LLM call

Zero-config: No behavior change when not configured.

Verification: 229 tests ✅ | clippy ✅ | fmt ✅

Closes #140

Co-Authored-By: codecoradev noreply@github.com

[github-actions]

🔍 Cora AI Code Review

❌ Blocked — critical issues found.

🔴 Error (2)

• src/engine/static_analysis.rs:30 — collect_static_context is a synchronous function that calls tokio::task::block_in_place. This function is called from review_diff_inner in review.rs which is async, so block_in_place works correctly there. However, block_in_place requires being called from a multi-threaded runtime context. If this function is ever called from outside a tokio runtime (e.g., in tests like empty_config_returns_none), it will panic. The tests currently avoid this because they hit early returns, but this is fragile. Consider making this an async function or documenting the runtime requirement.
• src/engine/static_analysis.rs:130 — When the 30-second timeout fires, the spawned thread continues to wait for the clippy child process, and the child process keeps running. The child_pid is captured but never used to kill the process. This means orphaned clippy processes can accumulate, consuming CPU and holding file locks. The child handle is moved into the spawned thread, so there's no way to kill it from the timeout path.

---

Review powered by cora-cli · BYOK · MIT