execution-agent 0.1.0__py3-none-any.whl

execution_agent/prompt_files/cpp_guidelines

@@ -0,0 +1,481 @@
+## General Guidelines : 
+**General C/C++ Project Guidelines**
+
+```
+**General C/C++ Project Guidelines**
+
+1. **Read README**
+
+   * Contains install, usage, and project-specific notes.
+
+2. **Check Dependencies**
+
+   * Look in README, `CMakeLists.txt`, `Makefile`, or `vcpkg.json`.
+   * Install required compiler and “-dev” packages.
+
+3. **Identify Build Tool**
+
+   * Find `Makefile` (Make) or `CMakeLists.txt` (CMake).
+
+4. **Build**
+
+   * **Make**:
+
+     ```bash
+     make
+     ```
+   * **CMake** (out-of-source):
+
+     ```bash
+     mkdir -p build && cd build
+     cmake ..            # add -DCMAKE_BUILD_TYPE=Debug/Release or -G Ninja as needed
+     make -j$(nproc)
+     ```
+
+5. **Configuration**
+
+   * Check for `.conf` or `config.h`.
+   * Pass paths/flags if needed, e.g. `-DFoo_DIR=/path`.
+
+6. **Run Tests**
+
+   * **CTest**:
+
+     ```bash
+     ctest --output-on-failure
+     ```
+   * Or run test executables directly.
+
+7. **Run Executable**
+
+   * Follow README (e.g., `./myapp` or server start commands).
+
+8. **Troubleshoot**
+
+   * Search GitHub issues or web.
+   * Rebuild clean, enable verbose (`make VERBOSE=1`, `ninja -v`), grep for “error:”/“warning:”.
+
+9. **Documentation**
+
+   * Read Doxygen/API docs or inline comments for structure and usage.
+
+---
+
+**Make/CMake–Specific Guide**
+
+### 1. Basic Workflow
+
+1. **Locate Build Files**
+
+   * CMake: top-level `CMakeLists.txt`.
+   * Make: root or subdirectory `Makefile`.
+
+2. **Prepare Build Directory**
+
+   ```bash
+   mkdir -p build && cd build
+   # If it exists:
+   rm -rf CMakeCache.txt CMakeFiles/* 
+   ```
+
+3. **Configure (CMake)**
+
+   ```bash
+   cmake ..                       # default
+   cmake -DCMAKE_BUILD_TYPE=Debug ..
+   cmake -G Ninja ..              # if using Ninja
+   ```
+
+4. **Build**
+
+   * **Make**:
+
+     ```bash
+     make -j$(nproc)   # parallel
+     make -j1          # fail-fast
+     ```
+   * **Ninja**:
+
+     ```bash
+     ninja             # stops on first error
+     ninja -v          # verbose
+     ```
+
+5. **Run Tests**
+
+   ```bash
+   ctest -j$(nproc) --output-on-failure
+   ```
+
+   Or:
+
+   ```bash
+   make test   # or make check
+   ```
+
+   Custom runners: follow README or look in `tests/`.
+
+6. **Check Exit Codes**
+
+   * Nonzero from `make`/`ninja`/`ctest` → failure; inspect logs or verbosity.
+
+---
+
+### 2. Common CMake Issues
+
+1. **Cannot Find Package X**
+
+   * **Symptom**:
+
+     ```
+     CMake Error: find_package(Foo) didn't find Foo
+     ```
+   * **Fix**:
+
+     * Install “foo-dev” (e.g. `sudo apt-get install libfoo-dev`).
+     * Or:
+
+       ```bash
+       cmake -DFoo_DIR=/path/to/foo/cmake ..
+       cmake -DCMAKE_PREFIX_PATH=/opt/foo ..
+       ```
+
+2. **Stale Cache / Persisting Options**
+
+   * **Symptom**: Changes not applied; missing headers despite install.
+   * **Fix**:
+
+     ```bash
+     cd build
+     rm -rf CMakeCache.txt CMakeFiles
+     cmake ..
+     ```
+
+     Or override with `-DVAR=…` on the command line.
+
+3. **Missing/Incorrect Include Directories**
+
+   * **Symptom**:
+
+     ```
+     fatal error: bar.h: No such file or directory
+     ```
+   * **Fix**:
+
+     * Check `target_include_directories(...)`:
+
+       ```bash
+       grep -R "target_include_directories" -n ../CMakeLists.txt
+       ```
+     * Build verbosely to inspect `-I` flags:
+
+       ```bash
+       make VERBOSE=1   # or ninja -v
+       ```
+     * Test manually:
+
+       ```bash
+       g++ -I/path/to/bar/include -c foo.cpp
+       ```
+     * Then add e.g.
+
+       ```cmake
+       target_include_directories(myTarget PUBLIC /path/to/bar/include)
+       ```
+
+4. **Undefined Reference (Linker)**
+
+   * **Symptom**:
+
+     ```
+     undefined reference to `Bar::baz()`
+     ```
+   * **Fix**:
+
+     * Ensure `target_link_libraries(foo PRIVATE BarLib)` in CMake.
+     * For static libs:
+
+       ```bash
+       g++ foo.o -o foo libbar.a
+       ```
+     * Avoid circular static-library dependencies; split or use shared libs.
+
+5. **No Tests Found / CTest Shows 0 Tests**
+
+   * **Symptom**:
+
+     ```
+     No tests were found!!!
+     ```
+   * **Fix**:
+
+     * In `CMakeLists.txt`, enable tests if behind an option:
+
+       ```cmake
+       option(ENABLE_TESTS "Enable tests" OFF)
+       if(ENABLE_TESTS)
+         add_subdirectory(tests)
+       endif()
+       ```
+
+       Then:
+
+       ```bash
+       cmake -DENABLE_TESTS=ON ..
+       make && ctest --output-on-failure
+       ```
+     * Verify test executables in `build/tests/`.
+
+---
+
+### 3. Common Make Issues
+
+1. **Wrong Compiler Flags**
+
+   * **Symptom**:
+
+     ```
+     gcc: error: unrecognized command line option ‘-std=c++17’
+     ```
+   * **Fix**:
+
+     * Edit Makefile:
+
+       ```makefile
+       CXX := g++
+       CXXFLAGS := -Wall -Wextra -std=c++17
+       ```
+     * Or override:
+
+       ```bash
+       make CXX=clang++ CXXFLAGS="-std=c++17 -O2"
+       ```
+     * Ensure toolchain consistency:
+
+       ```bash
+       export CC=gcc CXX=g++
+       make clean && make
+       ```
+
+2. **Stale Builds / Missing Dependencies**
+
+   * **Symptom**: Header change doesn’t recompile dependent objects.
+   * **Fix**:
+
+     * Add auto-generated `.d` files:
+
+       ```makefile
+       SRCS := $(wildcard src/*.cpp)
+       DEPS := $(SRCS:.cpp=.d)
+       OBJS := $(SRCS:.cpp=.o)
+
+       -include $(DEPS)
+
+       %.o: %.cpp
+       	$(CXX) $(CXXFLAGS) -MMD -MF $(@:.o=.d) -c $< -o $@
+
+       myapp: $(OBJS)
+       	$(CXX) $(OBJS) -o $@ $(LDFLAGS)
+       ```
+     * If unmodifiable, force clean rebuild:
+
+       ```bash
+       make clean && make -j$(nproc)
+       ```
+
+       or delete objects:
+
+       ```bash
+       find . -name '*.o' -delete && make
+       ```
+
+3. **Parallel Race Conditions**
+
+   * **Symptom**:
+
+     ```
+     No rule to make target 'moduleA/libbar.a'
+     ```
+   * **Fix**:
+
+     * Confirm serial build:
+
+       ```bash
+       make -j1
+       ```
+     * Add missing dependencies in Makefile, e.g.:
+
+       ```makefile
+       moduleB/foo.o: ../moduleA/libbar.a
+       ```
+     * If no write access, build `-j1`.
+
+---
+
+### 4. Spotting Errors Quickly
+
+1. **Grep for Errors/Warnings**
+
+   ```bash
+   make -j$(nproc) 2>&1 | tee build.log | grep --color -i "error:\|warning:"
+   grep -n "error:" build.log
+   grep -n "warning:" build.log
+   ```
+
+2. **Enable Verbose Mode**
+
+   * **Make**: `make VERBOSE=1`
+   * **Ninja**: `ninja -v`
+
+3. **Fail-Fast Builds**
+
+   * **Make**:
+
+     ```bash
+     make -j1           # stops on first error
+     make -k -j$(nproc) # continues despite errors
+     ```
+   * **Ninja**: stops on first error by default.
+
+4. **CTest Output**
+
+   ```bash
+   ctest --output-on-failure
+   ```
+
+---
+
+### 5. Common Pitfalls & Prevention
+
+1. **Mixing Build Artifacts with Source**
+
+   * **Issue**: `.o` or generated files in source tree → clutter and stale artifacts.
+   * **Tip**: Always do out-of-source builds:
+
+     ```bash
+     mkdir build && cd build && cmake ../ && make
+     ```
+
+     If forced in-source, run `make clean` or delete files manually.
+
+2. **Silent Failures in Scripts/Tests**
+
+   * **Issue**: Test scripts hide exit codes (`set -e` missing).
+   * **Tip**:
+
+     ```bash
+     ./run_tests.sh 2>&1 | tee test_run.log
+     grep -i "fail" test_run.log
+     ```
+
+3. **Mismatched Compiler Versions/ABI**
+
+   * **Issue**: Project expects GCC 8 but system has GCC 5.
+   * **Tip**:
+
+     ```bash
+     cd build
+     grep "CMAKE_CXX_COMPILER" CMakeCache.txt
+     export CC=gcc-9 CXX=g++-9
+     cmake ..
+     make
+     ```
+
+     For Makefiles:
+
+     ```bash
+     make CC=gcc-9 CXX=g++-9
+     ```
+
+4. **Circular/Missing Submodule Dependencies**
+
+   * **Issue**: `moduleA` needs `moduleB` but scripts omit linkage.
+   * **Tip**:
+
+     * **Make**: add `moduleB/libB.a` as a prerequisite.
+     * **CMake**: `target_link_libraries(moduleA PUBLIC moduleB)`.
+     * If unmodifiable, build sequentially:
+
+       ```bash
+       (cd moduleB && make)
+       (cd moduleA && make)
+       ```
+
+5. **Outdated CMakeLists (Using `file(GLOB ...)`)**
+
+   * **Issue**: New `.cpp` files aren’t detected until CMake reruns.
+   * **Tip**:
+
+     ```bash
+     cd build
+     rm -rf CMakeCache.txt CMakeFiles
+     cmake ..
+     make -j$(nproc)
+     ```
+
+---
+
+### 6. Quick Error-Fix Recipes
+
+1. **“Could not find package XYZ”**
+
+   ```bash
+   sudo apt-get update
+   sudo apt-get install libxyz-dev
+   cd build
+   rm -rf CMakeCache.txt CMakeFiles
+   cmake ..
+   make -j$(nproc)
+   # If in custom prefix:
+   cmake -DCMAKE_PREFIX_PATH=/opt/xyz ..
+   ```
+
+2. **Missing Headers (“No such file or directory”)**
+
+   ```bash
+   cd build
+   make VERBOSE=1 2>&1 | tee verbose.log
+   grep -n "fatal error: .* No such file or directory" verbose.log
+   # Add missing include via CMakeLists or Makefile once identified.
+   ```
+
+3. **“Undefined Reference …” (Linker)**
+
+   ```bash
+   cd build
+   make VERBOSE=1 -j1 2>&1 | tee link.log
+   grep -n "undefined reference" link.log
+   # Ensure the library supplying the symbol appears after objects; adjust CMakeLists or rebuild.
+   ```
+
+4. **Tests Fail Silently (Exit Code 0 But Wrong Behavior)**
+
+   ```bash
+   cd build
+   ctest --output-on-failure | tee test.log
+   grep -i "fail" test.log
+   grep -i "error" test.log
+   # If none, run test binaries manually:
+   ./tests/test_moduleA
+   valgrind ./tests/test_moduleA
+   ```
+
+5. **CMake Not Picking Up New Files (`file(GLOB)`)**
+
+   ```bash
+   cd build
+   rm -rf CMakeCache.txt CMakeFiles
+   cmake ..
+   make -j$(nproc)
+   ```
+
+---
+
+### 7. Test Suite Results
+
+When running a test suite, it is normal for some test cases to fail. If the percentage of failing test cases is less than 20% of the total number, it is considered acceptable, and further investigation is not necessary.
+
+```
+---
+END OF LANGUAGE SPECIFIC GUIDELINES SETCTION
+---

execution_agent/prompt_files/cycle_instruction

@@ -0,0 +1,51 @@
+Determine exactly one command to execute next, drawing on:
+  - The high‐level goals and subgoals you’ve been given,
+  - The full history of commands, their outcomes, and reported working directories,
+  - Any errors or feedback observed in previous iterations,
+  - Your own expertise regarding robust build and debugging practices.
+
+Before choosing, perform a thorough, step‐by‐step analysis:
+  1. **Recall the last command executed and its working directory**: State the exact command you ran most recently, note the shell’s reported current working directory afterward (e.g., “/home/user/Project”), and summarize its result (success, failure, files created, etc.).
+  2. **Interpret that outcome**: What concrete information did it provide? Did it reveal missing files, dependencies, or configuration issues? How does that push progress toward the next subgoal?
+  3. **Update your mental model, including cwd context**: Describe how this latest result and working directory fit into the overall context. Which goals have been satisfied so far, and which remain? Are there new blockers or unknowns?
+  4. **Enumerate possible next commands**: List two or three plausible actions (e.g., “run cmake with out‐of‐source flags,” “inspect CMakeLists.txt,” “list a directory,” “install a missing library”). For each, state:
+     - **Expected outcome**: What you expect to learn or achieve,
+     - **Why it differs from previous attempts**: Why this choice avoids repeating past failures,
+     - **Potential pitfalls**: What could still go wrong given the current cwd.
+  5. **Select the single best command**: Explain why this one action is the most logical and likely to succeed now—referencing the exact files, error messages, or missing components you’ve observed, and the current working directory. Emphasize how it prevents repeating mistakes (e.g., avoiding in‐source builds, using the correct cwd).
+  6. **Describe how to run it robustly**: Include precise flags or arguments (e.g., `-S .. -B .`, disabling formatting checks, choosing Debug vs. Release) and explicitly confirm or change into the correct working directory so that this step anticipates and avoids prior pitfalls.
+
+Then, output only a JSON object matching this schema:
+
+```ts
+interface Response {
+  thoughts: string;     // Include the full reasoning from steps 1–6 in detailed prose, explicitly noting the cwd at each relevant point. (REQUIRED)
+  command: {            // REQUIRED   
+    name: string;       // The tool name, e.g., "linux_terminal" or "read_file". (REQUIRED)
+    args: Record<string, any>;  // The exact arguments for that tool, including any cd to change directory. (REQUIRED)
+  };
+}
+
+Here is an example of a command call that you can output (This is a fictional example to just show you the kind of expected response):
+
+{
+  "thoughts": "1. Recall of last command executed and working directory: The previous command was `python3 -m venv venv`, executed in `/home/user/AwesomeApp`. After it completed, the shell's prompt showed the cwd still as `/home/user/AwesomeApp`, and the `venv/` directory was created there.\n\n2. Interpretation of that outcome: The creation of `venv/` in `/home/user/AwesomeApp` confirms that the virtual environment was built correctly in the project root. No errors were reported, but no dependencies have yet been installed inside this environment.\n\n3. Updated mental model, including cwd context: We are currently located in `/home/user/AwesomeApp`. The repository is cloned, and the venv is set up. The `requirements.txt` file is in `/home/user/AwesomeApp/requirements.txt`. With the virtual environment directory present, our next subgoal is to install the packages listed in `requirements.txt` into the venv so that the application and tests can run.\n\n4. Possible next commands:\n   • `cd /home/user/AwesomeApp && source venv/bin/activate && pip install -r requirements.txt`:\n     - Expected outcome: Activates the venv in `/home/user/AwesomeApp`, then installs dependencies from `requirements.txt` into the virtual environment. This avoids missing-module errors when running the app or tests. Previous attempts did not have the venv activated, so pip would have installed globally or failed; now it will succeed in the correct environment.\n     - Potential pitfalls: If the `requirements.txt` references a package with native extensions (e.g., `psycopg2`), pip may fail due to missing system libraries. In that case, we will see explicit error messages indicating which Ubuntu packages need to be installed.\n\n   • `cd /home/user/AwesomeApp && read_file requirements.txt`:\n     - Expected outcome: Displays the contents of `requirements.txt`, allowing manual verification of required package names and versions. Since we already know its location and trust its format, this is lower priority and just delays installing.\n     - Potential pitfalls: None significant, but it does not move us toward actually installing the dependencies.\n\n   • `cd /home/user/AwesomeApp && source venv/bin/activate && pip install --upgrade pip setuptools`:\n     - Expected outcome: Ensures pip and setuptools are up to date inside the venv, reducing the chance of installation failures. This could avoid package build errors.\n     - Potential pitfalls: If pip and setuptools are already current, it's redundant. If `requirements.txt` contains packages requiring newer pip, a direct install with `-r` might upgrade pip automatically anyway.\n\n5. Selecting the single best command: Running `cd /home/user/AwesomeApp && source venv/bin/activate && pip install -r requirements.txt` is the most direct next step. We are already in `/home/user/AwesomeApp` (confirmed by cwd), and installing dependencies is required before any tests or application code can run. Inspecting the file is redundant since its location is known, and upgrading pip separately is unnecessary because pip will upgrade itself if needed during the install process. This combined command addresses the immediate blocker—missing packages—and will reveal any system package requirements.\n\n6. How to run it robustly: We explicitly `cd /home/user/AwesomeApp` to guarantee the cwd is correct. Then `source venv/bin/activate` ensures we are using the venv's pip. Finally, `pip install -r requirements.txt` installs exactly the dependencies listed. If any package fails, pip will output a clear error (e.g., missing headers), which we can address by installing a system package and rerunning the same command rather than redoing earlier steps incorrectly.\n",
+  "command": {
+    "name": "linux_terminal",
+    "args": {
+      "command": "cd /home/user/AwesomeApp && source venv/bin/activate && pip install -r requirements.txt"
+    }
+  }
+}
+
+**IMPORTANT REMINDER**: When using linux_terminal, provide commands directly WITHOUT shell wrappers like `bash -c`, `bash -lc`, `sh -c`, or similar. The system handles shell execution automatically. For example, use `ls -la` not `bash -lc 'ls -la'`.
+
+**IMPORTANT NOTE TO THE ASSISTANT: DO NOT OUTPUT ANY OTHER TEXT AROUND YOUR JSON RESPONSE.**
+
+**SUCCESS CRITERIA:**
+When evaluating test results, remember:
+- Your primary goal is to get the test suite running, not to achieve 100% pass rate
+- If ~80% or more of tests pass, the task is considered successful
+- Having a few failing tests or errors is acceptable and expected
+- Once you have a substantial majority of tests passing (~80%+), declare goals accomplished
+- Do NOT waste cycles trying to fix the last few failing tests - focus on getting most tests working

execution_agent/prompt_files/java_guidelines

@@ -0,0 +1,37 @@
+## General Guidelines:
+**General Guidelines for Java Projects**
+
+1. **Read the README**  
+   Start by reading the project's README file on GitHub. It often contains important instructions for installation, usage, and any project-specific details.  
+
+2. **Check Dependencies**  
+   Look for any dependencies listed in the README or in configuration files like `pom.xml` (for Maven) or `build.gradle` (for Gradle). Ensure you have the required JDK version installed.  
+
+3. **Build Tool**  
+   Identify which build tool the project is using: Maven or Gradle. This information should be available in the README or through project configuration files (`pom.xml` for Maven, `build.gradle` for Gradle).  
+
+4. **Build the Project**  
+   Use the appropriate commands based on the build tool:  
+   - For Maven:  
+     ```  
+     mvn clean install  
+     ```  
+   - For Gradle:  
+     ```  
+     gradle build  
+     ```  
+
+5. **Configuration**  
+   Check if the project requires any configuration files (e.g., property files, YAML files) and set them up accordingly.  
+
+6. **Run Tests (if available)**  
+   If the project provides tests, it’s a good idea to run them to ensure everything is working correctly.  
+
+7. **Run the Project**  
+   Follow the instructions in the README to run the project. This could involve running a specific class, starting a server, or executing a specific command.  
+
+8. **Troubleshooting**  
+   If you encounter any issues during installation or while running the project, refer to the project’s issue tracker on GitHub or search for similar issues others may have encountered.  
+
+9. **Test Suite Results**  
+   When running a test suite, it is normal for some test cases to fail. If the percentage of failing test cases is less than 20% of the total number, it is considered acceptable, and further investigation is usually not necessary.  

execution_agent/prompt_files/javascript_guidelines

@@ -0,0 +1,69 @@
+## General Guidelines:
+**General Guidelines for JavaScript/Node.js Projects**
+
+1. **Read the README**  
+   Start by reading the project's README file on GitHub. It often contains important instructions for installation, usage, and any project-specific details.  
+
+2. **Check Dependencies**  
+   Look for dependencies listed in the README or in the `package.json` file. Ensure you have Node.js and npm (or Yarn) installed to manage these dependencies.  
+
+3. **Install Dependencies**  
+   Run the following command to install project dependencies:  
+   ```bash
+   npm install  
+   ```  
+   or, if the project uses Yarn:  
+   ```bash
+   yarn install  
+   ```  
+
+4. **Build the Project**  
+   If the project requires a build step, refer to the `scripts` section in the `package.json` file. Common build commands include:  
+   ```bash
+   npm run build  
+   ```  
+   or  
+   ```bash
+   yarn build  
+   ```  
+
+5. **Configuration**  
+   Check if the project requires any configuration files (e.g., `.env` files, JSON configuration files) and set them up accordingly. The README or project documentation should provide details on this.  
+
+6. **Run Tests (if available)**  
+   If the project provides tests, it’s a good idea to run them to ensure everything is working correctly. Common test commands include:  
+   ```bash
+   npm test  
+   ```  
+   or  
+   ```bash
+   yarn test  
+   ```  
+
+7. **Run the Project**  
+   Follow the instructions in the README to run the project. Common commands might include:  
+   ```bash
+   npm start  
+   ```  
+   or  
+   ```bash
+   yarn start  
+   ```  
+
+8. **Troubleshooting**  
+   If you encounter any issues during installation or while running the project, refer to the project’s issue tracker on GitHub or search for similar issues others may have encountered. Checking for error messages in the terminal can also provide clues.  
+
+9. **Code Linting and Formatting**
+   Use linters and formatters to ensure code quality and consistency. Common tools include ESLint for linting and Prettier for formatting. You can typically run these with:
+   ```bash
+   npm run lint
+   npm run format
+   ```
+   or
+   ```bash
+   yarn lint
+   yarn format
+   ```
+
+10. **Test Suite Results**
+   When running a test suite, it is normal for some test cases to fail. If the percentage of failing test cases is less than 20% of the total number, it is considered acceptable, and further investigation is not necessary.

execution_agent/prompt_files/latest_containter_technology

@@ -0,0 +1,7 @@
+The best containerization option for installing and running a project would be Docker. Here's why Docker stands out:
+
+    - Ease of use: Docker simplifies the containerization process, making it easy to create, deploy, and manage containers. It has a robust ecosystem with lots of community support and documentation.
+    - Isolation: Docker ensures that the project runs in a fully isolated environment, minimizing conflicts with other software on your system. This is useful for development, testing, and deployment.
+    - Cross-platform compatibility: Docker containers can run on any platform that supports Docker, making your project highly portable.
+    - Efficiency: Docker containers are lightweight compared to virtual machines, sharing the host OS kernel, which makes them faster to start and more resource-efficient.
+    - Ecosystem and tool integration: Docker integrates well with a variety of CI/CD tools, registries (like DockerHub), and orchestration systems (like Kubernetes), enabling smooth workflows from development to production.

execution_agent/prompt_files/python_guidelines

@@ -0,0 +1,48 @@
+## General Guidelines:
+**General Guidelines for Python Projects**
+
+1. **Read the README**  
+   Always start by reading the project's README file on GitHub. It usually contains important instructions for installation, usage, and any project-specific details. Some projects include a `Dockerfile` script, which you can review and reuse as needed.  
+
+2. **Check Dependencies**  
+   Look for dependencies listed in the README or in a `requirements.txt` file. Ensure you have the required versions of Python and any other libraries/packages.  
+
+3. **Virtual Environment**  
+   It’s a good practice to create a virtual environment for each Python project to avoid conflicts with system-wide packages. Use the command:  
+   ```bash
+   python3.X -m venv .venv  
+   ```  
+
+4. **Configuration**  
+   Check if the project requires any configuration files (e.g., `.env` files) and set them up accordingly.  
+
+5. **Build the Project (rare cases)**  
+   Some projects might require building before usage, especially if they include C extensions or require compiling assets.  
+
+6. **Run Tests (if available)**  
+   If the project provides tests, it’s a good idea to run them to ensure everything is working correctly. Some projects include a `tox.ini` file, which allows you to run tests with `tox`. Install `tox` first using:  
+   ```bash
+   pip install tox  
+   ```  
+
+7. **Run the Project**  
+   Follow the instructions in the README to run the project. This could involve running a script, starting a server, or executing a specific command.  
+
+8. **Troubleshooting**  
+   If you encounter issues during installation or while running the project, refer to the project’s issue tracker on GitHub or search for similar issues others may have encountered.  
+
+9. **Test Suite Results**  
+   When running a test suite, it is normal for some test cases to fail. If the percentage of failing test cases is less than 20% of the total number, it is considered acceptable, and further investigation is not necessary.  
+
+10. **Shell Compatibility**  
+   In some shells, the `source` command may not work. In such cases, replace `source` with just `.` (a single dot). For example:  
+   ```bash
+   . .venv/bin/activate  
+   ```  
+
+11. **Avoid Using Conda**  
+   Instead of Conda, prefer the following commands to set up your virtual environment:  
+   ```bash
+   python -m venv .venv  
+   source .venv/bin/activate  
+   ```