Bohdan Triapitsyn
a5aa32446d
The preview panel worked by proxying a dev server through OpenChamber's own origin and rewriting the HTML that came back. Anything the rewriter did not anticipate broke, and pages that refuse to be embedded never loaded at all. This deletes the proxy (-1604 lines and its tests) and merges the preview and browser panels into one surface backed by a real Chromium view. What the panel is now - A `<webview>` in its own session partition: logins and cookies persist, hot reload works because nothing is rewritten, DevTools are one click away. - Annotation: pick one element, drag a region, or draw freehand, write a note, and it reaches chat with a screenshot of the visible page with the marks on it. - Toolbar: hard reload, page zoom, device sizes, a light/dark switch that applies to the page rather than the app, and cookie/cache clearing scoped to the panel alone. - Several pages at once, each tab showing the page's own favicon, and an address bar that suggests pages already visited in this project. - Dev servers are listed from what is actually listening on the machine, checked against what a project announced, so a server is offered no matter how it was started. One that is still starting is waited for instead of failing. Remote dev servers The desktop app binds a local port and pipes raw bytes to the OpenChamber host over the existing authenticated connection, so the page keeps its own origin at the root of its own host. The reachable set is exactly what discovery reports and is re-checked per connection, so an authenticated client cannot dial arbitrary local services on the host. Links and redirects to another loopback port stay on the machine that served the page. A tunnel that cannot be opened is reported; it is never replaced by the plain loopback URL, which would answer from the user's own machine under a remote address. Agent control Browser actions are a separate `openchamber_web` tool: open, snapshot, click, type, scroll, inspect computed styles, resize between mobile/tablet/desktop, and capture a screenshot into `.openchamber/screenshots/` in the project. The existing `openchamber` tool keeps sessions, worktrees and scheduled tasks. Each has its own setting in the new Settings -> General -> OpenChamber Tools section, and the plugin is not injected at all when both are off. Capability belongs to the connected client, not to configuration: a client declares on its event stream that it can drive a page, which only a Chromium host does. Exactly one client performs each request — it claims the request before acting, and the first claim wins — because deciding by whose result arrives first would be too late for a click that already happened. No client listening is answered immediately with an explanation rather than a timeout. Runtime boundaries Web tabs get a plain iframe that can display a page but not inspect one. The VS Code extension no longer offers the surface at all, since nothing that makes the panel worth having works there. Mobile is unaffected. Native boundary Camera, microphone, location and device-picker requests from panel pages are denied — Electron grants them by default when no handler is set, and the panel loads whatever address the user types. Page capture, appearance emulation and storage clearing verify that their target belongs to the panel's own session instead of trusting a web-contents id from the renderer. Persisted state Stored `preview` tabs migrate to `browser` (v13 -> v14). Context panel tab limits are now per surface, so filling one surface no longer evicts another's tabs. Address history is stored per project and per runtime. Documentation `preview.mdx` and `desktop-browser.mdx` rewritten across all locales, the agent tool settings path corrected, new `DOCUMENTATION.md` for the browser-control broker and the dev tunnel, and the `ui-api-decoupling` skill updated where it still described the deleted proxy.
65 lines
3.7 KiB
Markdown
65 lines
3.7 KiB
Markdown
# OpenChamber Control Service
|
|
|
|
## Purpose
|
|
|
|
This module owns the typed control contract shared by the OpenChamber CLI and
|
|
the managed OpenCode `openchamber` tool. Both adapters delegate to
|
|
`createOpenChamberControlService()`; neither adapter may call or spawn the
|
|
other.
|
|
|
|
## Boundaries
|
|
|
|
- `service.js` validates and executes the fixed project, model, session, and
|
|
scheduled-task action allowlist. `actions.js` marks CLI-only actions with
|
|
`agentExposed: false` (currently `schedule.status`); the agent tool consumes
|
|
the filtered `OPENCHAMBER_AGENT_TOOL_*` exports. `schedule.toggle` requires
|
|
the `disabled` boolean and replaces separate enable/disable actions;
|
|
`schedule.list` also returns scheduler status as `scheduler`.
|
|
- `routes.js` is the authenticated CLI HTTP adapter. It forwards one action,
|
|
preserves service status and partial-result details, and propagates request
|
|
cancellation.
|
|
- `../agent-tool/runtime.js` is the managed-tool adapter. It wraps service
|
|
results in the versioned native-tool envelope and uses a separate ephemeral
|
|
loopback credential.
|
|
- `../openchamber-sessions/routes.js` and `../scheduled-tasks/service.js` own
|
|
their domain operations and are composed into this service.
|
|
|
|
## Invariants
|
|
|
|
- Session status and messages come from official directory-scoped OpenCode
|
|
APIs. Message output includes only ordered `text` parts.
|
|
- Wait never treats an initial idle response as completion after dispatch. It
|
|
requires observed activity or a newly completed assistant message.
|
|
- Timeout and cancellation are failures, never authoritative idle results.
|
|
- Validation that protects side effects runs before session creation or
|
|
dispatch. An explicitly requested model, agent, or variant is checked against
|
|
the directory's own OpenCode agent and provider lists before any session,
|
|
worktree, or goal is created, because `prompt_async` accepts an unusable
|
|
selection and then fails only on the event stream. A failed or empty lookup
|
|
never turns a valid selection into a rejection.
|
|
- `promptDispatched` reports an observed dispatch, never an accepted request.
|
|
After `prompt_async` the service confirms a new user message reached the
|
|
session; when it does not, the result reports `promptDispatched: false` with
|
|
`promptError` instead of claiming success.
|
|
- Send and fork dispatches without an explicit model/agent/variant reuse the
|
|
target session's last user-message selection before falling back to the
|
|
configured defaults; only session creation resolves defaults directly.
|
|
- Usage errors name the missing or conflicting input so CLI and agent-tool
|
|
callers can correct an invalid request without an upfront usage manual.
|
|
- Explicit `projectId` or `directory` scope takes precedence over the managed
|
|
tool's current-session directory fallback; the fallback never creates a
|
|
conflicting second scope.
|
|
- One failed directory status lookup produces `unknown` for only that
|
|
directory and does not erase other session results.
|
|
- Destructive session/worktree deletion and project-path registration are not
|
|
part of the action contract.
|
|
- `browser.capture` writes its image on the server, into
|
|
`.openchamber/screenshots/` under the scoped project directory, and returns
|
|
the project-relative path rather than the image bytes. The client that took
|
|
the picture may be on a different machine than the repository, and a path is
|
|
what an answer, a commit, or a review can use; base64 in a tool result cannot
|
|
be any of those. The agent's label is reduced to a filename fragment, never
|
|
used as a path. The result also states how to present the image, because chat
|
|
renders the image paths written in a finished answer below that message —
|
|
saving the file is not what shows it to anyone.
|