You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 23, 2025. It is now read-only.
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.
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
Logic Migration Candidates
High Priority:
Medium Priority:
Low Priority (IDE-specific):
Approach
Next Steps
Open Questions
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.