AI Hub: Interactive Coding Assistant

The goal of this project is to extend the existing AI Hub with an interactive coding assistant. This assistant will enable an AI to directly "work" on a user's local codebase, allowing it to understand, debug, and modify a project's files by communicating with a lightweight client running on the user's machine.

This is a significant step beyond a traditional RESTful API, as it allows for real-time, bi-directional communication, which is essential for the dynamic, back-and-forth nature of a coding session.

Core Components

The project is built on two main components that communicate over a WebSocket (WSS) connection:

AI Hub (Server): The central brain of the operation. This is your existing FastAPI application, which will be extended to include WebSocket endpoints. The server's primary responsibilities are:
- Maintaining the WSS connection with the client.
- Using a Large Language Model (LLM) to reason about a user's coding problem.
- Sending structured commands to the client (e.g., "read this file," "execute this command").
- Receiving and processing command output from the client.
- Generating file changes or new commands based on the current project state.
Local Client: A new, lightweight application that runs on the user's machine. Its sole purpose is to act as a secure, local intermediary. Its responsibilities are:
- Establishing and maintaining the WSS connection to the AI Hub.
- Security: Enforcing a strict sandbox, ensuring the AI can only interact with the user-selected project directory.
- Reading file contents and sending them to the server.
- Executing shell commands and sending the output back to the server.
- Receiving and applying file modifications from the server.

Communication Protocol

A clear, robust communication schema is the foundation of this project. All communication over the WebSocket will be a JSON object with a consistent structure, using a type to identify the command and a request_id to link a request to its response.

Server-to-Client Commands

These are the commands the AI Hub sends to the local client.

`type`	Description	Payload
`list_files`	Requests a list of files and folders in a specified directory.	`{"path": "./"}`
`read_files`	Requests the content of one or more specific files.	`{"files": ["src/main.py", "tests/test.py"]}`
`execute_command`	Instructs the client to execute a shell command in the project root directory.	`{"command": "npm test"}`
`write_file`	Instructs the client to overwrite a specific file with new content.	`{"path": "src/main.py", "content": "new code..."}`

Client-to-Server Responses

These are the responses the local client sends back to the AI Hub. All responses must include the original request_id.

`type`	Description	Payload
`list_files_response`	Returns a list of files and folders.	`{"status": "success", "files": [{"name": "...", "is_dir": true}]}`
`read_files_response`	Returns the content of the requested files.	`{"status": "success", "files": {"path": "content"}}`
`command_output`	Returns the `stdout` and `stderr` from the executed command.	`{"status": "success", "stdout": "...", "stderr": "..."}`
`write_file_response`	Confirms if a file was successfully written or returns an error.	`{"status": "success"}`

In the event of an error (e.g., a file not found), the client will always return a status: "error" in the payload, along with a human-readable error_message.

Kickoff Plan

We can tackle this project in three phases to ensure a solid foundation.

Phase 1: Establish the Connection

Server: Create the new workspace.py route file and define a basic websocket endpoint.
Client: Build a minimal proof-of-concept client (e.g., a Python or Node.js script) that can connect to the server's WebSocket endpoint.
Goal: Successfully send a "ping" from the client and receive a "pong" from the server.

Phase 2: Implement Core Functionality

Server: Define the logic for handling incoming client messages (command_output, etc.) and for sending commands to the client.
Client: Implement the message handlers for list_files, read_files, and execute_command. This client must include robust file system checks to prevent access outside the designated directory.
Goal: The server can successfully send a list_files command to the client, receive a list of files, and then send a read_files command for one of those files.

Phase 3: Integrate and Secure

Server: Integrate the new WebSocket communication layer with your existing LLM and RAG pipelines. The LLM's output should be formatted as one of the structured commands.
Client: Implement security features like command validation and a user confirmation UI for potentially destructive commands (e.g., rm).
Goal: A user can initiate a conversation with the AI, the AI can ask for a file list and file content, and the client can provide it, all without manual intervention.