fix: Formatting in plugins

Author: tirumerla

content/relayer/1.2.x/plugins/index.mdx

@@ -346,30 +346,30 @@ curl -X POST http://localhost:8080/api/v1/plugins/example-plugin/call \
 
 ```
 
-== Response Fields
+## Response Fields
 
 - **`data`**: The value returned by your plugin's handler function (decoded from JSON when possible)
 - **`metadata.logs`**: Terminal output from the plugin (console.log, console.error, etc.) when `emit_logs` is true
 - **`metadata.traces`**: Messages exchanged between the plugin and the Relayer via PluginAPI when `emit_traces` is true
 - **`error`**: Error message if the plugin execution failed (business errors)
 
-== Key-Value Storage
+## Key-Value Storage
 
 The Relayer provides a built-in key-value store for plugins to maintain persistent state across invocations. This addresses the core problem of enabling persistent state management and programmatic configuration updates for plugins.
 
-=== Why a KV store?
+### Why a KV store?
 
 - Plugins execute as isolated processes with no persistent memory
 - No mechanism exists to maintain state between invocations
 - Plugins requiring shared state or coordination need safe concurrency primitives
 
-=== Configuration
+### Configuration
 
 - Reuses the same Redis URL as the Relayer via the `REDIS_URL` environment variable
 - No extra configuration is required
 - Keys are namespaced per plugin ID to prevent collisions
 
-=== Usage
+### Usage
 
 Access the KV store through the `kv` property in the `PluginContext`:
 
@@ -394,7 +394,7 @@ export async function handler(context: PluginContext) {
 
 ```
 
-=== Available Methods
+### Available Methods
 
 - `get<T>(key: string): Promise<T | null>`
 - `set(key: string, value: unknown, opts?:  ttlSec?: number ): Promise<boolean>`
@@ -406,16 +406,16 @@ export async function handler(context: PluginContext) {
 
 Keys must match `[A-Za-z0-9:_-]1,512` and are automatically namespaced per plugin.
 
-== Migration from Legacy Patterns
+## Migration from Legacy Patterns
 
-=== Current Status
+### Current Status
 
 - ✅ **Legacy plugins still work** - No immediate action required
 - ⚠️ **Deprecation warnings** - Legacy plugins will show console warnings
 - 📅 **Future removal** - The legacy `runPlugin` and two-parameter `handler(api, params)` will be removed in a future major version
 - 🎯 **Recommended action** - Migrate to single-parameter `PluginContext` handler for new plugins and KV access
 
-=== Migration Steps
+### Migration Steps
 
 If you have existing plugins using `runPlugin()` or the two-parameter handler, migration is simple:
 
@@ -455,7 +455,7 @@ export async function handler(context: PluginContext): Promise<any>
 
 ```
 
-=== Step-by-Step Migration
+### Step-by-Step Migration
 
 1. **Remove the `runPlugin()` call** at the bottom of your file
 2. **Rename your function to `handler`** (or create a new handler export)
@@ -464,7 +464,7 @@ export async function handler(context: PluginContext): Promise<any>
 5. **Test your plugin** to ensure it works with the new pattern
 6. **Update your documentation** to reflect the new pattern
 
-=== Backwards Compatibility
+### Backwards Compatibility
 
 The relayer will automatically detect which pattern your plugin uses:
 

content/relayer/plugins/index.mdx

@@ -346,30 +346,30 @@ curl -X POST http://localhost:8080/api/v1/plugins/example-plugin/call \
 
 ```
 
-== Response Fields
+## Response Fields
 
 - **`data`**: The value returned by your plugin's handler function (decoded from JSON when possible)
 - **`metadata.logs`**: Terminal output from the plugin (console.log, console.error, etc.) when `emit_logs` is true
 - **`metadata.traces`**: Messages exchanged between the plugin and the Relayer via PluginAPI when `emit_traces` is true
 - **`error`**: Error message if the plugin execution failed (business errors)
 
-== Key-Value Storage
+## Key-Value Storage
 
 The Relayer provides a built-in key-value store for plugins to maintain persistent state across invocations. This addresses the core problem of enabling persistent state management and programmatic configuration updates for plugins.
 
-=== Why a KV store?
+### Why a KV store?
 
 - Plugins execute as isolated processes with no persistent memory
 - No mechanism exists to maintain state between invocations
 - Plugins requiring shared state or coordination need safe concurrency primitives
 
-=== Configuration
+### Configuration
 
 - Reuses the same Redis URL as the Relayer via the `REDIS_URL` environment variable
 - No extra configuration is required
 - Keys are namespaced per plugin ID to prevent collisions
 
-=== Usage
+### Usage
 
 Access the KV store through the `kv` property in the `PluginContext`:
 
@@ -394,7 +394,7 @@ export async function handler(context: PluginContext) {
 
 ```
 
-=== Available Methods
+### Available Methods
 
 - `get<T>(key: string): Promise<T | null>`
 - `set(key: string, value: unknown, opts?:  ttlSec?: number ): Promise<boolean>`
@@ -406,16 +406,16 @@ export async function handler(context: PluginContext) {
 
 Keys must match `[A-Za-z0-9:_-]1,512` and are automatically namespaced per plugin.
 
-== Migration from Legacy Patterns
+## Migration from Legacy Patterns
 
-=== Current Status
+### Current Status
 
 - ✅ **Legacy plugins still work** - No immediate action required
 - ⚠️ **Deprecation warnings** - Legacy plugins will show console warnings
 - 📅 **Future removal** - The legacy `runPlugin` and two-parameter `handler(api, params)` will be removed in a future major version
 - 🎯 **Recommended action** - Migrate to single-parameter `PluginContext` handler for new plugins and KV access
 
-=== Migration Steps
+### Migration Steps
 
 If you have existing plugins using `runPlugin()` or the two-parameter handler, migration is simple:
 
@@ -455,7 +455,7 @@ export async function handler(context: PluginContext): Promise<any>
 
 ```
 
-=== Step-by-Step Migration
+### Step-by-Step Migration
 
 1. **Remove the `runPlugin()` call** at the bottom of your file
 2. **Rename your function to `handler`** (or create a new handler export)
@@ -464,7 +464,7 @@ export async function handler(context: PluginContext): Promise<any>
 5. **Test your plugin** to ensure it works with the new pattern
 6. **Update your documentation** to reflect the new pattern
 
-=== Backwards Compatibility
+### Backwards Compatibility
 
 The relayer will automatically detect which pattern your plugin uses: