docs(guardrails): add the Reco guardrail page

.github/workflows/docs-checks.yml

@@ -0,0 +1,25 @@
+name: Docs checks
+
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+jobs:
+  writing-style:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 24
+      - run: node scripts/check-writing-style.js docs blog release_notes
+  structure:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.13"
+      - run: pip install pyyaml
+      - run: python3 scripts/check-docs.py docs

.github/workflows/update-openapi.yml

@@ -0,0 +1,53 @@
+name: Update OpenAPI snapshot
+
+on:
+  schedule:
+    - cron: "0 6 * * *"
+  workflow_dispatch:
+
+jobs:
+  update-openapi:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      pull-requests: write
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.13"
+      - run: pip install "litellm[proxy]"
+      - name: Write minimal proxy config
+        run: |
+          cat > /tmp/config.yaml <<'EOF'
+          model_list:
+            - model_name: gpt-4o-mini
+              litellm_params:
+                model: openai/gpt-4o-mini
+                api_key: fake
+          EOF
+      - name: Start proxy and snapshot the spec
+        run: |
+          LITELLM_DANGEROUSLY_PERMIT_WEAK_OR_UNSET_MASTER_KEY=true litellm --config /tmp/config.yaml --port 4000 &
+          for i in $(seq 1 120); do
+            if curl -sf http://localhost:4000/openapi.json -o /dev/null; then
+              break
+            fi
+            sleep 1
+          done
+          bash scripts/update-openapi.sh http://localhost:4000
+      - name: Resolve installed litellm version
+        id: version
+        run: echo "litellm_version=$(python -c "from importlib.metadata import version; print(version('litellm'))")" >> "$GITHUB_OUTPUT"
+      - uses: peter-evans/create-pull-request@v7
+        id: pr
+        with:
+          branch: litellm_openapi_snapshot
+          commit-message: "docs: refresh the OpenAPI snapshot to litellm ${{ steps.version.outputs.litellm_version }}"
+          title: "docs: refresh the OpenAPI snapshot to litellm ${{ steps.version.outputs.litellm_version }}"
+          body: "Regenerated the OpenAPI snapshot behind https://docs.litellm.ai/api-reference/ from litellm ${{ steps.version.outputs.litellm_version }} on PyPI."
+      - name: Squash-merge once Vercel checks pass
+        if: steps.pr.outputs.pull-request-operation == 'created'
+        run: gh pr merge --squash --auto "${{ steps.pr.outputs.pull-request-number }}"
+        env:
+          GH_TOKEN: ${{ github.token }}

.gitignore

@@ -21,3 +21,6 @@ yarn-debug.log*
 yarn-error.log*
 yarn.lock
 pnpm-lock.yaml
+
+# Python bytecode from scripts/
+__pycache__/

.nvmrc

@@ -0,0 +1 @@
+24

AGENTS.md

@@ -0,0 +1,45 @@
+When making public-facing docs, PR descriptions, comments, issues, commit messages, etc., always follow these guidelines to sound less AI-y:
+
+- prefer not to use emojis
+- don't use "—". Instead, reach for ";", ".", etc.
+- don't use the pattern "It's not X, it's Y", "You're not X, you're Y", etc.
+- don't use bulleted or numbered lists unless it would be nonsensical not to. Instead, prefer prose
+- be information dense, concise, and clear
+
+## Release notes: breaking changes
+
+Every breaking change in a release note must be surfaced in a dedicated red `:::danger Breaking Changes` admonition placed immediately after the "Deploy this version" block and before "Key Highlights"; do not leave it as a regular Key Highlights bullet. A breaking change is anything that alters existing default behavior, removes or renames a field, tightens who may do something, or otherwise requires action to preserve prior behavior; opt-in additions and pure bug fixes are not breaking. Lead each entry with a bolded one-sentence summary of what changed, then state the upgrade impact and link the PR. Group multiple breaking changes in the same release inside one admonition. Use the following shape:
+
+```md
+</Tabs>
+
+:::danger Breaking Changes
+
+**One-sentence summary of the change.** What breaks for someone upgrading and how to restore the prior behavior if applicable. See [PR #12345](https://github.com/BerriAI/litellm/pull/12345).
+
+:::
+
+## Key Highlights
+```
+## Release notes: GitHub release and ghcr image links
+
+Every new stable release note must link the GitHub releases page, https://github.com/BerriAI/litellm/releases, and the specific release entry at `https://github.com/BerriAI/litellm/releases/tag/vX.Y.Z`. Fetch that release entry before writing the note: its "Verify Docker Image Signature" block names the exact ghcr image for the version (for example `ghcr.io/berriai/litellm:v1.101.0`), so take the image reference from there rather than guessing the tag format. The note must then link that version's ghcr image, pointing at the package page `https://github.com/BerriAI/litellm/pkgs/container/litellm` with the image reference as the link text. Put these links in the "Deploy this version" section, directly after the `</Tabs>` closer and before any breaking changes admonition, in this shape:
+
+```md
+</Tabs>
+
+This release is published as [`ghcr.io/berriai/litellm:vX.Y.Z`](https://github.com/BerriAI/litellm/pkgs/container/litellm). See the [GitHub release](https://github.com/BerriAI/litellm/releases/tag/vX.Y.Z) and the full [releases page](https://github.com/BerriAI/litellm/releases).
+```
+
+## Release notes: runnable docker command
+
+The Docker tab under "Deploy this version" must be a command that actually boots the proxy. `STORE_MODEL_IN_DB=True` alone does nothing without a database, so always pair it with `LITELLM_MASTER_KEY` and `DATABASE_URL`:
+
+```bash
+docker run \
+-e LITELLM_MASTER_KEY=sk-<paste-a-long-random-key> \
+-e DATABASE_URL=postgresql://<user>:<password>@<host>:5432/<dbname> \
+-e STORE_MODEL_IN_DB=True \
+-p 4000:4000 \
+docker.litellm.ai/berriai/litellm:X.Y.Z
+```

CONTRIBUTING.md

@@ -35,6 +35,8 @@ Custom standalone pages live in `src/pages/`.
 
 If you add, remove, or move docs pages, check whether `sidebars.js` needs to be updated.
 
+To mark a page or section as Enterprise-gated, put `<EnterpriseFeature />` on its own line with a blank line before and after it, instead of writing the admonition by hand. It is registered globally in `src/theme/MDXComponents.js`, so no import is needed. Pass `feature="SSO"` to name the feature in the first sentence, use `<EnterpriseFeature free />` for features that ship in `litellm[proxy]` without a license, and put a one-line note between `<EnterpriseFeature>` and `</EnterpriseFeature>` when the page needs an extra sentence, such as a user limit. The component lives in `src/components/EnterpriseFeature/`.
+
 ## 5. Verify your changes
 
 Before opening a PR, run:
@@ -45,6 +47,25 @@ npm run build
 
 This catches broken links, invalid MDX, and other Docusaurus build issues.
 
+Also run the writing style check, which CI enforces on every PR:
+
+```bash
+npm run lint:writing
+```
+
+It covers `docs/`, `blog/`, and `release_notes/`. It fails on em dashes used as prose punctuation (see AGENTS.md) and, with `--warnings`, lists inflated wording such as "utilize", "leverage", or "seamless".
+
+Also run the structural check, which CI enforces on every PR:
+
+```bash
+pip install pyyaml   # once
+npm run lint:docs
+```
+
+It parses every fenced `yaml`, `json`, and `python` block in `docs/`, and fails on blocks that do not parse, unclosed fences, code written on the ``` line, comments after a `\` line continuation in shell blocks, relative links and heading anchors that do not resolve, missing images, GitHub-style `> [!NOTE]` alerts, and pages with more than one H1. The rule names in its output are explained at the top of `scripts/check-docs.py`. Comments, `...` placeholders, and object fragments (a `"key": value` list without the enclosing braces) inside JSON blocks are tolerated. If a block is deliberately a fragment that cannot be made valid, add `nolint` to the fence line (```yaml nolint); use that sparingly.
+
+Model ids in examples are placeholders. `docs-models.json` at the repo root maps a role (`openai_small`, `openai_large`, `anthropic`, `anthropic_large`, `gemini_pro`, `gemini_flash`) to the id examples use today, and pages write `{{openai_small}}` (or `azure/{{openai_large}}`, `bedrock/us.anthropic.{{anthropic}}`) inside code blocks and inline code; `src/remark/docs-models.js` fills in the real id when the site builds, including for the copy-as-markdown button. Moving the docs to a new model is one edit to `docs-models.json` with no page changes. `npm run lint:docs` applies the same substitution before it parses a block and fails with `model-literal` when a code block hardcodes one of those ids instead of using its placeholder. When the exact id is the point of a block, such as a price map key, a cache key, or a printed log, add `keep-model-ids` to the fence line (```yaml keep-model-ids). Ids that are facts about a provider rather than an example default, such as a supported-model table, stay literal. Other `{{name}}` tokens in pages are prompt-template placeholders and pass through untouched. A placeholder that starts like a role but is not one (`{{openai_smal}}`, or `{{gemini_flash}}` once that role is removed from the file) fails with `model-role-unknown`, since the build would print it as written.
+
 ## 6. Submit a PR
 
 Create a branch: