docs: add NuBi use cases section with end-to-end RCA walkthrough (#810)

Add a NuBi Use Cases section under AI & Pre-built Agents, starting with
a single end-to-end Root Cause Analysis walkthrough: a customer-facing
checkout failure traced through triage, knowledge-graph traversal, logs
and traces, down to the offending source code and the fix. Each step
shows the exact question asked and a real NuBi screenshot.

Includes a landing page and links from the AI index. More use cases
(alert fatigue, what-changed, cost/right-sizing, on-call handoffs) to
follow.

Author: mayankpande88

doc-server/docs/features/ai/index.md

@@ -14,6 +14,10 @@ NudgeBee's AI capabilities are **pre-packaged but not a black box** — every ag
 **Prerequisite**: An [LLM provider](../../integrations/LLM/) must be connected for AI features to work. Cloud SaaS users get a managed LLM by default. Self-hosted users can use BYOM (Bring Your Own Model) — see [LLM Integrations](../../integrations/LLM/).
 :::
 
+:::tip See NuBi in action
+Want concrete examples? **[NuBi Use Cases](./use-cases/)** walks through real conversations: the exact questions to ask, how NuBi investigates step by step, and the answers it lands on.
+:::
+
 ## Pre-built AI Assistants
 
 NudgeBee includes four purpose-built AI assistants, each focused on a specific domain:

doc-server/docs/features/ai/use-cases/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "NuBi Use Cases",
+  "position": 2,
+  "link": {
+    "type": "doc",
+    "id": "features/ai/use-cases/index"
+  }
+}

doc-server/docs/features/ai/use-cases/img/uc-checkout-dependency.png

@@ -0,0 +1,100 @@
+---
+sidebar_position: 2
+---
+
+# Find the Root Cause of a Failing Service
+
+Checkout is failing. The alerts are loud: HTTP 500s climbing on `PlaceOrder`. But the checkout pods are green: running, no restarts, nothing in the events. The symptom is in one service; the cause is somewhere else.
+
+This is the investigation NuBi is built for. Below is a single conversation that goes from "checkout is broken" to the exact line of code responsible, and the fix. You ask in plain language and drill down on what comes back.
+
+---
+
+## Start with the symptom
+
+Ask the question you'd ask a senior engineer.
+
+> **You ask NuBi**
+>
+> Checkout is throwing errors in the demo namespace. What's the root cause?
+
+NuBi checks checkout, then walks the [Knowledge Graph](../../knowledge-graph.md) downstream to follow the failure to its source. It answers with a 5-Whys chain:
+
+![NuBi's root cause analysis for the checkout failure: a 5-Whys causality chain ending at the enabled "Product Catalog Fail" feature flag, with supporting evidence and recommended next steps](./img/uc-checkout-rca.png)
+
+Checkout is healthy. The problem is downstream: `product-catalog` is returning gRPC code 13 (INTERNAL) because a feature flag named **"Product Catalog Fail"** is switched on.
+
+---
+
+## Confirm the dependency
+
+You want it explicit: which service, and how the failure travels.
+
+> **You ask NuBi**
+>
+> Which service is actually causing it, and how are they connected?
+
+![NuBi naming product-catalog as the cause, showing the checkout → product-catalog dependency and explaining how the failure cascades upstream](./img/uc-checkout-dependency.png)
+
+Now the relationship is explicit: `checkout` calls `product-catalog` during `PlaceOrder` to fetch product details, so a failed lookup breaks the order. NuBi traced that through the dependency graph.
+
+---
+
+## Demand evidence
+
+Conclusions are cheap. Ask for proof.
+
+> **You ask NuBi**
+>
+> Show me the exact error and a failing trace.
+
+NuBi pulls the literal error strings and a real failing request, with the endpoint, status, duration, and trace ID:
+
+![NuBi showing the exact error messages and a failing CheckoutService/PlaceOrder trace with HTTP 500 status, duration, and trace ID, next to the causality chain](./img/uc-checkout-trace.png)
+
+`failed to get product "OLJCESPC7Z"`. `13 INTERNAL: Product Catalog Fail Feature Flag Enabled`. A `PlaceOrder` trace returning 500. No hand-waving. The cause is on the record.
+
+---
+
+## Go to the code
+
+The runtime cause is settled. Now find the line.
+
+:::info Needs a source-control integration
+This step uses NuBi's Code Agent, which reads the service's repository. Connect it as a [source-control integration](../../../integrations/Code%20Repository/GitHub/github-integration.md) first. Without it, you still get everything above.
+:::
+
+> **You ask NuBi**
+>
+> Look at the product-catalog source and tell me which code path returns the error.
+
+![NuBi's Code Agent showing the checkProductFailure function in src/product-catalog/main.go, confirming the error is intentionally returned for product OLJCESPC7Z when the feature flag is enabled](./img/uc-code-rca.png)
+
+There it is: `checkProductFailure` returns an error when the requested product is `OLJCESPC7Z` and the flag is on. NuBi went from a customer-facing 500 to a named function in a cited file.
+
+---
+
+## Close it out
+
+> **You ask NuBi**
+>
+> How do I fix it?
+
+NuBi doesn't just name the fix. It hands you the exact steps: which ConfigMap holds the flag, the command to edit it, the field to flip, and what happens after you save.
+
+![NuBi's fix instructions: edit the flagd-config ConfigMap in the demo namespace and change the productCatalogFailure defaultVariant from "on" to "off", with the kubectl command and the resulting config](./img/uc-fix.png)
+
+That's the whole fix. If you have a [ticketing](../../tickets.md) or source-control integration connected, follow with **"open a ticket with the evidence"** or **"open a pull request to fix it"** and NuBi carries the investigation into a tracked action.
+
+---
+
+## Tips for your own investigations
+
+- **Lead with the symptom, not your theory.** Tell NuBi what's failing and let it find the cause. "Checkout is erroring" beats "is product-catalog down?", because you don't yet know it's product-catalog.
+- **Drill down, don't restart.** NuBi keeps the thread. "Which service?" → "show me a trace" → "now the code" gets further than three cold questions.
+- **Always ask for the trace.** A failing trace ID turns a plausible answer into a provable one.
+- **Name the scope.** A namespace or service in the question makes the answer faster and sharper.
+
+---
+
+That whole chain ran in one conversation across several agents: triage, knowledge-graph traversal, a failing trace, the offending code. Along the way NuBi recovered from a failed log fetch on its own and compressed its own working context to stay focused. You stitched nothing together; you just asked.

doc-server/docs/features/ai/use-cases/img/uc-checkout-rca.png

@@ -0,0 +1,26 @@
+---
+sidebar_position: 1
+---
+
+# NuBi Use Cases
+
+Real conversations with **NuBi**, NudgeBee's SRE AI Agent. You see the actual questions you ask, what comes back, and how NuBi gets there. Every walkthrough is a real investigation against a live workload, captured end to end. Nothing here is staged.
+
+:::info Before you start
+NuBi chat needs an [LLM provider](../../../integrations/LLM/) connected, plus a [Kubernetes cluster](../../../installation/agent/installation/) with an [observability source](../../../integrations/Observability/). Cloud SaaS users get a managed LLM by default. A few use cases need an extra integration, such as source control for code analysis or ticketing to open tickets. These are called out where they apply.
+:::
+
+## Available now
+
+- **[Find the Root Cause of a Failing Service](./incident-rca.md)**. A service is throwing errors and you don't know why. NuBi triages it, traces the failure across services through the Knowledge Graph, proves it with logs and traces, and points to the exact line of code. One conversation, symptom to fix.
+
+More use cases are on the way: alert-fatigue audits, "what changed after a deploy", cost and right-sizing, on-call handoffs.
+
+## How NuBi answers
+
+A few things worth knowing so you get better answers:
+
+- **It investigates, it doesn't look up.** NuBi runs real tools like kubectl, logs, traces, the Knowledge Graph, and code, then reasons over what it finds. Ask it what's wrong, not where to look.
+- **It holds the thread.** Within a conversation, follow-ups build on what it already found. Start broad, then drill down.
+- **It scopes to what you name.** Mention the namespace or service and the answer comes back faster and sharper.
+- **You don't need exact phrasing.** Plain language is fine. The prompts in these pages are starting points, not commands.