Skip to content

Chart and Browser Automation Bridge

Private / test stageOwner Frontend / productLast verified frontend@99f49dae6368414896bf2858cb848f5a7c7fcf98

The ONIX web client installs a small, closed set of browser-automation hooks that let a locally attached development or support tool read, and within a fixed and named capability list, drive parts of the already-rendered page. This page describes that surface as it exists in the onix-frontend repository only — the client/browser half of a split that also has a separate backend half, described at ../backend/mcp.md.

Why this page exists, and what is not yet settled

This page is the required frontend counterpart of a documentation split: the legacy "MCP tooling" page was split into a backend-owned page and this frontend-owned page, with a stated visibility of "private preview, public only after both the backend MCP runtime owner and this frontend bridge owner sign off." This documentation project's own general policy is that no page anywhere claims a named individual owner's sign-off; publication instead rests on a machine-readable evidence packet bound to immutable source objects, plus independent verification and disclosure review of that same evidence — and that substitute is what this page and its evidence packet provide for the frontend half. What this page's own row still lacks is the second, backend-side half of that pair: an equivalent reviewed accounting of the backend MCP runtime, cross-checked against this page rather than merely living beside it. Until that exists, this page's status stays private-test-stage rather than verified, consistent with how this section treats other reachable-but-secondary surfaces (/workspace, /lab, /admin). See evidence/frontend/integration-requests.md for the outstanding navigation and route-contract follow-up this split still needs on the publishing side.

What the bridge is — and is not

Every hook described here is a fixed, named, typed JavaScript object attached to the page while a particular widget is mounted, meant to be driven by a locally attached automation tool acting through the browser's own developer tooling against a page a user already has open — not a network service, not a remotely reachable endpoint, and not part of the same-origin backend proxy described in gateway-realtime.md. The chart-scoped implementation states its own design rule directly: it is a second, closed, enumerated capability namespace, with one typed async method per capability, no free-form code execution, and no open-ended method dispatch. Every other per-widget hook on this page follows the same rule in its own source: a hook can only ever reach a capability its own handle interface already declares, so a hook cannot be talked into calling something the interface itself does not name. This review found no capability in any of these frontend hooks that runs a caller-supplied string as code or accepts an unbounded method name.

The chart-scoped surface

Two separate, chart-only hooks exist, depending on which console currently has a chart mounted:

  • The two older consoles (/lab, /workspace) install a read-only hook that reaches exactly the same six enumerated /bars query controls (instrument_id, bar_type, start, end, after_sequence, limit) those consoles' own filter form already exposes. Every path this hook can take ends in a GET; the backend route those reads go through refuses every other HTTP method, so there is no write path through it at all.
  • The licensed Advanced Charts widget on /dashboard and /workspace-v2 installs a second, broader hook: it hands back the charting library's own widget object for the same symbol, resolution, and visible-range reads/writes the visible symbol search and timeframe control already perform, plus a separate, narrower closed capability list scoped to instrument search, resolution listing, a current chart-state read, and indicator/study management (listing, adding, removing, and adjusting the inputs of a study) against the same indicator catalog the visible UI itself offers. Neither reaches a capability a click on the visible chart does not already reach, and the indicator/study list a caller can act on is the same closed catalog the chart's own study picker is built from.

Other enumerated per-widget hooks on /dashboard

Beyond the chart, three further widget-scoped hooks install themselves only while their own widget is mounted, each documented in its own source as reaching "exactly what the visible widget already reaches" and no more:

  • One for the screener workspace — reading currently visible rows, the feature registry, and pattern observations, and acting on an already-loaded screen definition (applying it, resetting it, changing its sort, or changing which row or pattern is selected) — the same actions the screener's own visible controls perform.
  • One for venue connections and the order ticket — reading the connection/account/runtime state already on screen, and, on a deployment configured private-operator, reaching the same account-selection, connection-console, and order-entry actions the visible Connections widget and Order Ticket widget already reach (see dashboard-and-workspaces.md for those widgets). This hook adds no capability beyond what that visible UI performs, and every write it can reach still crosses the same same-origin proxy described in gateway-realtime.md, which refuses every mutating backend route unless the host itself is configured private-operator — a public, read-only deployment relays none of it. This page does not further enumerate that hook's method names or call shapes.
  • One for the strategy workbench — draft file reads and writes, immutable-revision browsing, and backtest submission/selection, scoped to exactly the strategy/backtest actions the Manager, Studio, and Backtests widgets already perform (see strategies-and-backtesting.md).

What is out of scope here

This bridge does not implement, and does not add, order-matching, portfolio accounting, or an execution engine of its own — see index.md for the frontend's boundary statement in general. Where any write reach exists in the hooks above, it is bounded by the same private-operator gate and the same same-origin proxy that bounds the rest of the product, not a second path to the backend. This page also does not cover, and its evidence pin does not extend to: the backend's own MCP tool/runtime process, documented separately at ../backend/mcp.md; or the native macOS host's local MCP surface — including whatever diagnostic scopes it may expose disabled by default for support use — documented at ../mcp/index.md and ../mcp/macos-host.md. Nothing in those two surfaces was independently re-verified for this page, and nothing here should be read as describing them.

Status

The bounded, chart- and widget-scoped facts above are checked against the frontend source at pin 99f49dae6368414896bf2858cb848f5a7c7fcf98. The page as a whole carries private-test-stage status rather than verified because the A1 disposition that created this page called for a joint backend-plus-frontend publication sign-off that has not been recorded — see evidence/frontend/frontend-evidence.json for the individual claim-level evidence and evidence/frontend/integration-requests.md for what remains for the site's navigation and route contract.

Evidence and source pins for this page

Private / test stage. Exists, but is private, internal or test-stage only. Not generally available.

Verified on against the following immutable sources:

  • frontend@99f49dae:src/components/chart/chart-mcp-install.ts
  • frontend@99f49dae:src/components/chart-mcp-bridge.tsx
  • frontend@99f49dae:src/gateway/bars-query.ts
  • frontend@99f49dae:src/components/connections-mcp-bridge.tsx
  • frontend@99f49dae:src/screener/bridge.tsx
  • frontend@99f49dae:src/strategy/editor-bridge/editor-mcp-bridge.tsx

Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.