This repository was archived by the owner on Sep 23, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
This repository was archived by the owner on Sep 23, 2025. It is now read-only.
Move logic into MCP server for cross-IDE portability #19
Copy link
Copy link
Open
Labels
ai-managedAI is permitted to update this issue OP and add commentsAI is permitted to update this issue OP and add commentsarchitectureDesign and architecture workDesign and architecture worktracking-issueOngoing work item tracked across multiple sessionsOngoing work item tracked across multiple sessions
Description
Cross-IDE Portability via MCP Server Logic Migration
Status: Planning
Current Understanding
Currently, significant logic resides in the VSCode extension (TypeScript), making Dialectic tightly coupled to VSCode. To support other IDEs (Cursor, Zed, Neovim, etc.), we should migrate as much logic as possible into the MCP server (Rust) and minimize IDE-specific code.
Benefits
- Cross-IDE Support: Same core functionality works across different editors
- Reduced Duplication: Write logic once in Rust instead of per-IDE
- Better Testing: Rust code is easier to unit test than extension code
- Performance: Rust implementation likely faster than TypeScript
- Maintenance: Single codebase for core logic
Logic Migration Candidates
High Priority:
- File reference parsing and link generation
- Review content processing and validation
- Terminal detection and selection heuristics
- PID discovery and process tree walking
- Selection context formatting
Medium Priority:
- Code action generation logic
- Terminal message formatting
- Error handling and user feedback
Low Priority (IDE-specific):
- Webview rendering (inherently IDE-specific)
- Native file system integration
- Editor selection APIs
Approach
- Audit Current Logic: Identify what's in extension vs server
- Design MCP Protocol Extensions: Define new MCP tools/capabilities
- Incremental Migration: Move logic piece by piece with testing
- Thin Client Pattern: Extensions become thin wrappers around MCP calls
Next Steps
- Audit current VSCode extension to catalog logic that could be moved
- Research MCP protocol capabilities for rich data exchange
- Design new MCP tools for file operations, terminal management, etc.
- Create proof-of-concept with one piece of migrated logic
Open Questions
- How much can we move while staying within MCP protocol constraints?
- What's the right abstraction layer for IDE-specific operations?
- Should we create custom MCP protocol extensions or work within standard?
- How to handle IDE-specific UI patterns (webviews, panels, etc.)?
Context
This supports the long-term vision of Dialectic as a cross-platform code review tool. By centralizing logic in the MCP server, we can support multiple IDEs with minimal per-IDE development effort.
Metadata
Metadata
Assignees
Labels
ai-managedAI is permitted to update this issue OP and add commentsAI is permitted to update this issue OP and add commentsarchitectureDesign and architecture workDesign and architecture worktracking-issueOngoing work item tracked across multiple sessionsOngoing work item tracked across multiple sessions