Sidebar Diagnostic Surfaces

BMO’s sidebar uses diagnostic intents to route clicks to the most relevant diagnostic surface instead of always opening a generic panel.

How it works

When you click a sidebar item, BMO checks the current system state and derives the highest-priority DiagnosticIntent:

Priority	Intent	Trigger	Dialog Opened
1	provider_error	Provider health shows error/cooldown	Provider diagnostics
2	mcp_auth_required	MCP connection in error state	MCP connection dialog
3	run_failed	Retained last run ended in failure	Run result review
4	workspace_contention	Workspace conflict detected	Workspace strategy dialog
5	context_pruning_active	Context shedding/pruning active	Context lineage inspector

Which sidebar items

• Provider health indicator → routes to provider diagnostics when error state active
• Protocols / MCP indicator → routes to MCP connection dialog when auth required
• Context / Lineage indicator → routes to context lineage inspector when pruning active
• Run result indicator → routes to run result review when a retained run failed

Live Run rows are not diagnostic-intent routing. During an active run, those rows open the Run Activity dialog as their normal action; diagnostic routing only takes over once BMO is surfacing a retained failure.

Visual hint

When a diagnostic intent is active for a sidebar item, its description shows a ! prefix (e.g., ! openai — cooldown) so you know an actionable diagnostic surface is available.

Fallback behavior

When no diagnostic intent is active, sidebar clicks fall back to their default action (e.g., opening the generic context hub).

Related read-only surfaces

These sidebar rows are not intent-routed; they always open a status report:

• Ripple — /ripple or bmo config show-ripple (Ripple Edits)
• OAI-compat — /openai-compat or bmo config show-openai-compat
• Files — /files or bmo config show-file-tools (File Tools Telemetry)
• Runtime incidents — /incidents for bounded posture; /incident remains capture and /incident-issue remains dry-run issue drafting

Implementation

• Type: DiagnosticIntent (string constants in internal/ui/model/diagnostic_intent.go)
• Registry: maps each intent to a dialog opener function
• Derivation: activeDiagnosticIntent() inspects provider health, MCP state, run UX, and prompt trace segments
• Dispatch: sidebarActionDiagnosticIntent in internal/ui/model/sidebar_actions.go

Visual: intent-derived sidebar routing

Sidebar diagnostic routing

TUI sidebar

Provider health: ! cooldown

Protocols: ! github auth required

Context: pruning active

Run: failed

Workspace: clean

Click providerOpen provider diagnostics, not a generic model panel.

Click protocolsOpen MCP connection/auth dialog.

Click runOpen run result review.

The sidebar is a state-derived control surface: active intent chooses the most useful dialog.

Behavior visual

Intent-derived sidebar routing

Sidebar clicks synthesize the most relevant diagnostic surface from current state.