Remove virtual_machine.md - cleanup for OS launch

virtual_machine.md

@@ -1,39 +0,0 @@
-Steps to build a self‑contained VM environment
-Identify and lock dependencies. Use the repository’s requirements.txt and the README’s instructions (pip install --extra-index-url https://download.pytorch.org/whl/cpu -r requirements.txt
-GitHub
-) to install a CPU‑only PyTorch build and other packages. The VM should include system libraries required by matplotlib and scikit‑learn.
-Create a container/VM build file. A Dockerfile or VM provisioning script can start from a lightweight base image (e.g., Ubuntu 22.04). It should:
-Install Python 3.11 and system build tools.
-Copy the repository into /opt/bit_transformer.
-Install Python dependencies (optionally using a virtual environment).
-Expose ports for the dashboard (e.g., 5000) and MCP server (e.g., 7000).
-Set environment variables such as MCP_SERVER_ADDR to http://127.0.0.1:7000 so the dashboard automatically forwards requests to the local MCP server when both are running in the same VM.
-Configure entrypoints. Add a shell script that starts the MCP server and dashboard concurrently. For example:
-#!/bin/bash
-# start MCP server in background
-python mcp_server.py &
-# wait for server to start
-sleep 2
-# start dashboard on port 5000
-python -m bit_transformer.dashboard_app
-Alternatively, use a process supervisor (e.g., supervisord) to keep both processes running. The script can also call watcher.py in development mode.
-Persist state inside the VM. Use a volume or directory (e.g., /var/lib/bit_transformer) to store model snapshots and telemetry logs. The ModelManager writes weights and metrics to snapshots/ by default
-GitHub
-, so mount this directory to a persistent disk if needed.
-Include optional hardware support. Since the model is CPU‑only by default but can use GPU when available, the VM build should install CUDA libraries only if GPU support is desired. For a CPU‑only VM, skip these packages.
-Testing and health checks. Add a health‑check endpoint that calls the MCP server’s /lambdas or /infer endpoint to verify that the model responds. Also ensure that the dashboard’s HTML and JS files are included.
-Potential Codex tasks to implement
-The following Codex prompts can guide the creation of a self‑contained VM environment:
-
-Write a Dockerfile that builds a container with Python 3.11, installs dependencies from requirements.txt using the CPU‑only PyTorch wheel, copies the repo, and exposes ports 5000 (dashboard) and 7000 (MCP server). Use environment variables to set MCP_SERVER_ADDR.
-Prompt example: “Create a Dockerfile for the current repository. It should use an Ubuntu base image, install Python and pip, copy the project files, install requirements with the CPU‑only PyTorch wheel, set MCP_SERVER_ADDR=http://127.0.0.1:7000, expose ports 5000 and 7000, and set a CMD to run both the MCP server and dashboard.”
-Add an entrypoint script named start.sh that launches the MCP server (python mcp_server.py) in the background and then the dashboard (python -m bit_transformer.dashboard_app), with appropriate sleep to allow server startup.
-Prompt example: “Add a start.sh script to the repo that starts mcp_server.py in the background and then runs python -m bit_transformer.dashboard_app. Make it executable and update the Dockerfile to use this script as the default CMD.”
-Extend the dashboard to allow configurable ports. Currently the dashboard uses Flask’s default port; exposing a parameter (e.g., PORT environment variable) would simplify deployment.
-Prompt example: “Modify bit_transformer/dashboard_app.py so that the run_dashboard function accepts optional host and port parameters and defaults to environment variables HOST and PORT.”
-Automate model initialization on startup. The VM could load a default model or create one based on environment variables.
-Prompt example: “Update ModelManager.__init__ to read a JSON config file from /config/model_params.json if present and initialize the model automatically at startup.”
-Add a health‑check endpoint to the MCP server to verify that the server is running.
-Prompt example: “Add an endpoint /health to mcp_server.py that returns {"status":"ok"}. Update the Docker healthcheck to call this endpoint.”
-## Status: Complete
-All tasks in this guide are now implemented. The Dockerfile builds a CPU-only container and runs `start.sh` which launches both the MCP server and dashboard. The dashboard accepts HOST and PORT variables, the ModelManager can read `/config/model_params.json` on startup, and the MCP server exposes `/health` for Docker health checks.