docs: add blank lines before lists (#6336)

Signed-off-by: Christof Leuenberger <1931446+chlab@users.noreply.github.com>

docs/api/externalsecret.md

@@ -18,6 +18,7 @@ You can control how and when the `ExternalSecret` is refreshed by setting the `s
 ### CreatedOnce
 
 With `refreshPolicy: CreatedOnce`, the controller will:
+
 - Create the `Kind=Secret` only if it does not exist yet
 - Never update the `Kind=Secret` afterwards if the source data changes
 - Update/ Recreate the `Kind=Secret` if it gets changed/Deleted
@@ -37,6 +38,7 @@ spec:
 ### Periodic
 
 With `refreshPolicy: Periodic` (the default behavior), the controller will:
+
 - Create the `Kind=Secret` if it doesn't exist
 - Update the `Kind=Secret` regularly based on the `spec.refreshInterval` duration
 - When `spec.refreshInterval` is set to zero, it will only create the secret once and not update it afterward
@@ -57,6 +59,7 @@ spec:
 ### OnChange
 
 With `refreshPolicy: OnChange`, the controller will:
+
 - Create the `Kind=Secret` if it doesn't exist
 - Update the `Kind=Secret` only when the `ExternalSecret`'s metadata or specification changes
 - This policy is independent of the `refreshInterval` value

docs/contributing/burnout-mitigation.md

@@ -78,6 +78,7 @@ None of these things will guaranteed solutions, however, they might help.
 CI/CD pipelines can help a lot in taking away some of the menial tasks while working on the project.
 Immediate bot responses for triage issues could be configured using copilot, or other means like claude code github action.
 These responses would use the repository as a context and could give immediate valuable info to the submitter such as:
+
 - Duplicate issues
 - Possible solutions looking at the documentation
 - Link to existing documentation based on context
@@ -143,6 +144,7 @@ Thanks for being part of this community! 🚀
 
 This document sums up various procedures and things that we can do and we can start on. The important part is publication,
 visibility and outreach. There are many channel on which ESO can communicate but the most important ones are:
+
 - Slack ( [external-secrets](https://kubernetes.slack.com/archives/C017BF84G2Y), [external-secrets-dev](https://kubernetes.slack.com/archives/C047LA9MUPJ) channels )
 - Reddit [Kubernetes Subreddit](https://www.reddit.com/r/kubernetes/) ( this was particulalry helpful in the past )
 - HackerNews pos
@@ -162,6 +164,7 @@ When events occur and response do not go as planned, the maintainers team will t
 Here is our DNA: Contributor's healths come first. We will never compromise humans for software.
 
 The team will try (best effort) to:
+
 - minimize impact on community
 - be transparent over any potential impact
 

docs/contributing/devguide.md

@@ -53,6 +53,7 @@ If you need to check license headers locally, you can use the SkyWalking Eyes to
 the running binary in the container using a process manager of its own.
 
 To run tilt, download the utility for your operating system and run `make tilt-up`. This will do two things:
+
 - downloads tilt for the current OS and ARCH under `bin/tilt`
 - make manifest files of your current changes and place them under `./bin/deploy/manifests/external-secrets.yaml`
 - run tilt with `tilt run`

docs/contributing/release.md

@@ -5,6 +5,7 @@ The external-secrets project is released on a as-needed basis. Feel free to open
 ## Multi-Module Versioning
 
 External Secrets Operator uses a multi-module structure with the following modules:
+
 - `/apis` - CRD types and interfaces
 - `/runtime` - Shared utilities
 - `/providers/v1/*` - Individual provider modules
@@ -48,6 +49,7 @@ Otherwise the `latest` documentation will point to the older version. Also avoid
 5. CI picks up the new chart version and creates a new GitHub Release for it
 
 The following things are updated with those commands:
+
 1. Update helm docs
 2. Update the apiVersion in the snapshots for the helm tests
 3. Update all the helm tests with potential added values

docs/examples/pushsecret-datato.md

@@ -58,6 +58,7 @@ spec:
 ```
 
 **Result in AWS Secrets Manager:**
+
 - `myapp/production/database/host`
 - `myapp/production/database/port`
 - `myapp/production/database/username`
@@ -195,6 +196,7 @@ spec:
 ```
 
 **Result:**
+
 - `config/database/host`
 - `config/database/password`
 - `config/api/github-token`
@@ -244,6 +246,7 @@ spec:
 {% endraw %}
 
 **Result:**
+
 - `services/PAYMENT_GATEWAY_KEY`
 - `services/EMAIL_SERVICE_KEY`
 - `services/STORAGE_SERVICE_KEY`
@@ -298,6 +301,7 @@ spec:
 ```
 
 **Result:**
+
 - `migrated/db/primary/host`
 - `migrated/db/replica/host`
 - `migrated/cache/redis/url`
@@ -355,6 +359,7 @@ spec:
 ```
 
 **Result:**
+
 - `app/database/host` (from dataTo)
 - `app/database/port` (from dataTo)
 - `app/database/user` (from dataTo)
@@ -451,6 +456,7 @@ spec:
 ```
 
 **Result:**
+
 - `services/a/api-key`
 - `services/b/api-key`
 - `shared/secret`
@@ -552,14 +558,17 @@ kubectl get pushsecret <name> -n <namespace> -o jsonpath='{.status.syncedPushSec
 ### Common Issues
 
 **1. No keys matched:**
+
 - Verify the source Secret has keys matching your pattern
 - Check regexp syntax: `kubectl get secret <name> -o jsonpath='{.data}' | jq 'keys'`
 
 **2. Invalid regexp error:**
+
 - Validate your regexp using an online regexp tester
 - Ensure special characters are properly escaped
 
 **3. Duplicate remote keys:**
+
 - Check if your rewrites produce unique keys
 - Adjust patterns or use explicit data overrides
 

docs/guides/templating.md

@@ -154,10 +154,12 @@ When a provider returns RSA-encrypted values, you can decrypt them directly in t
 `rsaDecrypt` performs decryption with the private key passed through the pipeline: `<privateKeyPEM | rsaDecrypt "<SCHEME>" "<HASH>" <ciphertext> >`. `SCHEME` and `HASH` are strings (for example, `"RSA-OAEP"` and `"SHA1"`). The third argument must be the ciphertext in binary form.
 
 Base64 handling: providers often return ciphertext as Base64. You can either:
+
 - decode in the template with `b64dec` (for example: `(.password_encrypted_base64 | b64dec)`), or
 - set `decodingStrategy: Base64` on the corresponding `spec.data.remoteRef` so the template receives binary data.
 
 Prerequisites
+
 - `spec.target.template.engineVersion: v2`.
 - A valid RSA private key in PEM format without passphrase (from another reference in the same ExternalSecret).
 - Ciphertext must match the key pair and the chosen algorithm/hash.
@@ -169,10 +171,12 @@ Full example:
 ```
 
 Useful variations (included as comments in the example):
+
 - Base64 decode in the template with `b64dec` or via `decodingStrategy: Base64` on `spec.data`.
 - Use a private key available in the same ExternalSecret (for example: `( .private_key | rsaDecrypt ... )`).
 
 Error notes
+
 - Referencing a missing key in the template will fail rendering.
 - If key/algorithm/hash do not match the ciphertext, decryption will fail and reconciliation will retry.
 

docs/introduction/faq.md

@@ -25,6 +25,7 @@ kubectl get es my-external-secret -o yaml | grep refreshTime
 ```
 
 The interval can be changed by the `spec.refreshInterval` in the ExternalSecret. You can also control the refresh behavior by setting `spec.refreshPolicy` to one of the following options:
+
 - `Periodic` (default): Update regularly based on refreshInterval
 - `CreatedOnce`: Create the Secret only once and never update it afterward
 - `OnChange`: Only update when the ExternalSecret's metadata or specification changes

docs/introduction/stability-support.md

@@ -10,6 +10,7 @@ This page lists the status, timeline and policy for currently supported ESO rele
 external-secrets only supports the most-up-to date, current minor version. Any other minor version releases are automatically deprecated as soon as a new minor version comes.
 
 During a minor version support time, we cover:
+
 - regular image rebuilds to update OS dependencies
 - regular go dependency updates
 

docs/provider/aws-parameter-store.md

@@ -126,6 +126,7 @@ The SetSecret method for the Parameter Store allows the user to set the value st
 #### Additional Metadata for PushSecret
 
 Optionally, it is possible to configure additional options for the parameter. These are as follows:
+
 - type
 - keyID
 - tier & policies

docs/provider/aws-secrets-manager.md

@@ -126,6 +126,7 @@ Additional settings can be set at the `SecretStore` level to control the behavio
 #### Additional Metadata for PushSecret
 
 Optionally, it is possible to configure additional options for the parameter. These are as follows:
+
 - kmsKeyID
 - secretPushFormat
 - description

docs/provider/barbican.md

@@ -204,6 +204,7 @@ If a secret cannot be found:
 ### Network Connectivity
 
 Ensure your Kubernetes cluster can reach:
+
 - The OpenStack Keystone endpoint (for authentication)
 - The Barbican service endpoint (for secret retrieval)
 

docs/provider/doppler.md

@@ -51,6 +51,7 @@ metadata:
 ```
 
 Next, create a Doppler Service Account Identity with:
+
 - **Issuer**: Your cluster's OIDC discovery URL
 - **Audience**: The resource-specific audience for the SecretStore (`secretStore:<namespace>:<storeName>` or `clusterSecretStore:<storeName>`), e.g. `secretStore:external-secrets:doppler-oidc-sa` or `clusterSecretStore:doppler-auth-api`
 - **Subject**: The Kubernetes ServiceAccount (`system:serviceaccount:<serviceAccountNamespace>:<serviceAccountName>`), e.g. `system:serviceaccount:external-secrets:doppler-oidc-sa`

docs/provider/hashicorp-vault.md

@@ -575,11 +575,13 @@ external-secrets --enable-vault-token-cache --vault-token-cache-size=262144
 #### When to Use Token Caching
 
 Token caching is beneficial when:
+
 - Using authentication methods that generate short-lived tokens (e.g., AppRole, Kubernetes auth)
 - Running multiple ExternalSecrets that use the same SecretStore
 - Experiencing high token generation overhead
 
 Token caching should **not** be used when:
+
 - Using static tokens (no performance benefit)
 - Security requirements mandate fresh tokens for each request
 - Memory usage is a concern

docs/provider/ibm-secrets-manager.md

@@ -259,6 +259,7 @@ ESO can add metadata while creating or updating a Kubernetes secret to be reflec
 In order for the user to opt in to adding metadata to secret, an existing optional field `spec.dataFrom.extract.metadataPolicy` can be set to `Fetch`, its default value being `None`. In addition to this, templating provided be ESO can be leveraged to specify the key-value pairs of the resultant secrets' labels and annotation.
 
 In order for the required metadata to be populated in the Kubernetes secret, combination of below should be provided in the External Secrets resource:
+
 1. The required metadata should be specified under `template.metadata.labels` or `template.metadata.annotations`.
 2. The required secret data should be specified under `template.data`.
 3. The spec.dataFrom.extract should be specified with details of the Secrets Manager secret with `spec.dataFrom.extract.metadataPolicy` set to `Fetch`.

docs/provider/ovhcloud.md

@@ -3,11 +3,13 @@
 External Secrets Operator integrates with [OVHcloud KMS](https://www.ovhcloud.com/en/identity-security-operations/key-management-service/).  
 
 This guide demonstrates:
+
 - how to set up a `ClusterSecretStore`/`SecretStore` with the OVH provider.
 - `ExternalSecret` use cases with examples.
 - `PushSecret` use cases with examples.
 
 This guide assumes:
+
 - External Secrets Operator is already installed
 - You have access to OVHcloud Secret Manager
 - Required credentials are already created

docs/provider/secretserver.md

@@ -369,6 +369,7 @@ updated. Using a plain name will update the **first match** returned by the API.
 #### Deletion Behavior
 
 The `PushSecret` resource allows you to configure what happens to the remote secret in Secret Server when the `PushSecret` itself is deleted, via the `PushSecret.spec.deletionPolicy` field. Supported values are:
+
 - `Retain`: (Default) The remote secret is left intact in Secret Server when the `PushSecret` is deleted.
 - `Delete`: The provider will attempt to delete the remote secret from Secret Server when the `PushSecret` is removed.