Restore to commit 74e578279624c6045ca440a3459ebfa1f8d54191

windows-app/README.md

@@ -0,0 +1,44 @@
+# Windows Desktop App
+
+This folder contains the Windows desktop build for the project. The desktop app reuses the existing web UI (apps and builder screens) and wraps it with a native shell that can run OpenCode locally, save output on the user's machine, and sync finished apps to the backend.
+
+## Goals
+- Reuse the existing web UI with minimal divergence.
+- Keep memory footprint low (Tauri + WebView2, no Electron).
+- Run OpenCode locally with API keys pulled securely from the backend; users never see the raw key.
+- Persist work on the user's device and sync results back to the backend so apps are also available on the website.
+- Ship a single Windows `.exe` via GitHub Actions; do not build locally.
+
+## How it works
+- **UI reuse:** `npm run prepare-ui` copies `../chat/public` into `ui-dist` and injects a lightweight bridge script so existing pages can talk to the Tauri commands.
+- **Native shell:** Tauri hosts the UI from `ui-dist` and exposes a few commands (`save_api_key`, `persist_app`, `list_apps`, `sync_app`, `run_opencode_task`).
+- **Local storage:** Apps are saved under the OS app data directory, isolated per user. API keys are written to an on-disk Tauri store (no read command is exposed back to JS).
+- **OpenCode execution:** `run_opencode_task` shells out to a local OpenCode binary stored under the app data folder and injects the API key into the process environment. If the binary is missing, the command returns a clear error so the UI can download or prompt the user.
+- **Syncing:** `sync_app` posts the locally saved app JSON to the backend (configured via the `BACKEND_BASE_URL` env var in CI or a `.env` file). After a successful sync, the app is reachable from the website.
+- **Key handling:** Only the backend may return API keys; the UI can request that the native layer saves the key, but there is no command to read it back, preventing direct OpenCode access from the web runtime.
+
+## Setup
+1. Install prerequisites (Rust stable, Node 18+, WebView2 runtime on Windows).
+2. From the repo root: `cd "windows app"`.
+3. Install dependencies: `npm install` (no build here).
+4. Pull UI assets: `npm run prepare-ui`.
+5. (Optional) Create `.env` in this folder with `BACKEND_BASE_URL=https://your-backend.example/api`.
+
+## Development
+- `npm run dev` starts Tauri using the copied UI in `ui-dist`. The bridge script is auto-injected into HTML files when preparing the UI.
+- Commands are exposed via `window.windowsAppBridge` (see `tauri-bridge.js`). Existing pages can call these helpers without changing core logic.
+
+## CI build (single Windows exe)
+- GitHub Actions workflow: `.github/workflows/windows-app.yml`.
+- The action runs on `windows-latest`, installs Rust and Node, prepares the UI, and runs `npm run build` to produce the bundled `.exe` (plus installer artifacts). Artifacts are uploaded for download; no local build is performed here.
+
+## Security notes
+- No command exposes the stored API key to the web layer.
+- OpenCode is only invoked from the Rust side with the key set via environment variables.
+- File system allowlist in Tauri is restricted to the app data directory plus the bundled UI folder.
+- If additional secrets are needed, source them from the backend and save via `save_api_key` only.
+
+## Next steps
+- Wire the existing apps and builder pages to call `window.windowsAppBridge` where persistence or syncing is needed.
+- Add OpenCode binary download/install flow in the UI using `run_opencode_task` error responses to detect missing binaries.
+- Point `BACKEND_BASE_URL` to the real API endpoint in CI and secrets for production builds.