[#1] Save latest changes before complete remote reinstall

README.md

@@ -9,7 +9,7 @@ A strictly local, privacy-first AI Medical Dietitian and Food Explorer. This pro
 - **RAG Architecture**: The AI is connected to a massively partitioned local MySQL database. When you ask a question or request a meal plan, the AI executes SQL queries autonomously to fetch precise nutritional data.
 - **SearXNG Web Integration**: When the local Database lacks culinary heuristics, the AI securely queries a local, private instance of SearXNG to answer questions without compromising patient privacy.
 - **Plate Builder & Unit Conversion**: Input culinary recipes (e.g., "1.5 cups of flour") and the system converts them to metric standard weights based on the product's density.
-- **Distributed Microservice Topology**: Supports decoupling across VirtualBox, Hyper-V, and WSL2 using Bridged Networking and SNMP container telemetry for Zabbix.
+- **Distributed Microservice Topology**: Supports decoupling across physical bare-metal servers, VirtualBox, Hyper-V, and WSL2 using Bridged Networking and SNMP container telemetry for Zabbix.
 
 ## Documentation (Capstone Deliverables)
 Please refer to the `docs/` folder for detailed guides:
@@ -67,7 +67,7 @@ For detailed step-by-step instructions, please consult the [Installation Guide P
 - **AI Engine**: Ollama (Llama 3.2:3B)
 - **Web Search**: SearXNG
 - **Monitoring**: Zabbix (SNMPv2c)
-- **Deployment**: Native Ubuntu, Docker Compose, Hyper-V / VirtualBox
+- **Deployment**: Native physical Unix/Linux servers (bare-metal), Docker Compose, WSL2, Hyper-V / VirtualBox
 - **Project Management**: Taiga (Synced dynamically via Python)
 
 ## AI Skills & Governance

docs/Operator_Installation_Guide.md

@@ -3,7 +3,7 @@ The current version is #ident "@(#)$Format:LocalFoodAI_lanfr144:Operator_Install
 
 # Local Food AI - Detailed Operator Installation Guide
 
-This document is a step-by-step installation, mapping, configuration, and verification manual for deploying the **Local Food AI** system in an enterprise environment. It covers hybrid hypervisor infrastructure (WSL2, Hyper-V, and VirtualBox), cross-node networking, SNMPv3 monitoring, alert channels, and acceptance testing.
+This document is a step-by-step installation, configuration, and verification manual for deploying the **Local Food AI** system in an enterprise environment. It covers mixed environments ranging from native, physical Unix/Linux servers (bare-metal) to hybrid hypervisor infrastructures (WSL2, Hyper-V, and VirtualBox), cross-node networking, SNMPv3 monitoring, alert channels, and acceptance testing.
 
 ---
 
@@ -23,15 +23,15 @@ Before running installation scripts, the operator **must** collect the following
 
 ## 2. Platform Mapping: Which Container Goes Where?
 
-To maximize CPU/GPU efficiency and secure database read/writes, services are distributed across three distinct environments:
+To maximize CPU/GPU efficiency and secure database read/writes, services can be distributed across native physical servers or virtualized environment hypervisors:
 
 | COMPONENT CONTAINER | DEPLOYMENT ENVIRONMENT | WHY |
 | :--- | :--- | :--- |
-| **streamlit-app (app.py)** | Local WSL2 (Windows) | Low-latency rendering and direct client access |
-| **mysql (Database Node)** | Hyper-V VM (Server A) | Persistent enterprise-grade disk storage |
-| **ollama (NLP llama3.2:3b Engine)** | VirtualBox VM (Server B) | Dedicated CPU/GPU virtualization allocation |
-| **zabbix-server & web (Monitoring)** | Hyper-V VM (Server A) | Centralized SNMPv3 alert processing and logs |
-| **searxng (Meta-Search Gateway)** | Local WSL2 (Windows) | Dynamic browser-level loopbacks |
+| **streamlit-app (app.py)** | Local WSL2 or Bare-Metal Unix | Low-latency rendering and direct client access |
+| **mysql (Database Node)** | Bare-Metal Server or Hyper-V VM | Persistent enterprise-grade disk storage |
+| **ollama (NLP llama3.2:3b Engine)** | Bare-Metal Server or VirtualBox VM | Dedicated CPU/GPU resource allocation |
+| **zabbix-server & web (Monitoring)** | Bare-Metal Server or Hyper-V VM | Centralized SNMPv3 alert processing and logs |
+| **searxng (Meta-Search Gateway)** | Local WSL2 or Bare-Metal Unix | Dynamic browser-level loopbacks |
 
 ---
 

docs/User_Description.md

@@ -6,7 +6,7 @@ The current version is #ident "@(#)$Format:LocalFoodAI_lanfr144:User_Description
 ## 1. System Vision
 The **Local Food AI** system is a strictly local, privacy-first, professional-grade clinical dietetics assistant. Developed specifically for clinics and healthcare practitioners, it provides offline nutritional analysis, meal planning, and warning flags based on dynamic patient health profiles. 
 
-Since the system operates entirely locally on local hypervisors, **zero patient medical data or search queries ever leave the server boundary**, ensuring 100% HIPAA compliance and data sovereignty.
+Since the system operates entirely locally on physical servers or local hypervisors, **zero patient medical data or search queries ever leave the server boundary**, ensuring 100% HIPAA compliance and data sovereignty.
 
 ---
 

docs/architecture.md

@@ -82,10 +82,10 @@ flowchart TD
 To ensure 100% resilience under network restrictions, the Local Food AI system is architected to operate under two distinct networking modes:
 
 ### 1. Mixed Distributed Topology (Production/Staging Mode)
-Services are distributed across specialized local hypervisors and Windows subsystems using bridged networking:
-- **Application Node (WSL 2)**: Runs the Streamlit frontend and local Ollama model engine.
-- **Database Node (Hyper-V VM)**: Dedicated Ubuntu instance hosting the relational MySQL partitions at `192.168.130.170`.
-- **Monitoring Node (VirtualBox VM)**: Dedicated host running Zabbix Server and receiving SNMPv3 notifications.
+Services can be distributed across native physical Unix/Linux servers (bare-metal), specialized local hypervisors, and Windows subsystems using bridged networking:
+- **Database Node (Bare-Metal Server or Hyper-V VM)**: Dedicated bare-metal Ubuntu instance hosting the relational MySQL partitions at `192.168.130.170`.
+- **Application Node (WSL 2 or Bare-Metal Unix)**: Runs the Streamlit frontend and local Ollama model engine.
+- **Monitoring Node (VirtualBox VM or Bare-Metal Unix)**: Dedicated host running Zabbix Server and receiving SNMPv3 notifications.
 - **Agile Scrum Tracker (Taiga)**: Remote agile project server at `192.168.130.161` for syncing deliverables.
 
 ### 2. Resilient Single-Node Local Fallback (Offline Mode)

docs/disaster_recovery_plan.md

@@ -41,7 +41,7 @@ cat /backup/food_db_users_2026-05-12.sql | sudo docker exec -i food_project-mysq
 - **Recovery Point Objective (RPO):** 24 Hours (User profiles and plates are backed up nightly).
 
 ### 3.2 High Availability & Failover Strategy
-If deploying in the distributed Multi-Hypervisor PoC environment (Hyper-V / VirtualBox / WSL):
+If deploying in the distributed Multi-Node / Multi-Hypervisor environment (Physical server / Hyper-V / VirtualBox / WSL):
 - **Ollama Node Failure**: The `app` is engineered to gracefully catch LLM connection timeouts. If the VirtualBox Ollama node dies, the Streamlit app will continue to function for standard Database lookups, returning a safe fallback message for AI evaluations.
 - **Zabbix Node Failure**: The SNMP daemons run autonomously in each container. If the Zabbix telemetry server goes offline, the containers will safely drop the UDP traps without bottlenecking application performance.
 

docs/distributed_deployment.md

@@ -2,13 +2,14 @@ The current version is #ident "@(#)$Format:LocalFoodAI_lanfr144:distributed_depl
 
 # Distributed Deployment Guide
 
-This document outlines the procedure to deploy the Local Food AI stack across a mixed topology of Windows 11 subsystems and hypervisors on the same local network.
+This document outlines the procedure to deploy the Local Food AI stack across a mixed topology of physical Unix servers, Windows 11 subsystems, and hypervisors on the same local network.
 
-## Supported Hypervisor Topologies
+## Supported Network & Hypervisor Topologies
 You can distribute the services across any combination of:
-- **Windows Subsystem for Linux (WSL 2)**: Ideal for the frontend and LLM nodes.
-- **Hyper-V**: Ideal for the Database node.
-- **VirtualBox**: Ideal for isolated Monitoring nodes.
+- **Physical Unix/Linux Server (Bare-Metal)**: Ideal for high-performance production hosting, running directly on physical hardware (e.g., Ubuntu Server).
+- **Windows Subsystem for Linux (WSL 2)**: Ideal for developer environments, local frontend, and LLM execution.
+- **Hyper-V**: Ideal for containerized Database nodes or virtualized system infrastructure.
+- **VirtualBox**: Ideal for isolated test environments or Monitoring nodes.
 
 ## Port Conflict Matrix
 When deploying nodes on the same IP subnet or host machine, ensure the following ports are open on your host firewall (e.g., Windows Defender Firewall) and not conflicting with existing services: