let5see/clawdbot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(webchat): auto-start at root

Browse Source
This commit is contained in:
Peter Steinberger
2025-12-09 21:07:53 +00:00
parent 3ee3f7e30b
commit bd41cf377a
7 changed files with 43 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/mac/webchat.md
View File

@@ -14,7 +14,7 @@ The macOS menu bar app opens the gateway’s loopback web chat server in a WKWeb
- WK logs: navigation lifecycle, readyState, js location, and JS errors/unhandled rejections are mirrored to OSLog for easier diagnosis.
## How it’s wired
- Assets: `apps/macos/Sources/Clawdis/Resources/WebChat/` contains the `pi-web-ui` dist plus a local import map pointing at bundled vendor modules and a tiny `pi-ai` stub. Everything is served from the gateway at `/webchat/*`.
- Assets: `apps/macos/Sources/Clawdis/Resources/WebChat/` contains the `pi-web-ui` dist plus a local import map pointing at bundled vendor modules and a tiny `pi-ai` stub. Everything is served from the gateway at `/` (legacy `/webchat/*` still works).
- Bridge: none. The web UI calls `/webchat/rpc` directly; Swift no longer proxies messages. RPC is handled in-process inside the gateway (no CLI spawn/PATH dependency).
- Session: always primary; multiple transports (WhatsApp/Telegram/Desktop) share the same session key so context is unified.

7
docs/webchat.md
View File

@@ -15,9 +15,10 @@ Updated: 2025-12-09
- `webchat.gatewayPort` config can point at a non-default Gateway port if needed.
## Endpoints
- `GET /webchat/info?session=<key>` → `{ port, sessionId, initialMessages, basePath }` plus history from the Gateway session store.
- `GET /webchat/*` → static assets.
- `POST /webchat/rpc` → proxies a chat/agent action through the Gateway connection and returns `{ ok, payloads?, error? }`.
- UI is now served at the root: `http://127.0.0.1:<port>/` (legacy `/webchat/` still works).
- `GET /webchat/info?session=<key>` (alias `/info`) → `{ port, sessionId, initialMessages, basePath }` plus history from the Gateway session store.
- `GET /` (or `/webchat/*`) → static assets.
- `POST /webchat/rpc` (alias `/rpc`) → proxies a chat/agent action through the Gateway connection and returns `{ ok, payloads?, error? }`.
## How it connects
- On startup, the WebChat server dials the Gateway WebSocket and performs the mandatory `hello` handshake; the `hello-ok` snapshot seeds presence + health immediately.