Build a RAG-Powered Knowledge Base with Smart Sampling Controls

Build me a single-file HTML/CSS/JS app called "RAG Knowledge Base" with a dark theme using slate and violet colour accents.

The layout should have three sections:
1. LEFT SIDEBAR (280px wide): A "Knowledge Base" panel with a large textarea for pasting in documents, a text field for a document title, and an "Add to Knowledge Base" button. Below that, show a list of added documents with their titles.
2. MAIN PANEL: A query input field at the top with a "Query" button, and a results area below that starts empty.
3. RIGHT SIDEBAR (260px wide): A "Sampling Controls" panel with a Temperature slider (0.0 to 2.0, default 0.7), a Top-P slider (0.0 to 1.0, default 0.9), and a dropdown to select MCP Transport Mode (options: "stdio" and "HTTP"). Show the current value of each slider as a number next to it.

Add a header bar across the top with the app title and a small status badge that says "Ready".

All sections should be visible at once on a wide screen. Use CSS Grid for the three-column layout. Style the sliders to match the dark theme. Don't wire up any logic yet — just build the shell with placeholder text in the results area that says "Your answer will appear here." Make it look polished.

Now add a RAG retrieval engine to the app in JavaScript. Here's exactly what I need:

1. CHUNKING: When a user clicks "Add to Knowledge Base", split the document text into overlapping chunks of roughly 200 words each, with a 40-word overlap between consecutive chunks. Store each chunk as an object with: { id, documentTitle, text, wordCount }. Keep all chunks in a `knowledgeBase` array.

2. RETRIEVAL: When the user submits a query, score every chunk using a simple keyword relevance function: tokenise both the query and the chunk text into lowercase words (strip punctuation), then count how many unique query tokens appear in the chunk text. The score is: matchingTokens / totalQueryTokens. Return the top 3 chunks by score, or fewer if the knowledge base has fewer than 3 chunks.

3. DISPLAY: After retrieval, show the top chunks in the results area BEFORE the final answer placeholder. Each chunk should appear in a card with: the document title, the chunk text, and the relevance score formatted as a percentage. Use a cyan accent colour for these chunk cards.

4. Update the document list in the sidebar to show each document's title and number of chunks it produced.

Don't call any external API yet. Just show "[API response will appear here based on retrieved context]" as a placeholder after the chunk cards.

Add an MCP Transport Layer simulation to the app. When the user selects a transport mode from the dropdown (stdio or HTTP), the app should behave differently in the following ways:

STDIO MODE:
- Show a small terminal-style panel below the transport dropdown labelled "stdio stream"
- When a query is submitted, animate lines appearing in this panel as if messages are being exchanged line by line, like: "> {type: 'request', method: 'query', params: {query: '...', topChunks: 3}}"
and "< {type: 'response', status: 'ok', chunkCount: 3}"
- Use a monospace font and a green-on-dark terminal aesthetic for this panel
- Show a status badge next to the dropdown that says "stdio connected"

HTTP MODE:
- Replace the terminal panel with a "Request Preview" card that shows a formatted JSON object representing the HTTP POST body that would be sent, including the query, retrieved chunk IDs, temperature value, and top_p value
- Show a status badge that says "HTTP ready" with a blue colour
- Also show a mock response header: HTTP/1.1 200 OK, Content-Type: application/json

Both modes should update live whenever the user changes the transport dropdown. The simulation should NOT make any real network calls. Label everything clearly so users understand this is showing them what each transport mode would look like in a real MCP integration.

Make the Temperature and Top-P sliders affect the generated answer in the results panel. Here's how:

1. RESPONSE SYNTHESIS: Build a `synthesiseAnswer(query, chunks, temperature, topP)` function. It should:
   - Combine the text of the top retrieved chunks into a context string
   - Generate a response by extracting and reassembling sentences from those chunks that are most relevant to the query
   - Use the temperature value to control variation: at temperature 0.0-0.3, always return the single most relevant sentence from each chunk verbatim. At 0.4-0.8, paraphrase lightly. At 0.9-2.0, add clearly labelled "[high temperature: speculative]" elaborations that extend beyond the retrieved text.
   - Use the topP value to control how many chunks contribute: topP below 0.5 means only use the single highest-scoring chunk, 0.5-0.8 uses the top 2, above 0.8 uses all 3.

2. ANSWER DISPLAY: Show the final synthesised answer in a clearly labelled "Answer" card below the chunk cards. Use an amber accent colour for this card. Include a small metadata line showing: Temperature: X | Top-P: X | Chunks used: X | Transport: stdio/HTTP

3. SAMPLING EXPLANATION: Below the answer, add a collapsible "Why this response?" section that explains in plain English what effect the current temperature and Top-P values had on the answer. For example: "Temperature 0.2 = precise and literal. Top-P 0.9 = drawing from all top chunks."

Update this explanation live whenever the sliders change, even without resubmitting a query.

Add these final features to complete the app:

1. QUERY LOG: Add a collapsible "Query Log" section at the bottom of the main panel. Every time a query is submitted, append a log entry containing: timestamp, the query text, temperature value, Top-P value, transport mode, number of chunks retrieved, top chunk relevance score, and the first 100 characters of the answer. Show the log as a scrollable table with these columns. Add a "Clear Log" button and an "Export as JSON" button that downloads the log entries as a JSON file.

2. KNOWLEDGE BASE STATS: In the left sidebar below the document list, add a small stats panel showing: total documents, total chunks, average chunk length in words, and a bar showing how full the "context window" is (treat 20 chunks as the max and show a progress bar).

3. STATUS BADGE: Update the header status badge dynamically: show "Ready" when idle, "Retrieving..." briefly during chunk retrieval, and "Answer ready" after synthesis completes. Use green for ready, amber for retrieving, and brand green for answer ready.

4. EMPTY STATE: If the user submits a query but the knowledge base is empty, show a friendly empty state in the results area with an icon and the message: "No documents in your knowledge base yet. Add some text in the left sidebar to get started."

5. FINAL POLISH: Add a subtle animation (CSS keyframe fade-in) when new chunk cards or the answer card appear. Make the query input submit on Enter key as well as the button click. Add a tooltip to each slider explaining what it does in one sentence.

Test the full flow works end to end and fix any bugs you spot.