docs: rewrite user docs, fix modal scroll, webhook URL, and sccache

Rewrite all public documentation to be user-facing only:
- Remove deployment, configuration, and self-hosting sections
- Add guide pages for SBOM, issues, webhooks & PR reviews
- Add reference pages for glossary and tools/scanners
- Add 12 screenshots from live dashboard
- Explain MCP, LLM triage, false positives, human-in-the-loop

Fix edit repository modal not scrollable (max-height + overflow-y).
Show full webhook URL using window.location.origin instead of path.
Unset RUSTC_WRAPPER in agent cargo commands to avoid sccache errors.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/features/ai-chat.md

@@ -1,41 +1,12 @@
-# AI Chat (RAG)
+# AI Chat
 
-The AI Chat feature lets you ask natural language questions about your codebase. It uses Retrieval-Augmented Generation (RAG) to find relevant code and provide accurate, source-referenced answers.
+The AI Chat feature lets you ask natural language questions about your codebase and get accurate, source-referenced answers.
 
-## How It Works
+## What It Does
 
-1. **Code graph** is built for the repository (functions, classes, modules)
-2. **Embeddings** are generated for each code symbol using an LLM embedding model
-3. When you ask a question, your query is **embedded** and compared against code embeddings
-4. The **top 8 most relevant** code snippets are retrieved
-5. These snippets are sent as context to the LLM along with your question
-6. The LLM generates a response **grounded in your actual code**
+AI Chat uses Retrieval-Augmented Generation (RAG) to answer questions about your code. Instead of relying solely on the LLM's training data, it retrieves relevant code from your actual repository and uses it as context for generating answers.
 
-## Getting Started
-
-### 1. Select a Repository
-
-Navigate to **AI Chat** in the sidebar. You'll see a grid of repository cards. Click one to open the chat interface.
-
-### 2. Build Embeddings
-
-Before chatting, you need to build embeddings for the repository:
-
-1. Click **Build Embeddings**
-2. Wait for the process to complete — a progress bar shows `X/Y chunks`
-3. Once the status shows **Embeddings ready**, the chat input is enabled
-
-::: info
-Embedding builds require:
-- A code graph already built for the repository (via the Graph feature)
-- A configured embedding model (`LITELLM_EMBED_MODEL`)
-
-The default model is `text-embedding-3-small`.
-:::
-
-### 3. Ask Questions
-
-Type your question in the input area and press Enter (or click Send). Examples:
+This means you can ask questions like:
 
 - "How does authentication work in this codebase?"
 - "What functions handle database connections?"
@@ -43,37 +14,42 @@ Type your question in the input area and press Enter (or click Send). Examples:
 - "Where are the API routes defined?"
 - "What does the `process_scan` function do?"
 
-## Understanding Responses
+## How RAG Works
 
-### Answer
+In simple terms:
 
-The AI response is a natural language answer to your question, grounded in the actual source code of your repository.
+1. Your codebase is parsed into functions, classes, and modules during graph building
+2. Each code symbol is converted into a numerical representation (an embedding) that captures its meaning
+3. When you ask a question, your question is also converted into an embedding
+4. The system finds the code snippets whose embeddings are most similar to your question
+5. Those snippets are sent to the LLM along with your question as context
+6. The LLM generates an answer grounded in your actual code, not generic knowledge
 
-### Source References
+## Getting Started
 
-Below each response, you'll see source references showing exactly which code was used to generate the answer:
+1. Navigate to **AI Chat** in the sidebar
+2. Select a repository from the grid of cards
+3. If embeddings have not been built yet, click **Build Embeddings** and wait for the process to complete
+4. Once the status shows **Embeddings ready**, type your question and press Enter
 
-- **Symbol name** — The qualified name of the function/class/module
-- **File path** — Where the code is located, with line range
-- **Code snippet** — The first ~10 lines of the relevant code
-- **Relevance score** — How closely the code matched your question (0.0 to 1.0)
+::: tip
+Rebuild embeddings after significant code changes to ensure the AI has access to the latest version of your codebase.
+:::
 
-## Conversation Context
+## Source References
 
-The chat maintains conversation history within a session. You can ask follow-up questions that reference previous answers. The system sends the last 10 messages as context to maintain coherence.
+Below each AI response, you will see source references showing exactly which code was used to generate the answer:
 
-## Configuration
+- **Symbol name** -- the qualified name of the function, class, or module
+- **File path** -- where the code is located, with line range
+- **Code snippet** -- the first several lines of the relevant code
+- **Relevance score** -- how closely the code matched your question (0.0 to 1.0)
 
-| Variable | Description | Default |
-|----------|-------------|---------|
-| `LITELLM_URL` | LiteLLM proxy URL | `http://localhost:4000` |
-| `LITELLM_API_KEY` | API key for the LLM provider | — |
-| `LITELLM_MODEL` | Model for chat responses | `gpt-4o` |
-| `LITELLM_EMBED_MODEL` | Model for code embeddings | `text-embedding-3-small` |
+Source references let you verify the AI's answer against the actual code and navigate directly to the relevant files.
 
-## Tips
+## Tips for Better Results
 
-- **Be specific** — "How does the JWT validation middleware work?" is better than "Tell me about auth"
-- **Reference filenames** — "What does `server.rs` do?" helps the retrieval find relevant code
-- **Ask about patterns** — "What error handling pattern does this project use?" works well with RAG
-- **Rebuild after changes** — If the repository has been updated significantly, rebuild embeddings to include new code
+- **Be specific** -- "How does the JWT validation middleware work?" is better than "Tell me about auth"
+- **Reference filenames** -- "What does `server.rs` do?" helps the retrieval find relevant code
+- **Ask about patterns** -- "What error handling pattern does this project use?" works well with RAG
+- **Use follow-ups** -- the chat maintains conversation history within a session, so you can ask follow-up questions

docs/features/dast.md

@@ -1,10 +1,14 @@
 # DAST Scanning
 
-DAST (Dynamic Application Security Testing) performs black-box security testing against live web applications and APIs. Unlike SAST which analyzes source code, DAST tests running applications by sending crafted requests and analyzing responses.
+DAST (Dynamic Application Security Testing) performs black-box security testing against live web applications and APIs. Unlike SAST which analyzes source code, DAST tests running applications by sending crafted requests and analyzing responses for vulnerabilities.
 
 ## DAST Overview
 
-Navigate to **DAST** in the sidebar to see the overview page with:
+Navigate to **DAST** in the sidebar to see the overview page.
+
+![DAST overview with scan runs and finding counts](/screenshots/dast-overview.png)
+
+The overview shows:
 
 - Total DAST scans performed
 - Total DAST findings discovered
@@ -21,29 +25,29 @@ Navigate to **DAST > Targets** to configure applications to test.
 2. Enter the **base URL** (e.g. `https://staging.example.com`)
 3. Click **Add Target**
 
-### Target Configuration
+### Target Settings
 
 Each target supports these settings:
 
-| Setting | Description | Default |
-|---------|-------------|---------|
-| **Target Type** | WebApp, REST API, or GraphQL | WebApp |
-| **Max Crawl Depth** | How many link levels to follow | 5 |
-| **Rate Limit** | Maximum requests per second | 10 |
-| **Destructive Tests** | Allow DELETE/PUT requests | No |
-| **Excluded Paths** | URL paths to skip during testing | — |
+| Setting | Description |
+|---------|-------------|
+| **Target Type** | WebApp, REST API, or GraphQL |
+| **Max Crawl Depth** | How many link levels to follow |
+| **Rate Limit** | Maximum requests per second |
+| **Destructive Tests** | Allow DELETE/PUT requests |
+| **Excluded Paths** | URL paths to skip during testing |
 
 ### Authentication
 
-DAST supports authenticated scanning with multiple methods:
+DAST supports authenticated scanning so it can test pages behind login:
 
-| Method | Configuration |
-|--------|--------------|
+| Method | Description |
+|--------|------------|
 | **None** | No authentication |
-| **Basic** | Username and password (HTTP Basic Auth) |
-| **Bearer** | Bearer token (Authorization header) |
+| **Basic** | HTTP Basic Auth with username and password |
+| **Bearer** | Bearer token in the Authorization header |
 | **Cookie** | Session cookie value |
-| **Form** | Login URL, username field, password field, and credentials |
+| **Form** | Login form with URL, field names, and credentials |
 
 ::: warning
 Authenticated scans access more of the application surface. Only test applications you own or have explicit authorization to test.
@@ -51,37 +55,15 @@ Authenticated scans access more of the application surface. Only test applicatio
 
 ## Running a DAST Scan
 
-Click the **Scan** button on any target row. The scan runs through these phases:
+Click the **Scan** button on any target row. The scan progresses through:
 
-1. **Crawl** — Discovers pages, forms, and API endpoints by following links and analyzing JavaScript
-2. **Test** — Sends attack payloads to discovered parameters
-3. **Report** — Collects results and generates findings
+1. **Crawl** -- discovers pages, forms, and API endpoints by following links and analyzing JavaScript
+2. **Test** -- sends attack payloads to discovered parameters
+3. **Report** -- collects results and generates findings
 
-The scan uses a headless Chromium browser (the `chromium` service in Docker Compose) for JavaScript rendering during crawling.
+## Viewing DAST Findings
 
-## DAST Scan Agents
-
-The scanner includes specialized testing agents:
-
-### API Fuzzer
-Tests API endpoints with malformed inputs, boundary values, and injection payloads.
-
-### XSS Scanner
-Detects Cross-Site Scripting vulnerabilities by injecting script payloads into form fields, URL parameters, and headers.
-
-### SSRF Scanner
-Tests for Server-Side Request Forgery by injecting internal URLs and cloud metadata endpoints into parameters.
-
-### Auth Bypass Scanner
-Tests for authentication and authorization bypass by manipulating tokens, sessions, and access control headers.
-
-## DAST Findings
-
-Navigate to **DAST > Findings** to see all discovered vulnerabilities.
-
-### Finding List
-
-Each finding shows:
+Navigate to **DAST > Findings** to see all discovered vulnerabilities. Each finding shows:
 
 | Column | Description |
 |--------|-------------|
@@ -92,21 +74,8 @@ Each finding shows:
 | Method | HTTP method (GET, POST, PUT, DELETE) |
 | Exploitable | Whether the vulnerability was confirmed exploitable |
 
-### Finding Detail
-
-Click a finding to see full details:
-
-- **Vulnerability type** and CWE identifier
-- **Endpoint URL** and HTTP method
-- **Parameter** that is vulnerable
-- **Exploitability** — Confirmed or Unconfirmed
-- **Description** — What the vulnerability is and why it matters
-- **Remediation** — How to fix the issue
-- **Evidence** — One or more request/response pairs showing:
-  - The crafted HTTP request (method, URL, headers)
-  - The payload that triggered the vulnerability
-  - The HTTP response status and relevant snippet
+Click a finding to see full details including the CWE identifier, vulnerable parameter, remediation guidance, and evidence showing the exact request/response pairs that triggered the finding.
 
 ::: tip
-Findings marked as **Confirmed** exploitable were verified by the scanner with a successful attack. **Unconfirmed** findings show suspicious behavior that may indicate a vulnerability but could not be fully exploited.
+Findings marked as **Confirmed** exploitable were verified with a successful attack payload. **Unconfirmed** findings show suspicious behavior that may indicate a vulnerability but could not be fully exploited.
 :::

docs/features/graph.md

@@ -1,92 +1,52 @@
 # Code Knowledge Graph
 
-The Code Knowledge Graph feature parses your repository source code and builds an interactive graph of symbols (functions, classes, modules) and their relationships (calls, imports, inheritance).
+The Code Knowledge Graph parses your repository and builds an interactive visualization of its structure -- functions, classes, modules, and how they connect through calls, imports, and inheritance.
 
-## Graph Index
+## What It Shows
 
-Navigate to **Code Graph** in the sidebar to see all repositories. Click a repository card to open its graph explorer.
+The graph maps your codebase as a network of nodes (code symbols) and edges (relationships). It supports Rust, TypeScript, JavaScript, and Python.
 
-## Building a Graph
+**Node types**: Functions, methods, classes, structs, enums, interfaces, traits, modules, and files.
 
-Before exploring, you need to build the graph:
+**Edge types**: Calls (function invocation), imports, inheritance, interface/trait implementation, containment (module contains function), and type references.
 
-1. Open the graph explorer for a repository
-2. Click **Build Graph**
-3. The agent parses all source files and constructs the graph
-4. A spinner shows build progress
+Nodes are color-coded by community -- clusters of highly connected symbols detected automatically using community detection algorithms.
 
-The graph builder supports these languages:
-- Rust
-- TypeScript
-- JavaScript
-- Python
+## How to Navigate
 
-## Graph Explorer
+### Graph Explorer
 
-The graph explorer provides an interactive network visualization.
+1. Navigate to **Code Graph** in the sidebar
+2. Select a repository from the list
+3. If the graph has not been built yet, click **Build Graph** and wait for parsing to complete
+4. The interactive canvas renders with all symbols and relationships
 
-### Canvas
+On the canvas:
 
-The main area renders an interactive network diagram using vis-network:
-
-- **Nodes** represent code symbols (functions, classes, structs, enums, traits, modules, files)
-- **Edges** represent relationships between symbols
-- Nodes are **color-coded by community** — clusters of highly connected symbols detected using Louvain community detection
-- Pan by dragging the background, zoom with scroll wheel
-
-### Node Types
-
-| Type | Description |
-|------|-------------|
-| Function | Standalone functions |
-| Method | Methods on classes/structs |
-| Class | Classes (TypeScript, Python) |
-| Struct | Structs (Rust) |
-| Enum | Enumerations |
-| Interface | Interfaces (TypeScript) |
-| Trait | Traits (Rust) |
-| Module | Modules and namespaces |
-| File | Source files |
-
-### Edge Types
-
-| Type | Description |
-|------|-------------|
-| Calls | Function/method invocation |
-| Imports | Module or symbol import |
-| Inherits | Class inheritance |
-| Implements | Interface/trait implementation |
-| Contains | Parent-child containment (module contains function) |
-| TypeRef | Type reference or usage |
-
-### Statistics
-
-The statistics panel shows:
-- Total node and edge count
-- Number of detected communities
-- Languages found in the repository
-- File tree of the codebase
+- **Pan** by dragging the background
+- **Zoom** with the scroll wheel
+- **Click a node** to open the code inspector panel
 
 ### Search
 
-Search for symbols by name:
-
-1. Type at least 2 characters in the search box
-2. Matching symbols appear in a dropdown
-3. Click a result to highlight it on the canvas and open the inspector
+Type at least 2 characters in the search box to find symbols by name. Click a result to highlight it on the canvas and open the inspector.
 
 ### Code Inspector
 
-When you click a node (on the canvas or from search), the inspector panel shows:
+When you click a node, the inspector panel shows:
 
 - **Symbol name** and kind (function, class, etc.)
 - **File path** with line range
-- **Source code** excerpt from the file
-- **Connected nodes** — what this symbol calls, what calls it, etc.
+- **Source code** excerpt
+- **Connected nodes** -- what this symbol calls, what calls it, what it imports, etc.
+
+### Statistics
+
+The statistics panel shows the total node and edge count, number of detected communities, languages found, and a file tree of the codebase.
 
 ## Use Cases
 
-- **Onboarding** — Understand unfamiliar codebase structure at a glance
-- **Architecture review** — Identify tightly coupled modules and circular dependencies
-- **Security** — Trace data flow from entry points to sensitive operations
-- **Refactoring** — See what depends on code you plan to change
+- **Onboarding** -- understand unfamiliar codebase structure at a glance
+- **Architecture review** -- identify tightly coupled modules and circular dependencies
+- **Security analysis** -- trace data flow from entry points to sensitive operations to understand blast radius
+- **Impact analysis** -- see what depends on code you plan to change before refactoring

docs/features/impact-analysis.md

@@ -1,42 +0,0 @@
-# Impact Analysis
-
-Impact Analysis uses the Code Knowledge Graph to determine the blast radius of a security finding. When a vulnerability is found in a specific function or file, impact analysis traces the call graph to show everything that could be affected.
-
-## Accessing Impact Analysis
-
-Impact analysis is linked from the Graph Explorer. When viewing a repository's graph with findings, you can navigate to:
-
-```
-/graph/{repo_id}/impact/{finding_id}
-```
-
-## What You See
-
-### Blast Radius
-
-A count of the total number of code symbols (functions, methods, classes) affected by the vulnerability, both directly and transitively.
-
-### Entry Points Affected
-
-A list of **public entry points** — main functions, HTTP handlers, API endpoints — that could be impacted by the vulnerable code. These represent the ways an attacker could potentially reach the vulnerability.
-
-### Call Chains
-
-Complete call chain paths showing how execution flows from entry points through intermediate functions to the vulnerable code. Each chain shows the sequence of function calls.
-
-### Direct Callers
-
-The immediate functions that call the vulnerable function. These are the first layer of impact.
-
-## How It Works
-
-1. The finding's file path and line number are matched to a node in the code graph
-2. The graph is traversed **backwards** along call edges to find all callers
-3. Entry points (functions with no callers, or known patterns like `main`, HTTP handlers) are identified
-4. All paths from entry points to the vulnerable node are computed
-
-## Use Cases
-
-- **Prioritization** — A critical vulnerability in a function called by 50 entry points is more urgent than one in dead code
-- **Remediation scoping** — Understand what tests need to run after a fix
-- **Risk assessment** — Quantify the actual exposure of a vulnerability

docs/features/issues.md

@@ -1,72 +0,0 @@
-# Issue Tracker Integration
-
-Compliance Scanner automatically creates issues in your existing issue trackers when new security findings are discovered. This integrates security into your development workflow without requiring teams to check a separate tool.
-
-## Supported Trackers
-
-| Tracker | Configuration Variables |
-|---------|----------------------|
-| **GitHub Issues** | `GITHUB_TOKEN` |
-| **GitLab Issues** | `GITLAB_URL`, `GITLAB_TOKEN` |
-| **Jira** | `JIRA_URL`, `JIRA_EMAIL`, `JIRA_API_TOKEN`, `JIRA_PROJECT_KEY` |
-
-## How It Works
-
-1. A scan discovers new findings
-2. For each new finding, the agent checks if an issue already exists (by fingerprint)
-3. If not, it creates an issue in the configured tracker with:
-   - Title matching the finding title
-   - Description with vulnerability details, severity, and file location
-   - Link back to the finding in the dashboard
-4. The finding is updated with the external issue URL
-
-## Viewing Issues
-
-Navigate to **Issues** in the sidebar to see all tracker issues across your repositories.
-
-The issues table shows:
-
-| Column | Description |
-|--------|-------------|
-| Tracker | Badge showing GitHub, GitLab, or Jira |
-| External ID | Issue number in the external system |
-| Title | Issue title |
-| Status | Open, Closed, or tracker-specific status |
-| Created | When the issue was created |
-| Link | Direct link to the issue in the external tracker |
-
-Click the **Open** link to go directly to the issue in GitHub, GitLab, or Jira.
-
-## Configuration
-
-### GitHub
-
-```bash
-GITHUB_TOKEN=ghp_xxxx
-```
-
-Issues are created in the same repository that was scanned.
-
-### GitLab
-
-```bash
-GITLAB_URL=https://gitlab.com
-GITLAB_TOKEN=glpat-xxxx
-```
-
-Issues are created in the same project that was scanned.
-
-### Jira
-
-```bash
-JIRA_URL=https://your-org.atlassian.net
-JIRA_EMAIL=security-bot@example.com
-JIRA_API_TOKEN=your-api-token
-JIRA_PROJECT_KEY=SEC
-```
-
-All issues are created in the specified Jira project (`JIRA_PROJECT_KEY`).
-
-::: tip
-Use a dedicated service account for issue creation so that security findings are clearly attributed to automated scanning rather than individual team members.
-:::

docs/features/mcp-server.md

@@ -1,155 +1,86 @@
-# MCP Server
+# MCP Integration
 
-The Model Context Protocol (MCP) server exposes compliance data to external LLMs and AI agents. Any MCP-compatible client — such as Claude, Cursor, or a custom agent — can connect and query findings, SBOM data, and DAST results without direct database access.
+Certifai exposes your security data through the Model Context Protocol (MCP), allowing LLM-powered tools to query your findings, SBOM data, and DAST results directly.
 
-## How It Works
+## What is MCP?
 
-The `compliance-mcp` crate runs as a standalone service that connects to the same MongoDB database as the agent and dashboard. It registers a set of **tools** that LLM clients can discover and call through the MCP protocol.
+The Model Context Protocol is an open standard that lets AI tools (like Claude, Cursor, or custom agents) connect to external data sources. Think of it as a way for your LLM to "see" your security data without you having to copy and paste it.
 
-```
-LLM Client  ──MCP──▶  compliance-mcp  ──MongoDB──▶  compliance_scanner DB
-```
+When an MCP client is connected to Certifai, you can ask questions like "Show me all critical findings" or "What vulnerable packages does this repo have?" and the LLM will query Certifai directly to get the answer.
 
-The server supports two transport modes:
+## Why It Matters
 
-| Transport | Use Case | How to Enable |
-|-----------|----------|---------------|
-| **Stdio** | Local development, piped to a CLI tool | Default (no `MCP_PORT` set) |
-| **Streamable HTTP** | Remote deployment, multiple clients | Set `MCP_PORT=8090` |
+Without MCP, getting security data into an LLM conversation requires manual effort -- exporting reports, copying findings, pasting context. With MCP:
+
+- Your AI coding assistant can check for security issues as you write code
+- You can ask natural language questions about your security posture
+- Security data stays up to date because it is queried live, not exported statically
+- Multiple team members can connect their own LLM tools to the same data
+
+## Managing MCP Servers
+
+Navigate to **MCP Servers** in the sidebar to manage your MCP server instances.
+
+![MCP servers management page](/screenshots/mcp-servers.png)
+
+From this page you can:
+
+- **Register** new MCP server instances with their endpoint URL, transport type, and port
+- **View** server configuration, enabled tools, and status
+- **Manage access tokens** -- reveal, copy, or regenerate bearer tokens for authentication
+- **Delete** servers that are no longer needed
+
+Each registered server is assigned a random access token on creation. You use this token in your MCP client configuration for authenticated access.
 
 ## Available Tools
 
-The MCP server exposes seven tools:
+The MCP server exposes seven tools that LLM clients can discover and call:
 
-### Findings
+### Findings Tools
 
 | Tool | Description |
 |------|-------------|
-| `list_findings` | Query findings with optional filters for repository, severity, status, and scan type. Returns up to 200 results (default 50). |
-| `get_finding` | Retrieve a single finding by its MongoDB ObjectId. |
+| `list_findings` | Query findings with optional filters for repository, severity, status, and scan type. Returns up to 200 results. |
+| `get_finding` | Retrieve a single finding by its ID. |
 | `findings_summary` | Get finding counts grouped by severity and status, optionally filtered by repository. |
 
-### SBOM
+### SBOM Tools
 
 | Tool | Description |
 |------|-------------|
 | `list_sbom_packages` | List SBOM packages with filters for repository, vulnerabilities, package manager, and license. |
 | `sbom_vuln_report` | Generate a vulnerability report for a repository showing all packages with known CVEs. |
 
-### DAST
+### DAST Tools
 
 | Tool | Description |
 |------|-------------|
 | `list_dast_findings` | Query DAST findings with filters for target, scan run, severity, exploitability, and vulnerability type. |
 | `dast_scan_summary` | Get a summary of recent DAST scan runs and finding counts. |
 
-## Running Locally
+## Connecting an MCP Client
 
-### Stdio Mode
+To connect an MCP-compatible tool (like Claude Desktop or Cursor) to your Certifai MCP server:
 
-Run the MCP server directly — it reads from stdin and writes to stdout:
+1. Go to **MCP Servers** in Certifai and note the server endpoint URL and access token
+2. In your MCP client, add a new server connection with:
+   - **URL** -- the MCP server endpoint (e.g. `https://your-certifai-instance/mcp`)
+   - **Transport** -- Streamable HTTP
+   - **Authentication** -- Bearer token using the access token from Certifai
 
-```bash
-cd compliance-mcp
-cargo run
-```
-
-Configure your MCP client to launch it as a subprocess. For example, in a Claude Code `mcp.json`:
-
-```json
-{
-  "mcpServers": {
-    "compliance": {
-      "command": "cargo",
-      "args": ["run", "-p", "compliance-mcp"],
-      "cwd": "/path/to/compliance-scanner"
-    }
-  }
-}
-```
-
-### HTTP Mode
-
-Set `MCP_PORT` to start the Streamable HTTP server:
-
-```bash
-MCP_PORT=8090 cargo run -p compliance-mcp
-```
-
-The server listens on `http://0.0.0.0:8090/mcp`. Point your MCP client to this endpoint.
-
-## Configuration
-
-| Variable | Description | Default |
-|----------|-------------|---------|
-| `MONGODB_URI` | MongoDB connection string | `mongodb://localhost:27017` |
-| `MONGODB_DATABASE` | Database name | `compliance_scanner` |
-| `MCP_PORT` | Port for HTTP transport (omit for stdio) | — |
-| `RUST_LOG` | Log level filter | `compliance_mcp=info` |
-
-Create a `.env` file in the project root or set these as environment variables.
-
-## Deploying with Docker
-
-The `Dockerfile.mcp` builds and runs the MCP server in HTTP mode on port 8090.
-
-```bash
-docker build -f Dockerfile.mcp -t compliance-mcp .
-docker run -p 8090:8090 \
-  -e MONGODB_URI=mongodb://mongo:27017 \
-  -e MONGODB_DATABASE=compliance_scanner \
-  -e MCP_PORT=8090 \
-  compliance-mcp
-```
-
-### Coolify Deployment
-
-1. Create a new service in your Coolify project
-2. Set the **Dockerfile path** to `Dockerfile.mcp`
-3. Set the **exposed port** to `8090`
-4. Add environment variables: `MONGODB_URI`, `MONGODB_DATABASE`, `MCP_PORT=8090`
-5. The MCP endpoint will be available at your configured domain under `/mcp`
-
-The CI pipeline automatically deploys on changes to `compliance-core/`, `compliance-mcp/`, `Dockerfile.mcp`, or `Cargo.toml`/`Cargo.lock`. Add the `COOLIFY_WEBHOOK_MCP` secret to your Gitea repository.
-
-## Managing MCP Servers in the Dashboard
-
-Navigate to **MCP Servers** in the dashboard sidebar to:
-
-- **Register** MCP server instances with their endpoint URL, transport type, port, and database connection
-- **View** server configuration, enabled tools, and status
-- **Manage access tokens** — reveal, copy, or regenerate bearer tokens for authentication
-- **Delete** servers that are no longer needed
-
-Each registered server is assigned a random access token on creation. Use this token in your MCP client configuration for authenticated access.
-
-## Example: Querying Findings from an LLM
-
-Once connected, an LLM can call any of the registered tools. For example:
-
-**"Show me all critical findings"** triggers `list_findings` with `severity: "critical"`:
-
-```json
-{
-  "tool": "list_findings",
-  "arguments": {
-    "severity": "critical",
-    "limit": 10
-  }
-}
-```
-
-**"What vulnerable packages does repo X have?"** triggers `sbom_vuln_report`:
-
-```json
-{
-  "tool": "sbom_vuln_report",
-  "arguments": {
-    "repo_id": "683abc..."
-  }
-}
-```
+Once connected, the LLM client automatically discovers the available tools and can call them in response to your questions.
 
 ::: tip
-The MCP server is read-only — it only queries data from MongoDB. It cannot modify findings, trigger scans, or change configuration. This makes it safe to expose to external LLM clients.
+The MCP server is read-only -- it only queries data. It cannot modify findings, trigger scans, or change configuration. This makes it safe to expose to LLM clients.
 :::
+
+## Example Queries
+
+Once your MCP client is connected, you can ask questions like:
+
+- "Show me all critical findings across my repositories"
+- "What vulnerable packages does the backend service have?"
+- "Give me a summary of DAST findings for the staging target"
+- "How many open findings do we have by severity?"
+
+The LLM translates your natural language question into the appropriate tool call and presents the results in a readable format.

docs/features/overview.md

@@ -1,10 +1,12 @@
 # Dashboard Overview
 
-The Overview page is the landing page of the Compliance Scanner dashboard. It gives you a high-level view of your security posture across all tracked repositories.
+The Overview page is the landing page of Certifai. It gives you a high-level view of your security posture across all tracked repositories.
 
-## Statistics
+![Dashboard overview with stats cards, severity distribution, AI chat, and MCP servers](/screenshots/dashboard-overview.png)
 
-The top section displays key metrics:
+## Stats Cards
+
+The top section displays key metrics at a glance:
 
 | Metric | Description |
 |--------|-------------|
@@ -14,22 +16,32 @@ The top section displays key metrics:
 | **High** | Findings with high severity |
 | **Medium** | Findings with medium severity |
 | **Low** | Findings with low severity |
-| **Dependencies** | Total SBOM entries across all repositories |
+| **Dependencies** | Total SBOM packages across all repositories |
 | **CVE Alerts** | Active CVE alerts from dependency monitoring |
-| **Tracker Issues** | Issues created in external trackers (GitHub, GitLab, Jira) |
+| **Tracker Issues** | Issues created in external trackers (GitHub, GitLab, Gitea, Jira) |
+
+These cards update after each scan completes, so you always see the current state.
 
 ## Severity Distribution
 
-A visual bar chart shows the distribution of findings by severity level, giving you an immediate sense of your risk profile.
+A visual chart shows the distribution of findings by severity level across all your repositories. This gives you an immediate sense of your risk profile -- whether your findings are mostly informational or if there are critical issues that need attention.
+
+## AI Chat Cards
+
+The overview includes quick-access cards for the AI Chat feature. Each card represents a repository that has embeddings built, letting you jump directly into a conversation about that codebase. See [AI Chat](/features/ai-chat) for details.
+
+## MCP Server Cards
+
+If you have MCP servers registered, they appear on the overview page with their status and connection details. This lets you quickly check that your MCP integrations are running. See [MCP Integration](/features/mcp-server) for details.
 
 ## Recent Scan Runs
 
-The bottom section lists the 10 most recent scan runs across all repositories, showing:
+The bottom section lists the most recent scan runs across all repositories, showing:
 
 - Repository name
 - Scan status (queued, running, completed, failed)
 - Current phase
 - Number of findings discovered
-- Timestamp
+- Timestamp and duration
 
-This helps you monitor scanning activity and quickly spot failures.
+This helps you monitor scanning activity and quickly spot failures or long-running scans.

docs/features/sbom.md

@@ -1,106 +0,0 @@
-# SBOM & License Compliance
-
-The SBOM (Software Bill of Materials) feature provides a complete inventory of all dependencies across your repositories, with vulnerability tracking and license compliance analysis.
-
-The SBOM page has three tabs: **Packages**, **License Compliance**, and **Compare**.
-
-## Packages Tab
-
-The packages tab lists all dependencies discovered during scans.
-
-### Filtering
-
-Use the filter bar to narrow results:
-
-- **Repository** — Select a specific repository or view all
-- **Package Manager** — npm, cargo, pip, go, maven, nuget, composer, gem
-- **Search** — Filter by package name
-- **Vulnerabilities** — Show all packages, only those with vulnerabilities, or only clean packages
-- **License** — Filter by specific license (MIT, Apache-2.0, BSD-3-Clause, GPL-3.0, etc.)
-
-### Package Details
-
-Each package row shows:
-
-| Column | Description |
-|--------|-------------|
-| Package | Package name |
-| Version | Installed version |
-| Manager | Package manager (npm, cargo, pip, etc.) |
-| License | License identifier with color-coded badge |
-| Vulnerabilities | Count of known vulnerabilities (click to expand) |
-
-### Vulnerability Details
-
-Click the vulnerability count to expand inline details showing:
-
-- Vulnerability ID (e.g. CVE-2024-1234)
-- Source database
-- Severity level
-- Link to the advisory
-
-### Export
-
-Export your SBOM in industry-standard formats:
-
-1. Select a format:
-   - **CycloneDX 1.5** — JSON format widely supported by security tools
-   - **SPDX 2.3** — Linux Foundation standard for license compliance
-2. Click **Export**
-3. The SBOM downloads as a JSON file
-
-::: tip
-SBOM exports are useful for compliance audits, customer security questionnaires, and supply chain transparency requirements.
-:::
-
-## License Compliance Tab
-
-The license compliance tab helps you understand your licensing obligations.
-
-### Copyleft Warning
-
-If any dependencies use copyleft licenses (GPL, AGPL, LGPL, MPL), a warning banner appears listing the affected packages and noting that they may impose distribution requirements.
-
-### License Distribution
-
-A horizontal bar chart visualizes the percentage breakdown of licenses across your dependencies.
-
-### License Table
-
-A detailed table lists every license found, with:
-
-| Column | Description |
-|--------|-------------|
-| License | License identifier |
-| Type | **Copyleft** or **Permissive** badge |
-| Packages | List of packages using this license |
-| Count | Number of packages |
-
-**Copyleft licenses** (flagged as potentially restrictive):
-- GPL-2.0, GPL-3.0
-- AGPL-3.0
-- LGPL-2.1, LGPL-3.0
-- MPL-2.0
-
-**Permissive licenses** (generally safe for commercial use):
-- MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, etc.
-
-## Compare Tab
-
-Compare the dependency profiles of two repositories side by side.
-
-1. Select **Repository A** from the first dropdown
-2. Select **Repository B** from the second dropdown
-3. View the diff results:
-
-| Section | Description |
-|---------|-------------|
-| **Only in A** | Packages present in repo A but not in repo B |
-| **Only in B** | Packages present in repo B but not in repo A |
-| **Version Diffs** | Same package, different versions between repos |
-| **Common** | Count of packages that match exactly |
-
-This is useful for:
-- Auditing consistency across microservices
-- Identifying dependency drift between environments
-- Planning dependency upgrades across projects