-
Notifications
You must be signed in to change notification settings - Fork 95
documentation updates #2142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
documentation updates #2142
Changes from all commits
e1411e5
dddd28d
ec9d2ea
3898c9d
ed276ca
ff57554
caf4555
120fe5e
3647448
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,374 @@ | ||
# Sidecar Architecture | ||
|
||
This document provides a detailed explanation of the Sidecar architecture, including component interactions, data flow, and design decisions. | ||
|
||
## Overview | ||
|
||
Sidecar is built as a Rust workspace with multiple crates that work together to provide AI-powered code assistance. The architecture follows a modular design with clear separation of concerns. | ||
|
||
```mermaid | ||
flowchart TD | ||
A[Aide Editor] <--> B[Webserver API] | ||
B <--> C[Application Core] | ||
C <--> D[LLM Client] | ||
C <--> E[Repository Analysis] | ||
C <--> F[Agentic Tools] | ||
C <--> G[MCTS Decision Engine] | ||
C <--> H[Code Chunking] | ||
D <--> I[External LLM Providers] | ||
E <--> J[Git Repository] | ||
F <--> K[Symbol Management] | ||
H <--> L[Language-Specific Parsers] | ||
``` | ||
|
||
## Core Components | ||
|
||
### 1. Application Core | ||
|
||
The Application Core is the central component that coordinates all other parts of the system. It initializes and manages the various subsystems, handles configuration, and provides a unified interface for the webserver. | ||
|
||
**Key Responsibilities:** | ||
- System initialization and configuration | ||
- Component lifecycle management | ||
- Resource allocation and management | ||
- Cross-component coordination | ||
|
||
**Implementation Details:** | ||
- Located in `sidecar/src/application/` | ||
- Main class: `Application` in `application.rs` | ||
- Configuration handled by `Configuration` in `config/configuration.rs` | ||
|
||
### 2. Webserver API | ||
|
||
The Webserver API provides HTTP endpoints for the Aide editor to communicate with Sidecar. It handles request routing, authentication, and response formatting. | ||
|
||
**Key Endpoints:** | ||
- `/api/agentic/*`: Endpoints for AI agent operations | ||
- `/api/tree_sitter/*`: Endpoints for code parsing and analysis | ||
- `/api/file/*`: Endpoints for file operations | ||
- `/api/plan/*`: Endpoints for planning operations | ||
|
||
**Implementation Details:** | ||
- Located in `sidecar/src/webserver/` | ||
- Main entry point: `webserver.rs` in `sidecar/src/bin/` | ||
- Uses Axum for HTTP routing and handling | ||
|
||
### 3. LLM Client | ||
|
||
The LLM Client handles communication with various Large Language Model providers. It manages API keys, formats requests according to provider specifications, and processes responses. | ||
|
||
**Supported Providers:** | ||
- OpenAI (GPT models) | ||
- Anthropic (Claude models) | ||
- Google AI (Gemini models) | ||
- Various open-source models via Ollama, LM Studio, etc. | ||
|
||
**Implementation Details:** | ||
- Located in `llm_client/src/` | ||
- Main broker: `LLMBroker` in `broker.rs` | ||
- Provider-specific clients in `clients/` | ||
|
||
### 4. Repository Analysis | ||
|
||
The Repository Analysis component analyzes code repositories to build a graph representation of the codebase. It uses PageRank-like algorithms to identify important symbols and relationships. | ||
|
||
**Key Features:** | ||
- File and directory scanning | ||
- Symbol extraction and relationship mapping | ||
- Importance scoring using PageRank | ||
- Context retrieval for relevant code sections | ||
|
||
**Implementation Details:** | ||
- Located in `sidecar/src/repomap/` | ||
- Main analyzer: `Analyser` in `analyser.rs` | ||
- Graph implementation in `graph.rs` | ||
|
||
### 5. Agentic Tools | ||
|
||
The Agentic Tools component provides a collection of tools that AI agents can use to perform complex code operations. It includes tools for code editing, symbol analysis, and context gathering. | ||
|
||
**Key Tools:** | ||
- Code editing tools | ||
- Symbol analysis tools | ||
- Repository search tools | ||
- Context gathering tools | ||
|
||
**Implementation Details:** | ||
- Located in `sidecar/src/agentic/` | ||
- Tool management in `tool/` | ||
- Symbol management in `symbol/` | ||
- Memory management in `memory/` | ||
|
||
### 6. MCTS Decision Engine | ||
|
||
The Monte Carlo Tree Search (MCTS) Decision Engine explores possible code changes and selects the most promising ones. It uses a tree-based search algorithm to evaluate different actions and their potential outcomes. | ||
|
||
**Key Components:** | ||
- Action node representation | ||
- Selection strategies | ||
- Value functions for evaluating changes | ||
- Execution planning | ||
|
||
**Implementation Details:** | ||
- Located in `sidecar/src/mcts/` | ||
- Action node implementation in `action_node.rs` | ||
- Selection strategies in `selector/` | ||
- Execution handling in `execution/` | ||
|
||
### 7. Code Chunking | ||
|
||
The Code Chunking component parses and chunks code into meaningful segments for better understanding by LLMs. It uses language-specific parsers to extract symbols, relationships, and context. | ||
|
||
**Supported Languages:** | ||
- Rust | ||
- Python | ||
- JavaScript/TypeScript | ||
- Go | ||
|
||
**Implementation Details:** | ||
- Located in `sidecar/src/chunking/` | ||
- Language-specific parsers in language-named files (e.g., `rust.rs`) | ||
- Common parsing utilities in `helpers.rs` | ||
- Text document management in `text_document.rs` | ||
|
||
## Data Flow | ||
|
||
### Request Processing Flow | ||
|
||
```mermaid | ||
sequenceDiagram | ||
participant Editor as Aide Editor | ||
participant API as Webserver API | ||
participant App as Application Core | ||
participant LLM as LLM Client | ||
participant Repo as Repository Analysis | ||
participant Agent as Agentic Tools | ||
Editor->>API: Request (code context, query) | ||
API->>App: Process request | ||
App->>Repo: Analyze repository context | ||
Repo-->>App: Repository context | ||
App->>Agent: Select appropriate tools | ||
Agent->>LLM: Generate prompt with context | ||
LLM-->>Agent: LLM response | ||
Agent->>App: Process LLM response | ||
App->>API: Formatted response | ||
API->>Editor: Display results to user | ||
``` | ||
|
||
### Code Editing Flow | ||
|
||
```mermaid | ||
sequenceDiagram | ||
participant Editor as Aide Editor | ||
participant API as Webserver API | ||
participant Agent as Agentic System | ||
participant MCTS as MCTS Engine | ||
participant LLM as LLM Client | ||
participant FS as File System | ||
Editor->>API: Edit request with code context | ||
API->>Agent: Process edit request | ||
Agent->>MCTS: Generate possible edits | ||
loop Action Selection | ||
MCTS->>LLM: Generate candidate actions | ||
LLM-->>MCTS: Candidate actions | ||
MCTS->>MCTS: Evaluate actions | ||
MCTS->>MCTS: Select best action | ||
end | ||
MCTS-->>Agent: Best edit action | ||
Agent->>FS: Apply edit to file | ||
FS-->>Agent: Edit result | ||
Agent->>API: Edit response | ||
API->>Editor: Updated code | ||
``` | ||
|
||
## Component Interactions | ||
|
||
### Application Initialization | ||
|
||
```mermaid | ||
sequenceDiagram | ||
participant Main as Main | ||
participant App as Application | ||
participant Config as Configuration | ||
participant Logging as Logging | ||
participant LLM as LLM Broker | ||
participant Repo as Repository Pool | ||
participant Lang as Language Parsing | ||
participant Tools as Tool Box | ||
participant Symbols as Symbol Manager | ||
Main->>Config: Parse configuration | ||
Main->>Logging: Install logging | ||
Main->>App: Initialize application | ||
App->>Repo: Initialize repository pool | ||
App->>Lang: Initialize language parsing | ||
App->>LLM: Initialize LLM broker | ||
App->>Tools: Initialize tool box | ||
App->>Symbols: Initialize symbol manager | ||
Main->>Main: Start webserver | ||
``` | ||
|
||
### Tool Execution | ||
|
||
```mermaid | ||
sequenceDiagram | ||
participant API as API Endpoint | ||
participant Agent as Agent | ||
participant ToolBox as Tool Box | ||
participant Tool as Specific Tool | ||
participant LLM as LLM Client | ||
participant FS as File System | ||
API->>Agent: Tool use request | ||
Agent->>ToolBox: Select appropriate tool | ||
ToolBox->>Tool: Execute tool with parameters | ||
Tool->>LLM: Generate content (if needed) | ||
LLM-->>Tool: Generated content | ||
Tool->>FS: Perform file operations (if needed) | ||
FS-->>Tool: Operation result | ||
Tool-->>ToolBox: Tool execution result | ||
ToolBox-->>Agent: Processed result | ||
Agent-->>API: Tool use response | ||
``` | ||
|
||
## Design Decisions | ||
|
||
### Modular Architecture | ||
|
||
Sidecar uses a modular architecture with clear separation of concerns. This allows for easier maintenance, testing, and extension of the codebase. | ||
|
||
**Benefits:** | ||
- Components can be developed and tested independently | ||
- New features can be added without affecting existing functionality | ||
- Different teams can work on different components simultaneously | ||
|
||
### Rust Workspace | ||
|
||
The project is organized as a Rust workspace with multiple crates. This provides better dependency management and compilation times. | ||
|
||
**Benefits:** | ||
- Clear separation between major components | ||
- Independent versioning of components | ||
- Faster incremental compilation | ||
- Better dependency management | ||
|
||
### Asynchronous Processing | ||
|
||
Sidecar uses asynchronous processing extensively to handle concurrent requests and long-running operations. | ||
|
||
**Benefits:** | ||
- Better resource utilization | ||
- Improved responsiveness | ||
- Ability to handle multiple requests simultaneously | ||
- Support for streaming responses | ||
|
||
### LLM Provider Abstraction | ||
|
||
The LLM client uses an abstraction layer to support multiple LLM providers. This allows for easy switching between providers and support for new providers. | ||
|
||
**Benefits:** | ||
- Support for multiple LLM providers | ||
- Easy addition of new providers | ||
- Ability to switch providers at runtime | ||
- Consistent interface for all providers | ||
|
||
### Tree-sitter Integration | ||
|
||
Sidecar uses Tree-sitter for code parsing and analysis. This provides accurate and efficient parsing for multiple programming languages. | ||
|
||
**Benefits:** | ||
- Support for multiple programming languages | ||
- Accurate parsing and symbol extraction | ||
- Efficient incremental parsing | ||
- Rich query capabilities | ||
|
||
## Performance Considerations | ||
|
||
### Token Usage Optimization | ||
|
||
Sidecar optimizes token usage to reduce costs and improve performance when communicating with LLM providers. | ||
|
||
**Strategies:** | ||
- Context pruning to remove irrelevant information | ||
- Chunking large files into smaller segments | ||
- Caching frequently used prompts and responses | ||
- Using embeddings for efficient similarity search | ||
|
||
### Caching | ||
|
||
Sidecar uses caching at multiple levels to improve performance and reduce redundant operations. | ||
|
||
**Cache Types:** | ||
- Repository analysis cache | ||
- LLM response cache | ||
- Parsed code cache | ||
- Symbol information cache | ||
|
||
### Parallel Processing | ||
|
||
Sidecar uses parallel processing for computationally intensive operations like repository analysis and code parsing. | ||
|
||
**Parallel Operations:** | ||
- File scanning and parsing | ||
- Repository graph construction | ||
- PageRank calculation | ||
- MCTS exploration | ||
|
||
## Security Considerations | ||
|
||
### API Key Management | ||
|
||
Sidecar handles API keys for various LLM providers. These keys are sensitive and must be protected. | ||
|
||
**Security Measures:** | ||
- Keys are never logged or exposed in responses | ||
- Keys can be provided via environment variables | ||
- Support for key rotation and management | ||
|
||
### Code Execution | ||
|
||
Sidecar does not execute user code directly, but it does perform file operations that could potentially be exploited. | ||
|
||
**Security Measures:** | ||
- Strict validation of file paths | ||
- Limiting operations to the repository directory | ||
- Careful handling of user input | ||
|
||
### Authentication | ||
|
||
The webserver API can be configured to require authentication for sensitive operations. | ||
|
||
**Security Measures:** | ||
- Support for token-based authentication | ||
- Role-based access control | ||
- Secure token validation | ||
|
||
## Extensibility | ||
|
||
### Plugin System | ||
|
||
Sidecar is designed to be extensible through a plugin system. This allows for adding new functionality without modifying the core codebase. | ||
|
||
**Extension Points:** | ||
- New language support | ||
- Additional tools | ||
- Custom LLM providers | ||
- Alternative repository analysis methods | ||
|
||
### Configuration Options | ||
|
||
Sidecar provides extensive configuration options to customize its behavior for different environments and use cases. | ||
|
||
**Configurable Aspects:** | ||
- LLM provider selection and parameters | ||
- Repository analysis settings | ||
- Caching behavior | ||
- Performance tuning | ||
|
||
## Conclusion | ||
|
||
The Sidecar architecture is designed to be modular, extensible, and performant. It provides a solid foundation for AI-powered code assistance and can be extended to support new features and use cases. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,238 @@ | ||
# Sidecar Key Concepts and Terminology | ||
|
||
This document explains the key concepts and terminology used in the Sidecar project. Understanding these concepts will help you navigate the codebase and contribute effectively. | ||
|
||
## Table of Contents | ||
|
||
- [AI Concepts](#ai-concepts) | ||
- [Code Understanding](#code-understanding) | ||
- [System Architecture](#system-architecture) | ||
- [Development Concepts](#development-concepts) | ||
- [Integration Concepts](#integration-concepts) | ||
|
||
## AI Concepts | ||
|
||
### Large Language Models (LLMs) | ||
|
||
**Definition**: Large Language Models are AI models trained on vast amounts of text data that can generate human-like text, understand context, and perform various language tasks. | ||
|
||
**In Sidecar**: LLMs are used for code understanding, generation, and editing. Sidecar supports multiple LLM providers, including OpenAI, Anthropic, and Google AI. | ||
|
||
**Key Components**: | ||
- `llm_client` crate: Handles communication with LLM providers | ||
- `LLMBroker`: Manages different LLM clients and routes requests | ||
- `LLMClient` trait: Interface for different LLM providers | ||
|
||
### Agentic System | ||
|
||
**Definition**: An agentic system is an AI system that can take actions autonomously to achieve specific goals. It can use tools, make decisions, and interact with its environment. | ||
|
||
**In Sidecar**: The agentic system allows AI to perform complex code operations, such as editing, refactoring, and analyzing code. | ||
|
||
**Key Components**: | ||
- `agentic` module: Contains the core agentic functionality | ||
- `ToolBox`: Collection of tools available to the agent | ||
- `SymbolManager`: Manages code symbols and their relationships | ||
- `Memory`: Stores context and information for the agent | ||
|
||
### Monte Carlo Tree Search (MCTS) | ||
|
||
**Definition**: MCTS is a heuristic search algorithm for decision processes, particularly useful for complex decision spaces where evaluating all possibilities is impractical. | ||
|
||
**In Sidecar**: MCTS is used to explore possible code changes and select the most promising ones for implementation. | ||
|
||
**Key Components**: | ||
- `mcts` module: Contains the MCTS implementation | ||
- `ActionNode`: Represents a node in the MCTS tree | ||
- `Selector`: Selects nodes for exploration | ||
- `ValueFunction`: Evaluates the value of nodes | ||
|
||
### Tool-Based Approach | ||
|
||
**Definition**: A tool-based approach allows an AI agent to use specific tools to interact with its environment and accomplish tasks. | ||
|
||
**In Sidecar**: Tools are used by the agent to perform specific operations, such as editing code, searching repositories, and analyzing symbols. | ||
|
||
**Key Components**: | ||
- `tool` module: Contains tool implementations | ||
- `Tool` trait: Interface for different tools | ||
- `ToolBroker`: Manages tool selection and execution | ||
|
||
## Code Understanding | ||
|
||
### Symbol | ||
|
||
**Definition**: A symbol is a named entity in code, such as a function, class, variable, or module. | ||
|
||
**In Sidecar**: Symbols are the basic units of code understanding. Sidecar extracts symbols from code and analyzes their relationships. | ||
|
||
**Key Components**: | ||
- `symbol` module: Contains symbol-related functionality | ||
- `SymbolManager`: Manages symbols and their relationships | ||
- `SymbolTrackerInline`: Tracks symbols in editor sessions | ||
|
||
### Repository Mapping | ||
|
||
**Definition**: Repository mapping is the process of analyzing a code repository to understand its structure, dependencies, and important components. | ||
|
||
**In Sidecar**: Repository mapping is used to build a graph representation of the codebase, which helps in understanding context and relationships. | ||
|
||
**Key Components**: | ||
- `repomap` module: Contains repository mapping functionality | ||
- `Analyser`: Analyzes repositories and builds graphs | ||
- `Graph`: Represents the repository as a graph | ||
- `PageRank`: Calculates importance scores for symbols | ||
|
||
### Code Chunking | ||
|
||
**Definition**: Code chunking is the process of breaking down code into meaningful segments for analysis and understanding. | ||
|
||
**In Sidecar**: Code chunking is used to parse and analyze code in a structured way, extracting symbols and their relationships. | ||
|
||
**Key Components**: | ||
- `chunking` module: Contains code chunking functionality | ||
- `TSLanguageParsing`: Uses Tree-sitter for language parsing | ||
- `EditorParsing`: Parses code in editor sessions | ||
- Language-specific parsers (e.g., `rust.rs`, `python.rs`) | ||
|
||
### Tree-sitter | ||
|
||
**Definition**: Tree-sitter is a parser generator tool and incremental parsing library that can build a concrete syntax tree for source code. | ||
|
||
**In Sidecar**: Tree-sitter is used for accurate and efficient parsing of multiple programming languages. | ||
|
||
**Key Components**: | ||
- `tree-sitter` dependency: The core parsing library | ||
- Language-specific grammars (e.g., `tree-sitter-rust`, `tree-sitter-python`) | ||
- `TSLanguageParsing`: Wrapper for Tree-sitter functionality | ||
|
||
## System Architecture | ||
|
||
### Application Core | ||
|
||
**Definition**: The application core is the central component that coordinates all other parts of the system. | ||
|
||
**In Sidecar**: The application core initializes and manages the various subsystems, handles configuration, and provides a unified interface for the webserver. | ||
|
||
**Key Components**: | ||
- `application` module: Contains the application core | ||
- `Application` struct: Main application class | ||
- `Configuration` struct: Application configuration | ||
|
||
### Webserver | ||
|
||
**Definition**: The webserver provides HTTP endpoints for external systems to communicate with Sidecar. | ||
|
||
**In Sidecar**: The webserver handles requests from the Aide editor, routes them to the appropriate components, and returns responses. | ||
|
||
**Key Components**: | ||
- `webserver` module: Contains the webserver implementation | ||
- `webserver.rs` binary: Main entry point for the webserver | ||
- Various router functions (e.g., `agentic_router`, `tree_sitter_router`) | ||
|
||
### Repository Pool | ||
|
||
**Definition**: The repository pool manages access to code repositories and their state. | ||
|
||
**In Sidecar**: The repository pool provides a unified interface for accessing and manipulating repositories. | ||
|
||
**Key Components**: | ||
- `repo` module: Contains repository-related functionality | ||
- `RepositoryPool` struct: Manages repository access | ||
- `state` module: Manages repository state | ||
|
||
### LLM Broker | ||
|
||
**Definition**: The LLM broker manages communication with different LLM providers and routes requests to the appropriate client. | ||
|
||
**In Sidecar**: The LLM broker provides a unified interface for generating text, chat completions, and other LLM operations. | ||
|
||
**Key Components**: | ||
- `LLMBroker` struct: Main broker class | ||
- `LLMClient` trait: Interface for LLM providers | ||
- Provider-specific clients (e.g., `OpenAIClient`, `AnthropicClient`) | ||
|
||
## Development Concepts | ||
|
||
### Rust Workspace | ||
|
||
**Definition**: A Rust workspace is a collection of packages that share dependencies and configuration. | ||
|
||
**In Sidecar**: Sidecar is organized as a Rust workspace with multiple crates, each responsible for a specific aspect of functionality. | ||
|
||
**Key Components**: | ||
- `Cargo.toml` at the root: Defines the workspace | ||
- Individual crates: `sidecar`, `llm_client`, `llm_prompts`, `logging` | ||
- Shared dependencies and configuration | ||
|
||
### Asynchronous Programming | ||
|
||
**Definition**: Asynchronous programming allows operations to run concurrently without blocking the main thread. | ||
|
||
**In Sidecar**: Asynchronous programming is used extensively for handling concurrent requests, I/O operations, and long-running tasks. | ||
|
||
**Key Components**: | ||
- `tokio` dependency: Asynchronous runtime | ||
- `async`/`await` syntax: Used for asynchronous functions | ||
- `Future` trait: Represents asynchronous computations | ||
|
||
### Error Handling | ||
|
||
**Definition**: Error handling is the process of managing and responding to error conditions in a program. | ||
|
||
**In Sidecar**: Error handling is done using the `anyhow` and `thiserror` crates, which provide flexible and ergonomic error handling. | ||
|
||
**Key Components**: | ||
- `anyhow` dependency: For general error handling | ||
- `thiserror` dependency: For defining specific error types | ||
- `Result` type: Used for functions that can fail | ||
|
||
### Tracing and Logging | ||
|
||
**Definition**: Tracing and logging are techniques for recording information about a program's execution for debugging and monitoring. | ||
|
||
**In Sidecar**: Tracing and logging are used to record information about the system's operation, errors, and performance. | ||
|
||
**Key Components**: | ||
- `tracing` dependency: For structured logging and tracing | ||
- `logging` crate: Custom logging utilities | ||
- `tracing_subscriber`: For configuring tracing output | ||
|
||
## Integration Concepts | ||
|
||
### Aide Editor Integration | ||
|
||
**Definition**: Aide is a code editor that integrates with Sidecar for AI-powered code assistance. | ||
|
||
**In Sidecar**: Sidecar provides API endpoints for the Aide editor to request AI assistance and receive responses. | ||
|
||
**Key Components**: | ||
- Webserver API endpoints | ||
- Request and response formats | ||
- Streaming response support | ||
|
||
### LLM Provider Integration | ||
|
||
**Definition**: LLM providers are services that offer access to large language models through APIs. | ||
|
||
**In Sidecar**: Sidecar integrates with multiple LLM providers to leverage their models for code understanding and generation. | ||
|
||
**Key Components**: | ||
- Provider-specific clients | ||
- API key management | ||
- Request and response formatting | ||
|
||
### Git Integration | ||
|
||
**Definition**: Git is a distributed version control system used for tracking changes in source code. | ||
|
||
**In Sidecar**: Sidecar integrates with Git to understand repository history, changes, and structure. | ||
|
||
**Key Components**: | ||
- `git` module: Contains Git-related functionality | ||
- `gix` dependency: Git implementation in Rust | ||
- Repository analysis based on Git history | ||
|
||
## Conclusion | ||
|
||
Understanding these key concepts and terminology will help you navigate the Sidecar codebase and contribute effectively to the project. If you encounter terms or concepts that are not explained here, please consider adding them to this document to help future contributors. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,11 @@ | ||
[workspace] | ||
members = [ | ||
"sidecar", | ||
"larp", | ||
"llm_client", | ||
"llm_prompts", | ||
"logging", | ||
] | ||
resolver = "2" | ||
|
||
[profile.release] | ||
lto = "thin" | ||
lto = "thin" |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,386 @@ | ||
# Sidecar Development Guide | ||
|
||
This document provides a comprehensive guide for developers who want to contribute to the Sidecar project. It covers setup, development workflows, testing, and best practices. | ||
|
||
## Table of Contents | ||
|
||
- [Development Environment Setup](#development-environment-setup) | ||
- [Project Structure](#project-structure) | ||
- [Development Workflow](#development-workflow) | ||
- [Testing](#testing) | ||
- [Debugging](#debugging) | ||
- [Code Style and Guidelines](#code-style-and-guidelines) | ||
- [Documentation](#documentation) | ||
- [Common Tasks](#common-tasks) | ||
- [Troubleshooting](#troubleshooting) | ||
|
||
## Development Environment Setup | ||
|
||
### Prerequisites | ||
|
||
- **Rust**: Version 1.79 or later | ||
- **Cargo**: Latest version compatible with your Rust installation | ||
- **Git**: For version control | ||
- **SQLite**: For database operations | ||
- **Tree-sitter**: For code parsing (installed automatically via Cargo) | ||
|
||
### Setup Steps | ||
|
||
1. **Clone the repository**: | ||
```bash | ||
git clone https://github.com/codestoryai/sidecar.git | ||
cd sidecar | ||
``` | ||
|
||
2. **Install Rust dependencies**: | ||
```bash | ||
rustup update | ||
rustup component add rustfmt | ||
``` | ||
|
||
3. **Build the project**: | ||
```bash | ||
cargo build | ||
``` | ||
|
||
4. **Run the webserver**: | ||
```bash | ||
cargo run --bin webserver | ||
``` | ||
|
||
### Environment Variables | ||
|
||
Sidecar uses environment variables for configuration. Here are the most important ones: | ||
|
||
- `OPENAI_API_KEY`: Your OpenAI API key | ||
- `ANTHROPIC_API_KEY`: Your Anthropic API key | ||
- `GOOGLE_AI_API_KEY`: Your Google AI API key | ||
- `SIDECAR_PORT`: Port for the webserver (default: 3000) | ||
- `SIDECAR_HOST`: Host for the webserver (default: 127.0.0.1) | ||
- `SIDECAR_LOG_LEVEL`: Log level (default: info) | ||
|
||
You can set these variables in your shell or create a `.env` file in the project root. | ||
|
||
## Project Structure | ||
|
||
Sidecar is organized as a Rust workspace with multiple crates: | ||
|
||
``` | ||
sidecar/ # Main crate with core functionality | ||
├── src/ # Source code | ||
│ ├── agentic/ # AI agent system | ||
│ ├── agent/ # Agent implementation | ||
│ ├── application/ # Application core | ||
│ ├── bin/ # Binary entry points | ||
│ ├── chunking/ # Code chunking and parsing | ||
│ ├── git/ # Git integration | ||
│ ├── llm/ # LLM integration | ||
│ ├── mcts/ # Monte Carlo Tree Search | ||
│ ├── repo/ # Repository management | ||
│ ├── repomap/ # Repository mapping | ||
│ ├── webserver/ # Web API | ||
│ └── lib.rs # Library entry point | ||
├── Cargo.toml # Crate manifest | ||
└── build.rs # Build script | ||
llm_client/ # LLM client crate | ||
├── src/ # Source code | ||
│ ├── clients/ # LLM provider clients | ||
│ ├── format/ # Request/response formatting | ||
│ ├── tokenizer/ # Token counting and management | ||
│ └── lib.rs # Library entry point | ||
└── Cargo.toml # Crate manifest | ||
llm_prompts/ # LLM prompt generation crate | ||
├── src/ # Source code | ||
│ ├── chat/ # Chat prompt generation | ||
│ ├── fim/ # Fill-in-middle prompt generation | ||
│ ├── in_line_edit/ # Inline editing prompt generation | ||
│ └── lib.rs # Library entry point | ||
└── Cargo.toml # Crate manifest | ||
logging/ # Logging utilities crate | ||
├── src/ # Source code | ||
│ └── lib.rs # Library entry point | ||
└── Cargo.toml # Crate manifest | ||
``` | ||
|
||
## Development Workflow | ||
|
||
### Feature Development | ||
|
||
1. **Create a new branch**: | ||
```bash | ||
git checkout -b feature/your-feature-name | ||
``` | ||
|
||
2. **Implement your changes**: | ||
- Make the necessary code changes | ||
- Add tests for your changes | ||
- Update documentation as needed | ||
|
||
3. **Run tests**: | ||
```bash | ||
cargo test | ||
``` | ||
|
||
4. **Format your code**: | ||
```bash | ||
cargo fmt | ||
``` | ||
|
||
5. **Commit your changes**: | ||
```bash | ||
git add . | ||
git commit -m "Add your feature description" | ||
``` | ||
|
||
6. **Push your branch**: | ||
```bash | ||
git push origin feature/your-feature-name | ||
``` | ||
|
||
7. **Create a pull request**: | ||
- Go to the GitHub repository | ||
- Click on "Pull Requests" and then "New Pull Request" | ||
- Select your branch and provide a description of your changes | ||
|
||
### Code Review Process | ||
|
||
1. **Automated checks**: | ||
- CI will run tests and linting on your PR | ||
- Address any issues reported by CI | ||
|
||
2. **Peer review**: | ||
- A maintainer will review your code | ||
- Address any feedback from the review | ||
|
||
3. **Approval and merge**: | ||
- Once approved, your PR will be merged | ||
- The branch will be deleted after merging | ||
|
||
## Testing | ||
|
||
### Running Tests | ||
|
||
```bash | ||
# Run all tests | ||
cargo test | ||
|
||
# Run tests for a specific crate | ||
cargo test -p sidecar | ||
|
||
# Run tests for a specific module | ||
cargo test -p sidecar -- agentic::symbol | ||
|
||
# Run a specific test | ||
cargo test -p sidecar -- agentic::symbol::test_symbol_manager | ||
``` | ||
|
||
### Writing Tests | ||
|
||
Tests should be placed in the same file as the code they're testing, using the `#[cfg(test)]` attribute: | ||
|
||
```rust | ||
#[cfg(test)] | ||
mod tests { | ||
use super::*; | ||
|
||
#[test] | ||
fn test_something() { | ||
// Test code here | ||
assert_eq!(2 + 2, 4); | ||
} | ||
} | ||
``` | ||
|
||
For integration tests, create files in the `tests/` directory of the respective crate. | ||
|
||
### Test Coverage | ||
|
||
You can generate test coverage reports using `cargo-tarpaulin`: | ||
|
||
```bash | ||
cargo install cargo-tarpaulin | ||
cargo tarpaulin -p sidecar | ||
``` | ||
|
||
## Debugging | ||
|
||
### Logging | ||
|
||
Sidecar uses the `tracing` crate for logging. You can control the log level using the `RUST_LOG` environment variable: | ||
|
||
```bash | ||
RUST_LOG=debug cargo run --bin webserver | ||
``` | ||
|
||
Log levels from most to least verbose: `trace`, `debug`, `info`, `warn`, `error`. | ||
|
||
### Debugging with VS Code | ||
|
||
1. Install the [Rust Analyzer](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust-analyzer) extension | ||
2. Create a `.vscode/launch.json` file with the following content: | ||
|
||
```json | ||
{ | ||
"version": "0.2.0", | ||
"configurations": [ | ||
{ | ||
"type": "lldb", | ||
"request": "launch", | ||
"name": "Debug webserver", | ||
"cargo": { | ||
"args": ["build", "--bin=webserver", "--package=sidecar"], | ||
"filter": { | ||
"name": "webserver", | ||
"kind": "bin" | ||
} | ||
}, | ||
"args": [], | ||
"cwd": "${workspaceFolder}" | ||
} | ||
] | ||
} | ||
``` | ||
|
||
3. Set breakpoints in your code | ||
4. Press F5 to start debugging | ||
|
||
## Code Style and Guidelines | ||
|
||
### Formatting | ||
|
||
Sidecar uses `rustfmt` for code formatting. Format your code before committing: | ||
|
||
```bash | ||
cargo fmt | ||
``` | ||
|
||
### Naming Conventions | ||
|
||
- **Types** (structs, enums, traits): `PascalCase` | ||
- **Variables and functions**: `snake_case` | ||
- **Constants**: `SCREAMING_SNAKE_CASE` | ||
- **Modules**: `snake_case` | ||
|
||
### Documentation | ||
|
||
All public items should be documented using rustdoc comments: | ||
|
||
```rust | ||
/// This function does something useful. | ||
/// | ||
/// # Arguments | ||
/// | ||
/// * `arg1` - The first argument | ||
/// * `arg2` - The second argument | ||
/// | ||
/// # Returns | ||
/// | ||
/// A result containing the output or an error | ||
/// | ||
/// # Examples | ||
/// | ||
/// ``` | ||
/// let result = do_something(1, 2); | ||
/// assert_eq!(result, Ok(3)); | ||
/// ``` | ||
pub fn do_something(arg1: i32, arg2: i32) -> Result<i32, Error> { | ||
// Implementation | ||
} | ||
``` | ||
|
||
### Error Handling | ||
|
||
Use the `anyhow` crate for error handling in most cases. For library code that needs to define specific error types, use `thiserror`. | ||
|
||
```rust | ||
// Using anyhow | ||
use anyhow::{Result, Context}; | ||
|
||
fn do_something() -> Result<()> { | ||
let file = std::fs::File::open("file.txt") | ||
.context("Failed to open file.txt")?; | ||
// More code... | ||
Ok(()) | ||
} | ||
|
||
// Using thiserror | ||
use thiserror::Error; | ||
|
||
#[derive(Error, Debug)] | ||
pub enum MyError { | ||
#[error("IO error: {0}")] | ||
Io(#[from] std::io::Error), | ||
|
||
#[error("Invalid value: {0}")] | ||
InvalidValue(String), | ||
} | ||
``` | ||
|
||
## Documentation | ||
|
||
### Generating Documentation | ||
|
||
You can generate and view the API documentation locally: | ||
|
||
```bash | ||
cargo doc --open | ||
``` | ||
|
||
### Writing Documentation | ||
|
||
- Document all public items (functions, structs, enums, traits) | ||
- Include examples where appropriate | ||
- Explain the purpose and behavior of each item | ||
- Document error conditions and return values | ||
|
||
## Common Tasks | ||
|
||
### Adding a New LLM Provider | ||
|
||
1. Create a new file in `llm_client/src/clients/` for your provider | ||
2. Implement the `LLMClient` trait for your provider | ||
3. Add your provider to the `LLMType` enum in `llm_client/src/clients/types.rs` | ||
4. Register your provider in the `LLMBroker::new()` method in `llm_client/src/broker.rs` | ||
|
||
### Adding a New Language Parser | ||
|
||
1. Add the tree-sitter grammar dependency to `sidecar/Cargo.toml` | ||
2. Create a new file in `sidecar/src/chunking/` for your language | ||
3. Implement the parsing logic for your language | ||
4. Register your language in `sidecar/src/chunking/languages.rs` | ||
|
||
### Adding a New Tool | ||
|
||
1. Create a new file in `sidecar/src/agentic/tool/` for your tool | ||
2. Implement the `Tool` trait for your tool | ||
3. Register your tool in the `ToolBox::new()` method in `sidecar/src/agentic/symbol/tool_box.rs` | ||
|
||
## Troubleshooting | ||
|
||
### Common Issues | ||
|
||
#### Build Failures | ||
|
||
- **Missing dependencies**: Make sure you have all required system dependencies installed | ||
- **Incompatible Rust version**: Ensure you're using Rust 1.79 or later | ||
- **Cargo.lock conflicts**: Try running `cargo clean` and then `cargo build` | ||
|
||
#### Runtime Errors | ||
|
||
- **API key issues**: Check that you've set the required API keys as environment variables | ||
- **Port conflicts**: If the port is already in use, change it using the `SIDECAR_PORT` environment variable | ||
- **Database errors**: Check that SQLite is installed and working correctly | ||
|
||
### Getting Help | ||
|
||
If you're stuck, you can get help from the community: | ||
|
||
- **GitHub Issues**: Search existing issues or create a new one | ||
- **Discord**: Join our [Discord server](https://discord.gg/mtgrhXM5Xf) for real-time help | ||
|
||
## Conclusion | ||
|
||
This development guide should help you get started with contributing to Sidecar. If you have any questions or suggestions for improving this guide, please open an issue or pull request. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,340 @@ | ||
# Sidecar Features and Capabilities | ||
|
||
This document provides a comprehensive overview of the features and capabilities of Sidecar, the AI intelligence engine that powers the Aide code editor. | ||
|
||
## Table of Contents | ||
|
||
- [AI-Powered Code Assistance](#ai-powered-code-assistance) | ||
- [Code Understanding](#code-understanding) | ||
- [Repository Analysis](#repository-analysis) | ||
- [Language Support](#language-support) | ||
- [LLM Integration](#llm-integration) | ||
- [Agentic Tools](#agentic-tools) | ||
- [Decision Making](#decision-making) | ||
- [User Interaction](#user-interaction) | ||
- [Performance Optimizations](#performance-optimizations) | ||
- [Security Features](#security-features) | ||
|
||
## AI-Powered Code Assistance | ||
|
||
### Code Editing | ||
|
||
Sidecar provides AI-powered code editing capabilities that help developers write, modify, and refactor code more efficiently. | ||
|
||
**Key Features:** | ||
- **Smart Code Completion**: Context-aware code completion that understands the codebase | ||
- **Code Refactoring**: Intelligent refactoring suggestions and implementations | ||
- **Bug Fixing**: Identification and correction of bugs and issues | ||
- **Code Generation**: Generation of new code based on natural language descriptions | ||
|
||
### Code Explanation | ||
|
||
Sidecar can explain code to help developers understand complex or unfamiliar code more quickly. | ||
|
||
**Key Features:** | ||
- **Function Explanation**: Detailed explanations of function behavior and purpose | ||
- **Algorithm Explanation**: Descriptions of algorithms and their implementation | ||
- **Code Flow Analysis**: Analysis of code execution flow and logic | ||
- **Documentation Generation**: Automatic generation of documentation from code | ||
|
||
### Code Review | ||
|
||
Sidecar can assist with code reviews by identifying issues, suggesting improvements, and providing feedback. | ||
|
||
**Key Features:** | ||
- **Issue Detection**: Identification of potential bugs, performance issues, and security vulnerabilities | ||
- **Style Checking**: Verification of code style and consistency | ||
- **Best Practice Suggestions**: Recommendations for following best practices | ||
- **Improvement Suggestions**: Ideas for improving code quality and maintainability | ||
|
||
## Code Understanding | ||
|
||
### Symbol Analysis | ||
|
||
Sidecar analyzes code symbols (functions, classes, variables, etc.) to understand their purpose, behavior, and relationships. | ||
|
||
**Key Features:** | ||
- **Symbol Extraction**: Identification and extraction of symbols from code | ||
- **Symbol Relationship Mapping**: Analysis of relationships between symbols | ||
- **Symbol Usage Analysis**: Tracking of symbol usage throughout the codebase | ||
- **Symbol Documentation**: Generation of documentation for symbols | ||
|
||
### Semantic Analysis | ||
|
||
Sidecar performs semantic analysis to understand the meaning and intent of code beyond its syntax. | ||
|
||
**Key Features:** | ||
- **Type Inference**: Determination of variable and expression types | ||
- **Control Flow Analysis**: Analysis of code execution paths | ||
- **Data Flow Analysis**: Tracking of data movement through the code | ||
- **Intent Recognition**: Understanding the purpose and intent of code sections | ||
|
||
### Context Awareness | ||
|
||
Sidecar maintains context awareness to provide more relevant and accurate assistance. | ||
|
||
**Key Features:** | ||
- **File Context**: Understanding of the current file and its purpose | ||
- **Project Context**: Awareness of the overall project structure and goals | ||
- **User Context**: Adaptation to user preferences and work patterns | ||
- **Historical Context**: Consideration of previous interactions and changes | ||
|
||
## Repository Analysis | ||
|
||
### Repository Mapping | ||
|
||
Sidecar maps the structure and relationships within a code repository to provide better context for AI operations. | ||
|
||
**Key Features:** | ||
- **File Relationship Analysis**: Identification of relationships between files | ||
- **Dependency Mapping**: Analysis of import and dependency relationships | ||
- **Module Structure Analysis**: Understanding of the module and package structure | ||
- **Architecture Visualization**: Visual representation of the codebase architecture | ||
|
||
### PageRank-Based Importance Scoring | ||
|
||
Sidecar uses a PageRank-like algorithm to identify important symbols and files in the codebase. | ||
|
||
**Key Features:** | ||
- **Symbol Importance Scoring**: Ranking of symbols by their importance in the codebase | ||
- **File Importance Scoring**: Ranking of files by their importance in the codebase | ||
- **Relevance Determination**: Identification of code relevant to specific queries or tasks | ||
- **Focus Prioritization**: Prioritization of important code sections for analysis | ||
|
||
### Git Integration | ||
|
||
Sidecar integrates with Git to understand repository history and changes. | ||
|
||
**Key Features:** | ||
- **Commit History Analysis**: Analysis of commit history and patterns | ||
- **Change Tracking**: Tracking of changes to specific files and symbols | ||
- **Author Attribution**: Identification of code authors and contributors | ||
- **Branch Analysis**: Understanding of branch structure and purpose | ||
|
||
## Language Support | ||
|
||
### Multi-Language Parsing | ||
|
||
Sidecar supports parsing and understanding of multiple programming languages. | ||
|
||
**Supported Languages:** | ||
- **Rust**: Full support for Rust syntax and semantics | ||
- **Python**: Comprehensive Python language support | ||
- **JavaScript/TypeScript**: Support for JavaScript and TypeScript | ||
- **Go**: Go language parsing and analysis | ||
|
||
### Language-Specific Features | ||
|
||
Sidecar provides language-specific features tailored to the characteristics and idioms of each supported language. | ||
|
||
**Key Features:** | ||
- **Rust**: Ownership and borrowing analysis, trait understanding | ||
- **Python**: Type hint analysis, decorator understanding | ||
- **JavaScript/TypeScript**: Type inference, async/await analysis | ||
- **Go**: Interface implementation checking, goroutine analysis | ||
|
||
### Extensible Language Support | ||
|
||
Sidecar's language support is designed to be extensible, allowing for the addition of new languages. | ||
|
||
**Key Features:** | ||
- **Language Parser Interface**: Common interface for language parsers | ||
- **Tree-sitter Integration**: Use of Tree-sitter for efficient parsing | ||
- **Language Configuration**: Configurable language settings | ||
- **Custom Language Rules**: Support for custom language-specific rules | ||
|
||
## LLM Integration | ||
|
||
### Multi-Provider Support | ||
|
||
Sidecar integrates with multiple LLM providers to leverage their models for code understanding and generation. | ||
|
||
**Supported Providers:** | ||
- **OpenAI**: Integration with GPT models | ||
- **Anthropic**: Support for Claude models | ||
- **Google AI**: Integration with Gemini models | ||
- **Open-Source Models**: Support for various open-source models via Ollama, LM Studio, etc. | ||
|
||
### Provider-Specific Optimizations | ||
|
||
Sidecar includes optimizations for specific LLM providers to maximize their effectiveness. | ||
|
||
**Key Features:** | ||
- **Prompt Engineering**: Provider-specific prompt templates and strategies | ||
- **Token Optimization**: Efficient use of tokens for each provider | ||
- **Model Selection**: Intelligent selection of appropriate models | ||
- **Parameter Tuning**: Optimization of request parameters | ||
|
||
### Fallback Mechanisms | ||
|
||
Sidecar includes fallback mechanisms to handle provider failures or limitations. | ||
|
||
**Key Features:** | ||
- **Provider Failover**: Automatic switching to alternative providers | ||
- **Graceful Degradation**: Reduced functionality when optimal providers are unavailable | ||
- **Error Recovery**: Recovery from provider errors and limitations | ||
- **Offline Capabilities**: Basic functionality without LLM access | ||
|
||
## Agentic Tools | ||
|
||
### Tool Selection | ||
|
||
Sidecar's agentic system can select appropriate tools for specific tasks. | ||
|
||
**Key Features:** | ||
- **Task Analysis**: Analysis of tasks to determine required tools | ||
- **Tool Matching**: Matching of tasks to appropriate tools | ||
- **Tool Composition**: Combination of multiple tools for complex tasks | ||
- **Tool Adaptation**: Adaptation of tools to specific contexts | ||
|
||
### Tool Execution | ||
|
||
Sidecar can execute tools to perform specific operations. | ||
|
||
**Key Features:** | ||
- **Parameter Determination**: Intelligent determination of tool parameters | ||
- **Execution Monitoring**: Monitoring of tool execution | ||
- **Result Processing**: Processing and interpretation of tool results | ||
- **Error Handling**: Handling of tool execution errors | ||
|
||
### Available Tools | ||
|
||
Sidecar includes a variety of tools for different operations. | ||
|
||
**Key Tools:** | ||
- **Code Editing Tools**: Tools for modifying code | ||
- **Symbol Analysis Tools**: Tools for analyzing code symbols | ||
- **Repository Search Tools**: Tools for searching the repository | ||
- **Context Gathering Tools**: Tools for gathering relevant context | ||
|
||
## Decision Making | ||
|
||
### Monte Carlo Tree Search | ||
|
||
Sidecar uses Monte Carlo Tree Search (MCTS) to explore possible code changes and select the most promising ones. | ||
|
||
**Key Features:** | ||
- **Action Space Exploration**: Exploration of possible actions | ||
- **Value Estimation**: Estimation of action values | ||
- **Selection Strategy**: Intelligent selection of actions to explore | ||
- **Execution Planning**: Planning of action execution | ||
|
||
### Feedback-Based Learning | ||
|
||
Sidecar can learn from feedback to improve its decision making. | ||
|
||
**Key Features:** | ||
- **User Feedback Processing**: Processing of explicit user feedback | ||
- **Implicit Feedback Analysis**: Analysis of implicit feedback from user actions | ||
- **Preference Learning**: Learning of user preferences | ||
- **Adaptation**: Adaptation to user preferences and patterns | ||
|
||
### Multi-Step Planning | ||
|
||
Sidecar can plan and execute multi-step operations. | ||
|
||
**Key Features:** | ||
- **Task Decomposition**: Breaking down complex tasks into steps | ||
- **Step Sequencing**: Determining the optimal sequence of steps | ||
- **Dependency Management**: Handling dependencies between steps | ||
- **Progress Tracking**: Tracking progress through multi-step plans | ||
|
||
## User Interaction | ||
|
||
### Natural Language Understanding | ||
|
||
Sidecar can understand and process natural language queries and instructions. | ||
|
||
**Key Features:** | ||
- **Query Parsing**: Parsing and understanding of user queries | ||
- **Intent Recognition**: Identification of user intent | ||
- **Context Incorporation**: Incorporation of context into query understanding | ||
- **Ambiguity Resolution**: Resolution of ambiguous queries | ||
|
||
### Response Generation | ||
|
||
Sidecar generates natural language responses to user queries. | ||
|
||
**Key Features:** | ||
- **Clear Explanations**: Generation of clear and concise explanations | ||
- **Code Examples**: Inclusion of relevant code examples | ||
- **Contextual References**: References to relevant code and documentation | ||
- **Follow-up Suggestions**: Suggestions for follow-up queries or actions | ||
|
||
### Interactive Sessions | ||
|
||
Sidecar supports interactive sessions for ongoing user interaction. | ||
|
||
**Key Features:** | ||
- **Session State Management**: Maintenance of session state | ||
- **Context Retention**: Retention of context across interactions | ||
- **Conversation History**: Tracking of conversation history | ||
- **Session Persistence**: Persistence of sessions across restarts | ||
|
||
## Performance Optimizations | ||
|
||
### Token Usage Optimization | ||
|
||
Sidecar optimizes token usage to reduce costs and improve performance. | ||
|
||
**Key Features:** | ||
- **Context Pruning**: Removal of irrelevant context | ||
- **Chunking**: Breaking large content into manageable chunks | ||
- **Compression**: Compression of context information | ||
- **Prioritization**: Prioritization of important content | ||
|
||
### Caching | ||
|
||
Sidecar uses caching to improve performance and reduce redundant operations. | ||
|
||
**Key Features:** | ||
- **Response Caching**: Caching of LLM responses | ||
- **Analysis Caching**: Caching of code analysis results | ||
- **Repository Caching**: Caching of repository information | ||
- **Invalidation Strategies**: Intelligent cache invalidation | ||
|
||
### Parallel Processing | ||
|
||
Sidecar uses parallel processing for computationally intensive operations. | ||
|
||
**Key Features:** | ||
- **Multi-threading**: Use of multiple threads for parallel operations | ||
- **Asynchronous Processing**: Non-blocking asynchronous operations | ||
- **Work Distribution**: Intelligent distribution of work | ||
- **Resource Management**: Efficient management of system resources | ||
|
||
## Security Features | ||
|
||
### API Key Management | ||
|
||
Sidecar securely manages API keys for various services. | ||
|
||
**Key Features:** | ||
- **Secure Storage**: Secure storage of API keys | ||
- **Access Control**: Controlled access to API keys | ||
- **Key Rotation**: Support for key rotation | ||
- **Minimal Exposure**: Minimization of key exposure | ||
|
||
Comment on lines
+308
to
+317
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Err pretty sure we don't do this as well ... Key rotation is not something sidecar should be worried about There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @theskcd oh yess im sorry let me delete features and roadmap lol, they are irrelevant at all |
||
### Code Safety | ||
|
||
Sidecar includes features to ensure the safety of code operations. | ||
|
||
**Key Features:** | ||
- **Path Validation**: Validation of file paths | ||
- **Operation Limits**: Limits on potentially dangerous operations | ||
- **Input Sanitization**: Sanitization of user input | ||
- **Permission Checking**: Checking of operation permissions | ||
|
||
### Privacy Protection | ||
|
||
Sidecar includes features to protect user privacy. | ||
|
||
**Key Features:** | ||
- **Data Minimization**: Minimization of data sent to external services | ||
- **Local Processing**: Local processing when possible | ||
- **Anonymization**: Anonymization of sensitive information | ||
- **Transparency**: Transparency about data usage | ||
|
||
## Conclusion | ||
|
||
Sidecar provides a comprehensive set of features and capabilities for AI-powered code assistance. Its modular architecture, extensible design, and focus on performance and security make it a powerful tool for developers working with the Aide editor. |
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,261 @@ | ||
# Sidecar Project Roadmap | ||
|
||
This document outlines the future direction and planned enhancements for the Sidecar project. | ||
|
||
## Current Status | ||
|
||
Sidecar is currently a functional AI-powered code assistant that integrates with the Aide editor. It provides capabilities for: | ||
|
||
- Code understanding and analysis | ||
- AI-assisted code editing | ||
- Repository mapping and context gathering | ||
- Multi-language support (Rust, Python, JavaScript/TypeScript, Go) | ||
- Integration with multiple LLM providers | ||
|
||
## Short-Term Goals (0-3 months) | ||
|
||
```mermaid | ||
gantt | ||
title Short-Term Goals | ||
dateFormat YYYY-MM-DD | ||
section Performance | ||
Optimize repository mapping algorithm :a1, 2024-04-01, 30d | ||
Improve token usage efficiency :a2, after a1, 30d | ||
Enhance response streaming :a3, 2024-04-15, 30d | ||
section Features | ||
Add support for more languages :b1, 2024-04-01, 45d | ||
Implement code health metrics :b2, 2024-04-15, 30d | ||
Create documentation generator :b3, after b2, 30d | ||
section User Experience | ||
Improve error handling and reporting :c1, 2024-04-01, 30d | ||
Enhance configuration options :c2, after c1, 30d | ||
Add user feedback mechanisms :c3, 2024-05-01, 30d | ||
``` | ||
|
||
### Performance Improvements | ||
|
||
1. **Optimize Repository Mapping Algorithm** | ||
- Improve the efficiency of the PageRank algorithm for large codebases | ||
- Implement incremental updates to avoid full re-indexing | ||
- Add caching mechanisms for frequently accessed symbols | ||
|
||
2. **Improve Token Usage Efficiency** | ||
- Enhance context pruning to reduce token usage | ||
- Implement smarter chunking strategies for large files | ||
- Optimize prompt templates for different LLM providers | ||
|
||
3. **Enhance Response Streaming** | ||
- Reduce latency in streaming responses | ||
- Implement partial result processing | ||
- Add progress indicators for long-running operations | ||
|
||
### Feature Enhancements | ||
|
||
1. **Add Support for More Languages** | ||
- Add support for Java, C#, and PHP | ||
- Improve existing language parsers | ||
- Create a plugin system for language-specific features | ||
|
||
2. **Implement Code Health Metrics** | ||
- Add code complexity analysis | ||
- Implement duplicate code detection | ||
- Create visualizations for code health metrics | ||
|
||
3. **Create Documentation Generator** | ||
- Automatically generate documentation from code | ||
- Support multiple documentation formats (Markdown, JSDoc, etc.) | ||
- Integrate with existing documentation tools | ||
|
||
### User Experience Improvements | ||
|
||
1. **Improve Error Handling and Reporting** | ||
- Enhance error messages with actionable information | ||
- Implement error recovery mechanisms | ||
- Add detailed logging for troubleshooting | ||
|
||
2. **Enhance Configuration Options** | ||
- Create a unified configuration system | ||
- Add support for project-specific configurations | ||
- Implement configuration validation | ||
|
||
3. **Add User Feedback Mechanisms** | ||
- Implement thumbs up/down feedback for AI responses | ||
- Create a system for collecting and analyzing user feedback | ||
- Use feedback to improve AI responses over time | ||
|
||
## Medium-Term Goals (3-6 months) | ||
|
||
```mermaid | ||
gantt | ||
title Medium-Term Goals | ||
dateFormat YYYY-MM-DD | ||
section Intelligence | ||
Enhance MCTS decision making :d1, 2024-07-01, 45d | ||
Implement learning from user feedback :d2, after d1, 45d | ||
Add multi-step planning capabilities :d3, 2024-08-01, 45d | ||
section Integration | ||
Expand IDE integration options :e1, 2024-07-01, 30d | ||
Add CI/CD integration :e2, after e1, 30d | ||
Create API for external tools :e3, 2024-08-15, 45d | ||
section Collaboration | ||
Implement multi-user collaboration :f1, 2024-07-15, 60d | ||
Add team knowledge sharing :f2, after f1, 45d | ||
Create project-specific memory :f3, 2024-09-01, 30d | ||
``` | ||
|
||
### Intelligence Enhancements | ||
|
||
1. **Enhance MCTS Decision Making** | ||
- Improve action selection algorithms | ||
- Implement more sophisticated value functions | ||
- Add support for parallel exploration | ||
|
||
2. **Implement Learning from User Feedback** | ||
- Create a system for learning from user edits | ||
- Implement preference learning from feedback | ||
- Add personalization based on user behavior | ||
|
||
3. **Add Multi-Step Planning Capabilities** | ||
- Implement hierarchical planning | ||
- Add support for complex refactoring operations | ||
- Create visualization tools for plans | ||
|
||
### Integration Improvements | ||
|
||
1. **Expand IDE Integration Options** | ||
- Add support for more code editors (VS Code, JetBrains IDEs) | ||
- Implement deeper integration with editor features | ||
- Create a standardized protocol for editor communication | ||
|
||
2. **Add CI/CD Integration** | ||
- Implement integration with popular CI/CD systems | ||
- Add support for automated code reviews | ||
- Create tools for test generation and validation | ||
|
||
3. **Create API for External Tools** | ||
- Design and implement a public API | ||
- Create documentation and examples | ||
- Build a plugin system for extending functionality | ||
|
||
### Collaboration Features | ||
|
||
1. **Implement Multi-User Collaboration** | ||
- Add support for real-time collaboration | ||
- Implement conflict resolution mechanisms | ||
- Create tools for sharing context between users | ||
|
||
2. **Add Team Knowledge Sharing** | ||
- Implement team-specific knowledge bases | ||
- Create tools for sharing insights between team members | ||
- Add support for organizational knowledge | ||
|
||
3. **Create Project-Specific Memory** | ||
- Implement long-term memory for projects | ||
- Add support for project-specific preferences | ||
- Create tools for knowledge transfer between projects | ||
|
||
## Long-Term Vision (6+ months) | ||
|
||
```mermaid | ||
mindmap | ||
root((Long-Term Vision)) | ||
Autonomous Development Assistant | ||
Self-improving capabilities | ||
Proactive code maintenance | ||
Autonomous bug fixing | ||
Advanced Intelligence | ||
Multi-agent collaboration | ||
Domain-specific expertise | ||
Contextual understanding | ||
Ecosystem Integration | ||
Full development lifecycle | ||
Cross-tool coordination | ||
Knowledge graph integration | ||
Enterprise Features | ||
Compliance and security | ||
Custom model training | ||
Enterprise knowledge base | ||
``` | ||
|
||
### Autonomous Development Assistant | ||
|
||
- **Self-Improving Capabilities**: Implement systems that learn from interactions and improve over time | ||
- **Proactive Code Maintenance**: Develop features that proactively suggest improvements and fixes | ||
- **Autonomous Bug Fixing**: Create capabilities for automatically identifying and fixing common bugs | ||
|
||
### Advanced Intelligence | ||
|
||
- **Multi-Agent Collaboration**: Implement systems where multiple specialized agents work together | ||
- **Domain-Specific Expertise**: Develop expertise in specific domains (web development, data science, etc.) | ||
- **Contextual Understanding**: Enhance understanding of project context, business logic, and requirements | ||
|
||
### Ecosystem Integration | ||
|
||
- **Full Development Lifecycle**: Integrate with all aspects of the development lifecycle | ||
- **Cross-Tool Coordination**: Enable coordination between different development tools | ||
- **Knowledge Graph Integration**: Create a comprehensive knowledge graph of code, documentation, and discussions | ||
|
||
### Enterprise Features | ||
|
||
- **Compliance and Security**: Add features for ensuring code compliance and security | ||
- **Custom Model Training**: Provide tools for training custom models on proprietary codebases | ||
- **Enterprise Knowledge Base**: Create an enterprise-wide knowledge base for code and best practices | ||
|
||
## Community Roadmap | ||
|
||
```mermaid | ||
gantt | ||
title Community Roadmap | ||
dateFormat YYYY-MM-DD | ||
section Community | ||
Improve documentation :g1, 2024-04-01, 30d | ||
Create contributor guides :g2, after g1, 30d | ||
Implement community feedback system :g3, 2024-05-15, 45d | ||
section Open Source | ||
Enhance plugin system :h1, 2024-06-01, 45d | ||
Create extension marketplace :h2, after h1, 60d | ||
Implement community governance :h3, 2024-08-01, 90d | ||
``` | ||
|
||
### Community Building | ||
|
||
1. **Improve Documentation** | ||
- Enhance user and developer documentation | ||
- Create tutorials and examples | ||
- Add interactive documentation | ||
|
||
2. **Create Contributor Guides** | ||
- Develop comprehensive guides for contributors | ||
- Create templates for common contributions | ||
- Implement mentoring programs for new contributors | ||
|
||
3. **Implement Community Feedback System** | ||
- Create tools for gathering community feedback | ||
- Implement transparent feature voting | ||
- Develop a roadmap influenced by community needs | ||
|
||
### Open Source Development | ||
|
||
1. **Enhance Plugin System** | ||
- Create a robust plugin architecture | ||
- Develop tools for plugin development | ||
- Implement plugin testing and validation | ||
|
||
2. **Create Extension Marketplace** | ||
- Build a marketplace for community extensions | ||
- Implement rating and review systems | ||
- Create tools for discovering useful extensions | ||
|
||
3. **Implement Community Governance** | ||
- Develop transparent governance processes | ||
- Create systems for community decision-making | ||
- Implement open planning and prioritization | ||
|
||
## Conclusion | ||
|
||
This roadmap outlines the planned direction for the Sidecar project, but it is subject to change based on user feedback, technological advancements, and community contributions. We welcome input from the community to help shape the future of Sidecar. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,4 @@ | ||
//! Contains the helper functions for git related operations on the repo | ||
pub(crate) mod diff_client; | ||
pub(crate) mod edited_files; | ||
pub(crate) mod operation_id; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
//! Utility functions for extracting operation IDs from PR content | ||
/// Extracts operation ID from PR description or title | ||
/// Returns None if no operation ID is found | ||
pub fn extract_operation_id(content: &str) -> Option<String> { | ||
// Common patterns for operation IDs in PR titles or descriptions | ||
let patterns = [ | ||
// Look for explicit operation ID format: "operation_id: XXX" or "operationId: XXX" | ||
r"operation[_\s]?[iI]d:\s*([a-zA-Z0-9_-]+)", | ||
// Look for operation ID in brackets: [XXX] | ||
r"\[([a-zA-Z0-9_-]+)\]", | ||
// Look for operation ID in parentheses: (XXX) | ||
r"\(([a-zA-Z0-9_-]+)\)", | ||
// Look for operation ID with prefix: op-XXX | ||
r"op-([a-zA-Z0-9_-]+)", | ||
]; | ||
|
||
for pattern in patterns { | ||
if let Some(captures) = regex::Regex::new(pattern).ok()?.captures(content) { | ||
if let Some(id) = captures.get(1) { | ||
return Some(id.as_str().to_string()); | ||
} | ||
} | ||
} | ||
|
||
None | ||
} |
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am pretty sure we don't do this anymore ...