bog maker 4000 web app road map

[bbartling]

Now that some history is being logged ... improvements to long-term architectural upgrades.

---

Roadmap for Bog Maker 4000

Phase 1: Persistent Job History (Short-Term Goal)

Implementation Steps:

1. Create a Database Initialization Script: Create a new file, init_db.py, to set up your database schema.

   # init_db.py
   import sqlite3
   
   connection = sqlite3.connect('database.db')
   with open('schema.sql') as f:
       connection.executescript(f.read())
   connection.commit()
   connection.close()

2. Define the Schema: Create a file named schema.sql.

   -- schema.sql
   DROP TABLE IF EXISTS jobs;
   
   CREATE TABLE jobs (
       id TEXT PRIMARY KEY,
       user TEXT NOT NULL,
       timestamp TEXT NOT NULL,
       bog_file_name TEXT NOT NULL,
       status TEXT NOT NULL,
       description TEXT NOT NULL,
       last_script_code TEXT
   );

3. Modify app.py to Use the Database:

   • Remove the global job_history dictionary.
   • Add helper functions to connect to the database.
   • Update your /history, /api/build, and /api/correct routes to read from and write to the database.

   # In app.py
   
   import sqlite3 # <-- Add this import
   
   # Remove this line:
   # job_history: Dict[str, List[Dict]] = {}
   
   def get_db_connection():
       conn = sqlite3.connect('database.db')
       conn.row_factory = sqlite3.Row
       return conn
   
   @app.route("/history")
   @requires_basic_auth
   def history_page(user: str) -> Response:
       """Renders the user's job history page from the database."""
       conn = get_db_connection()
       jobs = conn.execute(
           'SELECT * FROM jobs WHERE user = ? ORDER BY timestamp DESC LIMIT 10', (user,)
       ).fetchall()
       conn.close()
       return render_template("history.html", jobs=jobs, user=user)
   
   # In /api/build and /api/correct, replace the job_history logic:
   # ... inside the route, after creating a job_record dictionary ...
   conn = get_db_connection()
   conn.execute(
       'INSERT INTO jobs (id, user, timestamp, bog_file_name, status, description, last_script_code) VALUES (?, ?, ?, ?, ?, ?, ?)',
       (
           job_record['id'], user, job_record['timestamp'], job_record['bog_file_name'],
           job_record['status'], job_record['description'], job_record['last_script_code']
       )
   )
   conn.commit()
   conn.close()

---

Phase 2: Transition to LangGraph (Medium-Term Goal)

Mke agent's logic more powerful and flexible.

When to Make the Switch:
Transition to LangGraph when you want to implement features that are difficult with your current linear script, such as:

1. Human-in-the-Loop: Pausing the generation process to ask the user for clarification or approval before continuing.
2. Complex Logic: Adding more steps or conditional branches to the agent's reasoning process (e.g., "try a simple fix, if that fails, try a complex fix, if that also fails, ask the user").
3. Resilience: Saving the agent's state after each step so a long-running job can be resumed after a crash.

Implementation Steps:

1. Install Libraries: Add langgraph, langchain, and langchain_google_genai to your requirements.txt and rebuild your Docker image.
2. Refactor generic_agent.py:
   • Define a State graph to hold the agent's memory (script_code, last_error, attempts, etc.).
   • Convert your core functions (llm_generate_script, run_script, llm_fix_script) into nodes that operate on this State.
   • Use add_conditional_edges to replace your Python while loop with a graph-based control flow.
3. Update app.py: Your API endpoints will now call the compiled LangGraph agent (agent_graph.stream(...)) instead of run_agent_session(...). This also makes it much easier to stream real-time logs back to the user's browser.

---

Phase 3: Scaling Context with RAG (Long-Term Goal)

Concerned about context size. llms-full.txt is already quite large. When it becomes too big for the model's context window, or too expensive to send with every call, you should switch to Retrieval-Augmented Generation (RAG).

When to Make the Switch:

1. Context Window Errors: You start getting errors from the API that your prompt is too long.
2. Cost/Performance: The cost of sending the full context with every API call becomes too high, or the latency increases noticeably.
3. Relevance: You find that only a small portion of llms-full.txt is relevant to any given user request, and sending the whole file is inefficient.

Implementation Steps:

1. Pre-process Your Documents:
   • Instead of loading the context files as giant strings, you will write a one-time script to split them into smaller, meaningful chunks.
   • You will use an embedding model to convert these chunks into vectors and store them in a vector database (like ChromaDB or FAISS, which can run locally).
2. Modify the Agent's Prompting:
   • Before: Your current agent stuffs the entire examples_blob into the prompt.
   • After (with RAG): The agent will first take the user's request (e.g., "create a chiller plant sequence") and use it to search the vector database.
   • The database will return only the most relevant example scripts (e.g., the top 3-5 most similar examples).
   • The agent will then inject only these highly relevant examples into the prompt, keeping it small, targeted, and effective. This dramatically reduces token usage and can even improve the quality of the output.