## Architecture Overview: The Self-Hosted Model
The entire application will be packaged as a Dockerized service that the client runs on their
own infrastructure. It will consist of a backend server, a local vector database, and scripts for
indexing and running the AI agents. The client controls everything.
## Module 1: Local Codebase Indexing Engine
This module runs as a one-time command-line script to read and understand the codebase
locally.
● Step 1: Point to Local Repository
○ The client configures the application with the local filesystem path to their
codebase (e.g., /home/dev/my-project). There's no need to clone from a remote
source, as it's already on their machine.
● Step 2: Local Parsing & Chunking
○ The script recursively scans the provided directory.
○ Using Abstract Syntax Tree (AST) parsers, it breaks down the code into logical
chunks (functions, classes).
● Step 3: Local Vector Embedding
○ The client has two choices for generating embeddings, configured via a settings file:
■ Option A (Cloud Embedding): Use an API key for a service like OpenAI. The
code chunk is sent for embedding, but the code itself is never stored on an
external server.
■ Option B (Fully Local Embedding): Use a local, open-source embedding model
(e.g., from Hugging Face). This requires more local resources but guarantees
zero data leaves the client's machine.
● Step 4: Store in an Embedded Vector Database
○ The vectors and code metadata are stored in a file-based vector database like
ChromaDB or LanceDB. This database lives as a folder right alongside the
application on the client's machine. No separate database server is needed.
○ Result: A project.db file is created, containing the entire "knowledge" of the
codebase, fully private and local.
## Module 2: Client-Side Feedback Collector
The JS widget remains on the client's website, but its destination changes.
● Step 1: Configure the Endpoint
○ When the client installs the self-hosted AutoPR server, it exposes an API endpoint on
their local network (e.g., http://localhost:8000/report-bug or
http://internal-dev-server/report-bug).
○ The client customizes the JS widget snippet to point to their own hosted endpoint.
● Step 2: Capture and Send Locally
○ The widget's functionality is the same: it captures user feedback, console logs, and
network data.
○ It then sends this data payload directly to the client's own local AutoPR server.
## Module 3: Local Agentic AI Core
This is the "brain," now running completely inside the client's environment. The client chooses
their preferred AI model via configuration.
● Step 1: Triage & Diagnosis Agent (Local)
○ The local server receives the bug report data.
○ It uses an LLM to perform the analysis. The client configures which LLM to use:
■ Mode A (API-Based LLMs - "Bring Your Own Key"): The client provides their
API key for OpenAI (GPT-4o), Anthropic (Claude 3), or Google (Gemini). The
agent sends the bug data and relevant code snippets to the API for analysis and
code generation. This offers peak performance with easy setup.
■ Mode B (Fully Local LLMs - "Ultimate Privacy"): The client runs a local LLM
like Llama 3 or Code Llama using a tool like Ollama. The AutoPR application
sends its requests to http://localhost:11434 (Ollama's default address). This
requires a machine with a powerful GPU but ensures no code or bug data ever
leaves the local network.
● Step 2: Code Generation Agent (Local)
○ Based on the chosen mode (API or Local LLM), the agent takes the bug analysis and
the retrieved code chunks from the local vector DB.
○ It prompts the configured LLM to generate the code fix.
○ Result: A corrected block of code is generated entirely under the client's control.
## Module 4: Local DevOps & PR Automation Bot
This module now functions like a developer's personal command-line assistant, using local
tools.
● Step 1: Use Local Git Credentials
○ The application uses the git command-line tool that's already installed and
configured on the client's machine or server. It automatically uses the client's existing
Git name, email, and authentication.
● Step 2: Local Git Operations
○ The bot runs standard Git commands directly in the local repository folder:
1. git pull (to ensure it's up-to-date)
2. git checkout -b fix/auto-pr-login-bug-123
3. It modifies the necessary file(s) with the AI-generated code.
4. git add .
5. git commit -m "fix(AI): Resolve login button issue"
● Step 3: Push and Create PR
○ It runs git push origin fix/auto-pr-login-bug-123.
○ Finally, it uses a GitHub CLI tool (gh) or a simple API call to open the pull request,
populating it with the AI-generated analysis.
○ Result: A pull request appears in the client's GitHub repository, created as if the
developer did it themselves from their own terminal.
