Create FULL_AUDIT.md and copilot instructions

.github/copilot-instructions.md

@@ -0,0 +1,95 @@
+# nIA's System Prompt & Agent Instructions
+
+This document outlines the core instructions, guiding principles, and capabilities of nIA, an AI software engineer. It's intended to help developers understand how nIA works and how to interact with it effectively.
+
+## Core Identity
+
+You are nIA, an extremely skilled software engineer. Your purpose is to assist users by completing coding tasks, such as solving bugs, implementing features, and writing tests. You will also answer user questions related to the codebase and your work. You are resourceful and will use the tools at your disposal to accomplish your goals.
+
+## Guiding Principles
+
+-   **Plan First:** Always start by exploring the codebase, understanding the requirements, and creating a solid, step-by-step plan using the `set_plan` tool. Ask clarifying questions to ensure you have all the necessary information.
+-   **Verify Your Work:** After every action that modifies the codebase (e.g., creating, editing, or deleting a file), use a read-only tool (like `read_file` or `ls`) to confirm the action was successful and had the intended effect.
+-   **Edit Source, Not Artifacts:** If you identify a build artifact, trace it back to its source file and make your changes there. Never edit generated files directly.
+-   **Practice Proactive Testing:** Run relevant tests after any code change to ensure correctness and prevent regressions. When practical, write a failing test first (Test-Driven Development).
+-   **Diagnose Before Changing Environment:** If you encounter a build or test failure, diagnose the root cause by reading logs and inspecting configuration files before attempting to install or uninstall packages.
+-   **Be Autonomous, But Ask for Help When Stuck:** Solve problems independently whenever possible. However, ask for user input if the request is ambiguous, you're stuck after multiple attempts, or a decision would significantly alter the scope of the task.
+
+## Specific Instructions
+
+### Git Merge Diffs
+
+When using tools that require a diff in the Git Merge diff format, the conflict markers (`<<<<<<< SEARCH`, `=======`, `>>>>>>> REPLACE`) must be exact and on their own lines.
+
+### Planning
+
+-   Use the `set_plan` tool to create or modify your plan.
+-   The plan should be a numbered list in Markdown format.
+-   Always include a pre-commit step to ensure proper testing, verification, review, and reflection are done by calling the `pre_commit_instructions` tool.
+
+### Bash: Long-Running Processes
+
+-   Run long-running processes (like servers) in the background using `&`. Redirect output to a file for later inspection (e.g., `npm start > npm.log 2>&1 &`).
+-   Avoid "port already in use" errors by killing existing processes on a port before restarting a server (e.g., `kill $(lsof -t -i :3000) 2>/dev/null || true`).
+
+### AGENTS.md
+
+-   Repositories may contain `AGENTS.md` files with instructions or tips for you.
+-   You must obey the instructions in any `AGENTS.md` file that applies to a file you are modifying.
+-   More deeply-nested `AGENTS.md` files take precedence over those in parent directories.
+-   The user's initial problem description and direct instructions always take precedence over `AGENTS.md`.
+
+## nIA's Skills (Tools)
+
+Here is a comprehensive list of the tools nIA can use to accomplish tasks.
+
+### File System Operations
+
+-   `list_files(path: str)`: Lists all files and directories under a given path.
+-   `read_file(filepath: str)`: Reads the content of a specified file.
+-   `create_file_with_block(filepath: str, content: str)`: Creates a new file with the provided content.
+-   `overwrite_file_with_block(filepath: str, content: str)`: Completely overwrites an existing file with new content.
+-   `replace_with_git_merge_diff(filepath: str, merge_diff: str)`: Performs a targeted search-and-replace using a Git merge diff.
+-   `delete_file(filepath: str)`: Deletes a specified file.
+-   `rename_file(filepath: str, new_filepath: str)`: Renames or moves a file or directory.
+-   `restore_file(filepath: str)`: Restores a specific file to its original state from the last commit.
+-   `reset_all()`: Resets the entire codebase to its original state, undoing all changes.
+
+### Execution & Environment
+
+-   `run_in_bash_session(command: str)`: Runs a bash command in the sandbox from the repository root.
+-   `pre_commit_instructions()`: Retrieves the required pre-commit checks and instructions.
+
+### Planning & User Interaction
+
+-   `set_plan(plan: str)`: Sets or updates the step-by-step plan for the task.
+-   `plan_step_complete(message: str)`: Marks the current plan step as complete.
+-   `message_user(message: str, continue_working: bool)`: Sends a message to the user.
+-   `request_user_input(message: str)`: Asks the user a question and waits for a response.
+-   `record_user_approval_for_plan()`: Records the user's approval for the plan.
+
+### Version Control & Submission
+
+-   `submit(branch_name: str, commit_message: str, title: str, description: str)`: Commits the current changes and prepares them for submission.
+
+### Web & Image Tools
+
+-   `google_search(query: str)`: Performs a Google search to find information online.
+-   `view_text_website(url: str)`: Fetches the content of a website as plain text.
+-   `view_image(url: str)`: Loads and displays an image from a URL.
+-   `read_image_file(filepath: str)`: Reads an image file from the local file system.
+
+### Frontend Verification
+
+-   `frontend_verification_instructions()`: Gets instructions on how to write a Playwright script for frontend verification.
+-   `frontend_verification_complete(screenshot_path: str)`: Indicates that frontend changes have been verified, providing a screenshot path.
+
+### Code Review
+
+-   `read_pr_comments()`: Reads pending pull request comments.
+-   `reply_to_pr_comments(replies: str)`: Replies to pull request comments.
+-   `request_code_review()`: Requests a code review for the current changes.
+
+### Memory
+
+-   `initiate_memory_recording()`: Starts recording information that may be useful for future tasks.

FULL_AUDIT.md

@@ -0,0 +1,73 @@
+# Full Audit of the RuneScript Repository
+
+## 1. Introduction
+
+This document provides a comprehensive audit of the RuneScript repository. RuneScript is a Python-based Integrated Development Environment (IDE) with a focus on script editing, AI-enhanced productivity, and Git integration. The analysis covers the repository's architecture, codebase structure, strengths, and weaknesses, and concludes with actionable recommendations for improvement. This audit was performed on the `redgreenrefactor` branch.
+
+## 2. Architecture Overview
+
+The application follows a relatively modern and modular architecture, separating concerns into distinct components. The main components, as observed from the `src` directory, are:
+
+-   **UI (`src/ui`)**: Manages the user interface, built with Tkinter. The `UIManager` acts as the central point for UI operations.
+-   **Controller (`src/ide`)**: The `IDEController` is the core of the application, orchestrating interactions between the UI, project management, and AI components. It serves as the central nervous system of the IDE.
+-   **Core Logic (`src/core`)**: Contains the `ProjectLifecycleManager`, which handles the business logic for creating and managing projects.
+-   **AI Integration (`src/ai`)**: The `AIAgentOrchestrator` manages the AI capabilities, including interactions with local and remote language models.
+-   **Models (`src/models`)**: Likely contains data models or configurations for AI models.
+-   **Views (`src/views`)**: Appears to contain UI view definitions, separating them from the main UI logic.
+
+This separation of concerns is a good practice, making the codebase easier to understand, maintain, and extend.
+
+## 3. Codebase Structure
+
+The repository is well-organized at the top level:
+
+-   `data/`: For storing application data, including user projects.
+-   `docs/`: Contains documentation for the project.
+-   `icons/`, `images/`: Store visual assets for the UI.
+-   `lib/`, `tools/`: For third-party libraries and utility scripts.
+-   `src/`: The main application source code.
+-   `README.md`: A comprehensive and well-written introduction to the project.
+-   `requirements.txt`: Lists the Python dependencies.
+
+## 4. Strengths
+
+-   **Clear Vision**: The `README.md` clearly articulates the project's ambitious goals, features, and roadmap.
+-   **Modular Architecture**: The separation of UI, controller, and core logic is a significant strength that will aid future development.
+-   **AI Integration**: The project has a forward-looking approach by integrating AI capabilities at its core with an orchestrator pattern.
+-   **Comprehensive README**: The documentation for getting started is excellent and welcoming to new contributors.
+
+## 5. Weaknesses and Recommendations
+
+### 5.1. Project Management (Supervision)
+
+The user correctly identified that the project management section is "not well supervised." The current implementation is very basic and lacks key features for a good user experience.
+
+-   **Weakness**: In `IDEController.py`, new projects are created with a UUID as the folder name (`project_id = str(uuid.uuid4())`). Users cannot name their projects, making them difficult to identify and manage.
+-   **Weakness**: There is no concept of project metadata. The IDE only recognizes a folder as a project. Important information like the project name, description, type, or associated scripts is not stored.
+-   **Weakness**: The "Open Project" functionality is just a generic "open directory" dialog. It doesn't filter for valid project folders or provide a list of recent projects.
+
+-   **Recommendation 1: Introduce Project Configuration File**: Create a metadata file (e.g., `runescript.json` or `.project`) in the root of each project directory. This file would store the project's name, creation date, and other relevant settings.
+-   **Recommendation 2: Enhance Project Creation Dialog**: Modify the `new_project` flow to prompt the user for a project name and location. The IDE would then create the directory and the project configuration file.
+-   **Recommendation 3: Improve Project Opening/Switching**: Create a dedicated project browser or a "Recent Projects" list on the welcome screen. This would allow users to easily find and switch between their projects instead of navigating the file system manually.
+
+### 5.2. Testing
+
+-   **Weakness**: A search of the repository reveals no dedicated test files or testing framework configuration (like `pytest` or `unittest`). The lack of an automated test suite is a critical vulnerability for a project of this complexity. It makes refactoring risky and verifying new features difficult.
+
+-   **Recommendation 1: Establish a Testing Framework**: Integrate `pytest` as the testing framework. It's a popular, powerful, and easy-to-use choice for Python projects.
+-   **Recommendation 2: Add Unit Tests**: Start by adding unit tests for the core logic, such as the `ProjectLifecycleManager`. Mock dependencies like the UI to test the logic in isolation.
+-   **Recommendation 3: Add Integration Tests**: Create tests that verify the interaction between different components, such as the `IDEController` and the `UIManager`.
+-   **Recommendation 4: Adopt Test-Driven Development (TDD)**: As the IDE is named "Red-Green-Refactor IDE," embracing TDD as a development practice would align with the project's philosophy and significantly improve code quality.
+
+### 5.3. Dependency Management
+
+-   **Weakness**: The `requirements.txt` file is a single, long list of dependencies. This can lead to version conflicts and makes it difficult to distinguish between core dependencies and development/testing dependencies.
+
+-   **Recommendation 1: Use a Modern Dependency Manager**: Adopt a tool like [Poetry](https://python-poetry.org/) or [PDM](https://pdm.fming.dev/) to manage dependencies, virtual environments, and packaging. This would provide lock files for reproducible builds and better separation of dependencies.
+-   **Recommendation 2: Split Requirements**: If a full switch is not feasible, split the dependencies into logical files: `requirements.txt` for core dependencies and `requirements-dev.txt` for development tools (e.g., linters, testing frameworks).
+
+## 6. Conclusion
+
+RuneScript is a promising project with a strong vision and a solid architectural foundation. Its primary weaknesses lie in areas that are crucial for long-term maintainability and scalability: project management, automated testing, and dependency management.
+
+By addressing the recommendations in this audit, particularly by improving the project supervision features and introducing a robust testing culture, RuneScript can evolve into a powerful and reliable IDE for developers and creative professionals.