Class BowireInterceptRailContribution

Namespace
Kuestenlogik.Bowire.Interceptor
Assembly
Kuestenlogik.Bowire.Interceptor.dll

Intercept rail contribution (v2.2 rail-IA refactor). Replaces the previous Mocks + Traffic rails (plus the already-hidden Intercepted + Proxy descriptors) with a single rail whose four sub-tabs cover the whole "what do I do with live traffic" surface.

public sealed class BowireInterceptRailContribution : IBowireRailContribution
Inheritance
BowireInterceptRailContribution
Implements
Inherited Members

Remarks

Sub-tabs (locked order):

  • Captured — passive observation of flows captured by UseBowireInterceptor() (was Traffic → "Flows").
  • Live overrides — selective response substitution inside the interceptor pipeline (was Traffic → "Mock Rules").
  • Mock servers — standalone mock-server-from-recording hosts (was the entire Mocks rail). Rendered by the Kuestenlogik.Bowire.Mock package's JS fragment when present; degrades to an empty "Mock package not loaded" state otherwise.
  • Settings — interceptor / proxy config (was Traffic → "Settings").

A given Bowire process is NEVER both Standalone AND Embedded at the same time — deployment shape is fixed by how Bowire was launched. The Settings sub-tab reads __BOWIRE_CONFIG__.embeddedMode on every render and surfaces whichever config (loopback / external proxy URL vs. UseBowireInterceptor middleware status) makes sense for the active mode.

SortIndex inherits the slot Traffic occupied (950) so the merged rail's icon lands where operators already trained their muscle memory. The boot-migration block in prologue.js rewrites legacy ids (mocks, traffic, intercepted, proxy) to intercept on first paint.

Constructors

BowireInterceptRailContribution() 

public BowireInterceptRailContribution()

Properties

DisplayName

Human-readable label shown in the rail tooltip + Settings.

public string DisplayName { get; }

Property Value

string

Group

Visual group the rail belongs to. Adjacent rails with different group values get a divider between them. Built-in groups: "work", "scenarios", "quality", "hardening". New groups land at the bottom of the rail by default.

public string Group { get; }

Property Value

string

IconKey

Icon key from the workbench's SVG-icon catalogue (e.g. "house", "discover", "shield"). Resolved JS-side via svgIcon(key). Unknown keys fall back to a generic square placeholder.

public string IconKey { get; }

Property Value

string

Remarks

Inherits the trafficLight glyph the operator already learned for the Traffic rail in the same slot. The Mocks-only glyph is dropped — Mock servers becomes one sub-tab inside this rail, not a peer-level surface.

Id

Stable identifier (e.g. "discover", "recordings", "security"). Must match the rail-mode id the JS bundle uses for routing — operators' localStorage.bowire_rail_mode values + deep links key off this. Case-sensitive (snake-lower).

public string Id { get; }

Property Value

string

MainPaneRendererKey

Identifier of a JS-side function the rail package's JS fragment registers on window.__bowireRailRenderers at load time. The core renderMain dispatcher looks up the renderer by id and invokes it instead of hard-coding the per-rail branch. Empty / null means "no rail-owned renderer; fall back to the core dispatcher arm".

public string? MainPaneRendererKey { get; }

Property Value

string

Remarks

Convention: railId + 'Main' (e.g. "recordingsMain", "benchmarksMain"). The hosted JS fragment writes window.__bowireRailRenderers["recordingsMain"] = function () { ... }; inside the shared IIFE. The renderer takes no arguments and returns the DOM root for the main pane.

SidebarKind

Sidebar template the rail renders. Recognised values: "none", "services", "collections", "environments", "recordings", "mocks", "workspaces", "sources", "benchmarks", "flows", "proxy", "security", "library". Adding a new value requires a matching arm in render-sidebar.js's dispatcher — see the sidebar.kind comment block in that file.

public string SidebarKind { get; }

Property Value

string

SidebarRendererKey

Identifier of a JS-side function the rail package's JS fragment registers on window.__bowireRailRenderers at load time. The core renderSidebar dispatcher looks up the renderer by id and invokes it instead of hard-coding the per-rail branch. Empty / null means "no rail-owned renderer; fall back to the core dispatcher arm" — so the slice can be moved incrementally rail-by-rail without breaking the bundle.

public string? SidebarRendererKey { get; }

Property Value

string

Remarks

Convention: railId + 'Sidebar' (e.g. "recordingsSidebar", "proxySidebar"). The hosted JS fragment writes window.__bowireRailRenderers["recordingsSidebar"] = function () { ... }; inside the shared IIFE. The renderer takes no arguments and returns the DOM root to mount as the sidebar — same contract as the legacy renderRecordingsSidebar() &c. arms.

SortIndex

Sort priority. Lower values appear higher in the rail strip. The built-in catalogue uses 100-step intervals so third-party rails can wedge between two built-ins without re-numbering everything.

public int SortIndex { get; }

Property Value

int