librechat.ai/.cursor/rules/librechat-documentation.mdc

---
description: 
globs: 
alwaysApply: true
---
# LibreChat Documentation Rules

## Config Version Updates

When updating the LibreChat config version (e.g., from v1.2.6 to v1.2.7), follow these steps:

### 1. Create Changelog Files

#### Main Changelog File
Create: `pages/changelog/config_v{VERSION}.mdx`

Template:
```mdx
---
date: YYYY/MM/DD
title: ⚙️ Config v{VERSION}
---

import { ChangelogHeader } from '@/components/changelog/ChangelogHeader'
import Content from '@/components/changelog/content/config_v{VERSION}.mdx'

<ChangelogHeader />

---

<Content />
```

#### Content File
Create: `components/changelog/content/config_v{VERSION}.mdx`

Format:
- Use bullet points starting with `-`
- Group related changes together
- Include links to detailed documentation using `[Feature Name](/docs/configuration/librechat_yaml/object_structure/{feature})`
- Describe what was added/changed and its purpose
- Keep descriptions concise but informative

Example:
```mdx
- Added `memory` configuration to control memory functionality for conversations
  - Configure memory persistence and personalization settings
  - Set token limits and message window sizes for memory context
  - Configure agents for memory processing with provider-specific settings
  - Supports both predefined agents (by ID) and custom agent configurations
  - See [Memory Configuration](/docs/configuration/librechat_yaml/object_structure/memory) for details
```

### 2. Create Object Structure Documentation

For new root-level configurations, create: `pages/docs/configuration/librechat_yaml/object_structure/{feature}.mdx`

Structure:
1. **Title**: `# {Feature} Configuration`
2. **Overview**: Brief description of the feature
3. **Example**: Complete YAML example showing all options
4. **Field Documentation**: Use `<OptionTable>` components for each field
5. **Subsections**: For complex nested objects
6. **Notes**: Important considerations at the end

### 3. Update Navigation

Add the new feature to: `pages/docs/configuration/librechat_yaml/object_structure/_meta.ts`

Insert alphabetically or logically within the structure:
```ts
export default {
  config: 'Root Settings',
  file_config: 'File Config',
  interface: 'Interface (UI)',
  // ... other entries
  memory: 'Memory',  // Add new entry
  // ... remaining entries
}
```

### 4. Update Main Config Documentation

In `pages/docs/configuration/librechat_yaml/object_structure/config.mdx`:

1. Update the version example:
   ```yaml
   ['version', 'String', 'Specifies the version of the configuration file.', 'version: 1.2.8' ],
   ```

2. Add the new configuration section (insert alphabetically or logically):
   ```mdx
   ## memory

   **Key:**
   <OptionTable
     options={[
       ['memory', 'Object', 'Brief description of the feature.', ''],
     ]}
   />

   **Subkeys:**
   <OptionTable
     options={[
       ['field1', 'Type', 'Description', ''],
       ['field2', 'Type', 'Description', ''],
       // ... other fields
     ]}
   />

   see: [Memory Object Structure](/docs/configuration/librechat_yaml/object_structure/memory)
   ```

## Documentation Standards

### OptionTable Usage
```mdx
<OptionTable
  options={[
    ['fieldName', 'Type', 'Description of what the field does.', 'example: value'],
  ]}
/>
```

### YAML Examples
- Use `filename` attribute for code blocks: ` ```yaml filename="memory" `
- Show realistic, working examples
- Include comments only when necessary for clarity

### Field Descriptions
- Be precise about default values
- Explain the impact of different settings
- Note any relationships between fields
- Mention when fields are required vs optional

### Special Considerations
- For boolean fields that give users control, clarify WHO gets the control (admin vs end-user)
- For fields that replace default behavior, explicitly state this
- For union types, show examples of each variant
- For nested objects, create subsections with their own OptionTables

## Version Numbering
- Config versions follow semantic versioning: v{MAJOR}.{MINOR}.{PATCH}
- Adding new root-level configurations typically warrants a minor version bump
- Breaking changes require a major version bump
- Bug fixes or minor adjustments use patch versions