Use sentence case for all Sphinx documentation headings

Align heading style with Plone documentation style guide which follows
the Microsoft Writing Style Guide: only capitalize the first word and
proper nouns in headings. Affects 26 files across tutorials, how-to
guides, reference, and explanation sections.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: jensens

docs/sources/explanation/blob-handling.md

@@ -1,4 +1,4 @@
-# How Blob Storage Works
+# How blob storage works
 
 <!-- diataxis: explanation -->
 
@@ -91,7 +91,7 @@ blobs to S3-compatible object storage:
 - Blobs exceeding the threshold are uploaded to S3
 - A local cache directory avoids repeated S3 downloads
 
-## S3 Blob Wrapper (z3blobs)
+## S3 blob wrapper (z3blobs)
 
 The `zodb-s3blobs` wrapper can be applied to `direct`, `relstorage`, or `zeo`
 to redirect all blob operations to S3-compatible object storage. When enabled:

docs/sources/explanation/storage-backends.md

@@ -1,4 +1,4 @@
-# Understanding Storage Backends
+# Understanding storage backends
 
 <!-- diataxis: explanation -->
 
@@ -65,7 +65,7 @@ preservation.
   cached locally) or *shared* mode (blobs on a shared filesystem)
 - History-free mode gives better performance but disables ZODB-level undo
 
-## ZEO (Zope Enterprise Objects)
+## ZEO (Zope enterprise objects)
 
 [ZEO](https://zeo.readthedocs.io/) is the original client-server protocol
 for ZODB. A dedicated ZEO server process manages the filestorage, and
@@ -123,7 +123,7 @@ storage for large blob volumes.
 - Newer and less battle-tested than RelStorage or ZEO
 - Blob handling is fundamentally different from the other backends
 
-## S3 Blob Wrapper (z3blobs)
+## S3 blob wrapper (z3blobs)
 
 [zodb-s3blobs](https://pypi.org/project/zodb-s3blobs/) is not a fifth storage
 backend but a **wrapper** that can be applied to any of the first three backends

docs/sources/explanation/why-cookiecutter.md

@@ -1,4 +1,4 @@
-# Why Cookiecutter for Zope Configuration?
+# Why Cookiecutter for Zope configuration?
 
 <!-- diataxis: explanation -->
 

docs/sources/how-to/configure-cors.md

@@ -1,4 +1,4 @@
-# Configure CORS for REST API Access
+# Configure CORS for REST API access
 
 <!-- diataxis: how-to -->
 
@@ -10,7 +10,7 @@ CORS support is provided by
 [plone.rest](https://pypi.org/project/plone.rest/) and is configured through
 `cookiecutter-zope-instance` settings.
 
-## Step 1: Enable CORS
+## Step 1: enable CORS
 
 By default, CORS is disabled. Enable it in your `instance.yaml`:
 
@@ -19,7 +19,7 @@ default_context:
     cors_enabled: true
 ```
 
-## Step 2: Configure allowed origins
+## Step 2: configure allowed origins
 
 Specify which origins may access your Plone site:
 
@@ -71,7 +71,7 @@ The default value for `cors_allow_origin` is already
 you only need to set `cors_enabled: true`.
 ```
 
-## Example: Production with specific domains
+## Example: production with specific domains
 
 ```yaml
 default_context:

docs/sources/how-to/configure-pgjsonb.md

@@ -1,4 +1,4 @@
-# Configure PGJsonb Storage
+# Configure PGJsonb storage
 
 <!-- diataxis: how-to -->
 
@@ -12,7 +12,7 @@ standard SQL operators.
 - The `zodb-pgjsonb` and `zodb-json-codec` Python packages installed
 - A PostgreSQL database created for your Zope instance
 
-## Step 1: Set the storage type
+## Step 1: set the storage type
 
 In your `instance.yaml`, set the storage backend to `pgjsonb`:
 
@@ -21,7 +21,7 @@ default_context:
     db_storage: pgjsonb
 ```
 
-## Step 2: Configure the connection string
+## Step 2: configure the connection string
 
 Provide the PostgreSQL DSN so the storage can connect to your database:
 
@@ -38,7 +38,7 @@ default_context:
     db_pgjsonb_dsn: "postgresql://zodb:zodb@localhost:5433/zodb"
 ```
 
-## Step 3: Choose history mode
+## Step 3: choose history mode
 
 By default, PGJsonb uses a history-free schema (no undo, better performance).
 To enable ZODB-level undo support:

docs/sources/how-to/configure-relstorage.md

@@ -13,7 +13,7 @@ horizontal scaling.
 - The `RelStorage` and `psycopg2` Python packages installed
 - A PostgreSQL database created for your Zope instance
 
-## Step 1: Set the storage type
+## Step 1: set the storage type
 
 In your `instance.yaml`, set the storage backend to `relstorage`:
 
@@ -22,7 +22,7 @@ default_context:
     db_storage: relstorage
 ```
 
-## Step 2: Set the blob mode
+## Step 2: set the blob mode
 
 RelStorage stores blobs in the database. Your Zope client needs a local cache
 directory for blob data. Set the blob mode to `cache`:
@@ -38,7 +38,7 @@ You **must** set `db_blob_mode` to `cache` when using RelStorage.
 The default value `shared` is only appropriate for direct filestorage.
 ```
 
-## Step 3: Choose the database backend
+## Step 3: choose the database backend
 
 Set the relational database type. PostgreSQL is the recommended choice:
 
@@ -51,7 +51,7 @@ default_context:
 
 Other supported values are `mysql`, `oracle`, and `sqlite3`.
 
-## Step 4: Configure the connection string
+## Step 4: configure the connection string
 
 Provide the PostgreSQL DSN (Data Source Name) so RelStorage can connect to
 your database:

docs/sources/how-to/configure-z3blobs.md

@@ -1,4 +1,4 @@
-# Configure S3 Blob Storage (z3blobs)
+# Configure S3 blob storage (z3blobs)
 
 <!-- diataxis: how-to -->
 
@@ -11,7 +11,7 @@ This guide walks you through enabling S3-backed blob storage using
 - An S3-compatible storage service (AWS S3, MinIO, Ceph, etc.)
 - A bucket created for your blob data
 
-## Step 1: Enable the wrapper
+## Step 1: enable the wrapper
 
 In your `instance.yaml`, enable the z3blobs wrapper alongside your existing
 storage backend:
@@ -22,7 +22,7 @@ default_context:
     db_z3blobs_enabled: true
 ```
 
-## Step 2: Configure the S3 bucket
+## Step 2: configure the S3 bucket
 
 Provide the bucket name and a local cache directory:
 
@@ -34,7 +34,7 @@ default_context:
     db_z3blobs_cache_dir: var/s3cache
 ```
 
-## Step 3: Configure S3 connection (if not AWS)
+## Step 3: configure S3 connection (if not AWS)
 
 For MinIO or other S3-compatible stores, set the endpoint URL and credentials:
 

docs/sources/how-to/configure-zeo.md

@@ -1,4 +1,4 @@
-# Configure ZEO Client
+# Configure ZEO client
 
 <!-- diataxis: how-to -->
 
@@ -11,7 +11,7 @@ Zope application processes to share a single database.
 - A running ZEO server (see ZODB/ZEO documentation for server setup)
 - The `ZEO` Python package installed
 
-## Step 1: Set the storage type
+## Step 1: set the storage type
 
 In your `instance.yaml`, set the storage backend to `zeo`:
 
@@ -20,7 +20,7 @@ default_context:
     db_storage: zeo
 ```
 
-## Step 2: Configure the server address
+## Step 2: configure the server address
 
 Tell the client where to find the ZEO server:
 
@@ -37,7 +37,7 @@ default_context:
     db_zeo_server: "primary.example.com:8100 secondary.example.com:8100"
 ```
 
-## Step 3: Configure blob storage
+## Step 3: configure blob storage
 
 For ZEO, shared blob storage is recommended. All ZEO clients and the ZEO
 server share a common blob directory (which may be on a network filesystem
@@ -61,7 +61,7 @@ default_context:
     db_blob_cache_size: 10737418240  # 10 GB
 ```
 
-## Optional: Enable persistent client cache
+## Optional: enable persistent client cache
 
 To persist the cache across restarts (reducing startup time and ZEO server
 load), set a client name:

docs/sources/how-to/index.md

@@ -1,21 +1,21 @@
-# How-To Guides
+# How-to guides
 
 <!-- diataxis: how-to -->
 
 Goal-oriented guides for common tasks.
 
-## Database Backends
+## Database backends
 
 - {doc}`configure-relstorage`
 - {doc}`configure-pgjsonb`
 - {doc}`configure-zeo`
 - {doc}`configure-z3blobs`
 
-## Storage Migration
+## Storage migration
 
 - {doc}`migrate-storage`
 
-## Web Layer
+## Web layer
 
 - {doc}`configure-cors`
 

docs/sources/how-to/migrate-storage.md

@@ -1,4 +1,4 @@
-# Migrate Data Between Storage Backends
+# Migrate data between storage backends
 
 <!-- diataxis: how-to -->
 
@@ -12,15 +12,15 @@ using the generic [zodb-convert](https://pypi.org/project/zodb-convert/) tool.
   (e.g. `ZODB` for filestorage, `RelStorage` for relstorage, `zodb-pgjsonb`
   for pgjsonb)
 
-## Approach 1: Generated configuration files
+## Approach 1: generated configuration files
 
 When your instance uses a non-filestorage backend (RelStorage, PGJsonb, or
 ZEO), the cookiecutter generates `convert-import.conf` and
 `convert-export.conf` files in the `etc/` directory. These are ready-made
 configuration files for `zodb-convert` that convert between your configured
 backend and a FileStorage.
 
-### Step 1: Set the conversion paths
+### Step 1: set the conversion paths
 
 In your `instance.yaml`, provide the FileStorage paths for the "other side"
 of the conversion:
@@ -39,29 +39,29 @@ default_context:
 
 These settings work with all non-filestorage backends.
 
-### Step 2: Import data from FileStorage
+### Step 2: import data from FileStorage
 
 Place your `Data.fs` and blobs at the import locations, then run:
 
 ```bash
 zodb-convert etc/convert-import.conf
 ```
 
-### Step 3: Export data to FileStorage
+### Step 3: export data to FileStorage
 
 To create a portable FileStorage backup:
 
 ```bash
 zodb-convert etc/convert-export.conf
 ```
 
-## Approach 2: Using existing zope.conf files
+## Approach 2: using existing zope.conf files
 
 If you have two Zope instances with different storage backends, `zodb-convert`
 can read storage configuration directly from their `zope.conf` files. No
 extra configuration files are needed.
 
-### Step 1: Generate the destination instance
+### Step 1: generate the destination instance
 
 Create a second instance configured for the new storage backend:
 
@@ -79,7 +79,7 @@ cookiecutter -f --no-input --config-file instance-new.yaml \
     gh:plone/cookiecutter-zope-instance
 ```
 
-### Step 2: Run the conversion
+### Step 2: run the conversion
 
 ```bash
 zodb-convert \