feature: DBA Dash AI Assistant — Multi-provider LLM orchestration, SQL diagnostic tools, Windows service hosting & GUI integration

[goldenjacob]

Summary

This PR introduces the DBA Dash AI Assistant — a self-hosted AI microservice that sits alongside DBA Dash and gives on-call DBAs a single natural-language interface for triaging SQL Server environments. It runs 10 structured SQL diagnostic tools against the DBA Dash repository database, ranks and scores the evidence, and uses an LLM (Azure OpenAI or Anthropic Claude) to produce concise, operator-ready markdown responses with immediate actions, watch list items, root-cause analysis, and a confidence rating.

No data ever leaves your environment unless you have configured an LLM endpoint — and even without one, the structured tool results are still returned to the GUI.

---

Architecture

The feature is split cleanly across two parts:

Request flow

1. User types or selects a question in the GUI AI Assistant tab.
2. GUI POSTs to POST /api/ai/ask on http://localhost:5055.
3. AiIntentRouter selects one or more SQL tools based on the question.
4. SqlToolExecutor runs parameterized queries against the DBA Dash repository DB.
5. AiEvidenceRanker scores and orders findings by severity/relevance.
6. AiConfidenceScorer produces a High/Medium/Low confidence rating.
7. If an LLM is configured, OpenCodeChatClient calls the provider with a DBA-specialist system prompt + evidence JSON.
8. Markdown response is returned to GUI and rendered in a WebView2 panel.

---

New Project: DBADashAI

A new ASP.NET Core (.NET 10) project that runs as a Windows service (via UseWindowsService()) or as a console application for local development.

SQL Diagnostic Tools (10 total)

All tools implement IAiTool and query the DBA Dash repository database:

Tool	Data queried
ActiveAlertsSummaryTool	Current unresolved and recently resolved alerts across all instances
AgentJobAlertsTool	Recent SQL Agent job failures and error messages
BlockingSummaryTool	Active blocking chains, head blockers, wait times
DeadlocksSummaryTool	Recent deadlock graph events
SlowQueriesSummaryTool	Top queries by duration/CPU/reads from query store
WaitsSummaryTool	Wait stats broken down by instance and wait type
BackupsRiskSummaryTool	Databases with missing, stale, or unchecked backups
DrivesRiskSummaryTool	Drives by available space, growth rate, and time-to-full
ConfigDriftSummaryTool	Configuration values that differ from baselines across instances
SqlToolExecutor	Shared execution pipeline, connection management, and row limiting

API Endpoints

Method	Path	Description
GET	/api/ai/health	Liveness check — returns { status: "ok", utc: ... }
GET	/api/ai/diagnostics	Config diagnostics — shows provider, redacted keys, endpoints
GET	/api/ai/test-anthropic	Live connectivity test to the configured Anthropic endpoint
GET	/api/ai/tools	Lists all registered tool names and metadata
POST	/api/ai/ask	Main ask endpoint — takes question, tool override, maxRows, includeSummary
POST	/api/ai/proactive-digest	Runs all tools and returns a full environment health digest
POST	/api/ai/feedback	Submit helpful / not-helpful feedback for an answer
GET	/api/ai/feedback	Retrieve recent stored feedback records

LLM System Prompt

The DBA-specialist system prompt (OpenCodeChatClient.cs) instructs the LLM to:

• Lead with the most critical finding
• Group findings by severity: CRITICAL / WARNING / INFORMATIONAL
• For AGs: comment on replica sync, failover risk, RPO/RTO impact
• For restarts: distinguish planned maintenance vs. crash
• For blocking/waits: name the wait type and explain the workload it indicates
• For storage: give a time-to-full estimate
• End with a prioritized action plan: next 15 minutes / 1 hour / 24 hours
• Always name instances, databases, jobs — never give generic advice
• Include a confidence rating with a one-line reason

Output format enforced:
🔴 Immediate Actions Required
⚠️ Watch List (Next 1–4 Hours)
📋 Housekeeping (Next 24 Hours)
Root Cause Analysis
Prioritized Action Plan

---

LLM Provider Support

Three providers are supported. They are tried in fallback order unless AI:Provider forces a specific one.

1. Azure OpenAI ✅ Recommended

An Azure OpenAI resource deployed via Azure Foundry with a chat-capable model.

Required settings:
{ "AzureOpenAI": { "Endpoint": "https://.openai.azure.com", "ApiKey": "", "Deployment": "", "ApiVersion": "2024-02-15-preview" } }

All three of Endpoint, ApiKey, and Deployment must be non-empty.

Azure Foundry setup checklist:

1. Create an Azure OpenAI resource in your subscription.
2. Deploy a chat-capable model (e.g. GPT-4o, GPT-4, GPT-3.5-Turbo) under a named deployment.
3. Copy the endpoint URL, API key, and deployment name.
4. Paste into appsettings.json under AzureOpenAI.
5. Set AI:Provider to AzureOpenAI.
6. Restart DBADashAI.dll and verify via GET /api/ai/health.

---

2. Anthropic Claude (direct or via Azure Foundry)

Supports both the native Anthropic API and Azure AI Foundry proxied Anthropic deployments.

Required settings:
{ "AI": { "Provider": "Anthropic" }, "Anthropic": { "BaseUrl": "https://api.anthropic.com", "ApiKey": "", "Model": "", "Version": "2023-06-01", "MaxTokens": "1024" } }

For Azure Foundry Anthropic proxy, use the base URL without /v1/messages:
{ "Anthropic": { "BaseUrl": "https://.services.ai.azure.com/anthropic/", "ApiKey": "", "Model": "" } }

The client automatically detects Foundry endpoints (.services.ai.azure.com) and switches the auth header from x-api-key to api-key.

A live connectivity test endpoint is available: GET /api/ai/test-anthropic.

---

3. OpenCode (optional)

A self-hosted or third-party OpenAI-compatible endpoint.
{ "OpenCode": { "BaseUrl": "http://localhost:11434/v1", "ApiKey": "optional", "Model": "llama3" } }

---

Provider selection and fallback

AI:Provider controls which provider is used. Leave empty for auto-fallback:
{ "AI": { "Provider": "" } }

Fallback order (first fully-configured provider wins):

1. AzureOpenAI
2. Anthropic
3. OpenCode

If no provider is configured, tool results are returned without an LLM summary (the structured evidence is still shown in the GUI JSON panel).

---

Full appsettings.json template

{ "ConnectionStrings": { "Repository": "Server=;Database=DBADash;Integrated Security=true;Encrypt=true;TrustServerCertificate=true;" }, "AI": { "Provider": "", "FeedbackStorePath": "", "RunbookBaseUrl": "" }, "AzureOpenAI": { "Endpoint": "", "ApiKey": "", "Deployment": "", "ApiVersion": "2024-02-15-preview" }, "Anthropic": { "BaseUrl": "", "ApiKey": "", "Model": "", "Version": "2023-06-01", "MaxTokens": "1024" }, "OpenCode": { "BaseUrl": "", "ApiKey": "", "Model": "" } }

---

DBADashGUI Changes

New AI Assistant Tab (DBADashGUI/AI/AIAssistantControl.cs)

• Quick-start question library — dropdown with 16 pre-written DBA questions
  (covering alerts, blocking, deadlocks, agent jobs, backups, drives, waits, config drift, slow queries, and proactive digests)
• Free-text question box — type any question
• Rendered tab — LLM markdown response rendered in WebView2 (Markdig pipeline)
• Raw tab — raw markdown text for copy/paste
• JSON panel (optional, off by default) — full tool output for debugging
• Status bar + progress indicator — shows request state and errors
• Configurable via DBADashGUI/App.config:

---

ServiceConfig Changes

New AI Service Tab (DBADashServiceConfig/ServiceConfig.cs)

• Install, Start, and Stop the DBADashAI Windows service directly from the ServiceConfig UI — no need to open an admin command prompt.
• Live service status label refreshed on tab load.
• Admin manifest (app.manifest) added so the ServiceConfig tool requests elevation automatically — required for Windows service management.

---

Documentation

Docs/AI-Assistant.md — 300+ line end-to-end guide covering:

• Architecture and request flow diagrams
• Prerequisites (DB access, .NET 10 runtime, optional LLM)
• Full appsettings.json configuration reference for all three providers
• Azure Foundry setup checklist step-by-step
• App.config GUI settings reference
• How to run as a Windows service vs. console app
• All API endpoint reference
• Local dev workflow
• Troubleshooting (connection failures, missing summaries, slow responses)
• Security notes (secrets management, least-privilege DB access)

README.md — updated with AI Assistant section.

---

Security Considerations

• API keys are never logged or returned by any endpoint; GET /api/ai/diagnostics masks key values as ***set***
• Connection strings in diagnostic output are automatically scrubbed of Password, Pwd, and ApiKey values via regex
• No data is sent to any external service unless a cloud LLM provider is configured
• DB access uses the existing DBA Dash repository connection string — recommend a read-only SQL login scoped to the repository database for production use
• Do not commit appsettings.json with real keys — use environment-specific config or environment variables in production

---

Files Changed

43 files changed | 3,256 insertions(+) | 9 deletions(-)
New project: DBADashAI/ (entire project — ASP.NET Core, .NET 10, Windows service)
Modified: DBADashGUI/AI/AIAssistantControl.cs ← new AI tab control DBADashGUI/App.config ← AI config keys DBADashGUI/Main.cs ← tab registration DBADashServiceConfig/ServiceConfig.cs ← AI service management tab DBADashServiceConfig/app.manifest ← admin elevation request DBADashServiceConfig/*.csproj ← dependency updates
Docs: Docs/AI-Assistant.md ← new, full setup guide README.md ← AI Assistant section added

---

Testing

A real sample response from a live environment is included in DBADashAI/ChatFeedback.txt — the question "Summarize current DBA risks for the next 24 hours" produced a full multi-instance analysis covering AG health events, SQL Server restarts, blocking, and acknowledgement hygiene with a confidence rating of Medium.

To test locally:

1. Set ConnectionStrings:Repository in DBADashAI/appsettings.json
2. Run dotnet DBADashAI.dll --urls http://localhost:5055
3. GET http://localhost:5055/api/ai/health → expect { "status": "ok" }
4. GET http://localhost:5055/api/ai/diagnostics → verify provider config
5. Launch DBADash.exe → open AI Assistant tab → ask a question

[DavidWiseman]

Hi, thank you for the pull request. This one might take some time to review. One urgent thing for your attention - git retains a full history of commits. Some of the commits look like they contain sensitive information. I would recommend squashing these commits and force-pushing the changes. Also assume any sensitive information is compromised.

[goldenjacob]

Thank you very much! I'm definitely newer to this and thought I had everything sanitized, but ran Copilot to help track through and it found the entries. Thankfully there were no secrets in there. I have force pushed a sanitized update. Would you mind running the check again?

[DavidWiseman]

It was this commit that caught my attention by chance.
7b53943
It looks like there might still be some servername references. Line 42 in particular might be worth attention.

If you have GitHub desktop, you can goto the History and check the changes in each commit. Or you can check here for this PR.

[goldenjacob]

I can't quite figure out how to get all of this removed. I have sanitized everything I can, added files to gitignore, but I still see that commit with the information. If you have any advice I will gladly take it, otherwise I suppose I should close the PR and wipe my fork and start over clean.

[goldenjacob]

I just figured out how to do a squash commit and force push, hopefully that does it

[goldenjacob]

I made some fixes to the way it creates the service for the AI agent, and tried to more closely align the GUI elements in the config tool and main GUI's new "AI Assistant" tab. From my testing on a machine, it all works well together. In a future iteration I would probably want to make the example categories and questions table driven from the database with an initial set populated so they aren't hard coded.

[goldenjacob]

Closed this because I spent a lot of time on a rewrite to align with the existing styling, table driven example questions for the AI, etc. I have a new branch and will create a PR from it.