ERPBridge console

The console starts in light mode and uses green as its brand accent. Its sidebar can be collapsed on wide screens and becomes an accessible navigation drawer on small screens.

bridgectl web starts a read-only local console for configured ERPBridge contexts. The workspace groups Monitor (Overview, Logs, Metrics), Inventory (Contexts, Tools, Plugins), and Diagnose (Integration topology). The homepage shows context health, freshness, safe operational KPIs, and links into the investigation surfaces. Use bridgectl for mutations such as applying tools, flushing cache, invoking tools, and managing tokens.

Start

bridgectl web

The command binds to 127.0.0.1 on an available port and opens the default browser. Use these options when needed:

bridgectl web --no-open  # keep the browser closed
bridgectl web --url      # print the URL without opening the browser
bridgectl web --dev      # proxy frontend development traffic to Vite

The process stops on interrupt or termination. The console does not listen on a remote address and does not discover Kubernetes, Docker, or cloud deployments.

Security boundary

The console is a local backend-for-frontend. It keeps ERPBridge bearer tokens, ERP credentials, registry credentials, and raw upstream responses on the CLI side. Each launch creates a one-time high-entropy capability. The URL carries this capability in a fragment; the browser removes the fragment and sends it in X-ERPBridge-Console-Capability for data and log-stream requests.

The server validates the exact loopback Host and same-origin Origin. It validates configured upstream URLs, disables redirects, forwards no browser headers, allows only fixed read operations, and bounds response sizes. It does not provide routes to apply or delete tools, flush cache, invoke tools, create or revoke tokens, deploy plugins, or restart a deployment.

Data and topology

The console reads named bridgectl contexts. Health, metrics, and tools use the configured MCP server; cache and logs use the management server. Optional server metadata comes from /api/info. Missing optional endpoints show as unavailable and do not expose upstream error bodies.

The Overview dashboard starts with context health and freshness, followed by safe tool, cache, server, and current-session activity summaries. Failed live refreshes retain the last safe values and identify them as stale. Logs, tools, plugins, and bindings provide shared search/filter surfaces and distinguish empty results from filtered results.

The topology matches sanitized tool definitions to local API registry entries and shows exact plugin binding relationships when the plugin API is available. It labels API relationships exact, base-prefix, ambiguous, or unresolved. For generated tools that share an ERP base, register the API at that base/root URL. A path-specific registration only verifies that path and can leave other working tool paths unresolved. The canvas starts with a bounded component overview: one safe ERP API component per registration, its MCP tool count, ERP endpoint count, and a match-state summary. Select a component or MCP tool in the sidebar to show the chain from MCP tool to ERP API component to exact method/path endpoint, plus bindings and plugins. Selecting an MCP tool narrows the canvas to its direct execution path: MCP transport, that tool, its ERP API component, its exact ERP endpoint, and any attached plugin binding and plugin. The relationship table remains complete. High-cardinality tool, binding, and plugin relationships collapse into expandable groups. Escape or the back control returns to the overview. Use Show filters to reveal search and facet filters for node type, match confidence, and context state.

React Flow renders the read-only canvas and ELK computes layered, relationship-aware positions. The component sidebar and inspector sit below the full-width canvas to preserve horizontal graph space. Entity cards use consistent structure, while status icons, text, accent rails, and semantic tones communicate relationship state without relying on color or unique polygons. Exact relationships have no permanent labels, inferred relationships are static dashed edges, and unrelated relationships are dimmed while a path is selected. The minimap appears only for large focused graphs. Selecting a node or edge highlights the related path and opens a safe inspector with source, target, authority, context state, and endpoint paths. It does not claim cross-context ownership when the registry has no context field, and it shows paths rather than full upstream URLs. A keyboard-accessible relationship list remains available as the complete non-canvas alternative. The BFF reports when safety caps omit graph elements.

The Tools page is a filterable inventory. Select a tool name to open its read-only manifest view. Select View in topology to open that tool's focused execution path. The view presents the tool description and guidance, input fields, execution path, response path, security roles, routing hints, cache settings, and lifecycle metadata. It omits credential references, default values, raw output schemas, and full upstream URLs.

Logs are projected into a fixed safe shape and omit raw payloads and unknown fields. The Logs page shows the most recent valid timestamps first and retains safe events when a live stream is reconnecting. Metrics are live scrape samples. The console calculates rates only from samples observed during the current browser session, keeps label-specific series aligned, and provides responsive trends plus an accessible table. It does not provide historical Prometheus queries or percentile latency.

Plugins

The Plugins page shows exact plugin and binding versions, active state, binding phase, priority, failure policy, timeout, and configuration-present state. Each plugin entry links to an exact-version plugin detail page with matching bindings and unknown health. Plugin metadata does not appear in the Tools inventory. The topology also shows plugin and binding nodes when both read-only plugin list routes are available. The console does not deploy plugins or call plugin endpoints. It never shows plugin endpoints, credentials, static configuration, or raw invocation payloads, and reports plugin health as unknown unless the API provides an approved health field. Older deployments without the plugin routes show an unavailable feature state.