feat(cloud-console): task listing, attempt history, CORS, and console SPA

Implements the cloud-console OpenSpec change: adds GET /v1/tasks (filterable, bounded pagination, tasks:read) and GET /v1/tasks/{id}/attempts (404 on unknown task) to the platform SDK, with matching CloudClient methods and a closed-by- default CLOUD_CONSOLE_CORS_ORIGINS allow-list wired through CloudControlConfig. Ships an independent Vue 3 + Vite SPA at cloud-console/ that authenticates with an operator-supplied bearer token held in sessionStorage, renders tasks with attempt history, device pool, host registry, and the plugin registry with a registration form. Backend test suite: 438 passed (-m "not integration"); cloud-console typecheck and production build both succeed. PostgreSQL-backed repository tests and manual end-to-end verification remain pending external infrastructure. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-07-13 14:00:23 +08:00
parent 62923b9285
commit 2169bb03d9
32 changed files with 3415 additions and 24 deletions
@@ -183,6 +183,74 @@ finally:
 PY
 ```

+## Cloud Console (Web UI)
+
+The repository ships an independent Vue 3 + Vite SPA at `cloud-console/` that
+renders the task queue/history, device pool, host registry, and plugin
+registry, and exposes the existing plugin-registration action. It authenticates
+the same way `CloudClient` does: by attaching a pre-issued bearer token to
+every request. There is no login or session system.
+
+### Provision an operator bearer token
+
+Add a `CLOUD_PUBLIC_CREDENTIALS_JSON` entry whose scopes cover what the
+console operators need to do. The least-privilege set for read-only dashboards
+is `tasks:read`, `pool:read`, and `plugins:read`. Add `tasks:submit` only if
+operators should submit ad-hoc tasks from the same tab, and `plugins:admin`
+only if operators should register plugins:
+
+```json
+[
+  {
+    "principal_id": "console-operator",
+    "token": "replace-with-a-long-random-opaque-token",
+    "scopes": ["tasks:read", "pool:read", "plugins:read", "plugins:admin"]
+  }
+]
+```
+
+Rotate the token the same way as any other credential entry: deploy the
+updated Cloud API credential set and instruct operators to paste the new token
+into the console. The console keeps the token only in browser `sessionStorage`
+for that tab; closing the tab discards it.
+
+### Configure the CORS allow-list
+
+The Cloud API has no CORS middleware by default. Before a browser can call it
+cross-origin, set `CLOUD_CONSOLE_CORS_ORIGINS` to a comma-separated allow-list
+that includes the exact origin (scheme + host + port, no trailing slash) the
+operator's browser will load the console from:
+
+```bash
+# Allow a local Vite dev server
+export CLOUD_CONSOLE_CORS_ORIGINS="http://127.0.0.1:5173"
+# Or a deployed origin
+export CLOUD_CONSOLE_CORS_ORIGINS="https://console.example.com"
+```
+
+Restart the Cloud API after changing this env. The middleware is added only
+when the allow-list is non-empty — existing deployments see no behavior change
+until an operator opts in. Blanket `allow_origins=["*"]` is intentionally not
+supported because every console request carries a bearer token.
+
+### Run the console
+
+```bash
+cd cloud-console
+cp .env.example .env.local
+# Edit .env.local if your Cloud API is not at http://127.0.0.1:8001
+npm install
+npm run dev
+```
+
+Vite prints a local URL (default `http://127.0.0.1:5173`). That exact origin
+must be in `CLOUD_CONSOLE_CORS_ORIGINS` on the Cloud API. Open the dev URL,
+paste the operator token, and the dashboards become available.
+
+For a production build, run `npm run build` and serve the resulting `dist/`
+behind any static file server or CDN, with `VITE_CLOUD_API_BASE_URL` baked in
+at build time. The deployed origin must be in `CLOUD_CONSOLE_CORS_ORIGINS`.
+
 ## Runtime AI Planner

 The Host Agent reuses the local Runtime planner. AI planning is disabled by