Fix titled admonitions rendering as literal text

docs/extensions/api-key-extensions.md

@@ -20,7 +20,7 @@ What you get by declaring an `api_key` connection:
 - Before every tool call, the decrypted values are **injected into your server**
   over the `neatcontext/connection` handshake.
 
-:::info Prerequisites
+:::info[Prerequisites]
 Read [Build Your First Extension](./building-extensions.md) first — this guide
 reuses its folder layout, JSON-RPC framing, and method dispatch, and only shows
 what changes for authentication.
@@ -217,7 +217,7 @@ async function searchLogs(args) {
 }
 ```
 
-:::warning Never persist or print secrets
+:::warning[Never persist or print secrets]
 Credentials arrive per call and must stay in memory. Don't write them to disk,
 don't include them in tool results, and redact them from anything you append to
 `diagnosticLogPath`.

docs/extensions/building-extensions.md

@@ -15,7 +15,7 @@ endpoint. The same skeleton scales to as many tools as you need — the
 ([source on GitHub](https://github.com/XTSoftwareLabs/neatcontext-demo)) is this
 exact pattern with three tools.
 
-:::info Prerequisites
+:::info[Prerequisites]
 Node.js 18+ for developing and testing locally. No npm dependencies are required —
 everything uses Node built-ins. (End users don't need Node at all: NeatContext
 runs `command: "node"` servers on its own bundled runtime.)

docs/extensions/oauth-extensions.md

@@ -25,7 +25,7 @@ manifest:
 Your server never sees the flow — it just receives a currently-valid access
 token per call.
 
-:::info Prerequisites
+:::info[Prerequisites]
 Read [Build Your First Extension](./building-extensions.md) first — this guide
 reuses its folder layout, framing, and dispatch, and only shows what changes for
 OAuth.
@@ -52,7 +52,7 @@ Before writing the manifest you need an OAuth client from the service:
 3. Note the **client id**, the **authorize URL**, the **token URL**, and the
    **scopes** you need. Request the narrowest (read-only) scopes that work.
 
-:::tip Refresh tokens
+:::tip[Refresh tokens]
 If the provider makes refresh tokens optional (an "offline access" scope or app
 setting), enable them. Without a refresh token, the user must reconnect whenever
 the access token expires — NeatContext will say so in the extension's status.

docs/extensions/overview.md

@@ -60,7 +60,7 @@ notification** right after `initialize`, carrying the user's credentials for tha
 call (see [Connections](#connections) below); connectionless extensions can ignore
 it.
 
-:::info Your server is spawned fresh for every call
+:::info[Your server is spawned fresh for every call]
 NeatContext starts a new server process for each `tools/list` and each
 `tools/call`, and it lists tools **without** credentials. Two consequences:
 

docs/features/chats-and-tabs.md

@@ -25,7 +25,7 @@ tabs and you switch the entire working context, not just the conversation histor
   *"Message NeatContext"* box at the bottom. Press **Enter** to send
   (**Shift+Enter** for a new line).
 
-:::note A chat needs a profile
+:::note[A chat needs a profile]
 Sending a message requires the tab to have an **active domain profile** — context
 is the point, so NeatContext won't run without at least a minimal one. See
 [Domain Profiles](./domain-profiles.md).
@@ -94,7 +94,7 @@ question, and compare the answers side by side — no swapping context in and ou
 The [Incident Analysis walkthrough](../guides/incident-analysis.md) is built
 around exactly this.
 
-:::info Plan limits
+:::info[Plan limits]
 The number of chats, and of profiles and knowledge folders per chat, depends on
 your plan — see [neatcontext.com/pricing](https://www.neatcontext.com/pricing).
 :::

docs/features/domain-profiles.md

@@ -24,7 +24,7 @@ The **Domain Profiles** section in the sidebar has two buttons:
 Either way, the profile attaches to the **current chat tab** and appears in the
 sidebar list.
 
-:::tip Profiles are per-tab
+:::tip[Profiles are per-tab]
 Importing a profile attaches it to the tab you're on. Other tabs are untouched —
 that's what lets one tab be "Payments" and another "Infra". The **✕** next to a
 profile detaches it from the current tab only; the file on disk is unaffected.

docs/features/knowledge-bases.md

@@ -59,7 +59,7 @@ humans too:
 The [incident demo's knowledge folders](https://github.com/XTSoftwareLabs/neatcontext-demo/tree/main/knowledge)
 show the pattern: `runbooks/`, `tsg/`, and `postmortems/` per team.
 
-:::info Plan limits
+:::info[Plan limits]
 The number of knowledge folders per chat depends on your plan — see
 [neatcontext.com/pricing](https://www.neatcontext.com/pricing).
 :::

docs/features/model-provider.md

@@ -28,7 +28,7 @@ name, e.g. `gpt-5.4-mini`). That opens the **Model Provider** page:
 Click **Save**. The top bar now shows your model name, and every chat in the
 workspace uses this provider.
 
-:::caution Pick a tool-calling model
+:::caution[Pick a tool-calling model]
 Extensions only work if the active model supports **function/tool calling** (all
 mainstream chat models do). With a non-tool-calling model you still get profiles
 and knowledge search, but the model cannot query your systems.

docs/features/using-extensions.md

@@ -44,7 +44,7 @@ Each card shows the extension's name, description, version, its **tools** (hover
 one for its description), and the controls: **Enable/Disable**, **open folder**,
 and — for extensions you added — **remove**.
 
-:::caution Extensions are code you run
+:::caution[Extensions are code you run]
 An extension runs on your machine with your user's permissions. Treat a
 third-party extension like any code you download: review it before adding
 (click the folder icon and read the server — good extensions are a single
@@ -101,7 +101,7 @@ Every enabled extension's tools are available to the model in every chat. When
 the model uses one, you see it as an **activity step** in the response — tool
 use is never invisible.
 
-:::info Plan limits
+:::info[Plan limits]
 The number of enabled extensions depends on your plan — see
 [neatcontext.com/pricing](https://www.neatcontext.com/pricing).
 :::

docs/getting-started.md

@@ -66,7 +66,7 @@ Studio, vLLM…) work through their OpenAI-compatible URLs; see
 A [domain profile](./features/domain-profiles.md) tells the model how your team
 thinks: what it owns, what to check first, what never to touch.
 
-:::note This step is required
+:::note[This step is required]
 A chat needs an **active domain profile** before you can send a message — context
 is the whole point, so NeatContext won't run without at least a minimal one.
 :::

docs/guides/incident-analysis.md

@@ -16,7 +16,7 @@ which ships three tiny local mock systems (incident management, logs,
 deployments), a connector extension, two team profiles, and each team's runbooks.
 Everything runs on your machine; nothing touches real infrastructure.
 
-:::info Why this matters
+:::info[Why this matters]
 Between the two investigations, the **only** things that change are the profile
 and the knowledge folder each tab carries. The incident, the tools, and the raw
 evidence are identical — yet each team arrives at its own correct action. That is
@@ -76,7 +76,7 @@ check: open `https://localhost:7801/incidents/INC-1001` in a browser (accept the
 self-signed-cert warning) — you should get the incident JSON. The extension needs
 no such acceptance; it is configured to trust the demo cert.
 
-:::tip Port already in use?
+:::tip[Port already in use?]
 Override with env vars, e.g.
 `INCIDENT_PORT=8801 LOG_PORT=8802 DEPLOY_PORT=8803 node servers/index.js`, then point
 the extension at them with the matching `NEATCONTEXT_DEMO_*_BASE` variables (see the

docs/intro.md

@@ -7,7 +7,7 @@ slug: /
 
 Welcome to the **NeatContext** documentation.
 
-:::tip Quick hands-on demo
+:::tip[Quick hands-on demo]
 Don't want to read the docs first? Clone the demo repo and try NeatContext right
 away: **[github.com/XTSoftwareLabs/neatcontext-demo](https://github.com/XTSoftwareLabs/neatcontext-demo)**.
 :::