Add Maslow 4 chat assistant: Flask + OpenAI API with GitHub Pages and Cloudflare Worker support

[Copilot]

Adds a web-based chat interface backed by the OpenAI API, purpose-built to answer technical questions about the Maslow 4 CNC router. The AI is grounded by a curated markdown reference document injected as the system prompt. Supports three deployment options: GitHub Pages + Cloudflare Worker proxy (recommended), GitHub Pages direct, and self-hosted Flask.

Static Frontend (index.html) — GitHub Pages (dual mode)

• Single-page app at the repo root, deployable via GitHub Pages with no server required
• Fetches common_issues.md at runtime and injects it as the system prompt
• Multi-turn history, typing indicator, auto-growing textarea, Enter-to-send, consolidated error handling with retry support
• Proxy mode (recommended): when a WORKER_URL repo variable is set, the page calls the Cloudflare Worker — the API key section is hidden entirely and users can chat without providing a key
• Direct mode (fallback): when WORKER_URL is not set, the API key field is shown and the browser calls OpenAI directly; key is stored in localStorage

Cloudflare Worker proxy (worker.js) — keeps API key off the browser

• Free-tier Cloudflare Worker that proxies requests from GitHub Pages to OpenAI
• OpenAI API key stored as a CF Worker secret — never sent to the browser
• Handles CORS preflight, non-JSON upstream responses, and network errors gracefully
• Optional ALLOWED_ORIGIN variable restricts requests to the GitHub Pages domain

To deploy: npx wrangler deploy then npx wrangler secret put OPENAI_API_KEY

GitHub Actions workflow (.github/workflows/deploy-pages.yml)

• Triggers on every push to main
• Reads the WORKER_URL repository variable and injects it into index.html at build time via sed
• Deploys automatically to GitHub Pages using official GitHub Actions

To enable: Settings → Pages → Source: GitHub Actions; add WORKER_URL under Settings → Secrets and variables → Actions → Variables.

Backend (app.py) — Self-hosted Flask

• Flask app with two routes: GET / (UI) and POST /chat (LLM proxy)
• Validates message structure (role must be user/assistant, content must be string) before forwarding to OpenAI
• Catches APIError and empty choices responses; returns structured JSON errors with appropriate HTTP status codes
• common_issues.md is read once and cached; injected into every system prompt
• Model, max tokens (default 2048), port, and debug mode all configurable via env vars

Server-side Frontend (templates/index.html)

• Single-page chat UI served by the Flask backend
• Multi-turn history, typing indicator, auto-growing textarea, Enter-to-send
• Removes failed user messages from history on error so the user can retry cleanly

Reference document (common_issues.md)

Eight categories of Maslow 4 issues used as AI context: WiFi/network setup, belt mechanics, calibration, firmware updates, cutting problems, G-code/software, hardware assembly, and community resources.

Config (Flask / self-hosted)

cp .env.example .env
# Set OPENAI_API_KEY; optionally override OPENAI_MODEL, OPENAI_MAX_TOKENS, PORT
pip install -r requirements.txt
python app.py

Original prompt

Generate a webpage with a chat prompt to interact with an LLM (by API) which can answer technical questions about Maslow 4. Reference a markdown file with specific common issues which the AI can use to answer.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[BarbourSmith]

@copilot code review[agent] Can this be hosted on github pages?

[Copilot]

@copilot code review[agent] Can this be hosted on github pages?

Yes — added in commit b9ae991. The repo now has a static index.html at the root that works on GitHub Pages.

To enable GitHub Pages:

1. Go to repo Settings → Pages
2. Set source to Deploy from a branch → main / (root)
3. Visit the published URL, paste your OpenAI API key into the key field, and start chatting

How it works: the page fetches common_issues.md from the same repo as context, then calls the OpenAI API directly from the browser. The API key is stored only in the user's browser localStorage — it never touches any other server.

The Flask app (app.py) is kept as an alternative for anyone who prefers a server-side deployment where the key stays on the server. The README now documents both options.

[BarbourSmith]

@copilot Is it possible to keep the API key in the github pages secrets? I don't want users to have to provide their own API key

[Copilot]

@copilot Is it possible to keep the API key in the github pages secrets? I don't want users to have to provide their own API key

GitHub Pages secrets aren't available at runtime — anything embedded in a static page is visible in the browser source, so the key can't be hidden that way. The solution is a thin server-side proxy.

Added in commit 3f901f8: a Cloudflare Worker (free tier) that sits between GitHub Pages and OpenAI. The API key lives in a CF Worker secret — it never reaches the browser.

How it works

User's browser  →  GitHub Pages (static index.html)
                        ↓  POST /chat
              Cloudflare Worker (worker.js)
                        ↓  + Authorization: ****** key>
                   OpenAI API

Setup (one-time, ~5 minutes)

1. Deploy the worker:

npm install -g wrangler
wrangler login
npx wrangler deploy
npx wrangler secret put OPENAI_API_KEY   # paste key when prompted

Copy the worker URL printed after deploy (e.g. https://maslow-assistant.xyz.workers.dev).

2. Configure GitHub Pages to use the worker:

• Repo Settings → Secrets and variables → Actions → Variables (Variables tab)
• Add: WORKER_URL = your worker URL
• Repo Settings → Pages → Source: GitHub Actions
• Push any commit — the included workflow builds and deploys automatically

Once live, the API key field is hidden entirely and users can chat straight away:

(The screenshot above shows direct mode — in proxy mode the yellow key notice and input field are not shown at all.)

If WORKER_URL is never set, the page falls back to the current direct mode where users supply their own key — so nothing breaks for anyone who skips the worker step.