Rename to Plugin Compass, add mobile onboarding/signin, implement self-update for desktop, and fix workflow paths

This commit is contained in:
southseact-3d
2026-02-16 12:05:30 +00:00
parent 63698e1d19
commit d6e2af3a29
11 changed files with 945 additions and 138 deletions

View File

@@ -1,44 +1,54 @@
# 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.
# Plugin Compass Desktop (Electron)
This folder contains the desktop app build for Plugin Compass. The desktop app reuses the existing web UI and wraps it with a native Electron shell that can run OpenCode locally, save output on the user's machine, and sync finished plugins to the backend.
## Features
- Reuses the existing web UI with minimal divergence.
- Self-updating via electron-updater (no manual downloads required).
- Run OpenCode locally with API keys pulled securely from the backend.
- Persist work on the user's device and sync results back to the backend.
- Build via GitHub Actions.
## Self-Update System
The app includes an automatic update system using `electron-updater`:
1. **Automatic Check**: On startup, the app checks for updates from GitHub Releases.
2. **Background Download**: Updates download in the background without interrupting the user.
3. **User Notification**: When an update is ready, the user is notified via the UI.
4. **One-Click Install**: User can restart the app to apply the update.
### How Updates Work
- Updates are published to GitHub Releases by the CI workflow.
- `electron-updater` downloads the new version from GitHub.
- The update is verified before installation.
- Users can choose when to restart and apply the update.
### Developer Notes
- Updates require code-signing for production (not needed for testing).
- The update server is GitHub Releases (configured in package.json).
- Update events are exposed via `window.windowsAppBridge`:
- `checkForUpdates()` - Manually check for updates
- `downloadUpdate()` - Download available update
- `installUpdate()` - Restart and install
- `onUpdateAvailable(callback)` - Listen for update available
- `onUpdateDownloaded(callback)` - Listen for update ready
- `onDownloadProgress(callback)` - Track download progress
## Setup
1. Install prerequisites (Node 18+).
2. From this folder: `npm install`.
3. Pull UI assets: `npm run prepare-ui`.
## Development
- `npm run dev` starts Electron using the copied UI in `ui-dist`.
- Commands are exposed via `window.windowsAppBridge`.
## CI build
- GitHub Actions workflow: `.github/workflows/build-electron-app.yml`.
- The action runs on `windows-latest`, builds the app, and publishes to GitHub Releases.
## Security notes
- No command exposes the stored API key to the web layer.
- OpenCode is only invoked from the main process with the key set via environment variables.
- File system access is restricted to the app data directory.