[Feature Request] Support Stateful / Multi-turn Conversational Code Review & Incremental Reviews

[lwintermelon]

Problem / Motivation

Currently, open-code-review provides high-precision, deterministic line-level code reviews. However, the current review workflow is primarily stateless.

In real-world software engineering, code review is inherently an iterative and conversational process:

1. Incremental Updates: Developers push new commits / patch sets based on initial review feedback. The AI needs to recall past suggestions to evaluate whether issues were properly addressed without re-evaluating unchanged logic.
2. Clarification & Discussion: Developers often want to reply to specific inline comments to ask for explanations, request alternative refactoring ideas, or challenge suggestions.
3. Multi-turn Context: State-of-the-art AI assistants (such as GitHub Copilot or CodeRabbit) provide continuous session-based review threads and persistent conversation context.

Similar functionality is already implemented in other ecosystem plugins. For instance, amarula/reviewai-gerrit-plugin maintains session state and review history for multi-turn discussions on Gerrit changes (though it relies on LangChain).

---

Feature Proposal

We propose adding Stateful Session & Multi-turn Conversation Support to open-code-review.

Key Architectural Considerations:

• Lightweight State Management without Heavy Frameworks:
  While tools like reviewai-gerrit-plugin use LangChain to manage context, open-code-review does not need to adopt LangChain. A lightweight, Go-native session store (e.g., local file/sqlite-based history caching or PR/MR comment history parser) would align much better with open-code-review's high performance and deterministic engineering design.
• Persistent Review Threads:
  Ability to append follow-up discussions and track conversation history bound to specific PRs/MRs or Commit ranges.
• Incremental Delta Reviewing:
  Combine the existing AST/Diff analysis with historical session memory to review only new/changed code while maintaining global awareness of previous review comments.

---

Use Case Example

1. Round 1: ocr review generates inline comments on PR.
2. Follow-up Chat: Developer replies via CLI / comment: "Why is this line unsafe? How can I rewrite it with channel select?" -> OCR responds using prior context.
3. Round 2 (Re-review): Developer pushes commit v2. ocr reviews the delta, checks if Round 1 comments were addressed, and resolves fixed threads automatically.

---

Proposed Implementation Ideas

• Session Storage Interface: Define a pluggable storage interface (LocalFile, GitNote, or platform-native metadata) to save session_id and message history.
• Context Injection Pipeline: Extend the prompt construction pipeline to optionally ingest previous review turns and developer responses.
• CLI / Bot Interaction Commands: Add subcommands like ocr chat --session <id> or bot mentions in PR comments to trigger follow-up replies.

[lizhengfeng101]

Hi @lwintermelon, thank you for this thoughtful and well-structured proposal! 🙏

You've captured the iterative nature of real-world code review very well, and these are exactly the kinds of scenarios we think a lot about.

To share some context on our current design philosophy: open-code-review is intentionally stateless. Our goal is to keep the core a clean, pure tool — with as little embedded business logic and state handling as possible. This is not an oversight, but a deliberate architectural choice. In fact, even within Alibaba Group, the way we use OpenCodeReview internally is by building a layer of business management, state management, and session orchestration on top of this stateless kernel, rather than baking it into the kernel itself. Keeping the core minimal and deterministic is what lets it be embedded and composed reliably across very different environments.

That said, we completely agree with the value you're pointing to. As OpenCodeReview grows, we do believe we'll want to offer these capabilities — cross-session context, stateful/incremental reviews, and even collaborative Web views — provided in an elegant architecture within OCR itself, without compromising the purity of the core.

So thank you for the proposal — I believe this feature is on its way. Stay tuned! 🚀